Earlier today I got this obsession of overlaying an aerial view of current day Helsinki over an old map from 1837. I had to rotate and skew the pic to get a better fit and here’s what I turned up with:
Check out the live version. It may work on some browsers (chrome).
I promised a publisher I’d review their book, Android Wireless Application Development (2nd edition), however, I tried doing a book review earlier and honestly it’s just a snooze to read; so I thought I’d write a blurb about tech books in general too.
In general these technical books suffer from a very common ailment, being big and boring – no normal people would read these tomes from cover to cover and enjoy it. There are some publishers which consistently publish enjoyable succinct reading; but a large majority still churn out heavy tomes which end up selling regardless of their content.
The subject has been covered in some detail.
Andrew Binstock wrote about Lax Language Tutorials not too long ago,
“These books are marked by common failings that greatly frustrate their simple mission. The first and by far most-common handicap is a confusion by the authors in which they conflate a tutorial with a detailed treatise on every aspect of the language. For reasons not quite clear, the latter approach seems generally favored by the publishing industry, resulting in almost ridiculous volumes.”
Philip Greenspun also touches the subject in his Dead Trees story,
“It is an article of faith in the computer publishing that bigger books sell better. They take up more space on the shelf and readers with a tech problem find a bigger book comforting. Readers aren’t really sure what is wrong with their computer and they only have a few minutes in the bookstore so they figure the thickest book is the most likely to contain the solution.”
Sounds plausible. I did a bit of googling about the myth of authors getting paid by the pages, but that seems to be untrue; although a thicker book might mean more sales which would mean there is an implicit motive to make your book as thick and heavy as possible.
So how does this relate to Android Wireless Application Development? Well at 791 pages (including index and everything) it certainly is thick, although it’s not the thickest book I’ve seen. There are much worse. I’d love it if these books would limit themselves to 300 pages, but preferably closer to 200 pages.
The biggest cardinal sin of Wireless Application Development is explained by the authors’ themselves in the very introduction:
“This book was written for several audiences:”
It goes on to list software developers, quality assurance, project managers and “Other audiences”.
I figure you can write a book for several audiences, but you cannot write a _great_ book which is suited for several audiences.
The tech books which have affected me the most, the ones which were of most educational value to me, have all had focus. They tended to a narrow audience which I was a part of.
In Android Wireless Application Development I found maybe 3 chapters out of 29 completely irrelevant; which isn’t that bad actually.
Then again this is a reference book first. Every chapter can be read independently of each other. There is no common thread from beginning to end; so you can just pick the chapters which interest you and read them; and this is definitely the way you should read this book. Thankfully most chapters jump straight into code examples which mostly get straight to the point.
It doesn’t go very much in depth into the more advanced subjects, but nor should it. It scratches the surface and lets the reader go online if it interests him further.
With 29 chapters this is certainly the way to go; although I myself would’ve maybe dropped some of those chapters, but at least it doesn’t leave any major subject unscratched.
It’s all in there.
I used this book as a head rest while camping for a week in Iceland; and at 791 pages it certainly worked well for that; but you’ll learn a whole lot more if you actually read some of it.
Good for the non-beginner Java dev wanting to learn Android development but also for intermediate Android developers who just need a reference book.
Just finished The Clean Coder 
Does it deliver? Yep. It might not be Clean Code good but still pretty damn good.
This book doesn’t really cover code at all but focuses on the coder, his behavior and on his methodologies. It tackles very many difficult issues in very few pages in a clear and concise way. To cover the ground Bob does in about 200 pages is a major feat; especially when he manages to sprinkle in a fair amount of amusing anecdotes from his programming career to support his arguments.
I may disagree on some points but in overall agree with more than 95% of the stuff anyway so I’m not going to nitpick. This is an easily approachable book and won’t last you many evenings. This should be on any apprentice, journeyman and master programmer’s must-read-list.
A Code of Conduct for Professional Programmers
Short description of each chapter:
Chapter 1: Professionalism – How to act like a professional. Surprisingly few coders know how to do this.
Chapter 2: Saying No – Say no to stuff you can’t promise 100% as trying and failing will just make people distrust you.
Chapter 3: Saying Yes – When you say yes you should mean it. Commit to the stuff and don’t give vague promises.
Chapter 4: Coding – When you should code, for how long and what to do about external forces affecting your coding ability.
Chapter 5: Test Driven Development - Arguments for TDD.
Chapter 6: Practicing – Tips on how to practice and keep up with your craft.
Chapter 7: Acceptance Testing – How to do acceptance testing.
Chapter 8: Testing Strategies - Explains how and what to test on different levels. The levels being depicted in a pyramid from the lowest layer to the top like this: Unit Tests, Component Tests, Integration Tests, System Tests and Manual Exploratory Testing.
Chapter 9: Time Management – How to get stuff done and how to deal with interferences and time thieves.
Chapter 10: Estimation – Arguments that estimates are always uncertain and should be communicated that way. Proposes several methods of doing agile estimation.
Chapter 11: Pressure – Keeping your cool and staying clean under pressure.
Chapter 12: Collaboration - The most common collaboration anti-patterns you might be guilty of.
Chapter 13: Teams and Projects – Arguments for that teams shouldn’t be split up after projects.
Chapter 14: Mentoring, Apprenticeship, and Craftsmanship - How apprentices should be mentored into journeymen.
Appendix A: Tooling – The minimum tool set you should at least have in use if you wish to call yourself a Professional.
I’ve been meaning to write a summary about the feedback I got to my post about being an amateur Android game developer. It was mostly collected from reddit comments, hacker news comments, and comments on the blog post.
If anyone was wondering if the post had any effect on downloads the answer is yes. It was the only marketing which clearly affected the download stats. However, as with traffic to the blog post, the effect was temporary. I guess if you manage to write interesting content regularly you could ride that wave better than I did.
So here are some points collected from the feedback, and some of my own subjective opinions reiterated from the last post now condensed in this handy list.
Great game concepts can be ruined by crappy presentation or bad user experience. If you don’t have artistic talent consider getting a guy to do the graphics for you. Ditto for musical talent.
You can really immerse yourself and feel the seriousness of those orders when they're given by Mr. Potato head.
Your game probably only costs a buck or so, so you’ll probably end up paying $10 to make a $1 in sales. It’s ok to do do cross-marketing however, e.g. between your games, which doesn’t cost you a dime.
On the 8th of October I paid 5.29e for 23 clicks. You're going to need some crazy conversion rate and a product which costs more than $1 if you're going to make that marketing money back
You want to risk annoying your players for a few measly cents? You can annoy them when you can afford loosing some of your player base.
That's a YEAR'S WORTH OF AD REVENUE from Theseus. It's all gonna go to finance my extravagant lifestyle. I'm practically rolling in moolah.
Sometimes it’s just how the stars are aligned. Sometimes your version just sucks.
You may have the first pacman on some device, it still might not make a difference.
I have simply not found any other easy marketing technique to be as effective.
Visitors to Theseus. Each one of those peaks coincide with an update to the game.
Chances are it will never make any substantial sales, so treat it as a hobby. Those cinderella stories about devs striking it rich are just that – cinderella stories.
Just me and my computer on a Saturday night hacking away. Fun.
Check out AndEngine for instance. You’ll save a bunch of time.
Thanks Clippy!
It’s not going to make much of a difference but people who don’t know about your game can’t buy your game. Btw. download Theseus and the Minotaur.
Poor applications working for their pimpin' developers.
You’ll want statistics about your game usage.
That's a black box. That's how much insight you'll have about your game usage without in-game analytics.
Old players of your game are your best source for word-of-mouth marketing. You can achieve better retention by for example adding new levels regularly. In free versions if you don’t want to add more levels you could for example switch which levels are available for free to re-activate old potential customers.
Word of mouth marketing in action. The tobacco industry has great retention among its consumers.
If your game doesn’t have characters consider adding some and make sure they have some personality and are memorable.
The marketing-droids at Nintendo knew what they were doing when they unleashed this yellow cretin upon the world
Your first game is probably gonna be a dud. If your game doesn’t seem to be picking up and developing it is become a chore, then just cut your losses and move on to the next project. The more games you make the better, faster, leaner and meaner you will get.
It's the episode of Lucy when she was working in the android app factory.
A role playing game is going to need a lot of story and a lot of graphics, and a lot of your time. A game in which the player tries to beat his own high score won’t be infinitely time consuming and might still be a bigger hit.
Developer, choose your fate!
Thoughts? Go ahead and comment.
Back in February of 2010 I was coding in the offices of our customer – a semi-big Finnish company. It was interesting from a technical perspective, but the project had changed directions about half a dozen times in the past 6 months. I guess it lacked someone with some backbone to lead it according to one vision. Instead they were bending over to anyone with an opinion and we had a veritable software Frankenstein on our hands. Despite being a neat programming challenge the product itself was a mismanaged collection of random features in which my own faith was close to zero. It’s at times like these you start looking elsewhere for something that would bear more meaning.
I’ve done my own random software projects now and then and the last few years my interest had shifted to products that could make some dough. I had often taken ideas to the implementation stage, but most of these projects ended up fizzling out due to lack of motivation, becoming cute tech demos in the corner of my hard drive or in a forgotten code repository. In spite of that I was getting that urge to create something of my own again.
I had read about the fortunes some lucky developers had managed to make on the AppStore, but the real gold rush seemed mostly over. On the other hand the Android platform was gaining traction and it had a serious lack of fart applications; and I reckoned those fart applications needed developers. I had a crappy old Symbian based Nokia phone and thought it might be time to get one of those new fangled smarty phones. The iPhone was only available from one operator (not mine), and developing for it required a Mac, which was an even steeper investment. This made me hop on the Android bandwagon. I ended up scouring an auctioning site for an HTC Hero and on the 28:th of February 2010, I had the winning bid on a white HTC Hero. In the beginning of March a package of used mobile electronics had arrived much to the glee of a new owner.
The horse sticker wasn't included. I had to accessorize it myself.
Soon even your grandma will be ruled by a smart phone overlord
I played around with the Hero – and compared to my Nokia it was night and day. I came to the conclusion that these smart phones were going to be our overlords very soon. We’d be fiddling with these buggers updating our tweetbooks, fouring our facesquare, reading, chatting and playing on the go. In fact I concluded the gold rush was far from over, it was merely beginning. It wouldn’t be over until most people were conducting most of their online time on their phones. I don’t know where we’re now, but if we’re not there yet I think it’s pretty safe to say we’re getting closer.
View full article »
Google has enabled more detailed statistics for all android applications.
There’s a Statistics link just below the download and active installs numbers which will open up a more detailed statistics view.
Seems like they started collecting data after mid-december because that’s how far back the statistics for Theseus goes.
So a week back I released a major upgrade of Theseus with new graphics. The hypothesis was that the old “characters” didn’t have enough character, so players couldn’t relate to them in any meaningful way, and that the new more lovable Theseus and the now meaner looking Minotaur would engage the player more.
I never really figured I needed characters, since I classified this game in the same genre as chess or some such. Chess usually doesn’t have real characters (which laugh or cry). Then again Theseus is a bit less known than chess (just a hint). Having good characters shouldn’t at least take away from the game.
After a week I haven’t seen any difference in downloads, but maybe a slight decrease in bounce rate. The people I asked liked the direction of the new graphics and no one has complained thus far.
Old
New
To see more just check the screenshots on android market
I couldn’t find any complete tutorial on this and wasted a couple of hours figuring this stuff out.
So here you are, hopefully it’ll save you some time.
JDK5 introduced the APT (Annotation Processing Tool).
It was part of the sdk but the classes were part of the unofficial com.sun.* namespace, and you had to use the “apt” tool to process the source code.
JDK6 cleaned up the api and integrated this stuff it into javac itself so you didn’t need to use the separate apt tool anymore.
Apparently built for processing source code with annotations before they are compiled into classes, it can also be used for all kinds of fun like code generation and code analyzers which are IDE independent; and you don’t even need to use annotations necessarily. I think the JPA2 meta-model used in its criteria api is implemented with this.
I made one very contrived example of java6 processor usage with Eclipse. All of this is possible to integrate into a maven build but I’m leaving that out and focusing on how I got this processing to work within Eclipse.
So we’re creating a processor which will generate a new class for each class in projects compiled using this processor. Additionally we’ll create a Warning for each class which starts with a T. Yes it’s silly.
SillyProcessor.java:
@SupportedAnnotationTypes(value= {"*"})
@SupportedSourceVersion(SourceVersion.RELEASE_6)
public class SillyProcessor extends AbstractProcessor {
private Filer filer;
private Messager messager;
@Override
public void init(ProcessingEnvironment env) {
filer = env.getFiler();
messager = env.getMessager();
}
@Override
public boolean process(Set elements, RoundEnvironment env) {
for (Element element : env.getRootElements()) {
if (element.getSimpleName().toString().startsWith("Silly")) {
// We don't want generate new silly classes
// for auto-generated silly classes
continue;
}
if (element.getSimpleName().toString().startsWith("T")) {
messager.printMessage(Kind.WARNING,
"This class name starts with a T!",
element);
}
String sillyClassName = "Silly" + element.getSimpleName();
String sillyClassContent =
"package silly;\n"
+ "public class " + sillyClassName + " {\n"
+ " public String foobar;\n"
+ "}";
JavaFileObject file = null;
try {
file = filer.createSourceFile(
"silly/" + sillyClassName,
element);
file.openWriter()
.append(sillyClassContent)
.close();
} catch (IOException e) {
e.printStackTrace();
}
}
return true;
}
}
Without creating this META-INF entry I couldn’t get the processor to register in Eclipse.
META-INF/services/javax.annotation.processing.Processor:
com.kerebus.annotation.processor.SillyProcessor
Its only contents is the name of the Processor implementation. I guess you might be able to list several processors here, although I’m not sure.
That’s it. Now export it as a jar and use that jar in other projects where you wish to use the processor.
In the properties for your new project go to Java Compiler -> Annotation Processing
Check the “Enable Project Specific Settings” and make sure “Enable annotation processing” is checked. I also changed the generated source directory to a name which didn’t start with a dot so it wouldn’t be hidden in the package explorer (files or directories which start with a dot are by default filtered away in eclipse).
Next off go to Java Compiler -> Annotation Processing -> Factory Path
Here you should add the jar of your processor project. You cannot use project references.
Press the “Advanced” button and you’ll be presented with a dialog which contains the processor you defined in your META-INF/services/javax.annotation.processing.Processor file. Select it and press ok.
We’re practically done. Here’s what it looks like for me in my project:
So we get a warning for the Thing class because its class name start with a “T” and for each class in the project we get corresponding “Silly” classes generated. These are compiled and usable just like any other normal class.
For more info check out the eclipse jdt/apt docs, this bit about creating a code analyzer or the offical docs
Behold! An amazing video tutorial for Theseus on the Android:
It occurred to me that it might not be a bad idea to create a link to this directly from the app.
Since I think nearly all Android phones have a Youtube app, just dispatching a “youtube intent” with the url should open this video in the native youtube player.
Maybe in the next update.
I discovered this video on mobile game analytics using Flurry.
Good stuff:
http://casualconnect.org/lectures/2010-seattle-lectures/insights-from-2-5-billion-iphone-and-android-monthly-user-sessions/