Be careful when doing some computation with integers (Fixnum in Ruby). If what you want as a result is supposed to be a float (Float) at least one of the operands has to be float as well.
irb> 1/2 => 0 irb> 1.to_f/2 => 0.5 irb> 1/2.to_f => 0.5
September 24, 11:15 2009
Today, I needed to copy a large set of images from one of our servers to another. Beside of that, I wanted all of them to be converted - resized to fit my needs. It would be rather painful if I tried to download the whole thing to my local machine first, batch convert the files with some desktop application and then upload it to another server, since just the downloading part would last for at least four hours with the speed of my internet connection. After some research I came up with this solution:
find . -iname '*.jpg' -print0 | xargs -0 mogrify -resize 800x600\>
-monitor -quality 80
With help of the ImageMagick package, this line does all the heavy lifting - it finds all the jpeg images in the directory (and its subdirectories) and then converts them to be no more than 800 by 600 px in size. Mogrify command rewrites the original files, so I needed to make a copy of the images directory.
After that I just used tar and sftp to send the size-reduced image directory to the other server.
Neat.
January 26, 16:35 2009
Andy Nullman knows how to get some attention and eat his own dog’s food. The way he promotes his new book Pow! Right Between The Eyes! - How To Profit From The Power of Surprise is … well … surprising. He is giving away 200(!) copies of his book to, as he puts it “ANY LEGITIMATE BLOGGER who simply asks [me] for one”. The deal is simple: you ask for it in your blog post - Andy sends it back to you. Read about more details in his own post.
Beside the fact, that I’m wondering if he will keep his word and send me the book all over to Slovakia, since that’s where I live right now, I’m really curious about the contents of the book, too. If the ideas it contains are as clever as this campaign, it’s surely worth reading.
January 21, 9:22 2009
The New Year is not that new anymore and the New Year resolutions are slowly but certainly fading out in minds of more and more people, day by day. If you’re not motivated enough or your will is just weak, there are more than enough mind “hacks” to keep yourself motivated or remind you of the goals you have set for yourself to achieve. One of them is a Seinfield Calendar which is based on a simple idea of not breaking the chain of day-by-day achievements of the goal you are supposed to be doing. Just read the article on Life Hacker to get the idea.
What I’m bringing you here is my own implementation of a Seinfeld Calendar in Google Spreadsheets.
Its aim is to be as simple as possible (so, as the whole Seinfeld’s hack). The usage is simple, too. Just write “d” (done) for the day you have done something for your goal or write “f” (failed) for the day you haven’t done anything (or you can leave the field empty, if you like it more that way). For every goal you want to track, create a new sheet (just duplicate the first one) and rename it according the goal.
Now, just keep it green!
January 09, 11:17 2009
I wrote this post as a motivation for anybody trying to start with writing tests for their code but feels some kind of resistance or fear from doing the first steps. Both of these feelings are natural and reasonable. Doing testing right is not an easy task. The whole testing thing with all its terminology, tools, styles, philosophies, metrics etc. can feel a bit overwhelming, at first. And it really is. The good news is, though, that you don’t need to digest it all at once.
As with every big problem there is a way to break it down and start with the small pieces first. At the end, every test is just a piece of code that exercises some other code. Do you feel any big concept in that? I’m sure not. So, how about just starting to write some little piece of code that exercises some other code you wrote? You do it all the time anyway, don’t you?
You don’t need to start with any “big” concepts such as TDD (test-first driven development) from the beginning. If you really want to give testing a shot and are lost (as I was when I started with testing just few months ago), start doing it in small unobtrusive steps. Next time you start working on some application (or just a new feature in an existing one) do the first step as usual - think about the feature you are about to code, code it and try to run it. Write as little code as possible, though. The aim is to have some solid piece of ground to stand on. When done, you can start to cover the code you just wrote with tests. I know, it’s quite difficult to decide what exactly to do when you stare at a blank test file, at first. But don’t fear. Just grab the first testing-belt (whatever testing library you’ll find in your closet) that suits you (which means, the first one you have or you think you can have some clue about) and throw the first little thing you think can have some effect on your code. Try to assert something or just grab something randomly if you think there’s no other way out and fire. It may work. Just do something! You’ll quickly learn to distinguish between good and wrong weapons for particular situations. You’ll be surprised how quickly these tools make sense when you use them actively.
Other great opportunity for doing experiments with testing is when you have some considerable piece of code already written - it may be some old nasty application, running for years - and some trouble strikes. You know it should work, but it doesn’t. So, you find the troublemaker and are about to fix it. Why not fill in some tests now to make sure you have that delicate piece of code under control? It’ll make you more confident, at least.
As for the question which kind of test you should write first (unit, functional, integration or whatever other kinds there are), the same rule applies - do whatever you think you have or can have some clue about. First, try to write for example some unit test. If you fail, just try something else. Maybe it’s best for you to start with some kind of general acceptance tests, like “when I call this url in the browser, I should see my name on the page somewhere.” There are tools and test-belts (eg. webrat for Ruby/Rails) you can use for writing this kind of tests, too. Just choose what makes sense to you. Any piece of code that tests something your application should do, is valuable and will rise your self-confidence about what you have done as well as your positive feelings about testing.
You may also think that you are going to do just “one more thing” on the top of all the other things you already do when you code. That is true. On the other hand, testing, when done properly, should minimize some other unpleasant activities you usually do while coding. After you’ll start doing it, you’ll notice eg. that you don’t switch between your editor and the browser that much anymore. You write tests and run them instantly in the background (automation of testing is usually very easy to set up in current testing frameworks) instead of switching between the windows and hiting F5 all the time (if you’re developing mainly for the web). You’ll find out that you don’t need to dig into your code with a debugger that much, anymore. And if you will need to work with your older code, you will find it much more comprehensible with the test code at hand. Your workflow should improve with testing, not break. Write tests only if it makes your life easier. Otherwise, it won’t make any sense. Tests are for you, the developer, in the first place.
Start writing tests whenever you have an opportunity to do it (ie. whenever you write some code). Choose any tool that makes sense to you and write any test that you feel could cover at least some tiny behavior of your application (don’t care about the coverage or any other scary terms from the day one). Don’t be afraid about primitive tests and trivial assertions - you’ll get more confidence as your test coverage will grow and you’ll become more and more happier as you’ll notice that you don’t need to hit F5 that often anymore. Think about testing in other positive terms - the better you are at it, the less time you need to spend with activities you don’t like (watching the spinning refresh icon in the browser, debugging) and more with things you love.
December 31, 0:59 2008
