Tardate 11.2

Amplifying Human Emotion

2013-03-17T23:48:00.001+08:00

(blogarhythm ~ Sweet Emotion 相川七瀬)

It all comes back to connectivity. Om Malik (TWiST #327 @00:37:30) has a brilliant characterization of the true impact of the internet:

human emotion amplified at network scale

Rolling the Mega API with Ruby

2013-03-10T13:08:00.000+08:00

(blogarhythm ~ Can you keep a secret? - 宇多田ヒカル)

Megar (“megaargh!” in pirate-speak) is a Ruby wrapper and command-line client for the Mega API.

In the current release (gem version 0.0.3), it has coverage of the basic file/folder operations: connect, get file/folder listings and details, upload and download files. You can use it directly in Ruby with what I hope you'll find is a very sane API, but it also sports a basic command-line mode for simple listing, upload and download tasks.

If you are interested in hacking around with Mega, and prefer to do it in Ruby, give it a go! Like this:

# do a complete folder/file listing
session = Megar::Session.new(email: 'my@email.com', password: 'my_password')
session.folders.each do |folder|
  folder.files.each do |file|
    puts file.name
  end
end
# upload a file
file_handle = '../my_files/was_called_this.mp3'
session.files.create( name: 'First.mp3', body: file_handle )

Or from the command line:

$ megar -e my@email.com -p my_password ls
$ megar -e my@email.com -p my_password put *.pdf

I would still call it "experimental" at this stage because it needs more widespread hammering, and of course the Mega API is not fully documented yet. There are many more features of the API that it would be good to support, and I'd love for others to pitch in and help - go fork it on github!

I was keen to get a Mega account and check it out when the launch publicity hit, and was immediately impressed by the web interface. Very slick. Notwithstanding some of the intense analysis and some criticism (for example by SpiderOak and Security Now), the "trust no-one" design approach is very interesting to contemplate and hack around with.

The Mega API is still evolving. The documentation is thin and the main resource we have to work with is the Javascript reference implementation that actually runs the Mega site. But there has been quite a bit of work in the community to hack on the API - particularly in Python (with API analysis and projects like mega.py).

It didn't take me long to realise there was nothing much going on with Ruby. After a bit of messing around, I think the main reason for that is the pretty wretched state of cryptographic support in Ruby. Unlike Python (which has PyCrypto amongst others I'm sure), in Ruby we still on the whole get by with thin wrappers on OpenSSL that look and smell distinctly C-dy. But that's a challenge for another day...

For now I'm pretty happy that Megar has all the main crypto challenges solved (after a bit of low-level reverse engineering supported by a healthy dose of TDD). Now I wonder what I'm going to use it for?

Easy Mandrill inbound email and webhook handling with Rails

2013-02-16T00:54:00.000+08:00

(blogarhythm ~ Psycho Monkey - Joe Satriani)

Mandrill is the transactional email service by the same folks who do MailChimp, and I've been pretty impressed with it. For SMTP mail delivery it just works great, but where it really shines is inbound mail handling and the range of event triggers you can feed into to your application as webhooks (for example, to notify on email link clicks or bounces).

The API is very nice to use, but in a Rails application it's best to keep all the crufty details encapsulated and hidden away, right? That's what the mandrill-rails gem aims to do - make supporting Mandrill web hooks and inbound email as easy and Rails-native as possible.

I recently added some new methods to mandrill-rails to provide explicit support for inbound mail attachments (in the 0.0.3 version of the gem).

With the mandrill-rails gem installed, we simply define the routes to our webhook receiver (in this example an 'inbox' controller):

resource :inbox, :controller => 'inbox', :only => [:show,:create]

And then in the controller we provide handler implementations for any of the 9 event types we wish to consume. Here's how we might get started handling inbound email, including pulling out the attachments:

class InboxController < ApplicationController
  include Mandrill::Rails::WebHookProcessor

  # Defines our handler for the "inbound" event type. 
  # This gets called for every inbound event sent from Mandrill.  
  def handle_inbound(event_payload)
    [... do something with the event_payload here, 
         or stuff it on a background queue for later ... ]
    if attachments = event_payload.attachments.presence
      # yes, we have at least 1 attachment. Let's examine the first:
      a1 = attachments.first
      a1.name # => e.g. 'sample.pdf'
      a1.type # => e.g. 'application/pdf'
      a1.content
      # => this is the raw content provided by Mandrill, 
      #    and will be base64-encoded if not plain text
      # e.g. 'JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvY ... (etc)'
      a1.decoded_content
      # => this is the content decoded by Mandrill::Rails, 
      #    ready to be written as a File or whatever
      # e.g. '%PDF-1.3\n%\xC4\xE5 ... (etc)'
    end
  end

end

That's nice and easy, yes? See the Mandrill::Rails Cookbook for more tips.

If you love playing with transactional mail and haven't tried Mandrill yet, it's well worth a look!

Designing for Interesting Moments

2013-01-12T23:57:00.002+08:00

(blogarhythm ~ Moments Not Words - F.I.B)

Some deep thinking and analysis of how to design for interesting and effective interactions..

Designing for Interesting Moments

View more documents from Bill Scott.

2013: Time for web development to have its VB3 moment

2013-01-12T21:41:00.001+08:00

(blogarhythm ~ Come Around Again - JET)

And that's a compliment!

Wow. This year we mark the 20th anniversary of the Visual Basic 3.0 launch way back in 1993.

It's easy to forget the pivotal role it played in revolutionizing how we built software. No matter what you think of Microsoft, one can't deny the impact it had at the time. Along with other products such as PowerBuilder and Borland Delphi, we started to see long-promised advances in software development (as pioneered by Smalltalk) become mainstream reality:

finally, Rapid Application Development that really was rapid
simplicity that put the development of non-trivial applications within the realm of the average computer user. It made simple things simple and complex things possible (to borrow from Alan Kay)
development environments that finally did the obvious: want to build a graphical user interface? Then build it graphically (i.e. WYSIWYG), and build a complete client or client-server app from a single IDE.
an event-driven programming model that explicitly linked code to the user-facing triggers and views (like buttons and tables)
perhaps the first mainstream example of a viable software component reuse mechanism (improved and rebranded many times over time: ActiveX, COM, .NET)

In its day, Visual Basic 3.0 was variously lauded (by non-programmers who could finally make the app they always wanted) and loathed (by IT professionals shocked at the prospect of ceding control to the great unwashed). Interestingly, Visual Basic succeeded *despite* the language (BASIC, probably the most widely derided language of all time. Or perhaps it shares that crown with COBOL).

The party didn't last long however, as by the late 90's the internet had fundamentally changed the rules of the game.

VB, PowerBuilder and the like suffered from an implicit assumption of a client-server architecture, and were not prepared for a webified world. They didn't (all) disappear of course, with Visual Basic in particular finding a significant role as Microsoft's mainstream server-side language, and it lives on in Visual Studio. Yet it lost it's revolutionary edge, and had to be content to simply fit in as an "also can do in this language" alternative.

Web Development - a case of one step back and one step forward?

You would think that over the past 20 years, web development would have been able to leap far ahead of what was best practice in client-server computing at the time.

We have certainly come a long way since then, and many advances in practice and technology have become de rigueur. Here are some examples that would not have been considered normal by any stretch in 1993:

Reliance on open standard protocols at every tier: from client to server, server to database and messaging systems
Global, well-known repositories of shared, reusable code (Github, Rubygems .. and let's not forget grand-daddy CPAN)
Version control. There is no argument.
Automated testing tools and continuous integration.
Open source is mainstream, and even preferred in many contexts.

Yet it is also salutary to reflect on some of the great innovations we saw back in 1993 that have yet to be re-invented and re-imagined successfully for the web.

I am thinking in particular of the radical productivity that was possible with the event-driven, WYSIWYG GUI programming model. It certainly hasn't gone away (take xcode for example). But why is that not the leading way of building for the web today? After all, the web is graphical and event-driven. A perfect fit one would think.

It has perhaps been the very success of the internet, and the rapid unconstrained innovation it has enabled, that has in turn inhibited major advances in web development.

Those that have come close (such as Adobe Flash) have ultimately failed primarily because they did not embrace the open standards of the web. And others, like Microsoft Visual Studio and Oracle JDeveloper have remained locked in proprietary silos.

On the whole, we still work at levels of abstraction that are no higher, and many times lower, than those embodied by the best tools of 1993. It is, after all, very difficult to build abstractions over a foundation that is in constant flux. And with highly productive languages and frameworks at our disposal (like Ruby/Rails), it makes complete sense for many - myself included - to actively spurn graphical IDEs for the immense flexibility we get in return for working at the coding coalface.

The Tide is Turning

Once the wild west of hackety scripts and rampant browser incompatibilities, the building blocks of the web have been coalescing. HTML5, CSS3 and leading browser rendering engines are more stable, consistent and reliable than ever. Javascript is now considered a serious language, and the community has embraced higher-level APIs like jQuery and RIA frameworks such as ember.js and backbone.js. Web design patterns are more widely understood than ever, with kits like bootstrap putting reusable good practice in the hands of novices.

On the backend, our technology stacks are mature and battle-tested (LAMP, Rails). And we have an array of cloud-ready, open source solutions for just about every back-end infrastructure need you can imagine: from BigData (Hadoop, MongoDB ..) to messaging (RabbitMQ, ØMQ ..) and more.

My sense is that in the past couple of years we have been edging towards the next leap forward. Our current plateau is now well consolidated. Yet despite efforts such as codecademy to open up software coding to all, web development remains as complex as ever. To do it well, you really need to master a dizzying array of technologies and standards.

Time for Web Development to Level Up

What does the next level offer? We don't know yet, but I'd suggest the following as some of the critical concerns for next gen web development:

a unified development experience: the ability to build a full-stack application as one without the need for large conceptual and technological leaps from presentation, to business logic, to infrastructure concerns.
implicit support for distributed event handling: a conventional mechanism for events raised on a client or server to be consumed by another client or server.
event-driven GUI development: draw a web page as you want it to be presented, hook up events and data sources.
it is mobile: more than just responsive web design. Explicit suport for presenting appropriately on the full range of desktop, tablet and mobile devices
distributed data synchronisation: whether data is used live on a web page, stored for HTML5 offline, or synchronized with a native mobile application, our tools know how to distribute and synchronize updates.
(ideally) let's not have to go back to square one and re-invent our immense investments in standard libraries and reusable code (like the extensive collection of ruby gems)

Do we have the perfect solution yet? No.

But we are starting to see enticing inklings of what the future may look like. Perhaps one of the most compelling and complete visions is that provided by the meteor project. It is very close.

Will meteor streak ahead to gain massive mid-share and traction? Or will an established platform like Rails take another giant step forward? Or is there something else in the wings we don't know about yet?

It will be an interesting year. And if the signs are to be trusted, I expect we'll look back on 2013 as a tipping point in web development - its VB3 moment.

Do you think we're in for such a radical shift? Or heading in a different direction altogether? Or will inertia simply carry the status quo... I'd love to hear what others think!

How to make an eBook

2013-01-03T18:35:00.002+08:00

(blogarhythm ~ Land of a Thousand Words - Scissor Sisters)

So eBook sales have surpassed hardcover for the first time, and it is no surprise that the rise of the tablets is the main driver.

There's something quite comfortable about having a nice digital bundle of information at your fingertips, like warm buttered toast.

With relatively open standards and the ubiquity of ereaders, the ebook has become ideal packaging for all manner of information, from training manuals to open source project documentation. Or even that book that apparently 81% of us believe we have inside.

So how do you make an ebook? My first thought on searching for options is that we are pretty spoiled for choice. But there are important caveats to note, like how Apple iBooks Author can only publish in full fidelity to iTunes Book Store. And we can't get far before needing to study up on the various formats out there: EPUB is widely used, but not without its criticisms and edge-cases especially when trying to push the boundaries with multimedia and social aspects; the Kindle and other ereaders expect Mobi; and Kindle Fire introduced the KF8 format.

The good news is that producing pretty standard EPUB, Mobi, PDF and HTML variants of your book can be done very easily with a range of commercial and non-commercial tools. It's even possible to build an EPUB by hand with just a text editor if you are game.

I started to experiment with some open source toolchains to see just how well they work in practice. Personally, I'm liking the simplicity of using pandoc to build a range of output formats from markdown source files.

My experiments are in the eBook Toolchains project on github if you'd like to examine the various approaches I've tried. Have you tried something that's not there? I'd love to hear about it - comment below or better yet, send me a pull-request on the github project with your examples added!

Vale Conversations Network

2012-12-14T10:43:00.002+08:00

(blogarhythm ~ end roll 浜崎あゆみ)

So I just listened to the last IT Conversations podcast of all time All's Well That Ends Well.

I'll miss the curation they provided. Did you know that 8 out of 10 interesting facts I quote at dinner parties I learned on the network? ;-)

And still learning: IT Conversations was the 2nd podcast ever? Apparently Doug Kaye uploaded a feed the day after Dave Winer posted his first example of using the RSS enclosure tag.

I'm not sure the Conversations Network couldn't have remained relevant and valuable for years to come, but it is an admirable decision to go out on a high and close down gracefully - importantly taking the time and care to ensure that the content archives remain available indefinitely.

Building C# on MacOSX with Sublime Text

2012-10-22T21:41:00.000+08:00

It's been a while since I last cranked up mono to compile some C#, and this time I'm on a Mac.

Fortunately, no dramas. The mono team have made it a very smooth process. I simply downloaded and installed the Mono SDK (it is packaged as a standard disk image [.dmg]). That's enough to compile and run simple projects.

$ mcs hello_world.cs
$ mono hello_world.exe

There's a whole cross-platform IDE available now called MonoDevelop and it looks great if you are doing serious C#. Right now though, I was happy enough to build from the command line .. or from my favourite editor of the moment, Sublime Text.

Setting up a C# build system is trivial. From the "Tools | Build System" choose "New Build System..." option. My version simply associates with all .cs files and passes them to the mcs compiler:

{
  "cmd": ["mcs","$file"],
  "selector": "source.cs"
}

Then when you are in a C# file you can simply ⌘B to compile. Like this:

And you get a .exe that runs under mono from the bash prompt. Wild!

Blogarhythm: Because It's There - Michael Hedges #NP

The Full Monty - from Ruby to Python n00bie

2012-10-13T20:42:00.000+08:00

Ruby developers are a pretty spoilt bunch these days. The community has overall done a great job of rolling many of the advances in modern development practice into the tools and conventions we unconsciously put to work every day.

Now I wonder what life is like in the Python community? Like many Rubyists, I've played around with Python and Jython on and off. But nothing serious. And although you could get into a pedantic syntax war, I suspect for the most part the Python and Ruby communities don't overlap simply because once you dive into one camp, the only real reason you would switch to the other is because of some external driver (like a client's development standards).

It was a casual discussion about testing that re-ignited my interest in taking a peek over the fence. I picked up a copy of Greg L. Turnquist's Python Testing Cookbook and enjoyed playing around with a couple of the Python testing tools. It's an excellent book for ramping up your testing skills with Python - eminently clear and practical.

I was pretty sure that if any language community came close to matching Ruby's approach to development it would be Python. But is that true?

Most comparisons of Ruby and Python (like here, here and here) focus on language syntax and features. Conclusion?

same but different!

What I find more interesting is a comparison of the fundamental productivity patterns used in each community, assuming your goal is to produce high-quality code that can be reliably distributed or deployed, and likely makes liberal use of other - probably open source - code components.

So here is a rundown for some of the common patterns I could not do without when developing in Ruby, and what appear to be the leading Python equivalents - according to my research as of Oct-2012, but I welcome corrections and further information from any Python experts out there!

Environment Partitioning

We don't like dependencies from other projects leaking over to contaminate and confound what we are trying to work on. While you could run up a separate VM for each project, it is much better if you have tools that can keep installed libraries and even the language distributions separate for each project.

The Ruby Way: rvm is the leading tool for creating isolated ruby and gemset environments. A less intrusive alternative is rbenv (compared here).
The Python Way: virtualenv creates isolated Python environments. Ref: SO.

Dependency Management

It is likely our project will make use of other packages. We want automatic dependency management so that we can easy deploy predictable compositions of code packages.

The Ruby Way: bundler
The Python Way: pip with a requirements.txt file. Ref: SO

Reusable Code Packaging

For anything more than trivial scripts, we probably want to package our project so that it can be reliably distributed or deployed.

The Ruby Way: we use gems. Easily built by hand, or bootstrapped with a tool like bundler or jeweler
The Python Way: use setuptools (enhancements to the Python distutils) to build and distribute eggs. Ref: SO

Reusable Code Distribution

Both Ruby and Python are very open-source oriented programming communities. Not only do we consume a great deal, but it's likely we'll often want to make our own contributions easily available to others.

The Ruby Way: RubyGems for distribution, with source code most often found on github.
The Python Way: pip. And source code also seems to be showing up more on github than historical use of svn repositories. Ref: quora

Project Build Tool

We'd prefer a common approach to running project build, doc, install and test tasks rather than rolling our own for each project.

The Ruby Way: rake.
The Python Way: this one I'm not so sure of. It seems most projects simply provide a custom setup script using distutils, but there are a variety of projects that support more complex build requirements. Ref: SO

Automated Testing

It's 2012 already, we know that automated testing is a cornerstone of quality software. Especially so for code that is going to be widely shared and reused. Whether you do TDD, BDD or simply unit test, we all have a good test framework or two on our toolbelt.

The Ruby Way: Test::Unit, RSpec, Cucumber amongst others. It is extremely rare to find a project these days that doesn't have tests of some flavour.
The Python Way: unittest (sometimes called PyUnit) and doctest are common frameworks for unit testing and TDD. nose is a test runner, especially good for non-trivial projects. Lettuce is the rough Python equivalent of Cucumber. Like Ruby, there are many other projects to assist testing such as mocking tools like Mockito.
Bonus: open source projects have been rapidly adopting Travis for automated continuous integration on the back of a github commit. And it works for Ruby and Python.

Blogarhythm: Always Look On The Bright Side Of Life - Eric Idle/Monty Python

Are You Experienced?

2012-07-04T19:27:00.000+08:00

How many times have you seen a webdev job ad that asks for things like:

Minimum 5 years experience in Ruby on Rails, html5, JQuery, Mongo DB, and building andriod and iphone/ipad apps

So it just came up again on a mailing list, and we all had a good lol.

When people ask for more years experience than the technology has even existed, at one level the incongruity simply tickles our geeky funny bone like a classic joke setup.

At another level however - and one that HR professionals the world over still struggle with - specifying job requirements in terms of many years experience with a certain technology betrays a fundamental lack of understanding for what developers do. Like advertising for doctors "with 5 years experience prescribing naltrexone" - I don't think I want to be treated by one who was selected on that basis!

When when specifying technical job roles, it comes back to the key question of how do we ask: "Are you experienced?"

For some jobs, length of service with a technology is a useful indicator for hiring purposes. If we are seeking deep skills with a relatively stable body of knowledge: we want evidence that candidates have had enough time to get their green horns knocked off, learned to swim in the deep end, and pick up all those heuristic tricks they don't teach in school.

In the IT realm, these jobs tend to be those involved with more stable back-end technologies (e.g. relation databases), or developers doing application maintenance on legacy systems (e.g. 6 year old java applications used by a bank).

However, the closer you get to front-end technologies and the more dynamic your needs (read: startups), the more irrelevant - and often misleading - the "judge experience by years with a technology" rule becomes. The rate at which technologies change is just too fast. I've been doing this for many years (more than I'll admit here!), but:

I'm still learning new things every month - probably at an even faster rate than when I was a fresh grad
Half of what I learned last year is now obsolete, probably never to be called on again
I've lost count of the number of times I've developed mastery in something for 1 project, and never used it again

IMHO, the fundamental skill that great developers share is the ability to learn and assimilate. You don't want them stuck in a rut.

So how do we measure it? Rather than years of service, we need indicators of applied learning, for example:

A single significant project delivery (i.e. that goes live) is often enough to develop a good mastery of a technology
Multiple project deliveries demonstrates the ability to hone and apply that knowledge in different scenarios
Working with various technologies over time demonstrates flexibility and adaptability to the new
Founding an open source project shows that the individual not only has the creativity and inspiration to create something new, but has the tenacity to get it done (without a boss looking over their shoulder)
Contributing to an open source project demonstrates that the individual has pounded it enough to identify something that needs fixing, has had the mental firepower to figure out the root cause and how to fix it, and the collaborative skills to get the contribution merged.

So when I write a job ad for a technical role, I'd suggest defining the technical requirements along these lines:

5+ years professional web development experience
[a guide to the level of seniority within the general professional discipline]
Delivered multiple projects and current experience using: Rails 3.x, PostgreSQL 9.x, git
[the specific technical skills you expect people to have on day 1. Reference major version numbers where they represent significant evolutions of the technology, and make sure you use the correct nomenclature to avoid more lolz;-)]
Ideally, recent project experience using one of more of the following technologies: capistrano, redis, and MongoDb.
[technologies you use or are planning to use, but it won't kill you to allow the person time to get up to speed]
Experience contributing to or founding open source projects
[it's almost getting to the stage where developers really have to be quite uninterested in their career to avoid some involvement with open source projects - see comments above]

I haven't asked for all the technologies they've used in the past - assuming that this will come out when they explain exactly what they've been doing during those "5+ years professional web development".

Of course that still leaves a whole range of matters such as soft-skills and how you actually go about selling your startup vacancy. You can find this and more in the most excellent JFDI Hiring & Firing guide.

Blogarhythm: Are You Experienced? - Jimi Hendrix

gource - cool and not totally pointless

2012-05-27T09:39:00.000+08:00

Run gource on a source code repository and it animates the code's evolution. I think I first saw it used to illustrate the history of Python development since 1990, and I must admit my first reaction was cool but probably pointless.

Recently @dmm6319 ran it over our own project, and inspired me to play around a bit with it too.

So after watching our animation a few times I'm sheepishly revising my opinion of gource.

Yes, you probably need to have something invested in the particular code-base to care, and it certainly helps if you avoid the obvious cliche of using an "atmospheric" soundtrack.

But there are some real, big-picture insights that come through very clearly in the animation that you wouldn't necessarily get if you just looked at the source - for example, the shift from Cucumber to RSpec as our primary testing framework.

Blogarhythm: Asik Veysel - Joe Satriani

Rails + Ember + MongoDB + bootstrap

2012-03-19T01:00:00.001+08:00

I was fired up to try out ember.js after seeing Cameron's presentation at the last Singapore Ruby Brigade meetup.

Ember is one of the many javascript MVC frameworks that have been sprouting up over the past year, and it seems to offer a nice level of abstraction. I was quite interested to see how it might fit for a Rails/MongoDB application we're currently working on, so a few tests were in order.

I hosted some tests on a Rails 3.2.2 base, and threw in a whole bunch of technologies to see how well they play together. The story so far:

ruby 1.9.3 + rails 3.2.2 with rspec-rails and factory_girl_rails for testing
haml - templating for a pure rails alternative to compare with the ember app
mongoid - using MongoDB for server-side persistence, to see how this plays with ember
inherited_resources - for super thin controllers. Works beautifully with ember and Mongo (I literally wrote just a single line in the server-side controller
ember.js - the ember distribution...
ember-rails - makes it easy to add ember to the project (gem installed with bundler)
CoffeeScript - for the ember scripting
ember-rest - a simple RESTful resource adapter between ember and rails
twitter-bootstrap-rails - a gem packaging of twitter bootstrap (adds LESS to the asset pipeline)

Surprisingly, this all hangs together without too much fuss! You can see & fork the demo at rails-ember-mongo-bootstrap-demo.

What's next?

Testing: I've got RSpec in the project for conventional testing, but I haven't investigated the best ways to test the ember app itself yet.
Relations: perhaps switching to ember-data to test some non-trivial model associations
ember-bootstrap: adds bootstrap components to ember. Sounds promising but my initial attempts to use it weren't too successful

Blogarhythm: Remember - Jimi Hendrix

Adding Mobile Support with Web 2.0 Touch to the NoAgenda Attack Vector Dashboard

2011-11-07T22:34:00.000+08:00

The quest for an ideal javascript framework for mobile web applications has been a bit of a work-in-progress for some time (at least if you cared about cross-platform).

You might have got started (like me) with Jonathan Stark's excellent books Building iPhone Apps with HTML, CSS, and JavaScript and Building Android Apps with HTML, CSS, and JavaScript, and maybe tried the jQTouch framework that these spawned. Meanwhile, the official jQuery mobile framework has slowly been moving to fruition.

I recently discovered another project - Web 2.0 Touch - that is pitched as a mini framework with better features and more ease of use than jQTouch. Since I had a little side-project underway that could benefit from mobile support, I thought I'd give it a test drive.

And I was duly impressed. In just a few hours, I had a full and distinct mobile version of the site. Better yet, I didn't run into any weird behaviours that can plague mobile development. It just worked.

Now I'm not going to stop tracking the jQuery Mobile project or other solutions like Rhomobile, but if all you need is a quick, functional and good looking mobile view, then Web 2.0 Touch is well worth a look.

The NoAgenda Attack Vector Dashboard is the project I used Web 2.0 Touch for, and if you want to see all the intricate details of how I made the site mobile-friendly - you can! The entire site is open sourced and available on
GitHub. I'll just describe a couple of the features here...

Differentiated Views

The first has not much to do with Web 2.0 Touch per se, and is more just a demonstration of how easy it is to work with a range of view technologies in Rails.

Since the application has a very specific and rich desktop presentation, I knew the mobile version was going to be very different. Here are the desktop and mobile "home pages" side-by-side:

Rather than weigh down view code with lots of conditionals, I decided to use the MIME-type method of differentiation.

If you haven't used this before, it essentially means registering a suitable MIME-type (I called it mobile), and in the main ApplicationController, the request.format is set to this type if the client is detected to require the special mobile view. Now a request to an :index page will render with index.mobile.erb (or index.mobile.haml as is my preference), while the non-mobile view will render with index.html.erb / index.html.haml.

I've added the browser gem to the project for device identification, and for this app I've decided to only specifically handle iPhone and Android. I also don't give these phones a desktop view alternative, since I know it is not going to be nice.

# config/initializers/mime_types.rb:
Mime::Type.register_alias "text/html", :mobile

# application_controller.rb:
class ApplicationController < ActionController::Base
  before_filter { request.format = :mobile if (browser.iphone? || browser.android?) }
end

With that in place, my *.mobile.haml view and layout files just need to focus on rendering the mobile site.

Page Transitions

The jsTouch.loadPage method is used to load and navigate pages in the Web 2.0 Touch framework.

In the application, I've made this 'unobtrusive' so it might be worth pointing out what is going on. The .touch_load class is used to tag items that should initiate a page transition. The data-url and data-transition attributes tell it where to go and what transition animation to use.

.toolbar
  %h1= t('.title')
  %a.button.back.touch_load{'data-url' => menu_dashboard_path, 'data-transition' => 'pop-out' }= t(:done)
.content
  = render :partial => 'notes/table'

The enableSmartphonePageLoad function runs during page load to setup the behaviour:

  enableSmartphonePageLoad: function() {
    $('.touch_load').live('click', function() {
      var url = $(this).data('url') || $(this).attr('href');
      var transition = $(this).data('transition') || 'slide-left';
      if (url != "") {
        jsTouch.loadPage(url, { transition: transition });
      }
      return false;
    });
  },

Blogarhythm: Touch - Noiseworks

gitfall#1: Falling off a branch

2011-10-01T14:29:00.000+08:00

Ever had a merge fail with a fatal: git write-tree failed to write a tree message out of the blue?

It sounds terrifying, but when I got the root cause is quite mundane: file name conflicts in the merging commits that git is not smart enough to figure out without help. And when you fixup your merge, you are left with a commit that's lost one of its parents ("falling off a branch").

If you do much file reorganisation in a project with branches, it turns out this can be quite common (had it a few times on a recent project).

In an attempt to understand exactly what was going on, I put together the steps needed to reproduce and recover from the error. I've tidied these up and made it a full "tutorial/demo" script. You can find it in a repo called gitfalls - in the expectation that there are many more git curiosities and idiosynchrasies worth a similar treatment. Enjoy!

The script not only shows how to create the error, but two ways of resolving it and the "lost parent branch" issue:

Merge again after fixing the first failed commit. Duh!
Going a bit deeper and using git commit-tree to manufacture a new merge commit with the correct parentage

Lessons learned form all of this? Perhaps:

Avoid reorganising folder structures using folder names that once were used by files (or vice versa)
If you must do such a reorganisation, immediately merge or cherry-pick to other active branches if you can. This avoids laying a trap for a co-worker to hit later on.

Hope you enjoy the script, and if you have any others to contribute please be my guest!

Blogarhythm: Fall Out - The Police

Mikko Hyppönen@TED

2011-07-20T14:25:00.001+08:00

Doing more than just talking about viruses: he fires up a few classics in a DOS box and pokes around with a binary editor before looking at current threats and live infection data. Very cool and entertaining. Not many are brave enough to do live demos, but if you watch to the end you'll get to see how prepared he was for failure;-)

Best served with sides of:

Daniel Suarez's Daemon - for the extreme version of how bad things can go wrong,
Rebecca MacKinnon: Let's take back the Internet! - because maybe organised crime is the perfect distraction as we rush headlong to enslave ourselves to the Sovereigns of the Internet, and
Security Now! #291 - for Steve Gibson's deconstruction of stuxnet, the most spohisticated Internet-borne "weaponised payload" ever discovered... and perhaps a plausibly-deniable warning from Government(s) that "you call that a knife? THIS is a knife!"

PS: better quality vid on youtube. And yes, that is a 5 1/4" floppy.

Blogarhythm: Security - Jo Jo Zep & The Falcons

It goes PING!

2011-07-10T14:36:00.008+08:00

If you're like me, you have a bunch of trusty (and rusty) shell scripts that you reach for when doing things like testing a new load balancer.

Enough of that! igp (It goes PING!) is a simple command line utility for testing services with a range of common protocols: ICMP, UDP, TCP, HTTP/S, LDAP/S and so on.

This is nothing earth shattering I know, but it's nice to have simple cross-platform (since it's ruby) tool that does all the common protocols in one. Thankfully, most of the work has already been done by the net-ping library - igp really just provides a sleek command-line wrapper.

The only dependency is ruby+rubygems. Just:

gem install igp

And then you are ready to capture traces, for example:

igp my.server.com
#   ^ ICMP assumed by default. This is the same as:
igp icmp://my.server.com

igp http://my.insecure.server.com
igp http://my.insecure.server-hiding-on-a-funny-port.com:8080/javascripts/all.js

igp https://my.secure.server.com
igp https://my.secure.server-hiding-on-a-funny-port.com:4443

igp tcp://my.tcp-service.com:9091
igp udp://my.udp-service.com:123

igp ldap://my.insecure.ldap.server.com
igp ldaps://my.secure.ldap.server.com

Blogarhythm: Keep it Up - Snap!

Multi-tenancy with Rails

2011-04-24T14:25:00.006+08:00

RedDotRubyConf 2011 in Singapore is over. It was an amazing event (ryan takes notes so we don't have to - day#1 day#2)

Somehow I managed to cheat my way into a line-up of legendary speakers that included Matz himself. Here are the slides..

I spoke about multi-tenancy - what it is and why it's increasingly relevant for Rails development. It dives a little into four of the many approaches and ends with the challenge: Isn't it about time there was a 'Rails Way'?

Blogarhythm: So Many Ways POP DISASTER

jQuery UI AddToCalendar update

2011-03-20T11:08:00.003+08:00

Thanks to nfarina for a patch to improve compatibility with older IE versions.. jQuery UI AddToCal widget is stepped to 0.1.1 and now listed in the jQuery plugin store.

To recap .. use AddToCal if you want to offer your website visitors the ability to add any events you list or present on your site to their own calendar. It supports Google Calendar, Microsoft Live Calendar, Yahoo! Calendar, 30boxes, any iCal or vCalendar compatible desktop application (and you can extend it to support any special calendar software you might be dealing with).

See my previous post that describes how to use it in a bit more detail..

Blogarhythm: Birthday

Paranoid Yak Shaving

2011-01-30T15:30:00.000+08:00

So a few weeks ago I found myself wanting "soft-delete" in a Rails app. Ruby Toolbox is a little long in the tooth on the subject, but after a little more research I discovered xpond's paranoid project that was just what I wanted:

packaged as a gem, not a plugin

built for Rails 3 (arel-aware in particular)

can be selectively applied to your models

All was cool, except at about the same time we updated to Rails 3.0.3 and it broke (as it turned out, due to changes in AREL 2.0.6 internals).

One of the beautiful things about github and the way it's been adopted by the ruby/rails community in particular is that it makes it so damn easy to just dive in and help update code originally contributed by other people. So paranoid needs updating for Rails 3.0.3? No problem - fork it, diagnose the issue and push your fixes back up to github.

But that's also a great recipe for yak shaving ;-)

The fixes are yet to make it into the released gem, but if you desparately need 3.0.3 support you can install from my repo. i.e. in your Gemfile:

gem 'paranoid', '~> 0.0.10', :require => 'paranoid', :git => 'git://github.com/tardate/paranoid'

Blogarhythm: Paranoid (of course - but this is the bluegrass version!)

CruiseControlling Ruby 1.9.2 and Rails 3.0.2

2010-12-14T00:41:00.006+08:00

CruiseControl for Ruby from ThoughWorks has long been one of the easiest ways to your rails project under continuous integration.

But there's still an issue that it can't run under Ruby 1.9.x. That's not very good if you are targeting 1.9.2 for your project.

Here's a quick recipe for how you can build a 1.9.2 project with CC, using the wonders of rvm..

# download and unpack CC to /usr/local/cruisecontrol-1.4.0 (or where you like)
# for convenience, add .rvmrc in /usr/local/cruisecontrol-1.4.0 to have it run 1.8.7
echo "rvm 1.8.7-p302" > /usr/local/cruisecontrol-1.4.0/.rvmrc
# configure CC:
cd /usr/local/cruisecontrol-1.4.0
./cruise add my_project_name --source-control git --repository git@github.com:myname/myproject.git
# ^^ This will initialize the ~/.cruise/projects/my_project_name folder for a git-based project

# if you have an .rvmrc file in your git repo, pre-emptively trust it to avoid clogging CC:
mkdir ~/.cruise/projects/my_project_name
rvm rvmrc trust ~/.cruise/projects/my_project_name

In ~/.cruise/projects/my_project_name, edit cruise_config.rb to run a shell script instead of the standard build task (I'm calling it ccbuild.sh and it will be in the root of my git repo):

Project.configure do |project|
  # [.. other stuff ..]
  project.build_command = './ccbuild.sh'
  # [.. other stuff ..]
end

Add ccbuild.sh to your repository (don't forget to chmod u+x it). It needs to ensure rvm script is loaded and activate the correct ruby & gemset.

The script initialization is necessary because it seems the way CC spawns the shell script it doesn't pick up the rvm initialization you might already have in .bash_profile. Without rvm script initialization, "rvm" will invoke the binary which can't make the direct environment mods it needs to do.

Here's what I have in ccbuild.sh:

#!/bin/bash

if [ "$(type rvm | head -1)" != "rvm is a function" ]
then
  source ~/.rvm/scripts/rvm || exit 1
fi

if [ "$(type rvm | head -1)" != "rvm is a function" ]
then
  echo "rvm not properly installed and available"
  exit 1
fi

rvm use 1.9.2-p0@mygemsetname --create
bundle check || bundle install || exit 1
rake # setup to run all required tests by default

Once that's checked in and pushed to the repo, you can kick-off CC:


cd /usr/local/cruisecontrol-1.4.0
./cruise start

Now my ccmenu is green, and CruiseControl is running my project under 1.9.2 and rails 3.0.2;-)

Blogarhythm: Waiting for the light ART-SCHOOL

Rock till you drop.io

2010-11-06T22:14:00.012+08:00

Bombshell announcement on 29-Oct: drop.io have .. struck a deal with Facebook.

What this means is that Facebook has bought most of drop.io’s technology and assets, and Sam Lessin is moving to Facebook.

drop.io was widely acclaimed as the simple file sharing mechanisms we all needed. It resolutely solved the problem that everyone with a computer and a network connection has known at one time or another: how to share files too cumbersome for email, without resorting to techno-geekery like ftp and such. And it worked. Beautifully.

But it doesn't work anymore.

Goodbye drop.io! You were an amazing service. One of the best and brightest of the Class of Web 2.0. You made things simple. You solved a real, pressing problem.

Unfortunately, that's not what I'll remember you for now.

Instead, it will be for brewing a thunderstorm of concern over the very dependability of cloud services, as John C. Dvorak went to town on in his column.

And for teaching us that it's true - startup founders really don't give a toss for their customers if they can get a sweet deal and a plum job with one of the heavyweights instead.

And for once again propelling Facebook into the privacy-conspiracy-theory limelight. Sure, "no data will be transferred to Facebook", but they put you out of business and bought "most of [your] technology and assets", right? So will we be surprised when Facebook takes aim to lure it's unsuspecting users into sharing pretty much anything and everything - private, commercially confidential, and otherwise - using Facebook?

Well, I guess drop.io does really deserve our thanks for that last point, if anyone cares to notice.

The very best news—for anyone who can't imagine life without drop.io—is that there is another exceptional product out there called Dropbox that can handle most team sharing needs in addition to looking after your personal documents.

That's not a paid advertisement or anything. I simply use Dropbox everyday and just love it. I wouldn't be exaggerating to say it's probably improved the way I work more than anything even the folks in Redmond or Cupertino have shipped in recent memory.

Blogarhythm: Rock Rock (till you drop) .. Def Leppard

The Ultimate Steampunk Project needs $10

2010-10-30T23:59:00.001+08:00

I heard John Graham-Cumming on TWiT #269 talk about the project he has started to build - 173 years later - a full scale realization of Charles Babbage's Analytical Engine. Amazingly, it's never been done (only partial models exist).

Now, we are talking about a truck-sized, steam-powered machine that is Turing-complete and features (without silicon or electricity) "modern" ideas like instruction pipelining. The ultimate steampunk project. It also has a serious educational and academic aspect (including to digitize all of Babbage's plans and notes).

Due to significant private support coming forth, the pledge target has apparently been reduced from 50,000 to just 10,000 signatories. At the time of writing, John only needed another 6358 pledges of $10/£10/€10 each to get the project moving.

Now I don't often get behind fundraisers and campaigns, but this strikes me as one of those once-in-a-lifetime follies you cannot help but support. And all for about the price of the cheapest bottle of wine in the shop around the corner.

Blogarhythm: L.O.V.E. Machine WASP

Add to Calendar with a jQuery Widget

2010-10-03T16:35:00.002+08:00

If you deal with any kind of event-based information on your websites, you would probably really like an easy way of letting users add it to their calendar.

Unlike link sharing—where there are some great drop-in solutions like AddToAny and AddThis—calendar integration unfortunately remains a bit rough around the edges. Varying standards with varying degrees of adoption; consideration for desktop and web-based calendar clients; and the complicating factor of timezones make it all a bit harder than it really should be.

AddToCal is a jQuery UI Widget that I put together to help me solve the problem and do things like you see in the screen clip on the right. It's freely shared and available on github.

Using it on a web page is as simple as including the js links, binding it to the DOM elements or classes on your page that contain "events", and provide an implementation of the getEventDetails method that knows how to extract the event details from your particular DOM structure.

The example also demonstrates how to use AddToCal in conjunction with the hCalendar microformat for event notation (try it out here).

I've currently included support for the web-based calendars by Google, Yahoo!, and Microsoft Live. If you can serve iCal or vCalendar format event links then AddToCal also links to 30boxes and iCal/vCalendar desktop software—including the iPad Calendar application;-)

Serving iCal and vCalendar links

What about iCal and vCalendar formats? These are complicated a little because we need a URL to the respective iCal and vCalendar format resources .. so we need to be able to serve them before AddToCal can link to them.

Thankfully, this can be relatively trivial once you get a handle on the file formats. Here's an example of how to implement with Ruby on Rails.

Say we have an Events controller and associated Event model that represents an activity people may like to add to their calendars. A simple iCal implementation with ERB means creating a views/events/show.ics.erb along these lines:

BEGIN:VCALENDAR
PRODID:-//AddToCal Example//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
DTSTART:<%= @event.start_time.rfc3339 %>
DTEND:<%= @event.end_time.rfc3339 %>
LOCATION:<%= event_url( @event ) %>
SEQUENCE:0
UID:
DTSTAMP:<%= Time.zone.now.rfc3339 %>
DESCRIPTION:<%= event_url( @event ) %>\n<%= @event.full_title %>
SUMMARY:<%= @event.synopsis %>
PRIORITY:5
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

Sharp eyes will note the unusual rfc3339 helper method I've provided to make it easy to get date/times in RFC3339 format as required by the iCal and vCal standards. You could extend Time::DATE_FORMATS, but here I've simply added the method to ActiveSupport::TimeWithZone

class ActiveSupport::TimeWithZone
  def rfc3339
    utc.strftime("%Y%m%dT%H%M%SZ")
  end
end

To support vCalendar, we also implement views/events/show.vcs.erb

BEGIN:VCALENDAR
PRODID:-//AddToCal Example//EN
VERSION:1.0
BEGIN:VEVENT
SUMMARY:<%= @event.full_title %>
PRIORITY:0
CATEGORIES:SHOW
CLASS:PUBLIC
DTSTART:<%= @event.start_time.rfc3339 %>
DTEND:<%= @event.end_time.rfc3339 %>
URL:<%= event_url( @event ) %>
DESCRIPTION;ENCODING=QUOTED-PRINTABLE:<%= event_url( @event ) %> =0A<%= @event.synopsis %>
LOCATION;ENCODING=QUOTED-PRINTABLE:<%= event_url( @event ) %>
END:VEVENT
END:VCALENDAR

Depending on your Rails version and web server, you may have to teach it about these MIME types e.g. add to config/initializers/mime_types.rb:

Mime::Type.register "application/hbs-vcs, text/calendar, text/x-vcalendar", :vcs

Blogarhythm: Remember - Jimi Hendrix

12 Things Every Programmer Should Know

2010-10-03T15:10:00.000+08:00

Samnang Chhun posted his neat little presentation from BarCamp Phnom Penh 2010. It's a good summary of the leading memes of the moment..

Blogarhythm: everybody wants the same thing - scissor sisters

RFC 3339 / ISO 8601 dates in javascript

2010-10-03T14:42:00.004+08:00

Many server-side languages (e.g. Ruby and Python JSON encoders) and encoding formats like ATOM send dates in RFC 3339 / ISO 8601 format. The standard Javascript Date object cannot parse these values, which can make client-side scripting involving dates a pain.

There have been snippets of code floating around the net for ages, and various libraries that include necessary support. rfc3339date.js is my attempt at rolling the best into an standalone, unobtrusive, and open-sourced Date extension that plays well with other libraries that also extend the Date class.

It lets you do things like:

var d = Date.parse( "2010-07-20T15:00:00.333Z" );

d.toRFC3339UTCString();
=> "2010-07-20T15:00:00.333Z"

d.toRFC3339UTCString(true);
=> "20100720T150000.333Z"

d.toRFC3339LocaleString(true);
=> "20100720T230000.333+0800"  // assuming current timezone is GMT+8

The readme in the project repository on github has more information about the range of date formats supported and other methods available.

Blogarhythm: Too Many Times - Mental as Anything