Advertise here via BSA

Rumors that Apple has been working on a television set have been going for quite some time. The fire was stoked on the release of Walter Isaacson’s Steve Jobs biography, in which Jobs declares that he “finally cracked it” — referring to television user interfaces — and again in the past week after DigiTimes claimed the company was working on a summer 2012 timeline with 32″ and 37″ models (at those sizes, I hope DigiTimes is wrong — their track record is hit and miss).

The current Apple TV, a fantastic product but not a television set in itself, runs a version of iOS that has no support for third-party App Store applications. In the last few months, we’ve had the smallest taste of what apps on an iOS TV platform could do with the introduction of AirPlay, which allows an iPad to serve as a controller, serving up the control interface on the tablet and another view on the television.

We can assume that a fully-fledged television set from Apple, with the interface Jobs says he finally perfected before his death, will do what the iPhone 3G did for third-party developers and allow applications on the platform. But just what exactly is it that we can look forward to? What innovative ideas will take root on Apple’s television platform in ways that could be significantly different from the apps present on existing iOS devices?

Gaming

With AirPlay, some of the most interesting developments have been in the gaming world. When the feature was announced in June, I wondered about the potential that could be unlocked by using iOS devices as controllers for console-like gaming, with many parallels to the upcoming Wii U. The big question is: will AirPlay setups eventually dent console sales as much as devices like the iPhone and iPad have put a dent in sales of dedicated mobile gaming devices like the PlayStation Vita and Nintendo 3DS?

The iPad is a pretty great mobile gaming device but the current Apple TV is decidedly underpowered; it still can’t run 1080p video content, which is at this stage otherwise pretty ubiquitous. It pretty much goes without saying that the iTV would run 1080p video and there’s a good chance it would have the guts to run apps with 3D graphics of some quality if Apple has any plans to let developers near it.

With a television that can handle high-definition graphics processing and an iOS controller that can change to suit any game, I’d say this is one area that independent and big name studios alike will have a field day in. I don’t believe it would take serious gamers away from the Xbox 360 and the PlayStation but I can see the Wii losing market share.

Education

I’m not a fan of straight up educational video, and I’m not a huge fan of audio teaching either. I love learning using web apps or the reflective nature of learning via text where you can pause and think about certain concepts or lines, or the passive, reactionary mode of learning through video — which pretends to be more like classroom experiences where the teacher can interact with the students but is really anything but.

We’ve had heaps of great apps on computers, tablets and mobile devices for learning new skills, such as the plethora of language-learning apps that have been selling in droves since before the Internet was a common household utility, but I think an iTV running iOS, using voice or other iOS devices as an input, could make for a great learning environment in your living room.

Imagine, for example, pulling up guitar tablature on your iPad while watching the technique in practice, in real-time on the TV, and being able to quickly pull up related instruction — for instance, if there’s a pinch harmonic in the song you’re learning but you’re not sure of the technique, you can keep the context — the tablature for the song — on the tablet and learn the technique from the video instruction on the big screen; you wouldn’t have to leave the current exercise to learn prerequisite techniques as you went along.

As the Siri technologies of voice recognition and intelligent processing get more advanced it’s exciting to think about what teacher-student interactions our devices could emulate in the future.

Fitness

For longer than I can remember, aerobics on the beach has dominated early morning TV. One of the most popular product categories inspired by the Xbox Kinect is fitness gaming, with titles such as Zumba — which appeals primarily to women, not the Xbox’s traditional demographic — selling insanely well, along with other strong performers like UFC Personal Trainer.

It’s clear that, for those who can’t find, get to or afford fitness groups in their area, or are just taking baby steps off the couch, the television is a great facilitator of beginner exercise. I can see iOS developers building programs much like those seen on TV but that offer the user complete customization over their workouts, and integrated ways to track and graph things like weight loss and gain and logging of food consumption.

Where Xbox fitness titles can be pretty gimmicky, I can see iOS developers creating a cohesive system across devices: responsive video training in front of the TV and logging data on the go with the iPad and iPhone.

These are just three of the areas that developers will undoubtedly leap on first if the iTV arrives and if it opens up for App Store submissions. Let us know your own predictions in the comments section.

Advertise here via BSA

Like webfonts, responsive design wasn’t something you heard much about until CSS3 specs started making it into popular browsers. Now, it’s the cool thing to do, and for good reason — it means one site to maintain for all devices. But it’s also a really challenging approach to web design. In this article, we look at 10 tools that’ll help you handle the challenge.

320 and up

Most responsive designs are built with full desktop size in mind and scaled down from there. Andy and Keith Clark, the developers behind 320 and up, believe the opposite approach works best: design for the small screen, and implement the layout working upwards in size. 320 and up contains Media Query increments for five viewport sizes, a vertical grid, preset styles for typography and components from HTML5 Boilerplate.

inuit.css

inuit.css is a HTML5 framework that uses a grid system that scales down to small screens ‘out of the box’. It’s a minimalist approach, giving you just what you need to get started without unnecessary styles, but it’s extensible and there are a range of handy plugins available for it — such as one that creates breadcrumb trails out of ordered lists.

Skeleton

Skeleton is a light collection of CSS and JavaScript files that make designing responsive sites based on the 960px grid easy. Skeleton includes some basic styling and typography presets to get you out of the gate quickly. This project is the brainchild of Dave Gamache, formerly of esteemed UX firm ZURB and now on Twitter’s design team.

Less Framework

Less Framework is a CSS starter with four layouts — default at 992px, and tablet, mobile and wide mobile sizes — based on a grid system and including a selection of typography presets. Because Less Framework is one of the most popular options, there’s a range of supporting tools such as a Rails gem, OmniGraffle stencil and Compass plugin built around Less.

BluCSS

BluCSS is a CSS framework that, as usual, uses a flexible grid to facilitate responsive design. One feature that stands out is its responsive images, something many of these frameworks leave out; apply a class to your images and they’ll scale with your design. No need to include multiple files at multiple sizes, though be wary of unnecessary load on mobile devices with this approach.

Mobile Boilerplate

From the developers behind the famous HTML5 Boilerplate comes Mobile Boilerplate, a responsive template that puts the focus on mobile devices, namely those running Android, iOS, Blackberry and Symbian software. Everything from viewport scaling to HTML5 offline caching to home screen icons are ready to go.

Tiny Fluid Grid

If you find all these CSS frameworks to be too much for your needs, Tiny Fluid Grid may be the alternative you’re looking for. Simply tell it how many columns your grid will need, how big you want your gutters and how wide the site will be, and this site will spit out a responsive fluid grid you can use right away.

Golden Grid System

The Golden Grid System is a 16 column grid that uses a folding method inspired by the DIN paper system to collapse down to 8 columns on tablet-size screens and 4 columns on mobile screens, making it work for designs that range from 240 to 2560 pixels wide. The GGS developers say their folding method is superior to others because the gutters are better at staying in proportion with the content, producing less of a squeezed (or sparse, depending on direction) look.

1140 CSS Grid

The 1140 CSS Grid takes the opposite approach of the 320 and up system. This is primarily aimed at people who really want to design for a wider 1280 pixel screen, and are sick of catering to a 1024 pixel baseline. 1140 CSS Grid allows them to do that while fluidly re-arranging to fit on smaller screens all the way down to mobile.

Respond.js

Even before you start working on a responsive design, you may be worried about visitors using browsers that don’t support media queries, the CSS3 feature that responsive sites depend on. With Respond.js, this problem is easily solved; the script makes min-width and max-width work in Internet Explorer 6, 7 and 8, and should work with other browsers lacking support.

Bonus: ZURB Foundation

ZURB’s Foundation is a newer entry among responsive design frameworks, and is one of the most promising, having already won over many users of other frameworks. Billed as an easy-to-use yet powerful framework for building both prototypes and production deployments that work across all kinds of devices, Foundation makes use of a flexible grid, a library of styles and elements for rapid prototyping, and professes to take the pain out of creating layouts for different formats with the same markup.

Advertise here via BSA

The Fuel Network has supported FITC events over the years and today is no different. SCREENS 2011, (formerly known as “FITC Mobile”), now dedicated to mobile, tablet and set top box development. Jam packed with information and a massive networking opportunity, SCREENS consists of presentations, demonstrations and panel discussions. It is one of the only events in the world designed for developers of all platforms of screen content.

• 2 full days of presentations, plus one optional day of pre-conference workshops
• Covering iOS, Android, HTML5 – JQuery Mobile, HP/WebOS, AIR, FLEX, Windows Mobile, as well as marketing and business of apps
• Over 40 presentations and panels covering all aspects of mobile, tablet, and set top box development
• 400+ attendees anticipated from around the world
• Evening networking event

The Details

Developing for Mobile, tablets, and more
November 14-15, 2011
Toronto, Ontario Canada
Event website link

The Venue

Metro Toronto Convention Centre (MTCC)
North Building (255 Front street west), Toronto, Ontario Canada

Confirmed Speakers

• Alex Kennberg
• Bob Burns
• Brady Gilchrist
• Chuck Freedman
• Darren Osadchuk
• Erik Von Harten
• Greg Carron
• Julian Dolce
• Kevin Suttle
• Marin Alejandro
• Martin Dufort
• Matt Fisher
• Matt Rix
• Matthew Patience
• Mikko Haapoja
• Pearl Chen
• Peter Nitsch
• R Blank
• Renaun Erickson
• Ryan Creighton
• Scott Janousek
• Timothy Quinn

Topics

Android OS • App Success • BlackBerry Tablet OS • Corona SDK • Designing for Mobile • Mobile Marketing • Digital Home • Grand Central Dispatch and Blocks • iOS • jQuery Mobile • Managing Mobile Projects • Metro • Microsoft Stack • HCI • QNX • Thread Management • UI • UX • Windows Phone

Who will be attending SCREENS?

SCREENS is for both current and future developers of mobile, tablet and set top box content. The program caters to beginners, intermediate and advanced programmers. While most of the topics will be technical in nature, they will include coverage of usability and design considerations for these platforms. They will also cover how to monetize app content, what the market looks like, and how to market your product and services.

Companies represented at SCREENS 2011 include:

Microsoft • Adobe • HP • Wavefront • Indusblue • QNX • Mobicartel • Ludicrous Software • Jam3 Media • Bestbuy • WhereCloud Inc • Almer/Blank • Transcontinental Interactive • Teehan + Lax • Canadian Film Center • WhereCloud Inc.

Pricing & Fuel Discount

Festival ticket prices range from $199-$499
Festival + Workshop ticket prices range from $249-$299
Student Festival ticket prices range from $99-$229

All tickets include coffee, snacks, evening events and an event grab bag.

Discount code ‘Fuel’ provides 10% off any SCREENS 2011 tickets.
The super early bird deadline is August 26^th

Full ticket details here.

Advertise here via BSA

I recently had the opportunity to get an inside look at a graduating class from Full Sail University. Future Coders may be a little misleading as these students have already been rocking out, but I’m still calling them “The Future” because they are now leaving school and heading out to join the community.

Where They Learned

Admittedly, the initial thought of university based web education had me a little skeptical. As with most things in life, though, proper perspective is achieved by getting a first-hand look instead of judging from afar. I challenge anyone to take a walk around the Full Sail Campus and not drop your jaw. In a city hosting Disney World, it approaches a Campus layout with the same level of awe inspiring detail. My wife joined me for the tour and said that she would even become a geek like me in order to attend there.

Inspiration is vital and there is no lack of it on this campus. The achievements of past creatives and some fantastic tech are all around the facilities. While these aren’t coding related, being in a space with full video green rooms, amazing sound decks and an ESPN motion capture studio has to be inspiring. The campus is filled with creatives and the feel as you walk around is amazing.

Who they Learned From

These students took the web design and development track, which focuses on Interface Design & Usability, Web Standards, Flash / ActionScript 3.0, Dynamic Back-End Development, leading to a Final Project.

Graduation from the program doesn’t just end with Final Project, though. These students sit down with their teachers and the faculty and discuss the program. They discuss the good and the bad, sharing observations and suggestions for improvement. There was some great data shared in comparing Github’s commit history graphs with their daily schedules. The staff truly listens and engages, it was great to see the process in action. I imagine that this happens with every group, but this particular one seemed as if they could not be ignored. They were extremely impressive.

Their Final Projects

The biggest challenge that I could imagine that there is for the instructors at Full Sail University is letting these awesome students out of their sight. I only got a few short hours with them and I went home wanting to know what they’ll each be doing next. For the time being, though, we’d like to share their Final Projects.

Anthony Colangelo

What did you think of Full Sail University?

I absolutely loved Full Sail University. The community is so vibrant, the teachers are all brilliant and truly amazing teachers, and all of the people around here are awesome people to be around. They’re all smart, passionate, and driven, which inspires you and makes you push yourself harder. I cannot convey my love for this school and these people enough.

Why did you build it, and how did you do it?

For our final project, we built WDD Social (http://wddsocial.com), which is a social network for the Full Sail web community (teachers, students, and alumni). It is a great way for the community to meet, share projects and industry information, and to stay connected. It is also a great way for the outside world, especially industry professionals and future employers, to see what the community has to offer.

We built it because, after going through the degree, we realized this is something that has been missing from the community and it is something that would make the community better as a whole.

We built the front-end of WDD Social with HTML5, CSS 3, and jQuery 1.6. On the back-end, we built a custom PHP 5.3 framework, called Framework5, and a MySQL database.

Which teachers and courses really stood out to you, and why?

The teachers that stood out to me were Jason Madsen (@jason_madsen, now the Program Director, formerly the Object-oriented Programming teacher) and Rick Osborne (@rickosborneorg, now Department Chair, formerly server-side language and database teacher). They both are so smart, passionate, and hardworking that it truly inspired me to work extremely hard. They really taught me a lot, and I will always go back to them for advice and insight as I move on in my career.

Follow Anthony @antcolangelo

Alicia Brooks

What did you think of Full Sail University?

Full Sail University was by far the greatest choice I could have made. I absolutely love the fast pace and realistic structure. The accelerated program keeps you on your feet, working hard, and out into the world so much sooner. I feel that it really did prepare me for my upcoming career.

Why did you build it, and how did you do it?

 
I built my final project, supportmymission.org because I wanted to help people through my web skills. Supportmymission is a non-profit that makes raising funds for mission’s trips easier. It allows users to share their mission with everyone online rather than being limited to the people they know. I used a lot of technologies but the main one was CakePHP, learning a framework was something I wanted to accomplish before graduating.

Which teachers and courses really stood out to you, and why?

 
I have to say that every teacher at Full Sail is awesome, they are all experienced and all always willing to help you advance your skill set. I would have to say that Brandon Brown (@bybrandonbrown) and Marianne Sheldon (@marianneSheldon) definitely stood out to me. I asked them so many questions during final project. They were always willing and open to make time for anything I needed. I really appreciated that!

Follow Alicia @aliciaj_

Oliver Lacan

What did you think of Full Sail University?

I loved nearly every minute of it.

I mastered more in two years than I’ve managed to teach myself in ten: vector drawing, user experience & usability concepts, basic animation, object-oriented programming, server-side dev, relational and NoSQL databases, web standards & accessibility, mobile dev, and the all-essential production process. I’ve met good, passionate and driven people, both on the teacher and student side.

New classes each month meant that we never got stale information, curriculums evolve month-to-month. It also made it hard to get sick of a topic for which you had no affinity.

What is your Final Project?

My final project at Full Sail is called Roomies. It’s a web application that offers task and expense management for roommates with busy schedules. It incentivizes collaboration and good relationships by rewarding participation and assignment completion.

Why did you build it, and how did you do it?

We wanted to make tedious house-related group tasks and expenses less painful and stressful. The idea had been in the back of my mind since the fall of 2009 when I met Andrew Smith, another Full Sail web student, on Twitter and realized he had a very similar idea. We wanted it to exist too badly.

To build Roomies we used Ruby on Rails (a first at Full Sail). We became familiar with it while working on cleverCode, a tiny company we founded six months into our degree with my classmate Zach Nicoll. Andrew, who joined us in early 2010, introduced us to RoR and I started actively teaching myself how to use the framework six months before our final project.

After we discovered CouchDB at Full Sail, Andrew showed me the MongoDB document-oriented database. The excellent integration with Rails through the Mongoid ODM made us decide to use it on Roomies instead of classical SQL.

We also used CoffeeScript, Sass, Haml, and Compass to speed up and clean up our development process as much as we could since we had less than 2 months of active development time.

Which teachers and courses really stood out to you, and why?

All teachers at Full Sail have one great quality, they constantly evolve. They’re encouraged to freelance by the faculty which means they’re always learning new techniques and eager to pass them on to us.

Chris Burke & Gus Hernandez – Web Interface & Usability / Applied Design Tools & Interfaces: Those two classes are the crux of the user experience, usability and web design knowledge we received. Both spectacular courses taught by two guys who will not wear gloves to smack you down if you don’t apply critical thinking and logic when designing an interface. In a field where people give to much credit to aesthetics, I can’t overstate how crucial this was.

Concepts of Object-oriented Programming: As a non-programmer when I started Full Sail, I struggled through the first ActionScript class there. After Sean Bernath ( @sbernath managed to help me “get” programming, Jason Madsen was the guy who carried me through the “OOP revelation” faster than I had ever imagined possible. His skill at breaking down intimidating concepts into simple metaphors and challenging exercises made me fall in love with coding, and bear in mind this was AS3 & Flash. The fact that he went on to become the Program Director at Full Sail Web makes me extremely confident regarding the degree’s future.

Advanced Server-side Languages & Advanced Database Structures: I’m still amazed at the in-depth knowledge of database design & management Rick Osborne managed to transmit to us. His push for the use of Git (now widespread in the program), unit testing, and further OOP concepts is why I think grads will be very valuable in the industry.

The jQuery class with Mike Smotherman (@codeinfused) made me realize why I had fallen in love with the web (and not applications) in the first place, and get a glimpse at the power of the DOM.

Follow Olivier @olivierlacan

Kent Lassen

What did you think of Full Sail University?

It was an amazing experience. I couldn’t have asked for a better school. It has brought me from my days of coding HTML in tables to today, where I know plenty of languages and how to create amazing websites.

What is your Final Project?

Lightning Owl. It is a web app that allows a person to write and share notes. It is a writer’s management tool.

Why did you build it, and how did you do it?

I built this as my final project. It was an idea that I had been thinking about because I was getting into blogging.

Which teachers and courses really stood out to you, and why?

Jason Madsen, who was one of my flash teachers was amazing. His class was extremely helpful to me when it came to programming. I also think that all of the final project teachers were amazing and helped greatly. Without them, I wouldn’t have been inspired.

Follow Kent @kentlassen

Tyler Matthews

What did you think of Full Sail University?

Full Sail has provided me with an incredible education experience. The curriculum is designed to teach the latest technologies used in various areas of the web, including user interface design, server-side development, as well as production and deployment. The program is also accelerated, which is essential when you consider the fast paced nature of the web, with its ever expanding list of technologies and trends. The most beneficial part of Full Sail was the people I interacted with during the time I spent there. The community of web students and teachers come from a diverse range of technical backgrounds, which provide everyone with various perspectives, methods and techniques.

What is your Final Project?

For my final project, Anthony Colangelo and I built a social network for the web program here at Full Sail. Our site WDD Social (wddsocial.com) is a community for students and teachers to interact and share industry related information. Members can also share projects with the community, which are displayed on their public profile and visible to prospective employers. We also created a job board for current students and alumni, where positions could be posted by community and non-community members. 

Why did you build it, and how did you do it?

Early in the program, Anthony and I realized that it was difficult to interact with students throughout the degree. Full Sail has an accelerated approach to education, where classes are typically taken at the rate of two per month. This makes it difficult to meet others throughout the degree, especially those who are more than a few months ahead or behind our group. We realized that a community site could benefit students, while utilizing the technologies we learned during our 21 months here at Full Sail. 

Which teachers and courses really stood out to you, and why?

I’ve always been fascinated by server-side languages, and feel as if that part of the degree was most beneficial to me. The topics covered provided me with an in-depth understanding of what it takes to develop practical applications in PHP and Coldfusion. The server side courses also covered database topics such as relational database systems, MySQL optimization, and even experience with NoSQL database technologies.

Follow Tyler @tmatthewsdev

Advertise here via BSA

One sign of a developer power tool hitting critical mass is when a wellspring of Graphical User Interfaces explode onto the scene. It looks like Git — the distributed version control system authored by Linus Torvalds — has arrived. It brings with it a bevy of Git clients for Mac OS X.

Some are old, some are shiny new, and some haven’t even officially been released yet. Let’s run them down, shall we?

GitX

GitX may be the oldest of the lot, but this is a powerful and great looking Git client. It features a history viewer, GitHub’s gist integration, and most importantly a great commit interface which allows for easy hunk and single-line commits.

Best of all, it’s totally free & open source! There is a ton of activity on GitHub, most interesting of which is a fork by Brotherbard that adds many experimental features.

Git Tower

Free while still in beta, Git Tower is a commercial application claiming to be “the most powerful Git client for Mac”. Big words, but they’re doing a great job living up to them. Git Tower has a slick interface, a repo manager for easily loading previous projects, remote repo integration, and the list goes on.

Another thing that makes this application special is that they managed to capture FUEL editor Doug Neiner’s ugly mug on the History view screenshot. What are the odds?! :)

Gitbox

Gitbox hosts a bunch of powerful features while maintaining a minimal interface. Anybody who has designed interfaces for software knows how difficult a task that can be.

The app is free for a single repository and $39 for multiple repositories. Its features include single-click operations, automated remote commit fetching, local/remote branches, and external diffing tool integration.

GitMac

We don’t know too much about GitMac since it hasn’t entered its beta stage yet, but its definitely one to keep an eye on as development progresses.

Review

It’s exciting to see the maturation and adoption of a tool as powerful as Git. While graphical interfaces aren’t necessary for us “hardcore developers”, they are really nice for those who could benefit greatly from distributed version control, but have a case of Terminalitis®.

Give these tools a try and be sure to let us know in the comments if we missed any!

Advertise here via BSA

Manoj Sachwani — a contributor here at Fuel Your Coding — is launching a free weekly newsletter just for web developers!

Manoj says there will be just one email each Saturday and absolutely no spam. Right now the newsletter will mostly be sharing valuable links for developers, but he is open to feedback and would love us to help him improve it.

Potential topics include:

AJAX, AS3, ASP, ASP.net, Browsers, CSS,Cappuccino, CoffeeScript, Cold Fusion, Flash, Flex, HTML, HTML5, JavaScript, Media, PHP, Photoshop, Prototype, RSS, Rails and Ruby, SOAP, SQL, SVG, Semantic, WAP, XML, YUI, jQuery,Jobs, & more

Looks like he has something for everybody in that list. If you’re interested head on over to WebDeveloperWeeky.com and subscribe!

Advertise here via BSA

The very promising jQuery Mobile project is now in its first Alpha release! What better time to give it a spin with our (err… my) favorite web framework?!

You should read jQuery Mobile’s official introduction section to familiarize yourself with its principles, but in a few words: you include it on the page, format your markup to conform to its requirements and reap the benefits. Yay, let’s write a (very contrived) CRUD application with Rails 3 and jQuery Mobile!

Setup

Our application will allow us to create, read, update and delete blog posts (remember when I said it was contrived? Uhm..yah) from mobile devices. If you don’t have Rails 3 installed yet, you can get it via RubyGems:

gem install rails

Use the rails command line tool to generate a new application. We’ll call it jqmoblog.

rails new jqmoblog
# ... a bunch of files are created
cd jqmoblog

As of Rails 3.0.1 you cannot specify jQuery as the JavaScript tool of choice when you generate a Rails application, but we can easily swap it in by using the handy, dandy jquery-rails gem. Edit the Gemfile in the project’s root directory and add a dependency on the gem. Once finished your Gemfile will look something like this:

source 'http://rubygems.org'

gem 'rails', '3.0.1'
gem 'sqlite3-ruby', :require => 'sqlite3'
gem 'jquery-rails'

Install the required gems using the bundle command line tool:

bundle install

Now we’ll use the Rails generator added by the jquery-rails gem to get all the jQuery files we need:

rails generate jquery:install

When prompted, allow it to overwrite rails.js.

We’re almost ready. The application skeleton is in place and jQuery has replaced the Rails default JavaScript libraries, but we’re missing the basic model, controller, and views for our application.

Thankfully, Rails has a generator which will create these files for us and its called the scaffold generator. We’ll keep the blog posts in our app super-simple since we’re really just using them to learn about jQuery Mobile. Each post will have a title and a body. Generate the scaffold for a Post resource like this:

rails generate scaffold Post title:string body:text

This command will provide a list of files and directories it created. There should be a model (app/models/post.rb), a controller (app/controller/posts_controller.rb), and a directory of views (app/views/posts) for our Post resource.

Run the database migration that was created from the scaffold command so our database has a posts table with the required columns for storing our posts:

rake db:migrate

At this point you can fire up a Rails server and the app will load up in your browser:

rails server

Point your browser to http://localhost:3000 and you should see this:

Hmm, before we get to mobilizing this application, let’s make the root url load the list of our posts instead of the default Rails index file:

rm public/index.html

Edit the config/routes.rb and set the root route like so:

Jqmoblog::Application.routes.draw do
  resources :posts
  root :to => "posts#index"
end

Now load up http://localhost:3000 again and you should see the empty list of posts.

We still need to get the jQuery Mobile files on the page. Lets use the ones hosted on jquery.com. Add them to the application’s layout file so they’ll be on every page that gets served. In app/views/layouts/application.html.erb, edit the head section to look like this:

<head>
  <title>Jqmoblog</title>
  <link rel="stylesheet" href="http://code.jquery.com/mobile/1.0a1/jquery.mobile-1.0a1.min.css" />
  <%= javascript_include_tag :defaults %>
  <script src="http://code.jquery.com/mobile/1.0a1/jquery.mobile-1.0a1.min.js"></script>
  <%= csrf_meta_tag %>
</head>

Okay, everything is in place. Now we’re ready to turn this into a mobile app!

Getting Started

Before we flesh out our mobile CRUD actions, let’s get the posts index looking decent in mobile browsers. jQuery Mobile relies directly on the page’s markup to work its magic, so to invoke it we just need to change our views to conform to its conventions.

Each “page” in a jQuery Mobile application needs to be wrapped in a div with a data-role attribute of page. I put “page” in quotes because there can actually be many of them on a single webpage loaded from the server. In our app we’ll be loading each “page” from Rails, so we should just add this to our layout file which will wrap each of our individual views:

Before

<body>
  <%= yield %>
</body>

After

<body>
  <div data-role="page">
    <%= yield %>
  </div>
</body>

Next edit the post’s index (index.html.erb) and change the markup to create a header and a content section which lists all the posts in the database.

Before

<h1>Listing posts</h1>

<table>
  <tr>
    <th>Title</th>
    <th>Body</th>
    <th></th>
    <th></th>
    <th></th>
  </tr>

<% @posts.each do |post| %>
  <tr>
    <td><%= post.title %></td>
    <td><%= post.body %></td>
    <td><%= link_to 'Show', post %></td>
    <td><%= link_to 'Edit', edit_post_path(post) %></td>
    <td><%= link_to 'Destroy', post, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to 'New Post', new_post_path %>

After

<div data-role="header">
  <h1>Listing posts</h1>
</div>

<div data-role="content">
  <ul data-role="listview">
    <% @posts.each do |post| %>
    <li>
      <%= link_to post.title, post %>
      <%= link_to 'edit post', edit_post_path(post), "data-icon" => "gear" %>
    </li>
    <% end %>
  </ul>
</div>

Load up the page and it should look like this:

Two things to note here. First, we are once again using the data-role attribute to create the header and the styled list. This is a major theme of jQuery Mobile (as of the Alpha, I’m told they *might* be switching to class names instead of data- attributes). Second, each list item has two links, and jQuery Mobile automatically knows that this means we want to use a split button list. Pretty cool, huh?

Let’s add a button which will take us to a page where we can create new posts. Add this line to the end of the header div:

<%= link_to 'Add', new_post_path, "data-icon" => "plus", "class" => "ui-btn-right" %>

Again, jQuery Mobile “just knows” that this should be a button in our header and we pass it a class and a data-icon attribute to tell it where to place it and which icon to use. We now have a button in the header which links to the new post path!

Create

We’re gonna need to create posts so we can read, update and delete them, so lets handle creation first. The “Add” button on the posts index links to the new.html.erb view. It works as is and looks okay too. We’ll just tweak the markup to make it fit into the jQuery Mobile styles:

<div data-role="header">
  <h1>New Post</h1>
</div>

<div data-role="content">
  <%= render 'form' %>
</div>

We can now add new posts using the mobile interface! Go ahead and create a few so the posts index shows a list with links to edit each post:

Read

People will read posts from their show.html.erb view. Again, no change to the underlying controller or model code needs to happen. Just update the view file to look like this:

<div data-role="header">
  <h1><%= @post.title %></h1>
  <%= link_to 'Home', posts_url, "class" => "ui-btn-right" %>
</div>

<div data-role="content">
  <%= @post.body %>
</div>

Update

When we set up the posts index we added links to the edit.html.erb view using the gear icon on the right side of the split list. Now we just need to change the markup on that view to conform to jQuery Mobile’s requirements. Have you sniffed out a pattern to this development process yet?

<div data-role="header">
  <h1>Editing Post</h1>
</div>

<div data-role="content">
  <%= render 'form' %>
</div>

Again, it just works as expected and it will look great on many mobile devices. On to the final action, delete!

Delete

To facilitate deleting a post we just have to modify the delete links created by Rails’ scaffold generator to fit the rest of the mobile site. I think the edit page is a good place to add a delete link, so lets add a button to the header of edit.html.erb:

<%= link_to 'Delete', @post, :method => :delete, "data-icon" => "delete", "class" => "ui-btn-right" %>

The edit view is now complete, and it lets us update and delete our post.

Closing Up

If you’ve made it this far, you’ve probably realized that working with jQuery Mobile is pretty painless and it fits in with Rails quite well. There are a bunch of other things that jQuery Mobile can do, but this should hopefully whet your appetite. Remember, the framework is still in the Alpha stage so things can and probably will change.

I encourage you to read more about the project and get involved at an early stage so we can all benefit from a strong community!

***Download the source code for the application built in this post***

Advertise here via BSA

The trend toward rich client-side web applications has brought with it a need for robust JavaScript development tools. Firebug lead the way in this arena, but WebKit’s Web Inspector has caught up in a big way and ships with all recent versions of Safari and Chrome.

One powerful tool inside Web Inspector that is likely under utilized is the Profiles pane. I write a lot of client-side JavaScript and it still took me a long time to work up the gusto to dig into this tool and get anything out of it. If you find yourself in the position I was in, hopefully this post will give you what you need to get up and running quickly.

Basics

The JavaScript profiler is used to find and alleviate CPU bottlenecks in your code. To use it you invoke one or more “profile” runs in which Web Inspector tracks all JavaScript executed on the page and the time taken to execute it. In the picture below you will see a single profile called “Profile 1” being displayed.

There are two ways to run a profile:

1) Manually

The pane itself has a little button in the lower left-hand corner which can be used to start and stop a profile. This is the least precise of the two methods, but is sometimes good enough for one-off profiles. Click it once, go perform whatever action on the page that invokes the code you want profiled, and then click it again to stop.

2) Programmatically

The way I suggest you invoke profile runs is by calling into the console directly from your code. This will allow you to precisely position the start and stop of the profile for maximum signal to noise ratio. Here is how you might profile a totally contrived for loop programmatically:

console.profile('for loop');
for (var i = 0; i < 100; i++) {
  console.log('i is: ', i);
}
console.profileEnd('for loop');

After that bit of code is executed a new profile titled “for loop” will appear in the Profiles pane to be reviewed. The string argument to these functions is optional. If you don’t provide one it will simply increment “Profile [x]” like it does when run manually.

The Lingo

Now we know what the Profiles pane looks like and how to make it run, but its of no use unless we can derive meaning from the results. We can’t do that without understanding the terms used, so here are explanations as I understand them:

Self — the amount of time spent directly in the corresponding function

Total — the amount of time spent in the corresponding function and all functions called by it

Calls — how many times the corresponding function was called

Average — the value of the corresponding function’s Self divided by its Calls

Of these, Self and Total are the most confusing. The key thing to know is that the profiler tracks not only the time spent in each individual function, but also the time spent in functions called by that function. This is very useful when “drilling down” on a stack of function calls because you can look to see if the Total is bigger than the Self and if it is you know the time-consuming function is nested beneath the current one.

Everything’s Relative (or Absolute)

By default the Profiles pane displays all information in relative times so that each function is assigned a percentage of the total time of the profile. This is helpful in some scenarios, but I find the absolute times (measured in milliseconds and seconds) much more useful most of the time. To switch the profile result to absolute times, just click the little % sign at the bottom of the pane.

Top to Bottom. Bottom to Top

You can also sort the profile results using two different approaches. The default is the “Heavy” view or bottom up approach, which will more quickly float up the offending functions to the top of the heap. This is helpful to quickly identify trouble areas, but sometimes confusing because it doesn’t follow the logical structure of your code. For that, switch to the “Tree” view or top down approach. It looks like this instead:

Focus

One more feature of the Profiles pane is the ability to remove sections of the results and focus solely on the interesting bits. Do this by highlighting the interesting function and clicking the little eye icon in the lower lefthand corner. Other results will disappear and time percentages will be recalculated in the scope of the focused function.

Conclusion

I hope the above information explains what Web Inspector’s Profiles pane is, how to invoke it, what the results mean, and how to better organize them to increase their value. Give this power tool a try the next time you have some CPU intensive JavaScript that needs optimizing!

Advertise here via BSA

Earlier this summer, we kicked off a series on MongoDB where the goal was to write a simple todo application using native MongoDB drivers and three of our favorite scripting languages.

• Part One: the Plot
• Part Two: Ruby ToDo

This article is part 3 in that series, in which we write said application in PHP.

The Interface

In case you missed it you can look back at the introductory article for the complete details, but real quick I’ll review interface here:

• todo – list all incomplete tasks sorted by priority then chronologically
• todo next – list all incomplete tasks that are high priority
• todo done – list all complete tasks chronologically
• todo high “pay bills” – add high priority task called “pay bills”
• todo low “get milk” – add low priority task called “get milk”
• todo finish “pay bills” – complete task called “pay bills”
• todo dont “get milk” – delete task called “get milk”
• todo help – list all commands and their usage

Looks simple enough, let’s dive in!

The Driver

10gen distributes the PHP extension as a PECL package, or you can install from source. For more details, refer to the PHP.net Guide

We will go ahead and just use PECL, which is as easy as running one command.

pecl install mongo

You will also need to edit your php.ini file to add the following line, and probably reload your server.

extension=mongo.so

Go ahead and start a file called ToDo.php and stub out the first few lines. Since this is a command line application, it’s a bit different from a standard PHP script. We need to add a shebang and we’ll go ahead and change our error reporting levels to keep things quiet. Changing your error reporting is optional, if you aren’t sure of your coding skills, just leave the error reporting at full blast, you can turn it down when we finish the app.

#!/usr/bin/env php
< ?php

error_reporting( E_ERROR | E_PARSE );

The ToDo Class

PHP5 has great support for object-oriented programming, so we will employ a single object of a class we’ll write called ToDo. The class will take in the required command-line arguments, connect to the MongoDB collection that stores our todos, and execute the appropriate commands on them.

To facilitate these needs, our object will need to take some arguments from the user and store a reference to the MongoDB collection when it is instantiated:

  class ToDo {

    protected $argv = array();
    protected $mongo_connection = null;
    protected $mongo_db = null;

    public function __construct ( $argv ) {
      $this->argv = $argv;
      try {
        $this->mongo_connection = $mongo = new Mongo();
        $this->mongo_db = $this->mongo_connection->todo;
      }
      catch ( Exception $e ) {
        throw new Exception ( "Oops! Error connecting to MongoDB: " . $e->getMessage() );
     }
   }

The __construct function is the PHP5 way of adding a constructor to a class. This is called when you instantiate an object, like this for instance:

$my_todo = new ToDo( $argv );

When a new ToDo object is instantiated, our class will store the arguments passed in to it in an protected member called $argv and set up a connection to MongoDB in a member called $mongo_connection. Mongo is a class provided by the Mongo extension we installed earlier.

For convenience we will set up an instance of MongoDB in the member called $mongo_db. We do this since we will only be using one database.

Our ToDo class expects some arguments passed in to the constructor, so we need to provide them when we instantiate it. These arguments will be read in from the command-line when the program is executed, and PHP exposes these to our program via the $argv global variable.

However, $argv only exists in certain execution contexts of PHP, so we need to make sure we are executing from the command line. To ascertain this, we look at the constant PHP_SAPI, then we instantiate a ToDo object with the $argv array.

  if( 'cli' == PHP_SAPI ) {
    try {
      $app = new ToDo( $argv );
    }
    catch( Exception $e ) {
      print $e->getMessage() . "\n";
    }
  }

At this point, the ToDo.php should look like this:

#!/usr/bin/env php
<?php
   error_reporting( E_ERROR | E_PARSE );
   class ToDo {
     protected $argv = array();
     protected $mongo_connection = null;
     protected $mongo_db = null;
     public function __construct ( $argv ) {
       $this->argv = $argv;
      try {
        $this->mongo_connection = $mongo = new Mongo();
        $this->mongo_db = $this->mongo_connection->todo;
      }
      catch ( Exception $e ) {
        throw new Exception ( "Oops! Error connecting to MongoDB: " . $e->getMessage() );
      }
    }
  }

  if( 'cli' == PHP_SAPI ) {
    try {
      $app = new ToDo( $argv );
    }
    catch( Exception $e ) {
      print $e->getMessage() . "\n";
    }
  }

You can execute this program from the command-line, but nothing visible will happen. We still need to implement the bulk of the program, which parses the user’s command-line arguments and acts appropriately.

A Little Help

The first thing we’ll implement is also the simplest, a method that prints usage help for the program. It looks like this:

protected function help ( $error = null ) {
  if( ! is_null( $error ) ) {
    print "$error\n";
    print "\n";
  }

  $out = < <<EOF usage: {$this->argv[0]} <method>

== Methods ==

<none>             list all incomplete tasks sorted by priority then chronologically
help               show this help
next               list all incomplete tasks that are high priority
done               list all complete tasks chronologically
high <argument>    add high priority task called </argument><argument>
low </argument><argument>     add low priority task called </argument><argument>
finish </argument><argument>  complete task called </argument><argument>
dont </argument><argument>    delete unfinished task called </argument><argument>

EOF;
  print $out;
}

Run, Baby, Run

Now our application needs to be able to actually do it’s job, so lets create a method called run which will handle the program’s flow. In this method we examine the commands the user has given and call our other methods to get that work done. The default action is to list all incomplete tasks, and the catch-all is to execute the help method we implemented above. Here is what run looks like:

public function run () {
	try {
		if ( 1 >= count( $this->argv ) ) {
			$this->show(
				array( "complete" => false ),
				array( "level" => 1, "added" => 1 )
			);
		}
		else {
			$argument = strtolower( $this->argv[1] );
			if ( "help" == $argument )
				$this->help();
			else if ( "next" == $argument )
				$this->show(
					array( "level" => "high", "complete" => false ),
					array( "level" => 1, "added" => 1 )
				);
			else if ( "done" == $argument )
				$this->show(
					array( "complete" => array( '$ne' => false ) ),
					array( 'completed' => 1 )
				);
			else if ( "high" == $argument )
				$this->add( "high", $this->argv[2] );
			else if ( "low" == $argument )
				$this->add( "low", $this->argv[2] );
			else if ( "finish" == $argument )
				$this->complete( true, $this->argv[2] );
			else if ( "dont" == $argument )
				$this->complete( false, $this->argv[2] );
			else
				throw new Exception( "Bad Method" );
		}
	}
	catch ( Exception $e ) {
		$this->help( $e->getMessage() );
	}
}

$this->argv is an Array we were given when the ToDo constructor was run. It should hold all of the options and arguments that the user provided when they ran the application from the command line. If there is only one or fewer arguments we use a default action. Otherwise we move into the switch statement and choose a method there.

One item worth noting is that we assume that $this->argv[0] is the name of the program itself, which is how PHP (and most other languages) handle command line arguments.

Using Mongo

So far we’ve only dealt with setting up our class and parsing user arguments, we’ve hardly event glanced at MongoDB! Time to change that! I’ll work through each of the methods referenced in run

First, the show method:

protected function show ( $params = null, $sort = null ) {
  $cursor = $this->mongo_db->todos->find( $params );
  if( ! is_null( $sort ) )
    $cursor->sort( $sort );
  foreach ( $cursor as $row )
    print $row['task'] . "\n";
}

This method takes an array of selection parameters and an array of sort options (both optional) and passes them directly to the MongoDB cursor. The cursor will then let us extract the matching documents one at a time, sorted and returned as arrays. This style of interface is pretty easy to work with, it’s one of the great benefits of using a document store like MongoDB.

Now let’s find a way to store those item’s in MongoDB in the first place. This requires us to implement the add method.

protected function add ( $level, $item ) {
  if ( 2 >= count( $this->argv ) )
    throw new Exception( "missing argument" );
  $this->mongo_db->todos->insert( array(
    "task" => $item,
    "level" => $level,
    "complete" => false,
    "added" => time()
   ) );
}

Our add method takes two arguments. $level is the importance of the item, either “high” or “low”. $item is the text of the item itself. Once you have these two facts you can quickly pass them on to MongoDB’s insert method.

The insert method in MongoDB takes an associative array and persists it to the datastore as a document. You can store just about anything you like this way, as long as it can be serialized.

The final method we need is a bit more versatile, the complete method. This method can either finish a task or remove it from the system.

protected function complete ( $finish, $item ) {
  if ( 2 >= count( $this->argv ) )
    throw new Exception( "missing argument" );
  $document = $this->mongo_db->todos->findOne( array( "complete" => false, "task" => $item ) );
  if ( is_null( $document ) )
    print "No Matching ToDo Found\n";
  else {
    if ( $finish ) {
      $document['complete'] = time();
      $this->mongo_db->todos->save( $document );
    }
    else {
      $this->mongo_db->todos->remove( $document );
    }
  }
}

This method uses a variant of find (which we used in show) called findOne. Think of this as the MongoDB version of LIMIT 0,1. After we’ve tried to find a task matching the requested title, we then either abort (if not found) or complete (if found).

When completing we will use one of two MongoDB methods, depending on whether we are finishing or skipping the task. The save method will be used to finish a task. This method takes a MongoDB document that was previously retrieved and saves it back into the database. Any changes you make to the object (like setting the completed time, for instance) is persisted to the database. This is done through a unique (but not necessarily sequential) ID given to each document in the datastore.

To delete a task from our list we need to use remove. This method takes an existing document object (with a document id) and deletes it from the database.

Finishing Up

So there you have it, we’ve completed all of our methods. Now all we have to do is call run and we should have a working todo program!

if( 'cli' == PHP_SAPI ) {
  try {
    $app = new ToDo( $argv );
    $app->run();
  }
  catch( Exception $e ) {
    print $e->getMessage() . "\n";
  }
}

You can view/download the program in its entirety here. One thing to note is how little datastore code is needed to add CRUD to an application when using MongoDB as a datastore.

Hopefully this article has helped you with PHP or MongoDB, or both. Stay tuned for our next article in the series when we write the exact same application in Python!

Advertise here via BSA

Today’s software development culture promotes rapid development methodologies, minimum viable products, releasing early & often, and the axiom that “real artists ship.” What common thread weaves its way through all of these things?

SPEED.

If you haven’t felt the pressure to squeeze one more feature in before the release date, to fix an interface bug “RIGHT NOW!”, to get your product launched before your competition, or to shave a week off of your development schedule then you haven’t been developing software for all that long.

What many people fail to realize — and what I’ll emphasize in this post — is that the compromises we often make when optimizing for development speed can actually slow us down. More succinctly:

If you want to move faster, you have to slow down.

Allow me to demonstrate this concept in a few key areas of software development.

Testing

Automated tests are one of the first things to get tossed out when on a time crunch. Writing tests takes time, and that time could be spent implementing features. The problem with this line of thought is that one way or another the software needs to be tested before it’s released, and the less you automate the more you end up testing manually (how many times have you stepped through the same web form to test server responses?).

The added benefit of writing tests alongside your implementation code (preferably before it) is that it forces you to think about the problem space and you go into your implementation having put much more thought into it. So yes, you spend time writing tests, but you make it up in reduced implementation time.

The Big Win™ with building up a solid test suite is it reduces the amount of work you have to perform later when you refactor or add new features, making it a HUGE time savings as the system becomes more complex. Regressions suck. A solid test suite helps avoid them.

Naming Things

It’s been said that there are only two hard problems in Computer Science: cache invalidation, naming things and off-by-one errors.

When it comes to naming things people often mail it in because it is hard and they think they are wasting a lot of time doing it. This “speed optimization” can manifest itself in variables named “x”, “foo”, or “tmp3”. Those are ridiculous names, but even “okay” names that don’t properly describe what they represent can be quite troublesome.

Why is it so important to name things well and how could dedicating time towards that effort speed up development? Remember, code is written once and read many times. The ability for you (or more often, somebody else) to return to your software and pick up the context quickly is paramount in maintaining development speed. Nothing makes picking up context more difficult — and therefore time consuming — than non-semantic (devoid of meaning) variable, function, and/or class names.

Do yourself a favor: slow down & put some thought into naming things. Future-you will reap the benefits.

Documentation

When time is of the essence documentation is often pushed to last or thrown out altogether. The problem with this is that it also impacts how quickly new developers (including yourself 6-12 months later) can come up to speed and be efficient. There is no better time to document your code than after you have just finished writing it. At that point it is still fresh on your mind and you know all the little gotchas that will cost hours & days of development time if the next programmer doesn’t see them coming.

One reason people think documentation slows them down is that they formalize it too much or end up writing novels about their software. If your code needs a novel to explain it, it is too complicated and needs to be refactored into smaller, simpler pieces.

How can you document code and keep up the speed of development? Follow these guidelines and you’ll find that adding documentation as you go (which is far less daunting than going back and documenting everything at the end) adds trivial amounts of time to the overall development.

1. Put a brief summary at the top of multi-line functions.
2. Include inline warnings or explanations for tricky bits of code. This is also a red flag for refactoring later
3. Always document the intent instead of implementation
4. Make exceptions to these guidelines when it is prudent

The importance of documentation (as well as the form of it) varies from project-to-project, but almost all code needs these little breadcrumbs to be easily maintained & extended.

The Principle

That’s just a handful of examples. I could go on to talk about code style & establishing conventions, optimizing for readability, habitual refactoring, and other such concepts, but it is the overriding principle that is most important:

Invest time to think about what you’re trying to accomplish and the best way to proceed from the start when your software is simple. That way when complexity rears its ugly head your development won’t come to a screeching halt.

Need to develop something quickly? Just remember that sometimes you have to slow down to go faster.

Advertise here via BSA

Probably one of the first topics covered when you get started learning about jQuery events is the concept of canceling the browser’s default behavior. For instance, a beginner click tutorial may include this:

$("a.toggle").click(function () {
    $("#mydiv").toggle();
    return false; // Prevent browser from visiting `#`
});

This function toggles the hiding and displaying of #mydiv, then cancels the browser’s default behavior of visiting the href of the anchor tag.

It is in these very first examples that bad habits are formed as users continue to use return false; whenever they want to cancel the default browser action. I am going to cover two very important topics in this article relating to the canceling of browser events:

• Use the right method for the job: return false vs. preventDefault, stopPropagation, and stopImmediatePropagation
• Top, bottom or somewhere in the middle: where in the event callback should you cancel default behavior?

Note: in this article when I refer to event bubbling, I am talking about how most events will fire on the original DOM element, and then on each parent element in the DOM tree. Events do not bubble to siblings or children (When events “bubble” downward, it is called event capturing). Learn more about bubbling and capturing.

Use the Right Method for the Job

The main reason return false is so widely misused is because it appears to be doing what we want. Link callbacks no longer redirect the browser, form submit callbacks no longer submit the form, etc. So why is it so bad?

What return false is really doing

First off, return false is actually doing three very separate things when you call it:

1. event.preventDefault();
2. event.stopPropagation();
3. Stops callback execution and returns immediately when called.

“Wait a minute,” you cry! I only needed to stop the default behavior! I don’t need these other two items… I think.

The only one of those three actions needed to cancel the default behavior is preventDefault(). Unless you mean to actually stop event propagation (bubbling), using return false will greatly increase the brittleness of your code. Lets see how this misuse plays out in a real world scenario:

Here is our HTML for the example:

<div class="post">
    <h2><a href="/path/to/page">My Page</a></h2>
    <div class="content">
        Teaser text...
    </div>
</div>
<div class="post">
    <h2><a href="/path/to/other_page">My Other Page</a></h2>
    <div class="content">
        Teaser text...
    </div>
</div>

Now lets say we want the actual article to load into the corresponding div.content when a user clicks on either title link:

jQuery(document).ready(function ($) {
   $("div.post h2 a").click(function () {
      var a    = $(this),
          href = a.attr('href'), // Let jQuery normalize `href`,
          content  = a.parent().next();
      content.load(href + " #content");
      return false; // "cancel" the default behavior of following the link
   });
});

All is well (currently) and our dynamic page is well under way. Down the road we decide another piece of functionality we want is to add the class "active" to any div.post that has been clicked (or when a child element has been clicked) most recently. So, we decide to add a click handler to them as well:

// Inside Document Ready:
var posts = $("div.post");
posts.click(function () {
    // Remove active from all div.post
    posts.removeClass("active");
    // Add it back to this one
    $(this).addClass("active");
});

Will this work when we click a title link? NO! The reason it won’t work is because we used return false in the link click event instead of using what we really meant! Because return false really means event.preventDefault(); event.stopPropagation(); the click event never bubbled up to the parent div.post and our new event has not been called.

This becomes even more of an issue when mixing normal events with live or delegate events:

$("a").click(function () {
    // do something
    return false;
});

$("a").live("click", function () {
    // THIS WON'T FIRE
});

So what DO you really want?

preventDefault()

In most situations where you would use return false what you really want is e.preventDefault(). Using preventDefault requires you allow for the event parameter to be accessed in your callback (In this example, I use e):

$("a").click(function (e) {
    // e == our event data
    e.preventDefault();
});

This does everything we want without prohibiting parent elements from receiving these events as well. The fewer restrictions you place on your code the more flexible it will be to maintain.

stopPropagation()

Sometimes you just want to stop the propagation. Take the following example:

<div class="post">
    Normal text and then a <a href="/path">link</a> and then more text.
</div>

Now, lets pretend we want one thing to happen when you click anywhere in the div except on the link, and you want the user to actually be able to follow the link if they click on it. (From a usability standpoint, this is a poor example. You probably don’t want something else to happen if a user slightly misses clicking on the link!)

$("div.post").click(function () {
   // Do the first thing;
});

$("div.post a").click(function (e) {
    // Don't cancel the browser's default action
    // and don't bubble this event!
    e.stopPropagation();
});

In this case if we had used return false the div’s click event would not have fired, but the user would also not have been directed to the correct destination either.

stopImmediatePropagation()

This method stops any further execution of an event, even to other handlers bound on the same object. All events bound to a particular item will fire in the order they were bound. Take the following example:

$("div a").click(function () {
   // Do something
});

$("div a").click(function (e) {
   // Do something else
   e.stopImmediatePropagation();
});

$("div a").click(function () {
   // THIS NEVER FIRES
});

$("div").click(function () {
   // THIS NEVER FIRES
});

If you think this example looks contrived, it really is. However, the situation is a very real one. As you build more abstracted code, different widgets and plugins may be adding events to the same code you are working with. This makes understanding and using stopImmediatePropagation worth while when you come across a situation that needs it!

return false

Only use return false when you want both preventDefault() and stopPropagation() and your code can support not canceling the default behavior until you reach the end of your callback execution. I strongly encourage against using this method in any examples you may write for new jQuery developers. It promotes a poor use of event cancellation and should only be used when you are consciously deciding you need what it provides..

Top, Bottom or Somewhere in the Middle

Before, when you were (mis)using return false, it always had to go at the end of your function, or at least at the end of a particular line of logic where no further execution was needed. With e.preventDefault we have more choices. It can be called at any time during a callback function to take effect. So where should you put it?

1. During development, it should (almost) always be the very first line. The last thing you want is for your form you are trying to AJAXify to actually submit to another page while you try to debug a JavaScript error in the callback.

2. In production, if you are following progressive enhancement, put it at the bottom of the callback, or at the end of execution flow. If you are progressively enhancing a normal page, then your link click event or form submit event has the proper server side fallbacks needed for browsers that don’t support JavaScript (or don’t have support enabled). The benefit here, however, is not related to browsers with JS turned off, but rather browsers with it turned on in the situation where your code throws an error! Take a look at the following code:

var data = {};
$("a").click(function (e) {
    e.preventDefault(); // cancel default behavior

    // Throws an error because `my` is undefined
    $("body").append(data.my.link); 

    // The original link doesn't work AND the "cool"
    // JavaScript has broken. The user is left with NOTHING!
});

Now, lets take a look at the same event with the preventDefault call being placed at the bottom:

var data = {};
$("a").click(function (e) {
    // Throws an error because `my` is undefined
    $("body").append(data.my.link); 

    // This line is never reached, and your website
    // falls back to using the `href` instead of this
    // "cool" broken JavaScript!

    e.preventDefault(); // cancel default behavior
});

The same applies for form submit events as well, provided you have the proper fallback information in place. Never count on your code always working. It is far better to plan for a nice fallback than assume errors will never occur!

3. In production, if the functionality is JavaScript only, keep the call on the first line. Remember, it doesn’t necessarily have to be the first line in the function, but it should come as early as fits with your program logic. The concept here is this: If this part of your functionality was added with JavaScript in the first place, then a fallback is not really as necessary. In this case, having it first will just ensure random # characters don’t appear in the URL or cause the page to jump around. Obviously, provide as much error handling as needed to ensure your users aren’t left with nothing for their efforts!

Conclusion

I hope this article presented enough information for you to make the right choice when you cancel events. Remember to only use return false when you really need it, and make sure you cancel the default behavior at the right location in your callback. Always work to make your code as flexible as possible, and stop using return false!

Advertise here via BSA

Earlier this summer, we kicked off a series on MongoDB where the goal was to write a simple todo application using native MongoDB drivers and three of our favorite scripting languages.

This article is part 2 in that series, in which we write said application in Ruby.

The Interface

You can refer back to the introductory article for all the details, but I’ll reiterate the command-line interface here for easy reference:

• todo – list all incomplete tasks sorted by priority then chronologically
• todo next – list all incomplete tasks that are high priority
• todo done – list all complete tasks chronologically
• todo high “pay bills” – add high priority task called “pay bills”
• todo low “get milk” – add low priority task called “get milk”
• todo finish “pay bills” – complete task called “pay bills”
• todo dont “get milk” – delete task called “get milk”
• todo help – list all commands and their usage

Okay, let’s write this thing!

The Driver

10gen distributes the Ruby driver using Ruby’s most popular package distribution tool, RubyGems. To install the driver on your machine simply execute:

gem install mongo

Our program will need to load in the driver before anything else, and we’ll use RubyGems to do it, so create a new text file called mongo_todo.rb and begin it with the following:

require 'rubygems'
require 'mongo'

The ToDo Class

Ruby is a purely object-oriented language, so our program will employ a single object of a class we’ll write called ToDo. The class will take in the required command-line arguments, connect to the MongoDB collection that stores our todos, and execute the appropriate command on them.

To facilitate these needs, our object will need to take some arguments from the user and store a reference to the MongoDB collection when it is instantiated:

class ToDo
  def initialize(args)
    @args  = args
    @mongo = Mongo::Connection.new.db("todo").collection("todos")
  end
end

In Ruby, the initialize instance method is called when a new object of a class is instantiated, most often using the new class method, like this:

my_todo = ToDo.new

When a new ToDo object is instantiated, our class will store the arguments passed in to it in an instance variable called @args and store a connection to MongoDB in an instance variable called @mongo. Mongo::Connection is a class provided by the mongo gem that we’re using.

Since our class expects some arguments passed in to the initializer, we need to provide them to the new method. The arguments will be read in from the command-line when the program is executed, and Ruby exposes these to our program via the ARGV variable. So, we call new like this instead:

my_todo = ToDo.new(ARGV)

At this point, the entire program should look like this:

require 'rubygems'
require 'mongo'

class Todo
  def initialize(args)
    @args  = args
    @mongo = Mongo::Connection.new.db("todo").collection("todos")
  end
end

ToDo.new(ARGV)

You can execute this program from the command-line, but nothing will happen. Well, stuff will happen but you won’t see it displayed back to you. We still need to implement the bulk of the program, which parses the user’s command-line arguments and acts appropriately.

A Little Help

The first thing we’ll implement is a method that prints usage help for the program. It looks like this:

def help
  abort <<-HELP
  usage: #{__FILE__} <method>

  == Methods ==
  <none>            list all incomplete tasks sorted by priority
  help              show this help
  next              list all incomplete tasks that are high priority
  done              list all complete tasks chronologically
  high "argument"   add high priority task called argument
  low "argument"    add low priority task called argument
  finish "argument" complete task called argument
  dont "argument"   delete unfinished task called argument
  HELP
end

In Ruby, abort is a method you can call which will exit the application and display a string you pass to it. The string we’re passing in shows all the ways the program can be used, which will be displayed back to the user. This will be executed by default if the user doesn’t pass in an argument that we want to handle. More on that in the next section.

Run, Baby, Run

At some point, our application needs to run, so lets create an instance method called run which will handle the program’s flow. In this method we will determine what the user passed in from the command-line and call another method that handles the different use cases. The default action is to list all incomplete tasks, and the catch-all is to execute the help method we implemented above. Here is what run looks like:

def run
  if @args.empty?
    show :complete => false
  else
    case @args.first
    when "help"   then help
    when "high"   then add "high"
    when "low"    then add "low"
    when "next"   then show :complete => false, :level => "high"
    when "done"   then show :complete => true
    when "dont"   then complete false
    when "finish" then complete true
    else
      help
    end
  end
end

ARGV is an Array, so we can call methods like empty? and first on it. The meat of the run method is a Ruby case statement which checks if the first argument passed in by the user matches any of our predetermined keywords and calls other methods, add, show, and complete. These methods are the ones that actually interact with MongoDB and display information back to the user. We’ll implement them next.

Using Mongo

So far we’ve only dealt with setting up our class and parsing user arguments, we’ve barely even touched MongoDB! This is the meat of the application, so let’s get straight to it. First, the show method:

def show(params)
  sort = [["level", Mongo::ASCENDING], ["added", Mongo::ASCENDING]]
  @mongo.find(params, :sort => sort).each { |todo| puts "#{todo["task"]} (#{todo["level"]})" }
end

show takes a hash of params as an argument and passes that hash on directly to the mongo library’s find method, which will return an array of the found items in the collection.

We print each of the todo items returned from find along with the level of the todo. How do those items get in there in the first, place? That is up to the add method, which we will implement next.

def add(level)
  help unless @args.length == 2
  @mongo.insert "task" => @args.last, "level" => level, "complete" => false, "added" => Time.now
  puts "added #{level} level task: #{@args.last}"
end

add takes a single argument, the level of the todo to create (e.g.- “high” or “low”). It then makes sure that the user had passed in two arguments at the command line because it needs the second one for the name of the task. If not, it calls help which aborts the application.

If so, It calls Mongo’s insert method and passes it all the information to be stored in the datastore.

Finally, we need to implement the complete method, which is the most complex of the lot. Like add, it makes sure there were two command-line arguments given. Then it tries to find the todo by the “task” name. If found, it will either “finish” the task or “remove” the task depending on a boolean argument passed in. The method looks like this:

def complete(finish)
  help unless @args.length == 2
  if (document = @mongo.find_one("task" => @args.last, "complete" => false))
    if finish
      document["complete"] = Time.now
      @mongo.save(document)
      puts "finished: #{@args.last}"
    else
      @mongo.remove(document)
      puts "removed: #{@args.last}"
    end
  else
    puts "No ToDo matching #{@args.length} found"
  end
end

The mongo-related calls in the complete method are find_one, save, and remove.

Finishing Up

So, we’ve written our run method which calls the other methods using the user’s passed in arguments. Now all we have to do to get the class going is finish the program by creating a ToDo class object and calling run on it, like this:

ToDo.new(ARGV).run

You can view/download the program in its entirety here. One thing to note is how little code is needed to add CRUD to an application when using MongoDB as a datastore.

Hopefully this article has helped you with Ruby or MongoDB or both. Stay tuned for our next article in the series when we write the exact same application in PHP!

Advertise here via BSA

A few weeks ago, I tweeted:

General service announcement: it is written “jQuery” not “Jquery” or “JQuery”… even if it comes first in a sentence!!!! ∞

Then Saturday I put out a stronger tweet, and caught some stronger feedback for it:

Test: “If you want jQuery help, which misspelling will greatly hurt your chances: a) Jquery b) JQuery c) jquery d) All of the above. ∞

At the end of the day, does it really matter how someone writes the name “jQuery”? Does it make them a better or worse programmer based on how they type it out?

Let me clarify that I have never failed to answer a question on Stack Overflow (Where I like to hang out and answer jQuery questions) because the asker typed jQuery with incorrect capitalization. I would never fail to respond to an email because the asker wrote it as Jquery or JQuery. I would hate to be that petty an individual, and I think that is the feeling some people were picking up from my tweets.

However, I can say I notice it and it bothers me when people seeking help don’t type out the library name correctly. It really is a small thing, and maybe it shouldn’t bother me, but it does. It got me thinking about things that might negatively affect a request for help, and I came up with a list of six suggestions. I hope these suggestions are helpful when you need to ask for help with open source software.

Asking for Help

If you need help with an open source project, you will often be dealing with people that 1) don’t have a lot of time and 2) must use the time they have wisely. With that in mind, here are few suggestions that might help you get answers easier:

1. Take the time to make sure your question makes sense. Complete sentences, clear code examples, and links to a page demonstrating the problem all go a long way in ensuring a quality answer.
2. Run spell-check before sending your question. There are at least two reasons there would be a lot of spelling errors in a question: 1) English is not the native tongue of the person requesting help 2) The person requesting help didn’t take the time ensure a quality question. Most applications have spell check. If they don’t, you can copy and paste your question to an application that does have spell check. Reason #1 is understandable and should be overlooked; reason #2 is what will stand out most to someone reading your question. It may affect that person’s decision to answer you.
3. Getting back to my original statement regarding Jquery, JQuery and jquery. Some libraries have really weird spelling or capitalizations, some are more straight forward. Write the library/plugin name correctly when asking for help with it! jQuery should be very easy, but so many people get it wrong. It is like the names iPad and iPhone: the first letter is lowercase! For another example, the popular blogging platform is WordPress, not Wordpress or Word Press.
4. At the very least, run a Google/Yahoo/Bing search (pick one) with some of the words from the question you plan on asking. I almost always take time to run a few searches to answer a question myself before asking on Stack Overflow or emailing someone for help. It is just common courtesy to spend some of your time before asking for the time of someone else.
5. If you find the answer yourself after asking for help, be sure to let the person know you no longer need their help. Sometimes emails will sit around until there is time to answer them while in the mean time you find the answer somewhere else. It might reduce your chance of getting future emails answered if the person who takes the time to answer your question finds out they wasted their time.
6. Be respectful and kind. If an open source project is screwing up your project, you have a few choices 1) use a different project 2) pay for help 3) Ask kindly for help from the project. Notice I didn’t put “4) Demand help for free.” On a very positive note, I have to say every request I have gotten for help on the few small projects I maintain have been both respectful and kind. This is really important!

What It All Means

The bottom line is this: If it appears to someone reading your question that you have not put any time into either solving the problem yourself or writing a decent request for help, they will be less likely to put any time into answering it.

Remember, it isn’t always about just getting an answer. Sometimes its about getting the right person to answer your question. For instance, there are tons of programmers answering questions on Stack Overflow, but not all of them have equal qualifications and skill. Put in the effort up front when asking the question. It will be worth it when you get a solid answer!

Do you have any tips to add? If so, please let me know about them in the comments!

Advertise here via BSA

MongoDB is an open-source, document-based datastore that has been gaining traction with developers lately. Its popularity is most likely due to the “middle ground” it provides between relational databases like MySQL and key-value stores like Redis.

We’ve found the datastore a joy to use and wanted to feature it somehow on FYC. However, there are many, many introductory articles and getting started tutorials for MongoDB (also the information on the project’s website is spectacular), so we would be remiss to provide yet another basic intro.

Instead, we decided to highlight how the datastore is used from a few popular dynamic languages. 10gen – MongoDB’s creator – provides many official client drivers (libraries) and the open-source community has produced a handful of libraries as well. We couldn’t feature them all, so we chose three favorites – Ruby, Python, and PHP – to include in the series.

The Plot

Many demonstrations use throwaway “Hello World” type programs. We thought it would be much cooler to write something that we can actually use, build upon, and maybe derive some value from. With that in mind, we tried to think of an application that had the following characteristics:

1. Real-world use case
2. Few lines of code (~ 100)
3. Simple to understand and implement
4. No 3rd party libraries or frameworks
5. Demonstrate the basic CRUD operations

For better or worse, we chose to write a command-line todo list app as it fit the requirements well.

The Spec

Our todo application is invoked from the command-line and works as follows:

• todo – list all incomplete tasks sorted by priority then chronologically
• todo next – list all incomplete tasks that are high priority
• todo done – list all complete tasks chronologically
• todo high “pay bills” – add high priority task called “pay bills”
• todo low “get milk” – add low priority task called “get milk”
• todo finish “pay bills” – complete task called “pay bills”
• todo dont “get milk” – delete task called “get milk”
• todo help – list all commands and their usage

The only requirement outside of the user interface outlined above is that MongoDB be used to persist the todo list.

The Setup

An identical application will be written in Ruby, Python, and PHP using the official MongoDB drivers. Each language will get its own article in the series. You have the application requirements so feel free to code along in your language of choice. Also, we’d love to see versions in some other languages that we won’t be covering. Show us your skills by submitting them in the comments. We’ll happily tweet them out and link them up in our final article in the series!

Be sure to grab our RSS feed or follow @fuelyourcoding on Twitter so you don’t miss out as we get down & dirty with MongoDB!

Advertise here via BSA

The trouble with having over 200,000 iOS apps in the App Store is how difficult it is to find high quality apps to fit our needs. With that in mind, I have compiled this list of eight apps that I’ve found invaluable as a developer.

Without any further ado, here they are listed alphabetically:

Air Display

Price: $9.99
Type: iPad
Version: 1.0.1

Air Display lets you use your iPad as a wireless display for your Mac OS X computer. Why is this great for developers? Because we need screen real estate, baby!

Here’s a pic of Air Display in action as my 3rd monitor. The iPad monitor is perfect size for your Skype windows, API documentation, or a browser session with programming tutorials.

DomainStorm

Price: Free
Type: iPhone
Version: 1.0

When inspiration for that new web application hits you, the first (and most fun) thing to do is buy a great domain name for it.

DomainStorm is a relatively new app from Network Solutions built to help you accomplish just that. It tells you if domains are available, helps you brainstorm name ideas, lets you mark domains as favorites for later purchase, and even provides you WHOIS information so you can contact current domain owners about a purchase. A must have for sure!

Ego

Price: $1.99, $4.99
Type: iPhone, iPad
Version: 2.1

Obsessed with checking your site analytics? There is no better way to get a quick glance at your traffic than the beautifully designed Ego by Garrett Murray.

With support for Google Analytics, Ember, FeedBurner, Twitter, Mint, Vimeo, Tumblr, and SquareSpace this app has your analytics needs covered. Did I mention it was beautifully designed?

Evernote

Price: Free
Type: Universal
Version: 3.3.5

Evernote is a wonderful way to store all the programming tips, tricks, tutorials and gotchas that we accumulate as we go about our development efforts. The power of Evernote is the universal access to your notes that it provides. They have a web interface, Mac/Windows clients, and mobile apps including a highly polished iOS app.

If you haven’t tried Evernote yet, now is a great time to put all your notes in one highly accessible place. You can even save passwords in Evernote as they provide encrypted strings inside your notes.

iOctocat

Price: $4.99
Type: iPhone
Version: 1.7.1.1

iOctocat is, hands down, the best way to keep up to snuff with open-source development on GitHub from your iPhone.

This app features access to your personal news feed, repositories, individual commits, issues, user profiles and site search. While the app is not free as in beer, it is free as in speech and the source is aptly hosted on GitHub. That makes it a great candidate for learning iOS development as well!

iSSH

Price: $9.99
Type: Universal
Version: 4.2.5

Most developers have found themselves AFK when a very important server is having problems. If you know the feeling, then iSSH is your new best friend.

There are a few remote server control iOS apps available, but this one is the best one that I’ve come across. It allows SSH, telnet, and even VNC connections and boasts many features. The iPad version provides a display size large enough to allow determined coders like myself to fire up vim and get some coding done. The price is a bit steep, but if iSSH saves your butt one time then it has already earned its keep.

iStat

Price: $0.99
Type: iPhone
Version: 1.2

Bjango makes gorgeous and useful software including the OS X system monitoring tool iStat Menus. They also offer a similar app called iStat which displays your iPhone’s system stats.

The beauty of the iStat app for developers is that you can also use it to monitor remote servers running Mac, Linux or Solaris! You simply install a daemon on the server you need monitoring and iStat will show you its CPU, memory, disk, temps, uptime, and tons more information. It feels great to have intimate details about your servers always at your fingertips.

Nezumi

Price: $4.99
Type: iPhone
Version: 1.2

This one is specific to Ruby-using web developers. For those who fit that description, you absolutely need to try deploying an application to Heroku. It is the dead simplest way to get deployed and if you haven’t tried it yet then you don’t know what you’re missing out on.

For those who’ve seen the Heroku light, Nezumi is a must-have companion app for the Heroku service. Nezumi gives you instant access to your Heroku apps from your iPhone so you can add collaborators, manage your dynos, toggle maintenance mode, execute rake/console tasks, and even restart your application on the go. Love it!

So there you have ‘em. Eight great iOS apps for developers. Hopefully you’ll find that one or more of these apps helps you increase your productivity as a developer. I know I’m better off with them than I was without.

If you know of any other iOS apps that did not make my list, please give them a shout out in the comments, so we can all check them out!