Always Get Better

Archive for the ‘Web Programming’ Category

HP Releases Enyo 2.0

Wednesday, January 25th, 2012

Now that WebOS is being made open source, HP has released a new version of the Enyo JavaScript framework. Whereas the first version of the framework only supported Webkit-based environments (like the HP Touchpad, or Safari or Chrome), the newer version has expanded support for Firefox and IE9 as well. Developers who created apps with the old framework will have to wait a little while longer before all of the widgets and controls from Enyo 1.0 are ported over.

What does this mean for app developers? Now that Enyo is open-source, it means applications built on the platform will run on Android and iOS. But it’s not a disruptive technology – both Android and iOS have supported HTML5 applications for quite awhile; HP will be competing against mature frameworks like jQuery Mobile.

As a WebOS enthusiast I am definitely going to put some time into continuing my explorations of Enyo, but it’s getting harder and harder to justify the investment. My Pre is getting pretty old at this point, and hardware manufacturers have yet to express interest in making new devices to take advantage of WebOS. If I end up switching to Android with my next hardware purchase, it’s going to shift my priorities away from Enyo and its brethren.

Humans.txt – the Anti-Robots.txt

Saturday, January 14th, 2012
Mimbo - A Friendly Robot
Creative Commons License photo credit: langfordw

If you don’t want a search engine to read some or all of the files on your site, you can create a robots.txt file. (Looking through the blog archive, I realize I’ve never gone through the construction and contents of that important file, so this is a promise to one day return and fix that!)

When you want the opposite – accessible pages and author credit, create a humans.txt file. Although not an “official” standard, it is a fun way to acknowledge the (sometimes many) hardworking individuals behind the creation of a web site.

An example is:

/* TEAM */
Leader: Mike Wilson
Site: http://www.alwaysgetbetter.com
Twitter: HawkWilson
Location: Ottawa, ON

/* THANKS */
Seth Godin: http://www.sethgodin.com
Steve Pavlina: http://www.stevepavlina.com
Phil Haack: http://haacked.com

/* SITE */
Last Update: Jan 14, 2012
Standards: HTML5, CSS3
Software: WordPress

In most cases, you would want to include at least a TEAM and SITE section. Clearly the exact fields are left to your imagination, but it’s a very simple way to acknowledge the people who helps (directly or in spirit) a site to get to fruition.

For more information about humans.txt, check out the initiative’s home page at http://humanstxt.org/.

Node.js 0.6 Released

Monday, November 7th, 2011

The Node.js team has released version 0.6. Although much of the core was re-written, the most noteworthy change has to be the support for native Windows installation. Whereas previously it was possible to run node.js on Windows using Cygwin, the native compilation means its performance will be comparable to Linux equivalents.

Other important improvements include upgrading of the V8 engine and multi-process load balancing. Much more information can be found on the node blog.

Multiple Development Environments

Friday, November 4th, 2011

Hopefully when you do web work, you’re not developing code on the same server your users are accessing. Most organizations have at least some kind of separation for their development and production code, but it’s possible to go far further. Separating environments allows you to achieve multiple threads of continuous integration for all kinds of cool.

These normally break down as follows:

Development
Working code copy. Changes made by developers are deployed here so integration and features can be tested. This environment is rapidly updated and contains the most recent version of the application.

Quality Assurance (QA)
Not all companies will have this. Environment for quality assurance; this provides a less frequently changed version of the application which testers can perform checks against. This allows reporting on a common revision so developers know whether particular issues found by testers has already been corrected in the development code.

Staging/Release Candidate
This is the release candidate, and this environment is normally a mirror of the production environment. The staging area contains the “next” version of the application and is used for final stress testing and client/manager approvals before going live.

Production
This is the currently released version of the application, accessible to the client/end users. This version preferably does not change except for during scheduled releases. There may be differences in the production environment but generally it should be the same as the staging environment.

Having separation between the different environments is not tricky, but managing your data environment can be. There are, of course, all kinds of ways to solve the problem.

Accessing Configuration Parameters using Play Framework’s Template Engine

Monday, May 9th, 2011

Suppose we are building a Facebook application and have a variable called fb.appId containing our Application’s ID. We want to use that to initialize an FBJS call, but obviously don’t want to hard-code it into our page’s template.

Using the template engine in Play! framework, we can make direct calls to the underlying Java framework as long as we use the full namespace path. Our Facebook Application Id is accessible like this:


${play.Play.configuration.get("fb.appId")}

If we’re making a lot of configuration calls, we can simplify our lives by aliasing the namespace path:


%{
cf = play.Play.configuration
}%
${cf.get("fb.appId")}

Conditional Statements
Let’s go a step further. Suppose we have Google Analytics and only want the JavaScript to run when our site has been deployed to production (I covered a similar technique earlier this year using Ruby on Rails).


#{if play.Play.configuration.get("application.mode") == 'PROD'}
GOOGLE ANALYTICS CODE - WILL ONLY DISPLAY IN PRODUCTION
#{/if}

Tracking Down Website Speed Problems

Tuesday, April 19th, 2011
Tortoise
Creative Commons License photo credit: Eric Kilby

Why is my website loading so slowly?!?

There are a few common culprits behind website speed issues. When diagnosing problems, the best bet is to start at the worst performers and move up. Some suggestions, in order from slowest to fastest, are:

1. Internet Traffic
If your web page is downloading anything over the internet during each page request, stop right now. This is the most expensive operation you can perform. Example: Downloading a photo from Flickr and loading it into memory in order to determine its width and height dimensions.

2. Network Traffic
Local network traffic is generally very fast, but still involves transmitting information outside your computer. In some cases, such as web clusters with a shared session cache, the network performance cost is worth it for the overall application.

3. Database
Databases are fast, particularly when the data you need is already stored in a memory cache – which you generally can’t control. When paired with a key-value memory store like memcache, the majority of your database calls can come straight from memory.

4. Disk I/O
Even with the incredible access times found in today’s hard drives, reading and writing from the disk is an expensive operation (and why databases lose points, except for their memory caching abilities). Sometimes reading from disk is the better choice – YMMV.

5. Script Caching
Implement a tool like xcache (PHP). This will keep your code in binary bytecode format which is much faster to execute since it doesn’t have to be re-processed by the web server.

How Play Framework Saves the World

Monday, April 11th, 2011

Play framework must be the best-kept secret in the Java world. If you haven’t had a chance to see their totally awesome demonstration video where they build a full app before your eyes in a matter of minutes, go – go now. Then come back.

Why do I like this framework so much? Put simply, it is an elegant solution for nearly every problem I’ve ever run into in developing websites, both single-server and multi-server applications. Don’t take my word for it, see for yourself.

The Goodness of Java
To my mind, Java has the edge over more common scripting languages (like PHP) because it is compiled (fast) and statically typed (reliable). In the past, using compiled languages on the web was only possible if you were using ASP.NET or willing to put up with the hassles of existing Java frameworks and servers.

Play’s first innovation comes from wrapping the Java runtime inside a Python web server; using a Play application is as easy as running a command line script and connecting with your web browser. Play’s second innovation is its just-in-time compilation and display of error messages; if you make a mistake you will know in the amount of time it takes to hit refresh on your web browser.

Since it IS java, programmers can use libraries they have built for other applications or sourced from other vendors and plug directly into their code. This is one of the advantages Microsoft has had going for it and it is good to see it implemented so nicely in the open source world.

The Ease of Rails
Love it or hate it, Ruby on Rails has had an affect on the entire web world and its reach is definitely felt in the Play framework. Everything from the routing to JPA integration has that minimal-configuration design that is so prevalent in the Ruby world. Play has the edge though, due to Java annotations and the extra control you get as a developer.

Baked-in Unit Testing
Admittedly this is the first thing that drew me to the Play framework. Unit testing has to be one of the most important aspects of good programming; in fact, if your code is not covered by unit tests, I argue it is incomplete. Play has terrific support for unit testing, functional testing and selenium-based web testing. In version 1.1, Play added a headless web testing mode, paving the way to run framework applications in the context of an automated build environment – smart move!

Although awkward at first, using YAML files for database fixtures makes a lot of sense. Managing database access in unit tests has always been a challenge but thanks to the in-memory database server and fixture files Play offers us database integration testing – giving us the fresh-start benefits of mock frameworks along with the soundness of mind that comes from knowing you are testing the real database.

Share Nothing Architecture
Call it laziness, call it human error. At some point in the development cycle, the session always seems to end up carrying user data around. Even with data-sharing applications like memcached, that style of development does not scale well. With Play, sessions are stored in user cookies and consist of an encrypted key. The idea is the application takes care of loading any additional information it needs from this seed information, so the web cluster can be expanded to hundreds of nodes or reduced to a single server with no performance penalties on the other servers. Each Play instance operates as if it is the only one in existence, making it far easier to support complex site architectures.