Thursday, December 31, 2009

The Year in Technology

Year-end got me thinking about all the technology that I've been working with this year. And it's been quite a year! Since this coming year % 10 == 0 it has me tempted to put together a list of the tech I've worked with the last 10 years, but that'll have to come later.

I started the year in the middle of working on a phone application which gets Android SDK up on the list. It was really a pleasurable API to work with, and the coding style reminded me of some of the Java Swing client coding that I worked with in the past.

This year for me was about a huge push into web technologies. In my last startup in SW Architect role I got a solid start in that direction, as I headed up our push into web services (though SOAP and not REST based as this was enterprise environment).

But this year got me solidly doing some development in PHP and CSS and Javascript.

I worked on making my app available through Facebook using the PHP Facebook API and that really pushed me into the ugly details of PHP development.

Luckily on the next project I took on a good friend and colleague pushed me in the direction of Python and in particular using the Django web platform.

A big part of that project was Firefox Extension development which was really fascinating. This kicked up my Javascript development up a big notch, but also interesting in and of itself for understanding how the guts of web browsers actually work.

A couple months ago I became co-founder of a company that is still in stealth mode. Everything I did up to this point was excellent preparation for that.

It's also added a couple new technologies onto this year's list. The first is Lucene which is a Java-based indexing and search technology (no, we're not building a search engine!) which happily has a Python wrapper, PyLucene, which is what I'm using.

Just this week I've been working with MongoDB and it's been awesome. Having worked with SQL quite a bit the last number of years (first Oracle, then Postgres, then MySQL) in an enterprise application environment, building a system on top of MongoDB (using PyMongo naturally!) is awesome.

I'm looking forward to another year of new technology. Especially putting together the system for our new company. It looks to be a really exciting year coming up.

Tuesday, December 29, 2009

Asymmetric contract of APIs

A tweet about APIs that referenced this blog post really raised some interesting thoughts around APIs for me.

The short of the blog post is that it describes how a lone-wolf entrepreneur apparently got screwed over by Google changing their terms-of-service midstream on their YouTube API. The timeline is suggestive of the idea that they might have changed it, in fact, directly because of the work this guy was doing.

This raises big questions on the eco-system around creating products that leverage the API to services that other products provide. This is a big question because use of APIs has proliferated recently, and is clearly a powerful force for innovation and growth.

The APIs provided by Twitter, Facebook, and Google and the services that make use of them are high-profile examples, but of course there are plenty of others.

If you were building a bricks-and-mortar business you'd be able to enter into a contract with a supplier of some service such that it was clear what both of your responsibilities were. Even in the legacy software business, if you buy software from a vendor you can do things like get source code in escrow to protect against them going out of business and that sort of thing.

But in a world where one party makes available some access to a service, provides rules (rightly) against what you can do with that service, and then is able to change that service - the ground could get shaky.

I think what we need is the ability to "lock-in" some terms of service when using an API. The problem currently is that the relationship is completely asymmetric. Company A makes available an API and then can change the legal rules on you at their whim. If you built a business plan around being able to use that API in the way that you used to be able to - you're screwed.

Something like a "Terms of Use" would be useful - as in: "here are the terms under which I am willing to use your API". As I mentioned above, this could be as simple declaring that the Terms of Service for the API user is locked in at some specific time (presumably when the dependent party starts working with it - but there would need to be a formal commitment point).

Things as they are now are too one-sided, and you basically have to cross your fingers that the platform won't change out from under you. To keep driving innovation, I think that needs to change.

Saturday, December 5, 2009

Teamwork

A couple months ago I got an introduction to someone starting a company looking for a technical cofounder, and about a month ago I became that technical cofounder. It's an exciting space, lots of stuff to learn, and a challenging amount and type of technology to implement. Perfect! Still stealth mode, so I'm not disclosing more that that.

It's an awesome time to be starting a company, with more information and advice available now than could have been imagined just a few years ago. I'm lucky too, to be so close to the Boston/Cambridge area and the startup community there. Add to that Twitter and the insane amount of constant flow of information and advice and it is just unbelievable.

This past month what I've enjoyed the most is the teamwork involved in starting something up. The amount of raw information to take in and decisions and tradeoffs to be made when starting something new is great to begin with. Doing all of that as part of a back-and-forth as part of a quality team is outstanding.

I spent the previous year+ working on projects on my own, so this is an appreciated change!

Hopefully I'll be able to share some of my experiences and lessons learned along the way.

Friday, October 2, 2009

Inspiration

I came across an inspiring story yesterday in print, and then found that there were TED talks. There are so many lessons to be drawn from this man's experience that it's almost hard to know where to start. Decide for yourself - here's the links to the two TED talks.

I recommend watching them in this order.

http://www.ted.com/talks/william_kamkwamba_on_building_a_windmill.html

http://www.ted.com/talks/william_kamkwamba_how_i_harnessed_the_wind.html

If these links someday don't work, simply Google his name, William Kamkwamba, and I'm sure you'll find inspiration.

Wednesday, August 5, 2009

Information vs. Knowledge

I've been thinking a lot lately (in the back of my head) about an idea that I think addresses building knowledge instead of just providing information.

What I have in mind can in one way be described as an online site that would allow users to create debates on topics. More than a debate, it would be more like a community-driven argument map. Something akin to a wiki-like creation of an argument.

My hope would be that this would be something that people could use to both express their positions and to learn about the arugments for/against a topic in order to come to their own conclusions. I'm imaging what could happen if this was done for the healthcare debate for instance.

What got me thinking about this was that it seems to me that mostly what is available today are arguments from a specific viewpoint. We read blogs, articles, watch and forward youtube videos, forward emails, etc., that tend to align with our positions. It can be hard to break out of our own little echo chambers we end up in.

What I'd love is instead if there was a place to go to get the whole argument on a topic in a way that really helped inform.

At it's grandest I imagine this as a step in evolving the "Information Age" to the "Knowledge Age", by helping people organize their thoughts and think through their positions.

The idea here wouldn't be that each topic would have one right conclusion, but that the argument for various positions would be laid out in a way that people could navigate it and reach their own conclusion. And do so informed of what the arguments are for other positions, and what assumptions rest behind all of it.

The challenge would be doing this well, which is what would make it worth doing of course.

Wednesday, July 29, 2009

Importance of trying

I had an experience recently that reinforces a good lesson I think. That being how different it is to learn passively (by reading) versus actively, by trying to use it to accomplish something.

In this case it was attempting to provide the functionality I've been working on the last couple months that sits in an extension to Firefox and implementing it in a bookmarklet.

This first led me to refactor some of the code that I had written for the extension so that it separated out the parts that were specific to the firefox extension from the pieces that were more general and could be leveraged by something else (in this case, in anticipation of use by the bookmarklet).

Then followed learning about how bookmarlets work, common approaches, and the like.

Early use of the bookmarklet was successful, but I ran into a fatal problem. What I'm doing requires access to the entire web page, including all iframes. Because of security concerns, browsers disallow cross-domain javascript access into iframes. Which means essentially that running in the context of launching from a bookmarklet, I don't have enough "power" to do the things I want to do.

So in the end, the whole bookmarklet approach had to be abandoned. But the exercise was a great benefit:

1. The refactor of the javascript code that I already had makes it more flexible and easier to deal with.

2. I learned all about bookmarklets and how they work.

3. I learned more about the internals of the web browser, and specifically the issues around the challenges that cross-domain iframe access presents.

Of course, I would have been happier if the bookmarklet approach had also panned out - but I'll take what I can get.

Wednesday, July 8, 2009

So easy

I started the day with the task of deciding how I would go about integrating a ratings system and commenting into a service that I'm building the prototype for.

I've already been enjoying how easy it has been to get functionality up and running using a port of Django for Google App Engine called App Engine Patch, and also enjoying in general getting more comfortable with the Python programming language.

Anyway I decided first that I would look into integrating a third-party commenting system to address that piece, and thought I'd pick Disqus, which I've seen on various blogs and like (for reasons of threading and such).

After copying and pasting a total of about 17 lines of javascript into the appropriate template for my Django app, that was done.

I then spent some time putting together an implementation of ratings natively in the Django app. Then I went looking for a javascript UI piece, and in the process came across a ratings system that is part of something called JS-Kit.

A little bit of testing later, and removing the start of my ratings implementation, and 7 additional lines of code into the same Django template that took the commenting code, and I had ratings as well.

So, at the end of the day I had learned a lot, but also got ratings and commenting into the application at the cost of 24 lines of javascript.

Eventually I may rip these out in favor of native implementations, for various reasons. But for now - thanks to Disqus and JS-Kit for getting these out of the way!

Friday, June 26, 2009

From cheap to free

It's really amazing how the world of software development has evolved. The proliferation of platforms is incredible. I'm glad I started my career in the stages before open source changed everything, because it is nice to appreciate the differences.

A few months back I started a project with a friend. I got an account for hosting the application from a company named slicehost for $20 per month. I set up a source control repository on a service called github for $7 per month.

$27 per month total cost for developing and hosting a service is pretty darn cheap.

This past week, we ported the application so that it could run on Google App Engine (GAE), which is a web application hosting platform from Google. The cost until you get to some pretty fair amount of usage is $0. Beyond that it's pay-as-you-go with limits that you can set, so you set your budget.

At the same time, we decided to change the source control from using a tool named 'git' to a tool named 'mercurial' and in the process moving from github to bitbucket.org. At bitbucket.org, the level of functionality we need right now is also $0.

What's even better is that in both cases the price not only goes to $0, but the services improve. In the case of GAE you get an infrastructure that is operationally scalable. In the case of bitbucket.org, mercurial is easier to use than git.

What a world.

Thursday, June 25, 2009

Monday morning tech quarterbacking

I was having a discussion with a friend yesterday where part of it veered into those ideas that we, as developers, might kick ourselves for not having seen coming and developing a solution for ourselves.

Of course, hindsight is 20/20, so in a few years we'll be kicking ourselves about the ideas being developed now that we could have been doing too.

Here are some of the ones that I think about.

I feel like I should have put 2 and 2 together and realized how big IM would be. Back in junior high school in '86/'87 when I had a Leading Edge IBM clone running DOS and a 1200 baud modem, I was dialing into the school system's PDP/11 network and chatting on a program called 'dialog'. A few years later in high school we had a VAX cluster and a VT220/240 in every class room, and everyone's favorite thing to do was get on and use a program called 'talk'.

In the late 90's I grabbed an internet domain for personal use with the intent it would be to update periodically with recent happenings in my life or just things I wanted to write about. Uh, blogging.

Again in the late 90's, after New Oak was acquired and people started to leave, I tried to put together a web site where each person had a page that had information about where they were and their recent contact information that I would manually maintain. It was also common back then for tech folks to maintain "alumni mailing lists" for people that had left a company. LinkedIn anyone?

A problem I've bumped into a number of times over the years is sharing files online. Essentially wanting to get large files to another person, and not wanting to email the file. Since I have a domain and hosting I generally FTP it up and give the person a link to FTP it down. Yesterday I came across a company, drop.io, where the founders had that problem too and decided to build a solution for it so everyone could easily have the solution too.

Now, I'm not saying that it should be me with the successful companies around these ideas. But at some level I feel like it wasn't *such* a stretch to see that a general solution could be developed to a problem that I was personally coming across or a desire that was obviously there. So I feel that maybe I should have at least had a go at it.

Which leads to the present. Lots of ideas, and hard to know which one to pursue. I'm sure I must be encountering things that I do manually that could be done better as a general solution. But will I see them before they are in the rear view mirror?

Wednesday, June 17, 2009

Ads need change

I've been thinking about ads the last couple months.

It's no secret that most publishers are straining under the system of relying on ad revenue. Newspapers being the canonical example.

There's also big problems with ads that they have become background clutter that we mainly want to ignore (and a growing number of people actively block).

So - ads need to change if they are going to become more effective and less annoying. Actually, they already are, but there has to be lots more change to come.

I've seen it said elsewhere, and agree, that there needs to be less ads. The more ads there are, the less effective they become.

I really think that ads can be useful. When they are done right, an ad is just making you aware of a product (or brand) that you might be interested in.

Targeting, of course, is already and will continue to make a huge difference. The better job the ad system does of showing me the types of ads that I want to see, the better chance I'll be happy with it. No secret that this is Google's success given that they show you ads based on what you're searching for; the search is essentially telling Google pretty explicitly what you are interested in (they have to do *some* guessing of course).

I think also that ad units need to change. They simultaneously have to be less intrusive up front, but also need to be more engaging and interactive. Over time, ads may move away from what we think of as ads today. The reality is that an ad is just sponsored content delivered alongside other content that interests you (with the hope that the sponsored content will also interest you).

One innovation I think is lacking so far, and potentially disruptive, is thinking about ads as first class objects. Giving the user the ability to manage *when* they interact with an ad, and do things like share, is an interesting dynamic. While targeting provides and answer to the "what" and maybe "where" of displaying an ad, giving the user more control could bring in the crucial "when" to the equation.

Thursday, June 11, 2009

Sunday drives and technology

I was thinking recently about how much of technology is still in a novelty phase. By which I mean that it gets attention and traction because it is new and piques our interest. Twitter is probably a good and most hyped current example of that.

My thought was that maybe this was like back at a time in the US when cars were a novelty and people went for rides just because they could. Then commuting became so much an everyday part of life that the car isn't as much of a toy anymore. I guess it is the canonical "crossing the chasm" thing.

It reminds me of the commercial back in my childhood when the microwave was still a novelty that had the family sitting around watching the food turn in the microwave as it was cooked. We obviously just set the time and hit start and walk away now-a-days.

The reason I'm thinking about this is because in thinking of new ideas for technology, I want to keep in mind the difference between something that will survive the novelty phase and something that won't.

It's also just interesting to ponder what life will look like in 10 years when some of today's novelties become the fabric of our everyday lives.

Wednesday, June 10, 2009

A little history

Most recently I've spent the last year exploring some technologies and business ideas. This has led me on a journey that so far has gone through OBD-II car technology, smartphone development (Android), PHP, Facebook API, Firefox addons, Javascript, and most recently Python (django and Pinax).

My career started on the embedded side, on custom firmware developed for i960 on a custom FDDI board. In the meantime I've worked from assembly on up to Javascript.

In 1996 I was on the founding development team of New Oak Communications (acquired by Bay, then Nortel), where we developed an enterprise VPN platform. I was part of the team there that defined the C++ object-oriented core architecture of the product. My focus was on PPP and the related tunneling protocols of the day. I ported legacy PPP code to a C++ based O-O implementation, and wrote O-O C++ implementations of L2F, PPTP, and L2TP. I became an expert in L2TP at the time, and wrote a book on that protocol (happily all good reviews at Amazon here). L2TP has since evolved, and I haven't kept up with it.

In 2000 I was on the founding team of WaveSmith Networks (acquired by CIENA), where we developed a carrier ATM and Frame-Relay switch (later MPLS and more). We had a co-architect arrangement there, and I defined and developed quite a bit of the C++ based infrastructure on the embedded side and some of the common equipment subsystems. I later moved over to help out the network management group and my move up the stack began. I became the EMS architect and team lead, and oversaw the major overhaul of the monolithic EMS java application into a J2EE based solution.

In 2005 I was on the founding team of BlueNote Networks as the software architect, where we developed an enterprise VoIP software platform. In addition to definition of the overall architecture, I moved back in to C++ development to code large parts of the software infrastructure for the product. I also worked on some of the management platform in Java, and led the development of SOAP based web services in the product (implemented in Java using xfire (since renamed CXF)).

Along the way I've worked on several communication protocols deeply: SIP, SOAP, MPLS, FR, ATM, L2TP, L2F, PPTP, PPP, Ethernet switching, FDDI.

And several languages: Assembly (i960 & i386), C, C++, Java, PHP, Javascript, Python.

And of course lots of other random technologies that come up along the way.