My thoughts on this Apple Developer security thing

So Apple's developer sites have gone offline for a couple days now, apparently due to security issues. One security researcher called Ibrahim Balic came forward with with a story of how he found a bunch of vulnerabilities and notified Apple about his findings. Basically, he claims to be completely white hat.

On the other hand, developers have been getting password reset emails, and Apple apparently decided this issue was critical enough to throw the entire site offline for multiple days.

To me, that doesn't really seem like appropriate action. They could have also replied to him and thanked him but asked him to stop his actions while they worked on a fix. Then they could have simply set up some checks to make sure the vulnerabilities wouldn't be exploited until a fix was ready.

My guess? They looked at their log files, and found that the holes Ibrahim notified them about were being actively exploited by someone other than Ibrahim, and therefore that had little choice other than to shut the whole thing down.

This would make sense in that Ibrahim can actually be the white hat researcher he claims to be, while being consistent with the immediate shut down (and the reports of password reset emails developers seem to be getting -- though that can also simply be a side-effect of all the attention this issue is getting, people searching for other exploitable holes).

Yehuda Katz - My Problem With Turbolinks

“[...] a lot of existing JavaScript operates under the assumption of a clean scope, and a single DOMContentLoaded event. [...] the assumption of a clean global scope per server-rendered HTML page is baked into a lot of the JavaScript and jQuery libraries”

Yehuda comes up with the precise description of the problems I'd immediately suspected would be an issue when I heard of Turbolinks. Seems to me like Turbolinks is likely to become Rails 4's shitstorm I they do turn it on by default.

A case of the scrums

Recently where I work we have changed our agile process a bit. When we decided to switch to scrum, we’d started by doing it the way it’s described most of the time: a product owner organizes the backlog, team gives stories estimates, and repeat this for each sprint.

Now, it might be because we have a small team (3 part-time developers), or it might be other reasons, but after trying this process out for a few months, we didn’t feel that this style of doing scrum was the best match for our team and product.

We do sprints of two weeks long, and deploy to staging after every sprint. Every two sprints we deploy to production as well. We feel that this is long enough to get up to speed, but short enough not to lose a lot of flexibility.

All of this is still pretty much a standard scrum setup. However, we felt that the role of the product owner was hard to fill in our situation.

For every release (i.e. two sprints) we choose a few goals. Anyone can add goals into Pivotal Tracker (as epics), and we add a release planning meeting where the epics for the coming two sprints get chosen. Everyone present at this meeting gets to promote one epic and has to explain why they feel that epic is the most important one at that moment. Usually some consensus will be formed, but ultimately the choice of epics for a sprint lies with the product owner.

Epics are about features at a higher level than stories, but should still be able to be completed within the two sprints of the release. Anything that’s bigger than even two sprints should really be possible to be broken up, otherwise it’s probably not fleshed out enough to be broken further down into stories anyway.

After this preplanning meeting the team will ensure that the stories for the chosen goals get created. The developers will form and arrange the backlog for the coming sprint, and meet up to rate the stories.

At the start of the sprint last minute details like incoming requests from customers (this is stuff we should have an administration interface for but currently haven’t, and thus needs to be changed by developers using migrations) get added to the sprint and rated, and any stories that do not fit within the sprint anymore get moved back to the icebox. We do this because these were arranged such that they were the least important, and it’s highly likely that the next release will not have the same goals (in fact, in general this is our rule), and hence will have no place for these overflowing stories.

We religiously trim the backlog in this manner because we have noticed that a backlog cannot be maintained past a few sprints anyway. Any new stories that come up will usually feel more important than whatever is near the end of the backlog, which leaves the backlog with a perpetual long and sad tail. Recognizing this, we have decided to forcefully chop this tail off rather than drag it along.

Analyst Watch: Water-Scrum-fall is the reality of agile SD Times: Software Development News:

Organizations are increasingly adopting agile software development methodologies through a combination of bottom-up adoption and top-down change. However, the reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels water-Scrum-fall.

Open Source Report no. 2

And immediately I forgot to write this up for a few times… So here’s what I’ve been up to the past weeks:

  • hubot-scripts. I added a Prowl/NotifyMyAndroid notification script to our work Hubot, that will push every mention of your name to your iOS or Android device.
  • rails: I fix a small bug where parts of ActiveSupport were not able to be loaded in isolation.
  • simplestats is a small Sinatra app to collect web statistics from your visitors and save them in MongoDB. I wrote this out of frustration with Google Analytics, which is probably very powerful, but all we really wanted to know were some browser usage stats, specifically the width of the viewports of our users. While you could push this to GA with a script someone posted somewhere, I simply couldn’t figure out how to get the results back out…

Open Source Report no. 1

Inspired by Mike Gunderloy’s attempt at doing something for the open source world every day, I figured I should be able to at least do something every week.

So here’s what I’ve been up to the past week:

  • watchmen is a new extension for Python’s Fabric library that is aimed at monitoring a set of servers. At the office, we’re growing pretty tired of Nagios, so I did a little test to see how hard it would be to build something better. The actual checks would be pretty doable with this library, though we’d still need to build a webbased dashboard and notifications via e-mail/irc/campfire/sms.
  • soundcheck is my unified interface to running tests. I recently came across the need to run a Minitest suite, so I’ve added something to support that. Not quite happy with how it works yet, I’ll probably improve it next week.
  • bootstrap I fixed some JS with regard to the buttons, when they are <input type="submit">s, instead of divs with class button.

How do you hold your Nokia?

How do you hold your Nokia? - The official Nokia Blog:

We’ve found any of the four grips mentioned above to be both comfortable and as you can see, offer no signal degradation whatsoever. This isn’t a feature you’ll only find on high-end Nokia devices either.

I’m sorry Nokia, but you’ve lost your privileges to make fun of others about this a long time ago.

Touching the future: More thoughts on the coming tablet revolution - RussellBeattie.com

Russell Beattie on tablet computing:

Someone on a laptop is usually leaning over, staring intently, clicking their mouse once in a while - all which screams "Do Not Disturb" to those around them. Someone using their mobile has almost the same sort of body language, actually! Head down, shoulders hunched, mobile held close to their eyes, squinting intently at the screen while hesitantly jabbing at various options, or suddenly tapping out a message furiously. Everyone around that person gets the clear signal that they are doing something private and to not intrude.



Using a tablet is completely different! You're usually sitting in a comfortable position, face viewable, eyes scanning normally, with an occasional flick at the screen or other casual movement - this gives a totally different and much more welcoming vibe.

Personal Cloud Computing

Otherland is a science-fiction tetralogy wherein the author Tad Williams writes of a future where everyone has computing devices called "pads". While the story never goes into details of these devices, I can imagine them looking quite similar to what the iPad is currently. In the novel, these devices are the main computing power, and people access them either directly, or use them as processors, interfacing with the web through direct neural connectors. While these neural connectors may be some time away, it got me thinking.

One of the criticisms of the iPad, or tablet pc's in general is that they're missing so much. But what if we were to augment their limited capabilities while you're at home. We already have the keyboard for the iPad, which turns it into a slightly more capable editor.

What if we to fix the problem of processing power by replacing the Mac on your desk with a Mac Mini sized box, ready to supply it's processing powers to your pad, over the air, to any pad on the local WiFi which needs it. Hook a Drobo up to your network if space is an issue.

And let's imagine WiFi-enabled screens (Otherland calls them wallscreens). These would probably be similar to iMacs, but less powerful. Your iPad could be the control hub, a switching station which connects your bluetooth keyboard, the screen and the processing node.

I don't think the iPhone OS is ready for this yet, nor do I have any insight whether it could be made to be. WiFi probably isn't fast enough yet, and there are probably loads of other problems I'm conveniently ignoring. But we're already seeing this become a real possibility. Chuq Von Rospach wrote about coupling Lightroom on your desktop computer with an iPad Lightroom app. The only real problem at this point is getting data to and from your iPad fast enough.

Now, if only that iPad were available over here in the Netherlands…

Golfing with Ruby

Yesterday we held the annual IWI Programming Contest at the university. For this contest, it’s customary to have one problem which is longwindedly described, but extremely simple to write in code. This year, it basically came down to:

  • Read a line containing an integer n
  • Read n lines containing an integer x, and print floor(x/5)

We started golfing this, and this is what I came up with:

#!/usr/bin/ruby -n
p $_.to_i/5 if $.>1

The tricky part here is ignoring the first line. It took me a little digging through the Ruby documentation to find that $. variable, which holds the current line number of the file (or STDIN) most recently read.