TopSecretProject

Native apps aren’t just better because the technology is better, but because they are small, discrete applications, tightly focussed around a specific task or use-case.

Nowhere is this more apparent than in the media world. On the one hand we have massive, sprawling, and terribly confusing sites (like the Huffington Post) and on the other we have simple, focussed apps tasked around reading and interacting with a very specific subset of information. The New York Times actually has several specialised apps including News, Real Estate, Crosswords and Sudoku.

Some sites are already like this. Twitter is a good example … the Twitter web interface is very slick, and on the desktop is only beaten by clients with specific niche features (like Tweet-decks multiple account support for example).

It seems nearly too obvious to point out, but nearly all web-based applications (as opposed to sites) already follow this approach. The 37 Signals suite, Freckle Time Tracking, Pivotal Tracker – the list is long. When you think like an app, you behave like an app. This thinking pervades the ancillary marketing materials of these services as well. Each 37 Signals application has a dedicated website focussed on the task of selling that application.

What happens if we start applying this vision to the broader web?

Imagine … a central place to discover applications, each area of a site functioning as a standalone application, wound tightly around a single area of focus, a single task, a single use-case.

Many small pieces, tightly focussed, loosely connected.

And a small note while I am here: native apps are in general better at the current stage of our technology. In general, native apps have better integration, a smoother experience. BUT … this is not a guarantee, and there are plenty of bad native apps (check the Apple App Store for thousands of examples). I am betting on HTML 5 all the way. Just so you know.

I have started using what I think is a pretty robust system for handling JavaScript in my Rails projects.

The basic process is this:

1) In order to create some modularity, each controller in my system has it’s own JS file. The controller file contains the code required for the views in that controller. I still have some higher level files for common and application-wide JS code.

2) Each of the controller files is scoped to a namespace:

//File: javascripts/controllers/dashboard.js
var dashboard = {
  init: function() {
    //kick-off code for the "dashboard" controller
  }
}

3) I have a view helper that appends a load command to the layout. Loading is a matter of calling the namespaced init method: $(document).ready(dashboard.init);

The helper looks like this:

def load_controller_script(script = controller.controller_name)     
  content_for :javascript do
    "<script type=\"text/javascript\">$(document).ready(#{script}.init);</script>".html_safe
  end    
end

And is included in my layout using: <%= raw(yield :javascript) -%>

Using “raw” because I am in Rails 3 land.

4) At deploy time I use the awesome asset_packager plugin to join all of the controller files into a single file, meaning I only have a single request for JS in my production system. The namespacing ensures that there are no conflicts across the many small files.

That’s it!

I am still investigating the most robust way to setup the namespaces. The above is simple, but not necessarily the best way to go about it.

It would be quite a simple matter to have the files be more granular – you could actually tie them to specific actions in your system. Controller is fine for my use-case as this particular app is very JS-centric and builds actions and views using AJAX and JS in the browser (so a lot of my actions return JSON rather than HTML).

In my current project I have developed a light-weight tag library based on Radius Tags. I am using TinyMCE as my WYSIWYG editor and needed to handle these custom tags in an intuitive fashion. In this case, I am happy for the user to have to manually edit the code in the HTML view to interact with the tags, but I want to at least let them know the tag is there.

Assuming we have a tag: <o:title/>

I simply add the following to my TinyMCE configuration:

extended_valid_elements : "o:title",
custom_elements: "o:title"

extended_valid_elements tells the editor that this tag is valid.

custom_elements makes TinyMCE switch the tag into a div when in the WYSIWYG view. The div has a “mce_name” attribute with the value of the tag name (in this case mce_name=”o:title”).

With the tag being handled by TinyMCE, I can now customise the display by providing some styles in the Editor CSS.

You can assign a generic div style:

div[mce_name] {
  background-color:#EEEEEE;
  border:1px solid #CCCCCC;
  height:225px;
  width:600px;
}

As well as specific styles for a named tag (in this case  using a background image to render the display):

div[mce_name="o:title"] {
  background-image:url(/images/title_tag.png);
  background-repeat:no-repeat;
  background-position:2px 5px;
}

Easy!

The speakers for Ignite Melbourne have been announced.

I will be presenting this year on the topic “Things I have learned from a lifetime of failure”.

Going to be an excellent evening.

Busy times recently as I have two sites launched in the last week.

Lucky for me one of the sites was 10 Tips to Stress Less, full of useful advice on how to reduce stress.

The Stress Less campaign is coordinated by the Mental Health Association NSW (MHA) and has the aim of increasing community awareness of the risks of stress and providing tips and ideas on how we can all go about reducing the impact of stress in our lives.

The site is running on my own social “platform” thingy.

Stay tuned for more on this in the very near future.

The Techology

• Ruby On Rails
• Gems & Plugins:
  • asset_packager
  • acts_as_list
  • clearance
  • declarative_authorization
  • facebooker
  • formtastic
  • hoptoad_notifier
  • paperclip
  • sanitize
  • will_paginate
  • vote_fu
• rSpec, Cucumber, Selenium
• PostgreSQL
• jQuery and a range of plugins
• Facebook Connect, XFBML, FBJS
• Heroku with the RPM add-on

Things I learned:

• Facebook Connect is awesome
• Ruby on Rails continues to be awesome
• Heroku is awesome times infinity

Any sufficiently complicated website contains an ad hoc, bug-ridden, slow implementation of half of WordPress

I’ve been working on a new project for Inspire Digital.

The project is going to allow site members to produce their own content.

Members have a WYSIWYG editor (using jquery.wysiwyg) for creating content with some basic HTML. I wanted to come up with a way for only those who need the files to download the files.

Previously in this sort of situation I have simply included the script and css files within the form, but this is not valid HTML.

So … Loading Javascript and CSS dynamically with jQuery to the rescue!

Loading JavaScript is built-in to jQuery, but you need to create CSS elements yourself.

The approach places a class on the text area we want to be WYSIWYG, then we detect that class, load the CSS and JavaScript and initialise the editor. Easy!

$(document).ready( function() {
  if ($('.wysiwyg_editor')) {			
    $("head").append("<link>");
    css = $("head").children(":last");
    css.attr({ 
      rel:  "stylesheet",
      type: "text/css",
      href: "/javascripts/jwysiwyg/jquery.wysiwyg.css"
    });
    $.getScript("/javascripts/jwysiwyg/jquery.wysiwyg.js", function(){
         //wait before initialising to prevent intermittent load error		
	 setTimeout("init_wysiwyg_editor()",250); 
    });					
  }      	
}); 
function init_wysiwyg_editor() {
  $(".wysiwyg_editor").wysiwyg();
}  			

The only gotcha I found was that calling $(“.wysiwyg_editor”).wysiwyg(); would occasionally error with an undefined method unless I put a momentary timeout in before calling. I think this was the result of the browser making the call while still interpreting the freshly loaded script.

The last few weeks has been a bit of a whirlwind, but the site I have been working on since January for the Inspire Foundation is now live:

Reach Out – http://au.reachout.com/

Reach Out is a web-based service that inspires young people to help themselves through tough times, and find ways to boost their own mental health and wellbeing.
Our aim is to improve young people’s mental health and well being by building skills and providing information, support and referrals in ways we know work for young people.
Reach Out is run by the Inspire Foundation (www.inspire.org.au). Inspire’s mission is to help millions of young people lead happier lives.

All built using an agile methodology on Ruby on Rails, the framework of champions, of course.

So the Rails Maturity Model is reality.

I hate it.

I hate the actual concept of the Rails Maturity Model.

I hate it so much it’s making me think it’s time to start moving on from Rails and Ruby. Which is probably a slight over-reaction on my part, but anyway.

At best I think RMM is a marketing exercise for certain Rails consultancies.

At worst it fosters a myopic vision of Best Practice founded in the worst kind of Group Think.

As Yehuda Katz posted:

It makes perfect sense to create a forum for sharing and aggregating the practices that people are finding useful at the moment. What makes less sense is creating a ranked list of “popular” practices, with no obvious mechanism for mediating differences except pure popularity. And even worse is ranking firms by their aggregate level of conformance.
(see Incentivizing Innovation for more).

This is really the at the heart of the  problem. It’s not that we’re against a forum for sharing practice and process, but the moment we start rating and ranking organisations we are engaging in the worst kind of group think that many of us are trying desperately to avoid.

If I wanted this sort of Best Practice, I would have stayed in the Java world …

What happens when you disagree with a number of the current  practices that are make up the RMM?

What happens in the case where you have a different development philosophy?

There is no capacity for dissent in the current vision of RMM.

Full disclosure – I really saw red when I saw one of the RMM practices is “Haml for templates”. Genshi is beautiful. ERB is adequate. Haml is clumsy, brutal, ugly, wrong and demonstrably fucked.

The executive summary:

Twitter prefer Scala rather than Ruby  for some back-end processes.
Fun ensues

Some of the Twitter developers were recently intervied by Bill Veners on Scala: Twitter on Scala

Which seemed to raise the ire of many of the Ruby crowd in the infosphere. The fact that Twitterer(?) Alex Payne has a new Scala book smells of vested interest to many.

As Payne posted in Mending The Bitter Absence of Reasoned Technical Discussion:

the story … had gone from “Scala is a nifty language and you should think about it for your business to “Twitter engineer spits on the grave of Ruby, exalts Scala as shining new deity”

Tony Arcieri (REIA, Erlang) has a really great analysis of message queues and Ruby – the best part is some of the implicated Twitter developers address his points in the comments. The team evaulated various message queues and went with their own implementation (a Scala-based app called Kestrel).

The Twitter guys know their code, know their environment. They have tried a bunch of technologies, and have developed something that works for them.

However, it’s comments like this from the interview that really pique my interest:

I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.

Jeremy McAnally summed up my own thoughts on Twitter:

If you have to use kind_of? all over your code to mimic a “type system,” you’re doing it wrong.

Twitter: you’re doing it wrong!

I realise that I have no real right to be calling Twitter out here as my credentials with regards to developing the next big thing with a growth curve that is a straight line all the way up to world domination are currently nil.

But the secret truth of most large software projects is that the code often sucks.

See the Big Ball of Mud for more details.

So given Twitter’s code probably sucks, and your code probably sucks, and my code definitely sucks, what can we do?

I guess we assume they picked the right tool to make some of their code suck a little less.

Well done Twitter.

My takeaways:

The Rubyists are a pretty defensive group. I love Ruby and Rails. but still, I am hopefully not a member of the “cult”.

The JVM is just about the best platform there is for high-scalability. Not Java itself as such, but the JVM. I am fairly certain the future is going to be languages running on the JVM. I think Clojure is interesting for this reason – although Scala may be good middle ground as a future-proof language option. Lisps have a long history of being the best lanaguage ever that never made it to the mainstream.

Afterthought:

One other thing I do find very curious is that given the code-compile-deploy cycle still required by Scala is how it can really be as fast to develop in as Ruby or Python? During my time as a Java Developer, it was this cycle that was the real time killer. On any non-trival project the compile cycle will start eating minutes and deployment is necessarily complicated when pushing to servers with JAR/WAR deployment systems. I can understand how this trade-off may work for infrastructure (like a message queue) where changes are slow and largely internal, but for a web-level application where change is constant, it’s going to slow you down.