Paul Gallagher

(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?

(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

(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!

(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.

(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!

(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 TurningOnce 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 UpWhat 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!

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

Some deep thinking and analysis of how to design for interesting and effective interactions..
Designing for Interesting MomentsView more documents from Bill Scott.