Simon Whatley » JavaScript

3 Free eBooks on jQuery

Simon — Tue, 19 Jul 2011 21:33:15 +0000

jQuery, a JavaScript library, is definitely something worth knowing. Here are some resources to help you learn and master it.

jQuery Fundamentals by Rebecca Murphey, with contributions from James Padolsey, Paul Irish and others, is a free e-book available in HTML. It includes an overview of JavaScript as its first chapter, to help developers get up to speed.
Essential JavaScript & jQuery Design Patterns by Addy Osmani is a free e-book of design patterns for those who already know jQuery but want to take their skills to the next level.
Official jQuery Documentation

Run Two Versions of Firefox on Mac OSX

Simon — Wed, 30 Mar 2011 09:03:52 +0000

Last week Firefox 4.0 was released to the world. Web developers everywhere celebrated with delight, the new browser. Well, almost! The browser comes packed with a super-fast JavaScript engine called JägerMonkey, improved support for HTML5 and CSS3 and a bunch of new interface updates. But don’t get too excited just yet! It’s still a good idea to keep that old version of Firefox around for testing; we can’t assume everyone has upgraded to Firefox 4. So, to run both Firefox 3.6 and Firefox 4.0 on the same machine, just follow these simple steps:

Open up your Applications folder and find your old version of Firefox.
Right click -> Get Info.
Rename to “Firefox36.app”.
Download Firefox 4.0 and install as normal.

Voilà! You now have more than one Firefox browser to play with.

That was really simple huh? If someone knows how to do this on the Windows and Linux side, I would love to hear how.

Using Google-Hosted JavaScript Libraries with WordPress

Simon — Tue, 13 Apr 2010 15:00:19 +0000

With the announcement that Google will be including page loading times as part of it’s SERPs ranking algorithm, it has become increasingly important to optimise your use of 3rd-party libraries such as jQuery.

If you want — and this is the default setting for WordPress, themes and plugins — you can just download jQuery, put it on your server and link to it from your header.php file in the section.

However, it is better to use the proper wp_register_script() function, which can be achieved in your functions.php file:

if( !is_admin() ) {
   wp_deregister_script('jquery'); 
   wp_register_script(
   	'jquery',
   	("http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"),
   	false,
   	'1.4.2'
   ); 
   wp_enqueue_script('jquery');
}

The reason we use the wp_register_script() is to ensure that WordPress and its themes and plugins are aware that the script has been loaded and therefore not to load an additional copy.

I have also used the is_admin() function to prevent conflict and therefore errors, in the WordPress administrator.

Of course, this method is not only restricted to jQuery, you can do the same for other popular JavaScript frameworks such as Mootools.

Further information on the wp_enqueue_script can be found on the WordPress Codex.

Google Announces Plans to Offer a Google Analytics Opt-Out

Simon — Fri, 19 Mar 2010 11:06:49 +0000

Yesterday Google announced that it had been developing opt-out functionality for its Analytics product, seemingly in response to growing unease with United States and European regulators.

As an enterprise-class web analytics solution, Google Analytics not only provides site owners with information on their website traffic and marketing effectiveness, it also does so with high regard for protecting user data privacy. Over the past year, we have been exploring ways to offer users more choice on how their data is collected by Google Analytics. We concluded that the best approach would be to develop a global browser based plug-in to allow users to opt out of being tracked by Google Analytics. Our engineers are now hard at work finalizing and testing this opt-out functionality. We look forward to make it globally available to our users in the coming weeks.

This was an unexpected move, but possibly a very smart one by Google, which aspires to turn its Analytics product into an “enterprise-class web analytics solution.” Many analysts will see the creation of a browser plugin to opt-out of Analytics counterintuitive. Rationalising web analytics is already hard enough, but if you now need to factor in a proportion of people who may have opted-out, it will create a minefield of doubt. Furthermore, if people are able to opt-out of Google Analytics, will enterprises want to use it as an analytics solution?

It is safe to assume that Google do not want to kill one of their key products, which sits neatly between their search and advertising businesses. Indeed Google aren’t the first to create and opt-out, with Omniture and Webtrends having already created a cookie-based solution.

So why shouldn’t you be too worried about Google’s plugin?

Opt-out does not signal a death knell for data gathering. Although some people will undoubtedly be concerned about tracking and therefore download the plugin, the vast majority of users will not. Furthermore, it is the trends in analytics that are important rather than absolute numbers. Analysts will simply need to study, manage and quantify the resulting bias. Such issues are analagous with a user deleting cookies or disabling JavaScript in their browser.
Good privacy management reinforces trust in a brand that has been under attack over the amount of data it collects on its users. This in turn will drive long-term acceptance of Google products and enhance its earning potential. As mentioned at the beginning of this article, this move shows good faith to regulators and sets the stage for Google Analytics to operate safely within the containts of more stringent privacy regulations in the United States and more importantly Europe. If Google Analytics is allowed to operate freely on this basis, it may boost usage and advertising revenues, which in turn will maintain it as an important product for Google.
Opt-in customers are better customers because they provide an accurate picture of how they use your website and therefore are key in helping you improve the user experience. Focusing your efforts on those who are willing to be measured may enhance the achievement of site goals.

How should you prepare for the launch of the plugin?

Benchmark your data (traffic, visitors etc) before and after the release of the opt-out plugin. That way, you will be able to determine the potential bias between the figures and adjust the reports accordingly.
Understand how to accommodate the opt-out bias in your reports and determine which reports may need recalibration.
Understand how the change in your Google Analytics metrics may compare to or impact upon 3rd party metrics, for example those used to calculate advertising revenue.
Determine whether announcing the possibility of your users opting out will enhance the trust of your website, with the view to potentially alerting to your users that they have such an opportunity.

This move by Google is likely to set the trend amongst Analytics providers since online privacy is a major issue. Most modern browsers include an “incognito” setting, which allows for private browsing, therefore it stands to reason that the analytics providers will follow Google’s lead, even if it is only a cynical attempt to reassure users and maintain market share.

Thinking Mobile? If You Build It, They Will Come

Simon — Thu, 04 Feb 2010 14:35:59 +0000

Smartphone applications are predicted to overtake the desktop software market. So who will win the multi-billion-pound [dollar] application economy, and what are the new rules?

In January 2010, Apple announced to great fanfare that they had recently sold their 3 billionth iPhone application. Of course not all these applications are paid-for, but with a 30% levy taken on each and every paid-for application, Apple are taking a significant share of the revenue from the application pie. However, as a distribution channel, the AppStore is second to none, whilst the iPhone uptake is staggering, with a majority share of the smartphone market in many regions of the world. There is a significant opportunity for any developer to make a huge return on investment, assuming the idea is a winning one.

iPhone, Android, Windows Mobile, Blackberry, Nokia and now the larger form factor iPad and Kindle support the idea of applications, or will do in the near future. So what do you need to do to design and build your first application?

Familiarise yourself with the rules
Whether you’re going to build applications for the iPhone OS, Android OS or any other of the mobile platforms, you will need to familiarise yourself with how each operating system does things. Smartphone development is different from the development we are accustomed with on the Web. Reading the user interface guidelines for each platform will go a long way to developing your first application. Smartphones are personal devices and know where you are almost all the time through GPS. They have rotation detectors, compasses and multitouch screens with gestural interfaces. Only once you know what is possible with each smartphone platform can you begin to design your application.
Brainstorm the issues
This is the creative part of your application development process. You have a basic idea, but you need to take it forward into something that has features and benefits. Will the application be paid-for or free? Will it provide a service or be a marketing channel? Will it be standalone or link closely with other online presences and networks? Smartphone applications, unlike ordinary websites, invariably need to actually do something. There is an element of artificial intelligence at play, whereby the phone can actually know where it is in the world and it’s orientation, whilst the user interface is remarkably different from that of simply a mouse and keyboard. Smartphone applications can’t simply be flat catalogues, they need to do something and do it well. Whether this is booking and accessing a car as with StreetCar, buying something from eBay, paying with PayPal, creating music with RjDj, drawing pictures with Brushes, price comparison with RedLaser, reading the latest news from the Guardian, video casting with Qik or planning your journey with Tube Deluxe your app needs to be compelling.
Create a prototype
You have your compelling idea; create a proof-of-concept prototype. This prototype is used to test some or many aspects of the intended design without attempting to exactly simulate the visual appearance, content or intended interactions. Such prototypes can be used to “prove” out a potential design approach such as range of motion, mechanics, sensors, architecture, etc. Making paper prototypes, for example, is a great way to test the application rather than creating low or high fidelity wireframes and hoping for the best. Doing this also provides a perfect opportunity for people around you — friends, colleagues and family members — to try out the prototype with little fuss. Only once you’re happy with the design should you begin any form of coding.
Submit early
You have your application working. You have conducted a number of usability tests and all is looking great. It’s time to submit it to the appropriate application store. Apple has its AppStore, Android its Market Place, Nokia its Ovi Store and so on. Each store has its own nuiances, but if you’re considering an iPhone application, Apple has been know to drag its feet when approving applications for release. Apple has a much discussed approval process, with the possibility of rejection commonplace. Don’t make plans that depend on Apple. It is better to silently release the application, rather than creating a huge fanfare.
Iterate often
Once your application has been launched your work is nowhere near over, indeed it has just begun! As you gain more and more users, improvements will suggest themselves not only from within your team, but more often, from your users. Here is where you go back to stage two and start brainstorming again. Version 2 may include bug fixes, but also major feature updates. For the latter, your brainstorming will decide what is most important for the next iteration. When your next iteration is complete, the AppStore, for example, makes upgrades far easier to achieve than for normal desktop software.

If you’re planning an application that could disrupt one of the smartphones capabilities, such as Google Voice for the iPhone, it may be worth considering whether building an application specifically for that particular operating system is worthwhile. Google Voice was neither approved nor rejected by Apple for the iPhone, but has now been replaced by a fully featured HTML5 web-based application; circumventing the Apple approval process. Of course this now means that the same web-based application can be used for not just the iPhone, but other smartphones.

Now go forth and build it!

Resources

Smartphone User Interface Guidelines:

Application Development Frameworks:

PhoneGap an open source development tool for building iPhone, Android, Blackberry and other mobile apps with JavaScript
Appcelerator a mobile development platform for javascript developers

Mobile Web Application Frameworks:

jQTouch a jQuery plugin for mobile development
iUI an iPhone/iPod Touch user interface framework

Other:

Wikipedia article on Mobile Development

How to Configure Apache to GZip Your Components

Simon — Wed, 03 Feb 2010 15:26:38 +0000

Compressing your Web components will help speed up your Website. The majority of your visitors will benefit as most all Web browsers support GZip compression. You’ll want to compress all text, which includes HTML, CSS, JavaScript, XML, JSON, etc.

Apache 2.x uses mod_deflate. Much like setting expires headers, this will save you bandwidth and server load, because it allows output from your server to be compressed before being sent to the client over the network.

The deflate module is not compiled by default and must be enabled in the Apache httpd.conf file. Make sure the following is present and uncommented (remove preceding the #):

LoadModule deflate_module modules/mod_deflate.so

To set GZip compression, simply add the following to the section of your Apache vhost configuration:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Alternatively you can add it to your htaccess file in an block.

All you really need is the first line. The BrowserMatch lines are there to handle issues with older browsers such as Internet Explorer 5.

You can read all about GZip by reading Yahoo!’s Best Practices for Speeding Up Your Web Site guide.

Alternatively, read the Apache mod_deflate documentation.

Apache Ant Best Practices

Simon — Mon, 10 Aug 2009 09:12:40 +0000

Before Ant, building and deploying web applications required a series of scripts or manual processes, which often led to mistakes.

Apache Ant is a software tool for automating software build processes. It is similar to Make but is implemented using the Java language, requires the Java platform, and is best suited to building Java projects. However, that doesn’t mean it is restricted to Java projects. I use Ant increasingly for all my web development projects as it is an integral part of Eclipse, my IDE of choice. It makes building applications and releasing them across different servers far more efficient and less problematic.

When I start a new project, after creating the folder structure, I create the Ant build file. Ant defines the build process and must be used by every developer working on the project. All of the tips in this article assume that the Ant build file is extremely important, must be written with care, and maintained in version control and re-factored periodically, when the project dependencies change.

Ant uses XML to describe the build process and its dependencies. By default the XML file is named build.xml. This makes it really simple for you setup and edit different build processes. However, since Ant is relatively simple to set up, you need to follow a common set of best practices. Some of these best practices were inspired by mistakes made on previous projects, or ideas passed on to me by other developers.

Automate absolutely everything

Ant is a powerful tool. If you choose to use it, get it to do absolutely everything. Ant can integrate with your source control databases such as Subversion (SVN), run SQL scripts, change file permissions, send files across FTP, zip and un-zip files, and many more tasks besides these.

If you use Ant, only use Ant

Use Ant as a common baseline. Regardless of what IDE you use to develop your applications, set up an Ant build file that all team members use. The build.xml file is the one true build script. Make a rule that everyone should perform a successful Ant build before code is checked into version control. This will ensure that code will always build from the same build file.

Follow consistent conventions

Ant expects your build file to be called build.xml and the build’s properties file build.properties. These files should also be in the root directory of your project. Other than an insane desire to change convention and confuse other team members, don’t change this convention. Another less-well-known convention is to prefix all internal commands with a hyphen (-). It has the advantage that it is not possible to invoke targets that follow this naming convention, from the command line.

Spend time formatting the build file. Since XML is quite verbose, use tabs and line breaks to make the file readable to the human eye. Ant itself doesn’t care if the file looks pretty, but you can bet that you and your team will.

Pick meaningful, human-readable names for targets and properties. For example dir.reports is better than simple rpt. The specific naming convention is not important, beyond being meaningful to your organisation. For example, I use the following:

deploy.local
deploy.dev
deploy.test
deploy.live
-build
-clean
-concatenate
-minify
-prepare

The -concatenate and -minify commands are specific to web projects, the later using the Yahoo compressor library to minify CSS and JavaScript files.

Provide a clean target

Every build file should include a target that removes all generated files and directories, bringing everything back to its original pristine state. All files remaining after the clean should be those found in version control.

An example clean command could be as follows:

 name="clean" description="Deletes all generated files and directories">
	 dir="${dir.build}" />
	 dir="${dir.dist}" />
>

Use build files for all stages of the development process (development, staging and production)

Ant standardises your build and release cycle. Therefore use it for all stages of the development process. Use it for releasing code to your local development server, your staging or user acceptance testing server and your production server. The different deployments can obviously differ slightly based upon the needs, i.e. your production build need not include the creation of dummy data, but may include a call to source control.

Make build files self-contained

A build file that relies on external dependencies is one that will be difficult to configure or has the potential to cause problems. If your build depends on additional tools, put them in your source control repository. I generally include a lib for all dependencies in my project root. This folder includes such files as the Yahoo Compressor or JSLint.

Prefer a single build file

It is possible to split the build up into several small build files, each of which is responsible for a small proportion of the overall build. This isn’t always the best idea! Breaking the build often makes it harder to comprehend the whole process. It is better not to over-engineer the project and keep to a single, well formatted build file.

If your project is split into different build files, there should always be a master build file, found in the root directory of the project, even if it only delegates actual work to subordinate builds.

Put the build.xml file in the project’s root directory

The Ant build file can reside anywhere in the project tree, but conceptually it makes sense to put the file in the project root. This keeps things clean, simple and somewhat obvious to new members to the project. Having a build file in the top-level directory also makes it conceptually easy to see how relative paths point to different directories in the project tree.

When the build.xml file is in the top-level directory, you can compile code from the command line without the need to change the working directory.

Modularise your project

Arrange your project into coherent self-contain modules.

The following shows how I typically arrange my project files.

[root directory]
	/docs
	/lib
	/src
build.properties
build.xml
task.properties

The docs folder contains project documentation, the lib folder contains libraries specific to the project and required by Ant (generally this is a link to repository containing a number of utility JAR files, such as those for SVN and FTP). Finally, the src folder contains the actual project files.

Use version control

It is important to use version control for your entire project. The build file is an important artefact that needs to be versioned along with the source code of the project. When you tag a build for release, the build file should also be included. If you then need to roll back to a previous release, you will be able to build the code based upon the build file used for that particular release (after all, build files develop along with changes to the source code).

Third-party JAR and executable files should also be maintained in your local version control. This makes it possible to recreate previous releases, after all third-party libraries are likely to develop and change as frequently as your own code. If you want or need to take advantage of these changes, it is necessary to version control the older versions.

Avoid including build output in version control. Provided that you use version control correctly, you will be able to recreate these files at a later date.

Include comments in the build file (self-documenting)

Make the build file self-documenting. Adding target descriptions is one way to achieve this. For example:

 name="clean" description="Deletes all generated files and directories">

Internal targets should not include description attributes. Internal targets may include targets that perform immediate processing, such as file concatenation or minifying.

Another way to include help in the build file is the echo tag. You can put any amount of comment between these tags and the information is printed to screen. For example:

 name="clean" description="Deletes all generated files and directories">
	>Cleaning project...>
	>Deleting build directory...>
	 dir="${dir.build}" />
	>Deleting dist directory...>
	 dir="${dir.dist}" />
>

Summary

By using Ant and creating and maintaining build scripts for a project, the reliance on ad-hoc manual procedures for compiling and creating websites is removed. Using a defined process with Ant, or similar build tool, removes errors across the entire project, whilst allowing teams to develop code more efficiently.

References

Holzner, Steve (2005). Ant: The Definitive Guide, 2nd Edition, O’Reilly, ISBN 978-0-596-00609-9.

Apache Ant – http://ant.apache.org

Parsing Twitter Usernames, Hashtags and URLs with ColdFusion

Simon — Fri, 01 May 2009 11:24:07 +0000

Some time ago, well almost a year ago actually, I posted an article called Parsing Twitter Usernames, Hashtags and URLs with JavaScript. From that article, it became immediately apparent that this was an issue many people were confronting and one that required an answer. Now, belatedly, it is the turn of ColdFusion to get the Twitter love.

Compared to JavaScript it is far easier to parse the URLs, Usernames and Hashtags in a tweet using ColdFusion and minor amendments to the regular expressions used in the JavaScript code.

Below is an example tweet that I’ll use for this post.

 myTweet = "Woot! I've just taken receipt of my Holux M-241 GPS logger. Good call @fordie. http://bit.ly/2RsAu ##holux ##gpslogger" />

NB. For the purpose of this test, I need to double-hash the hashtags to prevent ColdFusion throwing an error.

Parsing URLs as Links to the resource

We can simply demonstrate the parsing of the link with the following code in the body of the page:

 myTweet = REReplace(myTweet,'([A-Za-z]+:\/\/[A-Za-z0-9-_]+\.[A-Za-z0-9-_:%&\?\/.=]+)','\1</a>','ALL') />

NB. The \1 is a back reference to part of the regular expression match. A backreference stores the part of the string matched by the part of the regular expression inside the parentheses. This means you can reuse it inside the regular expression, or afterwards as I am doing in each of these examples.

The resultant HTML generated is the following:

Woot! I've just taken receipt of my Holux M-241 GPS logger. Good call @fordie. http://bit.ly/2RsAu #holux #gpslogger

Parsing Usernames as Links to Twitter

Following on from the URL example above, we can apply a similar methodology to Twitter usernames since they can also be URLs to their associated Twitter page.

We can simply demonstrate this with the following code:

 myTweet = REReplace(myTweet,'[@]+([A-Za-z0-9-_]+)','@\1</a>','ALL') />

The regular expression in this case finds all instances of @username. The Twitter URL is then applied to the username.

The resultant HTML generated is the following:

Woot! I've just taken receipt of my Holux M-241 GPS logger. Good call @fordie. http://bit.ly/2RsAu #holux #gpslogger

Parsing Hashtags as Links to Twitter’s Search

Finally, Twitter also allows user’s to create Hastags within their posts. Hashtags are a community-driven convention for adding additional context and metadata to your tweets. Like regular URLs and usernames, Hastags can been parsed as a URL to an online resource, in this case, Twitter’s search.

We can simply demonstrate this with the following code:

 myTweet = REReplace(myTweet,'[##]+([A-Za-z0-9-_]+)','##\1</a>','ALL') />

The regular expression in this case finds all instances of #hashtag. The Twitter Search URL is then applied to the hashtag.

The resultant HTML generated is the following:

Woot! I've just taken receipt of my Holux M-241 GPS logger. Good call @fordie. http://bit.ly/2RsAu #holux #gpslogger

All in one

So, putting all the regular expressions together, you would end up with the following:

Woot! I've just taken receipt of my Holux M-241 GPS logger. Good call @fordie. http://bit.ly/2RsAu #holux #ipslogger

Which translates as the more useful tweet:

Woot! I’ve just taken receipt of my Holux M-241 GPS logger. Good call @fordie. http://bit.ly/2RsAu #holux #gpslogger

Where to take it next

Wrap these code snippets up into a simple twitterise function could be a good starter for ten. Following that, we could also create a simple Twitter feed reader, but I’ll leave that up to you to develop.

My Work Philosophy

Simon — Thu, 05 Mar 2009 15:29:19 +0000

Okay, so many of the points below aren’t purely my philosophy, but ideas and principles I have picked up along the way throughout my [development] career. Some relate to the UNIX philosophy, or even the Zen of Python, but wherever they’re from, they can be applied to many other domains.

Don’t reinvent the wheel unless you really have to. Borrow code and ideas from elsewhere whenever it makes sense. The web community it great at sharing, just look at the various JavaScript libraries, the huge quantities of APIs or indeed the major players’ developer areas: Google Code, Yahoo! Developer Network, Mozilla Developer Center, Adobe Developer Connection and Dev Opera to name five I regularly refer to.
Things should be as simple as possible, but no simpler (Einstein). This idea is really born out of and emphasised by 37Signals’ Getting Real book. Commonly, 90% of people using an application only use 10% of it’s functionality. The key therefore is to find what people use most often and only build that functionality. If there is a requirement to add more, then sobeit. This can also apply to the code-level, the essence here being a balance between over- and under-engineering something.
Do one thing well (The UNIX philosophy). It is better to do one thing well, than several second-rate. This could be at the code level — think encapsulation, coupling and cohesion — or indeed at the application level — you’re never going to beat Microsoft Word, but Google and Zoho have developed compelling alternatives, but with far less features.
Don’t fret too much about performance — understand how to write efficient code and plan to optimise later if or when needed.
Don’t try for perfection because good enough is often just that. This of course is a matter for conjecture. If I were working on a personal project, I may be more stringent on perfection than say, for a client’s application. This doesn’t mean to say the client’s application would be any worse, but rather it is a question of dotting-the-is and crossing-the-ts. It also depends on your perspective and what gains can be made by aiming for perfection.
(Hence) it’s okay to cut corners sometimes, only if you can do it right later. I rarely adhere to this! It makes sense to do it right the first time, since bodge-jobs often come back to haunt you and result in double the effort!
Don’t fight it; go with the flow. This is somewhat clichéd, but the essence behind this is try to avoid getting stressed out. This isn’t always easy to achieve, but taking a step back from a situation and avoiding politics is important.

I often strive for perfection, which isn’t an entirely clever pursuit since it is almost impossible to achieve. However, in a realm of imperfection, the principles above have helped me to achieve a modicum of decent code throughout the years. They may also resonate and provide inspiration for you.

Programmer’s Dozen – Programming Best Practices

Simon — Tue, 03 Mar 2009 11:23:46 +0000

Take control of your code with these programming best practices from Kevlin Henney. At JAOO Aarhus 2008 Kevlin used a trash can, vampires, a train wreck, whiskey and much more to make you understand and remember his 13 constructive points (a programmer’s dozen) about programming and code smells.

The 13 points made by Kevlin were:

0. Prefer code to comments.
1. Follow a consistent form.
2. Employ the contract metaphor.
3. Express independent ideas independently.
4. Encapsulate.
5. Parameterize from above.
6. Restrict mutability of state.
7. Favor symmetry over asymmetry.
8. Sharpen fuzzy logic.
9. Go with the flow.
10. Let code decide.
11. Omit needless code.
12. Unify duplicate code.

You can see a video of Kevlin’s presentation on the JAOO website.