Rogach on Scala

As many people out there, I read web feeds frequently. Usually, I read them each morning, and then each evening. But some time ago (20 days ago, to be exact), I got flooded by problems, and had to stop reading them. But the feed reader still sat there, accumulating stuff... Over 20 days, it accumulated 3,100 feed items! It took me one full day  to read through them. Just think about it - it is an equivalent of spending 1-2 hours each day just to clean the flood of incoming feed items. Clearly, it had to stop somehow. On the course of my "reading marathon", I noticed that I do not read many feeds (Slashdot, Lifehacker, Habrahabr) "cover-to-cover". Instead, I just look at the headlines - and in most cases (90-95%) dismiss the item without reading, since I'm not interested. So today, I embarked on the quest to clean up my feed list. I deleted the ones, that delivered non-interesting content (0 valuable items in the last 10-15), or were just dead. In the...

Everybody says that Java applets are dead (and there are talks to revive them with JavaFX 2). But it seems they are still not dead, at least from my point of view - since I maintain an applet for one of my customers. Basically, that applet processes .svg  files. And it would be convenient for user just to do double-click on a file and get the applet to start with that file. I solved this problem as follows: applet accepts a parameter in it's launch url, and file association in Windows launches Internet Explorer with the file name as parameter in that url. Here's the code to establish such file association: assoc .svg=SvgGraphicsFile ftype SvgGraphicsFile=C:\Program Files\Internet Explorer\iexplore.exe "www.someplace.ru/index.html?file=" "%1" And this is how I extracted that file name from applet url: // first, in our Applet class, we get the url, from which app was launched val docBase = getDocumentBase() // then, we parse it object Loader { def lo...

Sometimes it is funny to gather some statistics about your activities - how much time you spend reading, how much time you spend programming, etc. There is a Gnome panel app specifically for that purpose - Project Hamster . It does it's job well, but not well enough - it still requires you to manually specify start and end of each task, and I often forget to do that. But why do we need a full-blown app for such simple thing? I really think that we can mine most of the needed information simply by analyzing the focused window properties (actually, just two of them - process, that owns that window, and title of window). For example, when the main window is from "evince" program, then I'm probably reading some book, if it is Emacs or terminal, I'm coding, if Opera - most probably reading feeds. Window title is needed only in specific cases, when you can't differentiate based on the program executable name - sadly, most of python programs fall into this cat...

Sometimes you need to run some code after the subclass initialization - for example, if it is a library class that users extend and you need to check their configuration. The simple solution will be simply to obligate user to call some method in your class after he is done, but it looks redundant, prone to error, and not beautiful overall. It turns out that Scala has no obvious mechanism for this, so I needed to go through some hoops to achieve the needed effect. My idea was to use the DelayedInit trait  (which is deprecated now, sadly) in order to get the initialization bodies for the parent class and subclasses, then execute them in "delayedInit", and count the amount of times it executed. Since I can get the number of superclasses for any given class, I can just execute the after-init code when I've seen enough initialization bodies. I wrapped this into a trait for easier reuse. Note that if your class extends some other non-trait, you'll need to override ...

It turned out that spreading type annotations throughout all the code in all places where options are requested is not a good idea. And, of course, it is prone to errors - who likes those type annotations? When using such option parsing libraries, users usually end up creating a big object with fields corresponding to each option: object Conf { var apples:Int = 0 var bananas:Int = 0 } // ... parsing options ... Conf.apples = parser.getOption("option name", ...) Conf.bananas = parser.getOption("other option name", ...) Sure, this works, and usually flexible enough - but why would anybody want to create such boilerplate? And by the way, nobody likes var's in their code :) So in Scallop , I needed to cut down that unnecessary repetition. There are several ways: Create a compiler plugin. The most powerful option. And the least enjoyable - even given the ease of installing a compiler plugin using sbt, I doubt that anybody will install compiler p...

Command line interfaces have been with us almost as long as computers themselves - first cli's were created  in early 1960s , only two decades later than first general purpose computer was presented ( in 1946 ). From that old times command line and command line interfaces became trusted and loyal friends of the programmer. Fast forward to modern times. Now, half a century later, graphical user interfaces seem to be triumphing over all other interfaces. GUI evangelists love to present pretty charts, which demonstrate that CLI's are dying. But is CLI really dead or planning to die? No way, of course. The whole UNIX philosopy is built around small, orthogonal utilities, each doing its small piece of work perfectly (think wc, cat, find, bash pipes). And, obviously, this effect is almost impossible to achieve using pretty graphical systems with lots of buttons, checkboxes, sliders, knobs and what-not. The "almost" part of that statement is what keeps the m...

Today I will talk about anonymous functions and memorizers. Here is a simple, self-sufficient anonymous function (I think it is the simplest possible): val fun = (a:Int) => a + 1 What's wrong with it? Nothing, except for the fact, that it would recompute the value every time it is called. In case of adding 1 to argument, it is not a problem, but what if we would be doing something expensive? Wouldn't it be cool to be able to do something like following? val fun = mem( (a:Int) => a + 1 ) And Scala permits us to do exactly this: def mem[A,B](f:A=>B) = new Function[A,B] { import scala.collection.mutable.Map; private var cache:Map[A,B] = Map() def apply(v:A):B = cache getOrElseUpdate(v,f(v)) } val fun = mem( (a:Int) => a + 1 ) Now, we have a function, that stores all the computed results into a Map, and does not recompute them. There are several minor problems with this approach - for example, it is not thread-safe, and sharing this function between thre...