In my previous post, I wrote about evaluating four Dart frameworks to see if any of them could replace my current Dart + Grails concoction. Well, the short answer is yes, I did that and a little bit more. How does one get from “how does this work” to a rewritten version of Web Dungeon? Whoops, got straight to the finale and skipped the beginning and exposition bits.
Backing up a bit, I will start at the beginning – “Once upon a time there were four MVC frameworks…”.
The best short description of AngularDart is “an MVC framework for the browser”. To quote from their website:
“Angular brings traditional server-side services, such as view-dependent controllers, to client-side web applications. Consequently, much of the burden on the backend is reduced, leading to much lighter web applications.”
The documentation was good and the way they implemented MVC is very similar to Grails and Ruby on Rails, so that got a thumbs up from me. What Angular did not solve was how to serve the pages for me. My app is not a single page app, at which Angular excels, so ultimately I decided not to go with it. I will keep it in my mind for future work, as I liked it very much and it has heavyweight support from Google. I know Google has been known to abandon things (Google Wave and Buzz anyone?) but still, its better than many small projects which run the risk of being orphaned at any time.
This framework originated from a collection of blog posts and as part of a book on Dart (Dart for Hipsters). It seemed OK, but there was not a lot of documentation and appears to be not maintained too actively (last update was 5 months ago). So I gave it a pass.
PureMVC is an ambitious effort spanning many languages, of which Dart is just one. There is plentiful documentation, unfortunately a lot of it conceptual, with plentiful examples in Java and other languages. After thirty minutes of reading, I decided that PureMVC was too ‘big’ for my brain. All I wanted was a 50 line demo of Hello World in Dart with a Controller and some basic tags – not an encyclopaedia. I wish I could have found a page titled “PureMVC in 5 minutes”, complete with super simple examples for each language. After some floundering about, I pulled the plug. So PureMVC is a pass for now.
Finally, here was Rikulo Stream. Nice website – tick. Examples – tick. Last code commit 22 days ago – tick. Hmm, this one started to look promising after the first 2 minutes. When I took a look at the Hello-MVC sample, my care factor started to increase rapidly. It appeared simple and easy to get working. It was. The tire-kicking phase completed successfully, time for a test drive. I set myself the task of building a simple website over a few hours to see what Rikulo felt like in real use. That’s when things went a little crazy… I started firing on all cylinders by the second hour and by the fourth hour, I had started rewriting Web Dungeon in Rikulo Stream. By the next day I had a working port of Web Dungeon running on Rikulo Stream. Crazy, but a good kind of crazy. I had a winner, and a new website to boot! Now that’s a demo.
It wasn’t all peaches and cream. I did ditch a few things along the way. The new site abandons all attempts to look like a game. No more bloody letters or dungeon wall tiling. I’ll do that later, when I am closer to a finished product. More seriously, I have not ported the account login feature or SSL support, because I have ditched the database as well….
What – No Database?
After some google-fu, I realized that Dart did not have the database support I was interested in (H2). After being spoilt by ActiveRecord in Rails and Hibernate in Grails, I had zero enthusiasm for writing my own database connector. That would have been one serious digression from ‘let’s build a game’. Then I thought – stuff this, why do I need a database anyway? Why can’t I use YAML – my current pet data format? So let’s write down the kinds of things I need to keep track of:
- Player details – alias, email addresses, passwords
- Player characters and and their current play state
- Dungeon data and maps
- NPC and monster definitions
- Equipment definitions (e.g. Sword of Wisdom)
Jedi Mind Trick =>This is not that hard. I can do this with YAML… <= Jedi Mind Trick
The day I need to run queries like “List all the fighters who defeated the Feral Hamster with the Pencil of Doom in less than 4 rounds” – is the day I can afford to hire minions to do this for me. With Dart version 10.0 and DartUberODBC v4.0.
Done. Database 0, YAML 1.
The process of evaluation of the Dart MVC offerings, and various other libraries has made me GitHub’s newest involuntary evangelist. I am sure I have landed on their page about a hundred times over the last few weeks. My workflow seemed to be:
- Google Search Project X
- Click search result for Project X Home Page
- Land at GitHub again
- Stare at impenetrable source code
- Goto to Step 1 with next candidate
After a while, every time I saw a Github page exhorting all and sundry to ‘fork me’, what I really wanted was to stick that fork in someone’s eye. Not yours, because you are too sensible to use Github as a project website. I consider going to cloud repositories like Github as a last resort. If I need to look at someone else’s library code, something is desperately wrong in my world. I spend 99% percent of my googling time looking for solutions to problems, and I never, never, never, never want to look at code. I don’t care what’s under the hood. I have enough stuff of my own to keep track of without poring over someone else’s. So I always go for the ‘plug and play’ rather than ‘compile and pray’. That’s just me. When you spend a typical day trying to solve half a dozen problems in rapid succession – looking at someone else’s library code is almost always a big fail.
Forget Github. Set up a real website. Write up some idiot-proof demos,examples, exercises for the reader – whatever. Somewhere on the home page, add a short paragraph or list about what your library is good for. Even better is a short paragraph or list of what your library is NOT good for. API documentation is not documentation. Nearly always it is auto generated and consists of insightful tidbits like “returns name” or “set the status flag to zero”. Some serious WTF moments right there.
You need simple, ‘any idiot can get this working in 5 minutes’ samples, because I am that idiot. Don’t assume that every idiot will understand what you did and why, because I am that idiot. That’s why I ‘m downloading your stuff – either I cannot do it myself in time or don’t want to spend years relearning what you already know. So this idiot is grateful for your efforts when you distill your 10,000 hours of expertise into a single ‘Press Here’ button. Just remember that I need help to get your stuff working – because I am not you.
The Road to Hell is Paved with Good Intentions
I am convinced this originated by an programmer who travelled back in time and got rich by playing the stock market. Never have truer words been uttered about so many smart people, wasting so much time.
If you have read any of my previous posts you will get the idea of how far you can digress from your goal, if you follow logic blindly.
My own goal of building an online game has already led to the following “excursions”:
- Building a sprite animation tool in Java Swing in 2014! (I was in a hurry)
- Building a Dungeon Map Editor
- Replacing Grails with Rikulo Stream
All of this from someone who considers himself “focused”. That’s why a lot of hobby software projects can get into trouble, spiralling down into digression hell:
“I need a hammer to hang my picture frame.”
“Nobody makes them so I will make one myself.”
“I need to learn how to make steel.”
“Where do I get iron ore?”
“I found an iron mine going cheap and bought it.”
“Mining is harder than it looks – I need a geologist.”
So there you have it, from hanging up a portrait of your mother-in-law, to geology, in 5 easy steps.
This is the kind of thing I try to avoid at all costs. The hardest part is knowing how far down the spiral to go. Is the answer just around the next bend? Or do I give up and try something else. This is one of things you get a feel for after ending up in hell a few times, and often comes down to intuition.
When I ran into issues trying to add the dungeon editor to the grails version of Web Dungeon, a red light went off in my head and I ended up ditching Grails for Rikulo.
When I ran into issue after issue trying to split the web dungeon project into lots of small libraries – widgets, resources, rendering – the red light went off again. What worked well in Java did not work well in Dart with Intellij. Managing dependencies between all these little Dart libraries and adding them to final web dungeon ‘master’ project was not working. So I moved everything to a single Dart project. Suddenly things got simpler instead of harder. All my issues fell away and the path was clear. My pace accelerated and the warm fuzzies returned. I finished a few hours later. Maybe there is a way to manage multiple small Dart projects with the current state of the Dart SDK and Intellij. Maybe there isn’t. I could not get it to work – so I ditched it. I went with my intuition, which told me that it probably wasn’t me, but the tools. The single project works well, is easy to manage, and the messy bits I can live with.
Done. Next task please.