Summertime by Chet Baker and co. Apologies for the corny video, but the music is beautiful.
Unbelievably, this track was recorded just a few days after the band got together. And a few days before that, one of Baker’s close friends had died of a drugs overdose. Happy days.
Since I wrote Thoughts on the iPad yesterday, that article has been getting lots of hits from people searching for “ruby on ipad” — or variations thereof.
If you’ve reached this post by searching for something similar, I’m guessing you want to do one of two things: either 1) run Ruby on an iPad, or 2) develop for the iPad using Ruby.
Never going to happen.
Like the iPod and the iPhone, the iPad is a closed system. The only near-possible way to run Ruby on an iPad would, I’m guessing, be to create an app which bundled Ruby and provided a command-line interface to it. But that’s not going to happen either. Can you imagine Apple approving an app which allowed users to run any code they liked — even within a sandbox? Neither can I.
This is less clear-cut: there’s obviously no support for Ruby in the Objective-C iPad SDK, but we do have MacRuby: “a version of Ruby 1.9, ported to run directly on top of Mac OS X core technologies”. I think the key words there are “Mac OS X technologies (my emphasis)”; Mac OS X is different to iPhone/iPad OS X, and right now there’s about as much chance of using MacRuby to develop iPad apps as there is of Bill Gates coming to work at Apple.
That might change though (the MacRuby thing, not Bill Gates) — which change would depend on MacRuby becoming a popular way to develop for the Mac. If enough developers use it, Apple may — may — decide it’s worth their time an effort to port MacRuby to their other platforms.
So, Googler: there’s some small hope.
Update: if you’re here after searching for “ruby on iPad” or similar, read this article.
Some random, contradictory thoughts triggered by Apple’s iPad event.
It’s an evolution, not a revolution. I know this is a massive oversimplification, but it’s basically a bigger iPhone. The iPhone wasn’t a bigger anything — it was the first of its kind.
That’s not to say that the iPad is anything less than the iPhone (for some people it’s going to be better: more screen space, more functionality) but it’s not a game changer.
What is it for? I’m not convinced that I need to get one of these in the same way that I was convinced I should buy an iPhone when they came out. When I saw an iPhone, I thought “holy crap, that blows my Nokia out of the water”. When I see the iPad, I think “that’s cool, but I could just buy a Macbook Air”.
I can absolutely, 100% imagine sitting in an armchair with an iPad after work and checking up on my favourite websites.
It’s a compliment to a Mac, not a replacement for one.
If the eBook features are good, Amazon will be more than a bit worried. Amazon must be more than a bit worried.
The “half-screen iPhone apps” thing is crazy — doesn’t look right. They should have run them with the desktop in the background, like widgets.
Great move releasing the SDK on day one. I wonder if Apple made a special effort to do that because of what happened with the iPhone (complaints about no SDK, jailbreaking), or just because the SDK is their now anyway (from the iPhone)?
The little home button at the bottom looks silly.
The dock looks even sillier.
If I owned one, I’d buy more books. This is why publishers should get involved.
The iBook font changer is nice, but — Times New Roman?!
It’s cool that they’re using ePub (an open format)
Even though I don’t need to, I want to use iWork on an iPad because it’s just cool that you can.
I would have preferred to be able to run more than one app at once.
Using different keyboard layouts for different tasks is a nice touch.
$30 for unlimited internet is a bargain — if you use it.
$499 is a brilliant price.
Apple was never going to live up to the hype on this.
The iPad is all about convenience.
All in all the iPad looks pretty cool — on a level with the Macbook Air, not the iPhone; a refinement of something that Apple are already offering, rather than a completely new invention.
Ever wanted to do this?
Well now you can.
Recently, I’ve been working a Ruby project for which I wanted .method style access to hash values. This was for a DSL; in my opinion, it’s sometimes better to be able to do this…
…than this:
The first looks nicer, don’t you think? Sometimes looks are important. You run the risk of confusing users (the boundaries between “real” methods and hash value accessors are blurred), but in this case users will have a very clear idea of how their hashes work, so it’s not a big problem.
So, I wrote a little gem which does the job. And it is tiny! The gem is called Superhash and it’s available on Github. Basically, what Superhash does is intercept Ruby’s method_missing and look for hash keys corresponding to the method used:
This isn’t rocket science. But sometimes it’s fun to write something simple to scratch your own itch :)
To use, just require 'superhash' and you’re good to go. No includes needed. Check out the repository on Github, and let me know if you find it useful!
When you add a new credit or debit card to a PayPal account, you need to confirm that the card belongs to you. PayPal do this by charging a small amount to your card, and asking you to confirm from your bank statement a reference number which comes with that small charge. Once confirmed, PayPal refund 100% of the small charge.
For a Visa, the small charge is £1. Let’s be charitable: I imagine PayPal refunds that money after one or two days, once a user has had time to check their bank statements (online or by phone). For those one or two days, PayPal can collect interest on your £1. Multiply this situation by a few million.
My question to PayPal: why, given that you are making money from my money while I check my bank statements, do you take £1 instead of 1p?
Filmed in London in 1965 — everyone in the audience is wearing a suit!
While my real house languishes without hot water, I’ve lit the log fire and done some work on my blog!
I’ve been wanting for a while to get Derek Powazek’s Depo-Skinny theme (which I love, and have modified quite a bit) to show excerpts instead of full posts on the home page. This was inspired by John Nunemaker’s railstips.org, which does a nice job of showing an overview of posts on the home page.
I’ve always thought that full posts on my home page is too much, because I tend to write a lot (long, boring, geeky stuff mainly — that’s boring unless you’re a Ruby or Rails developer!). Up to now, I’ve been avoiding digging into Depo-Skinny’s PHP code because, well, I don’t like PHP :)
This morning though I jumped in and spent some time writing excerpts for recent blog posts, and fixing the theme to show them on the home page (I used WordPress’s the_excerpt()). I think this is a big improvement: you can scan the home page and easily see what I’ve been writing about recently.
I’ve also replaced the old header photo with a Wordle, which is another idea I’ve stolen from elsewhere :) This time, it’s from wordpressfoundation.org which, by the way, uses a new theme called “2010″. Looks nice.
So, a little bit of redesign work and I’m much happier! Check out my home page — what do you think?
Some lessons I’ve learnt working on my latest Rails project, a piece of tidy-and-fix work on an existing Rails application. Working on this project has really taught me a lot about the right and wrong ways to use Rails.
The app that I was asked to rebuilt had no routes. Nothing.
That’s not to say that no URLs worked with the app, just that the mappings between URLs and controllers/actions was defined in the code itself — mostly using the old Rails convention:
This makes it very difficult to discover how a Rails app responds to a particular URL, without hunting through the controllers to find a corresponding action. It also makes working with REST a nightmare!
Lesson learnt: use routes.rb
Rails is all about convention over configuration, of course. But when you’re coding a Rails app — especially if you’re new to Rails — it’s easy to ignore those conventions, or just be plain unaware of them.
This leads to a lot of unnecessary work. I’ve spent a lot of time over the past few months translating unconventional code into code that more closely fits the Rails way of doing things: the result is code that’s easier to test, easier to maintain, and much, much faster.
Lesson learnt: take some time to understand Rails’ conventions
The more I write code, the more I find myself thinking: complicated code is a Bad Thing. Of course, as a kind pedant once told me, there’s a difference between complicated and complex.
(If you don’t have a dictionary handy, “complicated” roughly means messy, difficult to understand; “complex” means many interconnected parts, or a large system. The key difference is that complex systems can be well designed: complicated systems are not.)
OK, dictionary rant over :) Messy, complicated Rails applications come about when a developer doesn’t take the time to think things through. Simplicity is normally easy if you take some time to plan your work upfront — messy code happens when things are rushed or not thought through.
Lesson learnt: think before you start coding
Obvious, but very true: Ruby is important to Rails applications. If you’re new to coding, or new to Rails, then take some time to learn Ruby first: otherwise, you’ll miss out on the power (and beauty) of a great language and a great framework.
Lesson learnt: learn Ruby and Rails, not just Ruby on Rails!
Conclusions? All of the above (and more) is important when you’re developing a Rails app. And you, the developer, are important too — have fun, keep learning, and don’t work too hard. Rails should be fun :)
This tweet from Saul Kaplan got me thinking: there are really two ways of looking at passwords.
Developers, geeks, and the security conscious think like this:
I need to protect this website/application so criminals don’t steal my personal details, bank account number, or email address. I should choose something secure: preferably a random collection of letters, numbers, and symbols. Plenty of websites store passwords as plain text, too, so I should pick a password that’s unique. I won’t be able to remember it, but my browser/keychain can handle that and the website/application will be much more secure.
Ordinary users think of passwords like this:
I have to type something into this box to make the website work. I’ll type “12345″: that’s easy to remember.
This is a problem.
Most ordinary users are aware of security as a vague, secondary concern: “someone might take my credit card details” or “emails can contain bad stuff”. Most ordinary users do not see passwords as a key part of security, and even if they do, they don’t really understand the implications of choosing a bad one.
To ordinary users, a password is not a security feature: it’s a hurdle to be jumped before they can do what they want to do.
How do we combat this? I don’t know. The tough option would be to check password strength and force users to choose a strong password. In the same way that websites validate email addresses on signup forms, they could validate passwords too.
Imagine if, in HTML5, you could do this:
Where “secure” is some attribute that requires the browser to validate the strength of the password” (alert message “The password you chose is too weak: please pick another”).
I don’t know how well-recieved this would be by users. At the moment, there is a slight attempt to encourage users to understand the importance of strong passwords, but this is second- or third-hand information to most users, at best.
As developers, we have a responsibility to help users understand the importance of passwords. I do it all the time, but I’ve come to think that a simple password field (with no validations) isn’t enough. Something needs to change.