The page consists of basically three main parts: Essential Japanese programming vocabulary, Expressions for communicating technical issues in Japanese (with a Part II), and A look at a Japanese software specification. They’re based on material I’ve gathered during my years working in Japan, mostly in completely disorganized, scattered text files, so collecting and choosing the useful bits of it for this page was more work than it should have been…

Actually, I first got the idea of writing a “Japanese for Programmers” book some time ago when talking with a former colleague. The idea was that there are so many especially Indian software developers working in Japan, but there are as yet no books aimed specifically at this segment, and there should be a huge market.

Anyway, I’m an avid reader of Seth Godin’s blog, and Seth is the guy behind Squidoo as well, so I naturally stumbled upon it. I gave it a go, and it’s actually a really fun and easy way to create modern, stylish, SEO’d web pages without having to bother with the technical issues.

And then in last month’s search queries used to find my site I saw “japanese speaking programming“, and that finally got me going to do something with my Japanese for Programmers idea – I mean people are searching for it, and they’re already finding my site from it (there’s no “Japanese for Programmers” site on the net anyhow!), despite me not specifically covering that topic, so it seems everything falls into place. And thus the Japanese for Programmers Squidoo “lens” was born!

So I hope it’ll get lots of readers and comments. I still have loads more material, so if it gets popular I might do a follow up. Here’s the URL again:

http://www.squidoo.com/japanese-for-programmers

I don’t know what the little fellow was up to, but imagine the destruction, had it hit me in the face (I walk pretty fast too). I suppose it had escaped from one of the houses. It probably won’t survive very long, considering it won’t get warm for a while yet and the abundance of cats in the neighborhood. Not to mention its suicidal tendency of flying towards people on the street.

By the way, did you know there’s a population of wild parrots in Tokyo? Escaped parrots have taken up residence in the trees lining the south side of the French Formal Garden of Shinjuku Gyoen. Yes, they are very particular about where they live. They’re larger than budgerigars though, and manage to survive.

© MzePhotos.com, Some Rights Reserved

Anyway, I was going to write about software architecture, not parrots. The last couple of days I’ve been thinking about what software architecture is. The word gets thrown around a lot, and people even carry the title “software architect”.

In my work there’s talk about architecture as well. We’re doing architecture.

Now, I’ve figured out that what gets called software architecture can, in down to the monkey’s balls practice, be classified as one out of five tangible things. I might at some point come up with more, and if you have any suggestion then please leave a comment. Anyway, here they are:

1. Build-time composition
   Can be in the form of invasive composition done by a proper composition system, as outlined in the book Invasive Software Composition, written by my favorite professor Uwe Aßmann. But more often in the form of simple #ifdefs, or link-time selection of different libraries.

2. Design patterns
   This is probably my favorite one. Design patterns are powerful not primarily because the pattern in itself is clever, but because they communicate the intention of the programmer to others quickly. If someone knowledgable reads a piece of codes that says it’s doing a visitor pattern, say, then you immediately know what to expect.
3. Naming conventions
   This might be the most common excuse for an architecture. And I’d count object oriented languages’ attempts to hide things behind (often long) namespace and (often nested) class names as just another naming convention (often termed “object oriented design”). Architecture often seems to take the meaning that things that belong to one part of the system starts with a certain prefix (such as a class name). It’s useful for finding things in the source tree, though.
4. Function pointers
   … in one form or another. All programmers use function pointers, often termed callbacks, handlers, functors, virtual methods, delegates, etc. Function pointers allows control of flow during runtime, but more often they seem to be used as a bad substitute for build-time composition. At some point there seems to be a line where this common code monkey tool turns into architecture.
5. Layers of indirection
   It has been said, perhaps by Mark Twain, that any programming problem can be solved by adding another layer of indirection. It is often implemented in the form of function calls, or by using function pointers, often in combination with naming conventions. Of course any code monkey can do function calls. But by doing small transformations of values and data types, and perhaps branching depending on the data, and letting the next layer do this in succession, one can seemingly achieve architecture.

Barring further bird attacks, I will consider these five items to be the fundamental building blocks of software architecture. Next, I intend to write about how these can be used to create good architecture. Because one man’s architecture is another man’s code bloat.

The methodology used by TIOBE to calculate a language’s popularity is basically the good old google hits ad-hoc voodoo index, using “[language] programming” as the query. This measures the “web presence” of a programming language.

First of all, it’s obvious to you and me that this measures something, that something being the amount of web pages including the term “[language] programming”, obviously. There’s nothing wrong with this method, as long as one is aware of what they’re measuring. But is it fair to call this the popularity of a language?

Look at this blog, for example. I mostly mention JavaScript and PHP here, just like everyone else. Throw in some Ruby and Python too to max out the buzz factor. There is no mention of relics such as C in this blog. But you know what language I use ten times more than any other? C. I’d love to have a job hacking away in JavaScript, Ruby, and Python all days, but I’d have to settle with half the salary. So here it goes: C programming. Index that. Embedded, heavily multi-threaded, efficient, minimum memory, hardcore badass C programming, that’s what I do, and I love doing it.

Most coders can’t do C. That’s why you see all these Visual This and Dot That and scripting languages on the ranking, because these kids blog about every little insignificant hobby project they manage to cut and paste together, just like I do. But let there be no mistake about it: real programmers can code in C. They do syntactically correct typedefs of function pointers in their sleep. (just kidding that’s impossible.)

At work I also hack in Python, Perl, and Makefile. At home it’s mostly JavaScript, PHP, Ruby, Python… Lately Python has replaced Ruby as my language of choice for home hacking because of its decent unicode support. (Although I’ve had to hack the Python standard library in some places where it didn’t properly support unicode. I read the next version of Python (2.6?) will use unicode strings by default, which is great, and only ten years late.) I also sold my soul the other day and installed Visual C# 2008 Express Edition for some hobby hacking. Turned out not very fun though, but I haven’t given up yet.

At my previous job I used C++ for doing essentially the same thing as I do in C now. I’m completely convinced that C is the right tool for the job. I’m also convinced C does object orientation better than C++, but that is a topic for another post. And I used to be a Java fan, but now I’m considering Java the best examples of software suckiness ever. It’s a volatile industry, technologies come and go, but no amount of blogging will convince me that the C programming language is anything but #1.

I’m saying it because it’s true: We’ll always have C. Because we’ve got jobs to do.

Developing this game has taught me one something about the time it can take from prototype to somewhat finished product: Developing the completely playable “offline” prototype version was quick and easy – after all, I developed minesweeper already in high school on my programmable Casio calculator. So I thought it would take about trice the time to finish it, but in the end it took about ten times that time.

One reason for this is the online highscore functionality. But T-rex, online highscores just means keeping a list of the best times on the server and sending it to the client. Yes, but then it wouldn’t take much to figure that all you need to do is type “register_highscore.php?time=0&name=script%20kiddie” into your browser’s address field to get an instant all-time high. So how did I solve that?

The game is played simultaneously on the client (i.e. in the web browser) and on the server (in php). Sweeps are sent at regular intervals to the server, which then plays the same moves and checks the results. So in the end it’s the server that decides that a game is over, how long it took, and whether that’s a new highscore or not. That, ideally, is not so complicated either, but well there are lots of opportunities to make stupid mistakes. (Especially when you’re having a shochu on the rocks while coding (I did it during my vacation).)

The other reason is that it’s hard to make a web app behave like a nifty game. You need graphics, animations, and that kind of stuff that often causes you to run into problems with layout positioning and, most of all, browser inconsistencies. Web browsers just aren’t ideal for making applications yet. (Well, tell me a platform that is, anyway…) The game runs best, as always, in Firefox. Although I admit I haven’t tried IE 6 yet. I’ll tackle that beast tomorrow. IE 7 works good, though.

I still have a number of features planned that I’ll implement during the coming weeks, but at least now it’s good enough to play. Try and beat my times! Here’s the url again:

http://henrikfalck.com/minesweeper/

So I was surprised by how hard it is to turn off this aggressive non-caching policy. I googled for a few minutes and browsed the php documentation without finding an easy way of doing it. Ok, so you can use the following code snippet to enable caching in php (the argument to the function is number of seconds the page is valid):

function send_cache_headers($expire) {
  header("Cache-Control: max-age=$expire");
  header("Pragma: cache");
  header("Expires: " . gmdate('D, d M Y H:i:s \G\M\T', time() + $expire));
}


How do I know this works? Because it’s based on a much cleaned up version of the code used on paintmyblog.com – which has proven itself already. I look forward to writing some cool apps using this library, and I hope other people will use it as well. Expect the first release next week.

Core JavaScript 1.5 Reference – Mozilla Developer Center
A thorough and complete reference for the JavaScript language and standard library, with examples and links to more information, etc. Really good.
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference

Gecko DOM Reference – Mozilla Developer Center
Complements the above reference with a complete reference to the document object model, i.e. all the methods and classes that are available in JavaScript for manipulating the web page in the browser.
http://developer.mozilla.org/en/docs/Gecko_DOM_Reference

Canvas Class Reference – Apple Developer Connection
If you like playing with the canvas tag like I do, then this is the place to go for reference documentation on the 2d graphics context object. Complete and handy with all in one page.
http://developer.apple.com/documentation/AppleApplications/Reference/SafariJSRef/Classes/Canvas.html

Prototype JavaScript Framework API
The reference documentation for the Prototype framework. Of course, this is only useful if you’re using Prototype. But if you’re not, you better have a really good excuse… such as using some bloated alternative like the Yahoo UI Library or Google Web Toolkit.
http://www.prototypejs.org/api

Dojo ShrinkSafe
Dojo ShrinkSafe shrinks the sizes of your JavaScript source files by removing whitespace and renaming local variables to shorter names, and some other stuff. Saves bandwidth and loading time without really giving much up, except debuggability. But you’re not doing debugging on your live site anyway, right? Riiight?!
http://alex.dojotoolkit.org/shrinksafe/