It seems to be that lately a site can only be a success if it reaches tens of millions of users, heck even Google pulled Wave because of the fact that it required more engineers per user than usual and it had not reached some magical user size. My hunch is that Google has gotten large enough of an organization that it now has the problem of team politics and it may have died due to a lack of internal power or will, because for sure it wasn’t a failure of technology that brought it down. (ok, sure, maybe a lack of UX vision – but that is solvable and the reason you have beta tests.)

This expectation failure is in both directions. We as users approach a site with a given level of anticipation and it’s a rare site that doesn’t do something that makes you sit back in your chair and go “ouch, wasn’t expecting that“. But now, with the continuous development cycle and the need for a certain churn in the media, a site doesn’t have three or four months to test out interfaces or feature sets – it is assumed it will deliver on those features now. And heaven help you if a Scoble or a Leo find your site before it’s ready and has it’s feature focus stable and ready, because nothing can prepare you for that ;)

So when your reading about how this site has failed (or heck, has EPIC FAILED) please do remember that for the most part we are all traveling in the same echo chamber that is the early adopter scene. That some folks are broadcasters, some are analysts and some are consumers and that a viable ecosystem needs all three to thrive. Within this ecosystem you will always find the struggle to maintain balance between the forces and often the “top of the food chain” folks will sometimes seem to be acting out of step with the others.

It is my contention, and what I have been badly striving to make as a point (just remember i’m a behind-the-scene dev type, not a words-smith) that often, in order for growth to happen, something needs to shake up the status quo – be it something new or one of the more mature/stable pieces to do something different so as to give a chance to one of the up-and-coming pieces. You can’t have growth without change.

I would also like to point out in my ecosystem analogy above I don’t mention the sites themselves and where they fit. That is because, to continue the analogy, the echo chamber is like that little bird (a Plover IIRC) that alligators allow to walk around their heads and in their mouths. The echo chamber and the social media industry are symbiotic and exist in the realm of, heck exist for the use of, us normal users – not the other way around.

Just as quickly as my hopes were raised at the chance of adding such a cool and lovable android mini to my shelf, multiple boots-to-the-head smushed them back down as I saw that his Series 01 of them had sold out! :(

Still considering myself lucky to have found his site, I decided to followed him on Twitter in case he posted of anything new arriving in his store. Days later he announced that he was going to do another manufacturing , but this time instead of putting them on the store all at once he would ration them out across multiple days. So instead of now me needing to have fast data-entry skillz I also needed to have good timing *and* fast data-entry skillz!

Well, technology to the rescue – after missing the first two offereings I quickly downloaded an addon for Firefox that monitors pages, set it to scan every 2 minutes and then waited. Wasn’t long till the buzzer went off and I was able to enter my order! Score!

So now, like every good geek/nerd I now have some Android love on my shelf :)

Pros

• Android 2.1 Eclair pre-installed
• Nice USB cable selection in that it comes with a USB <-> USBmini cable but also a conversion cable in case your laptop/netbook only sports a USBmini connection
• The 800×480 screen is decent and looked great when viewing YouTube videos and Flickr photos
• Came with a protective case

Cons

• Keyboard almost useless without a stylus (or skinny people fingers)
• WiFi had issues connecting to some of my devices (like the Apple gear) but worked well with my Netgear AP
• Resistive screen sits above the display in a very visible manner and even after using it for an hour I couldn’t stop noticing it.
• Back of device got noticeable warm when charging and when using the WiFi
• The Android status bar shows the phone service level bars even with no phone hardware present
• Android Marketplace seems borked out of the box, i’m waiting to see if a patch will help

I’m finding that the device is going to be useful for folks who are using one or two Android apps on their phones while sitting at the couch. Because you can sync apps via sdcard or (as soon as they fix it) the Marketplace, you should be able to keep it as a non-phone copy of what your phone has :)

Overall the sticking points, IMO, are what you would expect for a very low cost device but at the same time it is a functional Android 2.1 device that is comfortable in your hands. Some of the glitches means that I wouldn’t get this if your not comfortable with sdcard swapping or the ADB toolset.

So if your looking for an iPad experiance at a clone price point, then your wasting your money and time. But if you want to test your Android apps on something other than a phone or if, like me, you have personal productivity tools that are just *screaming* for more screen space then it’s a win – even tho I know I will be replacing it in a year.

Update 1: I added a photo at the bottom of the Tablet and my Nexus One so you can get an impression of the size of the Tablet

Update 2: I’m actually syncing it to my normal gmail account so I can test the Google Apps and I saw this on the registration wizard:

Welcome to Android for Telechips TCC8900 Evaluation Board (US)

This makes me wonder what other “dev only” items are lurking behind the scenes!

Shot of the front:

Shot of the ports:

From Left to Right: power, on/off button, mini USB, earphone, microSD

Shot of the product info:

Shot of the back side:

The Tablet and my Nexus One:

Hmm, I know VCALENDAR and can hack-parse html …

So 3 hours later and I have a very basic program that reads the Schedule wiki page, sucks out all of the tables that represent the daily schedules and generates a .ics ready for importing into your favourite calendar program.

Requires Python 2.6 or 2.5 with ElementTree installed: generate_summit_calendar.py

enjoy!

\o/

This was an interesting task because it involved a little bit of each job in the RelEng world at Mozilla:

I had to update the puppet manifest which we use to distribute files and manage configurations for the build farm so the signing keystore and configuration file would get to all of the production build servers. I also had to write a small Python program to make the actual call to Jarsigner because if we just called it from within the Buildbot step, the output would include the keystore passwords and that appears on the build server’s web page – not good.

I also had to drill deep into the various parts of the Mozilla Buildbot configuration and custom code because the Android build was new and just different enough from the other mobile builds that it wasn’t just a cut-n-paste solution.

And all of this I was doing the Mozilla way for the first time and let’s just say they have some unique custom code :)

But today the first half of the task was completed and that allows the nightly signed builds to be made public. What remains is to remove some work-arounds (for the packaging and tests) and then to start building the steps required to generate a release version of Fennec for Android.

Note: If you run into any configure or make issues you may need to install some of the from-source tools I had already in place from my work to get Mozilla Firefox to build from source. I’ve covered that in detail on my Mozilla wiki page.

I used the current source tarball from the MCabber site – make sure you get the MCabber source tarball and also the Loudmouth library tarball.

Extract both into your favourite working/source tree setup

tar xf loudmouth-1.4.3+gitb5a9de5b.20100413.tar.bz2

tar xf mcabber-0.10.0.tar.bz2

Build the Loudmouth library. Note: I put all of my source installed libs into /opt that way I can set LDFLAGS and CPPFLAGS to point to anything non-OSX that i’ve installed.

cd loudmouth-1.4.3+gitb5a9de5b

./configure –prefix=/opt LDFLAGS=”-L/opt/lib” CPPFLAGS=”-I/opt/include” –with-ssl=openssl

make

sudo make install

Switch over to the MCabber directory and build it

cd mcabber-0.10.0

./configure –prefix=/Users/bear

make

make install

and that’s it – you now have a console XMPP Client!

I first started interacting with them when I was with OSAF because as the build/release person for OSAF my job was to maintain the tools used and the vast majority of them turned out to be the same tools that Mozilla used. Little did I know that I would eventually inherit the care and feeding of some of them ;)

Now jump back to the present and I’m an employee of Mozilla and thankfully the culture hasn’t really changed, sure there are some “inside” differences and quirks, but I think they have done a good job at maintaining the same look-n-feel for folks no matter if your a mozilla.com person or a mozilla.org person.

For me the most fun was browsing the internal employee phonebook and seeing people who i’ve either admired or worked with on other projects – very cool :)

So forms have been filled out, subscriptions have been made and I think I’m plugged into all of the info sources I need to be wired into – now to figure out what the team needs to be solved and start learning.

I’ve had a great time at Seesmic and have helped and participated in the different challenges Loic has thrown at us but the server environment has moved from the realm of “how do we solve this” to a more normal production environment. Combine that with the fact that the Build team at Mozilla are working with mobile builds and have a build farm of over 600 servers, I just could not resist.

So I’m not leaving Seesmic for any specific reason, just moving to Mozilla because they are offering me a chance to help solve problems that just do not exist (that I know of) in any open build environment.

I still feel that the tools that Seesmic are creating to manage the personal social network environment are top notch and the design and developer team they have are going to continue to do amazing things.

I will get to enjoy them as a customer now :)

Given that the iPad will have an optional keyboard and given that you can activate it using wifi and don’t need another Mac to day and given the fact that Apple has really enhanced MobileMe – you now have the ecosystem required to allow the iPad to exist in a home with no other computers.

Think about it – you can turn on your iPad, enter your Apple ID (or sign up for one) and then your online and in the cloud – MobileMe will handle the backup/sync requirements to any iPhone you may have and all you need is WiFi or 3G.

If you do have other computers, that’s just gravy for the experience.

Wow!

Build/Release starts from when the first line of code is created and continues all the way to when a user installs and runs your application or accesses some part of your server or service. Yep, it’s inter-woven into all aspects of a project simply because if you don’t have quality steps all thru that process you end up with crap. It may be pretty shiny crap, but it’s still crap.

I find one of the better ways to visualize Build/Release is to work backwards from the customer and outline what it would take to research and solve any problem the customer is having. This often is classified by developers as bugs, but I’ve gotten more accustomed to thinking of them as Issues – because sometimes it’s not a coding defect that is causing the Issue, but rather a process or UX problem.

Your project, let’s call it twerzle has just been installed on your customer’s laptop and bang – they have a problem. What happens next depends on how prepared you were during the Release part of the Build/Release process.

• Do you have a support link or area on your project page
• Is the version number or other project identifier easily discovered or located
• Do you have a way for the user to give you the information you need without them having to be a digital forensics major?

These items will change from release to release, so you need to have outlined what steps are required to update your web site and secondary documentation – you do have a README file or CHANGES file and that information is accessible right? So our twerzle user has found your support link on the page they downloaded the app and that page also has what the latest version is so they don’t have to guess – what is next?

• Is this link a simple email box? Is someone assigned to answer the emails? Do you have an auto-responder?
• Is the link to a support forum? Has someone been tasked to monitor the forums? Is there a sticky-post showing the README contents?
• Is the link to an IRC forum – better hope you have 24hr coverage because that’s a fast way to an irked user if no one is around to answer them 24×7

So, community support methods and practices aside (that’s a whole other subject that I don’t even begin to understand fully), you now have a support request from a user and for the sake of our example, it actually contains a version number and a complete description of the problem. This is when you find out if you have a real Build/Release process.

Given the version information for the issue, can you now go back and install a clean instance of that exact version? No, I am not talking about a developer having what they think is a clean checkout of the source. I am talking about being able to retrieve the exact distribution image and then being able to install it on a computer that has NO development environment. Yep, this step is where most projects fail as they depend on developers to reproduce issues. But that works only for coding defects – not for application usage or environment issues.

That is what the crux of Build/Release is, the ability to have all of the information that goes into a project’s distribution available to back-track and solve any issue a customer may have. What goes into this nebulous hand-waving bundle depends on a lot of details, but it almost always boils down to three items:

1. Reproducibility
2. Documentation
3. Deployment

Reproducibility means simply, do you have available all of the source code, the libraries, and the environment needed to build said source code available for each release you have made. If you do not, then you cannot truly reproduce a release and while you may be able to figure out what the problem is, you will not be able to fix it for that release. You will have to fix it in the trunk and hope that the code is the same and that the fix doesn’t break other things.

Documentation is all of the things that make up the how and why of the building and creation of a distribution. What versions of libraries are needed, what steps are to be taken, what tools and assumptions are being used and what the process is to bundle all of that into a distribution. Yes, here source code and scripts do count – as long as you include them in the distribution snapshot :)

Deployment is basically all of the above but from the point of view of non-developers. What is the process to deploy a new release for testing, how do you take the developer generated items and QA them. Once they are tested, what are the steps for deployment to the public. Do you have upgrade steps, are there extra tools and/or documentation that needs to be generated for upgrades versus new installs.

I realize I have only given a very short overview of what I consider a Build/Release process is but most of the time the above is what a lot of projects don’t do well for a lot of little reasons. I myself need to sit down and try and map out how I will communicate more details since it is so project specific.

Thanks for reading and I hope my bumbling attempt at communicating this process has come across in a useful manner.