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 :(
Saturday, May 19, 2007
Count to 10
Well I'm married, working at a new job, in a new state, new apartment, new dishes, new shoes, new haircut...
Life has been hectic in recent times for those around me and myself! I have been involved in all kinds of events lately, and I look forward to being a homebody for a day, maybe two. I just got back from the Maker Faire. Wholly fun time, attend if you can it will be going on tomorrow and also down in Texas (in a month?). They had a huge, human size Mouse Trap Rube Goldberg deal!!! If that does not get you there what will?
Interesting stuff going on at the jobby job
On the work side of things I have putting together some image manipulation code in the last week (my first back since the marriage/honeymoon). I am watermarking pngs, jpegs and pdfs. The pdfs are the hard ones. I am using this lib called iText. My hat is off to Bruno Lowagie and Paulo Soares, the men behind iText. If you need to generate pdfs in the Java language this will be the lib you use (I'm 95.7% sure).
Oh I also set up Continuum at work so that it sends email notifications when projects break, bam!
My boss has been playing with Derby. I have some experience with Derby, but mostly in using it for testing w/ Spring + Hibernate + Maven 2. We are using this XML database called Mark Logic. Pretty cool I haven't been let loose on it yet, being busy with many other things... So my boss he created some code which he embedded into Derby that allows him to get documents from the Mark Logic DB. He parses these documents and inserts data into relational db tables within Derby. That guy is a hacker pro! He is also creating an Atom server that can be embedded easily within Java code.
I love this because it will allow me to create integration tests for an Atom client I am developing (among other Atom based projects I am working on). These tests would not depend on network machines. To outline this; a test begins by starting the embedded server. The server can create a simple Atom workspace containing some feeds and entries in kind. Then I can have my client hit the server (in the test). The nice thing is that I can control the server 100%. Every time the test runs the server will be a fresh copy of the Atom workspace. This is very very useful.
My Javascript journey
I've been reading a bit. I read a bunch of David Flanagan's 5th edition of "Javascript: The Definitive Guide". The chapter on modules and namespaces was most interesting to me. I haven't used the technique he describes, using objects within Javascript to create a namespace. I see it as a must use technique for any collection of code that you would like to see reused. Unfortunately this technique was not employed in a pet project I have been working on. I will have to spend more time refactoring it so that different parts are packaged under namespaces. Oh well if I never get an actual product working I at least garnered some skills in the whole mess.
Becoming a better programmer
I'm on a kick to to enable myself to be a better Java programmer. To do this I will be looking at ways to extend my skills in general ways.
Life has been hectic in recent times for those around me and myself! I have been involved in all kinds of events lately, and I look forward to being a homebody for a day, maybe two. I just got back from the Maker Faire. Wholly fun time, attend if you can it will be going on tomorrow and also down in Texas (in a month?). They had a huge, human size Mouse Trap Rube Goldberg deal!!! If that does not get you there what will?
Interesting stuff going on at the jobby job
On the work side of things I have putting together some image manipulation code in the last week (my first back since the marriage/honeymoon). I am watermarking pngs, jpegs and pdfs. The pdfs are the hard ones. I am using this lib called iText. My hat is off to Bruno Lowagie and Paulo Soares, the men behind iText. If you need to generate pdfs in the Java language this will be the lib you use (I'm 95.7% sure).
Oh I also set up Continuum at work so that it sends email notifications when projects break, bam!
My boss has been playing with Derby. I have some experience with Derby, but mostly in using it for testing w/ Spring + Hibernate + Maven 2. We are using this XML database called Mark Logic. Pretty cool I haven't been let loose on it yet, being busy with many other things... So my boss he created some code which he embedded into Derby that allows him to get documents from the Mark Logic DB. He parses these documents and inserts data into relational db tables within Derby. That guy is a hacker pro! He is also creating an Atom server that can be embedded easily within Java code.
I love this because it will allow me to create integration tests for an Atom client I am developing (among other Atom based projects I am working on). These tests would not depend on network machines. To outline this; a test begins by starting the embedded server. The server can create a simple Atom workspace containing some feeds and entries in kind. Then I can have my client hit the server (in the test). The nice thing is that I can control the server 100%. Every time the test runs the server will be a fresh copy of the Atom workspace. This is very very useful.
My Javascript journey
I've been reading a bit. I read a bunch of David Flanagan's 5th edition of "Javascript: The Definitive Guide". The chapter on modules and namespaces was most interesting to me. I haven't used the technique he describes, using objects within Javascript to create a namespace. I see it as a must use technique for any collection of code that you would like to see reused. Unfortunately this technique was not employed in a pet project I have been working on. I will have to spend more time refactoring it so that different parts are packaged under namespaces. Oh well if I never get an actual product working I at least garnered some skills in the whole mess.
Becoming a better programmer
I'm on a kick to to enable myself to be a better Java programmer. To do this I will be looking at ways to extend my skills in general ways.
Dear readers (LOL): Any tips or stories of how you may have done this for yourself would be appreciated.I have picked up the books "Jakarta Commons Cookbook" and "Java Generics and Collections". I think these should be helpful. I have sadly known about the Apache commons libs for a long time, and never mustered the energy to explore them. I can see now that was dumb. The commons-lang and commons-logging alone simplify lots of the Java cruft I dislike. Generics is a language feature that I do have some experience with. I have done little to really understand them though. I think the book will be a quick way to expand my language skills. I am also really interested in getting deep into the 1.5 concurrency stuff. Any good book suggestions?
Subscribe to:
Posts (Atom)
