High Scalability – High Scalability – Web 2.0 Killed the Middleware Star.

I had to get involved. The only catch was finding the right team to partner up with. Many of the teams were filled with people from companies like The Nerdery and TST and orgs like Ruby.Mn and I could have tried to crash the party with them but decided against it as I’d be the other guy…and they were full anyway. (Interestingly enough I was chatting with The Nerdery at the time re: employment and it would have been a great way for us to get to know each other; I ended up accepting another position before we could get intimate.) Instead I settled on a strategy of aligning with the teams that were close enough to meet the threshhold of volunteers and weren’t obviously aligned to a particular company. My other choices where to join groups with few volunteers, those centered around technology platforms I didn’t align well with like a product suite they sell, or to start my own team but finding 9 other volunteers in a few weeks seemed unlikely.

So I joined a team and put a little blurb out there and waited. And waited. And waited. And then started to think if my approach had been misguided. Typically when you’re meeting with someone you want to know better  you put on the sell and in this case my thought was “hey, I’m volunteering and by that fact I’m vetted as only good people would volunteer to work 24 hours with strangers so they have to take me.”

What I didn’t do was detail my years of startup experience, my 10+ years of web development and database work, my years leading teams, managing projects, writing content, cutting up designs back in the day when I led a team of devs in a U.S. top 40 interactive agency. I didn’t describe my 6  years running my own consulting business. Also, what I didn’t do was share my years of volunteering at places like Sharing and Caring Hands, serving Thanksgiving meals with my family in years past, working with Special Olympics for years and how last fall I spent a weekend at the Special Olympics Leadership as a mentor to an athlete.

Anyway…you know where this is going. I was rejected as a volunteer when I read this well crafted Dear John email.

This is the hardest part of an automated email’s job: I’m sorry to inform you that your request to join the “Push & Run” team was not accepted by that team’s captain. On behalf of The Nerdery and a good number of nonprofits with questionable website, thanks for volunteering. You can check out other teams that may be looking for a few good web pros or even start your own team on the website at:

http://tc2011.overnightwebsitechallenge.com/

Thanks,

The Nerdery Overnight Website Challenge

Pretty funny to me. At least there were still sites being made for the NPOs.

My mind has been on the mobile market lately for several reasons. First and foremost, I believe that the web and mobile markets offer the most exciting area of technical growth out there for consumers as well as shapers of the technical marketplace; I realize I’m far from alone in thinking this. Web commerce, web traffic, smart phone market share, mobile app sales keep rising and are trending up for the foreseeable future (I’m grouping tablets like the iPad with mobile). Second, the mobile need is now touching me personally with my latest project that has a mobile phase planned after the initial web release, this excites me to no end. If and when this project gathers steam in the market I see the traditional website ending up as a marketing hub for generating new users and existing users doing views and the mobile market centered on growth of the content that will make or break this project. Lastly, it just keeps slapping me in the face. Yesterday I read this: Reporter’s Notebook: Entrepreneurs Debate Death of Apps – WSJ.com. Last week I attended a jamSession on HTML5 with other devjammers which opened up some excellent conversations. And the week before that I took in the two day iPhone and Objective-C training session at The Nerdery to help gather my mobile strategy (thanks for the sessions, they were excellent).

As will.i.am would say “It’s a new day” and has been for a while when compared to the days of WML. So you have a new application to release to the world, you need the mobile functionality, what do you do?

Here are some options:

1. You build your website, build out the components into services and then build a mobile app for your target demographic. In 2008 that was the iPhone through the iPhone app store and hiring or learning objective-c. Today though you need to cover the iPad, android phones and tablets, and perhaps a Blackberry app (ack!). But then there is still folks like my buddy who has the Palm Pre and the recent Windows Mobile7 rollout which is coming late to the game but has some major $$backing.

   Pros: Native apps for each device will offer the best performance and experience and you can leverage the full power of the device.

   Cons: Hold on…I’m counting…for sure you have 2 new apps to build and SUPPORT and it could be 6. So the growth of your business is focused on how well your team can ramp and learn wide varying technologies like Java, Obj-C, .Net, and whatever blackberry is written in. I hope you have funding! In addition, you are tracking the release cycles for iPhones, iPads, androids and the support of those features by the manufacturers. I need to ask you a question. Isn’t this why you went to web development in the first place? Remember the days of supporting desktop apps and the customer support issues? I ask, doesn’t this model look familiar?

2. You use a toolkit. So you build your app in a tool and it will essentially compile what you want into applications for the various platforms. Sounds awesome and you can control the costs.

   Pros: You can budget, you don’t have to track the tech that isn’t core to your business.

   Cons: What if an appstore decides to ban the toolkit (like Apple did last year). Oh, and do you really think this works well for anything other than a marketing app? I truly don’t know but it seems too magical to me and I wouldn’t want to leverage my business to “Double, double toil and trouble; Fire burn, and caldron bubble”.

3. You write HTML5 ports of your site for mobile browsers.

   Pros: You keep your codebase together. Changes are easier to control and release and you have better platform independence (although viewing options will change on the varying devices).

   Cons: Is HTML5 real? Do you code to today or the potential standard or follow the leaders like Apple and Google? Are you HTML5 capable with your dev team? Will you get the deep functionality? How do you take a picture and upload it (seriously, how)?

4. You use a toolkit that kicks out HTML5. Like a merge of option 2 & 3.

   Pros: Could be the cheapest option and easiest out of the box

   Cons: You are still tied to a toolkit that is now kicking out widgets or something similar.

The choice obviously depends on your product and current situation. Take option 1 (writing your own apps), this strategy has been taken by Evernote to great success. Their model, in my estimation, is to make Evernote ubiquitous by bringing a compelling experience to every platform you use. The more you use the more you drive ad revenue or potentially pay for the product. But then you have to counter with FaceBook and their commitment to HTML5 and preparation to focus less on custom app development. Much like following the lead of Amazon in the early days of commerce, if it works for FaceBook it should work for you. (By the way FaceBook, I’ve been considering a west coast move. Wanna grab coffee? Reach me at @jacobhackl)

My take is heavy on option 3 with a slight brushing on option 4 but much of that is staked at where and WHEN you think HTML5 can support your mobile business. For now, I’m done focusing on Obective-C, I’m not going to write that custom WPF app for Windows7 mobile, android development will have to wait too. Less noise is needed. Let’s focus on the business, the core technology, and a transition to HTML5. One would hope that with more voices speaking on breaking away from apps that the movement can happen that much sooner.

Hide Main Menu.

So on 10/12/10 the WSJ had an article on scrapers which was altogether ho-hum until I saw the flow diagram for the scraping process and it got my geek on. Writing flow diagrams is darn exciting but mine end up looking like an arial view of the Colorado river as they snake back and forth. This flow is simple, effective, clean, and I like it. It also shows that it doesn’t matter what shapes you use if you use them effectively. Take that UML.

‘Scrapers’ Dig Deep for Data on the Web – WSJ.com.

Code Mastery.

Amen on this post.

As I write this I see a 2005 C# text that should probably go and the .net 2.0 framework training kit text for the MCTS…anyone need a monitor stand? The books are yours!

http://www.amazon.com/Pro-LINQ-Language-Integrated-Windows-Net/dp/1590597893