Programming

Jul

2014

Knowing When You’ve Wrote Crappy Code

Note: This article was kicked off by one I read over at LosTechies.

We write lots of code, statistically speaking some of it is what we’d deem as “crappy.” If you’re doing things right and progressing in your career and your understanding; your definition of “crappy code” should change over time. This is very important concept for a good Software Engineer, its one of the ways we get better. We recognize our past coding mistakes and work to better them.

Dangers of Crappy Code:

It could hide technical debt. “I don’t really know how or why this works, but here it is. Done.”
You’ve not taken the time to make what works, right. This potentially leads to bloated code, duplication, and an overall poor product quality.
Is it robust?
It is, potentially, not very reusable.
Can I hand this code off to someone else and they understand it?

Preventing Crappy Code:

The prospect of writing crappy code should not prevent you from getting a project working. However, it is very important to make it as right possible before committing the code changes to the repository.

Write self-documenting code. Some developers may scoff at this statement, but self documenting code is very possible in just about any language. Remember comments are your failure to communicate.
Remember to refactor, refactor, and refactor.
Ask for the opinion of a peer. This should be someone you consider qualified enough to give an opinion.
Use “TODO” comments so your thought process is not lost and it will serve as a reminder that you must still make something right. This doesn’t prevent crappy code from making it into a project but it documents its existence.

What To Do When You Find Crappy Code:

For the sake of this topic, lets assume you run across some crappy code 2 years into maintenance of a software product.

Identify why it is “crappy.”
Does it work or has it unknowingly introduced bugs into the system?
Perhaps leave a NOTE comment in the code, especially if it can add insight into the function of the crappy code.
Only change the code if it is within the scope of your current task. Remember that it has worked for 2 years and changing it now could potentially introduce error. If you do end up changing the code, attempt to make it right before you finish. Also make sure to update your unit tests.

Are you Ready? A Simple Test

Review a code base that you wrote 2 years ago. Did you find “crappy code?” The answer should almost certainly be a “Yes.”

Jul

2014

Isolate, Understand, Implement

Isolate, understand, implement: three very important things to remember when adding, modifying or replacing features on a project. The first step is to isolate the feature. Hopefully, your project is designed in such a way that once the code is isolated it is in a single place. The next step is understand. Meaning understand what the code currently does. Run the unit tests. Make sure you know without a doubt why the code works and what the code does. Also understand any effects that your changes might have. And finally, implement the new code or changes. During this phase you’ll modify the unit test set as appropriate, make the necessary changes to the code base, and ensure that the application is stable before pushing it back to your repository.

Apr

2014

First Impressions of Rust

Today I finished my first program written in Rust 0.10. As with my article on Dart earlier this weekend I’m going to rely on Wikipedia for short intro for what Rust is.

The goal of Rust is to be a good language for the creation of large client and server programs that run over the Internet.^[13] This has led to a feature set with an emphasis on safety, control of memory layout and concurrency. Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.^[14]
–Wikipedia

My first Rust program followed the same pattern that some of my other coding exercises have followed, that is implement an N-Queens puzzle solver. While not terribly complicated, the puzzle does force an introduction to several important aspects of the language. Since this was my first take on Rust, I am sure that my implementation isn’t great.

I found Rust to be an interesting language. One of the more interesting opinions I developed about it was that it really prevents developers from doing something stupid. That’s probably why it gets high marks for safe, concurrent code. If I were to compare Rust to any other languages, I would say that it is syntactically similar to Scala and C++. The strictness of the compiler does make learning the language a little more tedious than some other languages, but nothing that can’t be overcome. I am probably a little biased on that point too since I’ve been writing a lot of Python lately.

On performance, I did noticed that it was about 60% faster than a architecturally similar python n-queens script I wrote. I guess that’s not entirely unexpected from a compiled language. I really want to figure out Rust’s threading capabilities. That should greatly improve performance of the puzzle even more since it parallelizes well.

Rust has some serious potential and I predict as the language progresses, we will see more apps being written in it and more libraries available for it. I for one will be continuing to tinker with finer details now that I have this program done.

Links:

Rust

Apr

2014

First Impressions of Dart

Today I finished my first Dart tutorial. For those that don’t know what Dart is, Wikipedia has a nice synopsis that I’ve included here.

Dart is an open-source Web programming language developed by Google. It was unveiled at the GOTO conference in Aarhus, October 10–12, 2011.^[4] The goal of Dart is “ultimately to replace JavaScript as the lingua franca of web development on the open web platform”,^[5] but Dart currently relies exclusively on its cross-compilation to JavaScript feature in order to run in mainstream browsers. Dart is intended to address issues with JavaScript that Google engineers felt could not be solved by evolving the language, while offering better performance.^[5] Google works on Dart to help it build more complex, full-featured client-side Web applications.^[6]

Dart is a class-based, single inheritance, object-oriented language with C-style syntax. It supports interfaces, abstract classes, reified generics, and optional typing. Static type annotations do not affect the runtime semantics of the code. Instead, the type annotations can provide documentation for tools like static checkers and dynamic run time checks.

–Wikipedia

While the tutorial was simple and designd to be completed in about an hour, I found it a worthwhile and informative endeavor. It was just enough to give an introduction to the language and syntax. As the above snippet from Wikipedia states, Dart cross-compiles into JavaScript and should be familiar to people who know another C-style language.

I have a high degree of experience with object-oriented design, C++, and JavaScript and Dart has left me with a good first impression. I believe an important aspect of Dart is that it could be used to bridge the gap between C-style languages and JavaScript for programmers who do not have a lot of JavaScript experience. I do not believe that Dart will ultimately replace JavaScript, as Google hopes. JavaScript, while it has shortcomings, is ultimately very powerful and flexible. Dart’s ultimate utility will be something akin to CoffeeScript that is making it easier and less tedious to write JavaScript. In the coming weeks I may delve further into Dart, though up next I will probably do a tutorial or two on Rust.

Links: Dart 1-hour tutorial

Dec

2013

My First Raspberry Pi Project

View of the whole setup

Almost every year, I try to select a fun project to do while off for Christmas. This year the project I selected was based on Raspberry Pi. Specifically I decided to build a device that would, when motion is detected, find the range to the motion using an ultrasonic rangefinder, take a picture using the camera module, and finally email me the results.

After just a few hours of work, I had separate proofs of concept working for each sensor written in Python. A short time after, I started combining all the proofs of concept into a consolidated script which I got working. Right now I am perfecting the classes for interfacing with the range finder and the motion detector and I am currently using picamera 0.8 for interfacing with the camera module. I’ve included a link to the git repository I’m using for source control below.

Equipment:

Raspberry Pi Model B
Raspberry Pi 5MP Camera Board Module
HC-SR501 Human Sensor Module Pyroelectric Infrared
SainSmart HC-SR04 Ranging Detector Mod Distance Sensor
5 180 ohm resistors
Breadboard and miscellaneous connectors

Source Code: https://github.com/chaddotson/PiPy

: Raspberry Pi with breadboard

: Raspberry Pi with breadboard

: Side view

: Front closeup of ultrasonic sensor

: View of the whole setup

: Alternet side with Raspberry Pi breadboard and motion sensor

Aug

2012

Presentation Is Everything

PRESENTATION IS EVERYTHING

There is something that learned over the past couple of years, presentation is everything. It is quite possibly the most important element in all we do.

Presentation from the aspect of leadership can mean the difference between shared vision and unengaged worker bee. Presentation from the aspect of a product ( in my case software product) means the difference between phenomenal success and utter failure of a product.

In short, no matter how good or revolutionary your product is, if it looks bad, it will fail. To have a physical product example, look no further than the current mobile phone market. Look at two products: one you like and one you hate. What are the specs of each one? Are they comparable or does one have an advantage over the other. Now, for arguments sake, lets say the more “cool” one has a better physical appearance and a more flashy user interface but the one that is less “cool” looking and has a plain user interface has better specs and capabilities, which one would you buy? I’m betting (and society proves) that the “cooler” one with the more flashy interface wins out more than the other device. I’ve got no facts in front of me to prove this directly, only experience and my own beliefs.

FIXING OUR SOFTWARE

So how do we fix our software? Well here are some design concepts to keep in mind.

The API and/or the user interface for software must be intuitive.
The software features must be discoverable. This means that users can learn to use the software by using the software. There is not a need for an involved manual to pick up the software and begin using it.
The software must be easy to use. This is an ambiguous and loaded statement I know, but never-the-less it must be true. Just think about the software you are writing from the user’s perspective.

These are some of my most important concerns for a software product because if a user cannot easily pick up your software and start using it immediately, then you will have problems with adoption within your targeted user base. As with the mobile phone example above; if you have two pieces of software equivalent in terms of capabilities and specs, but one is presented a lot better and is more user friendly, which would you choose?

Going Forward

What we’ve learned here can be summed up in the two following statements. Software must be intuitive, discoverable, and easy to use. Also, presentation and appearance are quite possibly the most important part of software.

Dec

2011

Programming Progress

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” – Bill Gates

I have that quote on my instant messenger. I found out Friday that someone had saw and used it. Its good that someone found it useful. It’s a very valid point to make that lines of code isn’t an accurate measure of programming progress nor complexity. As a place to start, people looking for better methods might like Feature-driven development with a meaningful estimating system like PERT, CPM, or other system.

Apr

2009

MonoDevelop 2.0

I heard about this today. I’m really impressed that they’ve brought it this far. I’m going to have it install it on one of my virtualized linux installs and try it out.

The MonoDevelop team is proud to announce the release of MonoDevelop 2.0.

MonoDevelop is a GNOME IDE primarily designed for C# and other .NET languages. MonoDevelop enables developers to quickly write desktop and ASP.NET Web applications on Linux. MonoDevelop makes it easy for developers to port .NET applications created with Visual Studio to Linux and to maintain a single code base for all platforms.

via MonoDevelop 2.0 Released – MonoDevelop.

Dangers of Crappy Code:

Preventing Crappy Code:

What To Do When You Find Crappy Code:

Are you Ready? A Simple Test

Recent Posts