I need to cover some of my “blog debts”. Just didn’t around to persist my other Jazoon notes.
On Thursday afternoon Terrence Barr one of Sun’s Java ME evangelists gave a talk on “Developing Java ME applications using Sun’s open source platforms”.
Said but true, what I mostly remember is Terrence’s rush through his slides. He mentioned in the beginning that it was gonna be tight (time-wise) as the sessions at Jazoon are 10 minutes shorter than at other conferences. Be it as it may, can’t I expect a speaker to prepare accordingly? After all he seemed to have noticed beforehand that time constraints are different. You can’t just take your standard PowerPoint slides and squeeze them into a much smaller time box. As a listener I felt being served luke-warm Java.
Hot was the topic, though. Open-source Java ME is appealing. As I’m a novice to the Java ME world I’ll have to dig deeper to see what it can do for me. http://www.mobileandembedded.org will see me soon!
As a share holder of a major provider of commercial Java implementations for mobile devices I’m also eagerly following the market share of Sun’s open-source alternative…
Later that afternoon Simon Hefti, managing director of Zurich-based Netcetera AG, gave us an insight into what he calls “artificial complexity build-up”. He started with wonderful analogy for the problem:
Assume you bring in your car for maintenance. A few days later you’ll find yourself looking at a horribly high invoice although only a minor part in the engine had to be exchanged. However, since the faulty component was buried so deep down in the engine it had to be taken apart completely.
Artificial complexity imposes extra constraints on a problem solving process as it does not allow you to proceed straight forward. The problem itself may be easy to solve, but the context in which it lives makes it difficult. One key issue here is that weakening separation of concerns increases artificial complexity. This is true not just for the software industry. Simon talked a great deal about choices we make in terms of (third-party) components we bring into a software project. One might call this artificial complexity, of course; however, one might just as well speak of dependencies that complicate matters – something every developer will agree upon.
For a given set of desired functionality component A might cover 75%, component B another 20% while overlapping with what A does in certain areas. This still leaves you with 5% missing features although you’ve already introduced two external dependencies. Nonetheless, sometimes the bad boys are inside i.e. your own code. Simon cited from a study that showed that in more than 50% of cases where developers tried to anticipate future requirements and prepared accordingly (e.g. over-engineered or overly flexible APIs and thus increasing complexity) they were wrong.
Of course, there’s no generic solution to that, but raising awareness certainly helps. KISS!
Comments Off on More Jazoon coverage
Sun SPOTs are incredibly cool sensor devices produced by, well, Sun Microsystems. They seem to have a real momentum right now.
At Jazoon in Zurich Sun’s Simon Ritter gave a top presentation about the SPOTs in general an fed us with some background info. Since I’m working on my own SPOT application it didn’t come as a surprise that much of it wasn’t new to me. Nonetheless, I learned that the Sun Squawk J2ME implementation was started as a totally independent project and that it should be easily portable to different mobile devices as its native layer is very thin. Also, I knew it but wasn’t fully aware that I can have several applications running on one and the same SPOT in parallel. The fact that a SPOT contains several boards that serve separate purposes underline that they were built with extensibility in mind. Simon demonstrated how to control a Looking Glass user interface with a P5 Data Glove. It wasn’t quite like what you might know from the “Minority Report” movie, yet.
What I don’t get though, is why Sun stresses that SPOTs can (and should) be used for real-world applications. Yet, all they ever present and demonstrate are toy-related “fun products”. Good for nerds, but not so good for management making decisions.
Ergon had a dual-player Arkanoid application with the two bars controlled by Sun SPOTs tilted left/right. It’s fun to play, but takes some time to get accustomed to the responsiveness of the sensor application. I want to build that, too! It shouldn’t take too long to turn a regular mouse-controlled Arkanoid implementation into a SPOT-controlled toy.
Comments Off on Sunspotting at Jazoon
Yes folks, I’m at Jazoon currently. And while at it I thought I could persist my impressions in this blog. Why not share my notes with the world? After all, this is what blogging is all about – in a way at least.
The talk “Model-driven architecture with MDA“ was presented by two engineers from ergon AG. They presented their accumulated experiences from a real world project. While one can find loads of information about MDA as such, it was interesting to hear about hands-on experience. Since I got my own fair share of MDA stories and since those experiences made me somewhat reluctant to howl with the MDA-is-so-great wolves, I was keen to learn if it can be done right easily. A few things that I picked up:
- AndroMDA seems to like certain UML tools better than others. Magic Draw was used in the project presented because it was recommended by AndroMDA. I learned the same the hard way when we migrated from one modeling tool to the other. The XMI dialects can be quite different. Watch out for that! There’s a fair chance that you’ll have vendor lock-in there.
- Since AndroMDA uses the concept of “cartridges” (that’s what they call their plugins) the generated code can be based on any application framework. ergon generated code for Spring and Hibernate for example with the respective cartridges. Since those cartridges are extensible it should be easy, the said, to write your own.
- One major aspect of generating code is protecting those code sections you augmented yourself after generation. You don’t want that a subsequent generation run overwrites your own code. We used to have specially marked protected code sections the generator would not touch. According to the presenters AndroMDA seems to have an issue with this. It generates abstract superclass and dummy implementations for each abstract class. You’re then expected to fully implement the generated subclass. AndroMDA won’t touch those again. However, if your interface changes (resulting in a new abstract class) you have to push down those changes to the implementation class yourself. Or throw away the implementation class and have AndroMDA generate a new dummy implementation that satisfies the interface. Ugly and error-prone.
- ergon seem to advocate to “breed” a new kind of developer. They call them “modelers”. Hard-core code junkies like myself are likely to get bored with their job if they rarely need to touch code anymore – as promised with the MDA approach. At ergon the same developers that would have hand coded the application were used to model and generate the application. It was said that they (only?) still had fun because everything was so new to them.
Comments Off on Jazoon: Model-driven architecture with AndroMDA