Over the past couple weeks I’ve had issues getting my OSX 10.5 iCal client to continue working properly with our centralized CalDav server. I stopped being able to invite other domain users to my events as well as reserve “locations”, despite all my personal (non-domain) calendars continuing to work properly. I noted these iCal errors in Console.app…

*** -[NSConcreteTextStorage attributesAtIndex:longestEffectiveRange:inRange:]: Range or index out of bounds

CalDAVOperationQueue tried to dequeue operation <CalDAVScanDropBoxQueueableOperation: 0×174eb6a0> but it was not at the front of the queue.

When I tried to delete my domain account within iCal’s preferences, the application hung. When restarted, I could no longer bring up the preference dialog and saw this error repeated in Console…

*** -[NSURL initWithString:relativeToURL:]: nil string parameter

Apparently deleting everything in ~/Library/Calendars and starting fresh is the easiest solution. I have years worth of notes and interesting tidbits that I need to keep, however, so simply deleting all my data was not an option. With some educated guesswork, trial and error, I discovered that the following steps seems to make everything work again without apparent data loss or corruption..

1. Quit iCal.
2. Go to ~/Library/Calendars and backup the entire directory, just in case.
3. Delete all “Calendar Cache” files as well as any directory ending in “.caldav”.
4. Start iCal.
5. It may give you a progress dialog about “Upgrading Calendars”. I think this means it’s rebuilding the cache file.
6. Go to “iCal -> Preferences…” and delete/readd your domain account.
7. Wait for the domain account to resync and you should be go to go.

Hope this helps!

See, all my life I’ve been in performing musical groups–rock bands, solos with larger concert bands, marching bands etc.–so despite being introverted to a fault, I’m not easily intimidated by anything in the “performing arts” category, and am usually up for giving things the old college try. Within the past couple years I’ve become accustomed to speaking regularly at various city events, local tech groups, conferences etc., so I initially shrugged off the preparation as something I could bust out in an hour or two over a Heineken… or two.

I was wrong.

Now, I’m not dumping this information on you because you need to know my life history, but to strongly emphasize that even if you took Public Speaking in college, have performed literally hundreds of times in public, and have plenty of real-world speaking experience…

Preparing for Ignite is different.

It’s a wonderfully unique and fun experience, but I put more effort into my five minutes of Sun Tzu: The Art of…Business? than I usually do for 30-45 minutes of less creative informational content. Let’s look at why…

(1) Delivery timing is your biggest risk of failure.

Ignite fully automates the progression of slides; you cannot control advancement to give yourself even +/- 1 second. Also, for Phoenix at least, there’s neither a warning for how much time remains on the current slide, nor a preview of the next slide. If you’re accustomed to board-room style speaking with a forgiving remote, secondary screen full of notes/widgets, and 5-10 minutes of “padding” at the end, the Ignite format is a cold glass of water to the nether regions.

With a remote, keeping your verbal momentum lined up with slide advancement is relatively easy. You know exactly when your verbal punchline is going to come, and just hit the remote a split second before you say it. But in Ignite, the only way to get your voice and slides anywhere even remotely in the same synchronization ballpark is to practice the bloody hell out of it way ahead of time.

And when you’re done practicing, take a break and practice some more. Practice going slower and having to catch up. Practice going too fast and having to ad lib a few extra sentences here and there to fill “dead air”. Practice without any “next slide” or timing aids. Lather. Rinse. Repeat.

This is not to say that you should script the entire thing. Scripting sounds unnatural and dull. You should, however, know the subject matter inside and out, and know the outline and “story arc” of the presentation so that when you stumble on words or get out of sync, you’ll be able to recover.

For the audiences standpoint, your level of preparation will be abundantly clear. It’s obvious who didn’t have a verbal outline prepared; who didn’t practice for pacing; who did prepare but can’t handle being over/under time; how generally hard it is to time yourself versus a computer.

And much of this practicing should occur before your slides are due.

(2) Your slides need to be completed waaaay in advance.

Ignite isn’t the only event that requires final decks to be submitted in advance, but I know that many of you are in the habit of staying up ’til 4am day-of putting the (hopefully) finishing touches on slides. You can’t do that. The Ignite superheros need your slides early to prepare their technical voodoo, and asking them to update a few slides at the last minute would be very, very lame of you. Getting your slides prepared and finalized early is critical since you can’t practice delivery without them, and once they’re submitted you should assume that you can’t change them.

Get peer feedback before you submit your slides. My thanks goes out to Erica, Ben and Marc at OpenRain for providing the “you’re trying to say way too freakin’ much” feedback … it made the end result much better than it would have otherwise been. Peer review is always difficult to do, but discovering why you’re epically fail-sucking is the only gateway to improvement.

(3) You don’t get to rehearse in the venue.

The Ignite (Phoenix) folks want to keep your delivery fresh, natural, and full of adrenaline to showcase your passion. This is a good thing. Just be aware that you probably can’t walk out on stage beforehand for a quick run-through by yourself.

(4) Your bar is high.

In general public speaking, the audiences wants you to succeed. And when you’re speaking to an audience that is present for your message–such as Ignite–they’ve already built expectations of how awesome your message and delivery will be. If the message(s) couldn’t sell, there wouldn’t be an audience. You are expected to be awesome.

I’ve yet to meet anyone that says “Ignite sucks”, but have heard plenty of “Oh, it was awesome, but remember that one guy/gal? He/She was horrible.” Don’t be that guy/gal whose idea of originality is to do zero preparation and just “wing it” or divert from the slides in a otherwise distracting, unprofessional mess. People come to see great ideas from passionate, knowledgeable people, and it’s going to take some work to get that across in Ignite’s concise format.

Ignite preparation checklist. (Sorted by due date.)

1. Well thought out proposal submitted.
2. Talk accepted.
3. Slide draft and verbal outline complete.
4. Peer rehearsal and feedback.
5. Adjust.
6. Final sanity check.
7. Submit final slides.
8. Practice.
9. Sit in parking lot for 15 minutes before event practicing by yourself. (Strange looks from passers by expected!)
10. Be excellent.

You have the idea and the passion. Now go show us! (Just keep it brief.)

The MinoHD is a 720p, 30fps, all digital video recorder roughly volume equivalent to an iPhone: thicker but narrower. Video is encoded in variable bit rate H.264 with AAC audio. (Perfect for use on a Mac.) 4GB of internal flash memory holds about 60 minutes of video, but the storage is neither removable nor interchangeable. The battery is also internal, and charges from the USB connection automatically. A tiny color LCD screen allows for playback and deletion of recorded videos, and provides no special recording effects such as useless cheesy color filter nonsense typically present on consumer camcorders. Costco retail pricing is $179.

Recording a movie is as simple as turning it on and pressing the big red button. Hit the big red button again to stop. It took me approximately 10 seconds to master the process. (An intelligent dog could be trained to do the same if the buttons were bigger.) Use of the “FlipShare” software is not required to transfer video off the device. Just plug it in to a USB port and move the files off. If you choose to use FlipShare, it provides basic video management and editing capabilities, and appears to be necessary to update the MinoHD’s firmware. I’m using FlipShare for now, but like the option of not using it.

Pros

• H.264/AAC.
• 720p.
• USB connector built in. (No need to carry a cable.)
• Inexpensive.
• Rediculously usable.
• PC/MAC friendly.
• Solid-state.
• Light and small.
• No special software required for day-to-day use.

Cons

• Less than 1080p.
• No built-in light.
• Cannot upgrade flash storage.
• Battery cannot be changed.

Verdict

Highly recommended for those wanting a cost-effective HD camcorder for light, periodic use.

Lies (Preston Lee, 2009)

In Times Of Trouble (Preston Lee, ~2008)

With Whatever Time Remains (Preston Lee, 2009)

And because of my undying love for you, Ms. (Mr.? :( ) random person on the internet, I’m going to share something with you that I’ve never shown anyone publicly before…

My company’s first commercially available product: The Online Business Platform from OpenRain.

OpenRain’s managing superwoman may have had a small stroke when I told her she had to produce and post-produce this video, but I think I made her feel better by offering to take all the credit if it turned out well. I’m disappointed that the stunt scenes and Clive Owen guest appearance didn’t come through, but… recession and all that… or at least that’s what I inferred from her half-paralized drooling. So without further ado, please enjoy this awesome video demo of the Online Business Platform that I did all by myself… or not.

• Concurrency Using Threads – [slides] [sample code] (Many thanks to Jim Weirich for the original Keynote slides and example code.)
• 3D GUI Development With ruby-processing – [slides] [starfield] [twiverse]

• Increasing personal productivity.
• Reducing defects.
• Minimizing misinterpretation of requirements.
• Improving designs.
• (Many other benefits.)

As a developer, pairing make mountains of sense. Most tasks in the development world can be improved in a direct, obvious way.

The business perspective, however, is somewhat different. While any give client or manager will say “yes” if they want to see the above occur, a pragmatic developer presenting pro-pairing arguments must, more importantly, provide evidence that stakeholder–not developer–outcomes improve. Let’s look at a few different stakeholder perspectives individually…

Return on investment.

The common pro-pair argument of “increasing personal productivity” is, unfortunately, a deceptively irrelevant point when it comes to ROI. Business stakeholders will always want to increase productivity, but only if it improve project value per dollar, ceteris paribus. Individual productivity and overall ROI and not always proportional… but we’ll get back to this in a minute.

To play devil’s advocate, let’s create a extreme, cynical analogy by playing stakeholder to a small project that can be run in one of two ways…

1. Two expert developers arduously working for 2 man-months to complete a small project for a total business cost of $20K.
2. One hundred college interns assigned into 20 5-man teams, each trying to create a solution equal to or better than the above team could, estimated at 100 cumulative man-months (50x the development effort, but free because they get college credit) plus one man-month of project management and a half-man-month of additional overhead to simply identify the best developed solution. Total cost: $15K.

Now, this latter case is clearly an extreme fabrication of how real-world projects run, but does highlight a Occam’s Razor-like rule for business types…

If presented with two approaches with equal outcomes and equal risk, chose the cheapest. (Aside: This is not argument for crowdsourcing.)

In the latter case, overall productivity, code quality of a random line, design quality and other factors from a random intern will be horrendous. We’ll probable end of throwing out at least 95% of the code. But here’s the kicker… it doesn’t matter. From a business perspective we don’t care about the 95 interns that can’t tell a hard drive from an iPhone. (It’s a problem for another day, at least.) We do care about the 5 brilliant interns that teamed up, overcame the mediocrity of their peers, created something truly magnificent, and saved the company $5K. Despite bad individual productivity, the overall outcome is positive and at an overall lower cost. If we had to apply Preston’s Business Razor to this scenario, there is a clear winner, and it’s not the “ideal” one.

Why is “two” the ideal number?

It’s not… except when it is.

In economics, there are a series of concepts related to production possibilities, allocative efficiency, Paredo efficiency etc. that can be applied to engineering: using a group of individuals to maximize the production of various outcomes with limited resources. Here’s a simple empirical experiment that you can run using a group of 15 people and a good 30 minutes that touches on some of these concepts.

1. Print out instructions on how to make an origami cube, give them to each person, and make sure everyone can make a box on their own. Instruct everyone to make as many fully-assembled, respectable boxes as possible in 5 minutes. Some will be great at it, others less so, and maybe a few that just can’t do it. Don’t count the crappy-looking cubes. Figure out the average time to build a box across the group. This is our “baseline” number that we’re going to try to beat.
2. Break the 15 people into 5 groups of 3. Each team of 3 will now produce boxes assembly-line style, requiring each member to master specific parts of the process. Measure the production capabilities of each team in 5 minutes and again find the average time to create a box across the entire group.
3. Reform everyone into 3 groups of 5. The assembly lines will be longer, requiring everyone to become even more specialized in their responsibilities. Again let the groups run for 5 minutes and compute your output.
4. Lastly, form the entire group into a single, massive assembly pipeline of 15 people. Time the group and compute your output.

We now have 4 data points in how to maximize the production of the group, as well as some interesting observations. First, in all likelihood, the best overall production probably came in one of the middle two trials. People were forced to specialize, but not overly so to the point of awkwardness. Second, having 15 people do a task with less than 15 significant steps is really awkward. People specialized to the point of meaninglessness; issues in the pipeline blocked way too many people; the shear overhead of literally moving paper around defeated the point of specialization. Third, each group had its own characteristics. Some may have been so productive that they blew away the baseline quota, while other in similar sized teams simply could not work together due to process issues, personality conflicts etc. Each group probably also adapted within those five minutes to maximize the groups output based on who was faster/slowest, and best/worst at folding. Some groups may have created a “manager” role to correct critical pipeline issues, pitch in a few folds when someone gets behind, or fix the “broken” boxes. When in a massive 15-person pipeline, some may have gotten frustrated and wanted to split back into smaller groups.

Let’s put it into a real-world perspective by taking an arbitrary task from an issue tracking system: “refactor foo to support bar.” This task has it’s own optimal number of concurrent developers that will be unique to the team. For a group of interns, maybe it’s 5.5; for a team of superheros, 1.2; for my team, maybe 2.4. This specific task and specific team has its own distinct production characteristics (even though the task only needs to be done once), and only in very rare cases will the optimal number of people assigned to it be exactly equal to 2.0. The point is this…

Asserting that a “pair” of people is always optimal is just as absurd as asserting groups of 1, 3 or 4 are always optimal.

The number is unique per task, per project, per team, and understood outside of computer science when looked at from a businessy economic perspective. So from a stakeholder viewpoint, use of pair programming is absolutely acceptable (and even preferred) when optimal over other options.

Experienced engineers inherently understand that some tasks require multiple minds to collectively discuss difficult challenges, debug complex code etc., and don’t hesitate to seek additional eyes when it feels right. What we should not do is cling to the notion that “2″ is a magic number that should be used without contextual consideration. Maybe it’s 3… or 1… or 7… there is no universal constant that can predict this number, and it’s ok that it varies per task.

So for now, let’s put aside this arbitrary “2″, and instead rely on our experience, higher-level intuition, business strategy, basic metrics and strong understanding of our peers strengths and weaknesses when deciding when to pair.

Preston

There are several areas of this post in which he has taken issue. Since many people have already read this post I am hesitant to silently change copy, so for readability purposes I have highlighted that original copy in bold, followed it with additional personal commentary in square brackets, and Todd’s verbatim remarks in curly braces.

—-

I’ve avoided writing on this for a year and a half now, but have been pushed to do so by several inquiring minds over the past year and a half not affiliated with the company. Some documentation on this can be found in public record, and some not. I will note the points on which I’m speculating. None of this information is covered by any NDA I am under.

The company under discussion is generally known as “FonWallet”, though the official legal entity has changed numerous times and is fairly tangled in the personal affairs of one of its owners, Todd Coulter. {Todd, April 16th, 2009: “This is totally false, inaccurate and easily proven”} [Preston: April 26th, 2009: When I first became involved in the project, most important assets at the time seemed to have direct ties to Todd, personally, rather than the company: such as bank accounts, server assets, and vendor accounts.  At the time, at least, there were a handful of different entities that all centered around Todd... A few I recall were FonWallet Payment Solutions, Inc., FonWallet Payment Solutions, Ltd., MBXIP, SipCellNet... possibly other I do not remember. I do NOT have detailed knowledge of the activities of those additional entities, nor do I make ANY claims as to how--if at all--they currently relate back to FonWallet. Also note that I still have the original stock certificate log books for FPS, Inc. and FPS, Ltd.] I have neither vindictive nor harmful wishes against anyone affiliated with the company: only to be compensated for my work.

I personally performed a significant amount of work for FonWallet, at the time know as FonWallet Payment Solutions, Inc. and now known as FonWallet Transactions, Inc., largely in the first half of 2007. It is a startup operated largely in Phoenix. {Todd, April 16th, 2009: “This is again totally false, inaccurate and easily proven”} [Preston: April 26th, 2009: I personally know more than a few people of current and former involvement with the project that are local to the Phoenix area. Whether or not Phoenix represents a majority of the projects cumulative efforts, I do not know: simply that there is a significant amount of work being done in Phoenix. With regards to the entity primarily associated with the project, all current documentation I can find--including the FonWallet.com website itself--leads me to believe that "FonWallet Transactions" is now the preferred nomenclature. This could be wrong, but from the perspective of a reasonable outside observer, this definitely seems to be the case.]

Employees/Contractors of the company were initially paid as promised, however, dollars dried up around summer and most of the concurrent staff stopped received compensation. The only reason some of us stayed on as long as we did was due to a personal guarantee made by Todd Coulter to personally cover the staff debts if the company was not able. Soon thereafter I moved on. Others stayed. As far as I know, none of the compensation owed across that period has ever been paid, even though the company has been in operation under a new name. I am aware of at least 2 others people owned money by Todd Coulter, personally.

Mr. Coulter eventually became completely unresponsive to inquiries on the matter, which prompted me to file suit. (AFAIK I’m the only that did so.) Mr. Coulter did not respond to the suit. A motion for judgment was made on 12/12/2007, and ruled upon in my favor shortly thereafter.

Two suits were actually filed, with myself (Preston Lee) as the plaintiff for both. The first names FonWallet Payment Solutions, Inc. as the defendant with a ruling of $71,324.32. The second names Todd Russell Coulter personally as the defendant, with a ruling of $24,044.32. The sum total is $95,368.64. I suspect that the company name change was made, at least in part, to avoid having to pay these debts.  {Todd, April 16th, 2009: “This is totally false, inaccurate and easily proven”} [Preston: April 26th, 2009: This is purely speculation on my part, and to be honest, I hope is completely wrong. I do not have insight as to the specific reasons for the creation of a new entity (FT, Inc.), except for the knowledge that the old one (FPS, Inc.) was out of money, had a ruling against it for $71K., and the stock books were were in the possession of the guy (me) who filled suit. Again, I hope I'm wrong about this, but I haven't been provided with any reasons to believe otherwise.] To the best of my knowledge, Mr. Coulter was properly served on both accounts but neither notified the other owners of the company nor made attempt to respond to the suit.

Regardless, the latter ruling still stands, and I have tried numerous times over the past several years to settle the matter and collect compensation for the months of work that I am personally owed. I wish all those affiliated with the company the best of luck, however, this matter is certainly not “closed”. There are some interesting and challenging concepts involved and I wish the staff the best of luck. I write this note as a friendly, public attempt to settle this matter once and for all.

Relevant public legal documents should be available from the County of Maricopa, Arizona. If anyone–specifically Todd Coulter–would like to the discuss the issue with me directly, you can reach me direct via email or my cell.

The problem is an unaddressed gap in requirements between concept and action. In the customers mind, the concept may be clear. They may have a mental concept of what a Foozle is, what it means to the business, and how it will interact with the rest of the system. They may even have a GUI mockup laid out in mental Photoshop securely filed into the right hemisphere of their gray matter. As the developer, however, you don’t know any of this, and cannot act until you’ve figured out what the fooz you’re supposed to do.

The temptation in this situation is to pick up the keyboard and start coding according to your best guess of what the customer should have explicitly specified, since it’s not possible to reach him/her and you have to deliver something before they return. So you add a “foozles” table to the database, create some forms, tie it into the search algorithm and write a robust suite of regression tests. You are now the de facto project expert on Foozle and Foozle-related issues, and are pretty freakin’ proud of your work. The milestones completes, Foozle support hits production and it’s all good.

The customer returns from Jupiter delighted to find their feature request ticket resolved as successfully completed. They check out the work, and gaze wide-eyed upon the screen. Squinty eyes and an emoticon-like frowny face ensue, and all hell breaks loose. Sound familiar?

Yes: there has been a clear and obvious failure in process and communication. You–the developer–probably even muttered this when the issue hit your inbox, but let’s just assume that this particular real-world situation meant that the “proper” process wasn’t followed for legitimate reasons and you certainly weren’t about to twiddle your thumbs for two months waiting to meet with the customer upon return. Fail? Yes. The customers fault for hit-and-run management? Probably. But could you have handled the situation better? Yes! Let’s look at what could have happened to make an unfortunate situation a little sunnier…

When you first started thinking about the issue, you made the same mistake as the customer: you jumped from concept to a mental action plan without communicating the assumptions under which you made it. You formed your own mental concept of what a Foozle is, what it means to the business, how it will interact with the rest of the system, and created your own mental mockup. Unfortunately, all your concepts and conclusions ended up being completely different from the customers (since you couldn’t discuss them), and none of these discrepancies were discovered until delivery.

For our purposes, the interesting part about the situation is not that the lack of clear requirements prevented delivery of the “correct” system (according to the customer), but that you did not state your mental assumptions about Foozles  because your instincts told you it was a pointless exercise. The customer was on Jupiter and couldn’t possibly respond on time, so why bother? …right? Quite the contrary!

It is critically important to document assumptions on unclear requirement–especially when the customer is absent–because it places accountability of correct feature development back on the customer. What if your first reaction to the situation was to add a comment to the issue like this?…

I’m going to accept and attempt this issue, but I can’t find any detailed information on what needs to happen and REALLY need some customer time (~1-2 hours) so I know I’m going in the right direction. Not having this information leaves me with a LOT of fuzziness on what the expectation are, so here’s what I’m going to do…

[Explanation of your approach to the problem, explicitly making and stating assumptions as necessary in lieu of clear customer requirements. If you need a definitive answer that you can't get, explicitly define one as an assumption so the reader knows how you're getting from high-level concepts to lower-level action.]

If any of this is incorrect, PLEASE ping me IMMEDIATELY. I’m going to start development soon and want to definitively understand the intent of this ticket to avoid wasting time!

Your assumptions could be wrong. Really wrong. They could be so wrong that you’ve wasted 100% of your time because the customer made a typo and meant “Woozle”, not “Foozle”. The key difference is that you’ve been proactive in specifying missing requirements and gave the customer a non-confrontational opportunity to clarify their intention so you can Get It Done Right. Your clear, wrong assumption statements on Foozle concepts should–if the client was fulfilling their obligation–have triggered an immediately phone call from the customer. It didn’t, and that sucks, but given a tricky situation you’ve done pretty much everything you can do to assure the system is correct (short of a high-speed intergalactic chase to flag down the customer), and of that you can be proud.

In the best case, someone familiar with Foolze semantics will chime in to represent the customer until they return. In the worst case, the angry customer call will at least go much better since you can point to your desperate pleas for clarification on specific items, timestamped in a timeline manner before any of the “wrong” work was done.

1. You are building something greater than the sum of its parts.
2. You set the mission, vision and values.
3. You define the right people, right roles, and right rules.
4. You will push constantly to explore and learn to think outside your comfort zone.
5. You will often fall, but consistently stand up stronger… usually.
6. You will grow leaps and bounds professionally and personally.
7. You will come to understand the wisdom of those you admire, and fear.
8. You are pursuing your dreams and will pity those that lack the courage to pursue theirs.
9. You have no limit to your possible successes.
10. You are the driver of your destiny.

I’d also like to emphasise that none of these items are directly focusued on the immense financial wealth of which we all hope. Over time wealth may or may not come, but the common factor amongst all great entrepreneurs is the primary importance of personal satisfaction regardless of monetary riches. At times–and during all stages of business–progress can require a certain amount of financial masochism and sacrifice, yes, but always should you be proud of what you’ve done, where you’re headed, and excited for the treasures of the next day.

The JLBC’s February 12, 2009 budget update puts “January revenues 21.5%…below [fiscal year] 2008″, for a cumulative 2-year decline of 35.9%. ”January results [are] significantly worse than expected”, says slide 4 of the report. These numbers directly translate to additional lump-sum budget cuts for state-funded programs, including the Arizona University System.

Layoffs in the private sector worsen the situation via a direct reduction in state sales and employment taxes. In a 2010 appropriations hearing presentation also released yesterday, the committee discussed specific cuts to a page-long list of Arizona institutions. A 2010 option for reducing the Arizona University System budget calls for a $160.6 million lump-sum reduction. “ABOR and university system received a combined $141.5 million lump sum reduction [in 2009].” Such changes would affect Arizona’s Arizona State University, University of Arizona and Northern Arizona University despite higher projected enrollment numbers and tuition increases across the board. Arizona State leads in projected enrollment increases at 4% in 2010, with 15% at the East campus. Arizona University System tuition prices have increase an average of 8.5% annually since 2004.

The effect? All employees and families of the state of Arizona are nervous to find out, as “[c]urrent forecasts can indicate the direction of the economy, not its precise landing point”, to quote the 2009 update report. The nightly news will likely continue to cover layoffs, salary cuts and sob stories for Arizona not-for-profits for the foreseeable future, and it seems unlikely that a “quick fix” will restore budgets to previous levels as existing layoffs and budget decisions cannot be quickly recovered.

Please tell me I’m wrong.

Preston: Hi Bill, nice to meet you. How can OpenRain help you develop your online venture?

Bill: I have a unique web startup opportunity worth $4B and am accepting HTML experts to implement it.

Preston: [immediately suspicious of the phrase "HTML expert"]   Ok, you have my attention. What’s the business plan?

Bill: It’s essentially a combination of eBay, Facebook…

Preston: [senses where this is going]

Bill: …Slashdot and TheSuperficial.

Preston: It’s a news and auction site for celebrity social networks?

Bill: No no no, it’s more like Google meets MySpace.

Preston: Like.. Orkut?

Bill: Kinda, but simpler.

Preston: [completely confused]  Back to the business plan part for a minute. Could you tell me about the nature of the business? Is this an ad-based site?

Bill: No.

Preston: Ahh, ok. Some sort of subscription thing then like Salon or TheOnion?

Bill: No way. Users hate paying for stuff. It’ll affect our bottom line. We’re going to keep it free for everybody. And green. We should probably add a database of sites using ecological products. And videos, of course.

Preston: [now confident of where this is going]  Let me restate the question. Where did that $4B figure come from?

Bill: YouTube was bought out for $18B. Google will be all over this after we capture 10% market share.

Preston: [completely ignores the issues with those two sentences] I see. To be completely honest, I should share a couple general thoughts. [brings up telephone script #4 from personal wiki] We haven’t talked about budgets at all, but I assume this is an equity-share idea, and I’m really honored you thought of us. There are a lot of development shops out there, and I’m happy and thankful we stood out to you. Unfortunately, we’re not accepting equity-based projects at this time for two primary reasons. First–and again all in frank honesty–we have the technical, business and other resources to implement these things on our own without external partners. We have a lot of great ideas, and it makes the most sense for us to pursue them internally. Secondly, it’s our goal to treat employees the way we all want to be treated: with respect, recognition and great benefits. That comes with cash flow requirements we just can’t meet with equity-heavy relationships. I’m going to email you some contact information for other resources you may want to follow up with directly, and I think you’ll find that reputable software engineering shops will share these two sentiments in common as a matter of prudence. We look forward to working with you in the future, however, and we’ll keep in touch periodically to check up on you!

[exchange of pleasantries]

[Keynote] [PDF] [Slideshare] [Code] [Releases]

Ruby on Rails is a great RAD framework. We use it all the time. But one place Rails loses its magic–while not the fault of the framework itself–is with external integrations to legacy systems.

First of all, soap4r sucks. Everyone I’ve seen try to pick it up has gotten frustrated and angry at how awkward it is to write a SOAP client in Ruby compared to Java and .Net tools, which can do the same thing in a matter of minutes. Since RoR IDEs aren’t exactly 1337 yet, we need to put some serious love here as a community to prevent larger companies with heavy SOA leanings from running away screaming.

For some reason, many people seem to think that pouring t3h Rails int3rn3ts into an infrastructure will suddenly trim 75%+ off all development and maintenance costs, complete with rounded corners and shrink-wrapped buttons. Wrong. Many of the development tasks will take significantly shorter times to develop under timeframe expectations relative to Java and .Net, yes, but you can’t avoid costs associated with migrating legacy data and integrating with retarded external systems such as your ghetto-ass SOAP services. Nor should you avoid design activities such as usability analysis or proper testing practices. 

So if you have a web project that lives in complete isolation and does not have any legacy issues with which to deal, OpenRain can bust out that web project in a heartbeat. But if you have unresolved data management and integration issues, there is no acts_as_silver_bullet plugin which can save you the burden of having to actually think about and address those problems. Rails isn’t the cold bucket of water for your data nightmares.

My personal hiring strategy, while admittedly skewed towards finding only top tier entrepreneurial people, follows these steps..

1. Go to the core of The Right Persons culture. Forget about the “Java” checkbox on Dice.com. Figure out what The Right Person does online, and go there directly. Post a Java job to the local JUG mailing list, or a Ruby job to the Ruby talk group, for example. Only people genuinely into these topics sign up for mailing lists and forums, so by going straight to the cultural center of the ideal candidates interests you’ve already filtered out the dingbats who would apply just for the sake of applying. The Right Person is probably already employeed and thus would not be checking monster.com anyway. Allow HR to apply their own filters after you’ve identified the right culture.
2. Evaluate their communication skills via email and phone. When was the last time you read an uber-competent technologist who ended every sentence with three exclamation points and a smiley face!!! :) Yeah.. me neither. The subtleties of written language reveal how in touch one is with technical culture. They might have extensive experience with 16 different databases on their resume, but if they can’t explain–in laymans terms–what a database driver does, I can’t see him/her being able to produce well-documented results or be terribly useful in business meetings. Ar-tic-u-la-tion of one’s thoughts in both written and spoken word is critical to effectiveness.
3. Talk about technology in general. I don’t expect you to know the internals of the JVM to be qualified for a Java developer position. I do expect you to keep current on general technology trends and always have your ears open. I expect you to constantly learn and get your hands dirty, and I expect you’ve done some of it on your own time.
4. Ask the right questions. “What type of Exception does Socket.close() throw?” would be the wrong question. Phrase your technical inquires such that they are open ended, recognize that He/She Is Not Google, and allow the respondent to give an intelligent response even if they do not know the answer. Example: “How would you describe the lifecycle of a network connection?” The question is specific enough such that a knowledgeable person can immediately give a thorough answer, but not overly so such that it is a miniscule factoid you’d see on Jeopardy. Also ask questions which are subjective or provide incomplete information, such as, “Which Java OR/M technology would you use in a new web application?“. You’re not looking for a “correct” response, but to gauge how’ll they’ll react when prompted with incomplete, unclear or clearly stupid business requests. Just like the real world. Arrogance and stubbornness can often show through with a definitive answer to such questions, whereas a more pragmatic person might say “It depends.” followed by a diatribe on the pros and cons of various options.
5. Invest the time. Many large companies outsource recruitment because they see it as a secondary distraction to the organizations primary tasks. But the thing is… putting the right people in the right roles is as core to your business as it gets. And for the prices charged by technical recruiters, the $20K+ per head can easily be spent on competent geek personnel dedicated to networking in the correct communities for purposes of recruitment. 

But don’t fret: there are companies trying to change the system. For the time being, however, keep this mind next time you hear an interview going on down the hall…

Organization and role-specific cultural requirements come first; HR policy requirements come second.

I spent the majority of my early childhood growing up with my mother in a single-room add-on attached to the side of my grandmothers house in a Northern suburb of Chicago.

My mother never went to college and worked very hard to keep us financially safe doing jobs such as data entry. She is a very hard worker that gains personal satisfaction from a job well done and was always gainfully employed, so we were never poor in the hungry, homeless or other romantic sense, but firmly lower class, yes. My mom still loves to tell the story of how I didn’t understand you could purchase food without a coupon clipped from the Sunday paper. She didn’t have a lot of free personal time due to being a single parent, but made it work. I don’t think I would handle that lifestyle well, and have a tremendous respect for single parents trying to make ends meet while “being there” for the kid(s). I was even fortunate enough to get a hand-me-down obsoleted Macintosh computer from my mother’s coworker on which I typed school papers from elementary school until high school.

The land and house I grew up in had been established by my grandparents some years after World War II. My grandma grew up on a farm and filled the house walls with rural-feeling nick-nacks and small-town artifacts. The surrounding neighborhood became caught in urban sprawl and began to transform into luxurious mansions settled comfortably on 1-acre lots.

My father is a South Korean immigrant who came to America for a better life, and eventually found his place in California. The balls it takes to pack a suitcase and move to a foreign country with a pocket full of dreams continues to astound me. I recall listening to him confidently lay out his plans to run his own successful businesses as so many other Asian immigrants did in Los Angeles. Looking back on the first 18 years of my life, I now realize…

Having less in an environment of opportunity can be empowering.

When you have less, you feel like you must improve yourself to be noticed amongst peers. No one can fix a situation with a magic wand should you fail, so you must dedicate yourself to tasks because success will not otherwise come. And if you succeed, you’re not stuck with a convoluted sense of entitlement to a world full of subordinate peons. You know exactly how hard it is to make it in life because you’ve seen the sacrifices and tears from your family and friends. You chose your fate, and made it come true.

I enjoy the niceties in life just as much as the next guy (who doesn’t?), but I feel good that I don’t feel entitled to them. I know that if I get a nice dinner or fun new toy, I earned it, and I’m going to be more proud and protective of it than if you just handed it to me. It’s not just another disposable object; it’s mine because I consciously caused a chain of meaningful events resulting in a reward. Push the button, get a treat.

So here’s the deal. If you win the next Powerball jackpot, you get to keep a few million to secure your home, family and reasonable lifestyle, and have some fun while you’re at it. Go for it. Take a vacation on the International Space Station or something. I’d do the same. But you don’t get to blow $5 million in Vegas or $50 million on a toy.

You hire a financial management team and get to work doing something meaningful with your fortune (and your life) by sheltering homeless children, curing cancer, something. Make the world a better place. And if you’re investing wisely, you’ll feed off the inherent greed of the system and use the profits to further your own philanthropy. Keep the compassion, dreams and simple contentment of being poor, and use the power of being rich to change the world.

The fated rich have not such empathy for the masses.

Do not strive to be rich. Do not strive to possess. Do not strive to control. Do not seek admiration of the world. Do not seek approval of authority. Do not strive to be popular. Do not be a pessimist. Do not dwell on the past.

Strive to be wise. Strive to be kind. Strive to be selfless. Strive to be loving. Strive to be more. Strive to do more. Strive to use less. Strive to be an example. Strive to leave the world a better place than you found it.

Strive to redefine humanity.

I’ve been putting off changing my blog permalink structure for about 2 years for fear of getting SEO-smacked by Google. No joke. WordPress allows you to easy change the permalink structure with a few clicks, but doesn’t generate permanent redirect (HTTP 301) responses for visitors using the old link structure. Non-redirection link changes for established blogs extremely unwise since you lose all the SEO goodness with search engines such as Google, so I sat down tonight to figure out how to safely make the change.

The easiest solution is to use the Permalink Redirect WordPress Plugin by Scott Yang. This creates a “Permalink Redirect” page under “Settings” in the WordPress admin area where you may specify the old permalink structure from which to redirect. Incoming visitors to the old URLs will automatically 301 permanent redirect to the new URL structure as expected. Thanks, Scott!

I also tried the redirection features of the Platinum SEO and Advanced Permalinks plugins. Platinum SEO can handle post-specific permalink changes, but not site-wide permalink changes. Advanced Permalinks is no longer maintained and did not work for me within WordPress 2.7.

I recently received a review copy of slide:ology – The art and science of creating great presentations by Nancy Duarte, published by O’Reilly Media. I’m consciously making an effort to increase my frequency of speaking engagements, so I was thrilled to see a modern text on visual aids from a heavy usability-oriented angle. I’ve read the first two chapters so far and skimmed the majority of the remainder.

slide:ology is cleverly designed to read and flow like a presentation itself, although the content is far more in depth than an ordinary slide deck. Each of the 275 pages is a pleasure to look at, and the individual page designs themselves provide a great deal of inspiration. I’m particularly thrilled to see such creative use of negative space and negative geometry in many of the designs. Many texts on marketing effectively use the exact opposite approach.

Pros

• Visually inspirational. Tons of great ideal for your next keynote.
• Useful outside of the speaking domain. Many of the design ideas can be applied to print media and web design as well.
• Good copy which is brief and easy to follow.
• Reasonably priced.
• A great coffee table/break room book.

Cons

• You may have to implement many of these designs yourself. I’d easily pay an extra $5 for an optional download of Keynote templates ready to go, as well as the raw graphics files used in production.
• A slightly awkward print format. I understand why, but it doesn’t fit as well on the shelf as I’d life.

Overall, slide:ology is a great little piece of speaking inspiration by Nancy Duarte. Great job! (I expect more like this.)

Buy slide:ology here.

1) The Pop-Start

The pop-start–short for “popular startup”–is the stereotypical venture capital (VC) or Angel backed venture wherein an initial product prototype is created with a small angel fund, pitched to investors once (barely) operational, and subsequently funded for $1M+ in a second, third etc. round to fund growth to a profitable status. As each round is collected, additional personnel are generally hired immediately to kick off additional production development in a (hopefully correct) high-velocity direction.

Pros

• Should you raise enough in your initial rounds and find the right people, you’ll be able to keep the company operational in the early growth stages without incessant worry on keeping positive cash flow, which, depending on the idea, may not be possible.
• Fast growth once the big investment dollars roll in.
• A minimum of personal risk since only the initial angel round will likely come from close ties. 

Cons

• Tons of investor pitches and marketing/sales-speak on vaporware which will drive technical people insane.
• Legal issues from the get-go. Expect difficult negotiations with second round investors and costly legal fees.
• You’ll have to put up cash for airfare, lodging, marketing materials, legal fees etc. up front for possibly dozens of remote meetings. The costs add up fast.
• Large amounts of constant pressure from investors.

This is for you if…

• Your idea requires a substantial capital investment to get off the ground, such as $100K in federal licensing costs or $500K in manufacturing equipment for a first line of production product. You legitimately need this funding to get off the ground, and the amount is too large to put up yourself.
• Your exit strategy is getting bought out by Google for $100B.
• You can afford the risk of working on this full time, with little (or no) compensation up front and no gaurantees on a second round of funding.

2) The Weekend Warrior

The proliferation of online services for company creation has allowed many dreamers to create legitimate legal business shells in free time for hundreds of dollars. The weekend warrior start-ups are those who believe in the idea, but cannot financially afford to quit day jobs.

Pros

• Low risk. If the company fails, you still have your day job.
• Low cost. You still have the income from your day job, so eating small operational costs should be easy. If you’re supporting a large family on a single income, this may be your best option.

Cons

• Making progress is painfully slow since it’s an “in my spare time” project.
• People will not take your business as seriously since you are not committing your livelihood to it.
• The logistics of getting things done off-hours can be challenging, such as finding the time for calls during business hours without interfering with your day job.  

This is for you if…

• You can only commit yourself to working nights and weekends.
• You cannot accept large financial risk.
• You do not require large capital investments to reach financially sustainable operation.
• You can accept the fact that progress and growth will be slow.

3) The Self Serve

Self Serve businesses are full-time owner operated organizations which grow based on their own performance, rather than external investment. They are self-funded, full-time ventures which put the responsibility of success squarely on the owner(s) since there is often no formal governing board. OpenRain’s web development business started this way, and continues to be entirely self funded.

Pros

• No pressure from investors.
• Full-time personal investment gives you time to put operations in order.
• Will be taken seriously by potential clients/customers.

Cons

• Self-funded. This can be mitigated by limiting personal credit exposure, but there’s no getting around the fact that initial operating costs will need to come out-of-pocket, and losses may personally bite you regardless of the precautions you take.
• Personal pressure to constantly generate income since your personal income will be determined by the performance of the company.

This is for you if…

• External funding is not appropriate or necessary for your idea.
• You (and you business partners) are comfortable operating the entirety of a business amongst yourselves, our are able to invest in quality people to fill in the holes as soon as possible. Technical work, finances, marketing, sales, human resources, operations and 8000 other miscellaneous tasks will crop up needing someone’s attention. And that someone is you.

I’m unhappy because I picked them up tonight to run a very infrequent backup of all my household data: over a TiB worth while requiring the use of all of them for a complete home backup. Much too my dismay, I won’t be running any backups this weekend.

Failure rate: 100%. (5 out of 5 failures.)

I haven’t been this unhappy with a manufacturer since the last of my IBM DeathStars failed around 2003. Fortunately all the Seagate models are still under warrantee, but such performance is still disheartening and frustrating.

What’s happened to quality drive manufacturing in the 21st century? Some of the ~10MB hard drives in my 486-era machines easily lasted 10+ years, but a single drive these days lasting over 3 seems ever more scarce. Sigh.

Problem: AT&T won’t switch the phone numbers since each phone is still obligated to its own, separate 2-year contract, and ordering a new SIM will cost you $25.

Solution: I physically went to an AT&T store and explained the issue. The sales rep just had to perform some voodoo in his computer system to enable 3G for the original iPhone SIM so it could be used in the new model and access 3G services. This allows AT&T to avoid having to modify any contracts while allowing you to upgrade to an iPhone 3G and use 3G services.

Done!

After a long confusing Ruby debate today at OpenRain on the merits of functional, Erlang-esque write-once-read-many variables, I’m going to step onto the podium and just say it… Ruby should get “final” or “const” variables in a similar semantic style to Java, except at runtime. Rather than ramble on for 12 paragraphs explaining exactly how this might work, read this fictitious Ruby code snippet instead. (Optional: Also check out the chapter on “final” in Hardcore Java.)

Final variables like this are really just an inline TDD mechanism.

Allowing local stack data to be constant provides no functional enhancements to the software, but alleviates the need for certain types of tests by using the compiler and/or runtime to assert certain memory is immutable. The “friend_best” method variant in the code snippet would obviously break most existing Ruby programs, but ups the bar for defensive programming by preventing many common bugs out-of-the-box while still providing support for traditional Ruby variables. At the very least we should have something like “friend_better”. Adding this information to the parse tree will also make it easier for IDEs to provide features more easily implemented for static languages.

TDD/BDD is in–no qualms about it–but we can make our code safer, cleaner and more concise by applying some of the lessons learned by our statically-typed language cousins over the last few decades.

2008 exceeded expectation, and 2009 will be huge.

We’ll be growing.. a lot. Actually, we’ll most likely need to move again before summer. That’ll be an exciting time, but moving is always a massive pain. I do, however, look forward to hosting larger events without needing to borrow space from other suites in the building. Issues with our current lease notwithstanding, there should be plenty of options. We actually already have our eyes on a space, but it’s too early to speculate on.

I’m feeling great about the team and our opportunities in the new year. We *do* have capacity in January we’re needing to fill (December is not a great time to be signing new web development projects), and have a new business development manager (John De Santiago) to own most of the new relationship development process, freeing my time for things which I’m better suited.

With layoffs in Fortune 500 companies continuing to occur on a regular basis, I personally expect education enrollment and new small business start-up numbers to rise. Apollo Group (University of Phoenix) apparently just had it’s best quarter *ever*. American budgets in general, however, are being cut. It’s hard to say what this means for OpenRain’s web development business, but I think we’ll be fine by increasing attention towards marketing and sales activities.

It’s funny to think I felt the same nervous excitement this time last year, but seeing as 2008 went so well, that’s a good sign of things to come.

I shot my nephews first birthday party this weekend. If these shots don’t make you smile, you may have a degenerative muscular facial disorder all up in the smilin’ region. Seriously… see a doctor.

[flickr slideshow]

Let’s think about this for a moment.

The BBB is supposedly a not-for-profit organization formed to protect and inform consumers on the ethical status of businesses. BBB funding, however, comes directly from the businesses they “investigate” in the form of membership fees. This means the BBB has a direct conflict of interest. An operational company with a clean record and good references (such as OpenRain) has no need of the BBB except as a promotional novelty, and a company with a dirty record has no reason to pay to the BBB save for “cleaning up” their business record. There’s a name for this type of scheme; it’s called protection racketeering and is the same type of “business” performed by mobs. No thanks.

Complete follow-up email below, though contact information changed to protect the mobsters representatives identity. Please do your own research on the BBB and help spread the word to prevent other startups from falling prey to this scam.

—-

Dear Preston,

I enjoyed speaking with you regarding our invitation to become an Accredited Business with your BBB . You will be part of an elite group of businesses who have undergone a review process and adhere to the highest standards of business. I have enclosed our benefit package for you to review and a link to our website. Your annual BBB dues are $445. (This includes the BBB OnLine Logo!) We accept credit card or check by phone for your convenience. Please call me later at XXX-XXX-XXXX and we can take a few minutes to complete the accreditation information. We are the leader in marketplace trust and we look forward to having your company recognized as “BBB Accredited.”  Thanks again and have a great day.

Xxxxx Xxxx | Business Relations Representative

But then…

Microsoft FAIL. Is there a Frequent RRoD Club or something? I feel like I should be accumulating RRoD miles.

• We use entirely too much water. Luxuries such as golf courses in 110 degree (Fahrenheit) heat consume an absurd amount of resources. The Governator officially declared California to be in a drought earlier this year, and Arizona… well… it’s a desert. Maybe we should lay off on the palm trees and grass, hmm? Fighting this hard against the Earth’s ecological tendencies for the sake of luxury is bound to produce the highly inefficient modes of living to which we’ve become accustomed.
• Solar water heaters and photovoltaic collectors will be huge. Output effecientcy levels are increasing, they are approaching blue-colar affordability due to technological improvements and rebate programs, and fall in line with the ideal of consuming local resources.
• We eat poorly, and also consume a tremendous volume of costly non-native food. Foods simply lend themselves better to certain regions and we need to be more explorative of regional food options.
• Gas sucks. We all know it so I won’t go into it :(

This is a snapshot of my own macro-economic sustainability opinions, which change rapidly with the times and fall somewhere between ecological conservatism and hard-nosed financial feasibility.

Sustainable American living activists need to focus on three primary goals: (1) significant cultural change in all socioecominic classes, (2) improving sustainability technologies to produce incentives for #1, and (3) figuring out how to reduce the human footprint in economic context to make #1 and #2 plausible. Specific ideas I would like to see pursued..

1. Focus aggrocultural subsidies away from small rural farms and onto medium-sized, community-run suburban farming initiatives which share equipment and resources. The notion of the independent, middle-American mom ‘n’ pop farm in Smallville will always be romantic, but you cannot ignore the economies of scale. We need to look at the production possibilities curve of farm size vs. output, factor in waste of transportation costs and pesticidal effects, and find a compromise which will allow significantly-sized local farms to produce native or near-native vegitation within a 20-mile radius of urban areas, while not requiring the populous to return to an aggregarian state or douse everything in chemicals. (Not that chemicals are inherently bad: just unnecessary and wasteful in many cases.)
2. Incentivize large-scale adoption of solar water heaters by artificially raising the cost of traditional indoor tank water heaters and using the difference for solar subsidies. It’s ridiculous to spend energy heating a tank full of water in an empty air conditioned home when you could just put a damn tank outside in the sun for 10 minutes and have magnitudes more hot water for free. Sense make that does.
3. Incentivize large-scale adoption of household solar arrays by using artificial energy costs to subsidize payments to households selling energy back to the grid via bi-directional meters.
4. Plausible sustainability change requires working with the existing system. You can blame The Man all you want, but the world is not going to abruptly adopt better principles overnight. Changes need to come gradually–in a way people can slowly accept and adapt to–in incentives facilitated by the government, demand from the people, and interest of the industry.
5. Ceteris paribus, chose local products and services to keep money in the region and reduce waste.
6. Recycling costs cities too much. Trashing stuff costs citizens too little. Residents should force the issue with their municipality and compost the sanitary organic waste.
7. The food industry needs to stop wrapping every last item in a silly little shrink-wrapped cardboard box and sell everything OEM-hard-drive-style. That is, make one box for the display, but sell the product in an extremely minimalist biodegradable packaging. This will be (1) easier on consumers since there’s less trash to deal with, (2) better for the environment, and (3) cheaper for everyone. You can put as many bright colors and wacky content on the display as you want, as well as print on the biodegradable packaging.

Photography is about contorting perceptions of reality. We want to believe the handful of infinitesimally small glorious moments at our weddings, birthdays and holidays represent the way people felt the entire time, when they really only capture less than 1% of the entire event. Don’t believe me? Watch a wedding video. The whole thing. Booooooring. No one really cares about the 45 minute toast or 15 minute car processional out of the parking lot. We do care, however, about the idea of the toast and vehicle processional and enjoy remembering the initial excitement, just not the long tail of boredom. You, as a photographer, thus have tremendous power to influence others perception of events if you teach your camera to lie.

For example, take this photo..

Yuck. It’s your typical crap run-of-the-mill shot you’d see on flickr, and I don’t feel anything special when I view it. It’s true to reality, which isn’t interesting. Now take this next shot…

Not fine art, but much better: not because the situation or environment changed, but because we’ve lied about several things..

Movement. Look closely for “lines” formed by different objects in the first shot. It’s a chaotic mesh wherein the eye does know what to focus on. I don’t know what I should be looking at so my eyes are jumping all over the place. Am I supposed to be looking at the water jug? ..the dog? I have no idea. But in the second shot, notice how the diagonal line formed by the bottom of the house and the ground is mimicked by the step up to the door; by the dogs front feet; by the direction the dog is looking and moving; by the orientation of the two dogs. The movement of the entire shot eminates from the top right corner and radiates outward towards the other three. I know what I should be looking at and feel like something is happening because we’re created artificial movement.

White balance. The first photo is fairly accurate in terms of of the ambient light quality. The light was slightly bluish, which also happened to match the physical temperature of being very cold. But I don’t want you to feel cold. I want you to feel warm and fuzzy and giddy about the purdy doggy. The second shot feels warm, like a bright, sunny summer day, even though it was nearly freezing and about to rain.

Color. We’re pushed the saturation levels in the second shot to the extreme, but not quite so far as to detect our fib. Skies are not this blue, grass not this yellow/green, and adobe not this orange. Notice how every object has a distinct complementary color theme which is not intruded upon, as well as the exclusion of purple and red in the central theme.

Framing and cropping. By removing unnecessary distractions, we’re left with only the photos core concept to dwell upon. The negative space of the barren wall, sky and ground have distinct textures but are mostly devoid of objects which would steal our focus from the subject. We’ve tried to frame the dogs according to the rule of thirds, and all unnecessary concepts which could have been removed in the moment, have been.

Conclusion

Good photos are in the eye, not the technology, so you should strive to get great images straight out of the camera rather than rely on post-processing as a crutch. All of these concepts can be executed on a modern SLR and often only require post-processing for fine tuning.

Extra Credit Update! Spot the lie in this photo. (Hint: there’s an object in the room which shouldn’t be there!)

Publishers are also rejoicing, as many have been effectively sitting on completed books in anticipation of today. iPhone SDK Development by The Pragmatic Programmers is already available for immediate electronic download, and an O’Reilly representative has informed me that O’Reilly Media has just released iPhone Forensics.

It begins.

On a related note, I’m reminded of a former Soviet teacher I had in college who shared many thought provoking stories, including the observation, “In the Soviet Union we were all equal…ly poor.”

ABLEconf is a new event so I’m not sure what to expect, though I’d put my money on a lot of systems-level event content since much of the participation seems to be from local Linux groups.

Running Time: ~1:04

My big leap is OpenRain, for which I manage financial planning and performance amongst a bagillion other things, so I frequently receive questions on the financial aspects of forming and operating a company. This failure-based example assumes ExampleTech uses accrual accounting as opposed to cash-basis accounting.

Understanding Your Initial Investment 

When you start the company books, the first type of financial statement you’ll need to understand is the balance sheet. The balance sheet is a snapshot of the company’s finances at a particular moment in time, and aggregates all the company accounts into one single formula which always remains true..

Assets = Liabilities + Equity 

Once you invest in the company, that money becomes a company asset, and is no longer yours. You are only given claim to this money by an equivalent amount of equity. The company is a living, breathing entity, and is considered to a be a distinct taxable entity by the Internal Revenue Service (IRS) if you have formed an LLC (ExampleTech, LLC), S or C corporation (ExampleTech, Inc.). Even if you choose to do business as a sole proprietor (John Doe “doing business as” ExampleTech), which is not a distinct taxable entity, you should mentally consider your initial personal investment gone forever! Don’t event think about mixing personal accounts with business. ExampleTech accounts belong to ExampleTech and are maintained separately from your personal finances. Period.  It’s company money now, not yours, so get over it. You’ve invested $10K in ExampleTech to get it off the ground.

$10K Assets (cash) = $0K Liabilities + $10K Equity (ownership)

Since, the company has purchased $6K of equipment using $1K in cash and $5K on a credit card with an $8K limit (this will be important later). The balance sheet now looks like this..

$15K Assets ($9K cash + $6K equipment) = $5K Liabilities (credit card) + $10K Equity (ownership)

Where did these numbers come from? We have $15K in assets because we started with $10K in raw cash, spent $1K of it and received $6K of equipment in return. The difference is on the credit card as a $5K liability. Some interesting observations…

• You (John Doe) still have $10K of ownership equity even though the company only has $9K of cash in the bank. It would not be possible to cash out 100% of your initial investment without liquidating (converting to cash, a.k.a. selling) the equipment.
• If you bought the equipment out of warrantee and it breaks on day 1, ExampleTech will be down the $6K in equipment assets but would still need to pay off the $5K credit card liabiltity. The loss would come out of cash and leave the balance sheet looking like this: $4K Assets (cash) = $0K Liabilites + $4K Equity (ownership). Oops. On the plus side, you would realize what the term “equity-funded venture” means.
• All book equity is held directly by you, the owner. This is a tremendous advantage over private equity venture capital (VC)-based start-ups, because you are the only person who cares about the eventual return on equity (ROE) investment. By using short-term debt instead of long-term equity, your creditors couldn’t care less about ROE as long as you’re making payments on time, so ExampleTech’s decisions remain yours to make.

ExampleTech is now ready to operate, and opens its doors with a slick new job for ClientComm.

Understanding Cash Flow & Income

After 1 month of operation, ExampleTech has performed and delivered $8K of services to ClientComm. Only $3K in credit card expenditures was need to complete the job. ClientComm has been invoiced and “the check is in the mail”, which should arrive and clear within 2 weeks. ExampleTech is now moving on to a much bigger project for MegaComm. Here’s your current balance sheet..

$23K Assets ($6K equipment + $9K cash + $8K accounts receivable)
=
$8K Liabilities (credit card: $5K initial equipment + $3K ClientComm job)
+
$15K Equity (ownership)

Note that you’ve increase your equity 50%, which is now $15K up from the $10K you started with. Woohoo! Here’s the ExampleTech income statement for the previous month..

Income
ClientComm: $8K

Expenses
Office equipment: $5K
ClientComm production expenses: $3K

Net income for period (last month): $8K (income) – $8K (expenses) = $0K

So in your first month you not only purchased reusable office equipment, but broke even! (That’s pretty awesome, go grab a beer!) Armed with $23K in assets and a renewed sense of self-confidence, you’ve signed MegaComm to a new deal worth $40K which will only cost $10K to deliver. You immediately start MegaComm production by writing a check for the $10K in materials and production costs.

..And you’re about to realize how you just screwed up.

To your surprise, you receive a call several days later that your check has bounced due to “insufficient funds”. What you forgot to consider is perhaps the most important aspect of financial management for the start-up phase of a self-funded new business: cash flow. Your cash flow statement for last month defines the raw dollars going in and out of ExampleTech during the given period, and looks something like this..

Cash at period start: $10K
Equipment investment: $1K
Net cash flow: -$1K
Cash at period end: $9K

In Summary

Self-funding your company comes with the perks of directional freedom, less time pressure and fewer legal complications at the cost of pressure to stay cash flow positive from day 1. The self-funded company cannot grow–let alone survive–without an early, consistent trend of positive cash flow as we’ve just demonstrated. ExampleTech won’t have much wiggle room for strategic ventures and operational improvements until these numbers provide an ample financial buffer.

Next

We’ve glossed over quite a few important details such as taxes, loans, interest, accounts payable and, of course, paying yourself. So if you’ve found this information helpful and would like to see more content on the practical financial aspects of start-ups, let me know you’d like a Part 2 and the specific topics you’d like to know about!

This ups the pressure for OpenRain and the community to release some mind-warping Journeta applications before the conference. If you’re planning on developing a swanky new application with Journeta, please ping me for possible collaboration and/or inclusion into the session. And I thought yesterday’s live demo was suicidal… :)

While you’re on iTunes, you can also grab #68: Marc’s Ruby2Ruby presentation, as well as #48 given last year to the Phoenix Rails group on attachement_fu.

I’ll be presenting at the September 2008 Phoenix Ruby Users Group on Monday, September 8th, covering development of Ruby peer-to-peer applications using OpenRain’s latest gem release, Journeta. Topics will include Ruby’s threading model, basic networking review, Journeta usage, and live demos. 6:30PM, here.

[Location Details] [PRUG Google Group]

See you there!

Ru8y Search

1. I have tons of great ideas that aren’t going anywhere. (..or worse, are getting somewhere but at a pace slower than the end goal is moving.)
2. I really don’t like being told I suck.

Any leader that says they can completely shrug off even the most meaningless criticism is full of crap. Putting yourself on the line by saying, “I did something. Check it out.”, dangles your ego over a boiling pot of water. You know the potential for greatest is there–you wouldn’t have done it in the first place if you thought it was a bad idea–but your heart still sinks when you’re about to demonstrate your competence level to the public at large and have absolutely no guarantees on the outcome. Ego roulette is clearly not an engineers game.

…but then, I decided to change.

1. If I have a great idea and the time/resources to pull it off well, I’m going to look fear straight in the eyes and tell him to STFU.
2. I’m done with looking back and saying “I should have done more.” Whether it’s writing about a controversial opinion or pulling people out of a car wreck, no more inaction. Maybe I’ll collect an inbox full of hate mail or painfully burn to death in a firey explosion. So be it. At least I tried to change the world and did my part to the best of my ability. “You must be the change you want to see in the world.” -Mahatma Gandhi.

Now, I still have the same self doubt and self confidence issues at the next guy, but I finally feel like I’m doing something about it. And doing something is an engineers mantra. I’ve you’ve really got a great idea, it’s infinitely more important than your fragile ego. Here’s a couple of thoughts that may help entrepreneurial pessimists like myself..

• If you screw up on project XYZ, no one is going to care in 5 years. Take the small wins and build on them. It’ll feel good.
• What’s the worst that can happen? ..people will laugh at you? …you’ll loose your investment? …you’ll have to go back to your day job?  Are those the best reasons you can come up with? Really!?  *Please* … If you’re reading this you’ve got food, water, shelter, internet access and probably some good folks to lean on should things get tough. That’s more than most of the worlds population, so quit whining on the $10K it’ll take to do that new project and take a calculated risk. Even failure can feel good when you know you did all you could. You’re going to regret it if you don’t.
• Criticism is the easiest form of feedback, so there will always be haters and sometimes more negative commentary than positive. Learn to extract the meaning from the negative feedback, remember that those with the loudest voices don’t necessarily represent the population, and make it an opportunity to hone your game rather than pity yourself.

While we don’t regularly use titles at OpenRain, we nevertheless have to distinguish senior talent. The core issue is, “How to you objectively identify ’senior’ engineering qualities?” Today we’ll focus on several key factors always present in quality engineers, independant of language and platform.

Instinct

He/She has developed extraordinary technical relevance filtering to the point of being able to scroll through a never-before-seen 500 line file in a language they don’t know, and tell you..

• how complicated the code is.
• where potential bugs are.

Even with no formal knowledge of code smells or design patterns, a senior developer can sense ugly code and architecture from a mile away even if they don’t yet know exactly why.

Foresight

Long-term implications are always on the mind of the Senior Software Engineer. They’ve been through the end-to-end development process (from requirements gathering to product maintenance and end-of-life) numerous times, know what issues are going to arise and will point out a suitable solution long before the symptoms start to appear. (This quality thus becomes most apparent after delivery when work is bombarded with never-before-seen use cases.) The truly elite developer is often hard to identify because they’re solving the important issues before anyone else notices the problem. (Ben is a primary example of this extraordinary perceptiveness.)

Results Focus

Knowledge without application leads to arrogance without insight. Senior developers are always focused on results which stand the test of time and can easily see through posers who fluff their way through status meetings.

Communication

New developers seldom understand the required differences of communication between different types of stakeholders. Newbies tend to treat all stakeholders as authoritative figures, and are quick to lose direction when exposed to people with differing incentives.  The criticality of non-verbal developer communication is also apparent to the senior engineer.  For example, a green engineer may see issue tracking as micro-management, automated testing as an ideological obsession, and project planning as administrative overhead, but these are all monumentally important aspects required to keep all developers and stakeholders in a real-time communications loop, since many do not directly interact. A senior engineer will see these concepts as empowering and often get grouchy when not present because NOT having clear priorities and documentation introduces roadblocks to results.

Time & Priority Management

A senior engineer can more-or-less tell you what their schedule looks like a week out, even if it’s not written down, and won’t be hesitant to express any issues with workload ahead of time.

Estimation

New software engineers seem to invariably produce time estimates magnitudes off from reasonable numbers. The issue largely appears to be one of Foresight since accurate estimates are oft best produced by benchmarking current requirements against past similar project experiences: a task more easily accomplished with experience. This issue is an arguing point against the “Customer is Always Available” aspect of eXtreme Programming since a green developer is generally more likely to over-commit a workload than a senior.

If you installed MySQL using the official .dmg package provided by MySQL AB/Sun and are trying to install the native MySQL gem, you’ll need to pass a bunch of flags to the gem install process to get the thing to compile. Try this..

sudo gem install mysql — –with-mysql-config=/usr/local/mysql/bin/mysql_config

..if you still have issues (check your /opt/local/lib/ruby/gems/<ruby_ver>/gems/mysql-<gem_ver>/mkmf.log file), try this instead..

sudo gem install mysql — –with-mysql-dir=/usr/local/mysql –with-mysql-include=/usr/local/mysql/include/ –with-mysql-lib=/usr/local/mysql/lib/ –with-mysql-config=/usr/local/mysql/bin/mysql_config

Run `sudo gem install mysql` and definitely recheck the log file again as the gem install process sometimes reports false positives even if native components fail to install.