That looks fantastic, and seems to be in alignment with some things I have been doing lately (generating the server side controller of the API in Clojure + a set of documentation, from a set of definitions of API methods).
Good job!
I have done a lot of interface design (ex-lead UX at my company) and I used Inkscape. It's great, easy to use and fulfills all the needs I had.
Actually, using Inkscape was what put me in that role; my mockups were way better than everybody else's.
I do a very similar thing at my job, but instead of showing the results I ask for a report such as "we want to get X,Y and Z for the Ws where P holds true".
In my experience mulltimethods get you a long way when writing Clojure code. My projects use them often and add two or three macros. That is normally the only "overhead" I have to impose over regular functions.
That said, in the example you posted I don't think you are using all the power of the multimethods, because you did not replace the case statement. You went from a case statement to a multimethod+a case statement. In this case, why not let the mutimethod dispatching to do all the routing/case functionality for you? Just use (.-keyCode e) as your dispatch function and use the different values of KeyCodes.XXX for each implementation of the multimethod. And you can even add a :default implementation that leaves the coords untouched.
In my experience the natural use of multimethods arise when you can choose the dispatch function for an element based on either some piece of data from the element or a computed value derived fron the element. But if you have to rely on case/cond/if statements the value of the multimetod is lessened, as you still have to touch your dispatch function when your hierarchy of values change.
Very good point. This was an artifact of the way my wife originally structured the function (dispatching on the keywords :up, :down, :left, :right), and I just kept that.
I am actually writing a REST authentication service right now. The idea is to do it well once, and then reuse it in my other projects. It uses HTTP basic auth; as it is going to be called from the backend of my other projects it will not have the issues described in the article regarding the browser dialog.
I am tired of repeating this again and again, so I am doing some yak shaving and creating a hosted rest service for managing user accounts and authentication. I will use it as basic infrastructure for future projects.
Rather than a hosted/solution - I would be think a program language specific (node/php/java) solution would be more useful. For example - something like $199 for lifetime use for account/oauth/etc system that you can use on any project. Maybe even have additional "packages" like invite friend, etc. Just a thought.
I also have one (that I used in the US btw). The screen was great, easily readable outdoors, the phone was great, super simple, super light. And the battery great.
The dealbreaker was the sms UI: it was absolutely horrible because of the super limited amount of characters on screen at a given time (from memory, it was around 7 or so), it was impossible to text and receive texts in a coherent way.
The site looks great. One piece of feedback: middle-clicking using Chrome a project name in the home page browses to it in the same page; the expected behavior is to be open in a separate tab. Other links (such as the ones in the footer) behave normally.
Thanks! The fix will show up the next time I deploy. Which might be a while -- my revision control discipline on this project isn't as good as it could be.
