Stephan Miller
How to MacGyver Yourself Some Software

How to MacGyver Yourself Some Software

Other working titles for this article were “Guerilla Programming” and “How to Build Rube Goldberg Apps”, but I had to make a choice.

I fell into programming because I was broke and bored, and I knew software would speed up some of the things I do, so I learned a few languages. All you really have to learn is one major language and then you can write code in a lot of the rest, because most of the common languages are very similar. At least that has been my experience. I started with Basic on a Texas Instruments TI-99/4A, wrote shareware in Visual Basic 6, then went to the web with PHP. Along the way, I’ve played around with Ruby and Javascript.

I learned very quickly that if you find the right source code, you don’t have to worry about writing a lot of code. Just cut and paste a lot and know enough to let one script pick up where another one left off. And syntax is the most important thing. Once you know where all the braces and colons go, you can pick your way around a function reference to get the job done.

Solve a Problem

Things needs to get done faster. Monotonous tasks need to be delegated to a bot. Data needs to be collected. Software you currently use is close but no cigar.

I wrote my first shareware program because I thought that the amount of bids on an eBay auction must correlate to supply and demand. In other words, the more bids a certain type of product had, the more room for competition and to make a buck. Then I took it further to the point the software analyzed the keywords in each title and compared those to the amount of bids on each item to give me a bid/keyword number for writing the titles of my own auctions.

And that is how software solves the problem of laziness when there is work to be done. I no longer had to guess. Just find the product and list it.

Don't Do It From Scratch

The software above started with some Visual Basic code that extract data from web sites. I would browse source code directories evey once and a while to see if anything hit me. Most of the software I wrote started with something else. And sometimes the idea comes from current software I use.

KlipFolioThe one I have rolling around in my head right now is something I call “Listening Device”. And it is a hybrid of KlipFolio and TweetDeck with some added extras.

Tweetdeck is a Twitter client with columns. Each of the columns can be all tweets, replies, a group of people you follow or a Twitter search feed. It in one word, rocks. KlipFolio lets you add feeds, among other things, in blocks in it’s display. It works like Windows Sidebar, but is easier to deal with. You can put it anywhere on the screen, add about any feed or mash of feeds including images and videos. It very nicely moves everything out of the way to sit on any side of your screen.

My idea is Tweetdeck with profiles and the ability to add any feed.

Let’s say that I wanted to find out what people were saying about me. I don’t have to really worry about that too much, but let me fabricate for a while. I type my name to listen for anything about me. I then choose from various sources I want to listen to. Everything from forum searches to Google Blog Searches has an RSS feed now.

The query urls would be built-in, categorized and could be manually edited. They could be categorized by updates, forum site feeds, answer site feeds, blog search feeds, etc.

The resulting feeds I can mash however I want into the available columns. I can have a forums column, a blogs column and any other column I want.

Once I set that up, I can save the configuration as a workspace or profile. Then I can use it for any other name. But I can also set up other profiles with any combination of feeds. Because I have realized that there are different modes and reasons for listening. Sometimes I may just be researching a market. Sometimes I may be looking to comment on other blogs. Sometimes I may be in forum mode. And sometimes I just be waiting for perfect questions at answer sites.

Then I went off into feature bloat land with the ability to submit to social news sites or blog from the software.

Writing the Software

I highly doubt I will be doing this part. Not unless thousands of dollars rain from the sky to free me from my work for a little while. But here is how I would start from this point.

I would learn Adobe Air. From what I’ve read so far, you can build the apps with Javascript or Flash, but don’t quote me on that. And those languages I can deal with. I have always wanted to learn Flash, but never found it very useful, but it definitely is getting there. I went through a dry period between Visual Basic and finding Adobe Air. I stopped using VB with .NET. It was too much. You had to download the huge framework files first and then the software would run. And really, I looked at some of the source and decided it wasn’t for me. I am a geek but not that much of a geek. As as side note, AutoIt which is actually software for writing macros but you can create executable files with a decent looking interface. Not for this software though. Maybe for a Wordpress installation cloner I have been thinking of.

There are a lot of open source Adobe Air apps on Google code. I would find a few that were as close as possible to what I wanted to build and start taking them apart to build my own app. I would throw the best overview of the progamming language I could find in PDF form into AceReader so I could read it faster. And then I would use the cheat sheet to help me write the code to glue everything together and make it work. Later, if I want more features, I would find another app that had them and take a look at it’s source.

Chasing the Bugs

And this is the main reason that all software for now is on the back burner. Chasing bugs sucks. It can take most of the time sometimes. And if you sell your software, it’s even worse because you have angry customers who paid money and are now having issues also.

If you are beating your head against the wall, come back to it. Sometimes we read what we think we see and not what is actually there. You can stare at the same code for an hour and never find the bug. A lot of the time, when you come back to it later, it sticks out. Not that I always did this. I am sometimes a stubborn ass.

And that’s about it. Probably boring, but that’s a quick blueprint on writing software MacGyver style.

Stephan Miller

Written by

Kansas City Software Engineer and Author

Twitter | Github | LinkedIn

Updated