Signals, editor and factory pattern

I tried to remake my clone of Popcap’s Bookworm in Godot game engine. My JavaScript code was a mess and I didn’t want to write a whole game engine from scratch in JS, so I moved to Godot. Also the graphical editor appealed to me. My very much WIP Bookworm version is available here (currently it doesn’t even support Japanese and has an English dictionary instead).

Anyway, while working on the thing I learned something new. When my game was running I was getting a lot of errors, though they didn’t seem to break anything. I was using a factory scene for my different tile types and duplicating the tiles when needed. The tiles had signals connected to them in the editor and those signals turned out to be the source of the problem. Long story short, connecting the signals in code in the _ready function, while disconnecting them in the editor made all those weird errors go away.


Don’t use wildcard in UDF and Views

In SQL Server the * wildcard is useful feature when quickly putting together a query.

FROM MyTable

However there are certain situations where you should avoid using it. Namely you should not use it when you’re returning data from user defined function or a view (and possibly procedures as well). The reason behind it, is that SQL Server stores what a view or function returns (even if you don’t explicitly define it). When you ALTER or CREATE a function, the format of the returned data is defined. Let’s say your UDF executes this query:

FROM Orders

And your Orders table contains following columns:

  • Id
  • CustomerId
  • OrderTotal
  • IsPaid

This function will obviously return all the rows in the Orders table and everything is fine. However a problem will arise when you decide to alter the structure of the Orders table. Let’s say we will insert an IsCnancelled column right before IsPaid. So the table will look like this:

  • Id
  • CustomerId
  • OrderTotal
  • IsCancelled
  • IsPaid

The data returned by the UDF will be missing the IsCancelled column, but that’s not all. The contents of the IsCancelled column, will be presented as the IsPaid column. Such an error could wreck havoc. If you ALTERR the UDF (no changes are actually required), the structure of the returned data will be updated, but it’s better to avoid using the * wildcard altogether, than trying to manage this mess.

On the other hand, using wildcard in subqueries or CTE inside an UDF should be safe.

All this is probably obvious stuff to most people working with SQL Server and my example is very basic, but I had to fix problems caused by such use of the wildcard in the past and they can get ugly.

Rikaikyun 0.15

After nearly a year without a major update I managed to motivate myself to push a number of improvements to Rikaikyun. The key one is speed. I found my app to be acting sluggish with files that were 500+KB in size. A single volume of a WEB novel is usually this big and while I can split the volume into chapters, managing this many files becomes annoying. That’s why I rewrote the way the text is presented. Previously all text was dumped into the web view, but that caused those speed issues. On the other hand, I noticed that the dictionary doesn’t affect the speed of the app much, even though it takes some 70MB of memory. So I figured that keeping only the visible text in the web view should make the app work faster and it actually worked (few MB files can be still a bit too clunky to use). This was a bit tricky to implement, but I’ll spare you the details. Let me just say that I kept the scrolling mechanism to keep things simple.

Another thing I did was improve the security of loading random html files. The previous release of Rikaikyun wasn’t 100% resistant to loading external JS or inline JS. The new version however, should strip any JS from loaded document, or at least prevent it from executing.


Since many newer Android devices lack physical back button, I added on screen back button to various menus, to make the app easier to use on those devices.

As for the changes that are visible more easily, I added chapter positions to progress bar and navigation submenu. The navigation submenu allows you to jump chapters and also jump to specific position in the document.

As usual, the APK can be grabbed from here.

Rikaikyun Beta released

I reached the stage at which Rikaikyun appears to be fully usable (though I haven’t made a lot of tests), so I decided to release it to public (not that it was hidden from public before). You can grab the APK and source code from here. Note the APK will probably not work on anything less than Android 4.


You can also test the app in Chrome using the device emulation mode (you have to run Chrome with the –allow-file-access-from-files flag on). For running the app in chrome there is also a special Chrome hack option that allows emulating pressing back button by going back in browsers history.

Disappearing objects

While working on Rikaikyun I came across this strange problem, after pushing one of my revisions I tried running my app on my target device (Onyx Boox T68 Lynx) and found out it no longer works (even though I had no problems running on Chrome and another Android device). Debugging Phonegap apps on a Lynx is a pain, because Phonegap Development App cannot be used there, so you have to probe blindly in hopes of finding what could be causing the problem.

My first finding was that one of my classes suddenly became undefined. I spare you the details of what I tried or not, but the source of the problem was mismatched letter case in the name of one of the JS files. Now, I’m smart enough not to reference JS files using wrong case, but as it happen, at one point in the project, the file had a different name (only the case was different). Given that I use Windows and store my project on GIT, I’m sure you can guess what went wrong… Anyway GIT didn’t notice the fact that I change the case of the file and when I finally did a merge it renamed my file to what I named it originally.

I guess when you use the file:/// protocol in Android browser you have to pay attention to the case in file names, because requests to those files does appear to be case sensitive.

Ruby furigana in pure css

I’m not entirely sure about the nature of the ruby tag within HTML, but I know that it is used by many Japanese sites for including furigana. If you stumbled upon this post then you are probably aware what furigana is (and can skip the rest of this paragraph). If not, well in Japanese many Chinese characters are used. Those characters are called kanji. The Japanese also have 2 phonetic alphabets, hiragana and katakana. The problem with kanji is that unless you know the character (and in some cases the whole word), you will have no idea how to pronounce it (many Japanese names are written using the same characters but pronounced differently, not to mention foreigners and Japanese kids who are just learning kanji will have trouble with more than just names). To help overcome this problem the Japanese use furigana in some of their written text. Furigana are small hiragana characters (though small katakana or kanji characters are also used occasionally) placed above a kanji (in horizontal text) or to its right (in vertical text). You can find more about furigana on wikipedia.

Anyway, to correctly display furigana enclosed in a ruby tag, you will need a plugin like HTML Ruby for Firefox. Without such plugin the furigana (enclosed between parentheses) will be placed inline behind the kanji.

Here is a sample of HTML containing some ruby furigana.


Without a furigana plugin it will render as:


If you’re using a browser on a desktop computer, you can just install a plugin for your browser and be done with it, but what if you need to display ruby furigana on a machine\browser that doesn’t have such plugin, or what if you are writing a PhoneGap application?

It turns out you can style ruby furigana to display correctly using css alone. The biggest obstacle in getting this to display correctly is reversing the order in which kanji and furigana are displayed. The plugins achieve this through use of translate (within the transform style). This method has some limitations, but there is another way to do this.

The trick is to use table-header-group display method on the furigana. This is “equivalent” to making an element behave like a thead tag, effectively making it display at the top of it’s container (in this case the ruby tag).

Obviously this css furigana isn’t perfect (there is no support of dot furigana), but should be good enough to use in most cases. The code for ruby css is below:

	vertical-align: bottom;

ruby rp

ruby rb, ruby rt

ruby rt
	display: table-header-group;

ruby rb
	display: table-row-group;


Update: Turns out “newer” versions (4 and up) of android have Ruby support in the native browser, making this trickery unnecessary. I think FireFox too has added support for Ruby recently.

Rikaikyun – a reader app for Japanese text on Android

On desktop computer there are such wonderful browser plugins like Rikaichan, Rikaikun and Rikaisama that will translate Japanese words for you if you move your mouse over them.

Apparently Rikaichan might have (or have not) worked in an older version of FireFox for Android, but currently your best bet, when it comes to dictionary supported reading of Japanese on your Android device of choice is Jade Reader (it even works on a E Ink Android device like Onyx Boox T68 Lynx). However, this app haven’t seen an update in ages and is missing quite a few functions. The source code is available on the internet here. I tried my luck altering the code, but I only managed to make small alterations to an older version of the app. The never version uses different external libraries and it’s not well documented, so I had issues even compiling it…

I was trying to make an app that uses Rikaichan (Rikaikun to be exact) in Node-Webkit and by accident I found out that the Rikaichan core code runs even if I run it directly on a html page. This made me believe that it might be possible to run Rikaichan in PhoneGap. As it turned out, it can be used inside PhoneGap (I suspect it won’t work on any Android younger than 4.0.4 due to the amount of RAM it requires)!

Above I mentioned core code, what I meant by that is that I didn’t manage to make Rikaichan work as a whole, but just the dictionary module (data.js). Thankfully the dictionary module can be used on it’s own and the fancy display can be always recreated from scratch. Using it is actually quite simple, though I had hard time telling what is what inside Rikaikun plugin. Maybe I’ll make another post about that.

So, I started a new project name Rikaikyun. Currently it’s not very impressive as it just loads first chapter of Genji Monogatari (you can’t pick a specific file yet) while offering no customization whatsoever, but the point is the basic functionality is there. By basic functionality I mean, you can tap a word and it will open a dictionary popup. I have big plans for this app (furigana, word stats etc.), but I’m not sure how far I can push the thing performance-wise (PhoneGap isn’t the most efficient platform, though newer Android devices seem to handle it well enough).

Anyway, the project is still in a very early stage and it can be found at It should be possible to even test it without putting it on your Android device. Both Chrome (with –allow-file-access-from-files option) and FireFox should be able to handle the file (though touch events and zoom won’t work in FireFox). To test it on desktop just run the index.html found in www folder. For android, you would have to make PhoneGap build it for you, or use the PhoneGap developer app.

If there is any progress with this app, I’ll try posting info about it here.