This year’s annual review process swung around fast! It seems like the team joined Ingram Digital just months ago. I’ve done them a few times, but this was the first review process I’ve done at ID. Reviews are a time for reflection. A time to make and receive input on how we’ve performed. A time to realize and face weaknesses and understand our strengths.

There were five appraisals of my developers, and one on myself. To normalize the results I did my self-appraisal first. I had everyone on the team do their own self-appraisal, too, but I avoided reviewing theirs until I’d done my appraisal of them. This was to make sure my scores weren’t skewed and to look for any disconnects.

I started by reading status reports I sent for the year. For the weeks without status reports I re-read email to make sure I didn’t miss any accomplishments. This was time consuming and highlights the need to maintain a tighter journal of deeds. I’ve done this for myself over the last ten years. Keeping a separate journal for one’s team is highly valuable and I’m going to start doing this beyond status reports.

My team rocks, and my entries in my self-appraisal are the result of their efforts. As I listed each accomplishment I thought, “My team made this. My team created that… I worked my face off, but what specifically did I do?” It’s strange to reflect on what one was responsible for, but did with the hands of others.

Appraisals for my team were less demanding after my own. For one, after this point I’d compiled the full list of the team’s accomplishments. For two, it’s easier to judge others after judging one’s self.

Some additional links on performance reviews:

• Employee Performance Reviews
• Conducting Effective Performance Appraisals
• Why Annual Performance Reviews are a Waste of Time (I don’t agree with the writer, but it highlights what we should do during the year so reviews are effective and aren’t a surprise).

My dev team uses JIRA for bug tracking. It’s a flexible project management and defect tracking system. As with almost any bug tracking system out there (Bugzilla, Trac, etc), web based defect tracking from a mobile handset is not very user-friendly.

Enter JIRA Mate (formerly JIRA Buddy), written by Shaun Ervine, an application for iPhone and iPod Touch specifically for interfacing with your JIRA database. I was surprised by this application being available before a Bugzilla rev, let alone even being available at all. I’m not complaining. Bugzilla fans should get a move on for their own app.

JIRA Mate simply uses your saved filters allowing you to access your JIRA issues straight from your iPhone.

Since JIRA Mate is helping out your business I guess you could write it off as a tax deduction :)

The app is $8.99 and allows you to pull down issues organized in filters you’ve created in the standard web app, sorted by date (your filter sort setting is not utilized). It does not have issue creation or editing capabilities, but does pull comments and allow you to comment in kind. It’s perfect for keeping your finger on the pulse of your bug database and staying in communication via comments.

A Google search for Apple Dual-Link DVI yields a ton of product pages and blog posts about the greatness of Apple’s use of DVI. You’ll get quite a few of Apple’s own product pages, as would be expected. But only a few blogs are calling Apple out.

Apple recently released a new MacBook Pro. It has the most advanced laptop graphics equipment on the market, with dual NVIDIA 9400M and 9600GT chipsets. Apple has also employed a new port type, DisplayPort, that is not the same as Mini-DVI or Micro-DVI. This is a port that is easier to plug in than DVI and supports HDCP (high-bandwidth digital content protection).

People with needs for the best processing horsepower on the go are going to pick up this laptop. These professionals, myself included, are going to be disappointed. If you’re in to a high-end laptop like this you’re probably also pushing 30″ monitors. If not, you should be. But you can’t. The DisplayPort to Dual-Link DVI adapter doesn’t ship for 4-5 weeks (and that’s what they said on October 15th).

The image above is the dual-link DVI adapter from Apple. It’s a DisplayPort plus USB plug to a DVI female. Why does a dual-link DVI adapter require the addition of a USB plug? Giving up that extra USB port hurts. Paying Apple $99 to move us to a new port type is insulting.

So what’s with the delay? It doesn’t take 4-6 weeks to manufacture cables with DisplayPort, USB, and DVI plugs attached (the site has displayed 4-5 weeks for 4 weeks already). Either development of, or problems in, the circuitry is derailing Apple’s rollout. Or perhaps software driver updates will be required before the DisplayPort + USB adapters can be driven. If the latter, we would expect the adapters to ship at the same time as an OS update drops.

Apple, make this easy. Make it just work…

For more on DisplayPort see DisplayPort: what you need to know (Peter Cohen)

And for a little ridiculousness:

• Standard DisplayPort to DVI adapter ($29)
• DisplayPort to Dual-Link DVI adapter ($99)
• DisplayPort to VGA adapter ($29)
• Mini-DVI to DVI adapter ($19)
• Mini-DVI to VGA adapter ($19)
• Micro-DVI to DVI adapter ($19)
• Micro-DVI to VGA adapter ($19)

UPDATE: Another theory is that the chip for the adapter requires additional juice. The USB connector would simply be a power chord.

I’ve been glued to the news this week and filled up on too much doom and gloom. There are plenty of positive things to focus on. Even if this is the start of a recession, focusing on a tanking stock market doesn’t do any good as a developer. For you stock traders, yeah, you’re boned. But for software developers, there’s much to build.

Focus on what you’re good at. Make yourself better. Enjoy life.

It’s time to switch back to loving this perfect fall weather and looking forward to a killer ski season.

Photo by Peter Baer – CC

.

As a tech manager I’ve got myself in to that mode. You know the mode. The one where you’re so focused on building a great product that you’re not getting to code that often, if at all. This isn’t bad – you have to do whatever you can to get things done – but if you’re a developer manager, you need to live in this space. And I’ve felt the atrophy.

So over the weekend I scraped the rust off and tried some new stuff. I’ve never coded in Python, but I’ve had Google AppEngine sitting on my account for a while. And I’ve got a personal iPhone developer SDK and ADC membership. It was time to whip out the programmer-WD40.

What did I build? Pytchfork. What is Pytchfork? You’ll find out – but not in this post. It’s something I’ve had on my mind for a while. In about an hour I had AppEngine installed and Pytchfork configured. Less than two hours later I was done with a REST library and the framework for what Pytchfork will become.

A REST feature set for input. Basic XML, RSS, ATOM, and JSON as output. In a few hours. Not bad, and it felt gooooood.

From this I’ve learned Python is a friendly animal, and not just in theory. It’s too friendly. The lack of semi-colons in my C/C++ brain feels like I’m walking up to a cliff without a railing at each line ending. But it’s something one gets used to.

Unless you’ve written a PHP or Ruby framework you’re married to, AppEngine and Python is about the best thing you could do for yourself as a way to publish a small, personal, application.

Starting a Monday without rust feels great. Stay sharp!

Twicecream – a fake service to demonstrate a point about single sign-on…

In web 2.0 there is a determination to screw up potentially great services. It’s my number #1 pet peeve with software development these days. Here’s a fictitious example of a service you might create…

You’ve built a service that automatically Twitters your geo-position and the name of an ice cream parlor when you’re in front of it. Your phone buzzes when an ice cream parlor is detected and begins sending photos to SnapTweet and TwitPic, including Zagats ratings and commentary. Other patrons respond back and generate conversations. This is your social network: Twicecream – a social network for twittering ice cream enthusiasts.

In front of Ben & Jerry’s on the Wharf, Zagats 4-stars, pics: http://twicecream.com/abc123

Congratulations! You just failed.

You didn’t fail by creating a service few would use. You failed because you didn’t utilize the authentication mechanism your patrons preferred. You built an unnecessary barrier to your garden by requiring an unnecessary account creation. Don’t do this, it’s arrogant and inefficient.

Your patrons have Twitter accounts. Twitter has an API. Your service should have asked the patron to log in with their Twitter credentials.

This isn’t just for social networking. This goes for all web services. SaaS solutions that require secondary account creations are a bad idea. Single sign-on, whenever possible, should be used.

The whole idea is to simplify access to what the customer needs. If you’re requiring unnecessary account creations, you’re screwing it all up.

Had an awesome day – time to share!

• 12seconds.tv/channels/solyoung
• First 12second introduction
• TechCrunch link
• WCU post

Chris Bilson (@cbilson) had a good description regarding my post about Twitter’s scaling/architecture challenge.

“Kevin Rose and Leo Laporte tweet at the same time = crossing the streams”

I dunno if Proton Packs have exponential load challenges, but the end result for a server can feel similar. Is my post I pointed out that Twitter has to determine delivery options and potentially deliver between 100 million and 1 billion updates per day.

But that’s in a day. 1 billion messages in a day are a piece of cake when spread over 24 hours. What if 1 billion messages have to be delivered in an hour? Or all at once?

Take my list of the top-10 Twitter accounts and imagine them all at TED, WWDC, Google I/O, or your local unconference. These ten users, if each sends an update around the same time create 321,928 messages that need delivery (total number of followers for top-10 accounts). This is an awesome amount of message delivery. If those ten users live-blog or get conversational and send ten updates in an hour… 3,219,280 (again, that’s from only 10 users).

I don’t illustrate this to state it’s these power user’s fault. Absolutely the opposite. They’re generating amazing amounts of traffic, which is a wonderful thing, and the algorithms are the problem.

It’s possible to optimize algorithms and modify systems for maximum performance. I bring up Twitter’s challenges because I’m wondering if this is a challenge beyond present day computing.

To open some minds, here’s an impossibility often overlooked: Huge numbers in a deck of cards (just to show impossibilities can stem from small initial numbers).

Twitter has been having all kinds of scaling challenges. There have been hundreds, if not thousands, of posts on the subject. Dave Winer pushed an idea for a decentralized Twitter (and has since admitted the power of Twitter is in its centrality). There is a single, simple, reason for Twitter’s challenges – Math is against them.

The facility of communication on the Twitter service is absolutely outstanding. I’ve written extensively about using it to receive an amazing amount of quality information in my series on flow.

I originally questioned the scaling ability of the service prior to SXSW, but when the service held up I went back to the drawing board to make sure my numbers were correct.

Before continuing, let’s establish the basics about the service so the math will make sense…

• Each Twitter account can follow any other Twitter account (bear with me and forget those accounts with private updates).
• Messages travel in one direction, from the updater to the follower.
• Each account has updates from other accounts it follows placed in its timeline.
• A Twitter account can selectively receive pushed updates immediately via instant messenger and SMS in addition to having an update added to its timeline.
• An update added to an account’s timeline may or may not be push based (lets assume it’s demand driven, or pull based).
• An update sent to an account from an account denoted as SMS or IM announcement is push based (there is no other way to send an update – it must be actively pushed from the server).
• The mere possibility of an update needing to be pushed requires the system to check with each follower’s settings, thus requiring analysis of each follower for each update.

A warm-up equation

If there are one hundred (100) users and each user follows ten (10) fellow users, and each user sends ten (10) updates per day, assuming all updates are push-based, how many updates are sent?

The answer is 10,000 – each sent update (100 users x 10 updates) is forked out to 10 followers who have requested push updates. This is a very large number of updates to send out via SMS or IM compared to the base of users.

A very important fact: It doesn’t matter if a user follows with the intention of receiving an SMS or IM update. The possibility of an updating needing to be pushed requires Twitter to examine every follower when an update is received.

From 1999 to 2004 I worked as a software engineer at Mplayer (who then changed names to HearMe, who then sold their video technology to LIvVE, who then was bought by GameSpy).

As with any chat room, the scaling is similar to Twitter. We had to restrict rooms to 500 users (and had insanely reduced reliability as we approached 500). As shown with the warm-up, each message is forked out to every user. We capped at 500 in a chat room because each user in a room contributes some amount of messages, and therefore as users join a room the traffic grows exponentially.

Official and unofficial numbers

According to Twitter’s blog post with stats, 50% of the Twitter population has 10 followers. 10% of users have 80 or more followers. According to TechCrunch’s research there were 200,000 active users posting 3,000,000 updates per day (as of the end of April 2008). The average Twitter user posts 15 updates per day (3,000,000 divided by 200,000 = 15).

We’ll use Twitter’s percentages in their blog post and combine them with TechCrunch’s numbers. From this, we know there are 100,000 daily users with 10 followers and there are 20,000 people with 80 or more followers. To keep things simple, we’ll leave the other 80,000 daily users out of the equation for now.

• 100,000 users x 15 updates per day x 10 followers = 15,000,000
• 20,000 users x 15 updates per day x 80 followers = 24,000,000

For laughs, let’s put in the top 10 Twitter accounts with the most followers (beware, there were fights over this).

1. Kevin Rose x 15 updates per day x 46,646 followers = 699,690
2. Leo Laporte x 15 updates per day x 44,948 followers = 674,220
3. Barack Obama x 15 updates per day x 42,201 followers = 633,015
4. Alex Albrecht x 15 updates per day x 30,348 followers = 455,220
5. Jason Calacanis x 15 updates per day x 28,773 followers = 431,595
6. Robert Scoble x 15 updates per day x 28,037 followers = 420,555
7. Mars Phoenix (rover) x 15 updates per day x 26,828 followers = 402,420
8. Veronica x 15 updates per day x 26,199 followers = 392,985
9. John C. Dvorak x 15 updates per day x 24,102 followers = 361,530
10. MacRumors x 15 updates per day x 23,846 followers = 357,690

Total of average users + top 10: 43,828,920 updates delivered per day.

And that’s half of the Twitter user base, mixed with a tiny fraction of the users who have large number of followers. Realistically, my estimate above is less than 10% of actual traffic because I’ve left out the 40% and have not included the thousands of highly popular users with more than 80 followers. Additionally, the number of followers for the people in the top-10 has grown between 50 and 100 percent since the end of April! (Twitterholic)

This puts Twitter’s actual message analysis and possible delivery between 100,000,000 and 1,000,000,000 per day.

This also does not include a single page view or web service call to their servers. Those alone account for a huge amount of Twitter’s traffic.

Compared to IM traffic

Back in 2005 (ZDNet) there were 13.9 billion instant messages sent per day, with estimates of quadrupled traffic by 2009 (46.5 billion). Instant messaging is divided up among a few primary services and IMs are one-to-one. According to Wikipedia, AOL AIM has 53 million users. If Twitter became as widely used as AIM, it would grow 265 times (53,000,000 divided by 200,000).

Take our findings for the number of delivered (or analyzed) updates on Twitter and multiply by this growth and you find Twitter has to be capable of delivering between 26.5 billion and 265 billion updates (probably much closer to the latter).

How can Twitter scale?

Decentralized XMPP is probably the answer, but I don’t really know. I can see the problem though. If they grow to having one million daily users, they have between 500 million and 5 billion messages to deliver. If they grow as popular and as relied upon as AIM, they’re staring straight in to their own exponential order of magnitude.

Most smartphones slated for release over the next 12-months include a GPS receiver, built in. After that, it will be a marked failure to not include a GPS in a phone. The functionality that comes with GPS is outstanding – mapping, directions, location based experiences, etc. We’re about to enter an age of advancement in technological capabilities that we’re just beginning to imagine.

Consumers are moving to smartphones. The hottest smartphones (iPhone 3G, BlackBerry Bold 9000, most of Nokia’s Symbian and HTC’s Windows Mobile offerings) all include GPS and an exposed API for developing applications utilizing their hardware. Anything people can conceive of for location based mashups will be coming (more on these mashups in later posts)…

Here’s a first application…

BlackBerry is a leader in mobile phone GPS. Recently a few services that announce the location of one’s phone emerged. Initially these were billed as a sort of low-jack for one’s phone, a security service for the insecure (or those who want to spy on their kids, etc).

I decided to try a few of these. Most felt slimy, like, “you always know where your phone is, and you could also know where your wife is!” … I don’t know about you, but my phone is loyal and doesn’t run off with strangers… And I trust my wife far more than a phone.

My goal with trying these services was to mash Twitter, Pownce, Facebook, and other social networking services with my location. Such a mashup will allow me to share my real-time location with all friends. I came across BlackberryTracker.com. Much like the others, the idea is to provide you with the location of your phone. However, they have something the other’s don’t… Facebook and Google Earth integration (as well as a drop-dead-simple semi-RESTful API).

Friends can pinpoint me down to the meter on my Facebook profile, updated every 30 seconds. To be honest, it feels strange to openly publish this data. Security, and lack thereof, has us believing we shouldn’t share such information. But this fear is caused by the exception and not the rule. And in reality, my location in public isn’t private. Additionally, there are laws and common courtesies we live by, and I trust that people are inherently good.

Soon these services will be in the mainstream. Everyone will be able to pinpoint the location of anyone. Let me emphasize that… Soon everyone will be able to pinpoint the location of anyone. Not publishing your location will be like not having a mobile phone.

“Ingram Digital, an Ingram Content company focused on solutions for digital content management, hosting, distribution and promotion, today announced it has acquired the iofy digital audiobook platform from Audiofy Corporation.”

It’s official. As described in the press release, the iofy digital audiobook platform is now part of Ingram Digital. I’m happy about this move. This is the iofy development team I lead and I’m confident our acquisition will bring incredible value and additional ingenuity. We’ll now be building something amazing, which iofy wouldn’t have had the resources for on its own.

Other than some title changes, the team and focus are unchanged. Cartwright Reed, iofy’s President, is now in the role of Vice President of Product Development at Ingram Digital. My team is continuing the charge to build the best audiobook platform available (look for continued web service goodness).

The culture at both companies is driven by growth, creativity, and building solutions. I’ve had only positive experiences working with the folks at Ingram. They’re great people, and we’re looking forward to being part of an Ingram company.

After converting my MacBook Pro in to a Windows developer dream, I wanted to have the same experience on a more portable, commodity hardware unit. Virtualizing Windows within Windows with VMware Server is something I’m familiar with. It’s something many Windows developers may prefer (and I recommend if you’re not comfy with linux as your host OS).

Quick background: Virtualizing a development/qa environment allows one to have an easily cleaned control environment. When a machine gets dirty (too many installs, tests, builds, or other garbage collects), you can simply delete the virtual instance and copy a fresh installation back over. This saves a ton of time. In dev, this allows a safe, clean, environment to test builds in. In a QA environment, this allows a very fast way to return to a known state.

My goal in a virtualized dev/qa environment is to run a host which consumes an absolute minimum amount of resources. I run virtualization software that allows more than one running VM at a time, such as VMware Workstation (PC), VMware Fusion (Mac), or VMware Server (PC or Linux). If you’re running Windows as your host OS, I recommend Windows 2000 Advanced Server because it is tunable to consume less resources than any other flavor of Windows (including Windows 2000 Professional).

Given that Linux runs on wrist-watch sized systems, it’s a safe assumption that one will get better performance from virtual machines than on a virtualized Windows environment. I chose Ubuntu since it’s super simple to install, is fairly reliable, offers similar features to Windows, and is still a smaller footprint my Win2kAS machines.

I started with version 8.04 desktop (hardy). The installation was a piece of cake, but there are no tuning options in the basic .iso. I installed VMware Server, but just while running the OS I could tell I would run in to performance issues later. The desktop flavor of Ubuntu isn’t light enough to pass all the processing power through to the VMs.

Instructions

1. Install Ubuntu Server 8.04 – For those of you doing this for the first time and are coming from a Windows environment, you should use the following disk setup (assuming you have a single hard drive):

• 20 GB EXT3 partition, set as boot (“/”).
• 2 GB SWAP.
• remaining space, set up for home (“/home”).

2. Install Xubuntu with apt-get – Ubuntu Server doesn’t have a UI. Ubuntu Desktop is too heavy. Xfce is an outstanding light GUI desktop alternative. To get this installed:

1. Boot up your now Ubuntu Server machine.
2. You will land at the command prompt, type “sudo apt-get install xubuntu-desktop” (without the quotes).
3. Enter your password to grant privledges to download/install the Xfce GUI. It will take a while to download as the Xubuntu install is about 300 MB.
4. Reboot when ready, you’ll boot in to Xubuntu.
5. At the login prompt, choose to change the type of GUI you’re logging in to. Select Xfce.

3. Install VMware Server (as of this writing, server 2.0 is in beta and not recommended for a performance environment – stick to 1.0.x) – This was a total pain in the butt my first time around. I hope my instructions here allow you a fairly pain-free installation. Additional resources here, here, and here.

1. Open Firefox, available as a shortcut at the top of the screen.
2. Download VMware Server here: http://vmware.com/products/server/
3. It is now on your desktop, go to the Applications button at the top left and choose Accessories -> Terminal to open a terminal.
4. Type “cd Desktop” to move to your desktop.
5. Unpack the archive. Type “tar -xvf vmware[TAB]” (hit the tab key to complete the filename).
6. Move in to your VMware folder. Type “cd vmware[TAB]“.
7. Visit the ‘here, here, and here’ links above for all the resources you’ll need to get past the now-known errors you’ll run in to.

4. Copy VM instances from other systems – I use VMware Fusion on my Mac and VMware Workstation on a PC (haven’t used Workstation in a while). You can create instances in either of these products and then just copy them over to your Ubuntu system. Tips:

• Keep the fresh install VM instances as they are and make copies. You can now just drop in a copy of the fresh install so you don’t have to ever re-install the OS again.
• Install your dev and/or qa environment. Make a snapshot NOW. You can now revert to this snapshot immediately, whenever you want. Fresh, known, starting point: viola!

5. Tweak your VMware instance settings:

• Leave your host OS enough RAM to be comfortable. Give each VM as much as it needs.
• Disable 3D acceleration unless you absolutely need it in the VM for testing 3D. This is a resource hog.
• If your PC is multi-core, only give the VM 1 CPU (unless you need to test multi-core software).

6. Dev and QA to your heart’s content – You’re now free to revert, take snapshots, and otherwise manipulate your OS without the fear and wasted time of reinstallation. Enjoy!

Object-Oriented Programming (OO or OOP) is the best way to have re-usable, sharable, less-bug-ridden, easily readable, easier to debug, and easier-to-pick-up-later professionally written software.

“Learning classes” is the functional way to describe learning object-oriented programming. One skill begets the other. When in college my professor played a video of a band playing music. The band represented a program, and each musician represented a class.

I hope that’s not how it’s described nowadays for comp-sci peeps because it’s a completely backwards way to learn it. It is backwards because you’re already looking at a finished product. To understand OO and classes, think in terms of small portions. Then grow from there.

To give an example of how to build out a class, let’s build a musician or rocker since we’ve been on a Rock Band kick.

Before continuing, this assumes you’ve written some PHP – including at least making a function or two…

.

Now, what does a rocker have?

• Name
• Gender (probably)
• Instrument
• Talent Level

These will be the variables we put in our Rocker class, here’s the code to support us…

<?php

class Rocker {
// OOP classes are usually capitalized. Good form.
var $name;
var $gender;
var $instrument;
var $talentLevel;
}
?>

…

We need to be able to set and get the above information from our Rocker class, so we add some functions in there (‘setters’ and ‘getters’)…

<?php

class Rocker {
…

  // Functions (methods) should start as lowercase and then use uppercase to separate words
// (also known as camelCase)
  function setName($inName) {
$this->name=$inName;
}
  function setGender($inGender) {
$this->gender=$inGender;
}
  function setInstrument($inInstrument) {
$this->instrument=$inInstrument;
}
  function setTalentLevel($inLevel) {
$this->talentLevel=$inLevel;
}

  function getName() {
return $this->name;
}
  function getGender() {
return $this->gender;
}
  function getInstrument() {
return $this->instrument;
}
  function getTalentLevel() {
return $this->talentLevel;
}
}
?>

Now we have a Rocker for which we can set and retrieve attributes. The Rocker class still doesn’t do anything. We can very easily add some functions to the class which do stuff…

<?php

class Rocker {

…
    function play() {
    // you write this code…
  }

  function sing() {
    // you write this code…
  }

  function perform() {
this->play();
this->sing();
}
}
?>

You now have a basic Rocker class. You could use it as an object within a Band class or you could use it on its own. A quick example to create my Rocker and make me play…

<?php
$sol = Rocker();
$sol->setName(‘Sol’);
$sol->setGender(‘Male’);
$sol->setInstrument(‘Drums’);
$sol->setTalentLevel(’31334′);
$sol->perform();
?>

…

This may seem confusing, or even useless, since it really has nothing to do with web development. So let’s switch the term “Rocker” to “PageTemplate”, and switch up the functions so they’re actually useful…

<?php

class PageTemplate {

  function getIPAddress() {
    return $_SERVER['REMOTE_ADDR'];
}

  function makeTop($title) {
    print ‘HTML that makes up the top of a web page goes here, allowing for a custom $title’;
}

  function makeBottom() {
    print ‘HTML that closes the page’;
}
}
?>

With the above class, you could easily make a What’s My IP page with just a few lines of code:

<?php
require ‘pageTemplate.php’;

$page = PageTemplate();
$page->makeTop(‘sample title’);
printf(‘our IP address is: %s’, $page->getIPAddress());
$page->makeBottom();

?>

I recommend checking out this entry on devarticles.com: Object Oriented Programming in PHP.

Any questions, don’t hesitate to ask… randomblogaddress31@solyoung.com or @sol.

:

When following a lot of friends in a flow environment and using XMPP, one sees the above numbers in less than ten minutes. I’d been using Adium, but Adium doesn’t smooth scroll between each received tweet. It constantly jerks messages upwards and has made it virtually impossible to have a meaningful experience. There are often times when I want to read each incoming tweet. A good, smooth, reading experience was needed.

iChat has a slightly smoother hit at each received message, and is therefore much more enjoyable to read. The interface is customizable enough, but nothing quite as nice as some of Adium’s minimal themes.

I was mostly hesitant to switch since Adium has outstanding AppleScript support. I’ve been thinking of prototyping something (given a couple hours – someday). Apparently iChat has something even better which I should have known about… Callbacks! A script can fire for each received message.

This will make dynamic, real-time, filtering a reality.

The start of something very cool…

Here are my previous flow entries so you’re up to speed:

• Day 1
• Day 2
• Day 3
• Day 4
• Day 5
• Day 6 (no post)
  

I’m visiting my in-laws this weekend so haven’t been spending much time in the flow this weekend. However, even with short stints I’m finding a recurrent issue. Each day I think I’m going to hit a maximum number of people I can pay attention to. Each day I’m proven wrong. There’s an adaptation that takes place.

I’m following almost 3,400 and it’s working very well. I could imagine 5,000 being more than comfortable. Even on a standard IM client, the data flow is manageable. Most IM clients don’t smooth scroll, so it’s annoying to have each incoming tweet snap prior tweets upwards.

I’ve been thinking of the outline for a high-traffic Twitter client spec:

• XMPP for tweet flow.
• Web Services harnessed for contact management.
• RSS/Atom integration for pulling articles from Twitterer.
• Caching of existing Twitter contacts to embed information in to the XMPP traffic.
• Search and real-time filtering.
• Ability to only show tweets with links.
• Additional filters based on: Age of Twitter of account, Location, number of tweets, ratio of following/friends, has non-default avatar, has non-default twitter design… with real-time color-coding of tweets.
• Ability to favorite a tweet that came through XMPP.
• Auto-pull of a Twitterer’s most recent blog entries (requires a scan for RSS feeds on the Twitterer’s home page, then pulling/parsing those items).
• Auto-addition of Twitterer’s RSS in to Google Reader or other items.

With the above, one would have a complete Twitter news-room. One could immediately see what’s flowing and have access to a Twitterer’s additional information. This may be possible with a Flash or Java application, though I’d prefer a highly portable objective-C or C++ app. Maybe even ported to mobile clients (maybe, maybe).

This weekend my wife and I got an early start Friday to finish off our bathroom’s tile. I’ve been photo-blogging it to Flickr and periodically putting up notes on Twitter. The last couple weekends have been similar, doing plumbing, floor tile, prep work, etc.

Though there is so much to do (more blog posts, tons of iofy priorities, and building in a certain web service), this is still satisfying work… Something everyone 1/2 interested in real estate should do at least once. I’m a software engineer and dev team manager because I love to build things. I think other developers should feel this way too.

More pics after the jump…

Steve answered, “We change our minds a lot. The web apps have worked well, but developers wanted to do more. And we heard that. Creating an SDK is a lot of work, you want to make it something you can live with for 20 years, and yet update it without breaking apps. This is an elegant and clean system.”

I’m certain Apple had the SDK in development since before WWDC ’07. As Steve said, it takes a long time to develop an SDK. They just weren’t ready to announce it yet last year and covered by offering web apps. Their marketing machine and product release practices entice us to want more. We hated Apple last summer for it!

The remainder of the question was handled by Phil, “Second question. Electronic submission will be very fast, and this is a whole new process.”

A lot of people are screaming bloody murder about Apple controlling this process. While I don’t really like the idea of only getting Apps installed via Apple’s system, it could be a lot worse. Apple will be CHiPs, not the DMV. There will undoubtably be apps which make it possible to download and install while being untethered anyway.

The impression I got during the sign-up process to develop for the iPhone and download the SDK was impressive. Not because of the smoothness of the process (I hit terrible snags due to the server congestion), but because it’s obvious they’re going to allow developers to easily publish apps. What I got out of it is they’re making it better and easier to write software for the iPhone than for Windows Mobile or other handhelds. Apps will be as easy to publish as an album of music… Same model.

Dave Winer has been leaning towards the negative side of Apple’s plans, but he likes the idea of an untethered podcatcher. I’d love to talk to him about that… It’s something I expect iofy to work on.

Cart dropped a note about long anticipated API addition at Google (so long that most people forgot about they might even still be working on it). Google now has a contact API. This is huge news because up until now only Yahoo! offered a good synchronization service.

I’ve been a Yahoo! Address Book fan for years because of their service, especially how it integrates with their Go service. With Google’s API we’ll see apps that start synchronization between these two, as well as any other service out there. This is fantastic!

As promised (but late as a post), we released iofy’s RESTful documentation. This is extremely exciting for both our development and management teams. We now have an open account management API enabling others to offer iofy’s account management and access to a customer’s digital libraries of downloaded audiobooks.

I’m proud of this accomplishment.

The iofy RESTful API covers the features for partner or reseller to offer downloadable audiobooks. These RESTful web services use standard REST calls, are language agnostic, retrieve RSS 2.0 feeds and enable:

• product listing and search
• account management
• financial management
• purchase and checkout

One can receive dynamic product feeds from ws.iofy.com/product/, where search parameters can include title, author, publisher, narrator, ISBN, and more. These feeds come complete with thumbnail image enclosures, MP3 audio sample enclosures, and all the metadata.

Via account management, described last week, customer accounts can be created, modified, password reset, and most importantly the customer’s prior purchases become available in a library. One can offer this digital library and account management solution without building it (or maintaining it). Just harness it.

The fulfillment API allows assignment of a digital download in a single call. We included PHP sample source code, but it could just as easily be harnessed in any other language.

JavaScript and PHP sample code is available which allows complete harnessing of both APIs. To learn more, email developer@iofy.com.

iofy td: RESTful API

iofy td: Fulfillment API

http://philip.greenspun.com/business/internet-software-patents

Actually, I feel challenged to prove him wrong.

After reading this great, hilarious, post on upgrading to XP (yes, you read that right – this isn’t a Vista upgrade), I decided to take the plunge. I’ve been punished long enough for using Vista Ultimate in my VMware environment and portable laptop. It’s been a nice OS, but performance is in the toilet and I can’t take it any more.

It’ll hang around for testing purposes… Here’s hoping SP1 brings some hope to Vista.

Developing PC applications on the Mac is great, contrary to what some believe. I too was once in the ‘build-on-the-platform-you-target’ camp. Forget that horse-puckie and get efficient:

1. Get VMware Fusion: http://www.vmware.com/products/fusion/.
2. Make sure you’ve got XCode. This will be sixty percent of your development environment and you’ll be coding in OS X.
3. Install Windows XP or Vista, your choice, as a new VM in Fusion. This will be the other forty percent of your development environment where you’ll step code and delve out builds. Don’t set it up with more than 40% of your Mac’s RAM assigned (preferably 25%).
4. Install your development tools on this Windows instance, probably .NET 2005.
5. Set up a shared folder for your source code between your Mac user folder and the dev VM. Make it read-write by both systems (a setting in Fusion).
6. Set up more VMs in Fusion. These are your Test VMs (smaller, fast Windows instances used as QA machines) – as of this writing you should make XP Home, XP Pro, Vista Home, and Vista Ultimate VMs. You may want additional setups depending on your apps needs (administrator settings, etc). Set these up with 25% or less of your available RAM.
7. Do nothing… I’m waiting for you to finish step 6… It takes a while.
8. Run Windows Update (if desired) and take Snapshots of each VM (Command+T) after they’re set up. These Snapshots will let you revert to a clean state any time you wish.

Great, now you’re hooked up and can get your code on. With XCode you can utilize all your monitors (if you’re a developer using less than 2 monitors, we need to talk…). You’ll have XCode running with your source code all over the place organized how you like it. You’ll have your development VM running in a corner.

Use XCode as the code editor (you’ve got your source files saved on the Mac, in the shared folder). Keep the development VM running and hit Control+B in it (or better yet, add an AppleScript to XCode to pass Control+B to the VM) when you need a new build. You can step through the code when you need to.

When you’re ready to test your app(s) on all flavors of Windows, launch up the various VMs and install the app(s). Afterwards, restore to the Snapshot you took before. You’re starting from a nice clean start every time.

My dev team is prepping the release of our REST / RSS / JavaScript based account management this week. It marks the completion of building, then harnessing, a suite of RESTful RSS 2.0 feed based web services. The idea has been “avoid people wasting time, working on stuff they suck at focus developers on code they enjoy and excel at.”

We had problems with our 1.0 account management. User interfaces were tied too tightly to the back end. Heavy hitting framework and server programmers were working out UI kinks while artistic graphic designers were figuring out database calls. This was a huge waste. The site looked heinous and didn’t work the way we wanted it to.

Graphic designers don’t think in OO, let alone big-O. Server programmers don’t communicate visually.

It seems easy to fix, right? Just have heavy hitters do hard stuff and then have graphic designers make it look pretty? Make it look pretty first, then tie in the hard stuff? Not exactly. It requires a lot of planning and effort to coordinate and manage people’s time like that. It also requires serial development where people are waiting before they can start. All of which is a waste – this needs to be automatic and parallel. Don’t waste time trying to manage this if it can be done for you.

Enter REST. Enter RSS.

RSS (Really Simple Syndication) came first. Dave Winer, back in ’98, grew it from XML. It allows for simplified packaging of data. One can package and list blog entries, offer an MP3 playlist, send table-of-contents information, or transport code via codecast. At iofy we use it as a container to package web service responses.

RESTful development is also based on simplicity (here’s a great doc on REST). Get things done in an HTTP packaged call. With a very simple request in JavaScript, the web service is queried and you’ve got an RSS feed as a response. Our designers have their functionality via web services. Our server coders don’t touch the front end.

The server developers make the RSS feeds. This makes them happy and gives them time to build the critical server components. The graphic designers use JavaScript to call iofy’s RESTful Web Services API (link coming Monday). We use jQuery as our base JavaScript library. It’s damned fast to dev.

This simplified my project management. Tasks became clearly defined. In the beginning I was worried the approach would put a wedge between roles, but it worked in reverse. People understood the importance of their own functions and became reliant on each other for success.

Parallel Development.

While the design team determined a desired look and feel, the back end team planned architecture and database schema. As feeds were developed and APIs took shape, so did the layout of the site. When feeds became ready for harnessing, pages were ready. Management of the nitty-gritty became unnecessary.

We launch account management this week. You too can harness it in your language of choice (we’ll provide JavaScript code which lets you do this simply by dropping some .js on your page and a script on your server). iofy’s services are controllable from your own site.

iofy’s development team builds client software, web sites, and web services powering audiobook content delivery. We move content securely from server, to client, to iPod, and SD chip. 

<prediction>We won’t be looking at an all-out brain-drain, but with the present economic climate in the US and the present growth in Asia, we’re looking at some movement of IT in the next five years.</prediction>

Yahoo! has a lot more than search to offer – it shouldn’t be their primary business. As Scoble and Winer both pointed out, the wars are being fought on platforms – Especially the mobile platform. Yahoo!’s Go service synchronizes calendars, contacts, etc, from phone or PC and runs on Windows, OS X, BlackBerry, Symbian (Nokia), and Windows Mobile. Heck, it runs on almost every phone out there and OS X has Yahoo Sync built in. It’s been over a year since I’ve synchronized my phone by wire and I’m able to keep three phones and two laptops in sync.

Dave Winer shares insight from past technology wars while asking which platform will be adopted as the standard for synchronization of contacts, social networking, etc. I argue it could be Yahoo!. They’re embracing OpenID and offering Pipes. The Go service has plugins which tie in to MySpace and other social networking sites. They’ve got an identity system, a delivery method, and a decent reach in to the mobile market.

Finally, Yahoo’s two destinations – Yahoo! Music and Yahoo! Finance. These two are both number 1 in their class. Numero Uno. Why? They have content. Google offers search – when you’re looking for content. Yahoo!’s Music and Finance (and other sites) have that content.

These are the Yahoo! products that matter to me and the reason I’m a Yahoo! shareholder. If the sale goes through I’ll happily cash out with a profit and start looking elsewhere for services that satisfy consumer need.

It met its demise in the outer pocket of a WWDC07 laptop bag (yes, my bag, d’oh!)… Cracking the screen and becoming unusable. I don’t feel like doing a screen replacement. It’s now up for sale and I’m using the iPhone as the primary, with the BlackBerry 8800 as a backup. I’m hoping HTC will make another similar all-in-one device for mobile blogging soon – preferably with Windows Mobile 7.

<sarcasm>That’s great when you want your heavy hitting developers to do design work or when you want your designers to do low-level work (or if you want to add a layer of management to your project where you need to separate out what parts of a page are owned by what developer/designer.)</sarcasm>

Why give yourself that headache? I had that headache for a while and have a direct solution. REST + JavaScript. My heavy hitters delivered RESTful functionality for our API that can be harnessed by pretty much anything capable of HTTP. My webmaster and designers can now, purely in JavaScript, harness this API and deliver all the functionality they need with all the gorgeous style they possess.

You can too (drop us a note and sign up as a reseller.) Our API is REST and we’ve got JavaScript libraries for harnessing it. The JavaScript queries the web service and receives an RSS 2.0 response. Parse it, and you’ve got everything you need for account management, content delivery, sales, and reporting.

Now for the difficulty in JavaScript web service API harnessing… The big surprise we ran in to initially was with the failure rate of HTTP requests from client-side JavaScript calls. DNS stinks. We would make requests and randomly get failures. As it turns out, DNS will fail between 1% and 3% of the time on a typical DSL connection. You need to retry that connection…

I recommend the three-peat for failed connections. In your JavaScript (or any other language), use asynchronous calls to a function which will repeat the HTTP request up to three times before erroring out. This reduces the likelihood of failure to a cube of the failure rate.

The worst DNS providers fail 3% of the time. Therefore the first request has a 3% chance of failure. The second has 0.09% chance since the 3% that failed are 3% likely to fail again (3% multiplied by another 3%.) The third try won’t fail unless something bigger is going wrong, drops the chance to 0.0027%. This is far more acceptable than 3 in 100 and effectively removes the DNS issue of web service connections.

Monstrous servers and clusters banging on each other, effectively pulling web pages in order to deliver another web page elsewhere, is like having M1 Abrams tanks outfitted with BB guns instead of cannons.

At iofy we’re using web services with HTTP. We don’t like SOAP, but we’re RESTfully clean. Our web services API is unintentionally somewhat like Twitter’s API. However, there is a key difference. We use callbacks.

Callbacks allow partners to integrate with iofy’s web services without having to poll for updates. Both Yahoo! and Flickr do this for integrating customers.

We’re similar to Yahoo! in that the stores we power, such as The Language Stop, do not require persistent connections and would be inconvenienced by needing to implement anything larger than web service integration.

In order to keep things simple and fast (and not destroy your architecture with a polling only API) offer callbacks on top of polling. Any mid to large partner, or technically savvy smaller partner, will prefer the callbacks.

Way back when I started at iofy we had the challenge of creating PC and PocketPC applications that played secure audiobook content, displayed table of contents meta data and bookmarked. The applications needed to be under 200k, run on a 200MHz processor and be stable.A latent requirement was that the applications, to satisfy our reliability requirements, had to be statically linked so they could run from a chip without handling varying customer system configurations. Statically linked Microsoft libraries and our code within 200k in a real application. What?

Optimize, optimize, optimize.

Now we’re launching our download service which takes our original offering from a single chip on a single computer (or player) to a service which offers downloadable audiobook content.

There are more performance areas to optimize than you can shake a stick at (client, servers, db access, feed syncing, backups, etc). We’ve stuck to standards and performance as principle design requirements (and we’ve swung intelligently with big sticks.)

As we roll out iofy’s download technology I’ll touch on standards we’ve stuck to and how they may apply to you. I’ll be touching on performance considerations we’ve addressed, especially with feed synchronization. There will be pointers on how you can best integrate your eCommerce system with iofy’s API to offer downloadable content.

This is an exciting time for our engineering team at iofy. We’re seeing our latest hard work make its way to the mainstream.

Primarily I’m happy to hear that they’ve got a solid block to base their system on, “When other parts of the Twitter site go down, Starling stays up.”  From that block they can build out and have a scalable system.

And we’re going to help them build it.  Developers and customers and companies desiring to tie in to the magic are going to help build upon that block.  Heck, I’ve been buried in queue management…  I’m looking forward to seeing what they’ve got under their hood.

The 3.0 platform allows a customer or partner to plug in content and make it available for download via our download manager. If desired, the content can be secured with industry standard DoD level DRM and made available for purchase

Many people that make viable content do not have a method for monetized distribution. Many companies with content have problems with monetization.

In order to make a title available, a content provider simply provides an RSS feed to iofy. The content from that feed is converted and made available for mass consumption (if desired).

Problem solved?