You’ll first need an AWS account along with an SSH key pair. If you don’t already have those two steps done, go ahead and do that. The steps that follow suggest a particular AMI; however, you are free to select the instance type. Micro instance types are free to use; consequently, you can get up and running with ElasticSearch in less than a minute for free.

Now that you’ve got an AWS account and an SSH key pair, go ahead and create a new security group (or edit an existing one). It’s important that the following ports are open:

• 22 (required for SSH)
• 80 (ElasticSearch uses HTTP for standard API calls)
• 9200 (required for ElasticSearch)
• 9300 (required for ElasticSearch)

Next, fire up a Linux AMI. I, for example, prefer ami-c30360aa (this is Ubuntu Server version 13.04) and I configure the AMI to use the security group that I just covered.

Now, SSH to your newly instantiated AMI. Once on the AMI, you’ll need to install Java. Never fear though, I’ve got you covered. All you need to do is run a handy script via the Ubuntu-Equip project, that I use frequently just for this sorta thing:

1

wget --no-check-certificate https://github.com/aglover/ubuntu-equip/raw/master/equip_java.sh && bash equip_java.sh

You’ll need to accept the license from Oracle. Once that script completes, go ahead and type java -version and you should see Oracle’s JDK (i.e Java version “1.7.0_21”).

Next, download and install ElasticSearch via another nifty Ubuntu-Equip script:

1

wget --no-check-certificate https://github.com/aglover/ubuntu-equip/raw/master/equip_elasticsearch.sh && bash equip_elasticsearch.sh

This script doesn’t start ElasticSearch for you; thus, go ahead and change directories into the elasticsearch directory and fire it up like so:

1

~/elasticsearch$ bin/elasticsearch -f

Take a deep breath (but not too deep, as I need you to finish in less than 60 seconds) and find the Public DNS of the AMI you’ve been working on. Go ahead and copy it, then fire up a browser on your local machine and go to http://YOUR_AMI_DNS_NAME.com:9200/_plugin/inquisitor/ (be sure to note the port).

By the way, Inquisitor is a handy web application that lets you query your indexes. It was installed via the Ubuntu-Equip script – this tool is invaluable in figuring out how to properly query your indexes.

And that is it. In less than 60 seconds you’ve got ElasticSearch running in the cloud for you. Want to create a cluster? No problem, just follow these steps again to fire up another ElasticSearch instance and then configure the cluster accordingly.

I’ve not gone over configuring ElasticSearch nor have I showed you how to create ElasticSearch as a service on a Linux instance, but for one minute, what do you expect?

Websites render this way on mobile devices because they lack a simple meta tag. While the subject of mobile website optimization can be rather involved (especially when dealing with CSS media queries, which take longer than 10 seconds to understand), there is a simple trick that can at least can make your website render normally on a mobile device. And it can be done in 10 seconds.

Simply add the following meta tag in the head element of your website’s index page:

1

<meta name="viewport" content="width=device-width, initial-scale=1">

The viewport meta tag is supported by browsers on both iOS, Android, and by other device browsers including Internet Explorer Mobile on Windows Phone 8. This tag instructs a browser on how to properly display a webpage; without it, a webpage is, unfortunately, displayed mini-style on device browsers, which have a narrow width.

Thus, the viewport tag essentially zooms in the display of a webpage. In the case of the example tag above, the width of the website is set to the device’s width and the scale is set to 100% – this’ll allow the website to be displayed normally on a mobile device. Website visitors won’t have to squint or pinch and expand to just to read the site’s relevant text.

Paulund.co.uk has a really good write up regarding the usage of the viewport meta tag as well as CSS media queries; what’s more, the good folks who created HTML5boilerplate.com have a nifty presentation that’s worth a read too.

Search is the touchstone of the Internet; without search the Internet wouldn’t be all that useful. Google’s meteoric rise and its resultant eponymous name for search is clear evidence as to the importance of search. Search, however, hasn’t always been that easy nor affordable to implement.

Before the likes of open source projects like Lucene, implementing search in an application involved an expensive commercial product or a series of SQL like statements that were never really good enough. Lucene, however, isn’t a simple hobbyist’s pursuit. Lucene requires a lot of expertise; what’s more, successful projects within the Lucene ecosystem, like Solr lack a key feature that is defining modern architectures: distributed.

The continued low cost of storage combined with cheap rent-able infrastructures like AWS has made it convenient to store a plethora of data, thus bringing to bear the importance that applications must support searching vast amounts of data, do it quickly, and affordably. This is where ElasticSearch shines.

ElasticSearch sits on top of Lucene and adds not only a simple API for adding and searching content, but does it in a distributed manner. With infinitesimal arm grease, you can set up a search cluster that smears your data and resultant queries across a series of nodes. Not only is this resultant architecture fast, but it’s easy to set up and extremely affordable as search nodes can run on commodity hardware. In essence, ElasticSearch brings search to the masses.

Google and its resultant ease of search has changed the mindset of application users. Searching content is a presumed feature and if you don’t provide it, you’re already a few steps behind your competition. ElasticSearch is clearly a path to constructing a viable, easy to install, affordable, distributed search infrastructure for any application. If you don’t believe me, take a look at some of the innovative companies with substantial amounts of users using it: Github, foursquare, and Stack Overflow are just a few.

What’s also exciting is that there are some major players behind these projects – Mozilla is, of course behind Firefox OS, Canonical is behind Ubuntu Touch, and quite a few large players are behind Tizen, including Samsung. Firefox OS even appears to be courting carriers with an opportunity to run their own app stores. This app store opportunity naturally has carriers foaming at the mouth to re-assert some semblance of control: behold the Verizon app store! All apps are $0.99 and we’ll just bill you at the end of the month (like we used to do for all those ringtones you were accustomed to download back when we were in control of all things device-related before Apple destroyed that cash cow).

Naturally, we’re all eager to see how these new entrants fair. It reminds me of how interested I was in learning more about Windows Phone 8 and even Blackberry’s latest and greatest attempt at regaining some composure.

But then I remember this stunning fact: Apple and Google

together control nearly 9 out of 10 smartphones sold globally.

Even with industry heavyweight contenders (who are not new to mobile!) like Microsoft and Blackberry (who, we all should remember, owned the smartphone market before Apple got involved) haven’t really made a dent. Granted, it’s early to rush to conclusions, however, preliminary signs don’t bode well for either company.

The co-CEO of Samsung had some stinging criticism for Microsoft:

Smartphones and tablets based on Microsoft’s Windows operating system aren’t selling very well. There is a preference in the market for Android. In Europe, we’re also seeing lackluster demand for Windows-based products.

Blackberry appears to have some demand in the UK and Canada, a recently analyst T. Michael Walkley had this to say:

While we anticipate stronger near-term results for BlackBerry as higher margin BB10 smartphones sell into the channel, we do not believe BlackBerry can achieve sell-through market share levels to return to sustained profit levels

The salient point, nevertheless, is that neither Microsoft or Blackberry have yet to make a dent into the Google-Apple duopoly. And so while it’s easy to get excited about new entrants like Ubuntu Touch, the reality, at least for the time being, is that these operating systems will have little impact in the smartphone market.

After all, when your competition essentially owns 9 out of every 10 smartphones, evolutionary enhancements aren’t enough to break that stranglehold: you have to do something revolutionary. Besides, we’ve already seen this before: the iPhone was not an evolutionary offshoot of the Blackberry. It was revolutionary. Sadly, neither Ubuntu Touch, Tizen, nor Firefox OS appear revolutionary.

It’s easy to configure a Rails app to take advantage of CloudFront; what’s more, if your Rails app is hosted on Heroku, there’s a nifty gem, dubbed heroku-deflater, that’ll enable HTTP compression of static assets (other than images).

To get these three entities to play nicely together requires a few simple steps. Let me show you how.

First, if you want to enable HTTP gzip compression of static assets other than images from a Heroku app, then add the heroku-deflater gem to your Gemfile. This gem doesn’t compress images as in some cases, zipping images creates bigger ones!

Once you’ve run bundle install and deployed your app to Heroku, fire up a terminal and run [cURL](http://thediscoblog.com/blog/2013/04/18/curling-for-wget/) to verify that the HTTP response Content-Encoding is gzip like so:

1

curl -i -H "Accept-Encoding: gzip,deflate" http://your.awesome.web.app

You should see in the response this key phrase:

1

Content-Encoding: gzip

If you do see the Content-Encoding set to gzip, then you are good to go. If, for some reason, you don’t see it, check your environment’s configuration file (which you will have to edit to get CloudFront working anyway) and verify that the property config.serve_static_assets is set to true.

Next, sign into the AWS Management Console and enable CloudFront if you haven’t already. From the CloudFront admin page, create a new distribution via the Create Distribution button on the top left.

Once the create distribution wizard begins, be sure to select Download as your delivery method.

In the next screen, there are some important fields you’ll need to fill out, namely: the Origin Source Name and the Viewer Protocol Policy. For the Origin Source Name, you will need to put in your app’s URL or the Heroku URL (if you do not map a custom domain name to it). If you web site supports HTTPS, then be sure to set the Viewer Protocol Policy to HTTP and HTTPS.

The only other important setting after these two is the Price Class. It’s here where you can set where CloudFront will essentially serve up your content – the default setting of Use All Edge Locations is most likely what you need.

Finally, click the Create Distribution button – once you do that, it’ll take a bit for things to initialize (basically, the CDN needs to get built and this may take up to 30 minutes).

Now to configure your Rails app, you’ll need to open up your target environment’s configuration file (i.e. production.rb). The two fields you’ll want to be sure are properly set are serve_static_assets and static_cache_control. In particular, you are setting the cache control variable to one year. This means that once a static asset, like a JavaScript file is downloaded to the browser, it’ll be cached for one year. Don’t fret, however, if you think that’ll inhibit change – the file that is ultimately downloaded has a hash attached to it (via the magic of Rail’s Asset Pipeline). Consequently, the file that is cached is something like your_js_file-asdf098203820980a980 where that last bit is a hash value that’ll change if the file itself changes.

1
2

config.serve_static_assets = true
config.static_cache_control = 'public, max-age=31536000'

The last change you need to make to your environment file is to set the asset_host to the CloudFront domain that you just created. You can find this in your AWS Management Console – it’ll be a cryptic URL like http://asdjlkj2321.cloudfront.net.

1

config.action_controller.asset_host = 'the domain name from AWS Dashboard'

Commit your changes and deploy your app.

To verify things are kosher, you’ll need to give it some time (check the status of your CloudFront CDN – if it’s status is Enabled then you are good to go!). If things are ready, then fire up a browser and go to your app.

In this case, I’m using Chrome. Go to JavaScript console and hit the Network tab.

Surf around and you’ll note a few things – one, that the assets like images and JavaScript files are being severed up from your CDN (just look at the URL) and that the size will often say “(from cache)” – that means the CDN is handling the load rather than Heroku. You should also note that your web app is probably a bit more snappy!

Check out your Heroku logs and you’ll note fewer hits in this case – dynamic pages are still being loaded, however, static assets are not anymore – that’s the job of your CDN!

CloudFront isn’t free; nevertheless, I think you’ll find the corresponding cost quite reasonable. Pricing will vary depending on how much content you’ll be serving up with CloudFront – this is a function of how many visitors you have along with how many static assets that are ultimately downloaded to a user’s browser. For instance, 500GB of average content will cost you less than $75/month.

CloudFront’s pay-as-you-go model makes it extremely affordable to add a nice bit of pep to your app’s performance along with using gzip compression and HTTP caching. And hopefully as I’ve shown you, it’s rather easy to do with a Rails app running on Heroku.

As the article summary states:

Mobile users are typically distracted, busy, and ergonomically constrained, so build your mobile application UIs accordingly. Andrew Glover discusses key factors that differentiate mobile apps from web apps, then guides you through the creation of a mobile application UI that uses swipe gestures for navigation rather than button clicks.

So what are you waiting for? Check out ”Mobile for the masses: Take a swipe at it! Programming gestures in Android” and trade buttons for swipes in your Android mobile apps! And if you missed the first article, check out ”Mobile for the masses: A gentle introduction to Android” and learn the ins and outs of Android development!

Stay tuned for more articles in this series and don’t forget to watch for mobile focused articles on this blog as well.

1

wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p180.tar.gz

and you’re one step closer. There’s no flags to remember either.

Wget, however, isn’t natively available on OSX. From time to time, I’m stung to see the nefarious ‘command not found’ message after expectantly waiting to see some file I need downloaded.

Luckily, you can force cURL to act like Wget with a few flags. Simply use the -OL flags like so:

1

curl -OL http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p180.tar.gz

and you’ll be on your way to downloading some file.

Of course, it’s possible to get wget on your Mac via MacPorts or Homebrew; nevertheless, knowing you can achieve the same goals with cURL is always handy.

My favorite: getEventListeners. Understanding how the DOM is augmented with listeners is amazingly helpful!

All you have to do is fire up the JavaScript Console in Chrome and in the actual console window, you have a host a commands you can execute now just like you have in any other terminal app. Very helpful!

Web apps are truly ubiquitous because they take advantage of the browser and are thus, cross platform. You, for the most part, can get away with maintaining one code base that can be viewed on iOS, Android, and the other minor players. Yet, the key point of Web apps is that they are web sites, not mobile apps.

As you begin to blur that mobile app/mobile website line, you’ll stumble over various issues like performance or varying behaviors depending on the underlying device. Worse, you’ll find that not all browsers are created equally and thus, you’ll need to compensate for various scenarios or use assorted compensating tools like Modernizr. Or, you’ll find yourself throwing the web app into a container because you want mass distribution via an app store or because you want to take advantage of some native feature.

And at that point, in the eyes of many, you’ve built a hybrid mobile app. But that’s not the whole story.

Hybrid frameworks aren’t all created equal. There are, in fact, two flavors of hybrid-ness: hybrid-web and hybrid-native. Both are extremely different; in fact, to showcase the difference, I need only compare the “featured” apps of two hybrid frameworks: PhoneGap and Marmalade.

PhoneGap is a great framework for building hybrid-web apps. You code in HTML and JavaScript and the resultant code is run inside of a web view managed by a native container. You ostensibly write one code base and deploy to all the primary mobile platforms. Similar frameworks are: IBM’s Worklight and Icenium. Sencha Touch falls into this realm as well when you employ their container technology.

Marmalade is a hybrid-native app platform; that is, you can code in an intermediary language like C++ that is ultimately compiled down into native code (i.e. Java for Android, Objective-C for iOS, etc). These apps are not characterized by a web view in any way. They are native, close to the bone as it gets apps. The benefit is that you only had to write one code base, the underlying tool took care of the dirty work in making it work similarly on iOS and Android, for example. Similar frameworks are: Corona, MoSync, and Appcelerator to name a few.

Now look closely at the featured apps of each hybrid framework. They’re distinctly different aren’t they?

PhoneGap and the rest of the hybrid-web frameworks are good at producing informational apps. These apps can look beautiful and certainly can have some compelling features like tight integration with social networks and geo-tracking, for example. But they’re inadequate for games and still lack a rich user experience when compared to more native apps like Flipboard or AngryBirds.

Marmalade and the rest of the hybrid-native crowd shine when it comes to highly interactive apps like games; what’s more, these frameworks can build an app that generates a wow. And therein lies the crucial aspect that’s missed when the industry blindly assumes all hybrid options are similar. They couldn’t be more incorrect – thus, we need at least four categories (native, web, hybrid-native, and hybrid-web) and we need to eschew the lone term “hybrid” as it lacks clarification and therefore has no meaning.

Gesticulate makes it painless to detect straightforward swiping motions like up, down, left, and right. It’s a simple jar file you include in your Android libs directory. Throw Gesticulate’s SwipeDetector inside an instance of Android’s SimpleOnGestureListener, for example, and you’re detecting swipes with ease!

Gesticulate is used in Savvy Words, a flash card vocabulary app found on Google Play and Amazon’s Appstore for Android. See the Github project for more details such as code examples for how to use Gesticulate, how to build it, and to see Gesticulate’s tests. Swipe on, baby!

What’s interesting (and not too surprising) about this analysis is that frameworks like PhoneGap or jQuery Mobile (and laughably JQTouch?) are leaning more towards adoption ready when compared to frameworks like Marmelade, Coronona or MoSync. But this radar lacks some clarifying dimensions – for example, if you want to produce a mobile website on a lot of different mobile platforms quickly, then PhoneGap is probably the way to go. But if you’re looking to create a mobile app, then the choice to use PhoneGap must be treated with extreme caution.

You cannot create a compelling user experience that works across all platforms consistently with this framework right now. And it isn’t even the fault of PhoneGap entirely – it’s HTML5. That’s why going with something like JQTouch without viewing the big picture of what you are building is laughable.

Frameworks like Marmelade or Corona might be a bit more difficult to get started with (after all, you code in something other than HTML or JavaScript) but they can produce a native app that offers a compelling user experience capable of generating a wow. Remember, native-ness trumps the browser almost always unless your app is a series of screens that don’t require the user to interact.

Accordingly, the study lacks some needed dimensions – mainly, whether or not you are building a mobile app or mobile website. Don’t fall into the hype trap and jump into PhoneGap development unless you are sure what you are building is a simple mobile website and your audience isn’t expecting something like Flipboard or AngryBirds. Otherwise, you’ll find yourself investigating either pure play native development or frameworks that ultimately produce a native app.

As it turns out, MongoDB supports batch inserts! And just like in SQL land, Mongo’s batching feature is much faster at inserting a lot of data in one insert rather than x inserts.

For example, the Mongo Ruby driver’s insert method takes a collection; thus, you can insert an array of hashes quite efficiently. Even if you are using a ODM like Mongoid, you can still perform batch inserts as all you need to do is get a reference to the model object’s underlying collection and then issue an insert with an array of hashes matching the collection’s intended document structure.

For instance, to insert a collection of Tag models (each having 3 fields: name, system_tag, and account_id) in one fell swoop I can do the following:

1
2

tags = ['a', 'bunch', 'of', 'tags'].collect { |tag| {name: tag, system_tag: true, account_id: id} }
Tag.collection.insert tags

In the code above, the insert takes a collection of hashes; what’s more, the insert is tied to the tags collection via the Tag.collection call.

Batch inserts are always faster if you have a lot of similar documents – in our case, we saw a tremendous performance increase when employing batching.

The panelists are a diverse set, which made the interaction a lot of fun as each had unique perspectives. Check out what my friends Ryan McGeary, Steve Jernigan, Michael Shapard, Andrew Trice, and Chris Kamsler have to say!

Since then, Node’s installation has been come tremendously easy and NPM is even bundled with Node. And yet, installing Node (and keeping up w/its rapid release schedule) is even easier with a nifty tool: Node Version Manager.

With Node Version Manager (or nvm) you can be up and running with Node in 3 easy commands.

Step 1: Download and install nvm.

1

curl https://raw.github.com/creationix/nvm/master/install.sh | sh

Step 2: Reload your shell.

1

source .bash_profile

Step 2.5: Obtain a list of available node versions to install.

1

nvm ls-remote

Step 3: Install your desired version of node.

1

nvm install v0.10.0

After that’s done, execute a node -v to verify. Now wasn’t that easy? You bet!

As the article summary states:

The mobile landscape is rich with promise, and Android is a viable and exciting platform for developers who seek a way in. This new series starts with an introduction to Android that is tailored specifically for Java developers just getting started with mobile. Learn about Android’s three-layer versioning system (and find out why it matters), then set up your development environment and build your first Android app.

So what are you waiting for? Check out ”Mobile for the masses: A gentle introduction to Android” and learn the ins and outs of Android development! Stay tuned for more articles to come and don’t forget to watch for mobile focused articles on this blog as well.

How do you wow someone? You make your app easy to use and aesthetically pleasing to the eye. And it has to work correctly consistently. Unresponsiveness, however minor, won’t do.

Can you wow someone with an HTML5 mobile app? Sometimes. But let me tell you: it’s not easy. Don’t think for a second that just because there are a gazillion developers who have an understanding of HTML and JavaScript, that anyone can build an app to inspire a wow. No, it’s a tricky business with HTML5 these days.

Yep, there are fewer developers out there that actually can code Objective-C or truly understand Android. They might be costly too. But the wow comes from native apps these days and it looks to be that way for some time. Native apps are close to the bone – they don’t have to rely on browser standards or shivs to work correctly 83% of the time. Coded correctly, they work all the time. They are responsive, fast, and can work offline without a lot of magic.

HTML5 is great for mobile web sites. Not mobile apps. Until HTML5 can produce a significant wow factor, your best bet is to go native. It’s that simple.

Among open source, document-oriented databases, MongoDB is often billed as a NoSQL database with RDBMS features. One example of this is MongoDB’s support for dynamic queries that don’t require predefined MapReduce functions. MongoDB also comes with an interactive shell that makes accessing its datastore refreshingly easy, and its out-of-the-box support for sharding and clustering (via replica sets) enables high scalability across multiple nodes.

Check out this IBM developerWorks’ Knowledge Path dubbed ”Discover MongoDB” – watch four videos, read a few articles, listen to a podcast and learn everything you need to know about MongoDB!

Accordingly, to test a migration, you need to set up your test with how things were and then run your migration and verify things have migrated. As it turns out, this is super easy to do with a document oriented database like MongoDB. For this particular project, we’re using Mongoid, which is an Object-Document-Mapper (or ODM) for MongoDB and we’re also using a nifty gem dubbed mongoid_rails_migrations, which facilitates writing Mongoid migrations.

In order to reflect the state of the underlying datastore before running a migration, I needed to remove a particular collection, which due to changes in our models, is automatically populated with meta data when various events occur (think relational trigger here, for example). As you can probably see, as this new collection doesn’t exist in production, all the existing data in production needs some corresponding default meta data to reflect the new requirements which brought this collection to life.

Accordingly, once I initialize my models and the corresponding collection is populated, I need to completely drop the collection. Then, I can run my migration and then verify that the previously nuked collection is present with all the required data.

In my case, I’m using shoulda in concert with Test::Unit, but the details of a test framework really don’t matter – in any case, you’ll need to load your migration, which can be done via a require statement like so:

1

require File.join(Rails.root, 'db', 'migrate', '20130217194234_member_app_roles_permissions')

In my fixture logic, I’ve initialized a few objects and related them, which automatically creates the aforementioned meta data collection; consequently, I need to do two things. First, get a connection to the underlying test datastore and then drop that collection.

1
2

db = @account.db
db['member_app_roles'].drop

Now I’m ready to run my migration – it’s as simple as invoking the class method up!

1

MemberAppRolesPermissions.up

Once the migration has finished running, I can then verify that everything is cool and copasetic. In this case, I need to go directly to the datastore because those objects in memory won’t reflect my changes just yet.

1
2
3
4
5
6
7
8

member = Member.find(member.id)

assert_equal 2, member.member_app_roles.size
member.member_app_roles.each do |app_role|
  assert_equal 'admin', app_role.role
  assert_equal member, app_role.member
  assert_not_nil app_role.app
end

As a benefit of thinking through how to test a migration, you end up unveiling how you’d construct the migration’s down method. That is, in my case, to roll back, all I need to do is blow away the member_app_roles collection!

As you can see, testing migrations isn’t terribly difficult (probably a good reason why I haven’t found too much information about it); the key aspect is the logic that is applied to verify your migration actually worked. It should be noted that while I executed this test in the context of a document oriented database, you could certainly do the same in a relational database. For example, by dropping columns, tables, etc before running a migration. Either way, testing a migration is a snap. Can you dig it?

New tool converts your Apple #iOS apps to #HTML5 http://dld.bz/cejxz #appdev

The article about this new tool, dubbed the ”Intel HTML5 App Porter Tool” suggests that because iOS apps are limited to one platform, HTML5:

represents an opportunity because it’s supported across a wide range of different devices and operating systems, so it enables the same code base to be reused across different app deployments.

While technically this statement is true – HTML5 is ubiquitous and you do end up with a single code base – HTML5 is the lowest common app development denominator and thus produces an underwhelming experience when compared to its native brethren.

Taking a native iOS (or Android) app and recasting it into an HTML5 app is like taking your beautiful Ferrari and trading it for a station wagon. The experience will never be quite the same.

Don’t get caught up in the HTML5 hype-cycle. It’s a great platform for mobile web sites, but if you’re building a mobile app, the UX bar has been set quite high. You cannot yet meet that bar with HTML5.