Mike Smullin

Mike Smullin

Husband, Father, Entrepreneur, Investor, Engineer, Artist, and Self-motivated Student currently located in Eagle Mountain, Utah.

Yahoo Messenger: mike_smullin

Jabber/GTalk: mike.smullin@gmail.com

AIM: mikesmullin-ut

Posts by Mike Smullin

Game mechanics, social rewards, analytics for web apps

1

I love what Valve is doing with their Left 4 Dead 2 and Team Fortress 2 software. Achievements, unlockable weapons, mutations. All great ways to monetize beyond the initial retail sale.

I have often thought these strategies could be applied to websites. Here are some companies who agree: (more…)

IT Jobs: California, or Utah?

1

I’m 25 and I’ve been propositioned to move for employment many times now. Nearly every time it has been to move to Cali. I am reluctant because I feel there is something special about the Utah IT market… (more…)

Abnormal Management with Niko-niko Calendar

0

In the manufacturing industry, in the field of production management, there is a process known as abnormal management;  a clever measurement system designed to provide prior warning for defects in work products where people are involved.

The Niko-niko Calendar is a tool for automating this process and measuring abnormalities over time. Like many modern manufacturing innovations, it originates from Japan. The Niko-niko Calendar plugin for Redmine is a modern version of this tool that should integrate easily with our existing processes.

The value I see in this technology applied to my work specifically is in the harmony of business interests and developer’s needs.

Imagine a report containing a single table. Across the top horizontally you see each numeric day of the month, and down the left side vertically you see people’s names. In the center you have a matrix of emoticons. (more…)

Programmers: VirtualBox is a better Development Environment

3

You may ask why use an Oracle (formerly Sun) VirtualBox (VBox) Virtual Machine (VM) for a development environment when coding? From the perspective of a developer on your team, the answer is, for several reasons:

  • We can have the same development environment regardless of our desktop environment.
  • We set the VM to 512mb memory to start, which is like the remote VPS server environment. This is nice because you can scale memory and/or cpus up or down at will, and instantly with a few clicks. A great way to test your application under various loads.
  • By starting the hardware resource limits low (mem and cpu), we limit how greedy the stack can get. If the vm freezes, the rest of your system does not.
  • Starting with constraints forces us to build efficient code from the start, instead of refactoring for efficiency later (which realistically never happens). The same is true for bugs affected by the environment, which previously you would only encounter once you attempted to deploy to a remote development or production server. When you are deploying to production, that is too late to be finding out you have bugs related to environment differences.
  • With VMs you can take snapshots of the hard drive at any given point in time. Snapshots taken thereafter are similar to version control in that only the differences are actually saved. So it’s efficient, quick, which means less expensive. When you mess something up with the install or environment you can just roll back to a time when everything was working.
  • The use of snapshots can become like a form of unit testing. You can make copies of working environments to start new projects. You can test source code (e.g. from outside the VM over a mounted vboxsf or nfs share) in different points of the snapshotted environments.
  • Also, consider your other projects not in a VM. When you need to switch gears, you just start or stop another VM. It takes a few seconds, and you can be running several different versions of Apache, PostgreSQL, Ruby, PHP, and all other sorts of programming tools. This gives you precision in developing. No longer do you have to hold back to the old verisons of software in order to stay compatible with all projects. You can develop your applications on the bleeding edge of technology. And save resources by only running the tools you need when you need them.
  • Once you get the vm setup correctly, you can quickly send the entire environment to your peers. For teams on a gigabit LAN, the time to transfer a typical 1GB virtual disk image (*.vdi) is trivial. For teams across the planet, preparing instructions like the ones below are often faster and take on average 1-2 hours to complete. Not to mention if you put it on a USB drive you can take it with you anywhere you go.

There are more benefits as you will see through using it, but you’ll need memory; at least 1.5-2gb is preferable. Less is technically possible but you’ll see performance hit depending on the size of your VM.

Ultimately, the result for those using the vm image is an instant development environment, with no dependency conflicts, configuration quirks, or hardware differences. On average with this I have new development team members able to join the team brand new and start contributing meaningful code in as little as 6 hours on average, versus 24-32 hours for the non-vm approach. But with the non-vm approach you have to consider all the problems you face down the road that end up being  environment differences.

Below is a pseudo bash script outlining how to prepare one of these virtual machine images (*.vdi) using Ubuntu 10.04 (Lucid Lynx) 64-bit.

UPDATE: I haven’t used this script in a few months now; I found it easier to make a base image and use the `VBoxManage clonehd` cli command to copy and modify. There are numerous reasons for this but among them: its faster, its easier, it has all the latest updates including any quirky setup preferences you may have at the time. But the script below is still good for getting your first few images started.

(more…)

Google Picasa’s Facial Recognition Technology: So good, it’s freaky

1

I was playing with Google’s Picasa and Picasa Web Album yesterday. They have a facial recognition feature provided in both the desktop app and the web app. So the desktop app scans your hdd for pictures with faces, and the web app scans your albums for faces and gives you an opportunity to tag the faces. It was scary how accurate it was at both finding faces in pictures AND grouping them. Out of my album of 17 or so pics, it recognized that there were only 5 different people in them. Pretty freaky when you consider Google is required to comply with government wiretapping/spy requests, and that similar technology is being used in our traffic cameras.

Mike Smullin's RSS Feed
Go to Top