Before I started developing on Android in early 2009, I had very much enjoyed the blessings of Ruby’s ActiveRecord object-relational adapter which makes development very easy and fast compared to such heavyweight und – for my taste – cumbersome approaches as the DAO/JPA-Template/Hibernate layer cake that is commonly found in the Spring-dominated world of Java server development. But what I encountered when I first used Android’s way of creating and accessing SQLite databases was even worse than that. You get the least thinkable amount of support from the system and have to write your mapping and persistence logic (table creation, finders, etc.) as a thin layer directly on top of the SQL query interface.
As a remedy, I used and still use SQLiteGen in some of my projects, which generates a glue layer in the form of Java beans, as directed by the developer through Java annotations. It works, but project development seems to have run dry and the current version could use several improvements.
That’s why I started to look for something new and, a few weeks ago, stumbled across Sugar, a simple but effective object-relational mapper that imitates the behavior of ActiveRecord, mainly by using reflection to inspect the data structures that are mapped to database tables. I liked its general approach and forked Sugar on GitHub to convert it into an Android library project, fix some issues and inject new features, such as support for Enum-typed fields. If you are a an Android developer looking for an alternative way of mapping between your application model and your database, maybe you should give Sugar a spin.
And I hadn’t heard of it until now. Looks like I’m not such a geek after all.
But it shocked me just as much as when I heard that J.D. Salinger had died – it actually made my eyes well up – so I guess I am quite a geek.
When I wrote about the departure of other Java Gods, I thought I was making a joke when I wondered how long James Gosling would remain at Sun. Now Guy Steele is the last man standing… but for how long?
Ever since the takeover by Oracle, I haven’t had a good feeling about the future of Java. IBM would have been a much better match. Oy vey…
I use this posting for blatantly advertising one of the development projects I was recently involved in – an Android application called Hoccer. It was released by ART+COM Technologies as a free app on the Android Market and as entry for the 2nd Android Developer Challenge.
The aim of Hoccer is to simplify the process of sharing data (currently pictures and contacts) between devices – you use certain gestures for one-to-one (tap) or one-to-many (throw/catch) to determine sender and receiver(s) and the data is transferred over the internet subsequently, so no other mechanism of pairing etc. is needed.
An iPhone version is currently under development, and there’s a web client to hoc data from a desktop computer to a mobile device, so no one’s left out.
There seems to be a new kind of scam, involving the telephone network: my sister (from her O2 mobile phone) called me (on my Alice fixed-line phone), but the Lithuanian premium-rate number 0037091005481 was displayed as caller ID – although we’re both in Germany! This has happened to dozens or probably hundreds of people in Germany in the last few weeks, apparently mostly to customers of O2 and Alice.
Of course, phone scams have been around for a while, but they usually involve social rather than technical engineering. The twist in this one is that the scammers must have hacked some kind of telephone switches. I don’t know what hardware and software phone providers are using these days, but I think it’s safe to assume that it’s connected to the Internet, and it’s increasingly involving VoIP. It’s also interesting to note that Alice cooperates with O2 for its mobile services. Integrating disparate systems can get messy – maybe a door was accidentally left open somewhere on the way?
Being curious, I called that mysterious number and heard the following recording:
Thank you for calling pentowork [sic? the name was hard to understand] payment system, the most efficient internet based billing solution. To receive your unique PIN code, you are required to hold the line for thirty minutes.
So the aim seems to be the same as in many other phone scams – get people to call an expensive number, and make them stay on the line for as long as possible. The three or four calls it took to correctly write down the recording cost me about €10, but I also got to enjoy some nice background music: Comanche from the Pulp Fiction Soundtrack and Man on the Moon by REM. I wonder what they selected for the remaining half hour…
Short note to myself and whom it my concern. If you try to sudo gem install mysql on a Debian system and it responds, after some working, with:
Building native extensions. This could take a while...
ERROR: Error installing mysql:
ERROR: Failed to build gem native extension.
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out
then this should be the solution for you: First you install libmysqlclient15-dev, which generates a mysql_config file, and the install the gem using the config.
I’m currently updating a not-so-small application from Rails 2.0.2 to 2.2.2 and it seems that about every other plugin is not compatible with the new version, because one or the other method was removed, and I have to update them as well. Not such a big problem, if a compatible version exists, but takes quite some time, and I don’t understand that I have to go through this hassle (and other hassles) about everytime I update to a new Rails version. I don’t remember having this kind of trouble when I was working in Java Land. Can somebody explain?