the evolving ultrasaurus

the truth about mobile development

Sarah — Sun, 21 Feb 2010 16:56:26 +0000

For my talk at LA RubyConf, I decided to share some truths about mobile development, in general, rather than focusing only on how it is different with Ruby using the Rhomobile platform.

The truth is that mobile development sucks. With Ruby, sometimes it sucks less. The unavoidable problem is that at the end of the process you still need to get your app on the device using cruddy development tools reminiscent of the 1990s. I likened mobile developers to people who like to get tattooed. Perhaps some are thrilled by the painful process, but most endure it to achieve the end effect. Mobile applications are compelling, wonderful expressions of some practical problem solved that you can carry around in your pocket. Despite the often frustrating and stupid steps that I need to follow to get things done, I love what I can build as a mobile developer.

Rhomobile is steadily normalizing some of the process to smooth out the cross-platform differences using tools and techniques from Ruby, which I discussed at the end. My talk reviewed the development process backwards, starting with the user experience, reviewing what it takes to distribute the app and build it for distribution, then finally reviewing the code (posted on github). I posted links to the app for iPhone and BlackBerry.

The key point on the user experience is that mobile apps should be different on each device, but those differences should be superficial. It is essential that your app use the common UI patterns that users of that device expect, but the core of your app has to do with the problem you are solving and that should be consistent across devices. For the RubyConf app, those device-specific differences were the navigation. On iPhone, there’s a tabbar across the bottom. On Android, there is also a tabbar that has a slightly different look and is positioned across the top. On BlackBerry, these navigation options appear in a menu. The user of each device would find the navigation expected, since it is consistent with how other apps look and feel on that device. Meanwhile, most of the screens are identical across the app. I didn’t discuss the map implementation which is almost the same across devices — of course, it always looks like a map with markers, but the markers have a different visual representation and the pan/zoom controls are different.

The other point about user experience, which is not expressed by the RubyConf app, since it is really a work-in-progress, is that your branding should be consistent across platforms. Mobile apps have more in common with web applications than they do with desktop applications. On the web, your brand is integrated into your application UI. I expect that to be the common pattern for mobile applications as well.

The process of building, signing and distributing the app is quite different cross-platform. It is really hard without actually doing it to get a feel for what it takes and how long it takes to do this on each platform. The documentation is scattered and hard to follow even for a single vendor. One of the goals of my upcoming book is to pull together this information and help people understand what is common across platforms and what is consistent. In this talk, I gave a lightning-speed overview of the process on iPhone, BlackBerry and Android.

The slides for the talk don’t really stand alone, but I am posting them here for reference:

Mobile Ruby, LA RubyConf

View more presentations from Sarah Allen.

agile development in action

Sarah — Sat, 06 Feb 2010 17:41:30 +0000

I don’t know who first said that if you aren’t embarrassed about your v1 product, you waited too long to ship. At Mightyverse, we repeated that to ourselves as we struggled to release the first version of our iPhone app. After 2 weeks, we hit 128 downloads and I enjoyed reading my co-founder, Paul Lundahl’s reflection on the process. Despite our misgivings, we continue to explore the painful edge of what may not yet be a minimally viable product.

Why do I persist in this belief that we are pursuing the right methodology when the release of this marginally useful app means that many early users may be frustrated and never come back?

A mobile startup without a mobile app hasn’t reached the starting gate. At least now, we have a demo that anyone can see. No matter how many times I tell people that Mightyverse allows you to access native language video recordings, when I show the app half the people say “oh, so you are using video!” When you are introducing a new concept, people only hear half of what you say. Even when we speak the same native language, communication is hard.
We are learning a lot from the app and the process. Now we know that we can get through the Apple App Store process. We understand the limitations of the iPhone video APIs. With a version of the iPhone app released we can consider whether another platform will allow us to create a better user experience, while still leveraging our early iPhone work to maintaining a presence on that platform.
This open approach allows us to move more quickly toward our goals than traditional methodologies. Even if we are a bit embarrassed, we are also very excited. We are learning how to work together effectively to balance content and software development. We know that our 23,721 video recordings represent just a droplet of language and our software does not yet provide features which support any use case particularly well. Working in collaboration with language enthusiasts and other early adopters we have developed a process of continuous course corrections.
Having an audience leads us to make hard decisions quickly and perform crisply. Since the audience is small, we are comfortable experimenting and allowing forward motion with a post-hoc review process. Moving quickly unleashes creativity. The process is inexplicably fun.
Lastly, I expect that the people who will discover Mightyverse in the future will vastly outnumber the people who will use it now, so I am ok risking their displeasure. In fact, if we actually manage to stumble upon some people who hate it, perhaps that is an opportunity.

So, if you have an iPhone, download the app, join our experiment, and let us know what you think. After all, where else can you learn to say “I’m sorry. I speak the Japanese of a pre-schooler” ?

rails security review checklist

Sarah — Wed, 27 Jan 2010 08:00:12 +0000

I’m reviewing the security of a web app built with Ruby on Rails, so I put together a checklist for a security audit. This isn’t a bank or high security situation, but there were a number of engineers and quite a bit of open source code, so I thought a few checks were in order.

Here’s the list I came up with that I thought other folks might appreciate as a starting point (special thanks to the sfruby list, Mike Gunderloy, and Scott Bronson for feedback):

0) Make sure your Rails and gems are up to date for latest security patches (see rails security mailing list for recent advisory notes)

1) Active Record audit:
  A) SQL injection:
    (i) whole word search for “find”, “first”, and “all” then visually inspect all instances of ActiveRecord find calls for potential SQL injection vulnerability (also search for “sql” not whole work search to find find_by_sql and “execute” to find cases where raw sql is executed.
    (ii) search your models for “named_scope” and check :conditions
  B) check for mass assignment Either disable mass assignment as Eric suggests in his article, or audit its use. If doing an audit, check every model to make sure it declares which attributes are settable with attr_accessible. (While attr_protected may technically work, a white list approach is recommended by security experts and the rails security advisory on this topic)

2) Scripting attack: search all eRB files for <%= and ensure that if dynamically generated text was originally entered by the user, it is HTML escaped. Consider rails_xss

3) Secure Access: If some of the site does not have public access, check controllers and ensure that public actions are specifically allowed and that protected access is the default

4) search for “eval” (whole word) and verify that usages are safe (assume javascript eval is ok)

5) search for “forgery” (not whole word), make sure that
config.action_controller.allow_forgery_protection = false
is only disabled in test config
protect_from_forgery should be in the ApplicationController, unless there is a good reason for it not to be

6) check user auth and review that controller actions are limited to expected use

7) passwords: not saved as clear-text in the db, not logged

8) check that private data is not stored in cookies

must we be arrogant jerks?

Sarah — Sun, 17 Jan 2010 04:13:03 +0000

Much of Clay Shirky’s recent rant about women rang true to me. However, it took me much of the day, including talking with my friend Val Liberty to figure out what felt off about his rant. Over a whole day of dog walking, chatting over coffee and monopoly with the kids, we spent about 5 minutes talking about Clay’s post, but our talk colored my thinking about it. We covered gender issues, success, humility, and diversity, along with tech talk and business plans.

I know there are many paths to success. I routinely meet and do business with successful people who value integrity and honest communication. Peldi Guilizzoni, founder and CEO of Balsamiq, has recently modeled how to become a huge success while being a genuinely nice guy (and perhaps partly because of it). I know many other folks who have taken similar paths to success, though I don’t know anyone else who has documented it as thoroughly.

You don’t need to be an arrogant jerk to be confident. It is not lying to state what you believe you can do, instead of merely what you have done in the past. Clay Shirky clearly states the issue in the middle of his rant:

…people who don’t raise their hands don’t get called on, and people who raise their hands timidly get called on less. Some of this is because assertive people get noticed more easily, but some of it is because raising your hand is itself a high-cost signal that you are willing to risk public failure in order to try something.

However, he follows that by saying that it is a false hope “to imagine that women could be forceful and self-confident without being arrogant or jerky.” I disagree. Sure we have to risk being perceived as arrogant jerks (or some less pretty name). Perception is seldom reality, and the reality we live rarely matches that of our male peers. We have to put up with being criticized as emotional when our colleagues are admired for their passion. Nevertheless, we share the world and we need to figure this out. We have to work together with our non-sexist peers to change what is acceptable… both by changing what people are used to seeing and hearing from women AND by modeling other ways to become successful.

how to look for a job

Sarah — Sat, 09 Jan 2010 23:47:16 +0000

I recently gave the following advice about looking for a job. I thought maybe other folks would find it useful. It’s kind of a next generation job search, it’s an expansion of what Ted Leung called Job Search 2.0.

Write down your ideal job, then take a serious look at yourself and think whether you would hire yourself for it. If not, what skills do you need to develop that would make you the ideal candidate for that job?
Write down a list of 5-10 companies you would love to work at. I would argue that you don’t know if you would love to work there until you have had a genuine conversation with someone who works there or who has worked there recently. If you don’t know 5 companies where you would love to work, then find them.
Write in your blog* at least once a week about something in your field that would be interesting to a potential colleague at your dream company.
Figure out what are the relevant conference, local meetups or whatever for your target job. Start attending those. Consider whether you could propose giving a talk. If you don’t feel qualified, what can you do to while unemployed that would qualify you to give such a talk? Do it.
Tweet each blog post and about web articles you read in your field that are interesting.
Consider volunteering doing something altruistic that hones the skills required for your dream job.

Be active in your field even if you don’t have a job. If you keep honing your skills and your ability to communicate about them, two things will happen:

You will know better what you want to do and who you want to do it with
Yur job will find you

If you don’t have a blog, start one

You have something to say that no one else is saying. Even if there is some repetition with what other people have said, that is ok. I’m sure my blog is mediocre at times, but it is often excellent, and sometimes I don’t know when I write something whether it is old hat or new insight… sometimes it seems old to me since the idea has been rattling around my head for a while, but everyone else thinks it is amazing…. sometimes I think it is amazing, and everyone else ignores it. Writing a blog has helped me figure out what I am passionate about.

In any case, your blog tells a public story about you and when you are seeking a job that is really important. Also, there are less experienced people in your field who might really find what you have to say helpful. It is both marketing and a public service. Over time, google will find your resume more often on the front page of searches, and over time people reading your blog will think…. maybe this person is a fit for this position that has just gotten approved, maybe I should call him or her before I post the job.

Start by just writing a little bit about interesting stuff you’ve read. Linking to other people’s writing on the Web invites them to read what you write (if they are following their referrers as most people do). Some of those people will like your blog and come back or tell their friends or tweet about it. Eventually you will have a small following of people in your field who are interested in the same things you are. That is unique, compelling and powerful.

markdown to textile with vim regex

Sarah — Wed, 30 Dec 2009 08:36:20 +0000

So, I needed to change markdown to textile and google didn’t yield any handy scripts, so I sharpened my vim fu with Rubular, my favorite regular expression tester and came up with a few substitutions that took care of everything but lists and code blocks.

In vi, type ESC to go into command mode, then :%s/one/two/g will find every instance of “one” and replace it with “two”

First the easy stuff, headers. ^ finds the beginning of the line.

:%s/^# /h1. /g
:%s/^## /h2. /g
:%s/^### /h3. /g

To replace images, I needed to replace ![alt-text](link) with !link! so I needed to capture text. I suppose I didn’t really need the first capture, but I was working on the replace expression for a regular link when I realized it would be easier to do the images first. To understand the expression below, you need to know that $stuff$ captures some text which can be inserted in the replacement text with \1 and \2, etc. So to get everything between square brackets, I use [$.*$]

:%s/!\[\(.*\)](\(.*\))/!\2!/g

All of my images appeared on a single line, so I didn’t catch a potential issue in the above expression until I got to replacing text links. I needed to use a non “greedy” capture so that I wouldn’t pull in text after the link that happened to include a parenthetical comment. Normally, in reg ex I would use (.*?) but in vim I needed to write $.\{-}$ …wtf?

:%s/\[\(.*\)](\(.\{-}\))/"\1":\2/g

Special thanks to Adam Wolf’s tip via ShareGrove which helped me document these steps.

you can put VIM in a mode where the command history is just like another buffer. Not in insert mode, try q:

You should get a new buffer that you can edit with the command history in it, so “*yy would yank the current line into the system clipboard, etc.

ruby and rails classes in january

Sarah — Tue, 29 Dec 2009 06:43:42 +0000

I’ve gotten a number of requests for follow-on training in San Francisco for Rails and the Ruby language, so here are some classes coming up in January.

Ruby on Rails class

Another Ruby on Rails training at Marakana is coming up January 19-22 — the deadline for early bird discount is Dec 29. I was pleased to hear positive feedback from the test-first teaching approach:

I really love the emphasis on test driven development and the use of tests as a way to move students along in exercises. This is definitely the way to teach. I highly commend you folks for doing it. It provided instant feedback on how successful my coding was, and provided a good guideline for successful coding in my profession. — Reed College

One thing Marakana did extremely well was provide unit tests with labs. This one technique alone will now represent the standard I hold all future training courses to. It made training more than learning, it made it about problem solving. It made learning fun. — Near Infinity

Scholarship. Marakana will again be offering a scholarship spot (deadline Jan 12). If you feel that your presence will increase diversity in the Ruby on Rails community and that taking this class could have a positive impact on your life and you would not otherwise be able to afford the class, please fill out this short form. Our decision on the candidate will balance your need, how much taking this course will have a beneficial effect and your potential impact on the community. Bonus points for bloggers and twitterers or people who otherwise spread their know-how.

Ruby language class

Liah Hansen and I will be teaching a new Ruby language class which will be 6 weekly evening classes with homework assignments in between. I didn’t set up a scholarship form for the Ruby language class, since it is less expensive, but would consider an application for this class as well — just add a note to the first field in the form.

If you sign up for both classes, we’ll give you a $200 discount on the Marakana class.

Advanced Rails class

Wolfram Arnold will be teaching an advanced Rails class on Jan 25-28, the week after my introductory class. This will be a good companion to the first class or a way to sharpen your skills if you are already working with Rails.

fear stays silent while passion speaks

Sarah — Mon, 28 Dec 2009 07:43:12 +0000

Cisco CTO, Padmasree Warrior, gave a thoughtful keynote speech for the Women of Vision event. I watched part 1 in May. Reminded by Anita Borg Institute’s Year in Review, I enjoyed watching part 2 and part 3.

She titled her talk: “fear stays silent while passion speaks,” which struck me as an important way to talk about vision and about women in tech. Although I do think a certain amount of fear coupled with the courage to overcome it can sharpen an edge, too often women (and men) hold themselves back without even realizing their own power and creative force.

She also notes that work and life are always at odds. It isn’t about balance. It is about integration.

Here are five life lessons she shared:

Every transition brings a growth opportunity
an opportunity to add new skills
You can gain speed at a turn
applies to companies as well as individuals, a downturn or upturn allows us to focus
Leaders blur boundaries
You need to be able to work across functional boundaries, as well as across countries and with different kinds of people. Influencing across an industry is more important than leading a large number of people.
The best way to gain recognition is to give it away
People are often afraid of losing credit. Ideas are stronger when you share them. If you give someone credit for an idea, it is amazing how quickly they will run with it.
Opportunity is a mold waiting to be re-shaped
There is never a perfect fit for a job. We are always in a mold and it is up to us to break out of that mold. The fit doesn’t come to you, you need to work hard to make a fit.

“The CTO’s job is not to know all the answers, but to ask the right questions”

Japanese geek speak

Sarah — Sat, 26 Dec 2009 21:34:20 +0000

It was inspiring to meet Matz, the creator of the Ruby language, and other Japanese Rubyists at last month’s RubyConf. Matz kindly recorded various phrases about Ruby in Japanese . Since then I’ve been working on learning katakana as an easy intro (perhaps) to the Japanese language.

For those who are unfamiliar with Japanese, katakana is one of two phonetic scripts used in Japanese writing, along with Kanji which is the pictographic script used for the majority of Japanese words. Katakana is used mostly for words which have their roots in foreign languages, so it is naturally used for many words having to do with software development. I asked a Japanese Rubyist why is the word for “Ruby” (the programming language) not a Japanese word — even when speaking and writing Japanese the word for Ruby is “Ruby.” She replied that if they used the Japanese word, it would be indistinguishable from the word for the jewel. They can easily google for “Ruby” and find Ruby language references in Japanese text. The Japanese effectively extend their language by adopting foreign-language words for new concepts and inventions, and end up making the language more expressive by creating a larger vocabulary.

Despite the fact that many things that I might want to say as a software developer find their origins in English words, without hearing them first in isolation I would probably not understand them if I heard them. So, in addition to learning from the excellent book All About Katakana, I am also developing a list of geek words that are written in Katakana.

I’ve noticed that most of the tweets I see from Japanese Rubyists are in katakana and I wonder if I learn to read this phonetic text whether I might actually understand them now and then or perhaps the twitter stream is yet another dialect.

Below is my short list of geek vocabulary words that I am learning now (with some mightyverse links if you want to hear them). Once I get a little farther along in my studies, I hope to get my Japanese friend Iku to record more words for me, so please comment with your favorite katakana words (or ones you would like to know if you are an English speaker and I’ll add them to my translate wish list).

テスト
te su to
test

フレーム
fu rei mu
frame-

ワーク
wa ku
work

オブジェクト　　
o bu je ku to

ドット
do tsu to
(dotto)

メソッド
me so tsu do
(mesoddo)

object.method

ハッシュ
ha shu

ロケット
ro ke tto

hashrocket

テレビ
te re bi
television
(it’s for television)

creating a custom rake task

Sarah — Sun, 20 Dec 2009 17:30:51 +0000

There’s a nice Railscast introduction to rake for Rails, which goes into a number of other important details that aren’t covered in this post. Below is a little tutorial of creating a Rails rake task and getting it to run remotely on heroku.

Introduction to Rake

In lib/tasks, create a file called greet.rake

task :greet do
   puts "Hello world"
end

By naming the task .rake and putting it in this special place rails will automatically pick it up and make it available to you. You can see it listed if you type: rake -T on the command line. To run it:

rake greet

which will print “Hello world”

to run one task before another, specify a dependency like this (multiple tasks may be specified in the same file):

task :ask => :greet do
   puts "How are you?"
end

Writing a Practical Rake Task

Now for the task at hand, I’m going to create a rake task which creates a bunch of fake data for me to test with. First I’ll create a little experimental app:

rails rake_example
cd rake example
script/generate scaffold person first_name:string last_name:string
rake db:migrate

Here’s the rake task (lib/tasks/fake_people.rake):

require 'faker'

namespace :admin  do
  desc "create some fake data"
  task :fake_people => :environment do
    print "How many fake people do you want?"
    num_people = $stdin.gets.to_i
    num_people.times do
      Person.create(:first_name => Faker::Name.first_name,
                    :last_name => Faker::Name.last_name)
    end
    print "#{num_people} created.\n"
  end
end

Note that I’m using the faker gem (docs here) and I created a task dependency on loading the rails environment so I could access my Person model.

Now I can run

rake admin:fake_people

and it will prompt me to ask how many I want and then it will create them. Cool goodness, yes?

Running Remotely on Heroku

We’re not done yet. I want to deploy this on heroku and be able to run the task remotely. For this, there are two gotchas, first I can’t run an interactive script remotely; also I need to tell heroku that I am using the fake gem and make sure it is installed.

1) removing interactivity

Instead of an interactive script, we can set an environment variable or command line argument (thanks to a tip by Adam Wiggins).

My modified task looks like this:

require 'faker'

namespace :admin  do
  desc "create some fake data"
  task :fake_people => :environment do
    num_people = ENV['NUM_RECORDS'].to_i
    num_people.times do
      Person.create(:first_name => Faker::Name.first_name,
                    :last_name => Faker::Name.last_name)
    end
    print "#{num_people} created.\n"
  end
end

which I can call locally from the command line like this:

rake admin:fake_people NUM_RECORDS=1

2) adding gem to heroku

I need to create a gems manifest, which sounds fancy, but is simply creating a .gems file at the root of my app with contents similar to what I would put in my config environment.rb to specify that my app requires a gem:

faker --version ">=0.3.1"

3) Deploy and Run

So I can deploy my app to heroku with the usual steps

git init
git add .
git commit -m "example app for rake script testing"
heroku create
git push heroku master
heroku rake db:migrate

and run the task remotely:

heroku rake admin:fake_people NUM_RECORDS=1