We’re currently in the process of interviewing candidates for 1-2 Senior, and 2-3 junior level Rails Developers, and I’m wondering about the skills that are most critical, and how best to identify the best candidates.

My normal interview process flows like this:

1. Quick Phone screen evaluating basic development skills, background, availability, personality
2. Basic coding problem (less than 1hr to complete)
3. Phone call to review coding problem, ‘how would you handle X?’ questions, etc
4. On site interview targeting: Communication, Communication, Communication, (and tech)
5. Final decision

Independent of the language they will be working with, I’ve found decent success with having candidates answer some standard dev questions, solve a basic coding problem, and demonstrate their ability to whiteboard a design.

The problem is that it doesn’t scale. When we’ve opened up positions in the past, either Senior or Junior, there have been so many applications that its hard to contact them all. This leads to a reshuffling of the tasks and matching criteria, in an attempt to identify the ‘best’ matches, and ‘filter out’ the others.  So instead of calling each candidate first, we might simply reply to them with the details of the coding assignment. I’ve seen 40 people send the “I’m an extremely hard worker, very interested in your position and would do anything to join your wonderful company” cover letter and resume, and then get whittled down to only 10 candidates that actually submit the assignment.  (Note to applicants: ‘showing up’ is an important first step!)

I came across an interesting post titled ’11 tips on hiring a rails developer’ which mentioned some ‘filtering’ criteria to identify the best candidates

You can read the full description of each one, but there are a few of these that I wanted to highlight:

1. Don’t use Monster.com or recruitment agencies.
2. Poach Talent from other companies!
   
3. Don’t hire someone that doesn’t know Rails at all.
4. Look for open source contributions.
5. A personal Rails blog is required.
6. A university degree is not important.
7. Be wary of holes in proficiency.
8. Avoid brand-name superstars.
9. Hire perpetually.
10. Have a company Rails blog
11. Special compensation.

So each of these tips is meant as a heuristic or proxy of the true underlying ability. Any time you are making generalizations you are going to miss out on a few exceptions, but hopefully you end up with what you are looking for.

Starting with the most controversial first, (#5) while I like the idea of giving a strong preference to someone that has a rails blog, and loves  Ruby, Rails, and Web Development enough to be opinionated and spend their own time ranting about it, I’m not sure I could make it a filtering criteria. Doesn’t that seem a bit strong?

I feel the same about (#4) Open Source contribution. I think its great if they have it, but I’m not sure I would reject any candidates that haven’t contributed to open source.

While I’ve met many systems administrators that (#6) don’t have a degree, and are very good at their craft, I haven’t really encountered many solid developers that don’t have a degree. That’s not to say they aren’t out there, I’m just saying I’ve never encountered them, and I’m reluctant to use it as a filter. Do you think that there are many strong Rails developers out there without degrees? (I don’t care if they have a CS degree, but I think I prefer that they have some kind of degree)

As it relates to (#1) and (#11), I know for sure that the economics of finding a candidate through your own network and contacts can be less expensive than the recruiter fees (assuming you find a decent candidate and don’t waste a lot of your own time doing it), and if you are able to find someone directly, it frees up cash for such amenities as ‘New Macbook Pro’, ‘RailsConf’, and ‘Fridge full of XXX’.

If I was in charge of everything

I really like what Andy Singleton describes regarding how his team at Assembla is organized and tackles Agile Development, and on the right project, I’d really like take his advice and try this one:

“Don’t interview. Just pay people to join a project, pull a task from the queue, and find out what they can do.”

Anyways,  I’d be very interested in your thoughts regarding what makes for a Solid Rails developer, where you find them, how you keep them, and what you’ve learned.

(Oh, and if you know any passionate Rails Developers in the Chicago area, send them over!)

Share/Bookmark

The problem: I needed to display a warning to a user if the data they were looking at was more than 90 days old.

The solution: Create a method that takes 2 dates (either DateTime or Time), and returns the number of days, or hours between them.

  def self.difference_in_dates(date1, date2, unit = 1.day)
    return nil if date1.nil? || date2.nil? || unit == 0
      (( date1.to_time - date2.to_time ) / unit).round.abs
  end

The problem was simple enough, and my tests were all passing, so I moved on to my next task.

That code has been out in production for several months, but earlier this week, a new developer told me he got an error when running the test:

  NoMethodError: undefined method `to_f'
    for Mon, 21 Sep 2009 14:29:38 -0500:DateTime

(we’re running this in Rails 2.0.2)

I looked at the code, knowing it was working before, ran the unit tests myself, and didn’t see the issue. Now I’m on Windows and everyone else is on a mac, so as soon as I run into an issue that no one else has seen I want to prove if its a Windows problem. But wait, this test has been running in our Continuous Integration server (Hudson) for months, and no one else on the team ever had any issues with it, and the code has been working in production without any errors in the logs.

I jumped into rails script/console to see what’s up, and here’s what I found:

 >> x = DateTime.now
=> Wed, 23 Sep 2009 00:00:00 +0000
>>; x.to_time
=> Wed Sep 23 00:00:00 UTC 2009
>> x.to_time.to_f
=> 1253664000.0

Which is what I expected, but when I asked the other developer to run that same instruction, he got an error.

>> DateTime.now.to_time.to_f
NoMethodError: undefined method `to_f'
  for Mon, 21 Sep 2009 14:29:38 -0500:DateTime

What’s up with that? We’re running the same code, and all of our libraries are the same version. Looking at the date value in his error, I saw the timezone, and decided to try this variation locally:

>>  x = DateTime.parse("2009-09-21T14:29:38-0500")
=> Mon, 21 Sep 2009 14:29:38 -0500
>> x.to_time.class
=>; DateTime

So I’m gathering that when there is a timezone and you ask DateTime.to_time, its just going to give you back a DateTime.
I wasn’t expecting this, and its exactly why my code was failing, because sometimes the DateTime.to_time will return just a DateTime object. The Rails 2.0.2 docs do state this:

to_time()
Attempts to convert self to a Ruby Time object; returns self if out of range of Ruby Time class If self has an offset other than 0, self will just be returned unaltered, since there’s no clean way to map it to a Time

Ok, so I guess I have no excuse, its written right there in the docs, but I guess I, didn’t really look at the docs for the to_time method, or if I did, I didn’t really get what it was telling me. Either way I have a problem that isn’t going to change.

When I asked my colleagues at Pathfinder, they all said “Why do you need to do that?” and “couldn’t you find a gem or plugin that does that already?”

Which is a solid point. If you are doing something as common as checking for the difference between two dates you should expect to see either some straight code examples of the best way to do it, or a plugin or gem that solves that problem. I’ll need to dig into this a little further, but for the moment I simply updated the code to:

  def self.difference_in_dates(time1, time2, unit = 1.day)
    return nil if time1.nil? || time2.nil? || unit == 0
    (( time1 - time2)  / unit).round.abs
  end

and I looked through the places I was using this code and made sure I only passed in a Time object, so now I’ve ‘fixed’ the bug so that the tests don’t fail for anyone else, and I’ve bought myself some time to figure out what’s the best course of action.

But I’m still curious why DateTime.now behaves differently depending on OS? What’s going on there?
I jumped on to our build server (CentOs) and ran DateTime.now, and see no timezone, and that’s why the tests don’t fail there.
I jumped over to my heroku server and saw that DateTime.now includes a timezone.

Wondering what the os was I ran:

`uname -sr`.chomp.strip
"Linux 2.6.18-xenU-ec2-v1.0"
>> `cat /etc/issue.net`
=> "Debian GNU/Linux 4.0"

So what dictates the Date and Time setup? Is it purely an OS thing, or is it just a component of how time is setup on the server?

I jumped over to another Debian box, and there DateTime.now doesn’t include the timezone, so now I’m thinking that its not as simple as just the OS, but something else. (please someone, enlighten me!)

Conclusion: Don’t be an idiot
I did a few things wrong here, and I deserve to be flamed for it:

1. Read the docs, understand the code you are relying on. In most cases, ruby and rails just does what you’d expect, but its still worth reading into, even when things seem to be working just fine.
2. If the problem you are trying to solve seems common, google around, ask others what they have done, dig into the framework, etc. Assume you aren’t the first to run into it.
3. If it seems that what you are doing isn’t common, or isn’t handled in the frameworks/libraries you are using, perhaps it means you are looking at the problem the wrong way and there is another, simpler solution out there.
4. Test your assumptions. I will say that at least I had tests that covered my assumptions, and failed when they weren’t true. I may not have written the best solution, but at least it worked on every system we deployed it to, and never failed in production

Share/Bookmark

Eric Smith from 8th light gave a hands-on TDD presentation at last night’s Chiphone meeting, hosted at Obtiva’s downtown office, (conveniently located near the the train).

There was a good crowd of people, most attendees have ‘played around’ with iphone development, 4 have actively developed apps (3 people have live apps in the store).  From my quick survey of those that have submitted apps, it seems most of them were free utility apps or simple games, with at least one commercial app Dash for Confluence. It also seemed that no one had yet needed to do any animation beyond the basics, with just a bit of core-animation, but no need for more lower-level openGL or animation engines.

Eric started off by saying that he’s given talks on iPhone testing, but that just telling people what to do is not the same as letting them experience it for themselves,  so we did a Randori, where a pair starts working on some code, and every 3 minutes one person from the pair swaps out and chooses his replacement from the crowd.

What I liked about this was that I felt like I got to know the audience better, and actually watch people reason their way through the code or a testing/mocking issue.  (You know how sometimes you go to a user group, and it can be hard to get a chance to talk to others, or sometimes there is a ‘know-it-all’ guy, and you just want him to shut up. Knowing that you are going to have to go up there and code is a great way to silence those types)

When it was my turn,  there was an interesting issue with one of the tests that had us all stumped for a bit, but ultimately ended up being one of those problems where you need to deconstruct everything and build it back up. (The issue was that while we were trying to set fooController.textView.text = @”foobar”, we hadn’t instantiated a textView object, or set it on the controller yet.)

We got into some testing, mocking strategies, and a few Xcode tips & tricks, but not being all that familiar with the mocking framework, it would have been nice to just do a little intro on the api, but whenever someone was stumped the answer was shouted out pretty quickly.

It was nice to get some pizza, so a big thanks to Obtiva & 8thlight for putting this together. I wish we could do some presentations here at Pathfinder, but our space is better for a meet & greet, than a presentation. (plus I don’t think as many people would come to the River North area)

I was new to a Randori, and I think this style of presentation is good, but I do have a few ideas I think I’ll include when I host one:

1. Set out a basic agenda, introducing the approach, the codebase, relevant api, and where we’re hoping to end up
2. Moderate the work (and the crowd), and be ready to help out in case the pair gets stuck (which means you really have to keep an eye on what they are doing)
3. Make the work meaninful, and the outcome tangible. (we were able to see our posts getting pushed to twitter, which was nice)
4. Push the final code up to github as a branch, so they can check it out later and compare the original to what they created as a group

There were a few times when I couldn’t quite hear what the pair was saying, or read the screen that well, and though it wasn’t a large group there were a few side conversations that made it harder for me to follow. I think this was most likely to happen when the pair was struggling, so a little moderation would probably keep things moving along fast enough to keep everyone engaged. I saw another post that also laid out some strategies for how to best host a Randori session.

I’m looking forward to the next chiphone meeting, and I think there was some talk of doing a group project to make a little app for next month’s WindyCityRails.org conference.

Related Services: iPhone Application Development,
Ruby on Rails Development, Custom Software Development

Share/Bookmark

I had to dig into a production issue the other day that presented itself like this:
There was a piece of javascript code that iterated over some dom elements, gathered ids into 2 arrays, ran a validation check, and then flattened the arrays to add them to the url.

On firefox, opera, and chrome this was working correctly, and had been tested by the developers, but on IE 7 it isn’t working, and the problem wasn’t detected until it made it out to production. (Which raises a point about testing in IE during QA, which I’ll get to in a sec).

I started my investigation doing what I’d call “poor man’s debugging”, putting some alerts in, breaking up the code a bit to make it easier to inspect, etc. Normally I don’t do this when testing in Firefox, because I have Firebug, but in IE I always seem to start with the basics to get my bearings, then quickly move to a more pragmatic approach.

Then I started using firebug-lite, confirming that I can see the info I need, and I reverted my changes to the code so that I could verify that I hadn’t introduced any issues.

After sifting through the code, checking through the prototype library to make sure that it was being used correctly, I narrowed the problem down to a single line, which I could test from the address bar of either browser (when on a page with prototype.js loaded)

   javascript:alert([[,,,'foo'],[,'bar',,]].flatten().length == 2)

For me that will fail in IE 7, but pass in everything else.

I then wrote a test using jqUnit, the javascript testing library from jQuery, so that I could get into that rapid process of test => fail => fix => pass, without having to screw around with retyping or copying code, or forgetting what I’ve tried.

	test('prototype flatten array test', function(){
	ok([[,,,'foo'],[,'bar',,]].flatten().length == 2, 'the flattened array should be 2');
	});

Now if I load the page with that test on it, in Safari, Firefox, Chrome, or Opera, the test passes, but if I load it in IE 7, it fails. I now have an environment where I can dig in and make changes, and quickly confirm that I didn’t break anything in the other browsers.

After a bit of investigating I conclude that the issue is within the prototype.js library itself, behaving differently between browsers for this function:

flatten: function() {
    return this.inject([], function(array, value) {
      return array.concat(Object.isArray(value) ?
        value.flatten() : [value]);
    });
  }

I know that I have undefined or nil elements in my array, so I write a quick test to see how Object.isArray handles that. Turns out that it behaves the same way in all the browsers, but interestingly, it will return either True, False, or Undefined, which means that those undefined values will get added, because the flatten method above is just looking for ‘true’.

At this point I feel like writing a version of the method that is a bit more explicit, just to make sure that I’m on the right track. (I throw this in my test copy of prototype.js)

//explicitly checking for true and false, because isArray returns undefined
  myflatten: function() {
    return this.inject([], function(array, value) {
    var _isArray = Object.isArray(value)
    if (_isArray == true) {
      return array.concat(value.myflatten());   //must call myflatten
    } else if (_isArray == false) {
      return array.concat([value]);
    } else {
     return array;
    }
    });
  }

I create another test, and see that it passes in all browsers, but I’m not really interested in going to production with a patched version of prototype, and at this point I’ve already spent enough time on this bug, so I go back to my original problem code and find another way to remove the undefined elements of the array, and get the code pushed out to prod.

After things calm down, and we’ve gotten the outstanding bugs taken care of, I wanted to take another look at the problem, because while I feel that I’ve figured out a way to stop the problem, as I still don’t understand why its happening. After some googling, I don’t really see a clear indication that other people have run into this, but I take a look at versions newer than what I’m running in prod (1.6.0.1), and I see that the isArray method was recently changed to:

 function isArray(object) {
  return getClass(object) === "Array";
}

Which we can see will result in a strict true/false response, and when I reran my tests against that version, they passed, so I figure I’m done with it and we’ll just upgrade to the latest version when we can.

But something keeps nagging at me, as it seems that there’s more going on here than just the isArray method, so I dive into the code again and see that the function that is passed .inject is called more times in IE than in the other browsers, and that the code in .inject is pretty simple and just relies on .each.

I write a test to explore how .each will iterate over undefined elements in all the browsers.

	//shows that .each will iterate over empty array elements in IE
  test('iterator test', function() {
    var hitCount = 0;
    [,,,'foo'].each(function(value){hitCount++;})
    equals(hitCount, 1, 'should be 1');
  });

And I see that IE iterates over the array 4 times, whereas opera, safari and chrome only iterate 1 time. Interestingly my latest copy of Firefox is behaving the same as IE, and I swear it wasn’t doing this with the previous version I had when I was originally testing this a month or so ago.

Here are the results:

Conclusion:
Be careful in any assumptions you make about the contents of your arrays, and their iteration, in case they contain nils, or ‘undefined’ elements you weren’t expecting.

The other point I’d make is about the general practice of javascript debugging, and testing. If you get comfortable with firebug, and firebug-lite on IE/opera, you can save yourself a lot of time and narrow down to the issue pretty quickly. Having even a basic test suite can go a long way in ensuring that your javascript code behaves the way you expect in all of the browsers. Couple that with some selenium smoke tests, and you’ll find more bugs faster, and save a lot of wasted effort in your QA process.

Related Services: Ajax Rich Internet Applications, Custom Software Development

Share/Bookmark

I’ve been doing a good deal of PDF generation in Rails, and had to go through the process of comparing all the available techniques and frameworks in order to find the right solution for my needs.

Its great that there are so many tools out there, but it can be a daunting task to figure out which is best, which will scale, which will continue to grow and improve, and to evaluate the true ‘cost’ of free vs. commercial.

With all this info finally digested and sorted out,  I was surprised when I got a client request to be able to add a banner to an existing pdf, and from what I can  recall, none of the libraries I know about seem able to do this.  Right now, I’m in the middle of googling the hell out of it, but haven’t found my silver-bullet answer yet.  (maybe I should ask jeeves?)

I’ve done various searches and have come across a few categories of PDF tools:

1. Wrappers to existing pdf generation tools like fpdf, and iText
2. PDF Template tools where you build a pdf skeleton file, and bind values to it programmatically
3. Pure Ruby PDF Generation tools
4. PDF Readers and inspection tools

I did find a discussion about how this could work on Google Groups between Greg Brown creator of Prawn and Ruport, and James Healey developer of PDF::Reader, but that discussion basically ended with, “Yeah, that would be cool!”.

At this point I’m looking into the Origami library which is actually designed for pdf ‘security’ and testing, and isn’t explicitly designed for editing pdfs in this way, but at the moment its the leading candidate in my list.

Have I missed something? Is there an obvious way to do this in ruby/rails that I’m completely overlooking? (I haven’t looked very deeply at tools that shell out to the bigger libraries, but I wouldn’t rule them out)

The initial requirement was to be able to add a banner/header to an existing PDF, but I can see the complexities of determining how to shift the existing content down without screwing up all the formatting, so I think even being able to insert a coverpage might be a suffcient implementation for now. (Maybe I should be searching for pdf ‘merging’ instead of editing)

I’ll update you with my final solution in an upcoming blog post, and I’ll be covering all of the info I’ve learned on PDF Generation tools for Ruby and Rails  at this year’s WindyCityRails Conference on September 12th. Drop by http://windycityrails.org to register. (early registration ends Aug 1st)

Share/Bookmark

The ChicagoRuby users group (not to be confused with chirb.org another great Chicago Ruby user group) held their second meeting at their downtown location.

While the meetings out in Elmhurst are always informative and helpful,  the downtown location may allow for a bigger crowd, and the weekday time might work better for more people. Plus, the Illinois Technology Association – Tech Nexus is right next to Union Station which works great for people that still have to go out to the suburbs.

Noel Rappin’s talk covered some of the most common questions he gets through the Pathfinder Development Blog, and his own site RailsPrescriptions site RailsRX.com dedicated exclusivly to testing.

There’s too much detail to cover here, but at a high-level, Noel covered:

• The why, how, when, and where questions that make the foundation of a good testing approach
• Testing techniques for legacy projects
• A good review of the different testing frameworks, what their differences are, and some discussion about each (test::unit, shoulda, rspec, cucumber)
• A solid review of different factory tools that go beyond standard fixtures (Factory Girl, Fixture Replacement, Machinist, and Object Daddy)
• Strategies for migrating from Fixtures
• Differences between the mocking frameworks:  Flexmock, mocha, rspec, and RR (double ruby)
• Finding the right balance, and avoiding the pitfalls of ‘over mocking’
• Cucumber testing workflow (and where cucumber doesn’t work well)

The audience seemed to have a wide range of experience, but all had opinions to share about what they’ve learned about testing.  After the talk everyone seemed fell into small groups to network and exchange ideas and contact info, and a group gathered around Ray and Noel as they tossed around some ideas on potential future meeting topics “Ruby IDE/Editor review”, “Rails Jumpstart”, “Coding Dojo”.

The organizers took a stab at hosting the meeting virtually over gotomeeting (not sure if it was recorded or not).

Their next meeting is scheduled for July 18th, details can be found in their meetup.com group.

The organizers of the ChicagoRuby.com group are also the organizers of the 2nd annual WindyCityRails Conference right here in Chicago, on Sept, 12th, which Noel will be presenting at.

Share/Bookmark

photo credit: great_sea

A few weeks ago Alice Toth and I had a conversation about how we can better serve our clients, and while we normally delve into project efficiencies like communication, developer training, and good QA practices, this time we both concluded that we need to do a better job of helping our clients reach their goals in the most efficient way possible, and sometimes that means talking them ‘down’ from the specific implementation idea they have, and finding a faster way to get there.

I said that one of our challenges is that sometimes our clients feel they’ve hired us to just  ’Mow the Grass’, not discuss the landscape architecture, so we’re not always in a place to be heard when it comes to discussing the fundamentals of a project.  Alice wrote a nice post about what ‘Just Mow the Grass’ meant to her, and the strategy she’s devised to find a nice middle ground.

Here’s how I see it

I was thinking about the times when we encounter projects that are looking for what I call ‘commodity software development’ which is to say they feel they already have all the requirements, and everything is all figured out, and they just need a fixed-bid project to have it built. The reality though is that most of the time the idea is not fully fleshed out, and needs a good deal of work. While there might be some giant spreadsheet of features, usually the core business goals aren’t clear, and many fundamental issues have not been covered.

If the customer thinks they have hired us to just ‘mow the grass’, they aren’t in a place to hear any ideas about the big picture, they simply want us to ‘build it’, and as a consulting company we do need projects, and we want to have happy customers, so it seems we can either just build exactly what they asked for, and hope it turns out for the best, or we can help them confirm the business fundamentals a bit, and verify that the plan will work.

“I didn’t hire you to question me”

Its not easy to get into the fundamentals with our customers, but the overall success of our work is dependent on knowing the fundamental assumptions that led to its creation, and in my mind that means we need to explore those ideas and test them out.

The other comparison/metaphor I had been kicking around in my head goes like this:

Imagine you are a building contractor. You build buildings to meet the needs of your clients, while adhering to the ‘best practices’ of your industry. If a client comes to you and wants you to build a new ‘asian-fusion’ restaurant in an area that you are pretty sure its not going to take off, you could suggest that another location might work better, but in reality, the customer probably isn’t interested in what a contractor has to say about the viability of a concept restaurant. If the concept doesn’t take off, the contractor still got paid, the builing is still standing and can be used for other purposes, and an outsider would not conclude that the restaurant failed because of anything related to the structure of the building itself. And while it might seem that the contractor doesn’t care if the concept restaurant succeeds or not, let’s suppose that if it had been successful it would lead to a long and successful relationship where the contractor and the business owner continue to work together on new buildings and projects.

So in this example, the ‘building’ project has specific and measurable requirements that are independent of the big picture success of the restaurant.

Now comparing that to a software development project that is core to the business. The software product that is created is inextricably linked to the success of big picture, and the software is unlikely to stand on its own and be usable for some other business. In fact if the big picture is not successful often times the software product itself is blamed.

Some of the fundamentals of a project

1. Is this a problem that users care about?
2. Is this the best way to solve that problem?
3. Is the business value greater than the cost to build it? (if not, how could we either lower the cost, or increase the value?)

I’ve noticed this fundamental failure to align the proposed features of a product to their expected return more on iPhone projects, and other smaller budget projects. That’s not to say that its not present on larger projects, just that its more noticeable on smaller projects.

Ok, so now what?

Where as I was suggesting that we need to just dive into the fundamentals of the project and balance out the features relative to their expected value, and that its our job to ‘Fight’ to make sure we’re building the right solution to the right problem, Alice’s suggestion was that we need to consistently deliver high-quality results on the tasks we’ve been charged to do, even if it is just ‘Mowing the grass’, in order to establish trust and credibility, and earn our place at the ‘big table’ of advice giving.

What I don’t like about Alice’s idea is that its simple, elegant, logical, and its not mine!  (There’s nothing worse than someone taking something you said and interpreting it to be more positive and cohesive than you realized)

You may have won this round Alice, but what will you do with customers like these?

Share/Bookmark

1. Tether **
2. Run more than one app at a time (background processing)
3. Support multiple browsers (IE, Opera, skyfire, Iris)
4. Multimedia messaging **
5. Use a storage card for music, pics, etc

** While there are plans for the iPhone to support tethering and multimedia messaging, AT&T has not yet announced when it will be available.  (whereas I am writing this on the train right now, tethered to my phone, with just a basic data plan).  So I understand that it will be coming soon to the iPhone, but is not available yet.

To be honest I feel strongly that the first 2 are solid points, whereas the rest kind of quickly decrease in value, but I tried my best to come up with 5 things that mater, and I previously had ‘Record Video’ at #3, but now the iPhone will support that, so I had to take it out.

Tethering

While I saw good reviews of the Samsung BlackJack when I was in the market for a new phone, tethering was the #1 reason I bought the phone instead of an iPhone. Being able to get on the internet with my laptop from anywhere, at anytime is a very big deal for me. I take the train to work, and often have to rush out the door at night in order to make the schedule, but its easy for me to keep working from the train, and finish up my emails, check-in/deploy code, connect to vpn, etc. and that flexibility is huge.

As a consultant it means I can provide assistance to my customers in a more flexible manner. I recently had a customer contact me with an emergency deployment issue while I was on the road, about 20mins into a 4hour drive. While still on the phone with the customer I was able to plug my usb cable in, fire up my laptop, securely connect to their network, view the logs, debug the issue, change the code/configuration, check in to github, deploy and close out the tickets over the course of 2hours, all without losing connectivity (and picking up Wendy’s on the way!).

At one point I had tried to find telnet/ssh tools for my phone that would allow me to do some work from the phone directly, but I find its just easier to tether and use all the tools of my laptop.

Running Multiple applications

Being able to run multiple apps at once is more important than I originally realized, as it helps me to be much more productive and connected.

Some recent use cases of mine are:

1. Using Fring to IM a colleague about an important work email, while walking to the subway, drafting a reply to that email, opening a new tab in my browser to check the bus schedule (if its on time I’ll take that instead of the train)
2. Pulling up google Maps while on the road (while someone else is driving of course) to see the route to a friend’s house, using Fring to IM that friend that we’ll be there soon, and looking up events going on that weekend in the area.
3. Talking on the speakerphone to a customer while looking for some info in email and google docs

Mulitple Browsers (or browser engines)

This might not be a very strong point as the browsing experience on the iPhone is pretty damn good, but I am happy to have:

1. Multiple browsers for different uses (IE for simple mobile browsing, Iris/skyfire for a more powerful experience)
2. Flash video support in the browser (YouTube, Hulu), with Skyfire

* I realize there are different browser options for the iPhone, but my understanding is that they all share the same platform (ie. none of them support flash in the browser)

Conclusion

For me the real lesson here is that I am motivated by ‘tool envy’, (insert joke _here_). This is just like what I have experienced when pairing with someone using intelliJ when I was on eclipse, or they’re on a mac when I’m working on windows and its something that can drive you to look at your environment and ask “how can I make this better?” For windows mobile users I think it takes a bit of effort to find the things that make the phone better, and its a shame that Microsoft hasn’t made this process eaiser. Once the iPhone has tethering, and with lower prices coming, its much harder to justify buying anything other than an iPhone.
(oh, and let me know if there is anything else I missed)

Related Services: iPhone Application Development, Custom Software Development

Share/Bookmark

In Yesterday’s post I said I’d put together a quick list of things to think about around web application security. This is by no means an exhaustive list, but its a set of categories and things I start to look at when doing a security assessment on an app.

Web Application Security Checklist
Account management

• Password management (validation, expiration, previous passwords, etc)
• Account lockout (number of tries, IP auditing, etc)
• Role management

Data management

• Don’t Leak sensitive user info (SSNs, account numbers, other identity info) in URLs, cookies, sessions, logs, or printable pages.
• User Auditing (who changed what, and when)

Browser hacks

• Cross Site Scripting (XSS)
• Cross Site Request Forgery (XSRF)

Encrypted transport (make sure Ajax calls are secure)
Encrypted storage (credit cards, ssns, etc)
Server configuration (firewalls, web/app server, db)

I actually have a longer list, but its not formatted/organized very well,  so this is my first cut at sharing it with others.

What other areas do you look at when doing security checks for your web apps?

What tools do you use?

Share/Bookmark

Photo Credit:
Amagill under Creative Commons Attribution

Security is hard

Security is often an after thought, slated towards the end of a project, or after some big issue has been discovered, but the nature of security functionality, rules, roles, auditing, etc make it hard to layer in to an existing codebase effectively.

Oh, and if the code base isn’t sufficiently tested, you’re in for a world of hurt.

If you are a developer that was just asked to ‘do a quick security check and plug any holes’, you are now in the difficult position of managing the expectation that a two-week security review means “we’re covered”. Be realistic about what you can accomplish, setting out some short-term and long-term goals.

Do More With Less. Start with a research ‘Spike’

Instead of pushing for more time to be able to ‘cover it all’ (even though you have no idea what ‘it all’ is yet), it might be better to start with a shorter analysis phase, where you detail your findings, identify any trends, and include recommendations for process change. I’ve found that even the most demanding manager is appreciative and understanding when you ask for a small amount of time in order to produce a better estimate, than to just immediately demand more time without any evidence as to why.

Plan for success

With your analysis and recommendations in hand,
you’ll be in a better place to give an estimate on what it will take to correct the problems, and any potential side-effects, (ie. “our legacy data partners might not be able to implement their side of this new security plan on time”). Plus, the team can decide which items are the highest priority, and more importantly, you’ll have put some practices in place to prevent any new security issues from slipping in later.

Because we are never really ‘finished’ with security, now would be a good time to schedule the next security review, tapping another member of the team to head it up (with your guidance), so that everyone knows that security is something they should be thinking of. Instead of doing a single ‘big-bang’ security audit headed by one person under an unrealistic deadline, you’ll rotate the responsibility through the entire team, taking smaller more managable bites, and educating everyone in the process.  Eventually your ‘security-review’ will be a natural part of the iteration and your everyday work.

(Tomorrow I’ll post a quick checklist of general areas to look into for web application security.)

This same ‘analyze, prioritize, estimate, rotate’ technique could be applied to any ‘big-bang’ approach, such as:

• Performance tuning
• Adding unit tests to legacy code
• Refactoring
• Releasing to Production

Your team will get into a rhythm and become more efficient as the knowledge is evenly distributed. But more importantly your customers will appreciate the stability of having smaller but more frequent changes instead of massive buggy ‘overhauls’. They’ll see bugs getting fixed faster, and notice that little things that have bothered them for awhile are also getting fixed. Who knows, they might even give you the feedback that leads to your next million dollar idea!

Share/Bookmark