Since you’re reading this, I’m going to go out on a limb and guess that you’ve only landed on my blog in order to enjoy a quick moment of mirth at the expense of the imperfect proles who actually need my advice.  Drink it in.  You’ve earned it.

If you don’t fit into that camp, don’t worry!  You’re exactly the person that they had in mind when they designed Ruby!  Or Python!  Or any one of a dozen other languages with a REPL.  Don’t worry, I know you know what a REPL is, but I’m going to prove that I know what it is, so that you can skip straight to agreeing with me, thereby proving that you knew what I was talking about the whole time.

“REPL” is just technobabble that means “Read-eval-print loop”.  Still too much technobabble?  The REPL is the cool little tool that lets you run big-boy code from an interactive shell and it gives you the ability to get inside the computer and poke around while your program is running.  It’s so simple.  It’s IN the computer…:

I’m (not) a computer

The above screenshot gives a tiny example of the sorts of things you can do with your Ruby REPL.  I picked Ruby for this example, but you’d see something similar in any language that provides a REPL.  You can do simple stuff like print a string, or, even better, you can dig into your application and just mess with things!  After all, who doesn’t like to mess with things?!  That couldn’t possibly have side-effects, right?

Anytime you can use an interactive mode like the ones I mentioned above, it’s going to be easy to get close to the application that you’re developing.  These tools are extremely powerful, especially when you combine them with some sweet Dependency Injection action.

One day, you’ll see the light that is Java and you will be amazed.  With a healthy supply of semi-colons, you’ll migrate your application to Java while shedding a tear for all the lost time that you could have spent together.  Migrating from one language to another is easy, so you’ll immediately want to fire up your Java interpreter and mess with all of the things in your new Java app.

Unfortunately for you, Me-from-the-past is going to tell you “No dice.”  Java doesn’t come with an interactive mode out-of-the-box.  The closest that you could come to a REPL in Java was using the Java Management Extensions (JMX) to examine registered resources.  After you register a few Beans, you’ll hopefully be able to run something like JConsole to look at your application’s guts.  If you did everything right, you’ll probably see some objects that you can look at… and you’ll immediately begin thinking that maybe you should migrate back, if only to get your REPL back.

Fortunately for you, Me-from-right-now is here to tell you that our own brilliant Marshall Pierce has felt your pain and has leveraged the arcane magics of Groovy and SSH to provide you with a mega-hammer that he assumes you are not going to use to hit yourself in the face: a interactive prompt for your JVMs, both local and remote! A local REPL for exploring your app in dev mode is great, but a remote REPL for poking around in your live app is even better. (Where by better, I mean dangerous and awesome.)

“Wh—…H—…How did he do that?” you might ask, ever so eloquently.  Basically, you’ll embed a tiny SSH server that exposes a Groovy shell that can execute arbitrary code inside a running JVM.  Marshall has helpfully provided a small demo app that shows exactly what this looks like.  Seriously, go run the example project.  When you do and you realize how you have now become the master of time and space, you won’t have anything to say except, “That was easy.”

Hopefully, you skipped right over that part about executing arbitrary code in your JVM, because that sounds terrifying.  But, if that made you a little queasy, you can rest easy knowing that your precious JVM is safe and sound.  With only a few more characters, you can tell your app where to find a set of public keys (RSA or DSA) that it can use to authenticate SSH requests.  Now, when you run your Groovy shell, you just have to specify the location of your private key file, and you’ll automatically get the secure handshake that feels ever-so-good.

If you’re looking for more detail, you should check out the project’s public GitHub page, where you will find helpful instructions on how you can start poking around where James Gosling never intended for you to be…

The post One Weird Trick to SSH into your JVM appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

Today, Palomino Labs is equal parts proud, confused, and apathetic to announce the release of 2 Tumble 2 Jump, the second in a series of games that puts the player squarely where they want to be: in the mind of a frozen tumbleweed.

The masses have spoken!  We have listened to what they said!  And we have ignored what they said in favor of bringing you more Tumble Jump!!!  After all, who knows you, better than us?  And we say that you want more tumbleweeds!

You probably thought that your phone doesn’t need more than one game about tumbleweeds.

You probably thought that you could escape Ol’ Slopey Mountain.

You probably thought that Yetis and cacti don’t share exactly the same shape.

You probably thought that we would introduce new mechanics in a sequel game.

YOU THOUGHT WRONG!!!

We humbly accept your apology, and we offer you the chance to atone for your past mistakes by downloading 2 Tumble 2 Jump right now.  You’ll find the same tumbling and jumping that enthralled you the first time around, but this time it’s winter.  What does that mean?  It means that there’s snow now!  And Yetis!

Submit your PTO requests; arrange for the kids to stay at Grandma’s; prepare the hydration IVs— because you’re going to want to play this game way more than you should.

The post 2T2J Release appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

Tweaks is designed to bridge the gap between developers and designers during the development phase of a project.  Unless a single person is playing the roles of both the designer and the developer, there’s going to be a lot of communication overhead during the refining process of the UI.  The process usually starts with the designer bringing mockups to the developer.  The developer takes these screens and tries to get as close as possible to what the designer had in mind.  Since we’re talking about (at least) two different people, thinking in (at least) two different ways, we can almost guarantee that the product is not going to match the vision.  Even if the developer somehow magically manages to implement the exact thoughts of the designer, it may turn out that what the designer had imagined doesn’t make sense after all.  Regardless, in a project of any scale, both sides are going to spend a lot of time going back and forth in a conversation that you might recognize.

Developers and Designers: Can’t we just get along?

The real problem here is that we can’t afford to have designers and developers working on the same screen while a UI is being created.  It would be hugely inefficient because they speak different languages (or at least different dialects) and it’s pretty much impossible to keep both people actively working the whole time.  That’s why we’re forced to have this back-and-forth conversation that wastes time with multiple deployments and context-switching.

It seems to me like Tweaks is going to consolidate the back-and-forth into a single conversation that looks more like this.

Fewer iterations == more efficient.

Tweaks allows a developer to expose certain UI properties to a designer (or really, anyone who has a dev build of the application) who can update those values dynamically.  While the designer is reviewing the developer’s work, they can use the shake gesture to bring up a secret menu that lets the designer change values on the fly.

One easy example to imagine is adjusting the background color.  This is an extremely easy task for a developer, but the time required to redeploy and pass the changes on to the developer is going to be wasted.  On the other hand, the designer might not know how to change the background color and might not even have access to the source.

Before Tweaks, the developer probably would have hardcoded the view with something like this:

self.backgroundColor = [UIColor colorWithRed:0.2
                                       green:0.9
                                        blue:0.2
                                       alpha:1.0

And then when the designer comes back and tells the developer that the background color should be more red, they’ll update those hardcoded values and push a new version to the designer.  If the designer doesn’t have specific RGB values in mind, this could be repeated several times while they zero in on the color that is “just right.”

Instead, Tweaks is proposing that you replace those hardcoded values with a Tweaks macro like this:

self.backgroundColor =
    [UIColor colorWithRed:FBTweakValue(@"Window", @"Color", @"Red", 0.2)
                    green:FBTweakValue(@"Window", @"Color", @"Green", 0.9)
                     blue:FBTweakValue(@"Window", @"Color", @"Blue", 0.2)
                    alpha:1.0

The first three arguments describe where in the Tweaks hierarchy you’ll find the adjustment.  In this example, you’d be able to change the red component of the RGB value by going to the “Window” section and looking for the “Color” section of that table.  As you can see below, you’re able increment or decrement the values that developer exposed, or you can tap the value itself to show a keyboard if you have a specific value in mind.  In addition to numeric values you can expose other basic data types like strings and booleans.

What the designer will see after they shake the device and navigate to the leaf values.

Are you worried about how this library will affect your production releases?  You should be!  However, you can rest easy knowing that the adjustment functionality is disabled by default in production.  When you deploy in production mode, the macros are expanded into the default values that the developer provided.  This means that you don’t incur any performance penalty for evaluating values, and at the same time you don’t expose any secret dev options to the end user.

Final Thoughts?

• It’s a very cool idea and one that I’d really like to start including in my iOS projects.
• Fortunately for us, Ron (the brilliant gentleman who most often wears the designer hat at Palomino) is more than capable of manipulating an iOS view himself, so I’m not sure how much time it would actually save us.
• This is still going to require some designer-developer face time, so that the developer can show the designer what things can be tweaked.  It’s easy to understand in a small example, but when you have a real app with lots of changeable properties, the developer is going to have to be very careful about how he organizes the hierarchy of adjustable properties.  It would be very helpful to take some time to explain his scheme to the designer.
• This library would really benefit from an export function.  When a designer finishes making all of the adjustments that he wants, there should be some easy way for him to pass the new (changed) values back to the developer.  As far as I know, there is currently no functionality to do this.  Update: it looks like this ticket was raised to accomplish the exact thing that I want, but it hasn't been merged yet.  Hopefully soon!
• The library is still young and has a few rough edges.  For example, installation via Cocoapods did not work for me.  I found this issue that claims to resolve the problem, but it was easier for me to just drop the library into my project.  If it continues to grow and be maintained, I expect these sorts of problems to disappear, but make sure you go into it with your eyes open.

The post Too Much Pressure or: How I Simplified My iOS Design with the Tweaks Library appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

The Docker community is full of wide-eyed idealists who see the world as a place of default configurations and simple use cases using only the latest things. The Docker examples include Node.js, CouchDB, and Riak, among others. No mention of, say, Rails, despite it being one of the most popular frameworks over the past 5 years. I’ll try to fill that void.

What this tutorial covers

This blog post is an introduction to Docker for folks who use Rails. You don’t have to know anything about Docker, but you do need to know how to get a Rails app running. I’ll walk you through setting up Docker for development on a Mac, creating a Dockerfile, and running that Dockerfile on your development Docker host.

If you don’t have a Rails application, go make one. There are numerous tutorials on creating a simple Rails app. This tutorial assumes you have an existing Rails app that you want to deploy with Docker.

Setting up Docker

Setting up a development environment for Docker is pretty easy using their provided instructions—the Provisioning instructions are what you want. Some things I mention below are using those instructions on a Mac; namely, I’m using boot2docker, which automates the management of a virtual machine that acts as your Docker server.

One note: boot2docker creates a VirtualBox VM that uses NAT, but it does not map any ports to be accessible from the host machine. After issuing boot2docker init, you should run:

VBoxManage controlvm boot2docker-vm natpf1 "rails,tcp,127.0.0.1,3000,,3000"

Which will map port 3000 on your local machine to port 3000 on the Docker VM. Later, we will have our Docker container listen on port 3000 and without this mapping it will be inaccessible.

Creating a Docker file

The only thing you need to Dockerize your app is a Dockerfile. This defines how docker build will assemble the container for your app and how docker run will execute it. The beginning of the Docker file defines what base image to use:

FROM ubuntu

Like a lot of Rails developers, we use a Ruby runtime manager to ensure consistency across different developer systems. In our case, we use RVM, but a similar approach could be used for rbenv. The first thing we need to do is install RVM in our container and install the Ruby version we use:

RUN curl -sSL https://get.rvm.io | bash -s stable
RUN /bin/bash -c -l 'rvm requirements'
RUN /bin/bash -c -l 'rvm install 1.9.3-p448'
RUN /bin/bash -c -l 'rvm use 1.9.3-p448'
RUN /bin/bash -c -l 'gem install bundler --no-ri --no-rdoc'
RUN /bin/bash -c -l 'bundle config path "$HOME/bundler"'

The first command is the familiar one-line install for RVM. With it installed, we run the subsequent commands using the rvm-shell so that they have the rvm environment. After installing the Ruby that our app prefers, we install Bundler.

The last bit of setup is to pull the Rails application code into the container and install the gems that it needs:

ADD . pl-site
WORKDIR pl-site
RUN /bin/bash -c -l 'bundle install'

The final bit of our Dockerfile tells Docker what port to expose and how to run the Rails server:

EXPOSE 80
CMD /bin/bash -c -l 'ruby script/rails server -p 80'

The entirety of the Dockerfile looks like this:

FROM ubuntu

RUN apt-get update -q
RUN apt-get install -qy curl

RUN curl -sSL https://get.rvm.io | bash -s stable
RUN /bin/bash -c -l 'rvm requirements'
RUN /bin/bash -c -l 'rvm install 1.9.3-p448'
RUN /bin/bash -c -l 'rvm use 1.9.3-p448'
RUN /bin/bash -c -l 'gem install bundler --no-ri --no-rdoc'

RUN /bin/bash -c -l 'bundle config path "$HOME/bundler"'

ADD . pl-site
WORKDIR pl-site
RUN /bin/bash -c -l 'bundle install'

EXPOSE 80
CMD /bin/bash -c -l 'ruby script/rails server -p 80'

Building the container

With the Dockerfile written, the container can be built with docker build:

docker build -t container_name .

This command will take a while to run and produce a lot of output as Docker assembles your container: downloading the base image, installing RVM & gems, and putting your code in place.

Running the container

With the container built, you can run it on your development docker instance:

docker run -p 3000:80 container_name

This runs the container, mapping port 3000 on your local machine to 80 on the container, where the Rails server is listening.

Stopping the container

The docker run command executes in the foreground but ignores SIGINT (i.e. ctrl+c) by default. You can stop & remove the container with this one liner:

docker rm -f `docker ps -lq`

Resetting the Docker host

Docker aggressively caches throughout the build process—each step of your Dockerfile is saved so that subsequent runs of docker build can skip parts that have completed successfully. Unfortunately the caching, like that in so many projects, can cause problems when you’re developing. Sometimes it can be fixed by clearing the cache of Docker steps with docker rm `docker ps --no-trunc -a -q`. More often than not, though, I’ve had to go a step further and blow away the Docker host altogether. Since it is a VM controlled by boot2docker, removing & recreating it is easy. I’ve settled on this one liner that I run whenever I want to really rebuild the container:

boot2docker stop && boot2docker delete && boot2docker init && \
VBoxManage controlvm boot2docker-vm natpf1 "rails,tcp,127.0.0.1,3000,,3000" \
&& boot2docker start

Code

The example code used here is on GitHub. Note that there is an ultra-simple branch, echo, that makes an echo server in Docker.

The post Introduction to Docker with Rails appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

As you’re reading this, it’s important to keep in mind that the Ninefold Rails platform is relatively young and still looking to build out it’s feature set.  With that in mind, a big part of what I’m evaluating is potential.  There are certainly other, more mature tools that have more features, but what I saw in Ninefold was promising enough to bring it to your attention.

Interface

Before you start using Ninefold, you should know that the GUI is going to let you do most of the things you want to do, but it’s going to be in a very no-nonsense kind of way. If you came from the Ninefold home page—which looks very cool with its faceted design—you might be expecting a dashboard with a lot of personality and a cool design. I wouldn’t call any of the dashboard pretty, but any developer is going to be immediately comfortable within it, and it’s going to let you get things done efficiently.

The last time you’ll see any color…

The no-nonsense dashboard

I found that it was fairly straightforward to navigate around the dashboard and I never found myself asking “Where do I go now?”

The one big downside to the web dashboard is that it tends to be slower than I’d like.  Every tab is a separate page load, and it doesn’t take long to start feeling the pain of that.  That said, I didn’t feel like it was unusably slow and I’m hoping that that’s something that would improve with time.

Logging

In my experience, log aggregation is one of those things that seems like it should be easy, but is never as elegant as I would like it to be. I am very happy to say that this is not the case for any Ninefold apps that you might create. Once you deploy an app, the Ninefold dashboard shows a logging section that makes debugging and issue resolution much easier.

The logs for my application along with the sources that are available.

Log Searching

If you look at the screenshots, you’ll notice that the dashboard kindly offers you the ability to string-search whichever logs you’re looking at. When I look at a log, I almost always want to do some kind of search like this, so the fact that it’s built in is pretty cool and it saves me a bunch of munging that I might otherwise have to spend time on. As happy as I was to see a built-in log searcher widget, I was even more excited to see the ability to select sources and hosts of logs to filter by.

Log Filtering

When I write to a log, I always feel like I’m trying to walk a fine line between giving enough information to diagnose issues that may crop up and giving so much information that the really important stuff is lost in a sea of garbage. Ninefold makes me feel much better about my logging because they allow you to restrict what you’re looking at to one (or many) of any of a dozen different logging mechanisms. Most of the time, I don’t want to see something like the migration logs, so I can remove those from the list of what is displayed. Being able to filter at a high level like that is really cool and it’s something that I’m going to miss the next time I’m not on Ninefold. It’s worth noting here that you can do the same thing, relative to the servers that you’re deployed on. If you’re running on two different hosts, you can restrict your log view to only look at the host(s) that you’re concerned with. I was running a simple app with just a single host, so I didn’t have reason to use that feature, but I can imagine it being really cool in a high-traffic production environment.

Support

It seems to me like Ninefold is still trying to gain traction (at least here in the States) so they don’t have nearly as big of a user community as some other platforms might.  When I started using Ninefold, I was a little worried that this would mean that it would be easier to get stuck on one issue or another.  After using it for a while, I think that it would be hard to argue against that unfortunate truth.  However, in my experience, the in-app support that Ninefold offers is good enough that the smaller community ends up not even being a factor.  I rarely had any problem figuring out what to do next, but when I did get stuck, Ninefold has a little “Chat Now” dialog on the bottom of every page that connects you almost instantaneously with a support person.  Normally, I avoid these support chats as much as possible, but the person who answered my support requests was prompt, obviously familiar with the framework, and had the power to solve my problem.  I’m no longer worried that I’ll run into any sort of significant blocker that would halt my development.

Data Migration

The thing that I was probably least happy with during my Ninefold experience was the way that you interact with data.  I started with an app that one of my coworkers built that tracks the beers that we’re trying at Palomino Labs.  The app is new and the existing dataset is relatively small, so I wanted to import the data from the real app into my test app.  Unfortunately, it doesn’t seem like there’s a good way to do that from the dashboard.  I was able to take a snapshot of the other database without any problem, but I couldn’t find any way to bootstrap my app with that snapshot.  I ended up using the Ninefold CLI gem to manually recreate a few important pieces of data (e.g. app user accounts) and then living in a sad reality where my app didn’t have much data.

At this point, I would like to add two caveats to my complaints here.  First, like I mentioned above, Ninefold provides a CLI that I didn’t explore much, but that seems like it would be pretty useful.  I didn’t try to do any sort of data restoration through that system, instead preferring to use it just like a Rails console.  It’s possible that the CLI provides a way to restore database backups, but I was trying to restrict my usage to the dashboard as much as possible.  The second caveat is that I mentioned this specific use case to one of the Ninefold developers last time I had a chance to talk with them, and it sounded like this might be on the short-term roadmap.  I’m hopeful that the next update to the dashboard includes a means to restore backups.

Deployment

The first thing that I’ll note about deployment is that it’s extremely easy.  If you have a git repo in Github or Bitbucket, Ninefold provides you with a handy little wizard that will create your app in about 30 seconds.  It’s easy to deploy from branches, and you can check a box to add post-commit hooks that will automatically redeploy  your app whenever you make a change.  I never had any problems with the post-commit hooks on this project, but one of my coworkers reported that the hooks stopped working for him mid-development.  This is one of the areas that I’m willing to overlook some rough edges because of the new-ness of the platform and I’m fairly confident that this is a piece of functionality that the Ninefold developers are fully on top of.

The big downside to the deployment process was that it seemed to take a fairly long time for me.  Due to a few of my own mistakes, I had to redeploy our (small) app 3-4 times in a short timespan, and it seemed like I was waiting about 10-15 minutes for each deploy.  I don’t expect anything blazingly fast, but I spent more time waiting on a deployment than I would’ve liked.

Add-Ons

At the moment, the Ninefold ecosystem is a little bit young and that shows in the number of add-ons that are available to include in the app.  There are a handful of cool-looking modules (e.g. New Relic, SSL, etc.) that you can add to your app with the click of a button, but you’ll need to wait (or roll your own) if you want to use any modules that aren’t on the shortlist.  That said, the number of add-ons that ARE available right now is totally reasonable given the age of the platform, and they claim some interesting functionality (like when they set up a New Relic account for you, if you don’t already have one).  I’m optimistic that more tools are going to get added as time goes on, so if you have something you need, try reaching out to them.

Environments

I have yet to see a Rails hosting platform that is really good at splitting an app into different environments (e.g. staging and production environments for a single logical app) and I didn’t feel like Ninefold did much to solve that problem.  I only deployed one version of our app, but when I talked to Hayden about how he solved the environment problem, he told me that he just handles the environments as separate apps.  So, we have one app for production and one for staging and there is nothing (except the code) in common between the two.  I don’t fault Ninefold in any way here, because I’m not sure how I want these to be related in the interface, but it seems like they could be linked better.

Overall

After spending some time with Ninefold, I’m fairly happy with the service.  It’s still a young product, but what they have is solid and, even better, they seem to be moving in the right direction.  If you have the time, I’d definitely recommend checking it out to see if it fits in your workflow.

The post Easy, Fast, Powerful: This is Your Rails on Ninefold appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

• Better Touch Support.  If you’ve ever tried to use your Ext JS 4 application on an iPad, you know that the experience leaves a lot to be desired.  A few of the most glaring issues — scrolling and touch events — have been resolved in Ext JS 5.  It’s important to stress that Ext JS 5 is still a framework for building applications for desktop browsers, and Ext JS 5 is not a replacement for a mobile framework like Sencha Touch, but at least now your Ext JS apps will be functional on an iPad.
• Two-Way Data Binding.  Previous versions of Ext JS made many complicated things very easy: grids and RESTful AJAX come to mind.  But one thing that always bothered us was that updating a view when model data changed — or vice versa — was always more work than it seemed like it should be.  Ext JS alternatives like Ember.js, for example, make binding data to views painless by comparison.  With Ext JS 5, two-way data binding is finally a reality. Gone are the days of boilerplate code juggling data changes between the various layers.  Ext JS 5 introduces a very simple but powerful templating language to wire views and view models together.  Rejoice.
• View Controllers. Ext JS is great for building reusable components for large applications.  One drawback of this approach, however, is that you often find yourself having to choose between cluttering your view classes with control logic specific to that view (violating MVC), or duplicating that control logic in increasingly-complex, bloated, and non-DRY controllers.  This problem is magnified when you start needing to manage multiple instances of the same component independently of one another.  Well, good news friend: Ext JS 5 introduces the concept of a View Controller, which is essentially an instance of a controller tied to a specific view instance.  Instantiating a second instance of the view creates a second, independent View Controller.  Ext JS 5 even takes care of the memory management for you.  We expect that this will make our applications far simpler and more maintainable.
• View Models.  Another anti-pattern that we often find in our Ext JS applications is that data-level logic often creeps into view classes.  Think store configurations, or manipulating model data (e.g., concatenating first and last name, or calculating averages).  The new View Models in Ext JS 5 are classes (again, tied to specific view instances) responsible managing data munging so that views can just be views.  Together, View Models and View Controllers are a huge win for separation of concerns enthusiasts like ourselves.
• Routing.  Previous versions of Ext JS have had token support for URL-based routing, in that they provided a utility class for interacting with hash changes.  In practice, though, deep-linking and URL-based routing required writing a fair amount of custom logic.  This meant that deep-linking was often either completely ignored or bolted on later as an afterthought.  In Ext JS 5, routes are now first class citizens.  We can now define routes in the controller, complete with pattern-matched URL tokens, and per-action interruptible before filters.  Routing in Ext JS 5 is now so easy that there’s no reason not to build it into your app from the beginning.
• Chained Stores.  Ext stores make it very easy to load and filter data from a server.  But what if you want several stores with slightly different views of the same basic dataset?  If you apply filters, those filters are reflected in every component that uses that store, so filtering a grid might have unintended consequences elsewhere in your application.  As a result, it becomes common practice to create several different versions of the same basic store.  While this is conceptually easy to maintain, it adds quite a bit of memory and network overhead, as loading these stores will actually load the same records individually.  Enter the new Chained Stores.  Now, multiple stores can share the same pool of records (each of which is loaded over the network  only once), while each store has their own filters applied.  It’s the best of both worlds: clear code, and efficient memory and network usage.
• Data Sessions.  Ext JS 5 introduces a new concept called a Data Session, which aims to keep track of multiple (possibly dependent) changes to several models, allowing for efficient and intelligent bulk updates.  Data Sessions can also be used to isolate change sets, in effect giving you some of the powers of database transactions.  This feature is definitely a departure from how JavaScript developers are used to interacting with models, but it sounds like a very powerful new tool that’s worth checking out.
• Components in Grid Cells.  We can now put buttons in grid cells.  That’s all I have to say about that. (But sparklines look pretty cool too.)

Those are just a few of the improvements coming in Ext JS 5.  For a more complete list, check out What’s New in Ext JS 5.  We’re certainly looking forward to all the new goodies.

The post Ext JS 5: Now With 25% More Ext JS appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

In the hallway you’ll find our coffee station, with a Breville espresso machine and a Chemex, as well as a dozen or so varieties of beans from a number of our favorite roasters. On display in the main work area are our bowling trophies, including Ron’s 1st place win. And then… there’s beer.

From our office kegerator, built and stocked by our resident homebrewer Tyler, to our substantial bottle collection, it should be no surprise that we take beer very seriously here at Palomino Labs.

While we have tried to convey all of this in our company’s culture page, there’s only so much you can capture with a static page. So it was about time for a Web 2.0 upgrade (sure, we’re a decade behind the trend, but who’s keeping track).

Now when you visit our site, you can see what bottles we have around the office these days and an activity feed with the latest additions to our collection, the most recently opened bottles, and our thoughts on them.

These widgets are driven by a simple rails app running on Ninefold. In addition to keeping track of our inventory and reviews, the app is also integrated with BreweryDB to get label art and other relevant properties of the beers. We hope these additions will give you a little more insight to our love of beer, and will encourage you to stop in for a taste the next time we open something. Cheers!

The post What’s Being Poured at Palomino Labs appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

Some Backstory

Parse is the latest BaaS provider we’ve experimented with, but it is not the first. If you’re familiar with our blog, then you’ve likely seen our post on how to build An App in an Afternoon using StackMob. We liked the idea of BaaS, especially as a tool for rapidly prototyping web apps, and intended to use StackMob as part of an application to help a startup vet their idea. We had just sent our client a proposal and were out for our regular Taqueria Tuesday lunch when it was announced that PayPal was acquiring StackMob.

With the future of StackMob’s service up in the air, we had to find a new backend option. Parse had also undergone an acquisition in 2013. However, unlike StackMob which is shutting down, Parse lived on and continued to improve as one of the tools offered by Facebook for application developers. Many of the concerns we had with Parse back in mid-2012 had since been addressed (like the lack of cloud code, which was introduced that Fall). So we decided to use Parse as the backend solution.

Fast forward two months… the app is complete and in the hands of our clients. The verdict on Parse: it is a great way for a single developer to quickly build a throw-away prototype, but professional web app developers are not their current target audience. Now that might sound a little harsh, so lets take a step back and discuss some of the gotchas we encountered while developing that lead to this conclusion and that anyone considering using Parse for their backend should be aware of.

The Gotchas

No Multi-Environment Support

Parse applications have no built-in support for multiple build environments. The recommended solution is to create separate applications for your development, test, and production environments. While creating new applications in Parse is fairly simple, there is currently no way to clone applications or programmatically create them to ensure each of your “environments” has the same class structures and permissions. We ended up manually comparing and updating our environment applications whenever we wanted to ‘synchronize’ them, which took time and was prone to human error.

Security Means More Cloud Code

We had planned to use Cloud Code from the start to run cron jobs for sending emails. As we worked with Parse throughout the development process, it became clear we’d also need to use it extensively to implement some form of security. Parse allows you to configure static class level permissions through their data browser. But for anything more dynamic, such as restricting an entry to only allow the creator to update it, you need to assign a custom Access Control List (ACL) to each entry as it’s created.

ACLs can be defined by the client or in Cloud Code. While creating ACLs in client code is easier, it leaves your application vulnerable to malicious requests that were not generated by your code. So it is better to generate ACLs by adding beforeSave Cloud Code hooks to each of the classes you need to restrict. For example:

Parse.Cloud.beforeSave("YourClass", function (request, response) {
    var entry = request.object,
        creator = request.user;

    // The inputs to a beforeSave are not guaranteed. For
    // example, adding a 'YourClass' object in the Data
    // Browser will not have a user associated with it.
    // So we must check for the creator's existence first
    if (creator) {
        // beforeSave could be triggered by a create or
        // update. So we confirm the entry isNew before
        // adding an ACL.
        if (entry && entry.isNew()) {
            creator.get("accessRole").fetch().then(
                function (role) {
                    var acl = new Parse.ACL();
                    acl.setRoleReadAccess(role, true);
                    acl.setReadAccess(creator, true);
                    acl.setWriteAccess(creator, true);
                    entry.setACL(acl);
                    response.success();
                },
                function (error) {
                    console.error("Failed to fetch accessRole");
                    response.error();
                });
        } else {
            // This allows for updates to go through for
            // authenticated users
            response.success();
        }
    } else {
        // This unfortunately blocks the data browser
        // from creating entries. However it also
        // prevents unauthenticated users from
        // creating them.
        console.error("Unauthenticated user");
        console.error("...or maybe an admin?");
        response.error();
    }
});

As the example shows, you can generate appropriate ACLs with user and role (group) access for each entry as it’s being added to the class with custom Cloud Code. One important thing to watch out for when writing these hooks is that Parse executes the beforeSave logic for both CREATE and UPDATE operations, but the inputs in these two situations can be very different.

Cloud Code Frustrations

Speaking of writing Cloud Code, there are several major limitations that hindered our ability to develop reliable code efficiently. There’s no developer server that allows emulating Cloud Code functionality locally, which means you have to deploy it every time you want to test any code changes. This also limits your options for debugging to logs and error messages instead of being able to use the developer tools in your browser.

This limitation also means that two developers cannot work on separate Cloud Code functions for an application at the same time. When you deploy your Cloud Code it replaces everything that was previously deployed with the files you’ve just uploaded. So if you deploy changes to test them out, any uncommitted changes your coworker was testing get replaced (even if they’re for a different function). When we asked about this at Parse’s last Bay Area meetup, the recommended solution was to have separate applications for each developer to test their Cloud Code in (please see No Multi-Environment Support above).

The last major gotcha for using Cloud Code is that it’s very difficult to unit test. We were able to write tests for a simple function by stubbing out all of the Parse Cloud Code functionality, but as soon as we started using Cloud Modules it became increasingly difficult to stub everything. Seeing as our two main use cases for Cloud Code were emailing users and security, this was a major concern for us, and is one of the biggest deterrents for using Parse in future projects that would require Cloud Code.

Nonstandard REST API

This might be less of an issue for most people depending on what frameworks you’re working with and how flexible you need your application to be. Parse provides several SDKs that do a good job of abstracting away the complications of their REST API. But for our application, we chose to forgo the JavaScript SDK and use Parse’s REST API instead. We did this because we intended to use Sencha Touch to build a mobile friendly web application. Sencha Touch’s MVC structure already has built in support for communicating with standard REST backends. So, in theory, Parse should have been simple to integrate. Also, by developing against a REST API, we gain the flexibility of being able to easily switch out Parse in the future for any other backend solution that has REST API support, without having to greatly modify the application’s codebase.

Unfortunately, as we started to implement more features and functionality, we kept encountering non-standard APIs that required custom handlers instead of relying on Sencha Touch’s default logic. For example, suppose you have a class that has a beers field that is an array of strings. To update this field, most REST APIs support PUT operations where you replace the contents of the field with a newly specified array. Parse instead, uses a PATCH operation approach that allows you to modify the existing array.

{
    beers: {
        __op:"Add",
        objects:[
            "Ensorcelled",
            "Egregious"
        ]
    }
}

While using PATCH isn’t incorrect, it means that if you have a model that you’ve modified, you can’t save it by performing a PUT operation on it’s contents, but instead must track the changes separately and construct a custom patch to send to Parse. This also becomes an issue if you use Parse’s includeKeys API parameter to hydrate pointers, as you cannot perform a PUT operation with hydrated data.

So to that end, we wrote a lot of extra code that is Parse-specific and will have to be stripped out and cleaned up if we ever want to switch backends.

Our Conclusions

There are several other issues we encountered while developing with Parse that either took extra development time to investigate and work around, or worse, required us to compromise on the quality and security of our application to make things work. All together, these issues are enough that we do not plan on using Parse for any future client projects for now because the known costs greatly outweigh the potential gains.

However, if you are trying to rapidly prototype an application for a demo or just for fun, and you have no need for security, ease of collaboration, or multiple environments, it is possible for Parse to make the process faster. In fact, we have a new internal project that we are using Parse as the backend for those exact reasons. We have only one developer working on it, and it is a prototype that we do not plan on making secure or reusing the code for a release product.

From the sound of things at Parse’s meetup, the company’s current user base is largely native mobile-game developers. However, from talking with James Yu, Parse’s co-founder and CPO, the company is working to expand their audience:

“At Parse, we want to make it easy to use our platform in both an individual and team environment. We’re working on features that will improve development in teams, especially around Cloud Code. In fact, many of the possible improvements listed here are on our short bucket list. Stay tuned!”   - James Yu, Parse Co-founder and CPO

So be sure to check their blog for feature updates before deciding whether BaaS and Parse are right for your next project.

The post Parse Gotchas appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.