I just ran into a problem with Eclipse 3.4.2 on Mac OS X Snow Leopard. Attempting to run or debug an Eclipse application, I got the error message "Cannot load 32-bit SWT libraries on 64-bit JVM".
Turns out that the old Eclipse versions (pre-3.5) are 32-bit, and Java 6 in Snow Leopard runs 64-bit by default. There seems to be multiple solutions to the problem, but the easiest in my case was to add "-d32" on the "Program arguments" list on the run configuration (the solution described here).
Sunday, November 01, 2009
Thursday, August 13, 2009
Using Google Reader's "Send To" feature with Diigo
I use Google Reader for keeping track of blogs and news. For bookmarks, I use Diigo.
Google Reader just added a "Send To" feature that allows you to send the link of a news item to Twitter, Facebook, Delicious, etc. Diigo is not on the list. However, it is possible to add your own "Send To" targets.
For Diigo, this is the recipe:
Now, you can post an entry in Google Reader to Diigo using the "Send to" link in the bottom of each item.
Update: You might also want to take a look at this Lifehacker article.
Google Reader just added a "Send To" feature that allows you to send the link of a news item to Twitter, Facebook, Delicious, etc. Diigo is not on the list. However, it is possible to add your own "Send To" targets.
For Diigo, this is the recipe:
- Go to "Settings" in Google Reader
- Go to the "Send To" tab
- Click the "Create a custom link" button
- Specify the following details
- Name: Diigo
- URL: http://www.diigo.com/post?url=${url}
- Icon URL: http://www.diigo.com/favicon.ico
- Click "Save"
Now, you can post an entry in Google Reader to Diigo using the "Send to" link in the bottom of each item.
Update: You might also want to take a look at this Lifehacker article.
Tuesday, June 09, 2009
Security messages when they're best
I know that it's not a good idea to have a password identical to your username but even so, this may not be the best way to announce it to the world. This dialog is presented from Quality Center every time you attempt to log in:
[caption id="attachment_48" align="alignnone" width="383" caption="Message from Quality Center"][/caption]
[caption id="attachment_48" align="alignnone" width="383" caption="Message from Quality Center"][/caption]
Monday, February 16, 2009
Great series of blog entries on DDD
Casey Charlton has a great series of blog entries on DDD (Domain Driven Design). The articles just keep on coming, and now he has made an ebook with all the articles. Great work, highly recommended.
Tuesday, February 03, 2009
Quality and the speed of development
Uncle Bob has written a post on the subject of quality versus speed.
I really like his point that speed in and of itself is not a success criteria. If the software you develop isn't quality software, it may (or may not) be faster to get the first release of the product shipped.
However, the speed of development for the remainder of the product's life may be heavily reduced due to the lack of quality in the design.
A good example of the opinion that speed matters more is when someone states that "we don't have time to write unit tests." Writing tests may take longer in the short run, but if done right, the quality of the software increases, which may even help get the release of out the door faster. At least, the quality of the code will improve.
In the upcoming book by Roy Osherove, The Art of Unit Testing, he deals with an example, where two teams in the same organisation implemented two similar features. One team wrote unit tests for their code, the other didn't. In summary, the unit testing team spent twice as long implementing the code. However, they were significantly faster integrating the code, and spent less time in manual test and bug fixing cycles. Actually, the team that wrote unit tests completed the feature in less time than the team that didn't. In addition, the number of bugs found in production was much lower.
The example in the book may not have been a very scientific study, but it shows that actions to increase the quality of the software may actually have the positive side effect of increasing the speed of development. Just remember that speed of development is not a quality in itself.
I really like his point that speed in and of itself is not a success criteria. If the software you develop isn't quality software, it may (or may not) be faster to get the first release of the product shipped.
However, the speed of development for the remainder of the product's life may be heavily reduced due to the lack of quality in the design.
A good example of the opinion that speed matters more is when someone states that "we don't have time to write unit tests." Writing tests may take longer in the short run, but if done right, the quality of the software increases, which may even help get the release of out the door faster. At least, the quality of the code will improve.
In the upcoming book by Roy Osherove, The Art of Unit Testing, he deals with an example, where two teams in the same organisation implemented two similar features. One team wrote unit tests for their code, the other didn't. In summary, the unit testing team spent twice as long implementing the code. However, they were significantly faster integrating the code, and spent less time in manual test and bug fixing cycles. Actually, the team that wrote unit tests completed the feature in less time than the team that didn't. In addition, the number of bugs found in production was much lower.
The example in the book may not have been a very scientific study, but it shows that actions to increase the quality of the software may actually have the positive side effect of increasing the speed of development. Just remember that speed of development is not a quality in itself.
Labels:
agile,
craftsmanship,
Design,
Quality,
unclebob
Sunday, January 25, 2009
Fantastic quote on Java in the "good old days"
Java before the Convention over Configuration movement: "Java is a DSL to transform big Xml documents into long exception stack traces" (Scott Bellware, according to Jeremy D. Miller).
Sunday, January 04, 2009
ReSharper 4.5 Nightly Builds are coming...
I just noticed that the nightly builds for ReSharper 4.5 have appeared. They are available here.
The changes in R# 4.5 are highlighted here. I am particularly looking forward to the enhanced performance and reduced memory footprint - these are practically the only issues that I find a tiny bit annoying (but nothing that cannot be cured with an extra helping of RAM).
The changes in R# 4.5 are highlighted here. I am particularly looking forward to the enhanced performance and reduced memory footprint - these are practically the only issues that I find a tiny bit annoying (but nothing that cannot be cured with an extra helping of RAM).
Subscribe to:
Posts (Atom)