Category Archives: Uncategorized

classycle-gradle-plugin update: works with Gradle 2.14.1 and Java 7

A while ago I released classycle-gradle-plugin, enabling easy integration of Classycle into Gradle builds. Classycle is a really great tool for static code analysis, especially checking for unwanted dependencies, cycles, etc.

I’ve just released a new version of the plugin. Since 1.2, it should work without problems with Gradle 2.14.1 (tested with 3.2.1 as well) and Java 7. Happy hacking, and thanks a ton to GitHub contributors!

Two Ways to Access Properties in ClojureScript

There are two pairs of complementary functions to set properties on objects in ClojureScript. One is aset and aget, another is set! and .-propname:

(def scope (js-obj))
(aset scope "var1" "Value")
(aget scope "var1")
(def scope (js-obj))
(set! (.-var2 scope) "Value")
(.-var2 scope)

Are they equivalent? Is syntax the only difference?

For a demo, let’s say we set and print two fields on an object, like this:

(def scope (js-obj))
(aset scope "var1" "Value")
(set! (.-var2 scope) "Value")

(.log js/console (str "(aget scope \"var1\") ->" (aget scope "var1")))
(.log js/console (str "(.-var2 scope) ->" (.-var2 scope)))
(.log js/console (str "(.-var1 scope) ->" (.-var1 scope)))
(.log js/console (str "(aget scope \"var2\") ->" (aget scope "var2")))

The resulting “setting” instructions are deceptively similar:

mynamespace.scope = {};
mynamespace.scope["var1"] = "Value";
mynamespace.scope.var2 = "Value";

And of course all combinations print out correctly – I can see this on the console:

(aget scope "var1") ->Value
(.-var2 scope) ->Value
(.-var1 scope) ->Value
(aget scope "var2") ->Value

So far so good.

Now, if you’re at least a little bit serious about using ClojureScript, you have to consider advanced optimizations. What happens in this mode?

My code got compiled to:

var Xm;
Xm = {var1:"Value", lc:"Value"};

And on the console all I see is:

(aget scope "var1") ->Value
(.-var2 scope) ->Value
(.-var1 scope) ->
(aget scope "var2") ->

What happened to var2? Why is set! suddenly incompatible with aget and aset with .-field?

If you look at compiler output in both cases, you should see that in one case the value is bound by name and in the other by symbol. In my understanding, it has a few consequences:

  • Advanced compiler renames symbols, but leaves strings intact.
  • aset and aget operate on names. set! and .-var operate on symbols. If you set a variable using “symbolic reference”, the compiler will rename the symbol so you won’t be able to get it by name anymore. If you set it by name with aset, reading by symbol as .-var will not work either because the symbol is renamed.
  • If you deal only with ClojureScript, you should probably use the symbolic references. They look more idiomatic and will benefit from advanced compiler features such as minimization. On the other hand, in this case you often may want to leverage the idiomatic data bindings – vars, atoms and such.
  • As soon as you want your names to be accessible from outside, or you want to access names set outside, use only aset/aget. It obviously applies to interop with JavaScript libraries. Less obvious case (for me) was libraries that operate on DOM, like Angular or Knockout. If you want that {{user.name}} to work, you cannot use the symbolic version.

It all makes sense now, but I haven’t seen it documented. Well, that’s still true for most ClojureScript.

I am a DZone Most Valuable Blogger and JavaCodeGeek!

I’m happy to announce that at about the same time I became a DZone Most Valuable Blogger and a JavaCodeGeeks author. Some of my posts have been appearing on various blogs, community sites and aggregators for a while (especially those on Clojure and functional programming), but being invited to participate in something like these two programs is quite a new experience.

Some parts of this blog is ranting and bragging, but the main purpose has always been to learn and share knowledge. I wouldn’t have learned so much without the blog – just getting something to work is a lot easier than understanding it enough to be able to explain it to someone. We all know that the community is quite demanding. I learned the hard way that writing too shallowly, repetitively, or without proper understanding is immediately punished. On the other hand, it’s truly exhilarating to see my post mentioned by people I really admire, or make it to the front page of Hacker News.

The most rewarding part is always the comments. Not only does it mean that someone has visited the site, but also that they actually cared to read the post and share their insights or related knowledge.

Thanks, guys!

Fitt’s Law and Dual Monitors

Thanks to Jeff Atwood at Coding Horror I recently discovered the good old Fitt’s law. To make a long story short, it says that the larger the component is, the easier it is to click on it. The area near to screen edges is the most valuable, because from mouse cursor’s point of view it is infinite. See Particletree for a great visualization of this concept.

I knew that intuitively. It seems that UI creators have taken it into account for years, putting tiny title and task bars on top or bottom and all the most important icons in corners. I haven’t realized how important it is until I started using a mediocre dual head configuration. After all, computer is a part of me and I don’t see it until something goes wrong.

Consider this setup:

Monitor configuration in Ubuntu

The larger display is a desktop monitor with higher screen resolution. The smaller one is my laptop. Since I am right-handed and I use laptop keyboard, it needs to be on the left. Apparently in Ubuntu the “left” monitor is always the one that gets the desktop, with task bar, shortcuts and so on. I don’t know how other operating systems deal with it, but in Ubuntu you always need to have a rectangular desktop. It means your mouse can move to the brown area, right above what you see as the top edge of the screen.

Now using a quick launch or tray on the smaller screen is quite an ordeal. Even if the displays were of the same size, or the OS dealt with it without the “brown area”, you still would have issues with window title bar icons or scrollbars.

With Fitt’s law at least I am able to name this issue.