Monday, February 13, 2012
Removing all .svn folders
Every now and then I need to copy a folder which is under source control. By copying the folder all source control information is copied along which needs to be removed afterwards. If the amount of folders is small this is done pretty easy manually but when we are talking larger amounts of folders doing it manually easily ends up pretty time consuming.
I figured there would be a pretty easy solution for this with some nifty Linux command line magic and it didn't take long to find something that worked:
find . -iname ".svn" | xargs rm -r $1
This removes all .svn folders recursively.
Labels: linux, subversion
posted by Peter Haldbæk @ 12:21,
, links to this post
Saturday, January 21, 2012
Issue with Amitech 390B TV solved
I happen to own an Amitech 390B LED TV and noticed a very peculiar behavior when I was watching Swedish television (SVT1, SVT2 or SVTB/SVT24). Teletext would be turned on automatically every 10 minutes or so which was highly annoying since it had to be turned off again manually. Since I do not use the screen for watching television anyway it did not really matter but I still found it weird and last night I thought of something that might fix it.
So if you are facing these issues, simply turn off the subtitles.
posted by Peter Haldbæk @ 20:36,
, links to this post
Wednesday, October 26, 2011
More mobile conferences
I just discovered some extra (Android) conferences which seem interesting.
- DroidCon was recently held in London but is also held in Berlin, Amsterdam and Bukarest
- AnDevCon Nov. 6-9 in San Francisco
Labels: conference, mobile
posted by Peter Haldbæk @ 23:12,
, links to this post
Thursday, September 22, 2011
Hibernate, Oracle, HSQLDB and sequences
Recently I was writing some unit tests where I needed to access a database sequence for generation of unique numbers. The production environment uses Oracle while my unit tests use HQSLDB. The numbers from the sequence are extracted by ordinary SQL through Hibernate meaning that I could not rely on specifying the database dialect since the SQL is hardcoded. The code used for extracting the numbers (in Oracle) looked something like this
long number =
((BigDecimal) sessionFactory.getCurrentSession().createSQLQuery
("select my_seq.nextval from dual")
.uniqueResult()
).longValue();Running this in a unit test results in a ClassCastException since HSQLDB either generates the primitive int or a BigInteger instance depending on how the sequence was created. A simple solution for this is to add a scalar to the query determining the type of the returned number.long number =
((BigDecimal) sessionFactory.getCurrentSession().createSQLQuery
("select my_seq.nextval as id from dual")
.addScalar("id", new BigDecimalType())
.uniqueResult()
).longValue();Voila! The number is now converted to a BigDecimal by Hibernate and the ClassCastExceptions are long gone.Labels: hibernate, hsqldb, java, oracle, test
posted by Peter Haldbæk @ 20:01,
, links to this post
Monday, August 29, 2011
Mobile conferences
Just stumbled upon some more interesting conferences. I really wanted to go to Google IO and/or WWDC but these conferences sell out in like 2 seconds so my odds of ever going to one of these events seem slim. But there are other interesting conferences out there and here is a quick list of what I have found so far:
- Android Open Oct. 9-11 in San Francisco
- App Conference and Hackaton Oct. 26-27 in Santa Clara (not really a conference but looks fun)
- Mobile Web Africa Nov. 22-25 in Johannesburg, South Africa
Labels: conference, mobile
posted by Peter Haldbæk @ 21:23,
, links to this post
Saturday, June 18, 2011
NAS and iPhoto, Mission Impossible?
Before I got my MacBook Pro I used my old Mac Mini with Tiger installed as my primary storage for my photos (using iPhoto). I then purchased a NAS, formatted it with ext3, copied my iPhoto library to the NAS and configured my Mac Mini to use the NAS as iPhoto library instead of the library stored on the Mini itself. It worked like a charm and now my photos would also be available to my other devices on my network (phones, other computers, media renderers etc.).
- iPhoto libraries for Tiger and Snow Leopard are not compatible
- And apparently something happened with iPhoto in later versions since it is not possible to put the iPhoto library on an ext3-formatted disk.
So I decided to look for a solution where:
- My photo library should be stored on my NAS
- The NAS is formatted with ext3
- The folder structure of the library should be configurable. I specifically wanted to store my photos in a structure like this: year / month / date.
- The export of photos from camera to computer should be done automatically (I do not want to drag images into correct folders by hand)
I figured this could be achieved in two ways. Either by finding a way of exporting my photos directly to the NAS and then later importing these photos into iPhoto (I actually do like iPhoto I just hate the lousy support for network storage) or letting iPhoto import the photos to my MacBook Pro and then schedule a job to automatically copy the files to the NAS. I do not need to sync the Mac Mini since it is more or less retired.
Importing photos to NAS
I first explored the possibilities given by Apple.
Image Capture
Mac OS X comes with a little utility called Image Capture which exports photos from your camera to your computer. I never explored whether it supported ext3 formatted disks since you have to export the photos to your destination manually. Image Capture does support automatic export but then all your exported images will end up in the same folder. So I quickly turned to other solutions.
Autoimporter
A (very) secret photo utility in Mac OS X is called Autoimporter. It is not accessible through the Applications menu so you will have to open Finder and locate the application by hand. It can be found at /System/Library/Image Capture/Support/Application/AutoImporter.app.
At first this tool looked very promising. It basically (as it name suggests) imports photos automatically based on your configuration. It accepts parameters such as date, camera name, user name and sequence number. Unfortunately the date is the date of the import not the date when the picture was taken and it does not support nested folders so I turned to options offered by 3rd parties.
Kodak Easy Share
Kodak has released a free photo library tool called Kodak Easy Share. It was really hard finding the downloadable application (and I forgot where I found it) but do not bother. It stinks. It looks horrible on a Mac and the export functionality did not support nested, configurable folders so this was not an option either.
digiKam
I was a little excited to try this out since it has a very good reputation. It is open-source and runs on both Linux, Windows and Mac so I was really hoping this could solve my problems. It is not supported on Mac out of the box though and I had lots of problems intalling it but I succeeded in the end. Follow the instructions at http://www.digikam.org, pray and wait (it took me 2 full days for everything to compile).
I really liked digiKam as a product. It seems very polished (not as polished as iPhoto) considering it is open-source and there were tons of options. The import from camera functionality however suffered from the same limitations as I discovered with the other tools. No support for nested, configurable folders so once more it was back to the drawing board. I was very impressed though and would seriously consider digiKam over F-Spot next time I use Linux.
Using iPhoto and rsync
That was it. I gave up on finding software which could copy photos from my camera to a folder structure on my NAS ordered by year, month and date. A task so seemingly simple but apparently impossible to achieve. Instead I opted for option number two. Importing photos to my laptop using iPhoto and then synchronize the NAS with the contents on my laptop.
I figured I could use rsync for that but I had some problems locating my photos in the iPhoto library. I did find some photos but I was not sure whether they were the originals or not so I decided to search Google for advice. I quickly realized that messing up with the internals of the iPhoto Library (even if it is only copying) is not the way to go. The later versions of iPhoto (pre 9 I think) started storing images in a database instead of the file system making it hard to just copy the photos to my NAS.
It was about then my first revelation came. Either I use iPhoto as I am supposed to (as Steve wants me to that is) or I skip it. Messing with the internals of iPhoto would only give me headaches. I decided to continue using iPhoto but my problem was still not solved.
Phoshare to the rescue
Months went by and I tried to convince myself I was happy with iPhoto as it was. And then I accidently came across a neat little utility called Phoshare. Phoshare lets you export photos from iPhoto (almost) exactly as you want. It does not support nested date folders but it probably supports everything else you could wish for. It also exports image metadata and it is pretty fast too.
So at last I could breath a sigh of relief (and satisfaction). Now I use my iPhoto installation on my laptop as my main administration tool and for import of photos. After each import I run Phoshare and it synchronizes my laptop and NAS. I do not have nested date folders but I started using the iPhotos event functionality and order my photos in folders with year and event name. It makes it pretty easy to navigate from my other devices at home and it works like a charm.
Finally I am done. I cannot wait to see if iMovie is up to the task of sharing my movies through my NAS (slight sarcasm might have been used here).
posted by Peter Haldbæk @ 22:36,
, links to this post
Saturday, March 26, 2011
Mockito, static imports and Eclipse
I recently started using Mockito as a mocking framework. Mockito makes heavy use of static imports which by default in Eclipse are not accessible through code completion. It is possible to use the Mockito methods by accessing them through their class by writing Mockito.when but this would quickly clutter your code with a lot of Mockito references. Code completion has been around for ages so not having it feels like coding in Notepad or vi. Fortunately I have found out that it is actually possible and quite easy to configure Eclipse to add the static imports which is a great relief.
Simply open the Preferences in Eclipse and go to the menu item Java -> Editor -> Content Assist -> Favorites and press the button New Type.... Enter the text org.mockito.Mockito and press OK. Now you have all static methods on the Mockito class available to you through code completion.
Other useful Mockito classes to add are org.mockito.Matchers and org.mockito.BDDMockito (if you are into BDD).
Labels: eclipse, java, mockito, test
posted by Peter Haldbæk @ 14:22,
, links to this post
Thursday, October 28, 2010
Concrete - My very own Android ORM
I finally decided to write my own ORM for the Android platform simply because I thought this was really needed. The only option I found was the Active Android framework which is not open source in any way. So I figured it was time to code my own framework. So here is Concrete! The framework is still very rudimentary to say the least but if I find the time I think it will work out pretty nicely. I have been influenced by Hibernate, the Active Record pattern and of course Active Android. In the current state it does not support relations (yikes!) but I am working on this so stay tuned.
So how does the framework work? It is pretty easy. Let's say you have a table called Foo with the string myText, the integer myNumber and the date myDate. All you have to do to get basic CRUD operations on this table is to create this object:
package com.briskbee.concrete.example.record; import java.util.Date; import android.content.Context; import com.briskbee.concrete.Record; public class Foo extends RecordPlease note all variables of the class are public. This is necessary for the framework to be able to recognize them as properties of the class (and columns of the table). So now we have an object let's use it. Let's say we are inside an activity and want to create a row in the table foo.{ public String myText; public int myNumber; public Date myDate; public Foo(Context context) { super(context); } }
Foo foo = new Foo(this); foo.myText = "some text"; foo.myNumber = 3; foo.myDate = new Date(); foo.save();That is basically all there is to it. No need for writing tedious CRUD code anymore. It is as DRY as it gets. Retrieving, updating and deleting records are just as easy:
// Load foo Foo foo = new Foo(this); foo.load(1); // Update foo foo.myText = "some other text"; foo.update(); // Delete foo foo.delete();That is pretty neat in my book. The framework relies heavily on reflection and I have no clue how this performs. The code runs faster if you are writing all the hardwiring by hand but it is also pretty boring and very un-DRY.
As a developer you still need to have your own implementation of SQLiteOpenHelper which creates the tables for you. I am planning to implement some automatic stuff for this too but fixing relations is a higher priority at the moment.
posted by Peter Haldbæk @ 23:04,
, links to this post
Friday, October 1, 2010
Paid Android apps finally in Denmark
Today Google announced they would introduce paid apps in the Danish version of Android Market and 17 other markets as well. It was announced in an email sent to all Android developers.
Hello,This comes as a very pleasant surprise to me as I was slowly giving up hope that this would change anytime soon.
We're writing to inform you about some changes to Android Market that require your attention.
Effective today, developers from 20 additional countries (Argentina, Australia, Belgium, Brazil, Canada, Denmark, Finland, Hong Kong, Ireland, Israel, Mexico, New Zealand, Norway, Portugal, Russia, Singapore, South Korea, Sweden, Switzerland and Taiwan) can now sell paid apps on Android Market. Over the next 2 weeks, users from 18 new countries (Argentina, Brazil, Belgium, Czech Republic, Denmark, Finland, Hong Kong, India, Ireland, Israel, Mexico, Norway, Poland, Portugal, Russia, Singapore, Sweden, and Taiwan) will be able to purchase paid apps from Android Market.
Please see the related post at Android Developer Blog here:
http://android-developers.blogspot.com/
We encourage you to visit the Android Market developer console at http://market.android.com/publish to make the necessary adjustments.
Thanks, and we look forward to continue working with you on Android Market.
Sincerely,
The Android Market Team
posted by Peter Haldbæk @ 21:48,
, links to this post
Monday, September 27, 2010
Speeding up unit tests using in-memory database
I am a big fan of test-driven principles but have been on projects where running the full unit test suite would last 2-3 hours simply because writing to and reading from the database would slow everything down. This normally lead to optimizations such as only creating test data once having the unfortunate side effect of making unit tests dependent on each other (one unit test may change some data used in another unit test). It can also lead to random behavior making the test pass one time and then not the other simply because unit tests are not necessarily run in the same sequence every time.
Using an in-memory database can improve time spent on running unit tests significantly. In this article I will discuss the pros and cons of this approach and show how to do this.
Before you start using in-memory databases for unit testing some basic questions should be asked.
- Does your database support in-memory use at all?
If it does there is no excuse for not using the in-memory database instead of the physical one. Databases I know of who currently support in-memory versions are SQLite, HSQLDB and Oracle TimesTen.
- Do you use non ANSI SQL?
- Do you use triggers?
- Do you use some form of procedural SQL (PL/SQL and the likes)?
If your database does not support in-memory usage and you can answer yes to one (or more) of the questions above it might turn out you cannot use in-memory databases but there are ways to solve this. Lets go into detail.
Do you use non ANSI SQL?
If your SQL is non ANSI SQL you will have a harder time switching between database vendors since the code now depends on vendor-specific SQL. One such example could be Oracles old definition of joins. In Oracle 8i and older versions outer left joins where defined like this
SELECT * FROM emp, dept WHERE emp.deptno = dept.deptno(+)Whereas the newer version (9i and onward) also supports the ANSI SQL definition
SELECT * FROM emp LEFT OUTER JOIN dept on emp.deptno = dept.deptnoPlease be aware that the old definition of left outer (and other) joins are still supported by Oracle meaning that the non ANSI SQL definition of joins still exist in a lot of places (I used to use them myself until I realized this).
If you use Hibernate this is (probably) not a problem since you can just change the database dialect of Hibernate when running your unit tests. But this requires that you do not make any direct use of (non ANSI) SQL and my experience is that this is seldom the case. There is always some special problem which is to hard to express via Hibernate and then you end up writing some SQL instead.
Do you use triggers?
If you decide to use the in-memory database of HSQLDB (I did) and you have triggers in your (production) database you need to have something similar in your in-memory database. HSQLDB supports this in its own peculiar way but it is actually quite neat in a testing environment because the trigger itself is a little piece of Java code that is executed. So you need to implement the triggers in the test database as well.
Do you use some form of procedural SQL (PL/SQL and the likes)?
If your application makes heavy use of procedural SQL in-memory databases are probably not the best fit unless your production database supports this out of the box. Because you will probably have to rewrite all of your procedures to do so. If it is only a matter of converting one or two procedures an in-memory database like HSQLDB supports this like triggers above. It is just a matter of writing your procedure as some Java code and register it as a procedure in HSQLDB.
Using an in-memory database
I was working on a project where unit testing was abandoned since running the tests were simply not possible. Not because it took a lot of time but simply because the tests would fail when they were being run together. Database connections were not released quickly enough giving all kinds of problems. So instead of trying to fix a problem I had been trying to solve for years I ended up redefining the whole testing framework making use of an in-memory database. We were using Oracle 10g and the database itself was pretty simple so it made a lot of sense to make the switch. Using HSQLDB in-memory is really easy. I implemented a base test class all unit tests extend from. This base test class is responsible for creating the proper JNDI context containing the HSQLDB data source.
import javax.naming.InitialContext;
import org.hsqldb.jdbc.JDBCDataSource;
...
// Construct DataSource
JDBCDataSource ds = new JDBCDataSource();
ds.setDatabase("jdbc:hsqldb:mem:myDB");
ds.setUser("SA");
ds.setPassword("");
// Put datasource in JNDI context
InitialContext ic = new InitialContext();
ic.bind("java:/comp/env/jdbc/myDS", ds);
Before each test the database is created with schema, tables and test data. Since everything resides in memory initialization is exceptionally fast compared to a physical database. I never made any direct measurements to compare the two approaches but I know I never wait for a test to finish. It just does in an instant. That is such a relief!The Hibernate configuration for the test classes must also be changed to use the HSQLDB dialect. Edit this in your hibernate.cfg.xml file:
Now you are set and you are ready to run your tests using an in-memory database.org.hibernate.dialect.HSQLDialect
posted by Peter Haldbæk @ 15:47,
, links to this post