Will I still be a Rubyist in 5 years? #rdrc
(blogarhythm ~ Ruby - Kaiser Chiefs)
The third RedDotRubyConf is over, and I think it just keeps getting better! Met lots of great people, and saw so many of my Ruby heroes speak on stage. Only thing that could make it even better next year would be to get the video recording thing happening!
I had the humbling opportunity to share the stage and here are my slides. Turned out to be a reflection on whether I'd still be a Rubyist in another 5 years, and what are the external trends that might change that. Short story: Yes! Of course. I'll always think like a Rubyist even though things will probably get more polyglot. The arena of web development is perhaps the most unpredictable though.
A couple of areas I highlight that really need a bit more love include:
- There's a push on SciRuby. Analytics are no longer the esoteric domain of bioinformaticists. Coupled with Big Data (which Ruby is pretty good at), analytics are driving much of the significant innovation in things we build.
- Krypt - an effort lead by Martin Boßlet to improve the cryptographic support in Ruby. My experience building megar made it painfully obvious why we need to fix this.
Let it never be said, the romance is dead
'Cos there’s so little else occupying my head
I mentioned a few of my projects in passing. Here are the links for convenience:
- RGovData is a ruby library for really simple access to government data. It aims to make consuming government data sets a "one liner", letting you focus on what you are trying to achieve with the data, and happily ignore all the messy underlying details of transport protocols, authentication and so on.
- sps_bill_scanner is a ruby gem for converting SP Services PDF invoices into data that can be analysed with R. Only useful if you are an SP Services subscriber in Singapore, but other wise perhaps an interesting example of extracting postitional text from PDF and doing some R.
- megar ("megaargh!" in pirate-speak) is a Ruby wrapper and command-line (CLI) client for the mega.co.nz API. My example of how you *can* do funky crypto in Ruby ... it's just much harder than it should be!
read more and comment..
Amplifying Human Emotion
(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
read more and comment..
Rolling the Mega API with Ruby
(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 listingOr from the command line:
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 )
$ megar -e my@email.com -p my_password lsI 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!
$ megar -e my@email.com -p my_password put *.pdf
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?
read more and comment..
Easy Mandrill inbound email and webhook handling with Rails
(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 < ApplicationControllerThat's nice and easy, yes? See the Mandrill::Rails Cookbook for more tips.
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
If you love playing with transactional mail and haven't tried Mandrill yet, it's well worth a look!
read more and comment..