Welcome to the OCD nerd power hour.

Yes, the wait is over and you can now get a TrackerBot of your own in the App Store! TrackerBot is the only native app designed whole-heartedly for the iPad and iPhone, and it really shows. If you love your iPad as much as I do, and love Pivotal Tracker just the same, TrackerBot is going to make your day.

TrackerBot 1.0 has been in development since it began as a summer side project in July 2010. Labor Day rolled around and two things were clear. First, that TrackerBot was clearly going to be the best Tracker app out there. Second, it was going to take a lot more than just weekends and holidays to get there. After spending all my vacation days, quitting my day job, and founding Vulpine Labs LLC TrackerBot is alive and kicking. I couldn’t be prouder.

The goal for TrackerBot has always been clear: provide the best Pivotal Tracker experience possible, anywhere. In particular TrackerBot allows you to interact with your Pivotal Tracker projects as if they were physical objects. Grab a story with one finger, and just drag it where you want it. But you’ve got two hands! TrackerBot is completely multi-touch so feel free to use the other to scroll through your stories and find that perfect spot.

The interface, while being polished and preened for iPad and iPhone, is still very familiar to any Pivotal Tracker user. Some other apps in the app store have completely re-invented the Pivotal Tracker interface to match their view of how Tracker should be used. TrackerBot has instead tried to stay true to Pivotal Tracker as you know it, letting you use Tracker however you want to instead of how the developers think you should.

That said, TrackerBot is still young! The most notable feature missing right now is the ability to search for stories and customize your story panels. The first version has focused on getting the core interface details solid, but development has already begun on adding support for searching by keyword, labels, and by the owner of a story. Please be vocal in our Get Satisfaction support community and let us know what features are important for your team.

It’s been a really long road to release TrackerBot, and I’m really excited to see it in people’s hands. I’ve had wonderful beta testers who’ve provided a great deal of feedback and praise for TrackerBot, and I’m incredibly excited to share it with everybody else now.

Check out TrackerBot in the App Store!

I got an ebelskiver pan a year or two ago, thinking I’d make ebelskivers now and then, but really because I wanted to experiment with the funky pan. Sure you can make spherical pancakes in it, but what ELSE could be made in there? Cupcakes? Puddings?

Or how about, SPHERICAL FRIED EGGS:

Feel free to take a minute to put what remains of your life back together after this bombshell hit you. Cool, now that you’ve accepted your new spherical egg overlords, you’re probably wondering how to make some yourself. You’ll need an ebelskiver pan, eggs, and a wee bit of butter.

To start, separate an egg. Don’t be too exact though — you’ll want the yolk half to have some egg white with it. Put the pan on low heat and drop a tiny cube of butter in the center well. Once the butter has melted, swirl it around a bit, and then fill it with egg. You can either start with just egg whites, or start with the yolk and enough egg whites to fill the well. Let the egg cook enough to form a sturdy half shell, but don’t cook it through. The important part is that it be sturdy and easy to manipulate. If the egg whites aren’t cooked enough, they’ll break up a bit when you try to move them.

Once you’ve got a sturdy half-shell, you’ll need to turn (but not flip) the egg. I use a single, thin, pointed chopstick for this. Insert the tip of the chopstick between the egg and the pan and try to move the egg a bit. If it doesn’t want to move, then it might need to cook some more.

Use the chopstick to turn the egg enough to let the uncooked egg whites (if any) spill out over the side. Ideally you could turn the egg 90-degrees on it’s side, but I found this difficult at times — the egg would just slide back. Once you’ve turned the egg, add more egg whites to fill the well again. You should end up with a 2/3rd or 3/4ths sphere (sort of pac-man like). Let the egg get sturdy again, and then turn again, adding the remainder of the egg. Easy peasy!

Actually, no. It takes practice and experimentation, and even then it’s easy to mess up. Luckily for me, the very first egg I tried was also one of the best. Replicating that success took some effort, though even when I made mistakes, I found a way to set it straight. Egg is just a bunch of protein-goo you need to wrangle.

Learn from my mistakes

Heat: One of the reasons my first attempt was successful was that the pan hadn’t yet gotten too hot. While it meant the egg took longer to cook at first, the egg was stronger. Also, it meant I could take my time as I turned and formed the sphere. A lower heat will take longer, but you’ll be able to recover from mistakes more easily.

Whites or Yolks First: I made good eggs whether I started with egg whites only, or started with the yolk and some egg whites. However, when starting with an egg-yolk two things happened. First, I found it harder to do the first turn of the egg. Without the yolk, the uncooked whites in the center would spill out and immediately start supporting the sphere. With the yolk in the center, I had to pour more whites in while I was also turning.

The other thing I noticed with the egg-yolk-first method is that the yolk was more likely to get overcooked. However, starting with the egg whites meant that the whites would get a little overcooked. Egg yolks need to reach a higher temperature than egg whites, so the whites turned a little rubbery. I dislike runny yolks though (I like them gummy instead), so I made most of the eggs with the yolk first.

Conclusion

Spherical fried eggs are the future. Don’t try and resist, even though they are far more labor intensive and taste about the same. Still, spherical fried eggs are WAY MORE AWESOME and can be eaten with chopsticks no less. That makes them worth the effort, even if they taste about the same.

Areas for future research

Next week (or whenever I stop being sick of eggs), I think I’ll research SPHERICAL OMELETTES. I suspect they’ll be a bit easier to manage, and instead of worrying about the yolk in the center I can stuff them with things.

I spent a day and a half comparing Cappuccino and SproutCore, two web frameworks for creating pretty stunning desktop-like web apps. Long story short: I’ve decided to use SproutCore instead of Cappuccino.

First, some background. I’m currently prototyping a startup idea. Like many such ideas, it’s very aspirational and a bit vague, but I’m certain that great UX will make or break this startup in the real world. I wanted to start prototyping the UX quickly, so I could work through lots of bad ideas until I found the right one.

Cappuccino and SproutCore both seemed to offer me a way to do this, but I couldn’t decide. Both seemed to have aspects that I liked, so I decided to go through both projects’ tutorials and see which I liked best.

Cappuccino

I started with Cappuccino, because I felt it was the most likely choice for my project. The sample apps seemed really impressive, and I’ve been working with iOS a lot, so Objective-J was no barrier. Objective-J in many ways seemed far more familiar and recognizable than many of the OOP hack jobs that have been written for Javascript.

Things started to go downhill from the start though. To some extent, my experience could have been made smoother with better written tutorials and documentation. Installation was a little confusing if you don’t download the starter package. I opted to use Tusk, since the starter package is nearly a year old and I wasn’t sure if it was up to date (more on this later). But my first problem was figuring out what Tusk was, where to download it, etc. Cappuccino is actually built on top of Narwhal, which provides tusk, and the Common JS framework. Once I figured out what these projects were, I was actually impressed and excited, but the Cappuccino site leaves you to figure this out on your own.

I’ll spare you the detailed play-by-play of the tutorials, but suffice it to say that they could be better organized. I’ll let these two quotes from the tutorials speak for my experience developing a Cappuccino application: “This may seem daunting, but its [sic] really not that complex.” and “This may seem a bit overwhelming, but if we analyze it in pieces you’ll see that it’s really quite straight forward.”

That pretty much sums up my experience with Cappuccino. The author is right — the intent of the code is straightforward and understandable, especially if you have Cocoa experience. But ZOMG the amount of code needed to build the app was really tedious. All styling needs to be done in code, without help from CSS. As a result, it wasn’t clear how easily it would be to create a distinctly different UX than the default provided. Once I looked again at the apps people have launched with Cappuccino, they all had a distinctly similar look and feel. Also, Cappuccino’s main UI framework, AppKit, is over 1MB! It took a few seconds to load even when I was working locally.

Lastly, I have to ask: what kind of future does Cappuccino have? It feels a bit weird that Cappuccino, effectively a port of Cocoa to Javascript, is now primarily developed by Motorola, who is interested in using it for Android development. There hasn’t been a peep from 280 North since they were acquired by Motorola. Their amazing-looking dev tool, Atlas, is seemingly MIA, nearly two years after it was announced in February 2009. The author of many Cappuccino webcasts and “This Week in Edge Cappuccino” left the community a year ago. There is very regular activity on GitHub (this blog post implies it’s more active than SproutCore in some ways), but Cappuccino felt a bit like a ghost town to me. Hopefully the 280 North guys are just keeping their heads down and getting busy, but it’d be more convincing if they actually launched something.

SproutCore

My experience getting up to speed with SproutCore was completely different than Cappuccino. First, the installation was dead simple. SproutCore is installed through a Ruby gem, and comes with useful command line tools that aid development. The Todos tutorial was also significantly easier to follow, since it highlighted code changes and was structured better. It also covered far more ground — the entire MVC stack — and gave me a much better sense of how I’d actually build something useful.

The experience of building an app in SproutCore was also significantly simpler. Javascript has a lot of warts, but SproutCore uses its attractive features — notably, the object syntax — to great effect. Defining views, data sources, and controllers in SproutCore feels almost declarative in nature, since it is so concise. Hooking it all together is also dead simple, thanks to the impressive property and KVO / KVB systems. The tutorial didn’t cover testing, but I love that testing is well covered by their guides.

After going through the tutorial, it struck me that SproutCore is really a far better application of some of Cocoa’s core technologies than Cappuccino. Cappuccino is a very literal port of Cocoa and Objective-C to Javascript, without taking advantage of any of Javascript’s strengths. SproutCore seems to translate core Cocoa concepts into Javascript in a way that feels very natural. SproutCore feels like Cocoa’s web-based cousin, where Cappuccino seems like an imitator.

It’s also comforting to know that SproutCore is behind a large, shipping web app with a polished UX (MobileMe). Having Yehuda Katz in the community also doesn’t hurt. The new SproutCore Guides site seems to be developing quite nicely as well. In short, there’s a lot of visible community-building going on with SproutCore, at least from an outsider’s perspective.

Conclusion: SproutCore Wins!

I feel bad that I don’t have anything more to write about SproutCore, but my initial experience with it was so smooth that there’s little more to say. My goal was to find a front-end application framework that would let me start experimenting with my own ideas quickly, and SproutCore seems to be that framework.

The big caveat is that I haven’t started yet. I’ll soon discover where they’ve hidden the unicorn poop, but getting started is half the battle, right?

At pretty much every place I’ve worked, the admin area of the site (that secret part of the site that only employees or investors get to see) is built using the same layout and UI conventions as the consumer-facing site. And without fail, they’ve always sucked. They’re downright awful, barely usable, internally inconsistent, horribly laid out, and confusing as hell.

They suck for two reasons. First, developers are too busy building consumer-facing features to make them good. It’s way too easy to put off building proper maintenance and analytics tools when your actual customers are howling.

Secondly, to my main point, the use cases that drive the admin area rarely have much overlap with those that drive your consumer facing site. The admin area is for your fellow employees to get their jobs done, and the consumer site is for customers. Probably due to the lack of time available, developers and designers just cut and paste the consumer site’s design patterns over to the admin area.

Stop it! Seriously. You’re making your co-workers’ lives worse. For 8 hours a day, 5 days a week, they have to trudge through the shittiest code you’ve ever written. The hangover they wake up with on Saturday kills their weekend, and then they have to come back and take it the following week. Don’t do that to them. If appealing to shame or morality doesn’t work for you, consider the productivity loss to your business caused by this crap.

This is a completely avoidable situation these days, thanks to projects like SproutCore that allow you to build pleasant, desktop-like interfaces quickly. Your server-side code will be simpler and easier to maintain, since the admin area will be mostly API-driven, and your consumer site will be better off without a crappy admin interface holding it back.

Trust me, your co-workers are going to love you for this.

My friend Alejandro Crosa recently tweeted his wish that Ruby 1.9 include a ‘new’ operator like in Javascript and many other programming languages:

@nerdyc @ikai I kinda like it too, if 1.9 makes “new Class” work then all my typical javascript errors will disappear

So I decided to show him how to reproduce the new operator using Ruby meta-programming! For non-nerds, or people new to Ruby who might actually use this in real world code — THIS IS A JOKE.

(via utnereader and poptech):

Kathryn Schulz is an expert on being wrong. The journalist and author of “Being Wrong: Adventures in the Margins of Error,” says we make mistakes all the time. The trouble is that often times being wrong feels like being right. What’s more, we’re usually wrong about what it even means to make mistakes—and how it can lead to better ideas.

This talk is probably the best way I could ever hope to explain what it’s like to write software to a layperson, or at least how writing software changes your view of the world and yourself. It’s also a great way to show why agile engineering teams work better than lone cowboy coders.

To write software is to be wrong. It’s not just that computers are anal about syntax, the problem you’re solving is hard, or that the tools to write software suck. The act of converting your abstract ideas into precise working code shows you just how fuzzy and half-assed your idea really was. Like Schulz implores us to do, good programmers take being wrong as feedback on how to be right.

When I first began writing software in high school, I remember spending most of my time convinced I was right and the computer must be wrong. I did silly things like testing whether the computer could properly perform addition, because clearly computers suck at math. But in every case, it was always my code that was wrong. Always. Once I got past thinking I was right and assuming I was wrong, writing software became dramatically easier.

For those of you without time to watch the whole video, Schulz’ closes by providing an optimistic view of being wrong. Being wrong isn’t the problem, she says, the problem is being convinced you’re right. Just like with my programming skills, an internal conviction that you’re right only gets in the way of achieving actual results. You don’t learn from being right, you learn from being wrong.

She implores us all to externalize the way we answer the question of whether we’re right or not, just like a pilot has a co-pilot, an auto-pilot, a control tower, and an array of gauges and metrics to help him know whether he’s flying correctly. Open-source is mentioned, along with democracy, as a system that can take decision-making away from a single person’s conviction that he or she is right.

Which brings me to agile software development, which I think is a better example of Schulz’ ideas than open-source. Agile software development is a set of methodologies for writing software that I believe have one thing in common. They all expect you to be wrong, all the time, and embrace it. Being wrong is fundamental to being agile, since you can’t pivot quickly if you’re not learning quickly, and you only learn by being wrong fast and often.

The most fundamental way any software team decides whether its code is correct or not is by writing tests — code that tests the performance of other code. Agile teams differ in that they write their tests first, before the actual code to test is written. Tests written after code has been written simply echo back the same logic used to write the original code. They are not independent, and therefore the tests don’t really help you externalize your code’s correctness.

Writing tests first is just the opposite. A test-first approach forces you to think about the problem first, uncover all the horrible edge cases, and determine what external criteria prove the code is correct, irrespective of how the code is written. And since the code isn’t even written yet, the tests always begin in a failing state. They only pass when your code is done, and force you to continually run your tests as you write code. This keeps your mind close to the problem at hand, not some internalized sense of completion.

Schulz’ also emphasizes the need for other people to help you find your mistakes. Doubters, adversaries, or just someone with a different approach or background than you. Whether it’s a co-pilot, a rival, or just someone you want to impress, having others around helps us avoid telling ourselves that we’re right. It also exposes us to other, perhaps better ideas.

In this same vein, many agile software teams practice pair-programming. Two people sit at one computer and write software together, just like Schulz’ pilot and his co-pilot. Perhaps because of the stereotype of antisocial hackers, many people find the idea completely odd. Many, if not most, software developers are also horrified at this idea, since they are used to working alone, without anybody or any tests there to point out their mistakes. They think a pair’s job is to sit there and judge you and tell you you’re wrong.

They’re only half right. Your pair’s job is definitely to tell you you’re wrong, but that’s only a problem if you haven’t accepted that you’re wrong all the time. At the end of her talk, Schulz quotes Richard Rorty: “To accept our own fallibility is to embrace ‘the permanent possibility of someone having a better idea.’” Good pairs should live by this quote, since pairing is fundamentally a collaborative, creative experience that exposes you to new ways of thinking, approaches you’d never considered, as well as just a friend to pass the time with. Pairing only becomes nightmarish if you’re pairing with someone too full of themselves to admit their mistakes, or too afraid of being wrong to share their ideas.

Pairing and test-first development are together the core principles I believe form the highest art of software development. Testing alone, even when writing the tests first, can prove whether our hypothetical pilot can correctly land the plane, but they can’t prove to you that he’s landing at the right airport. Similarly, pairing without tests are like a pilot and a co-pilot flying together, but without any gauges to help them correct their shared assumptions. Pairing and testing together prove that your code works as expected, as simply as possible, and solves the right problem.

Fundamental to all agile principles and practices is the assumption that you’re going to be wrong — dead wrong — and you’ll need to develop practices that help you answer the question of whether you’re right or not. I’d highly recommend anybody watch Schulz’ talk, but software developers in particular.

(Source: poptech)