The TD Team’s Must-Have Tools for Web Development and Collaboration

Being a web developer is tougher than most people think. Not only does it require you to work with rapidly evolving technologies such as databases and web frameworks, it also requires you to communicate effectively with other functional teams. As an agile team, we strongly agree that effective communication and collaboration plays a huge role in a project’s success.

Thankfully, we have tools to make our lives a lot easier, tools that over the years, have gotten better and better. Here are the tools we believe to be extremely useful for web developers, not only for programming but also for collaboration.

TextMate

Known as “The Missing Editor for Mac OS X”, TextMate is considered one of the best editors for Macs. It’s a lightweight editor that boasts of a lot of useful features, such as fast switching between files, foldable code blocks, the ability to run shell commands from within the document, and a whole lot more.There are also a lot of bundles and plug-ins that can save you time and effort when programming.

An example is the Git bundle which allows you access to common git commands without leaving your editor. For our project, we found the rspec and cucumber bundles convenient because they provided shortcuts for writing test examples and switching between spec and code files.

The downside to TextMate is that it’s exclusively for Mac. If you’re using Windows, you might want to check out E-TextEditor which claims to be similar to TextMate and has support for TextMate bundles. For Linux users, check out Redcar. It also has support for TextMate bundles. Oh, and it’s free.

Firebug

If your work often involves the frontend, this tool can’t be left out. Firebug is a very popular and powerful tool for Firefox browsers. It allows you to modify markup, style, and layouts in real time, which really speeds up making changes to the UI. It also has a JavaScript debugger, which allows you to measure the performance of your scripts, use breakpoints in debugging, and check your AJAX responses.

Take note that there’s also an extension called Firebug Lite for Google Chrome, which is a bit different from Firebug in that it has a couple of limitations such as not having the Javascript debugger. So if you’re using Chrome, you might be better off using the built-in “Inspect” tool under its developer tools, which is very similar to Firebug.

Photoshop

If you think being a web developer is all about backend stuff, you’re seriously mistaken. It’s pretty common that developers have to design the frontend based on some mock-ups from the user experience team. Naturally, this calls for an image editor, the obvious choice being Adobe Photoshop.

In our experience, we spend a fair amount of time slicing images and inspecting font styles from PSDs. Getting Photoshop is a little pricey, but if you plan to do a lot of UI stuff, it’s definitely a wise investment. If you’re really on a tight budget though, you might want to take a look at Gimp, a free image editing software that supports PSDs.

Basecamp

Basecamp differs from similar project management tools with its focus on improving collaboration through communication, rather than statistics, charts or graphs. Having managed over 4 million projects with a 98% satisfaction rate, it’s a project management tool that’s hard to ignore.

One look at the interface and you’ll notice how simple and attractive it is. I think that this is actually the best feature of Basecamp, the fact that it’s so simple, you really don’t need to have any prior experience to get the hang of it.

We use Basecamp for pretty much everything, from user experience debates, to programming discussions, even marketing campaigns and strategies. It’s also effective for communicating whatever problems we have and asking for other people’s opinions.

For the development team, we use Basecamp as a knowledge sharing tool, posting useful articles and presentations. We also post problems on it so other team members can collaborate to solve them. Having everything on Basecamp is useful for times when similar issues pop up, because then we always have previous references to look back at.

Campfire

Most of us still use IM clients like Skype or Y!M as our first option when talking to individual teammates. These tools are undoubtedly very handy and easy to setup but are sometimes lacking when it comes to communication within groups. This is why we use Campfire, which is like a chat room, designed specifically for teams.

One of the main advantages of using Campfire is that you can share files and code in real time. This makes it a lot easier to share information since you no longer have to manually send a file through other mediums such as email. It also allows live image previews, conference calling, and is integrated with Basecamp. If you’re a fan of emoji, some of them are also supported in Campfire, which makes things a little more fun. For your viewing pleasure, you can refer to this cheat sheet.

Within our team, we have members working from different locations, so having Campfire is super handy, especially if you need something right away. As an agile team, we also do our daily stand up meetings on Campfire.

Propane

Propane is a nice little Campfire Mac-client with a neat interface. It compliments Campfire nicely and is extremely helpful if you do a lot of drag-and-drop operations. It lets you customize notifications, even with Growl support, so you can set priorities on which messages are most important. All these features mesh well together to make sure you don’t miss a thing.

From our standpoint, these are the tools that really keep us working efficiently and cohesively as a team. Do you have any other suggestions, perhaps something your own team uses? We’d love to hear about it in the comments below!

-Gerald, Software Bear

Developer Quick Tips: Awesome Print

Debugging can be pretty tough. As developers, narrowing down to the problem becomes a continuous exercise of patience as we inspect all sorts of objects at each and every step until we find what’s wrong. Staring at a cluttered screen littered with unformatted hashes, objects, and structures can be a bit overwhelming for most of us. And the worst part is that it’s all in monotonous black and white. Why does it have to be such a pain to look at?

Well, it actually doesn’t, and it’s all because we have Awesome Print. Awesome Print is a ruby gem that allows printing Ruby objects in full color. It’s just like using p or pp, but much better. Using ap lets you see your objects with proper indentation, shows you the index of array elements, and displays output in full color.

To start using Awesome Print, just type in gem install awesome_print on the console, or insert gem "awesome_print", "~> 1.0.2" in your Gemfile if you’re using Bundler. That’s all you have to do to start using ap!

Using Awesome Print is super easy. Like I said earlier, just use it as you would ‘pp.’ Yup, that’s it. Try it out in irb: type in require ‘ap’ and use ap<object>. In my case, report is a hash containing report information. It should look something like this:

Now, isn’t that better than using pp?

And if you’re one of those people who love to customize their tools, you can also pass multiple options to ap, such as indent, limit, and color. For example, if you want the indentation to be 4 spaces, and the color of strings to be cyan, you can do something like this:

ap report, :indent => 8, :color => {:string => "red"}

And there you have it, your very own customized output!

We found using ‘ap’ extremely helpful while building TrafficDito. We would frequently inspect report and user objects, which meant looking at them properly indented and fully colored made ‘em so much easier to read. It’s probably saved us from a lot of headaches and eye strain since we started using it.

For anyone who finds reading plain text in the console difficult, I highly recommend Awesome Print. Next time you find yourself in a debugging session, make sure to give it a try!

You can find more information regarding the gem and the available options at Github.

- Gerald, The Software Bear

Automated iOS Testing for the TrafficDito App

Here are two of the scenarios we run from our full test suite. When a user taps Report, then they should see the report modal. And then when they tap on the moderate traffic condition, it should show in blue. And finally, when they tap “Report It,” they should see a loading screen, followed up the report showing in the stream. Then the same thing again, only from the map.

Oranges to Apple: Web Development to iOS

TrafficDito was our first native mobile application. We had experience in the web development front, but to suddenly jump into the world of iOS development wasn’t an easy task. There was a lot to learn, and plenty more to unlearn. Gone are the days of simple request and response cycles.Now we have to deal with having a constantly running app which carries constant state. And with that, you have to worry about memory and performance implications. Not to mention having to unlearn all that fancy CSS3 and HTML5 graphics rendering stuff that made us feel sexy. Here are three of the biggest things we learned from our maiden voyage into this wild new terrain.

1. Constant Application State: I can’t forget about you.

On the world wide web, the only thing you ever really worry about is a request. What are you going to do when that guy from Bohol requests for that page on Tarsier hair grooming? You load the resource, maybe throw in some dynamic content like the latest deals on Tarsier shampoo, and send it off to the guy.

For mobile development, you’re not just responding to one request anymore. You’re handling a bunch of interactions from the user, sometimes more than one at a time. So how do you make sense of it all? Let’s all give thanks to the MVC architecture of the iPhone SDK. Let’s focus on that C part. Controller.

The controller is where you define the entry points to your application. As a user touches buttons, scrolls through a table view, whatever. These are all just mini requests that you handle in some way. Updating the model, updating the view, changing state of the controller itself, etc. The only real difference is that you have persistent state between all these requests.

On the web, each request is individual. Someone goes to a URL you setup to represent some resource. You may be dealing with a GET, a POST…some interaction to that resource. But these requests are isolated. Your web app doesn’t remember what happened before or after that request without the help of a session or cookie.

Not so in mobile development. Oh no. Not so. 

Rather than every request being isolated, they’re all connected. This makes your job easier in one regard. You know everything there is to know about your user all the time. No need for some cookie, session, nor database. Unless the dude closes your app, you’re fine.

But this also makes your job more difficult. You now know everything there is to know about your user all the time. These are things you may not want to know. No, I don’t mean his history of bowel movements (unless that’s what your app is about). What I mean is you know all that you want to know about your user, and you have all of that information in memory. And that memory is something you’re going to have to worry about a lot now.

2. Native App: That hardware be hard.

No duh. That’s why we got into this mobile thing. That buzz word there. Native. That means fast. Hardware access. GPS. Compass. Camera. All those other neato features. But you know what? With all good things comes a burden.

You don’t exist on some cloud server anymore with nearly limitless memory, processing power, and disk space. You have true limitations. Memory problems are extremely common in the mobile space. If you’re developing for an iPod Touch especially, those things have so little memory that you’ll get more warnings about your memory than your grandparents do.

Luckily, iOS 5 has eased this burden greatly with ARC (automated reference counting). It’s just Apple’s fancy way of saying “garbage collection”. You start off with some variable, and whereas previously you had to remember to release it at the proper time so as to free up memory, ARC will take care of that for you. You don’t have to manually release variables now (and really, you can’t). Cool.

Unfortunately, ARC does come at a price. Sometimes, it will cause you unexpected problems. If you ever get memory warnings, variables are going to get released and you’ll have a nil value where you expected an array of tarsier pictures. In some cases, this means a crash. In others, things will just stop working, like that “cancel” button that’s supposed to dismiss the modal view.

On our own report stream, we had some reports stored in an array on the view controller. If you left that view and went to, say, the map, then sometimes that’d result in a memory warning. That intelligent ARC system looked for something to release, and that large array of report objects seemed like prime siopao cat meat. So bye bye array of reports.

It didn’t crash. It’s just if you went back to the stream after such an occurrence, you’d be kindly told there are no more reports. Just like that, all the traffic in Manila disappeared. Cool. If only.
 
How do you solve such problems? For us, the solution was simple. Use Core Data. It will take care of most of those problems for you. But for us, we needed to keep a copy of the showing reports in an array on the controller, or else things would go out of sync between the table view and the data store. So if that array ever got dropped, we just needed to repopulate it.

- (void)reportManager:(ReportManager*)manager didFinishFetchingReports:(NSArray*)newReports
{
    _reports = [NSArray arrayWithArray:manager.reports];
}
 
- (NSArray*)reports
{
    if (!_reports) {
        _reports = [NSArray arrayWithArray:self.reportManager.reports];
    }
    
    return _reports; 
}

You’ve got to be careful about these memory problems. If the beta testers are telling you about some bug that you just can’t find to save your life, then chances are, it’s a memory problem. Fire up the simulator and start sending simulated memory warnings like it’s a whack-a-mole game. Or boot up your iDevice and load up abajillion Mobile Safari tabs and have a go at it.

3. Graphics Rendering: That makeup ain’t cheap.
 
You spend years perfecting the art of CSS. Moving away from the archaic days of slicing up PSDs and using the power of CSS3 and HTML5 to render all those fancy graphics for you. Surely moving into the cutting edge of the mobile world would give you these same nice things.
 
Just like CSS3, it’s true that Core Animation framework gives you access to easily creating drop shadows, rounded corners, and even gradients. That’s just what you need, right?
 
Wrong. Well, ok. You can. But be prepared for sluggish performance on anything less than the iPad 2 and iPhone 4S. For everything else, animating these custom elements gets to be very tedious.
 
You know that report stream? Those little dots indicating the traffic condition?

I thought for sure it’d be awesome to render those using native iPhone drawing capabilities. Make a box, round the corners into a circle, apply a gradient, a border, and we’re done! Boy did it look hot. And it followed the CSS3 way!
 
But then I ran it on a real device, the iPod Touch 4th Gen. Shoo, it was slower than EDSA traffic on a Friday night. Seriously. As you swiped, it had to redraw those elements again and again, for every single frame. And sadly, these devices don’t carry that 9800GTX Gran Prix of Awezome GFX Card with a 4.23THz GPU. So what to do…
 
Good friends, our best option is to go back to the 1990’s way of slicing and dicing our PSDs. No, it’s not as sexy as rendering everything just as you’d learned in your years of web development. But hey, at least it’s blazing fast! And that’s what matters.
 
But that doesn’t mean there aren’t a few nice things to employ as you slice. Let’s take a common problem: a box.

Drop shadow, rounded corners. The 90’s approach is an image for each corner, and various background images. No such thing these days.
 
There’s this sleek method on the UIImage class. It’s called -resizeableImageWithCapInsents: (-stretchableImageWithLeftCapWidth:topCapHeight: in iOS 4.3 and before) and sure enough it works just as the name implies. It gives you an image that you can stretch and resize to your heart’s delight. Just set the resulting image as the background of your view and change the dimensions of your view’s frame. Bam.

 
However, there is a downside. Images take up memory. Both for the initial download of your app, and loading them into memory. What to do?
 
When you make your images, keep that in mind. Cut out all the crap that repeats and just wastes space. Have you seen our condition button selector? Take a look:

No Neo, that isn’t the red pill. That’s a button we use throughout the entire app. Take a look.

Yup, it’s used everywhere. The report button, the segmented control buttons, etc. All you need to know is how many pixels are unique on the top and left. (iOS5? Then right and bottom too!) And bam! Resizing glory.

[barButton setBackgroundImage:[[UIImage imageNamed:@"barButtonItem"]
                                stretchableImageWithLeftCapWidth:6.0
                                topCapHeight:0.0]
 forState:UIControlStateNormal];

 
Noice. So when it comes to laying out your designs, at least for iOS, it’s probably best to avoid native graphics rendering. At least until the graphics processing power starts to match that of desktops, which may be when the iPhone 5 comes out with its quad-core OMG A6 processor, who knows.
 
Conclusion 

For our first app, there was certainly a lot to learn, just about the basics. But if you think deeply about the concepts you learned, you can still apply them. Understanding MVC’s power will make the transition easier, and exploring the art of performance on a native device will help you not make the mistakes we made. But from all this, we’ve learned. It will make our next app experience much quicker, but for sure there’s still a lot more to learn. And more to share with this fine audience. Until then..
 
- Stephen, Coke Zero-Addicted Coder