There’s been some debate online this week about how hard or easy it is to learn Ember. It just so happened that a couple of days ago I spent a couple of hours starting to learn about AngularJS and I thought I’d share how the first 5 minutes went.

I started learning with the nice screencasts on Egghead.io. I then reached a screencast with the following code snippet:

1
2
3
4
5
6
7
8
9
10
11
12

var myApp = angular.module('myApp', []);
myApp.factory('Data', function () {
    return {message:"I'm data from a service"};
});

function FirstCtrl($scope, Data) {
    $scope.data = Data;
}

function SecondCtrl($scope, Data) {
    $scope.data = Data;
}

In that code, it’s explained, we define what “Data” is and when AngularJS sees a controller that uses Data, such as our FirstCtrl and SecondCtrl, it will inject it. At this point my partner and I stopped in our tracks together and noticed some unknown magic is happening. After all, neither of us knew of a way in JavaScript to see how a function’s arguments are named, and so how can AngularJS use that for injecting?

After googling a bit we came across a StackOverflow answer that said a function’s toString method can be used to parse out the argument names. Staring at each other puzzled, we didn’t want to believe it, saying there’s no way that’s what’s going on. Then he suggested I override FirstCtrl.toString and lo and behold, the injection broke.

Now that’s some magic that I joked was “even too much for DHH”, and I find it hard to believe anyone that knows a bit of JavaScript can start learning AngularJS without going through what we just did. But then, we realized something more.

Most sites, on production, minify js files in a way that mangles names. How is that supposed to work with this sorcery? Googling some more we found in the AngularJS docs that there’s simply a workaround, a different syntax that’s used in a way that survives minification.

Now don’t get me wrong, I’m just starting to get to know AngularJS, and it looks like it has some really nice features, but having to go through this whole ordeal the first 5 minutes I’m learning something new, only to realize that syntax is actually useless and that I’ll never use it, is weird. It made me feel as if someone wanted to put in a “cool” feature, and when they noticed it actually won’t work for most production uses they left it in for the coolness factor, instead of removing it.

The bottom line is, no project is perfect, and usually once you’ve already learned something, it looks so much simpler than the rest!

You should follow me on twitter!

So many people I know claim to be doing agile, and are crafting software, and whatever. Unfortunately, from my experience it is clear that while everyone like saying they do stuff, they aren’t actually doing it.

Going through the motions, instead of understanding what you’re doing, is basically useless. The only way to get better at something is through introspection, that requires you to be aware of your actions and the wanted outcomes.

Some examples:

Do the people on your team know why you have to stand up at the daily standup? Are members told what kind of information to share and what not? Or is it simply 10 minutes of everyone not listening?

Does your team pull up estimates for tasks? Why? Do you look at the estimates at the end of an iteration? Will you cut features in case the estimations show you won’t complete all the tasks?

Are your automatic tests valuable? I’ve seen mountains of useless tests that do not aid refactoring, super slow or simply just don’t really test anything. If people don’t understand why they’re writing them, how can you expect them to write good ones?

Are your retrospectives just 30 minutes that you’re waiting to get over with, with basically no action items that change things?

There’s a reason software developers have grown to hate process, and it’s because most of the times process is just that, stuff that needs to be done without a lot of benefit or apparent logic. Make sure you and your team know why you’re doing stuff, that’s the only way to get better.

Earlier today I gave a talk at Rails Israel about being more awesome with RSpec.

In case you’re interested to read more about custom matchers, my post about it might help you.

You should subscribe to my feed or follow me on twitter!

Ever since IFTTT were forced to remote Twitter triggers I, as many others I’m sure, was having problems getting similar, trivial tasks done without a lot of work.

After a bit of searching I found out that twitter’s v1 API has RSS feeds, which IFTTT supports. Though that API will probably be shutdown in March since it’s deprecated, I discovered that for now it can be a decent replacement to some stuff I used to do with twitter triggers.

The simple stuff

I used to have IFTTT tasks that evernote’d my tweets and favorites for future reference. I found out that these were easily replaceable using the timeline and favorites feeds, and then wiring IFTTT to listen to these feeds and save their contents to evernote.

Where things got messy

I’ve set up a tumblr that basically just monitors links (photos actually) that two awesome dudes tweet at eachother, for prosperity. The Feathers-GeePaw was got a new post via IFTTT everytime a tweet appeared from @mfeathers to @GeePawHill starting with a link (“http”). Now unfortunately, this wasn’t trivial to mimic using feeds.

Though IFTTT’s feed triggers allow matching, which would hopefully would have allowed matching the right tweets and links, it doesn’t allow extracting the link.

The workaround

I spent an hour whipping up a simple proxy tornado server running on Heroku that does the easy filtering job by itself and set IFTTT to poll that thread. The hacky code is available here (you would have to excuse the poor name I chose).

The future

As I mentioned, the v1 API is going to die in March. I’m hoping that by then IFTTT would find a better workaround, or I will have to implement a few more of these dumb proxies, these time in the v1.1 API (which requires actually setting up a twitter development account and authenticating for each request).

You should subscribe to my feed and follow me on twitter!

In case you’re interested in Passbook, we published today a good summary of pitfalls and gotchas that we ran into while implementing our passes.

You can find the post on the BillGuard blog here.

I’ve recently had a lot of fun taking part in the Stripe Capture The Flag (CTF) game. It’s basically a game where one has to go through several levels, finding different vulnerabilities in order to advance. This time the vulnerabilities were web-related, such as XSS, SQL injections, etc.
It’s great of the Stripe team to go through this effort to educate us all (as a bonus to providing an excellent service).

I wanted to share a little tidbit about solving one of the levels. In level 6 you needed to do an XSS attack that consisted of posting some content with some javascript in it and then posting the user’s password back. Both posting the script and the user’s password were supposed to be extra tricky, since the server made sure no one can write quotes to the DB. The intention the Stripe guys had, I understand, was to make one learn about different kinds of javascript code that can be written to wiggle through different kinds of defenses.

Let’s take a look at the method that did this protection:

1
2
3
4
5
6
7
8
9
10
11
12

def self.safe_insert(table, key_values)
  key_values.each do |key, value|
    # Just in case people try to exfiltrate
    # level07-password-holder's password
    if value.kind_of?(String) &&
        (value.include?('"') || value.include?("'"))
      raise "Value has unsafe characters"
    end
  end

  conn[table].insert(key_values)
end

When something is posted, the body is usually provided inside the key_values as a simple string e.g. { "body" => "my body" }. In that case, anyone can easily see that the protection will work.

Enter Rack params

Rack, which is used by Sinatra and Rails, helpfully performs some magic in order to allow its params to be more than simple hashes of strings to strings. It does some nice parsing to allow passing nested hashes and arrays. For example, if the POST query looks like ?body[]=w00t instead of ?body=w00t the params hash will contain {"body" => ["w00t"]} instead of just {"body" => "w00t"}.

Can you see where this is going? I just changed my code to pass the body with the extra [] suffix and now the safe_insert method got a hash containing something like {"body" => ["my evil XSS with ' and \""]}. Since the value is now an Array and not a string, the validation is not run. Luckily for us, passing an array of length one to Sequel for saving to the DB translates to SQL roughly as INSERT ... VALUES(('my body')) .... Since just wrapping an expression in parenthesis in SQL doesn’t make it treat it as a list/array, the insert is performed smoothly and we have our invalid post in the DB.

I talked with the nice Stripe folks that admitted that this way of getting past the validation was not something they had in mind.

It can happen to you too

The easiest way to prevent from stuff such as these to show up in your code is to make sure that params you get are of the types you expect them to be. It’s not fun, but I’m currently not aware of a gem or something like that to handle these cases. Please enlighten me if you think of better ways!

You should subscribe to my feed and follow me on twitter!

If you spend as much time on the web as I do, you sure have been a victim of fake HTML controls abuse. Both as a user of websites and as a developer I’ve wasted time, effort and nerves on the trivial things getting harder just to make them a bit more pretty. I wanted to list all of the reasons these fake controls suck, which one can also treat as the list of things to pay attention to if you’re inclined to write them anyway.

Disclaimer: Sometimes it makes sense to write your own control. If that text box is the holy grail of your site - by all means go crazy. I can’t imagine Twitter of Facebook without their text areas being what they are. But please, don’t inflict your fake control on us when all I want is to turn off your damn email notifications.

Most of the disadvantages I list here can be worked-around. The important thing is for us to understand these disadvantages and their cost. I’ve yet to see some plugin that gets all of these right.

The prettiness vs. familiarity trade-off

Most of the times people use fake controls is because they want something “prettier”, “shinier” or just more “web X.0”-y. While that might be the case, it comes with the cost of losing the familiarity the users of your site already have with the native controls they see every other place. If all of a sudden a checkbox doesn’t look like the regular checkbox I always see on my IE but like a toggle on an iPhone I’ve never used I’m more likely to be confused than amused.

Also, it has to have the different states controls can have implemented and in such a way that I can quickly grasp. If I have to click to find out if your toggle is disabled or just off - you’ve lost.

Reimplementing the wheel, poorly

You’d be surprised how hard it is to create a solid control such as a good drop-down list (select control). The people who wrote browsers worked very hard to make it work like it should work and like everyone expect it to work. Once you write one yourself you have to make sure it acts the same when I move between windows, click outside the element, resize windows, change zoom level, etc. What this basically means is that you’ll somehow get it wrong eventually.

Mobile support

There’s a reason mobile phones and tablets implement some of the controls in a different manner - because they should. I find it hard to believe your own select control will work better than iOS’s native one that allows me to scroll and pick efficiently and fast, regardless of the zoom I have on the page. In this age where mobile is everywhere and important, do you really want to tamper with your users’ experience?

Don’t limit me

Keyboard

If you’re reading this, you wouldn’t be surprised to know that there are a lot of people that use the keyboard quite extensively when surfing websites. For us, being able to navigate quickly using the keyboard and especially filling out forms is a big part of the user experience. If I can’t tab between elements because they’re not real elements, I can’t press space to toggle a checkbox or don’t see a nice native outline of the element I’m on - I’m basically being handicapped.

Plugins and extensions

More and more people are using plugins and extensions. Be it to auto-fill passwords and forms or for making certain things look differently. Whatever control you have, you better have the real native control below so that jQuery plugins, bookmarklets and whatever comes can change your forms and with your fake elements catching up on that and displaying it correctly.

Limiting developers

You as the developer probably also care about plugins as I’ve mentioned (because you want to use more plugins that make good stuff happen, and they need to interoperate with your pretty controls anyway). But don’t forget there are more side-effects to rolling your own. For example, you will have to work harder to get trivial styling to work. CSS has really nice selectors like :focus, :enabled, :checked and more. When using fake elements you usually have to reimplement these yourself.

Accessibility

Last issue, not because it is not important but because I admit I am ignorant in this matter. I know that native controls are something mostly supported for people with disabilities, and am sure your own fake ones won’t work out of the box.

Keep all of these matters in mind, and please spare us from your fake controls unless we really really want them.

You should subscribe to my feed or follow me on twitter!

Last week we (BillGuard) finally got out of beta, launching our paid version. As pretty much every software project known to man kind, we had some pressure with this project too. During an extremely short period of time I felt, for the first time, the real meaning of the message behind The Mythical Man-Month.

For those of you who don’t know, the Mythical Man-Month is a book that talks about software projects managements and how our estimations are usually not really what we think they are. The one-line example that gets the point across clearly is “9 women can’t deliver a baby in 1 month”.

When we noticed that our project was going to be a bit late we were extremely tempted to have all developers join in on the effort to get it out the door sooner than later. While we originally had 2-3 developers working on the project full-time (with almost always a couple doing pair-programming), for 2 days we cranked it up so that all 7 of us were working on it.

I can hear you going “What? Just 2 days? Is that his Man-Month?!” Well, let me tell you how odd it was. I wasn’t too thrilled about having so many people working on the same thing, but was prepared to give it a try. The book always talks about the rising cost of communication and management as more people are working on the same thing, which always sounded too abstract for me to fully grasp. Yes, it made sense, but I didn’t connect to it.

To my astonishment, in those 2 days I saw the complications of communication jam our work:

The cost of mind-share

During those 2 days I, as the developer that knew most of the code we were working on, had to constantly stop whatever I was doing to help someone else. Every 10 minutes someone came up to me to ask what a certain task meant, what might be the best way to do X, do I know what causes Y to happen and just plain syncing up. It’s obvious that I couldn’t get into a proper flow of development, which effectively already canceled out one developer.

More than the trouble I had trying to get some code written, my teammates were having different types of trouble too. First, they had to immerse themselves in code they were not familiar with in a fast pace. That includes having to grasp design choices of a constantly changing code base. Not having the time to go over all the other code that was being written, it was easy to open a file after 2 hours and see it completely different.

We also had to try really hard not to step over each other’s toes, and not to get dragged into merging conflicts. This meant that often you’d hear someone call out to make sure no one’s messing with class X and the likes.

And last, we had the trouble of hammering our “product owner” with tons of questions, often questions that he already answered multiple times earlier. This of course led to miscommunications and confusion.

After those 2 days

I sat down and blatantly said that as much as I like my fellow developers I’d be more than happy to stop receiving their “help” in this form. We returned to our previous formation and gladly got stuff done fast and with less talking and noise going around. It might sound funny but those 2 days were, for me, an excellent example of the exact point Fred Brooks was trying to make.

You should subscribe to my feed and follow me on twitter

Recently, we were talking about tackling an area of our code base in which we have accrued a large technical debt, and what would be the best way to get rid of it.

At first, the very attracting idea of a rewrite came up, this time specifically accompanied by dumping the old tools for new, sexier tools that would surely make everything better.

After some more discussions though, we reached the conclusion that as good as the new tools would be, there certainly is no silver bullet involved, and so the real question was - why do we think this time we would be any better and not get into the same mess a few months after completing the rewrite? Also, as everyone knows, rewrites are scary shit and never end well. While the idea seems quite easy when you start, you always realize down the line that the code got convoluted for a reason, and that you’re going to miss your estimates by a long shot.

The next idea we had is, of course, to first refactor our way out of the mess we got into and then gradually start using better tools as new features and changes to existing code are required. This is the responsible, own-up-to-our-mess choice. Of course we liked this idea, but the big question is: how should we go about this refactoring?

Some thought that the team should dedicate developer time for several sprints and have a developer work full time on these refactorings. This notion made me cringe and I thought I’d share why:

• We’re in a startup goddammit! If you can afford taking a developer off to play with code for several sprints instead of working on valuable features then, surely, you have too many developers! As an aspiring software craftsman I long for adding value to my users, not to get paid to play architect.
• Refactoring for the sake of refactoring, as much fun as it can be, is never as good as actually changing the code because you need to. I can really spend a whole day polishing a piece of code. The issue is that if you have no target in mind, like “it should be easy to add a new page to our app” then you don’t know when to stop. I’d hate for us to do this coder-masturbation (excuse my French) instead of doing actual work.
• Having refactoring tasks makes it OK for regular quality to be lower because it can be “refactored later”. That kind of crap is what got us in this mess in the first place!

To sum, I do believe refactoring is the way to go, but that the good path is to devote more time to tasks that require changing messy parts so that the developers would have the time to make sure they leave the code better than they found it, and clean stuff up, so that next time changes there would take less time.

You should subscribe to my feed or follow me on twitter!

The other day I came across another great use-case for Rubinius that might be useful for a lot of developers.

I use pry as my ruby REPL regularly. Often I feel the need to dig deeper into some part of the ruby stdlib. For example, just this week I wanted to find out what String.replace() does. Reading the documentation I still felt the need to dig deeper and see what’s going on.

Using CRuby (the ruby version you’re probably using) one can see the source code in pry by installing the proper gem (gem install pry-doc). Here’s the source code we got:

1
2
3
4
5
6
7
8
9
10
11
12

pry(main)> show-method String#replace

VALUE
rb_str_replace(VALUE str, VALUE str2)
{
    str_modifiable(str);
    if (str == str2) return str;

    StringValue(str2);
    str_discard(str);
    return str_replace(str, str2);
}

As you can see there isn’t a lot we can understand about the internal behavior of this function without digging deeper into str_replace, which isn’t really possible from pry.

Enter Rubinius

After you install rubinius (rvm install rbx --1.9) and switch to it (rvm use rbx) you can get a more interesting result (you might have to gem install pry after switching to rubinius for the first time):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

pry(main)> show-method String#replace

def replace(other)
  Rubinius.check_frozen

  # If we're replacing with ourselves, then we have nothing to do
  return self if equal?(other)

  other = StringValue(other)

  @shared = true
  other.shared!
  @data = other.__data__
  self.num_bytes = other.num_bytes
  @hash_value = nil
  force_encoding(other.encoding)

  Rubinius::Type.infect(self, other)
end

Now, not only can we see that String#replace replaces the contents of the String object we have with the contents of the other one (basically, treating String as a pointer and changing what it points to), we are free to dig deeper with the joys of ruby. For example, if we want to understand what StringValue does we’re just a short show-source StringValue away from it!

This simple ability is a valuable resource in getting intimate with ruby as a primary language. If you find more cool uses of this, please let me know.

You should subscribe or follow me on twitter!