Java Application Architecture

oktober 2nd, 2012

Kirk Knoernschild’s book, Java Application Architecture: Modularity Patterns with Examples Using OSGi, ought to be made superfluous, but as it stands it is direly needed.

At least the first two parts: “The Case for Modularity” and “The Patterns” should be known by heart by any Java developer. It should be second nature for disciplined and professional developers.

In “The Case for Modularity” Kirk goes over the definition of what a module is, whether architecture is a phase carved in stone in the beginning of a project, or whether it is pervasive and should be attended to all the time.

How growing complexity must be countered by disciplined maintenance.

Why Technical Debt and Design Rot must be cleared to keep the source code from succumbing to the development death spiral.

Why cyclic dependencies must be rooted at all costs.

And what the benefits of modular structures are.

While you may think that a given piece of software is not ripe for modular extraction, because it will never be replaced or reused elsewhere. This is not the right attitude, as the first or second use of the source code is the test cases preferably developed in sync with the source code, either in a TDD or BDD way. It is simply easier to unit test a unit, no matter how big that unit is.

Finally – just to prove that this is not hot air preached from the pulpit – Kirk refactors a small application in 7 steps each a tiny isolated step improving on the overall structure. This is how software should evolve once it has fallen prey to design rot.

The second part of the book, The Patterns, describes 18 patterns in 5 chapters, which Kirk has made available here:

The Base Patterns:

  • Manage Relationships
  • Module Reuse
  • Cohesive Modules

Dependency Patterns:

  • Acyclic Relationships
  • Levelize Modules
  • Physical Layers
  • Container Independence
  • Independent Deployment

Usability Patterns:

  • Published Interface
  • External Configuration
  • Default Implementation
  • Module Façade

Extensibility Patterns:

  • Abstract Module
  • Implementation Factory
  • Separate Abstractions

Utility Patterns:

  • Colocate Exceptions
  • Levelize Build
  • Test Module

The third part concludes with examples in OSGi, covering Java, Scala, and Groovy implementations.

The book is a must read and must understand for (Java) developers and architects.

I highly recommend the book for anyone interested in modularity, especially developers looking at an existing code base resembling a big ball of mud who wants to disentangle it.

Posted in books, programming | Comments Closed

Pragmatic version control using Git

september 20th, 2011

Written by Travis Swicegood published by The Pragmatic Bookshelf, 2008, ISBN-13: 978-1-934356-15-9

At 184 pages this is a short book on Git, but it does cover the bare necessities and then some. Apart form 3 appendices the information is added in 11 chapters:

  1. Version control the Git way
  2. Setting up Git
  3. Creating your first project
  4. Adding and committing: Git basics
  5. Understanding and using branches
  6. Working with Git’s history
  7. Working with remote repositories
  8. Organizing your repository
  9. Beyond the basics
  10. Migrating to Git
  11. Running a Git server with Gitosis

While Git is more complex than the book can explain – and it doesn’t try to explain everything, it is pragmatic after all – I would say it covers the Pareto 80% of the standard user’s needs.

Following the Pragmatic tenor the book does the job of demystifying Git without attacking Subversion or CVS – or any of the other distributed version control systems. Chapter 10 handles the issue of migrating from SVN or CVS (via SVN) to Git.

As a side note to this, I would add that I think filesystems are stupid in the sense that they ought to have changed to transaction based systems at the time disk space was sufficient for this kind of storage, and that the ‘save’ button in every application ought to simply do something akin to a Git commit. IMHO the snapshot way we currently use is simply stupid.

While there are some nifty tricks you can do with Git with regards to the history I think it should be mentioned that these tricks are better left only for your personal branches and not for a shared commit. That is, it is okay to modify the order and squashing branches before you push or allow others to pull.

It’s kind of funny that the single biggest benefit of using Git – as I see it – is the personal revision control, and that isn’t mentioned in greater terms, though Travis does mention the benefit when he was working with a Subversion repo – see the box “Being the Git: Using Git in a Subversion Company” on page 141.

I would have liked to have seen some recommended workflows for different setups as well as some developer discipline guides, i.e. branch before you do anything new, have a working solution you’d like to be able to return to? Commit! Even after a working unit test.

The book is a fast and okay-to-good read.

Posted in books, programming | Comments Closed

Building and testing with Gradle

september 7th, 2011

Written by Tim Berglund and Matthew McCullogh published by O’Reilly, ISBN: 9781449304638

The only book out there on Gradle, and it is relatively new published July 2011. At 110 pages it is rather short, and doesn’t cover everything about Gradle – it’s not a ‘Complete guide to Gradle’, but the 6 chapters cover the basics in the obvious ways:

  1. Hello, Gradle!
  2. Gradle Tasks
  3. Ant and Gradle
  4. Maven and Gradle
  5. Testing with Gradle
  6. Multiproject Builds

The book does provide pointers for migrating from e.g. Maven to Gradle. As I’m not intimately familiar with neither Maven nor Gradle, I can’t really say if it is sufficient to jump from Ant directly into Gradle, or if a quick pit-stop in the Maven (3?) camp is beneficial.

There are a few kind of typos in the book, e.g. Example 1-5 the src directory seems to be a subdirectory of the build.gradle file, this is fixed in Example 1-6 though.

There’s also a minor issue with the doFirst() method – I’d suggest saying that this would prepend or prefix the closure to the existing block as opposed to saying appending to the beginning.

The book is more concise and better organized than the Gradle user guide which seems to do a halfbaked description, then referring to a later chapter.

Running some modified examples from the book – not from the github repository – I experienced a rather detrimental blow up when applying the plugins for Scala and Groovy. The compiler dependencies need to be added to the build file.

Being the only book on the subject it’s sad that it’s not a Complete Guide, but it does fulfill what the title promises, it’s just not enough. An okay read though.

Posted in books | 1 Comment »

Drive: The surprising truth about what motivates us

juli 24th, 2011

Finally I got to read Daniel Pink’s book: Drive.

It’s a good book, but as someone mentioned you could get a long way with just the talks he has been giving. Nevertheless, the book tells a few truths on the problems with the conventional wisdom popularized by Taylor early in the 1900’s. Assuming that Taylor was wrong – and I must say that I didn’t need Pink to convince me of that, but it’s good to know that I’m not alone in this assumption – what could be a more fitting motivational approach for the 21st century’s workers, the creative minds?

Autonomy, Mastery, and Purpose.

Autonomy in what you do, when you do it, who you do it with, and how you do it. As long as you do whatever is needed and in a timely fashion.

Mastery – you will never achieve it, as you can always grow and become better at what you’re doing. Mastery requires the pursuit of the better self.

Purpose – we need a reason beyond Maslow’s needs for doing what we’re doing.

Pink tells us about the Intrinsically motivated (I) and the Extrinsically motivated (X) people. Which kinds of tasks can be seen as fit for extrinsic motivation, e.g. payment, and why something may be better with an intrinsic motivation.

I’m not quite sure, how you’ll go by and ignite the intrinsic motivation for everything, but it sure sounds like a good idea to drill down to the core and find the intrinsic motivation to get going.

Of course, we get the mention of Mark Twain and Tom Sawyer’s whitewashing of Aunt Polly’s fence.

Who should read it?

Anyone! But especially parents, teachers, leaders, and managers.

Posted in books, gamification | Comments Closed

Gamestorming

juli 24th, 2011

Gamestorming is a really nice collection of different games to play during a brainstorming session, or any other meeting requiring some different attack vectors – sometimes just to keep the meetings fresh and interesting.

The collection is a diverse set of different games ranging from short time, few people to long time, a lot of people.

Most of the games don’t require more than pens, post-its, and flipovers or whiteboards.

If I was to have more meetings than I’m currently involved in, and if those meetings were with collocated participants, then I’d love to use some of the games listed in the book.

Some of the games make me think of ‘The back of the napkin’ by Dan Roam (an excellent and inspiring book), and some of the games make me think of Esther Derby and Diana Larsen’s book: ‘Agile Retrospectives’ Needless to say that some of the Gamestorming games would fit a retrospective perfectly.

In this digital age, it puzzles me that I haven’t seen a plethora of utility software for this kind, e.g. a best match for meeting and games. But then, I may not have been looking.

The book is organized into 8 chapters:

  1. What is a game?
  2. 10 essentials for Gamestorming
  3. Core Gamestorming skills
  4. Core Games
  5. Games for Opening
  6. Games for Exploring
  7. Games for Closing
  8. Putting Gamestorming to work

So, who should read it?
Well, anyone participating in sufficiently many meetings where people tend to get stuck or wants to try a different approach. There are different ways to hold meetings.
Meeting leaders looking for a different way to motivate people, or perhaps to get a different kind of action.
Consultants, project managers, …

Posted in books | Comments Closed

Gamification by Design

juni 17th, 2011

The book starts out with what has become Gabe Zichermann’s
standard take on Gamification, and with good reason, as it covers
the basic introduction to the subject, as well as some of the
conundrums, thus we pass by:

  • Broccoli
  • Where in the World is Carmen San Diego
  • Greenstamps
  • 10:1
  • SAPS
  • Project Runway vs. Deal/No Deal

We get a short introduction to Flow by Mihaly Csikszentmihalyi,
operant conditioning, Skinner boxes, Bartle player types, and why
people play. These are fundamental things for people in games not
just for people interested in gamification.

I don’t quite get the linear level description:
[PDF] Page 49 “In game design, level difficulty is not linear. In
other words, level one is not half as complex as level two, which is
not half as complex as level three, and so on. Instead, difficulty
increases in a curvilinear form.”

As I read this, then the description says:
lvl1 = 1/2 lvl2
lvl2 = 1/2 lvl3
but then lvl1 = 1/4 lvl3 – this is not linear but a power function:
lvl n = 2^(n-1) lvl1

Which is quite similar to the D&D and AD&D level progression tables, and curvilinear to boot. That said, it is an ‘Early Release’ and it could be fixed.

Then we get to Leaderboards and Badges – the “ooh, I think we can do that”-slap-on and call it Gamification that a lot of people are saying is “the only way” of doing gamification for anything and everything. That is not Gabe’s way of doing it, but as the book is a sort of cookbook, it seems stupid not to touch upon the subject.

The Ruby implementation of a point scoring forum I could live without, but – again – it would seem weird to have a cookbook without examples.

There’s an introduction to Bunchball integration including some rather useful tips on what to be aware of when designing.

The big hit, I would say, is the sadly brief coverage of the virtual economy, this time using BigDoor as an existing API vendor.

All in all: Yet another “required read” by Gabe Zichermann and Christopher Cunningham

Posted in books, gamification | Comments Closed

The shortest path is rarely the smartest.

juni 4th, 2011

As Einstein said:

“Everything should be made as simple as possible, but not simpler.”

Even so, we – as software developers – tend to skip corners for the sake of delivery or to appear productive. We ought to know better, we ought to know that, e.g. unit testing improves on the quality of code produced, yet still we keep on thinking that that’s crossing the stream to find water.

If we were to live our lives using the same daft assumptions, then we’d either tie our shoelaces only using the uppermost holes, or – being programmers – use the traveling salesman’s solution, visiting every hole in the shortest path possible, in essence making a simple loop. Neither of these fulfills an adequate shoe lacing.

The simplest working shoe lacing is the American style – the zig-zag we’re familiar with from sneakers.

different simple lacings

different simple lacings

So is the issue that we don’t see the problem, and therefore there is no problem? Are we simply ignoring the problem because we think it’s a trivial thing? Are we simply not aware of the fact that other possibilities exist? Or are we going as simple as technically possible without seeing that it’s simpler than logic and sensibility should have required?

Event Based

Instead of simply hard wiring the code to do our bidding, it is often more reusable and perhaps more interesting for other developers to build on top of what we already have. This is often the reason for providing APIs. But APIs only do so much, they are reactive parts not really proactive, and as such – being a one direction service – are providing less usefulness.

The most often used notion of bidirectional systems is event based, or some other form of publish/subscribe. Usually this isn’t prevalent in standard code – probably because as a developer you think you know all the possible uses of the system. You have high coupling because the code is assimilated into, well, the code. Sometimes this is fine, sometimes it is not. Often it leads to God objects.

God Objects

God objects are the objects in which you put everything and the kitchen sink, and they are used all over because they are just so useful. Often they consist of thousands of tokens and every conceivable method, e.g.


boolean isSet(Object o) { return o != null; }

Besides stupidity, they often scoop up any utility functionality often just because the object is included anyway, and it seems that simply adding one more function wouldn’t matter, and the bother of creating a new class in a new file simply doesn’t seen to be worth the bother. Thus you end up with an object capable of formatting time, currency, chopping text, html, etc. Some of it is redundant since newer JDK versions, but tidying up never seems to be touching the God object – it’s in use so many places that the workload of altering one method would propagate to hours of work fixing the dependencies.

God Package

Sometimes the God object has an evil cousin: The God package. This is a package where there’s no real connection between the objects in the package, but apparently the cut is difficult to make – or deciding upon a fitting sub-package structure is not a worthy cause. God packages ends up with more than a few hundred classes, some even reaching several thousand classes.

But then, there are other issues such as taxonomy failure, where we believe that if we can just get the right system from the start.

Taxonomy Failure

At some point everyone tries to file a set of items according to one taxonomy system or another. Whether it is e-mail by sender, movies by category, music by album, artist or genre we almost always end up with a broken system. That’s because we’re trying to generalize something, which ends up not fitting into the generalization. Then we start with exceptions to the rules, then exceptions to the exceptions.

E.g. all birds can fly, except ostriches, emus, and cassowari … but these can run rather fast. Except penguins! Okay – if the animal has a beak, it’s a bird, except tortoise and platypus.

We’re always trying to fit things into tree hierarchies, and they rarely fit – most likely because the tree is the simplest graph.

“Stupid is as stupid does” – but stupid is also not fixing the discovered stupidities of old – yes, this may end up in circles where you later learn than something seemingly stupid was done, but that there was a very good yet undocumented reason for doing so. It’s all about (in)competence levels.

Tags:
Posted in programming | Comments Closed

Gamebased Marketing

marts 12th, 2011

One of the ‘need to read’ books on gamification. The book may seem average and simple, but it is nonetheless worth a read. For anyone serious in the gamification business it is a required read.

The book provides a set of steps for starters into gamification under the premise that gamification should not have to cost the provider any money.

While some of the advice given seems elementary it is still important to follow or at the very least be aware of, e.g. Barrier to entry.

There are a few elements which seem rather American – and I don’t see a way to make this generally acceptable for any culture.

There is – in my mind – no doubt that Gamification will influence our lives in the future. I can’t wait for it to be introduced at a political level.

Gamebased marketing is not about sugaring marketing campaigns, it’s about making playable games first, then tie in the thing you want end users to do.

Posted in books, gamification | Comments Closed

Cows in the Maze

januar 31st, 2011

– and other mathematical explorations

21 chapters of mathematical recreation. Usually I find the professors books rather entertaining, but I must say I’m feeling a bit disappointed about this volume.

It’s off to a good start with “the Lore and Lure of Dice” – the context specific reflection on the question of probability, and the non-transitive dice. Then quickly passing Piet Hein’s board game Hex.

Why we’re introduced to Tarzan and Jane in the midst of an otherwise interesting subject, “Walking with quadropeds” – the patterns of the gaits of four legged animals, I have no idea.

Chapters 7, 8, and 9 touches upon time travel, which – as I recall it – is much more physics and sci-fi than mathematics. Luckily though chapter 10 serves a nice gem – Cone with a Twist – the sphericon.

Chapter 11 touches upon the shape of a drop, and in chapter 12 we’re back to probability and fallacies in The Interrogator’s Fallacy, where we now use Bayes’ theorem and Mathews’s formula. There’s an error in the formula printed on page 173 at the top though, it should be:
P(A|C) = P(C|A) * P (A)/ P(C)

Then we get to the title chapter: Cows in the Maze. And while it has cows and is kind of a maze – it’s not a standard maze, it’s a maze of logic statements.

Leaving the maze on a Knight’s Tour into Cat’s Cradle over Klein bottles (and Möbius bands) into Voronoï celled craters into knots, which again I found a bit disappointing.

The construction of Most Perfect Squares are matched up with Mathematical impossibilities.

The final chapter of the book regards dancing with strings forming regular solids.

Posted in books | Comments Closed

Gamification

januar 23rd, 2011

The idea to use game thinking and game mechanics to solve problems of any kind, raise moral and put an incentive in the hearts of players – which is all of us. It’s funny seeing dogs being trained using quite similar methods.

Games work if they are fun and enticing, but they mainly work for the purposes for which they were built: Entertainment. Sometimes, though, they have a positive side effect in that they actually make the players learn something, if not useful, then at least meaningful. That’s the Mary Poppins notion of “a spoonful of sugar makes the medicine go down.”

Games have been used throughout the ages as means to both entertain and educate – and they do that in an abstract world. The main reason for the sudden hype of gamification is that with internet connected devices we do see a much lower barrier to entry, and the possibility to pick up the game anytime anywhere.

Remove barriers to entry. Automate any mechanical tasks

Taking the card shuffle out of Solitaire or Patience games – or Poker for that matter – doesn’t improve on the gameplay as such, but it makes it a lot easier to pick up the game as well as play it.

Games can be anywhere

It doesn’t have to be a game – it could just be playful behavior, e.g. the VW initiative The Fun Theory – I’m thinking about the Piano Staircase, which reminds me of the piano floor in the 1988 movie “Big” starring Tom Hanks.

Many things are possible if the right idea and implementation arises. Be inspired try out some ideas for yourself, test and tweak them. Dive into the psychology behind predictability of people, the choices we make, and what really drives us.

Posted in gamification | Comments Closed

« Older Entries
Newer Entries »