Technology

Aug

2014

No Comments – A Failure Twice

Everyone that writes code has encountered or written their fair share of undocumented code.

A failure twice?

I was encouraged to write this article because of something I read about the pinball game that once was included with windows. According to the article on MSDN, the pinball game was removed due to a bug that should have been fixable. However, the overall qualify of the code made repair impossible and the game was removed from the distribution. Two major items can be taken from this:

Failure 1: The could should have been self-documenting / few comments required.
Failure 2: Code not easily understood should have been commented.

Properly commented code can be tricky!

In college they push you to comment your code while not stressing that over documentation is also bad. I remember writing programs that had comments on almost every line for assignments. In the end it doesn’t buy you anything, it just restates the obvious and clutters the solution. In the workplace, comments and whether or not the code needs them are hit and miss.

Some notes about comments:

Many comments are an acknowledgement of your failure to communicate. Write better self-documenting code.
Outdated or wrong comments are worse than no comments.
Consider refactoring code that’s not self-documenting. I find one of the biggest places this can be done is extracting methods from if statements.
Choose a good, descriptive names. I’m a little wordy in my names, but in the end most of my code can almost read like a sentence.

Remember

The code is your best documentation. Think about what you want to communicate with it and how to be as clear as possible.

Aug

2014

Node.js vs Python vs PyPy – A Simple Performance Comparison

IMPORTANT NOTE: The NodeJS algorithm had a slight discrepancy in it. See this article for a correction to the performance comparison section of this article.

The Algorithm

Yesterday, I decided to try translate my algorithm for calculating N-Queens to JavaScript. I’ve implemented the same single-thread, brute force, recursive algorithm in many different languages with the biggest difference being the syntax of the language. Once I completed the JavaScript Implementation, I ran the program with the latest version of Node.js.

The Findings

I knew Node was fast but it still surprised me. As you can see by the included charts, the performance difference between Node.js and out-of-the-box Python is pretty significant. Its not until the algorithms complexity and recursion depth hit certain limits that Node.js’s performance starts to falter.

Node.js and CPython – What’s The Difference?

You might ask what is behind this performance difference. The answer is actually pretty simple. It all boils down to how the code is being executed. Node.js uses the V8 JavaScript Engine (Wikipedia | Google) written by Google and a part of the Chrome Browser. V8 includes a just-in-time compiler that compiles the JavaScript to machine code before execution and then continuously optimizes the compiled code. Python is a bytecode interpreter; meaning that the default interpreter (CPython) doesn’t execute Python scripts directly. Instead, it first generates a intermediate file that will later be interpreted at runtime.

Ways To Get Better Performance

If you want to use Python, we can overcome the differences between Node.js and vanilla Python by using PyPy, an alternative implementation of Python that includes a just-in-time compiler. For the algorithm I wrote, you can see a pretty good performance boost over Node.js when using PyPy.

Special Notes

I’ve placed my source on GitHub at the following url: https://github.com/chaddotson/puzzles
This is just with one type of algorithm, the best solution might and probably does change depending on what type of application you are researching. For webserver performance, Node.js is slightly better than PyPy running Tornado.
This algorithm is a simple brute force algorithm, there are many faster and better ones out there.
At a board size of 15, Node.js could no longer run the algorithm due to its maximum recursion limit.

Edit – A Follow-Up

The original focus of this article was shear performance, but I’ve received a question regarding the memory footprint of the 3 methods. I think that is a very good and valid question. So, I reran the tests to capture the peak memory utilization by each. For this test I used “/usr/bin/time -l” to capture the maximum resident set size. While this isn’t exactly the peak amount of memory utilized by the algorithm, it is sufficiently close to report on.

New Findings

Upon rerunning the tests for capturing memory utilization, I found that for the most part memory utilization contrasts performance. A higher memory utilization isn’t really unexpected, if you think about it. Essentially, the jit is sacrificing memory for performance. In most cases, this isn’t really that bad. Using a jit is just a cheap way of boosting performance of code written in an interpreted language. The boost in performance, speed of which it was written and the maintainability of it outweigh memory utilization concerns in many cases.

The Oddity

As you can see, I’ve included a chart covering all the solutions for boards 8×8 to 14×14. During most increments in board size, the memory utilization seems to increase exponentially; however, when we hit the 14×14 board size we see all the cases level off at relatively the same memory utilization of around 300 MB. At this time, I really don’t have a good answer for this. I could certainly speculate, but I’d rather not until I know more.

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

The Flood of Social Media Posts – Whats Wrong, How To Mitigate It, How To Fix It

What’s Wrong

Since its creation, social media has taken off at an exponential rate. Each day more and more people are creating accounts and contributing to the feed. Facebook is the service most readily adopted, mainly because of the people already on it. In the case of Facebook, lets say that the typical user has 200-300 friends and lets say that just a quarter of those (50 of 200) are enthusiastic posters (2-3 posts/day). That equates to somewhere north of at least 100 posts per day then add to that the posts from your other friends. Lets make a guess of an overall total of 200 posts/day on just that one social media outlet. Facebook’s solution to the inundation of posts is the top posts vs recent posts feature.

Skip to the services that I think are the most susceptible to inundating users with content: Twitter and Pinterest. As a user of Twitter, it seems that I have trouble following over 40 people. Once upon a time I followed near 90 people and found that useful posts actually got buried in the noise. Pinterest on the other hand seems to violate all that is good with respect to UI design; it is way to busy and your eyes don’t follow any particular lines. Liberal use of pinterest’s follow feature can unintentionally muddy the content you see.

Tips On Dealing With It

I think the only way to fix usage of Twitter is to limit the number of people you follow. Pick high quality, low post rate users. This will improve the overall quality of content you get. For Pinterest, limit the number of users or boards you follow.

How To Fix It

How do you fix being inundated with content? Facebook is certainly trying to fix it via their “Top Posts” feature. The top posts feature attempts to make guesses about what you want to see based on your interests, what you’ve looked at in the past, and probably other metrics (and controversial stuff such as a recent study). Even though I don’t care for their current top posts feature I believe Facebook is on the right track. It all boils down to the ability to listen to everything but only pay attention to what your interested in, even when you may not 100% know yourself.

I think the ultimate “Top Posts” algorithm would take into account the following:

What you’ve looked at in the past. (Given)
Users would be given preferred tags based on what they view.
It would tag each post and each would receive an initial ranking based on the types of posts the user normally make.
The initial ranking score given to a user’s posts is a function of how well their posts have done in the past.
Each post’s rank is updated in each of its tags as people view them based on their rank in the tag category.

Up Next: I may decide to make a post discussing a theory of how people leave one service and adopt another.

Jul

2014

Apple’s Magic Mouse – A Software Engineer’s Perspective

Over the past month I’ve been trying to make the transition from my old windows environment to an OSX environment. Part of the transition involved buying a Magic Mouse. Apple’s Magic Mouse is definitely a very interesting device. It is a very accurate mouse with the added capability of a gesture enabled touchpad. While I like it, the negatives are over powering the positives… at least for me.

It seems too small, at least for my hand.
While you can scroll by using the integrated trackpad, there is no out of the box concept of a middle click. I don’t use that when coding, but I sure use it alot when browsing the web. I was able to get it back by installing the 3rd party tool “BetterTouchTool.”
The integrated trackpad is over half of the device. I find that I mistakenly activate it alot.
The single action of the device whether right or left clicking is irritating. Maybe its just the size of the device that makes this seem irritating.

While I think it maybe great for some people, I’m not sure they are great for everyone. While I am not going to get rid of mine, I am starting to use my old Microsoft Mouse more often again. About the only thing I miss about the Magic Mouse is the trackpad scrolling.

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.

Jun

2014