Review: Force Trainer

I know, I know, I'm a bit late to do a review of the Force Trainer since it came out around late 2009 (Gizmodo review).  However, only now did the price come down enough for me to try it out as I put it into the category: "interesting but is it really useful?"

If you're even later to the party than I am, the Force Trainer is one of the first generation of consumer-grade Mind Machine Interface, and like many other technologies is somewhat expensive (Amazon price is at ~35 USD instead of the original 129), somewhat difficult to set up (initial calibration is frusterating) and somewhat unreliable (or maybe I'm just not the Jedi I used to be).  In case you missed the subtext, yes, IT READS YOUR MIND (or more correctly reads your brain waves).

I've had it (so far) for about two days now and find it a much better concentration aid so far than guided meditation CDs or simple silence (without feedback, how will I know if I'm concentrating correctly?)

All in all, a decent buy at $35, just to have something that reads your mind (this technology will only get better and more prevalent as time goes on, so you may as well get used to it now).

Also, if electronics is your thing, there's a hack to link the input into a serial port.  You could technically adjust your dimmer lights with your thoughts via consumer technology.


I'm really starting to dig the 21st century!

Testing, Testing and Testing

You hear it in real estate: location, location, location.  You hear it (not as much) in software: test, test, test.  However, in software the tests are all different.

A recent project that I'm on involves a venerable app with as much technical debt as the US Government... and we need to add a feature.  Solution: tests, tests and tests.  More specifically if you don't know the different kinds of tests:

• Good old Unit Testing, easy to implement and understand, unless...
• You are getting used to mock objects (e.g. JMock or Mockito)
• You are testing database functionality and are new to DBUnit
• You are testing a web app or Servlet and are new to HttpUnit
• You're confusing unit testing (ONE module) with integration testing (multiple modules)
• Example: testing your Data Access Layer (DAL) with a dummy DB, like a local HSQL
• Integration Testing, usually implemented with a framework that ends in "Unit" so it's easily confused with unit testing.  Integration testing integrates two or more components, everything from two classes to the entire app with a dummy DB.  Due to this you can have multiple levels of integration tests, each testing more modules together.  Examples include:
• Testing a servlet in HttpUnit's ServletUnit instead of your actual web container
• Testing your DAL with an "actual" database (whatever actual means to your project)
• Testing a fully created Spring bean with the real beans injected instead of mocks
• System Testing, this is tests of the entire system
• QA usually conducts manual system tests
• There can be automated ones as well with things like Selenium
• As an example for a web app, using a supported browser to use the app in the final web container and using the real database.

There is of course, much more to software testing, but these three are usually a good start.  Heck, in many organizations / projects even using unit testing is new to people.  Like Regan said: trust, but verify.

PS: There's a good post at EvilTester with a more philosophical approach to testing.

College vs. Industry

Over at InfoQ they have a stimulating article "Crossing the Software Education Chasm" reviewing another ACM article of the same name.  A good article about how to better prepare college students for the "real world".  I've had some thoughts of my own from my own experience at San Jose State University (SJSU) in the Computer Science department.

Image by Clay Bennett

I'm not sure about education in general, but at SJSU we were consistently put into teams and consistently not even TOLD about code versioning software.  I was unfamiliar with even the CONCEPT yet alone the practice of even CVS until my Senior year.  Furthermore, testing was not emphasized at all (a point made in the ACM article) but at least writing was.  (Yes, you can blame or thank SJSU for this blog, indirectly).  The most important lession was not a formal class at all.

I used to think that college was the hugest, worst bureaucracy I would ever encounter.

Then I got a real job.

DBUnit in Practice

For those of you unfamiliar with DBUnit, it works with JUnit to put a database into a known state between unit tests (e.g. you can wipe out the DB and start from a blank on each run if you want).

I've recently picked up how to use this technology in practice, and this article will help others ease the (somewhat steep) learning curve.

I found DBUnit to be a very collaborative technology, in the sense that it interacts with a lot of other technologies to do it's job.  First off, DBUnit does not PROVIDE the stub or mock database, you'll have to provide one yourself (Apache Derby and HyperSQL are swell for this).  Secondly you have to establish a connection to the DB yourself (using JDBC) and thirdly you'll need to create the tables for the DBUnit data yourself (e.g. via SQL CREATE TABLE statements).  Lastly you'll need to dependency inject (if you know Spring than this concept is nothing new) your JDBC connection object going to the test DB into whatever class you are going to test.  THEN you can run your DBUnit tests.

In conclusion, you need to use a lot of other technologies and paradigms in order to truly use DBUnit.  I hope that this overview and the links help.