August 4, 2011
Posted by on
So, for the past month I have been working on a side project called the BikePOV. If you have been reading my tweets, I’m sure you’ve picked up on my cursing, explaining and working on making it work.
This evening I finally got everything working just the right way — and it actually works!
So, first let me explain what is going on. I took an Arduino prototyping board and designed a circuit around it. Essentially I took 12 RGB (Red, Green, Blue) LEDS and soldered them onto a circuit board. I then mounted the circuit board in between the spokes of a bike wheel. The theory is that when the wheel turns, I can control the LEDs, and make them flash in a pattern that represents letters, patterns or images. This is called a POV, or Persistance of Vision.
This idea has been done before — there are pre-made kits that you can buy from a company called AdaFruit. A company called Monkeyletric also sells a POV kit for about $60 (which is MUCH nicer than my setup, but they only have pre-done patterns). Read more of this post
September 23, 2009
Posted by on
Last week I had the pleasure of attending the Detroit Java User’s Group presentation from Josh Holmes on Application Simplicity. Walking into the presentation, I, along with most of the people that attended expected the typical UX presentation (keep it simple, stupid! among other common slogans), but I was pleasantly surprised at one of the tangents that we went across.
“If you have to think about how to explain the solution, it is entirely too complex.”
We then went into a great dialog about how you can best arrive to the most simple solution. One of the things he kept drilling to us was this : If you don’t understand what your code is doing in the background, you can’t write good code.
Today, we live in a world of code-hinting, code-wizards, code cookbooks, and frameworks that write our applications for us. Far too often I’ve been asked to help debug an application or help solve an issue where the person really has no idea what their code is really doing in the background. Dragging and dropping a data-grid onto the stage, dragging a database connection to it and publishing the application is great — but can you actually tell me what is happening in the background. Would you be able to explain why it starts to slow down after running the application was running for 5 minutes?
In the United States we tend to have two camps of people who create applications. Some people are based in computer science or computer engineering. These people have taken some sort of formal classes in computer science theory and understand memory management, multi-threaded computing, etc. The other camp is primarily developers — people who typically don’t have formal CS/CE training, and often will require the use of tools or frameworks to complete their projects. The difference is either engineering software or developing software.
Do you know what kind of code your tools or frameworks are creating? How much overhead does storing that variable as a string vs. a boolean have? How about creating your own class? How does your framework / language manage CPU cycles when you store large amounts of data?
Just things to think about. Knowing how your underlying code works, and not just relying on a tool to create your application can help you write better code. Anybody can use a tool to connect a web page to a database, but not everybody can engineer an application.