Thursday, June 21, 2007
Soldering for dummies
Great article over on MAKE about soldering. If you plan on doing any soldering soon you should check this out!
Sunday, June 17, 2007
Get What You Pay For
I am a guy who loves a good deal. Often I buy something merely because of pricing. This is not limited to new items, I love shopping for used stuff. Garage sales, eBay, Craigslist you name it. Don't take this as a statement indicating that I am a cheap skate! Just because I pride myself on finding the best Mexican taco stand, where you can fill up for under 10 bucks, doesn't mean I will not plunk down $30-$40 for a really good dinner. I understand that often you get what you pay for.
Now here is an example. When Dyson vacuums first came onto the seen a few years ago I was astonished. How could one justify paying over $400 dollars for a vacuum. Geez, I mean the one I had through college was maybe sixty dollars. This feeling was strengthened when I actually got to check out one firsthand at a shop. I felt it's construction was a little cheap, being made out of so much plastic (and those colors WTF?). I would say these feelings where strong, but guess what? I was all wrong.
My wife and I received a Dyson as a wedding gift. At first I just figured "Hey it must be better than my old college vac". When I finally broke open the packaging I was dumbstruck. It came with so many extras it was hard to believe. There where a lot of special attachments in the box. I'm not talking about just simple brush tools, crevice tools and whatnot. It came with 3 varieties of the aforementioned. It also came with 3 other, very fancy attachments for other things. What, I do not know yet, but they look pretty useful. It also came with a full on carpet care kit, included spot remover and carpet freshener.
So how does the thing work? Well it gets the job done much, much better than my old college vacuum did. I don't think I could ever go back now. It picks up everything, doesn't (seem) to lose suction, and moves around with a precision that my old vacuum just never had. It also is pretty sturdy in light of it's all plastic construction. I think I was wrong in holding it's plastic construction against it. The plastics used do seem pretty durable, save for the piece that at the bottom front of the machine. This piece has been rammed into a few walls, and has developed stretch marks that plastics often get when bent and such.
The engineering of this vacuum is also a point of interest to me. I find more and more cool features of this machine as I fiddle around with it. The material that is used in the hose of the vacuum is amazing. It stretches and shrinks back very naturally. No other vacuum I've seen uses this sort of material. The emptying of the debris sucked up by the vacuum is simple, and is much cleaner than any vacuum I have used. Every little part of the machine can be easily removed for cleaning, which makes me think the engineers put a lot of thought and time into it's design.
Well I've spent way to much time blabbing about a freaking household appliance. Like the title says you do get what you pay for. I would also like to say that sometimes maybe innovations go without being noticed because of held beliefs. If something costs an arm and a leg then maybe it deserves a closer look.
Now here is an example. When Dyson vacuums first came onto the seen a few years ago I was astonished. How could one justify paying over $400 dollars for a vacuum. Geez, I mean the one I had through college was maybe sixty dollars. This feeling was strengthened when I actually got to check out one firsthand at a shop. I felt it's construction was a little cheap, being made out of so much plastic (and those colors WTF?). I would say these feelings where strong, but guess what? I was all wrong.
My wife and I received a Dyson as a wedding gift. At first I just figured "Hey it must be better than my old college vac". When I finally broke open the packaging I was dumbstruck. It came with so many extras it was hard to believe. There where a lot of special attachments in the box. I'm not talking about just simple brush tools, crevice tools and whatnot. It came with 3 varieties of the aforementioned. It also came with 3 other, very fancy attachments for other things. What, I do not know yet, but they look pretty useful. It also came with a full on carpet care kit, included spot remover and carpet freshener.
So how does the thing work? Well it gets the job done much, much better than my old college vacuum did. I don't think I could ever go back now. It picks up everything, doesn't (seem) to lose suction, and moves around with a precision that my old vacuum just never had. It also is pretty sturdy in light of it's all plastic construction. I think I was wrong in holding it's plastic construction against it. The plastics used do seem pretty durable, save for the piece that at the bottom front of the machine. This piece has been rammed into a few walls, and has developed stretch marks that plastics often get when bent and such.
The engineering of this vacuum is also a point of interest to me. I find more and more cool features of this machine as I fiddle around with it. The material that is used in the hose of the vacuum is amazing. It stretches and shrinks back very naturally. No other vacuum I've seen uses this sort of material. The emptying of the debris sucked up by the vacuum is simple, and is much cleaner than any vacuum I have used. Every little part of the machine can be easily removed for cleaning, which makes me think the engineers put a lot of thought and time into it's design.
Well I've spent way to much time blabbing about a freaking household appliance. Like the title says you do get what you pay for. I would also like to say that sometimes maybe innovations go without being noticed because of held beliefs. If something costs an arm and a leg then maybe it deserves a closer look.
Whats going on?
So I was adding things that are tech related in this blog, such as working with Maven. Maven is a sweet build system for Java projects. I say build system lightly, as it does so many things. I have decided that my large cache of knowledge would be better presented in it's own blog, solely dedicated to Maven. So here it is, mavenize.blogspot.com! If you are trying to become a user of Maven this is a great place to get the many concepts down. It can be hard to connect the dots as a new user of Maven. Have fun!
Sunday, June 10, 2007
Testing your code
Testing is very important. What constitutes testing? Well that depends. If your application is mostly self contained, meaning it takes some command line args then spits out some data, then unit testing probably would be all you need. Other times your application must interact with one or more systems, so it would be good to test that all systems integrate nicely.
In this post I'm going to give my opinion on testing, and the two larger types I use and how and when to apply them.
Unit Testing
What do I mean by unit testing? I mean the following:
1. Your tests all run very fast, and the whole suite of tests runs in or around 5-10 seconds.
2. Every (yes every) time you compile the unit test suite is run to find errors in your code. Now you see why they must run fast.
To have fast running unit tests it is often very important to use interfaces between application objects. This will allow you to create mock versions of objects for testing.
An example: you have a remote HTTP interface with an implementation that allows HTTP calls to a network server. Now say you want to test an object that uses this remote HTTP interface. If you use the real implementation of the HTTP interface, the one you create for use in your application, you will encounter some problems. At some point you will compile, and your unit tests will fail because the HTTP object cannot reach the HTTP server, or maybe the server is on the fritz and returns the wrong data. This remote HTTP call could also be slow, causing your tests to break the 5-10 second 'rule'.
What is my solution? Create mock objects that implement an interface but don't do much. Some methods return nothing, so you may just create an empty method. Others might return an object, so simply create that objects configure it and return it. If you create a mock version of the HTTP interface you can control exactly what happens when it's methods are run.
Creating the mock objects allows consistency in your tests. Unit tests are all about consistency. If nothing else your unit tests should always perform exactly the same, with the only variable(s) being the object(s) being tested. What this means is that if you are having tests "integrate" with other systems it is no longer a unit test... Which leads me to the next part of this post.
Integration Testing
Integration testing is just as important as unit testing. If you are building an application that must integrate with another system you may want to write tests that test your application against the system to integrate with. These tests can let you gain knowledge such as: where things are slow between the two systems, test what happens in various scenarios i.e. testing for error handling, make sure that the system you integrate with can handle the load you put on it, or any other type of integration. Integration tests are more important to run a few times a day while you are actively working on a project. They often to do not run very fast, and could take many minutes or even hours :(
In this post I'm going to give my opinion on testing, and the two larger types I use and how and when to apply them.
Unit Testing
What do I mean by unit testing? I mean the following:
1. Your tests all run very fast, and the whole suite of tests runs in or around 5-10 seconds.
2. Every (yes every) time you compile the unit test suite is run to find errors in your code. Now you see why they must run fast.
To have fast running unit tests it is often very important to use interfaces between application objects. This will allow you to create mock versions of objects for testing.
An example: you have a remote HTTP interface with an implementation that allows HTTP calls to a network server. Now say you want to test an object that uses this remote HTTP interface. If you use the real implementation of the HTTP interface, the one you create for use in your application, you will encounter some problems. At some point you will compile, and your unit tests will fail because the HTTP object cannot reach the HTTP server, or maybe the server is on the fritz and returns the wrong data. This remote HTTP call could also be slow, causing your tests to break the 5-10 second 'rule'.
What is my solution? Create mock objects that implement an interface but don't do much. Some methods return nothing, so you may just create an empty method. Others might return an object, so simply create that objects configure it and return it. If you create a mock version of the HTTP interface you can control exactly what happens when it's methods are run.
Creating the mock objects allows consistency in your tests. Unit tests are all about consistency. If nothing else your unit tests should always perform exactly the same, with the only variable(s) being the object(s) being tested. What this means is that if you are having tests "integrate" with other systems it is no longer a unit test... Which leads me to the next part of this post.
Integration Testing
Integration testing is just as important as unit testing. If you are building an application that must integrate with another system you may want to write tests that test your application against the system to integrate with. These tests can let you gain knowledge such as: where things are slow between the two systems, test what happens in various scenarios i.e. testing for error handling, make sure that the system you integrate with can handle the load you put on it, or any other type of integration. Integration tests are more important to run a few times a day while you are actively working on a project. They often to do not run very fast, and could take many minutes or even hours :(
Subscribe to:
Posts (Atom)
