In a world gone mad..

A quick note about using ProGuard to optimize and/or obfuscate Android packages. Maybe this is useful to someone..

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

Filed by The.French.DJ at 12:54 am under Android, Development
No Comments

Just read through this quite interesting interview with Dean Wampler.

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

Filed by The.French.DJ at 10:44 am under Development
No Comments

Three weeks passed in no time. Here’s another quick status report on my Android porting efforts.

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

Filed by The.French.DJ at 12:14 am under Android, Development, Games, Mobile
No Comments

I’ve spent the last two weeks porting JamJam, IntensiGame and the related projects to Android. It’s been an interesting ride..

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

Filed by The.French.DJ at 5:28 pm under Android, Development, Games
No Comments

It’s been a major struggle to get this game online. But here it is now: JamJam at Jamba

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

Filed by The.French.DJ at 11:31 pm under Development, Games, J2ME
2 Comments

Following up on my post from yesterday I re-read the revised version of Fowler’s Mocks Aren’t Stubs article. With the whole article being a good read, this is the part that I consider the most important to me:

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

Filed by The.French.DJ at 1:37 pm under Development
No Comments

Well, what can I say.. I got distracted by this rather interesting interview with Donald Knuth.

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

Filed by The.French.DJ at 2:10 pm under Development
No Comments

I missed Uncle Bob’s article about “Manual Mocking: Resisting the Invasion of Dots and Parentheses” and only found it through this blog post: “Think different about mock objects!”

Good stuff.

To be honest I feel like I did not keep up enough with all the Mocking and TDDing stuff in the last few years. A few days ago I started a new pet project to help me catch up a little bit. Let’s see how this turns out..

Anyway, the XPlayer blog post has some valuable (for me!) points:

One thing I learn is that mock objects are a design tool, while many people see it only as a technique for speeding up unit tests.

Because you should use mock objects as far as you can apply TDD, whereas you can design and *discover* interfaces (and roles), and assign responsibility. On the other hand, in front of a third-party library you cannot follow this process, since the code is not under your control, and you cannot modify it.

Because if you use mock objects with third-party libraries (two concrete examples taken from our recent projects: isolating our tests from the database in a Rails app, or in a java app using Hibernate ORM), you’ll write tests that *guess* the library behaviour, and your guesses may be far away from the actual behaviour.

So, I’ll repeat myself, following this “mocks as a design tool” approach, you’ll mock only types you own.

I basically quoted the whole post here.. :) Go on, read it!

I’m off to read the original Uncle Bob post now..

Cheers,
tfdj

Filed by The.French.DJ at 1:23 pm under Development
No Comments

As a follow-up to my rather useless book review section update a few days ago I decided to write some more about Software Creativity 2.0 by Robert L. Glass.

It is easy to read this book and see it as “merely” an important book with a number of important essays. But for me it sparked a few interesting (at least to me!) ideas and it made me recall a few long lost thoughts about the “dichotomy of discipline and flexibility” in the field of software, computer science, programming, etc.

Let me present here a few quotes from the book.

But let me start with one of my (trivial) thoughts that has been stuck with me since reading the book:

The Formal/Structured/Disciplined Approach of Software Development could be characterized as “the act of solving”.

The Heuristic/Agile/Flexible Approach of Software Development could be characterized as “finding previously not known solutions”.

In short: Disciplined “solves”. Flexible “provides solutions”.

You will have to read the book to understand the larger context of this. With essays about theory versus practice, industry versus academe, etc. But for me one of the more important fundamental concepts is captured in the “solves” versus “provides solutions” thought.

Let me continue with some quotes from the book (which are mostly quotes in the book, too). They are not directly related with the introductory thought above. But that does not really matter.. :)

On congruence – in the context of matching the right technique with the problems/complexity you’re trying to solve:

Plauger writes: “The name of the game is congruence.” The techniques you employ had better be consistent with the intrinsic complexity of the problem you’re trying to solve.
(from Software Creativity 2.0 by Robert L. Glass)

A simple but powerful and important statement. Instead of simply saying that you should “not use a hammer for every task at hand” the (for me) most important aspect in this quote is the “intrinsic complexity”. When I look at my software projects, this is the thing that limits me. The intrinsic complexity. For me it is not only about the right technique. I also learned that my brain has its limits when trying to conquer (software) complexity. (You can call me stupid if you want. I am probably quite OK with that.. :) I can try different approaches and techniques. And some problems are solvable by me this way. For some I have to try harder. For some I have to try new techniques. But for some I simply have to back down and say: “Sorry. I cannot solve this.”

For me this was an insight that resulted in quite some relief.

On management – a trivial but very important and much to my surprise often not understood or not accepted thought:

Plauger again: A large enough project is primarily an exercise in management. The programming technology has only a minor effect on the outcome.
(from Software Creativity 2.0 by Robert L. Glass)

I can – to this day – not believe how (plain and simple) stupid many software “professionals” are. Management is key to project success. Of course the skill level of the developers is important. But management is key. Accept it. Live (work) by it.

On mathematics – one of my problem areas, sadly:

“I am simply saying that the help it [mathematics] provides, for the vast majority of software people, is marginal at best. Perhaps, in fact, Latin would be at least as useful in terms of the logic and rigor it offers.”
(Robert L. Glass in Software Creativity 2.0 about his “Latin Syndrome”.

Mathematics nearly killed me back in university. I failed “Analysis” twice and only made it through the verbal examination (the last chance), because the professor was kind enough to acknowledge the fact that I am a really a programmer (by heart) and not a mathematician and the mathematics are probably a bit too advanced for someone that tends to lean more towards the practical side of computing. Back than I realized there is some wisdom in this man that I appreciated on many levels. To this day I am thankful to this man.

On software specification – the core topic of my diploma/thesis:

Frosch 1969: “the idea of a complete specification is an absurdity”
(from Software Creativity 2.0 by Robert L. Glass)

I remember during the time I was writing my thesis how I argued with my boss about the benefits of software processes and having the requirements specified as complete as possible. The goal for my thesis was to evaluate the benefit of doing upfront requirements specification in context of the then available software processes. Mainly limited to the what then became Unified Process I specified a medium sized software project, designed it with Rational Rose, used the Rose code generator to create a nearly executable prototype and then captured this experience and tried to put it into the various contexts of software process, requirements, design, implementation, maintenance.

It was a rather enlightening experience. Not a very “good” or “nice” experience in it self. But enlightening it was.

Reading now what I have just written, I realize this is quite strongly connected to the “congruence” thing mentioned aboce. Yes, sure this approach was “interesting” to follow. But no, it is not very practical. Unfortunately it is rather complicated to formulate all of the draw backs here. For this, read the book. Glass does this much better than I could ever do. Fact is: I experienced exactly what Glass is talking about.

Enough for now. I’ll write a second post with some more quotes later. I did not realize how much has accumulated while reading this book.

tfdj

Filed by The.French.DJ at 3:23 pm under Development, Review
No Comments

Head on over to http://github.com/DanielLukic

I have finally released the frameworks I use for developing my J2ME applications. With Android and the iPhone going strong nowadays I am probably a bit late with releasing my J2ME stuff. But who knows? I am thinking about covering Android with a RunME like emulation layer. This will probably happen sometime 2012.. :)

Anyway, here is a quick overview of the projects/modules:

* IntensiBuild – Simple Ruby-based build system for building various releases of an application. This needs a few updates from my commercial projects to cover building a J2SE release and a ME4SE launcher JAR.

* IntensiGame – Framework for building entertainment applications and games. Provides a basic ‘engine’ for running a frame-based application and various video- and audio-related classes.

* IntensiTools – Very basic tools used for creating and working with certain resources.

* RunME – J2ME emulation layer for running J2ME apps with J2SE. Compared to ME4SE this is focused on providing a faster game canvas with real-time scaling and full-screen support.

* Galaxina – Partial implementation of a shoot em up game. Running on CLDC1.x/MIDP2.x phones and on desktop systems with Java.

I will have to update the projects quite a bit before they are really useful to someone else. Documentation is one thing. Library dependencies and license and copyright notices are a different story.

Filed by The.French.DJ at 8:23 pm under Development, J2ME, Java, Mobile
No Comments