HalOtis

Fermenter Built

2013-05-13T23:25:15Z

Finished the build for the Fermenter over the weekend. Here’s a video going over the physical components for the project:

The chamber itself is based on the Son of a Fermentation Chiller. with the only modification being that I made mine a bit smaller than their plans.

The django based web app is all open-source. The code & instructions for building it are available on GitHub. https://github.com/mfwarren/Fermenter

The Pi will run a django based web interface that will provide simple and minimal control and logs of the brewing process.

The electronics are fairly simple, and as soon as I figure out how to generate a circuit diagram I’ll add instructions for how to solder together the prototype board.

Fermenter Project

2013-05-02T03:42:15Z

With so many possibilities, I finally decided on a worthy project for my Raspberry Pi.

This summer I’m hoping to brew my first lager beer and brewing lagers is quite a bit tricker than ales, especially when it comes to controlling the temperature of the fermentation.

There are a number of existing projects out there for creating a computer controlled fermentation chamber. The most notable one is called BrewPi, which I looked at but it seemed to be designed with unnecessary complexity. I wanted something simpler on the electronics that dropped the Arduino components and relied on just a web interface for control.

The project starts with the components for a DIY Lagerator made out of insulating foam boards. And adds to that a temperature sensor, the Raspberry Pi and a few other bits and pieces.

The Pi will run a django based web interface that will provide simple and minimal control and logs of the brewing process.

I’m hoping for a quick turn around on this project so I can start brewing with it before summer temperatures kick in.

Exercise for Programmers

2013-04-22T15:38:08Z

Staying on top of your game is best accomplished by continuously learning and by ensuring you are mentally and physically at your best. As a desk jokey it can be difficult to get enough exercise in a day so you have to be pro-active about staying in shape outside the office.

For several years I did a lot of running, 4-5 times per week I would run between 5km and 30km. Running is a great exercise because:

it’s intense – you can always push yourself to run faster/further.
Very little equipment required – just running shoes
Local fun runs and races to keep you motivated
Great way to see your neighbourhood from a different perspective
it engages your entire body

After moving to a new city running became less enjoyable due to poorly maintained sidewalks and the only walking paths close by are along a noisy highway. So I discovered something else to focus on. Strength training.

Strength training has a number of key benefits to health. It makes you prepared for those few days a year that require lifting and moving heavy furniture or equipment. The last thing you want to have happen is to throw out your back when doing some chores around the house. When it comes to strength training the classics seem to be the most effective: deadlifts, squats, and bench press.

Regardless of if you choose to do running, strength training, cycling, swimming, walking or yoga it would be wise to trade some evening TV time for some physical activity.

Cockiness of Programmers

2013-04-10T15:55:06Z

There’s no doubt that programmers are lazy people. Anything that can be automated is, copy/paste code – you got it!

There is another trait of programmers that they assume because they can program in one language well, and have touched a few other languages over the years they can quickly learn a new language on the job.

Programmers are arrogant about their own skills.

The article What If Cars Were Rented Like We Hire Programmers? exemplifies the problem though their analogy is not accurate. A programmers job is more like the mechanic or factory worker building the car. If you had built or fixed only Subaru Imprezas for 10 years then you are not amazingly qualified to fix Fords. If Ford is looking to hire, they know that there are 1000′s of mechanics more experienced on their cars in the pool.

I say this because after several years of writing Javascript, learning on the job, I finally decided to pick up a book. The first thing I learned was just how much I didn’t know.

More programmers need to read books to master the skills they need on the job instead of relying on Stack Overflow and Google to solve all their problems when they arrise.

The thing to watch out for is the situation where you read someone else’s code and say to yourself “I have no idea how this works, or what it does”. As a programmer that should be a red flag – you don’t completely grasp the language syntax.

If you don’t have a complete handle on the syntax of a language chances are you also don’t know how to write idiomatic code. Without those two things mastered the code you do write will be poorly organized and buggy. The next programmer to come along to work on your code will hate you. You will be that guy who everyone bitches about for writing bad code.

Bite the bullet, read a book from time to time. Always be Learning.

Produce as Much as You Can

2013-04-02T15:40:28Z

It took a long time to really fully appreciate the feeling you get from producing something new in this world and letting it go for sale or for free.

There’s a lot of apprehension that comes with those first few products you release. You worry about the bugs that are still there, the features you didn’t have time to implement and the competition that is fierce.

Until you release something to the public for consumption it can be as perfect as you imagine in your mind. Real life users never match up to your expectations – they don’t know how to use it. where are the features are, what it’s for etc.

You put a lot of time and effort into building a new product. Much of the skill that goes into creation is learned through school and books. The things you learn from the first release of your product to the public can really only be learned by doing it. The only way to get better at releasing your work to the public is to do it often enough to gain experience.

So create as much new stuff as you can in this world. Get it out there for others to use. Learn as much as you can. And then do it again.

It’s the most addictive thing I know.

6 Tips For a Successful Project Plan

2013-03-26T02:38:50Z

The difference between a successful project and one that is a dismal failure can often come down to the project plan. There are different approaches to planning from ad hoc planning to full on gantt charts in MS Project. I think there are some universals for developing a plan that results in a project that works as expected.

1. Have a Vision

It’s not smart to just be reactionary – someone asks for a feature, you add it. That just results in a mess over time. SpaceX the private rocket company run by Elon Musk, runs every decision through their goal question. “Will this help us get to Mars?” By running every decision through this one question it helps to make sure that they don’t detour slowly over time. Figure out the end goal.

2. Set Waypoints

Figure out a series of releases that you could hit along the way to your final vision. Ideally have things that can be done in less than a month. Quick releases helps keep the momentum and allows you to test assumptions early, as well as build skills necessary for a better final project.

3. Trust the Numbers

You will make mistakes, misunderstand the market, have difficulty finding an appropriate sales strategy and have UI designs that your customers don’t understand or features they don’t want. You will. Be sure to have the analytics in place early to determine what actually works, and re-adjust your plan for the realities of the market as you discover them.

4. Budget, Scope, Schedule

If the project you want to finish cannot be done on time, on budget, or with all the minimum features then you have to face the real problem of re-evaluating the project or deciding to find something else. Of course accurately knowing the costs of a project before hand is impossible.

5. Talk to people

You can’t create a a successful business in a vacuum. You need customers. They may not know what they want, but you definitely need to communicate with them.

6. Track progress

When you don’t track progress towards hitting your waypoints it is inevitable that deadlines will slip and scopes will balloon. Tracking deadlines provides a bit of extra motivation to you and your team to work harder and more focused.

How to SOA an existing project

2013-03-11T19:45:16Z

SOA or service oriented architecture is a way of building a complex project so that each individual unit can stand alone with a documented API. There are many benefits to taking an SOA approach to designing a complex software system.

To those familiar with programming, SOA provides the same sorts of benefits as OOP but at a higher level of abstraction and with a network interface rather than a code interface. The benefits of providing encapsulated logical units that can hide the complexities is well understood by most experienced programmers.

For a business taking a SOA approach to building a complex project makes a lot of sense. It allows teams to be divided into smaller groups to reduce the communication load and help limit the scope of the problems that any one developer has to concern themselves with.

So how do you take a monolithic piece of existing software and change it to SOA?

The first and perhaps most critical decision to make is where to cut your application into pieces which can become isolated services. The most obvious first approach might be to cut between the GUI and the business logic. That is usually NOT the best thing to do for any real complex project. Deep coupling of the UI usually makes this division much to big for an initial undertaking.

Likewise starting with something too small can lead to an abandoned project. A simplistic project that can be ‘finished’ such that no developer ever has to be familiar with how it was built can lead to problems down the road when it breaks and no one knows how to fix it.

So an SOA unit should be logical, it should be not too big that it is destined to fail, and not too small that it can be forgotten.

A further guide to finding an aspect of the code to pull into a service is whether it will have more than 1 customer or could have more than 1 if it was a service. By customer I mean anything that might want to call into it’s API. For a HR system the customers might be the GUI used by HR department, tools used by managers, excel spreadsheets used by the CFO and a business intelligence dashboard for the CEO. With that many potential customers of an API there is a strong benefit to having an SOA approach compared to asking HR for quarterly reports or sending them emails to update an employees phone number.

One further option to consider is to wrap your entire application in an API so that it can be leveraged somewhere new.

On one project I worked on we had a complex requirement for managing encryption keys. We needed a way to expire old keys, provide redundancy against server failures, and have a nuclear missile style 2 person/2 password login process. It made sense to develop this as a stand alone service. It paid off with a project that gives us confidence that some newbie programmer can’t easily create a critical security hole in an application that uses it.

Amazon is perhaps the best case study for a successful SOA deployment. Their SOA approach has spawned entirely new billion dollar businesses (AWS). One of the benefits they’ve seen is that because of their highly used SOA APIs the requirement for testing is greatly reduced. Incremental updates get slowly rolled out providing time to listen for errors. On these highly exercised APIs regressions can found quickly before any harm is done. The actual use of the service provides a much more complete test of it than any test suite could possibly perform.

Perhaps the best place to start on an SOA conversion project is to see if there is already some natural divisions in the developers knowledge and experience within the existing code base. Creating SOA services based on these natural lines will ensure that the new teams will already have an expertise in their service and reduce the learning/ramp up time. Domain knowledge is the biggest hurdle for any programmer (ie it take a lot more time to switch from enterprise software to video games than it does to switch from Javascript to C#).

So you’ve got an idea for where to start. The next thing to decide is what the API should look like. I prefer RESTful interfaces because of the lower barrier required over something like SOAP for clients. SOAP would make things like a bash shell script difficult to do. I also prefer JSON over XML for similar reasons but also because XML allows for some style inconsistencies between developers such as should something be an attribute or child. Should authentication be done with simple username/password or are there requirements for something like OAuth?

Your team should probably develop a couple of libraries in some key target languages for their API. This hides things like URLs and encodings behind a more obvious code API.

Documentation is also very important. An undocumented API will probably never be used by anyone. Both the raw API and any libraries should be documented with examples. If it’s a public API, put your libraries up on github.com so that other developers can easily find them and keep up to date.

Work in some analytics if you can for the new API. Tracking usage and performance of your service is fascinating and can provide some key insights into where improvements could be made.

Lastly, a new SOA project will include some new infrastructure and deployment requirements. You’ll need to decide on server requirements, uptime and redundancy for this new service. As well as write any new deployment scripts for it.

So an SOA conversion is not a trivial task. It does come with some overhead which is usually made up for by growth of the service as it finds new customers and new use cases. Reducing the scope of a large project into separate services provides less easily measurable benefits such as reducing communication costs, reducing the scope of future changes and making the project easier to understand.

Next Gen Websites

2013-02-22T02:57:22Z

the web 1.0 was defined by static html pages and simple cgi scripts. Web 2.0 was marked by improvements in CSS and HTML capabilities, as well as growing influence of Javascript especially with AJAX to make things a bit more interactive.

The next significant shift in the development of websites is moving a lot more of the page layout and generation to the client side and implemented in javascript. The web server won’t be generating full pages anymore, only snippets and raw JSON for CRUD operations.

Web 3.0 is enabled through several MVC frameworks such as Backbone.js which encourage application logic to be moved client side to the browser and the server serves up the raw data and persists anything required to the cloud. These next gen websites give the developer a more clear line between UI code vs server side persistance.

It makes sense to move control of the HTML layout and rendering over to Javascript because that’s what it was designed to do. Adding a template language and renderer on the server side only to further manipulate the DOM client side is a bit of a duplication of responsibility.

The learning curve for this change is a bit steep. Check out ToDoMVC for a review of the javacript libraries/frameworks available.

Lines of Code Per Day Performance

2013-02-13T18:03:51Z

There are few arguments with programmers that can elicit such passionate hatred as a debate about measuring a programmer’s performance by tracking the number of lines of code they write per day.

There are far too many variables at play which can affect a programmers ability to type code – how well they understand the problem, the language being used, familiarity with libraries, and distractions in the workplace. Because of these extra variables it becomes unfair to compare LOC productivity between programmers or between projects.

However I do believe it has merit as a personal metric.

I am a believer in mastery through practice. You deliberately practice a musical instrument by playing the same song over and over until the performance is good. You learn your multiplication tables by practicing on 1000′s of example problems in primary school. You master Jujitsu by repeatedly doing the same throws over and over until they become instinct.

For mastery to occur the practice must be deliberate and focused on improvement. You wouldn’t get better at playing piano if you just mash keys – no matter how many hours you did it for.

Software programming is a skill like these others which takes experience to become proficient with. For the vast majority of programmers I’ve met proficiency comes naturally through years of 9-5 coding. I’m not happy with that level of performance for myself.

Measuring yourself in terms of time to code a solution to a given problem is a valuable metric to have to identify what areas you need to focus on.

For example if you took a standard example such as implement a merge sort algorithm – and tested yourself on that over time and against different languages you would be able to measure a meaningful change in your programming performance.

You might first find that you don’t know the algorithm well enough to type it out off the top of your head and turn to Google for a description of it (a detour that takes valuable time). If it’s a new language you may find points that the syntax throw you back to a book. Over time if you continued to learn you could reduce the time it takes to type out a solution.

It’s not that typing out merge sort once per week is going to be code that you would even want to keep. Just like you don’t record your drum practice and post it up in an album on iTunes. The point is to identify places in your process for improvement by asking could I have typed out this code better or faster if I was more familiar with the syntax, or knew of some extra libs to use that would cut down on lines of code.

Then once you’ve perfected that song (algorithm) move onto something new. Practice it until there is no room for improvement in your time to solve or code quality.

I believe that practice like this should improve your personal day to day Lines of Code Per Day metric to be 2x to 5x what it would have been without the deliberate practice.

Great App Challenge of 2013

2013-02-08T18:42:26Z

This year myself and a friend have taken up the challenge of releasing a new iPhone/iPad game every 2 weeks to hopefully have 20-25 finished games by the end of the year.

The strategy is to build upon 3 different game platforms for all the games. Each game will add one new feature to the platform and completely replace all the art assets to create a unique and fun game.

The first game was submitted to Apple last week. It was an update to the first game I did for iPhone called UFO Invader. It will form the base platform for the next 8-10 games. The second game, called Air Barons, was finished up and submitted to Apple last night. The next game is an 8-bit styled space fighter and will add tile-mapped levels and designed coin/power-up layouts to the platform.

The goal of this challenge is 4 fold:

Learn how to create better and better games through fast iteration of the entire process – design, art, programming, and marketing
Reduce the risk of focusing on one big game by producing many games that each may resonate with different players
Start generating a small cash flow quickly that will grow with each game release
Build out a network of games to cross promote each other

It is not going to be easy to do working just in the evenings and weekends but 2013 is the year to do it!

I’ll be blogging about the work I’m doing here on this site as I go.