Category Archives: Blog Post

JUnit and PyUnit, @Ignore and @expectedFailure

Posted by Tom Schultz on May 3, 2011 8 comments
java-logo2-150x150

What’s @ignore and @expectedFailure?

I think that JUnit’s description says it best, “Sometimes you want to temporarily disable a test.”

Here’s the whole thing for JUnit…

“Sometimes you want to temporarily disable a test. Methods annotated with Test that are also annotated with @Ignore will not be executed as tests. Native JUnit 4 test runners should report the number of ignored tests along with the number of tests that ran and the number of tests that failed.” - http://api.dpml.net/junit/4.2/org/junit/Ignore.html

And for Python these two links seem to begin to explain some of the thought behind the decisions to add this feature…

http://bugs.python.org/issue1399935
 http://mail.python.org/pipermail/python-dev/2006-January/059503.html

My concern with this feature

I think this is one of those features that kind of got added on a slow day rather than really thinking about the impact that it has on the code and that reflection on the language. It makes sense right? You run your tests, you see some tests failing and you make a decision in your mind that you expected those to fail for a little while during development so you want them to stop sounding the alarm and blowing whistles!

This seems innocent enough at first but what are the long term implications?
Well firstly I think that you should really ask the question “Why do I have failing tests that I want to suppress??”  I can’t think of any good reason personally.  If you’re implementing something so huge that you’ve written tests that you can’t make pass before you test it on an integration server then you’ve probably bitten off more than you can chew and your feature will change/get removed before you can make the tests pass anyway.

Secondly, writing tests should be as simple as possible. Adding something extra to a testing framework, which also defeats the purpose of the framework, seems like we’re making things way more complicated than they have to be. A unittesting framework is supposed to tell you when things pass or fail. If you don’t want the tests to show up as failures and they do not indicate that something is broken then remove them.

Thirdly, maintenance…who’s going to clean this all up? You’ll see some places that warn the users of these features about this. Make sure that you remove this before you finally commit or merge to trunk! Why not just not worry about it by not using it?

If anyone has a really great use case for this please share in the comments! I may have my opinions/rants but I’m mutable :)

Update:

Twitter response about @ignore and @expectedFailure

This is an interesting perspective on the use of @expectedFailure. Basically it can allow you to manage bugs in third-party libraries. For instance if you find a new bug in some library that your’re using, you can write a test for that bug and when it gets fixed that will turn into an “unexpected success” and you can then clean up that test.

For me I still wonder how often this is truly useful. I haven’t seen a lot of tests written for bugs in third-party software. Also, if you have to use that part of the third-party library that has the bug then you must depend on that bug being there or not so you should have tests covering the outcome of the third-party’s bug.
The tests that you have will be covering “your” use of the third-party software. Obviously if the third-party software has a severe bug in it then you may decide not to continue using it.

Thanks Andrzej Krzywda! Great article on your blog.

Podcast Episode #9 – The Giants are Evil

Posted by Tom Schultz on April 20, 2011 None comments

It’s been a long time since we made a podcast…and you can probably tell. We took extreme effort to keep the rants pointless and to have a good time so please enjoy our first podcast of 2011!

Topics!

  • Facebook being for dullards
  • Twitter is a conspiracy
  • Google is evil
The Giants are Evil [ 28:52 ] Play Now | Play in Popup | Download

What is LizaMoon?

Posted by Tom Schultz on April 2, 2011 None comments

So this is pretty big news eh!

LizaMoon is the domain that a newly discovered SQL injection vulnerability attempts to take viewers too.  From there it will attempt to load FAKE anti-virus software onto your computer.  It appears that this attack has affected nearly 1 million websites so far (http://www.google.com/search?q=%22src%3Dhttp:%2F%2F*%2Fur.php%22)

Websense.com has released excellent information and tracking of this SQL injection attack that appears to have start March 29th.

http://www.youtube.com/watch?v=wKI5dg1cs74

For more tracking of the injection attack visit WebSense.com’s community information at these urls…

http://community.websense.com/blogs/securitylabs/archive/2011/03/31/update-on-lizamoon-mass-injection.aspx

http://community.websense.com/blogs/securitylabs/archive/2011/03/29/lizamoon-mass-injection-28000-urls-including-itunes.aspx

http://community.websense.com/blogs/securitylabs/archive/2011/03/29/lizamoon-mass-injection-28000-urls-including-itunes.aspx

 

Stackoverflow.com has an example and log information as well as some tips for server admins to attempt to clean and prevent the issue from happening again.

http://stackoverflow.com/questions/3788080/attack-on-asp-site-that-uses-a-sql-server-database

 

Also for system administrators, OWASP – The Open Web Application Security Project has excellent resources on how to manage the infamous SQL Injection risk.

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

http://www.owasp.org/index.php/Guide_to_SQL_Injection

Sprint HTC EVO 4G Battery Life

Posted by Tom Schultz on April 1, 2011 None comments
HTC-EVO-GL

Problem:

Since Sprint released an update for my HTC EVO 4g (3.70.651.1) my battery life has decreased significantly. The phone wouldn’t last much longer than 5 hours.

The battery life drained much faster in areas where I had poor service. This is normal in most cases but after the update the battery drain was much worse.

Solution:

It appears that the in the update Sprint released for the HTC EVO 4g (3.70.651.1) increased some of the polling for the 3G data connection. So if I turn the wifi on and have it connect to access points instead of having it search for 3G then my battery lasts all day long and then some.

Tesla Motors vs Top Gear UK – Ah…Cute.

Posted by Tom Schultz on March 31, 2011 None comments

Tesla Motors used to have my affection and attention whenever they were in the news, but now they’ve decided to attack something else near and dear to me… Top Gear UK.

http://www.teslavstopgear.com

I’m sorry Tesla Motors, but you’re insane.

Jeremy Clarkson spent nearly the entire first half of their review praising the Tesla Roadster in the episode in question.

But as they do with all their reviews, they also pointed out some “consumer” issues with the vehicle they review. They do this with every single car they have on their show. And guess what! It’s entertaining!
Jeremy Clarkson, Richard Hammond and James May have dissed cars that cost several times as much as a Tesla Roadster.

Oh and so that we don’t forget how much we’re talking about here…The Tesla Roadster costs a staggering $101,500.
That’s including the $7500 government tax credit!

So I guess the ~2000 cars that Tesla has sold (That’s $203,000,000 btw) will all be returned due to this Top Gear turn down.

I guess what I’m trying to say is that if Tesla Motor’s sales are really being affected so much by a UK car show  then maybe they should listen up and fix the problems that were noted by the Top Gear crew.

League of Legends Character Data – an Idea

Posted by Steve Oxley on March 4, 2011 None comments

Gangplank - a champion in League of Legends

Gangplank - champion from League of Legends (he's a pirate! yarr!)


Today, on the way home from work, I had an idea. I’m posting it publicly so that I’ll feel more obligated to see it through.

Lately (read: the past year) I’ve been playing a lot (read: too much) of a little game that I like to call League of Legends (since that’s its name). It’s a really interesting game – it’s not ridiculously fast paced, but it’s very strategic. Before I explain my idea, I’ll explain the premise of the game. League of Legends is a tower defense game. Each game is played by two teams currently consisting of either three or five players each. The goal of each team is to destroy the other team’s nexus. In order to do this, a team must first destroy some of the opposing team’s towers (a.k.a. turrets – they do fight back) and at least one of the enemy’s inhibitors.

Each player plays a champion (there are currently over seventy to choose from!) which has unique statistics (for example, critical strike chance, attack damage, and armor) and abilities (for example, some champions have abilities which slow enemies, while others have abilities which cause them to take reduced damage for a certain amount time). Now, the really interesting part about this game is, in my opinion, the scaling aspect of it. At the beginning of each game, every player’s champion starts out at level one. Over the course of the game, each player’s champion will gain experience and gold from killing enemy champions, enemy minions and neutral monsters, destroying towers, and so on. The experience gained will cause the player’s champion to level up (to a maximum level of eighteen), granting access to new or upgraded abilities and increasing the champion’s statistics (such as armor or health). The gold gained will allow the player to purchase items for his champion which will either increase the champion’s statistics or provide some other benefit (or detriment to the other team). Games are often decided by who can “farm” the most gold and gain levels the quickest in order to overpower the other team (which, granted, always depends on a great number of other factors such as team composition and player skill). Nevertheless, it’s this scaling that is one of the main focuses of the game.

In fact, really good League of Legends players will spend a significant amount of time studying different item, mastery, and rune “builds” (masteries and runes perform functions similar to those of items but are not purchased with gold). It is this between-game study that my idea relates to.

I want to compare the properties of different champions. As I said earlier, each champion has different statistics which will affect what role they will take on a team. These statistics should be relatively easy to compile into a useful format for comparison – this is where I will start. Later on, it will probably be interesting to compile data about how different item builds, rune builds, abilities, etc. affect a champion’s performance, but those will be more complicated and will have to wait until later.

For those of you who read this blog for the coding-related content, fret not! There should be plenty of coding details in future posts in this series (ugh, i said “series,” I’ve got to follow through now).

Oh, and if you’re going to create an account for League of Legends (it’s free!), use my referral link (shameless, I know).

Keys to a stable application

Posted by Tom Schultz on March 1, 2011 1 comments
Checkmark

Unit Tests!

If you don’t know about unit testing and the power and flexibility that it gives you then you NEED to get on board!
When your project has over 50% test coverage you’ll start to experience a strange feeling of confidence in the code that you’re writing. This confidence you’re feeling will be the fact that you’ve seen your code perform it’s duties over and over again with success.

Each time you run the tests after you’ve added code, you know that everything still works and that gives you huge peace of mind.

Obviously there are some other things you can aim for to aid this.

Like…

  • If you find a bug…write a test that exercises it and fails…THEN fix the code and see the test pass!
  • Aim for 80% coverage or more on the entire application.
  • Setup hooks in your version control that runs the tests before it lets you check in your code.
  • Use fixtures! If you interact with data then use fixtures! Do not pull from a live database! If you pull from a database on a server you’re introducing configuration issues and tighter coupling.

Want to learn more?

Version Control

I didn’t put this first because I assume that people use version control on their projects. If not on a RAID server or in the cloud then at least a simple Mercurial repository on their local machine.
The ability to track versions of your software is essential in providing long term stability to your application. Interestingly enough I don’t think that tracking your files is what brings stability from version control. Typically when you choose some form of version control there are prescribed methods that are suggested for the developers to interact with this version control. For subversion there is the idea that you’re supposed to have a “trunk” and then branch and merge back down. These methods of separation in work bring more discipline to the development of your application.

Obviously don’t discount the idea of having version tracking on your source code! Version tracking has an immense value in the development of your application. Version control makes it possible to track bugs down to the very line! Version control allows you to branch your project and work on many features in parallel! Best of all version control opens the door to a world of many developers working on the application at one time!

Want to learn more?

Best Practices

What can I say, Duh right?

If you’re in school right now, tell your professor to start teaching some best practices in an area they’re familiar with. You will benefit from these your entire life.

Want to learn more?

Testing

Pretty simple, do it! Make SURE that you test your code before you commit it and send it off to your QA process. There are now quick little changes in which you don’t have to test the actual user interface or consumer of your code. Do this! It’s freaking annoying when you don’t!

Make sure that you have an isolated environment(integration server) to test your code on! This will make it easier and it’s also very important for the next step as well.

In Django you can even use the built in server to test your application. Snap(Haskell) also has it’s own server.

Want to learn more?

Release Planning

This is interesting because it never came up on my radar until we started doing it, and then I realized how important it really was. I mean it’s obvious right? Here make this thing and then release it! Ok, how?  It’s also helpful to practice on your integration server(mentioned above) before releasing to production. This might sound silly but practice does make perfect!

Secondly, or maybe firstly, release planning just helps everyone know what their job is on release day.

Want to learn more?

Issue Tracking

Ok, I’ll be honest, I don’t know if this goes at the top or the bottom.  You can have issue tracking setup as your developing but one thing I know for sure is that you need it once you’ve released the product! Oh, and it really helps to have it public as well! Products like GetSatisfaction.com will help you communicate with your customers! And who’s input should you care about the most? The people that use your product!

The trick with issue tracking is that you must respond to the issues! The quicker the better in most cases.

Want to learn more?

Summary

The steps I’ve outlined here are not from any one particular process. These are just things that I’ve seen through trial and error that have appeared to work in my environment. I feel like they are high-level things that can be acknowledged and done that will increase the stability and maintainability of a software product.

What do you think? Feel free to comment! We can help each learn!