My parents were getting ready to sell their house a few months ago, and while I was there I grabbed a few super old computer books from when I was a kid. Nostalgia I suppose, and I figured they would be cool to have around. What I didn’t expect was that I would find a printout and a few pages of handwritten notes from a program I was working on when I was 9. But of course, once I did, the only rational response was to see if I could finally get it working. Which it now is.

While I know it definitely isn’t the only 6510 related project on Github, I have to assume it’s one of a very small number of CBM Basic programs. It’s a 6510 assembler written in Basic. The Commodore 64 was the machine I had when I started to really get into programming. When the thing booted up it had Basic burned into ROM, which was a fantastic way to get things going. But I knew what was really going on underneath was all machine language, and that the real programmers wrote in assembly. The Commodore 64 didn’t come with a built in assembler or machine monitor, like some of the other 8 bit systems at the time did. And we didn’t have a ton of money, so getting one of the commercial assemblers at the time wasn’t really an option. So I figured I would write my own.

I actually spent tons of time manually compiling instructions and poking them into memory back then, which was insanely educational. I forgot how close we were to the hardware all the time back then. And trying to work out how to build an assembler on my own was probably a fantastic set of experience to have built up. I ended up getting my hands on a commercial assembler eventually though, and never really finished up my own version.

Like most programming problems, the issue wasn’t really with the code, it was with the data abstractions. The program was actually functional as it was, it was just kinda buggy, and relatively convoluted cause it was trying to parse the operands to figure out which instruction to use. I wanted to get the program working, but I didn’t want it to take me too long either. So I ended up cheating and used non-standard mnemonics for the instructions to pack info about addressing mode and index registers into the opcode instead. For instance instead of using “cmp ($1a,x)” for indirect indexed addressing I swapped to using “cmpix $1a”. The expressiveness is the same, it just means I can pull in a token at at time without any need to apply logic. The thing really becomes just a lookup table.

So in a grand total of about 45 minutes, including the time to figure out how to use the VICE emulator and load Basic programs into it without having to type it into the emulator, I had a working program that was able to run the example code I had been trying out 29 years ago. I think if 9 year old Miker could see that 45 minutes of hacking and the result he would be pretty impressed.

One of the nice things about getting FFOS 1.2 on my device is being able to use App Manager instead of the simulator plugin to do development. Given that the App Manager replaces the Simulator Dashboard in the newest versions of Firefox, it seems like the kind of thing developers should have access to. So hopefully ZTE figures out a way to get a 1.2+ release on their developer phones.

Note however that the app manager is available in the Firefox 26 series, which is current the pre-alpha release. You can install Aurora side by side with the current stable Firefox release (that’s the default on OS X at least). The app manager is available without having to install anything, but you’ll need to install the ADB helper to connect to an actual device. Details are in the using the app manager document. I’ve been testing it out primarily with my locally built FFOS 1.2 on the ZTE Open (inari) device.

Now comes the hard part of trying to figure out what you can put on the device to make sure everything is working before you dive too far into hacking around on your own. You’ll probably run across things like the Firefox OS Quick Start example and the Mozilla templates for Open Web Apps. None of those seem to be working to generate something you can install on a device (they work great for the simulator, running on the same machine as your development tools). Seems like there haven’t been a ton of folks working with physical devices yet.

This Firefox OS boilerplate app serves as a fantastic starting point however. Just a clone and then “Add Packaged App” in the app manager and you’ll be able to refresh and run on the device. There’s some rough bits, like geolocation isn’t working within the app on my device, and “Take picture” has some issues. However I can “Pick image” and choose camera as the source and that works okay. And the rest of the stuff like vibrate, ambient light, device orientation, and check battery are all working.

I picked up a ZTE Open Firefox OS device a little while ago. Given that developer hub says it’s a “powerful device aimed at developers and early adopters worldwide” I figured it would be good for some hackery. I read the specs, so I knew that “powerful” should be pretty suspect. I was surprised to find out that it’s not really for developers, and increasingly doesn’t seem to be all that open.

When I first grabbed it I figured maybe I could use it to just get a feel for FirefoxOS and the direction the teams were trying to push for. However, the phone ships with a 1.0.0 version of the operating system and some major basic features were missing to even use it for a day or two. For instance GMail contact syncing shows up in FFOS 1.1 (I’m not a Facebook user, so syncing using the one existing mechanism wasn’t an option). Since this was supposed to be a developer phone for early adopters, I figured that would be easy to remedy. Not so, there’s no official OS updates for the phone planned at all. Weird.

Okay, no problem, I’ll use it to just do a little poking around developing using the Gecko/Gaia stack and getting a feel for it on real hardware. However, trying to push an app from the simulator it never showed up on the phone. Rebooted and it popped up. Turns out there’s a race condition bug in FFOS 1.0 which really keeps it from being usable as a developer platform. Of course the pages talking about it say you should “make sure you have the latest version of Firefox OS on your devices”. Which we just established isn’t possible for this developer device, at least not according to ZTE. Well ain’t that just a kick in the crotch?

So of course I ended up doing what I said I wasn’t going to do, and dove straight down the rabbithole of compiling my own recent version of Firefox OS from source and getting it installed on my ZTE Open device. Turned out to be way more of an involved process than I expected given that the device is named the “ZTE Open”. I expected that to mean developer friendly. Together with the Firefox site saying the device was aimed at developers, I didn’t see any reason to second guess that assumption. Here’s the process I went through though, which should get you going from an unboxing to running FFOS 1.2 on your device. The process isn’t too horrible, but making sense of lots of the existing posts out there and figuring out the right order for a fresh device took some experimentation.

The first thing to do is apply the update from ZTE. This was one of the hardest parts to puzzle out for me. Turns out the firmware on the model I had was old enough that it was failing to flash the images once I had them built. There were folks posting that they had gotten certain parts working, and it was failing for me and others who had recently purchased devices. Turned out that the original firmware didn’t support fastboot, which is one of the mechanisms for getting the code actually onto the device. That V1.0.0B02 release from ZTE has instructions for how to load it using the stock recovery image, and once it’s installed you’ll be able to use the simple tools to get your code onto the device. Also nice, with the ZTE provided update.zip on your SD card you can use recovery mode to get back to a working system if you end up screwing up the system partition. Which I did dozens of times.

Once you have the ZTE update in make sure you have debugging turned on for your phone. Go into Settings / Device Information / More Information / Developer and flip on the Remote Debugging option if it isn’t on already.

Next, unfortunately, you’ll have to grab a binary image of the boot partition hacked up and ready to use. This is horrible, and it’s the other part that was really a sticking point trying to figure out. As you’ll see later on, for some reason the boot2gecko build for the inari device (which is the name you use for building for the ZTE Open) doesn’t generate a boot.img. From what I can tell it doesn’t even generate the parts necessary to pull together into a boot.img. And as I found out through multiple tries, putting the system and user partitions from a custom build together with the boot from a stock system you’ll generally end up with the OS booting and the UI layers crashing repeatedly. That’s what I got at least.

Once you’ve got that stuff the build is pretty much as described in the FirefoxOS build docs. I use an OS X system, but I did my build in a VMWare VM running Ubuntu 13.04. The tools used to interact with the Firefox OS devices are the same as used for Android development. And I’ve done that under a VM tons, so I was pretty comfortable with that part of the setup. Plus being in a VM meant I could muck with the stuff in the Linux install as much as I wanted. Below is the actual process I ran through, getting all the tools in place, configuring, and building. This assumes you’re starting from a completely fresh 13.04 install, you run through the installer and then let it pull down any updates, then do this:

NOTE: I moved the set of commands to run off to a gist cause Octopress was prettying up the quotes and making them cut/paste unfriendly.

And then you should have a FFOS 1.2 install runnable on your device. I tested mine out with my TMobile SIM in the US: phone works, SMS works, data connection works (though by default it was disabled on mine, just use the notification pulldown and toggle the cellular data option right next to the wifi toggle). Hopefully as the device and OS evolve this gets a lot easier and more developer friendly. Needing to pull a binary boot image from someone else just to get a fresh build onto a device, that’s not good. I was expecting FFOS development to show up Android development in terms of encouraging developers to work with the base system. Not the case so far.

A few weeks ago Nathen Harvey was kind enough to stop by and give us a critique of how we do Chef automated testing and some workflow suggestions. We had been using chef-solo to do some of the recipe development and automated testing, but all our real deployments were done using chef-client. And the differences between solo runs and chef-client runs kept biting us. We had seen the stuff Lookout Mobile has done to run a VM for the chef server in addition to the node during testing. But that seemed like an awful lot of overhead. Fortunately Nathen gave us the awesome hack of using different organizations for the different developers of chef rules, different organizations for CI, and then the production organization. That gives us complete isolation of the different working areas, but still keeps setup relatively simple. w00T!

His suggestion was to use the knife-block plugin to make swapping around between organizations easier. Definitely an awesome tool, and very useful. But we ran into a few issues because knife-block uses a different method for finding it’s knife.rb file than the knife command does. So I pushed up a fork of the original knife-block code with a change to how it picks up the configuration location. This version uses the Chef::Knife config loader to find the actual configuration being used, and uses that directly. In the original version it borrowed a function from Chef, but that function tried to find knife config by looking for a .chef directory somewhere in the parent directories on the filesystem. The real Chef config loader looking in a bunch of additional places. So the result was that if you had your config in ~/.chef and ran your knife block commands from your home dir it worked fine, but if you cd into /tmp suddenly your knife block commands would freak out.

Once I dug in and saw what was going on, I figured it would be pretty easy to fix up. After looking at the Chef code it became obvious why the knife-block stuff did things the way it did. I hate to have to monkey patch to get things to work, but the change is actually pretty trivial. I ended up injecting a get_config_file method into Chef::Knife so that once I constructed a Knife object I could ask it for the location of the chef config file. Now if knife itself works, I’m sure knife-block will end up pulling config from the same location. Useful for when I need to login to the CI server and poke around to do some debugging (Bamboo stores the test files outside of the home directory of the bamboo user in our configuration).

For the testing itself we use some Vagrantfiles with definitions of the different server types we have. Knife-block provides a nice easy way for me to test against an mrowehl organization, and then use a devops-test organization for some automated validation, and finally swap to the prod organization to push stuff up live. So of course I want to be able to use the Vagrantfile when I’m testing locally and developing recipes, and use the same Vagrantfile on the Bamboo server with the devops-test organization to validate that everything is working. I didn’t want to have to go in and edit the chef-client provisioner config to swap organizations though, and using something like environment variables to drive it just seemed really ugly. Fortunately we ran across this post about pulling vagrant chef-client config from knife.rb and ended up putting together our Vagrantfiles so they automatically follow where knife-block is pointed. Together with the changes in the Vagrant 1.3 series releases to automatically remove node and client from the server when you do a ‘vagrant destroy’ it makes for an awesome testing setup. Just use knife block to swap around to different organizations and up/destroy your boxes as much as you want, your wanton path of destruction just gets all swept up automatically behind you.

With the vagrant config hackery in place it doesn’t matter what organization we want to test against, the text of the Vagrantfile can stay the same as long as knife is pointed to the right place. That made it pretty trivial to put together a simple wrapper Rakefile to clear and populate the organizations. With those wrappers all our Bamboo server has to do is:

• grab the latest from our chef-repo with git
• ‘knife block use devops’ to swap to our test organization
• ‘rake delete_all’ to clean out the test organization
• ‘rake upload_all’ to put all the new cookbooks in place
• ‘vagrant up’ for the actual test
• and then a run always ending task to ‘vagrant destroy -f’

Fortunately the vagrant up command returns the exit status of the chef-client run as the status for the command, so picking up failures is pretty trivial.

Of course, this stuff isn’t perfect. The tests always run in our ‘dev’ environment, which has the cookbook versions unpinned. That’s how we can clean out and reload the organization each time without it causing trouble. Of course if you had pinned cookbook versions you would have to add in some logic to make sure you could load the proper version each time you reload. But for our current level of complexity, just knowing that the latest batch of changes doesn’t completely break is an awesome start.

It’s not quite ready for a release yet, but I’ve also got some Packer templates which converge a node using chef-client and export the Vagrant friendly box so I can distribute the VM. Once I have them cleaned up a bit I’ll post those too.

Update: The change for knife-block to follow the same knife.rb lookup logic as Chef has been merged into the main repo.

A few weeks ago Arte and Mario asked me to swing by to chat with folks participating in the Momentum accelerator to talk about scaling technology. While we were talking I pointed folks to a few posts and videos of talks I consider to be some of the root nodes of a lot of other conversations. I’m not sure I’ve ever pulled this together before.

• Allspaw/Hammond - 10+ Deploys Per Day
• Randy Shoup - Ebay’s Architectural Principles
• AKF Partners - Splitting Applications or Services for Scale
• High Scalability
• Netflix Tech Blog

That Allspaw/Hammond presentation is the most primary in my opinion. It’s the talk that lots of us consider to be the inflection point of the devops movement, when the practice started to really gain visibility. What had previously been a random collection of techniques we didn’t have a great way to refer to became “devops”. There’s a ton of useful information in that presentation. Not just the overall concepts of dev and ops working together with a different kind of coupling, but some specific tools to make that happen like shared metrics, feature flags, and shipping dark.

The presentation from Randy Shoup has also withstood the test of time fantastically well. The four architectural principles are great top level items: partition everything, async everywhere, automate everything, remember everything fails. And the presentation from AKF Partners dives into a bunch more detail about how to partition services so that you can just throw hardware at problems. That model also provides a lot of the basis for most of the conversations I end up having about geographic distribution of services (which actually sounds exactly like a discussion about how to design the I/O layer of an operating system, you just swap terminology).

The High Scalability and Netflix blogs provide great concrete examples of what some of the problems and solutions look like. Principles are great, but like always there’s more than one way to do it. So it’s great to have some concrete examples to poke through. Plus Netflix being one of the pioneers of the static AMI methodology of infrastructure automation it makes their approaches particularly strongly opinionated.

The platforms themselves have changed the level of abstraction you need to work at when putting this stuff into practice. Thanks to MongoDB and Riak we don’t have to wrapper tons of instances of MySQL or Postgres to make a datastore that scales horizontally. And thanks to services like Elastic Beanstalk, Heroku, and EngineYard we don’t have to pay as much attention to how to distribute load across multiple application servers. But even though you can count on your platform to remove a bunch of the details in some cases, it’s a good idea to understand the principles. First of all cause it’s possible to misuse the platform and end up not getting the full advantage you could. But also because platforms can only help out so far. Eventually you need to crack open the abstractions and either continue with an application optimized line of evolution, or figure out how to wrapper additional layers of capability around what the base platform provide. In either case at least being aware of the principles your underlying platforms are working on will pay back hugely.

How do you start introducing some testing if you have a huge group of existing projects, for the most part all implemented using different languages and technologies? That’s the problem I’ve been poking at recently. The first issue is that none of the technology choices were made with testability in mind. And I don’t want to have to go through and run a bunch of code refactoring and reorganization just to start testing. I would much rather start testing, and then start introducing changes to make things easier to test and to increase the coverage. The second issue is that we’re pretty sure there are some major architectural changes and redesigns coming in the short term. So to dig in and harness up the guts of a bunch of systems we know will be changing really shortly anyway also doesn’t seem like a fantastic idea. Plus some of the changes are more about the operating environment than the code itself, and a bunch of unit tests won’t necessarily help us figure out if the web services break when we move from MySQL 5.5 to 5.6.

The most obvious and brute-force way would be to recreate the whole end-to-end environment and create some system tests for it. I think that would be too brute-force though. I would like our first step to provide some tools that would be useful to developers and the infrastructure folks. A whole end-to-end environment might be useful for infrastructure, but would be a burden for development. Even if this were running up on AWS, imagine having to spin up a dozen instances and wait for them to initialize just so you could test your one change. And the system as a whole definitely wasn’t built with testability at the granularity of the entire infrastructure in mind. So good luck being able to hit even a small set of the conditions the running systems are subjected to.

No, what we needed to start were a few automated acceptance tests at the granularity of the individual architecture components. Fortunately, cause much of the process before was run off manual QA there are collections of test cases floating around for lots of the components. And there’s frequently even a description on a wiki page of how to configure a QA environment for a given component (for example how to setup a database, configure Tomcat, and install and run a web service). So now it’s just a matter of being able to script all that up.

Since I wanted these tests to be useful both for development time checks and infrastructure validation that meant they needed to run on an environment as close to production as possible. But setting up a bunch of testing environments introduces a whole other set of problems potentially as large as the set we’re trying to solve. Spinning up the instances in the cloud might work, but also introduces a different level of complexity. I wanted something that a developer could have available right in their project checkout they could use to validate their work as they go along and ensure there won’t be any surprises when trying to run in production. Fortunately, that’s exactly what Vagrant is meant to provide.

With Vagrant and VirtualBox on a development machine it’s easy to spawn a VM running the same version of CentOS we’re running in production. The instructions for setting up a QA environment become provisioning scripts for the Vagrant config, which automatically get run when the VM launches. The automation for the test cases themselves or loading data need to be handled on a case-by-case basis, but with the ability to sync files between host system and VM and automatically configure port forwarding into the VM it makes it much simpler to bundle everything into a single command.

Cause we’re testing at the same granularity at which these projects are deployed, we don’t have to refactor the projects before we can start automating some testing. The projects already have well defined input and output points, which is how they communicate with the rest of the infrastructure, so we just latch onto those. Now, admittedly, the service contracts for lots of the projects are fuzzy at best. Cleaning those up is one of our medium term goals. But at least now we can start with testing in place and then start changing stuff.

And if the infrastructure folks want to try running on a different distro, or using a different version of a package, they also now have the tools to check changes without having to run things through QA. Make the necessary changes on the VM and then run the script to make sure nothing has broken.

For this to start looking like a proper continuous delivery test setup we should be driving the setup of the VM using the same configuration as we use in production, which is why we’re also working on swapping to a more robust infrastructure automation system than we have currently. For example, Vagrant allows Chef or Puppet for provisioning instead of using a shell script. And instead of using the synced filesystem to move data back and forth, the system under test should be deployed using the same tools and process as the deploy to production. But at least there’s movement in the right direction now.

I’ve done a bunch of angel investing over the last few years. And I’ve decided I’m no good at it. The market, so far, seems to agree with me. Most of the investments I’ve done are nowhere, frequently not even making it to launch. That’s okay actually, not a big deal.

What the realization has forced me to do is cycle back on why I was angel investing in the first place. I really wanted to do it so that I could help friends realize their dreams. There are tons of people I’ve worked with over the years who have fantastic skills and often correspondingly focused vision. That sounded like a great investment thesis to me, folks who I’ve worked with directly. And I figured that giving them some money to help out when they were starting on a new effort would be a great way to share in the adventure.

However, there’s a bunch of stuff I missed the first time around:

• I’m bad at filtering ideas. I think everything is a good idea. That seems to just be a bias of exuberance and having been an operator myself for the last 20 years. I project how I would attack the problems, and assume if it’s something I can execute on certainly other people can. In retrospect that was dumb, and I should have realized this one in advance.
• I thought I would be able to directly help out. I’ve been building businesses and technology for 20 years, I normally have a lot to contribute. However, once I’m an investor teams tend not to come back to me for help. I think cause most of them only want to come back with good news, they’re kinda embarrassed to come back to an investor for help. That’s just dumb on their part. I use my investors for help all the time, and they’re always supportive, encouraging, and effective. Trying to run success theatre is dumb.
• Venture funded businesses, and the current crop of startups in particular, are really focused on short term financial gain. There’s not really much “realizing dreams”. Unless your dream is to flip a company to Google. So it’s ended up being kinda boring. If it was even in there to begin with, vision frequently takes a back seat. And the companies just randomly pivot over and over, flailing around trying to find instant product market fit and 10x compounding daily growth cause they think it’s rational to expect that. Of course they never do.
• At the levels I’ve been investing (normally very small stuff like $10k to $25k, the occasional $50k) it just doesn’t shift the needle. Coupled with folks not coming back for help: I’m not getting any leverage out of the investment and the teams aren’t getting any leverage out of the money.

So, of course, the real next question should be how do I fix it? I could just give up on trying to make awesome things happen. But that’s not really my style. I’ve also been tempted to dust off lots of stuff I learned from Churn Labs and try to run a similar effort, with significant tweaks this time around. That whole line of thinking is worth a post of its own actually.

Recently I had to do some legal work that required me to actually go through and enumerate all my assets in one place. So the shares I have in companies that I’ve invested in ended up side by side with the list of companies I have shares from cause I’m advising them. And the difference was shocking. The folks I spend a bit of time with every month, they’re rocking it. That says to me there might be something to me being able to directly help out. Now correlation is not causation, I’m fully aware. So it might just be that the folks who aren’t asking me for money are predisposed to a working style that increases the chance of success, and it really doesn’t have anything to do with me at all. But right now it’s a working hypothesis at least, and I’m willing to test it.

There are actually a bunch of different methodologies I’ve been thinking about to put that test into play. But then my current company got bought (which, by the way, I’m using as an additional point in support of my hypothesis :-P), and for once I’m finally enthusiastic about working with the new team for a good chunk of time. So that severely cuts down on the plans I can realistically put into action over the next few years.

That means if I want to keep involved it really needs to be as investor, but I needed to figure out how to:

• Work on things that are going to change the world in a positive way, and that me and the team will be proud of.
• Make sure there’s a way to keep myself directly involved, so I can figure out if I actually make a difference at all. I need to figure out a nice scientific approach to determine this still.
• Provide real leverage to the teams.

There are tons of incubators and accelerators out there now, and I didn’t want to be just another “me too” in a sea of mediocrity. Fortunately they tend to really focus on different businesses than I would like to go after, so I’m thinking I can do something that isn’t duplicative. There are tons and tons of little companies spun up to try to exploit tiny gaps in existing markets, and relatively few looking to open up new areas. In other words there aren’t too many SpaceX style projects out there. And I would like there to be.

My plan is to start filtering the projects I work with using a completely different set of criteria going forward, to take a much more active and direct role in the projects, and to start investing in the $250k to $500k range instead. I’ve got one of these starting to come together now, and a few other discussions with folks about the overall model. I think the right model for myself is actually to keep this to one project at a time, just to keep myself and the team focused. So I’m probably going to also start being a lot more low volume than I have been in the past.

I love the idea behind social media services, helping to connect people and strengthen relationships. However I don’t think most are actually fulfilling on that vision. Sure, you can stay connected with friends. But your goals and the goals of the social service itself frequently aren’t aligned. The desire of social media services to drive the metrics they want based on your connections to friends and family have resulted in systems that prey on base urges. The result is systems that drive themselves off addiction loops. In the end they’re like overeating or smoking, bad habits. And I assume most people will look to weed out those behaviors in the interest of their overall health. That’s my view at least, so I took the plunge and deleted my Facebook account about a year ago.

At about the same time I decided to crank down a lot of my tech news consumption, and filter down the folks I follow on Twitter to people who regularly post things that are uniquely amusing or valuable. I had realized what I was really trying to do was:

• make sure I had a good spread of new info coming in to keep generally informed
• keep on top of what was going on in my industry

So I focused on directly solving those problems instead of having someone else try to correct for them by proxy. The first part was kicking back up my long-form reading habit, I started downloading and consuming lots of Kindle books. When we were working on Churn Labs I wanted to learn more about places that created long periods with high levels of innovation. In the info I was finding online I commonly came across the same examples over and over. Places like Florence during the period of the Medici family, or Apple, or Corning. But most of those posts online referenced books for details. In following up the references and just trying to get some details I picked up a few books and read them through.

At the time it had been a while since I sat down and read a book front to back that wasn’t either sci-fi or highly technical. I found that for the purposes of “researching” something, trying to dig into a new topic and understanding it well enough to be able to make a mental framework and form personal opinions, I was getting a lot more out of just reading long-form writing. When it comes to picking up a new subject most online resources don’t do a great job. I think that’s why there’s so much attention right now being thrown into “online learning.” The Internet is a fantastic way to keep up to date with a topic you already understand. But it’s generally falling flat when it comes to getting up to speed with something new. Fortunately for me I pick things up relatively well in written form, and I’m pretty good at filling in practical experience on my own. So when I hit something new, sometimes I’ll follow up the cursory Wikipedia overview with a book if the topic seems interesting enough. It can get to be an expensive habit, but I’m finding it to be well worth it. Hopefully soon all these education startups will make free resources I can use instead, but for now I’m sticking to the books.

Listening to podcasts has also helped a good deal with getting an overview. A bunch of the topics I’m interesting in following at a high level. I don’t have the background to follow all the details of new info, but I like to at least keep informed about major advances in science or engineering. Audio format delivery seems to be great for that. Lots of the podcasters keep things high level, I assume cause that’s best suited to the medium. So adding just a few shows like the Economist and Science Friday has made me feel like I’m pretty well on top of all the stuff I really care about. And I just use an app (Stitcher on Android for me) so I can listen to the shows while I walk to/from the train station. Fills up time that wasn’t really being well utilized before.

Then I had to figure out how to keep up with the details of the industry I’m working in. Or at least I thought I had to. Turns out that the generic information sources plus directly operating in the industry was already feeding me more than enough data. I lost a lot of noise by not following the tech industry coverage. And I figured keeping on top of daily events was necessary for conversations with other folks in the industry, otherwise you seem ignorant when someone asks you about a hot topic. But I found that with the noise gone I had stronger opinions and better judgment anyway, and the discussions I had were actually higher quality. Probably cause I had spent more time exploring and validating my own viewpoint, so I had a lot more to contribute to conversations.

Every now and again, there’s something that’s absolutely essential for me to catch quickly. What I’m finding is that normally someone will forward it to me. Usually to get my opinion on it. And I find that cause I’m consuming things outside the channels most folks pick through, I can serve that same role for others. Really, that’s my “social network” doing what I originally hoped it would do. Turns out the social tools were standing in the way.

This blog has been dormant for a long time, but I’ve decided to start it back up. I created the site cause I wanted a Wordpress install I could test my PalmOS based mobile blogging client against. But once I had the site up and running I started tossing all sorts of random stuff in. Everything from my own thoughts on scalability to summaries of events about the FabLab. However, after a few years of tossing all sorts of random stuff in here I started to really focus on mobile, so I created a mobile specific site called This is Mobility so that I wouldn’t have everything all jumbled together. Then with so much interesting stuff happening in mobile this blog eventually fell into disuse. And it’s remained unused since 2006.

Recently I’ve felt getting a little more randomness going again is a good idea. And I’m really happy I kept all these blog posts around to read, so I could get a peek back into my mind 10 years ago and remind myself what it was like. When I started reading through these posts I figured that’s all I would do, read and then put it aside. But I realized how different my thought process was a few years ago. And not just cause I was young and naive, but because I was looking at things without the encumbrance of much bias. ”Beginner’s mind” is probably the best term for it. That beginners mind decided that Linux and open source were a good bet for building online services. And that beginners mind decided that homesteading a spot in the mobile world was a good idea back in 2003. I wouldn’t pass on getting a bit more of that beginners mind, and it seemed like writing here again could help with that process. With the site being 10 years old, it seemed somehow proper to bring it back.

Of course, some updating needed to be done. While I love Wordpress for some things, I’m also getting tired of it getting exploited and abused cause I pay so little attention to it. It’s my own fault for not updating it, but I really like the option of swapping to something I don’t need to pay attention to instead of modifying my behavior. So I swapped over to using Octopress, which uses post files written in markdown to generate the site as a static set of pages (hat tip to Tony for the suggestion). Thanks to a fantastic set of scripts called exitwp I was able to move an export of my Wordpress data right into Octopress friendly format. Yay! That should be the end of Viagra and Levitra ads randomly appearing at the end of my posts. And as a bonus I can publish the whole thing through Github Pages, and store the source in Github. Which I was doing with the rowehl.com site anyway, but had to take special care to backup the database to keep blog posts safe. Now it’s all just one repo. And cause the pages are hosted directly off Github, when I crash my personal server doing Linux distro hackery I don’t take down rowehl.com.

Also nice about Octopress - the default profile takes a responsive approach. So now my personal blog looks better on mobile than my mobile focused blog. With the way the Octopress templates and plugins are structured it was pretty easy to make some style changes, swap in some fonts that make the site look a little less amateur hour. I got rid of commenting all together and have added some share buttons instead, cause that’s how the world works now. Everyone already has their own place to speak, so why put their thoughts into my database? And again, once less thing for me to worry about.

In the end, actually not much effort at all. And I’m really happy with how it works. Now I have a place to write about all that other not-specifically-mobile stuff like cool bits of open source, programming, emerging technologies, and startups. And to remind myself just how far things have come, I dug up and posted the source code to the Treo650 blogging app that kicked this whole thing off 10 years ago.

I was just installing the Sun JDK on my workstation at the office, and when I tried the obvious: apt-get install sun-java5-bin got an error message about not being able to find a license. Interesting, thought I, “there must be a higher level package wrappering this whole thing that deposits a license file somewhere for the apt-get process to pick up”. A bunch of searching around in the repository listings turned up no java license related packages.

You find where download mp3 music on player, You need mp3 music download from online mp3 archive

So I did a search and ended up with this description of installing Java under Ubuntu which says pretty much what I was doing, except using the graphical package manager instead. “How lame would it be if you needed to install Java using the Synaptic package manager instead of the command line?” Not lame enough to discourage doing it apparently. If you’re looking to install Java under Ubuntu you might have to use the package manager instead of apt-get in order to do it. Next time you see Java people throw rotten fruit at them to let them know how you feel about that.