Every year I like to post my new years resolutions. (I also post a picture of where I was on New Years Eve) It's fun to go back and look at my old resolutions (2011, 2010). It's been an excellent way of keeping myself accountable and as a reminder that change is constant.

1. Update all website footers from © 2011 to © 2012.
2. Read 20 books (250 pages or more).
3. Drink more white tea and other flowery tea stuff. (i usually turn my nose up at the flowery stuff)
4. Go camping. (specifically Angel Island, and Channel islands)
5. Build something non software related.
6. No coffee or alcohol for 6 months.
7. Play year round in a basketball league.
8. Run marathon #2.
9. Write more blog posts.
10. Be more mindful.

I recently read How to Win at the Sport of Business: If I Can Do It, You Can Do It. Usually I'm not a fan of this kind of content, but i found the collection of essays inspirational. Towards the end I found this gem; "Twelve Cuban Rules for Startups". With the current events in my life it seemed appropriate. See if you can find the reference to Glengarry Glen Ross.

Twelve Cuban Rules for Startups

Anyone who has started a company has his own rules and guidelines, so I thought I would add to the memo with my own. My “rules” below aren’t just for those founding the companies, but for those who are considering going to work for them, as well.

1. Don’t start a company unless it’s an obsession and something you love.
2. If you have an exit strategy, it’s not an obsession.
3. Hire people who you think will love working there.
4. Sales Cure All. Know how your company will make money and how you will actually make sales.
5. Know your core competencies and focus on being great at them. Pay up for people in your core competencies. Get the best. Outside the core competencies, hire people that fit your culture but are cheap.
6. An espresso machine? Are you kidding me? Shoot yourself before you spend money on an espresso machine. Coffee is for closers. Sodas are free. Lunch is a chance to get out of the office and talk. There are 24 hours in a day, and if people like their jobs, they will find ways to use as much of it as possible to do their jobs.
7. No offices. Open offices keep everyone in tune with what is going on and keep the energy up. If an employee is about privacy, show them how to use the lock on the john. There is nothing private in a startup. This is also a good way to keep from hiring execs who cannot operate successfully in a startup. My biggest fear was always hiring someone who wanted to build an empire. If the person demands to fly first class or to bring over a personal secretary, run away. If an exec won’t go on sales calls, run away. They are empire builders and will pollute your company.
8. As far as technology, go with what you know. That is always the cheapest way. If you know Apple, use it. If you know Vista … ask yourself why, then use it. It’s a startup, there are just a few employees. Let people use what they know.
9. Keep the organization flat. If you have managers reporting to managers in a startup, you will fail. Once you get beyond startup, if you have managers reporting to managers, you will create politics.
10. NEVER EVER EVER buy swag. A sure sign of failure for a startup is when someone sends me logo-embroidered polo shirts. If your people are at shows and in public, it’s okay to buy for your own folks, but if you really think someone is going to wear your YoBaby.com polo when they’re out and about, you are mistaken and have no idea how to spend your money.
11. NEVER EVER EVER hire a PR firm. A PR firm will call or email people in the publications you already read, on the shows you already watch and at the websites you already surf. Those people publish their emails. Whenever you consume any information related to your field, get the email of the person publishing it and send them a message introducing yourself and the company. Their job is to find new stuff. They will welcome hearing from the founder instead of some PR flack. Once you establish communication with that person, make yourself available to answer their questions about the industry and be a source for them. If you are smart, they will use you.
12. Make the job fun for employees. Keep a pulse on the stress levels and accomplishments of your people and reward them. My first company, MicroSolutions, when we had a record sales month, or someone did something special, I would walk around handing out $100 bills to salespeople. At Broadcast.com and MicroSolutions, we had a company shot. The Kamikaze. We would take people to a bar every now and then and buy one or ten for everyone. At MicroSolutions, more often than not we had vendors cover the tab. Vendors always love a good party.

I can't believe I got my hands on a Kindle Fire. As of today the documentation for getting your application on the Fire is somewhat sparse so I thought I'd throw up what helped me out. Note: these instructions are meant for a developer on OS X.

You want to target the Android 2.3.3 SDK. Then after recompiling your application and fixing any errors/warnings.

Follow these instructions:

1. On the Kindle Fire Settings screen, go to "Device" and turn On "Allow Installation of Application From Unknown Sources"
2. Plug your Kindle Fire into your Mac.
3. Open ~/.android/adb_usb.ini with your favorite text editor
4. Add the value "0x1949" to the end of the file and save it.
5. You'll need to restart the adb server process to get it to re-read that file. Do that with "adb kill-server".
6. Run "adb devices" and you should see the attached device.

I have to say after my first 5 hours with the Kindle Fire I really like the hardware especially for the price. Sadly under all of that beautiful hardware the user interface still feels very android. Even after all of the customization that Amazon (which seems like a lot) has done, it's pretty remarkable and really stable. I can only imagine whats to come in future software updates.

Happy Hacking!

For my latest venture I decided to split up parts of the codebase into separate git repositories. In the past I haven't done this and I just wanted to try something completely different in terms of code organization. So far it's been great ... alas nothing is perfect and there's one nasty side effect. My problem is sometimes I do a ton of work on my workstation at home and sometimes I'm mobile and moving from coffee shop to coffee shop. This seems like a semi-common use case (the assumption is that most developers have more than one machine they code on).

The problem is I'll do a major block of work on my workstation, commit, then push out to the server. I'll then get to where I'm going, and immediately pull down the latest to the laptop. Doing that with one repository is simple. Doing it with more than one repository ... lame and insanely repetitive. An engineer when seeing this pattern should automate.

#!/bin/bash

START_HERE="/path/to/project/directory/";

cd $START_HERE;

echo -e "\nPulling down latest for $START_HERE\n";

for d in $(find . -maxdepth 1 -mindepth 1 -type d); do
        echo -e "$d";
        cd $d;
        git remote -v;
        git pull;
        cd $START_HERE;
done

echo -e "\nYou're welcome.\n";

Copy and paste this code into a file and chmod 755 some_script_name.sh then ./some_script_name.sh.

Enjoy!

On the day in which iCloud goes live (and for some very very lame reason my iPad 1 will not update to iOS 5). Let's take a second and remember back to when Bill Gates was presenting the Windows "Live" Platform and how it would solve the sync problem ...

and just for contrast lets see the Apple version ...

kinda funny right?

Update: my iPad 1 just updated. :-)