You can use optimize, but I had to disable code/simplification/cast and code/allocation/variable optimizations. In addition, overloadaggressively and allowaccessmodification will result in illegal opcodes detected at runtime only.

        <proguard optimize="true" shrink="true" defaultpackage=""
                  printmapping="false" verbose="false"
                  usemixedcaseclassnames="true" obfuscate="${obfuscate}"
                  overloadaggressively="false" printseeds="false"
                  allowaccessmodification="false" microedition="false">
            ... snip ...
            <keep name="*" extends="android.app.Activity">
                <method name="*"/>
            </keep>
            -optimizations !code/simplification/cast
            -optimizations !code/allocation/variable
        </proguard>

tfdj

Talking a lot about Scala. Clojure, Haskel, Ruby, JavaScript. Multi-Paradigm and Polyglot programming.

To be honest: I haven’t heard of Dean before today. :) But when I read Object Mentor and Uncle Bob, I knew I should keep on reading..

So if you got some minutes, watch the video or read the notes..

tfdj

After my initial port of JamJam which resulted in the DroidShock release to be found here, I started porting my IntensiGame example project: Galaxina.

I squashed a multitude of bugs in IntensiDroid – the IntensiGame implementation for Android. Added some core functionality that DroidShock didn’t use. And ended up with a first solid IntensiGame release.

Still only working with my Samsung Galaxy I am waiting impatiently for my G1 and the Nexus One. With my PSYCHOCELL buddies jumping on the Android bandwagon I have a few Android devices for testing available soon. Hopefully this will fix the OpenGL/EGL issues that I still have with the G1 and the Droid in no time.

Grab the alpha release Android packages from the Galaxina page on www.intensicode.net.

I recommend the non-OPENGL version. Both versions render at about the same frame rate. And the non-OPENGL looks a lot nicer.

But if you want to help me out, please test the OPENGL version, too, and send me some feedback. Does it run at all? Gfx messed up? Etc..

I will go back now to DroidShock and start playing with the more Android specific concepts like using touch for more control options and integrating sensor data.

tfdj

Get this movie and watch it:
Food Inc at IMDB
Food Inc Homepage
Food Inc at TPB

Enjoy Life! Respect Life! Go Vegan!

There are so many things in life you can have fun with.. Make your choices.. Wisely..

Amen,
tfdj

that’s all you need after a long day of coding..

tfdj

On the one hand, Android is a relief coming from J2ME.. :) The development environment is fun. The emulator is usable. Startup time is crazy, of course. But what emulator isn’t? But deployment is fast enough and easy enough. The same is true for using a real device via USB. No problems except some 1.5 SDK woes with Linux. Solved in no time.

You also have some nice APIs to work with. Graphics, sound, IO, especially network IO. It’s all there.

But, on the other hand, you will encounter many dark areas quickly. Up until Android 2.x the whole EGL (the embedded OpenGL) thing is horribly broken in weird little ways. Leaking garbage, interrupting you application every few seconds for a few hundred milliseconds, not supporting proper extensions and at least EGL 1.1. Only EGL 1.0 is a requirement for Android devices. Horrible firmware-/device-specific issues like for example the Samsung Galaxy falling back to software rendering when you tell it to allocate less memory for EGL.

IO seems to be a bit slow. But I’m still investigating if I’m doing something wrong there. Or if there are better APIs or ways to store and retrieve data.

Anyway, I got JamJam running at nearly 30 FPS using EGL/OpenGL or basic canvas graphics without too much tweaking. Acceptable for a first release, I guess. Funny enough I have no problems running the same game (and same code base) at 30-50 FPS on J2ME phones like the more (r/d)ecent Nokia and Sony Ericsson phones.

I have attached a first release of “DroidShock” to this post. I consider this a free demo version of JamJam for Android. I’ll add versions supporting other screen sizes during the next few days. Let me know if you’re interested in helping me out with some alpha/beta testing on your device.

Cheers,
TFDJ

Release with Canvas graphics: DroidShock_DEBUG_CANVAS_320×480

Release with OpenGL graphics: DroidShock_DEBUG_OGL_320×480

When Windows Vista came around I started telling people sorry, can’t do it. Don’t want to do it. Luckily for me most people skipped Vista. Those with Vista came running to me with Wifi trouble and stuff like that. And I usually shrugged my shoulders and say sorry. Well, we all know what a great job Microsoft did with Vista.. :)

Now there’s Windows 7. And for some time it looked like it could be a replacement for Windows XP. Finally.

But it’s not. It’s crap. The same as Vista. Same problems. New problems. Usability is really bad. We don’t have to get into any discussions about security I assume. With the latest IE8 hacks out there it is futile for anyone to defend Microsoft in the area of security.

Anyway, I have to continue shrugging my shoulders and will continue to urge people to stick with Windows XP as long as possible. Or switch to Ubuntu/Linux. A few converters are really happy with Ubuntu. The switch does make sense by now. If you are into games you can keep a dual boot Windows partition or switch to a console. But don’t bother with the Windows 7 crap as your main desktop OS.. Please..

Amen,
tfdj

This is a little milestone for me. I have a few other apps online. But JamJam is the first application (and the first commercial game) I consider a major release. It may not look like much, but apart from the game itself, all the used frameworks and tools are available as open-source by now. (See my github page for details.)

This was all part of the “release”: The IntensiGame framework, the RunME emulation layer for development, the IntensiBuild system for building against the different J2ME device specs, and of course JamJam, the game itself.

Well, time moved on. And so did I. Android is the new thing now.. Expect an initial IntensiDroid release, soon.. :)

tfdj

It’s at this point that I should stress that whichever style of test you use, you must combine it with coarser grained acceptance tests that operate across the system as a whole. I’ve often come across projects which were late in using acceptance tests and regretted it.

Most projects I worked on, most teams I worked with, did some kind of testing. None TDD. None came even close to what the grand masters are doing in this area. But we all tried our best.

However, what most of us never realized is that unit testing is really just that. *Unit* testing. I remember when back in 2003 (plus minus a year) I worked on a Java (Micro Edition) navigation software and I wrote tests (which I called “system tests” back then) for running the whole app in a ‘headless’ emulator and logging all navigational actions. The test then compared this to the expected output. Running time was up to a minute for some of these tests. In another corner of this project I wrote “graphical tests” which rendered the 2D and 3D view of the navigation system and compared the images to the expected output. After I left the project, the colleagues quickly dropped most of the tests. (In fact, most of the unit tests were dropped, too. They considered them a burden. But that, I guess, is a different story.) I, however, knew how helpful these tests were. More than once did I make a simple change in an ‘unrelated’ class and it would magically affect the output of the ‘advisor’ component – not drawing the correct direction sign anymore. The tests didn’t necessarily help me to spot the source of the bug. But they made sure I did not commit breaking changes.

On a more recent project, a proxy server written in Ruby, I applied three levels of “system tests”: I used “spike tests” to drive a set of objects from all layers, but with a SQLite3 database instead of the real thing. Then I added “black box tests” running the system as a whole and hitting it with certain HTTP requests. Still using the SQLite3 database setup and running the tests on the local developer machine or the build server. Plus I added “deployment tests”. More or less the “black box tests”, but running against the deployed system. Because the proxy was the place where I had to add quick changes (because the proxied system was to hard to change), these tests allowed me to move very quickly from changes to deployment (to the test system) and on to production.

To make this long story short: Two things are important for me. 1. I am all with Uncle Bob in that you should always consider the database just an implementation detail. Make sure from the very beginning that you can replace it with an in-memory or SQLIte3 database. Or flat file. Or fake. Or whatever. 2. Use fine-grained unit tests. Plus, use coarse-grained acceptance tests. (What I called “system tests” or “spike tests” above.)

I’ll continue reading up on mocking and testing etc.. I feel I have a lot more catching up to do.. :/

tfdj

It reminds me of my early years at the university. I feel like I can share Knuth’s point of view on many topics. Like Extreme Programming, Parallel Programming and “everything else”. But I also understand the thrive for new approaches like Extreme Programming and everything related to multi-cores and parallelism. It’s fair to say that I have two hearts beating in my chest.

My early years at the university I learned the old ways. Older professors. Older ideas. Still relevant! Make no mistake there.. But after a few years I noticed a shift. The professors noticed it, too, I guess. And most adapted successfully. I (we all, I guess) went through the Unified Process and the Personal Software Process to Extreme Programming and beyond.

I’ve spent six and a half – mostly good – years at the University of Karlsruhe. Blessed with professors like Tichy and Goos and some more who’s names I don’t recall correctly right now..

Amen,
tfdj