Archive for March 2010

Do Research. Don’t Be Just A Code Monkey.

March 22, 2010

I don’t think that good developers are good because they’re overly smart and well suited for the work. Being smart is definitely a plus as it helps get to the heart of problems faster, but even the blade of the keenest intellect will be rendered blunt by the muffling sheathe of ignorance.

Waxing poetic aside, you can’t do a good job if you don’t know what you’re doing. No matter how good you think you might be, you can be better by research, study, and experimentation. I feel that this sentiment applies not only to programming, but to all matters of life. The driving force behind this reckless abandon in the pursuit of knowledge and research is passion. You might not have a passion for your job, but hopefully you have a passion for programming (assuming your a programmer… insert other career as it will work well enough in substitute). If you don’t, consider finding a different career, one you have a drive and desire to succeed in. You’ll go farther in an area you have a passion for than one you don’t. It’s better to be an expert at a “lesser” career than a bad or mediocre at a “higher” career. No one wants a rocket surgen that doesn’t really have a passion for rocket surgery.

“But how?” you may ask, thinking that just saying to ‘research’ without any idea of what goal to pursue isn’t very helpful advice at all. Well that might be true, but everyone’s passions, interests, and job requirements will differ so saying ‘learn about parallel processing’ or ‘research distributed computing’ or ‘learn Ruby, it’s awesome’ isn’t very helpful either. But there are a few methods you can use to start your exploration.

The main idea is to explore areas around your current job, but perhaps not directly related. Try learning a different language that you could, theoretically, implement your same work project in if you knew the ins and outs of it. Maybe start a personal project at home that uses that language to discover the differences between it and something else you already use. Sometimes the features of one language can give you ideas how to better use the one you’re stuck with. If you’ve ever used closures in Ruby (or another language that has them), you’ll start thinking about your Java or C code quite a bit differently.

Another excellent thing to do is learn a new framework or way of doing things that is not the norm for your day to day job. Let’s say you’re writing web apps that deal with a lot of relational database transactions and data manipulation. Try learning about non-relational databases such as object databases or NoSQL. There are many open sourced, non-sql dependent databases that you can try out to learn how you can store and retrieve semi-structured data in a non-relational way. Try to figure out the benefits you gain with your current methods, and compare them to the benefits you’d gain if you switched to a different one. You probably won’t switch your work project over, most people don’t have the authority to do such a thing, but it’s still useful because you’ll open your eyes to different ways of doing things which will end up translating to useful knowledge in your daily job.

Learn a new language every year. Do personal projects in that language. If it’s scripting, maybe make some scripts to help your day to day life out a little. Knowing how to utilize more langages will help you appreciate the differences of them and allow you to be better able to pick the best tool for a given job. It also doesn’t hurt when someone at the office starts asking for someone with experience in some new language and you’re the one who knows anything about it. Embrace change, and don’t get stuck in a rut.

Learn something new every day. Be it a use for a framework, a new language feature, or just something about your own code. Continually learning is critical in the high tech field, as you’re knowledge goes out of date way faster than a lot of other professions. Letting yourself get out of date is like letting a knife rust. It won’t be very useful to its user for long, and will be replaced if it gets too far worn.

Test your code before you write it. Test Driven Development really works. You’ll end up writing way more test code than you ever did before, which is a good thing. You might also notice that you structure your code differently if you write your tests first. The main idea is to allow each piece of code to be tested individually from any other piece of code. If you have a class that you want to test a method of, you should be able to fully test that method without implementing any other class. Any reliance on another classes behavior should be implemented through mock objects. Keep your code decoupled and program based on interfaces. It might not be a bad idea to look into a dependency injection framework, or to get familiar with the finer points of the factory design pattern.

Learning and knowledge is the key to success in our world. I would much rather have someone who’s passionate and willing to put in some work to learn how things work and how to do things better than the average day to day code monkey on my team rather than a good code monkey. The second can implement things that I ask for, but the first can invent new implementations and design reusable code that is worth 3x the code monkey.

Advertisements

3D Printing and Electronics

March 10, 2010

I was recently approached by a friend of mine to join forces and create a DIY 3D printer. For those who don’t know, a 3D printer is a machine that can fabricate 3D objects that are rendered in a computer using a medium such as plastic, rubber, or sugar. Much of the design is similar to a regular desktop printer, except that instead of using ink it uses a building material, and instead of just printing in 2 directions, it has a moving platform that lowers to allow for the 3rd dimension. It really just prints the material in several 2D layers that build up to slowly create a physical object. Useful in prototyping and art.

My main desire for having a 3D printer is to build housing and components for an arduino. It would be much easier to custom create components from a 3D model for me than to hand make them out of wood or metal, especially since I lack in a decent work shop with power tools. Commercial 3D printers run from $15k up, but DIY kits can be had for under a grand. I’m not sure when my resources will allow me that indulgence, but it’s something to look forward to in the future.

However, my recentĀ fascinationĀ in the Arduino, physical computing, and robotics in general have made me wonder if I shouldn’t have also gotten a degree in Electrical Engineering. The college I graduated from did not offer that degree, however the field has begun to interest me increasingly so. I might try to look up some electronics courses at a local community college to expand my horizons.

In the meantime, one of the best ways of learning is not through an institution but through research and experimentation. For experimentation I have to wait for my arduino to arrive (it should be here on friday), but as for research, there are more possibilities in that area. I’m looking at some books on the subject, but I’m not quite sure where is the best place to start. I could focus on some of the physics and basic text books on the subject, or focus more on the experimentation and practical usages. If anyone out there has a good learning road map to a non-colligate learning curriculum on hobbyest electrical engineering, let me know. šŸ™‚

In a slightly different ramble, I’m discovering that my leanings seem to be towards the lower level and possibly abstract areas of programming and engineering. I’ve been focusing my code on creating libraries rather than single use programs. Code reuse has always been an interesting topic in computer science I feel. It’s greatly expounded upon as one of theĀ benefitsĀ of object oriented and modular code, the ability for reuse. However I’ve noticed that many developers, and entire teams of developers, rarely write any code that is reused in another project. They will use code from existing libraries such as the Java Standard Library, but will not often create them. However, I feel drawn to making base items that can be reused in multiple projects and by other people.

I think this is why electronic engineering fascinates me so much right now. It’s one of those areas where lower level library code is very much in need. If I can design and create a device that can interface with a microcontroller to perform some interesting action, I would then need to write a driver or library to make that interaction more abstract and easier for a basic user. I haven’t done much C/C++/Assembly programming so I’ve never written a driver, and that’s where my knowledge of theory and experience deviate.

Gaining some practical experience for basic theory is that area of excitement that I feel I can achieve by wiring up components to a microcontroller and building devices that have not yet been built. An exciting prospect that, in the end, I feel will help to improve myself as a developer.

Go/Chess Timer with Camera

March 5, 2010

So as I mentioned previously, I’ve been interested in building things recently. I haven’t yet purchased an Arduino yet (I’m waiting to find the right package and for some spare money), but I still think about projects that I want to do. I’ve glanced at several things that other people have done and while making my own skill crane might be pretty cool, I came up with another idea that’s been floating through my head for a few days now.

I’m a big Go fan, so for me making something related to Go would be interesting. There are lots of programs for playing games on the internet which have the unique advantage of recording the games that you play so you can exactly review them later. For physical games, you need to create a kifu to record the game, which requires that you write down your move after you make it. Writing the move down however can be distracting from thinking about the game. In major games, professionals will have a recorder who sits and records all of the moves for them (they also keep track of time), but that’s not very feasible for the majority of players.

So the idea is to make a device that automatically creates kifu for physical board games. I think there is a fairly obvious path for doing this as well. In a tournament style game of Go, players would use a Go/Chess timer for keeping track of how much time each player has. The devices are generally a box that sits on the side of the board with two largish buttons on top and two clocksĀ underneath. The clocks show the time for each player. When it’s your turn, your clock is counting down the time. When you finish your turn, your clock stops and your opponents clock starts counting down. There’s a few moreĀ advancementsĀ that can happen in these clocks like dealing with overtime and such, but that’s the basic principle.

Creating the clock with an Arduino shouldn’t be too hard. Two buttons (plus maybe a few more for configuration), two LCD screens, and maybe something to make noise when you run out of time should be fairly easy to wire up and program for a basic timer. What I’d like to do though is also attach either a web camera connected to a computer (laptop) or a digital camera that has a remote shutter control. The idea is that when you press the button to signify that your turn is over, the web or digital camera takes a picture of the board. You can use these pictures later to manually recreate the game in like an SGF file, or if I’m feeling really ambitious utilize some digital photo analysis and recognize where the pieces are played and automatically create SGF files. This way you can review even your physical game after having played it.

The PS3 eye Toy camera is my current target camera platform. There are USB drivers that make it run on windows (and I can look for Linux drivers) so I can pull data off of it. Since I acquired my camera with the Eye of Judgement game, I already have a neat stand that is designed to look down on a surface. When a button is pressed, the Arduino can send a signal over the serial cable to the laptop (or other computer) to signify that an image should be taken. If I later use a digital camera with a remote shutter control, then the whole process wouldn’t need a separate computer at all.

I realize that the same thing can be done just using software on a general PC and designating two keys for the timer, but I think having a dedicated device with better buttons that feels more like a game timer would be a more enjoyable experience. Also the ability to add blinking LEDs and/or sound when your time is running out would add to the overall feel.

If I ever do make it, I’ll be sure to post some info about the end result and some pictures. I’m going to go back to pondering my future building plans.

Building Things

March 1, 2010

Most of my posts on here have been about software development and work related issues and observances. I’m going to deviate slightly into the realm of hobby, which I think is important for people of any career in order to keep the personal passion alive and to keep your brain active without burning out.

Recently I’ve been reading a lot of Make Magazine which is primarily about building things of all sorts, though it does lean a bit towards electronics. Building technology is one of those basic features of humanity that separates us from other species. When I was younger I used to visit a friend’s house who’s father had an extremely well equipped workshop that we would use to make random things. For the longest time I stored all of my blank CDR’s on a wooden spindle that we created in that shop. Somewhere along the way with college and a career, building things fell to the wayside. Something that was so interesting and involved when I was a kid I no longer thought about or had time for. It is an unfortunate state to have gotten to, but luckily I’ve been able to rediscover the fun and excitement of making things from raw materials.

My first project was to build a small scale version of a trebuchet. My version is not even close to historically accurate, was created by lashing together pieces of wood with string, isn’t extremely sturdy, and the hook on the throwing arm is a bent nail taped with electrical tape. However, it works. It can toss a small ball around 50-60′ using a sack of change as a counterweight. Just by making the proof of concept small scale rickety version, I have built in myself ambition for creating a proper model.

I think that as we get older, for those of us who don’t stay in a making field or practice, we forget that we have the ability to create things ourselves. You do not have to be a master carpenter to build a table. You can build a trebuchet using hand tools and scraps of wood without any significant training. Making things, especially if they’re fun or useful (or both!), can be a very rewarding experience that I think many people forget that they have the ability to do, even in some spare time.

One of my original ambitions upon moving to California was to utilize the local Fry’s and build myself a robot. I’m not really sure what this robot will do, or its exact purpose. It probably won’t even look like any normal robot, but I wanted to create one. It’s been almost 2 years and I haven’t started even thinking about how I would create a robot. The dream just never seemed feasible to me with my limited knowledge. I’m not an electrical engineer, I’m a computer scientist. I can program a robot that’s already built, but making one is something outside of my expertise. Luckily today with the abundance of resources on the internet along with the open source movement, Robotics and creating electronics is not out of the realm of a passionate hobbyest who has no formal training.

My next goal along the path of building things will take me to the Arduino which is an open source microcontroller. There is a kit available that will get me started on the path of physical computing with the ability to control LEDs, servos, gears, read various sensors, and make noises. The eventual robot army is the natural conclusion. Everyone needs a hobby, even if it’s world domination. It keeps the mind busy.