This is where it's at:
85% is for pansies; real men eat 99%!
Got it for Christmas...I'm about to give it a go.
Update: If I had to describe the taste, I would go with "solid black coffee", if there were such a thing (not like a coffee bean, but brewed coffee). The texture is a bit chalky/pasty as it melts in your mouth, but not unpleasant. Definitely a unique experience for real chocolate lovers.
Verizon FiOS is like:
Screencap from FileZilla server...
Austin is just an awesome city. There's just something about it that attracts me to it. I can't really say why I like it there so much. I'm not really a clubber or a bar hopper, so the 6th Street Entertainment District really doesn't do it for me (although it was definitely fun to stroll through there with all of the live music and partygoers). I enjoy live music, but I'm not fanatical about it (although it was awesome hearing live music all around the 6th Street area after sunset - from bands on the street to bands in open bars). I like window shopping about as much as any guy does (but it was definitely cool hitting up the row of quirky shops on Congress Ave.). I'm not really a food snob nor am I really picky about what's "good" and what's "bad" (but I must say, the TexMex in Austin simply trumps anything we get here in NJ).
But I leave you with a badass video from the Austin Zoo during Tiger feeding time:
While small and a bit run down, the Austin Zoo is otherwise awesome in that the crowds are small, the commercialization is low, the peacocks are just free roaming...very awesome, and they have a huge collection of large cats (not to mention a black bear display that is practically asking for a lawsuit because you can literally reach your hand in there and pet the cuddly guy).
I am definitely in a funk of some sort.
I've just been completely out of it ever since I pulled a 110+ hour week at the beginning of November working towards the release of the project I'm working on: FCG's FirstPoint.
Now that we're nearing the end of the year, we're getting ready to prepare a release.
I think what I've learned from this process is, surprisingly, the importance of process in software development. That's something I thought I'd never hear myself say (or see myself type). Having gotten my start during the tail end of the startup era in 2000, I've been used to small teams with light processes to promote speed and efficiency. But I think often times, people who don't have experience putting together large projects are all too willing to sacrifice "doing it right" for "doing it fast".
I've always been an advocate, but this go round, I think I might have been too soft and let off of it too soon.
One has to insist on some level of process that defines an overall workflow from conceptualization to realization, even more so for remote teams. Certainly, these processes and workflows should not be set in stone, but they must be considered and they must be documented for the better of the team and progress.
Cooking a meal for 2 is easy enough; most recipes are written this way and most cookware is designed for preparing such meals. But how about preparing a meal for 200? All of a sudden, the scale of it all changes dramatically. One needs larger infrastructure to support the ingredients, larger cookware, larger utensils, more manpower, and most importantly, there must be a process and a "glue" to hold all of these components (cooks, prep stations, servers, dishwashers, etc.) together now and ensure that the components work in unison.
Without process, planning, and infrastructure to support it, such an undertaking will surely be painful and the dishes will likely be served slightly late and a bit cold.
In writing software, the boundary between cooking for 2 and cooking for 200 is a very fine line. It's not so much as how many concurrent users the software will support (although that does increase complexity), but how many features must be included in the software package. When preparing a dinner for 4, preparing a two course meal will be significantly easier than preparing a 7 course meal simply due to the lesser number of ingredients to prep, store, and cook.
With software engineering, all too often, it is simply too easy to go from preparing a 3 course meal to a 7 course meal if scope and feature creep isn't controlled. I think process can help this by ensuring that the introduction of new features isn't simply "hey, I need this new feature, can you add it?" but more involved and includes a thorough evaluation of how the feature fits with the existing feature set, whether it is a "must have" feature (of course the boss always says yes , and planning to consider whether it is part of a larger featureset that can be slated for a later release.
Process defines milestones and encourages visibility to the timeline of the project. It makes the future more tangible. If you know you have milestone 1 in three weeks and milestone 2 in 5 weeks, it makes it easy to schedule a task estimated at 4 weeks of work for milestone 2 instead of trying to shove everything into one giant release. Process defines the workflow for introducing new features in a controlled manner such that features are not introduced in one module that breaks another module since, with the right process, those involved will have long since had a chance to review a rough design specs and will know ahead of time, the changes needed to adjust. Process ensures that code that is commited is well written and written to a common standard. This is done through mandatory peer reviews and knowledge exchanges on regular schedules.
But in any case, 'tis a lesson learned.