156 karma · joined November 4, 2011
I used both Yourkit and Java Mission Control for monitoring the JVM. They both have some functionality of deadlock detection, but it did not flag these two threads. Yourkit identified these threads as waiting, not blocked, but I'm not sure how it makes that distinction.
[1] http://www-03.ibm.com/systems/power/software/aix/sysmgmt/wpa...
One is the port of core.logic. AFAIK there is not a comparable Javascript logic library, although the ClojureScript port does not have all the features of the Clojure base.
Another novel feature is integration with nrepl via the piggieback library[1]. This allows you to evaluate ClojureScript code directly in your running web app if your editor has nrepl connectivity. Again, I don't know of a way to do this with current Javascript tools. But here again, the solution still feels like it lacks maturity.
I don't understand enough of core.async to really comment, but the excitement around it seems to point to another rather exclusive bit of ClojureScript functionality.
Just a tip: we call them breakfast tacos.
goog.dom.query - This isn't included by default, I'm guessing because it's a third-party wrapper around dojo.query. I had to follow a few threads on Google Groups to figure out how to include it. Another option is to use Chris Granger's jayq. But there's no way to do CSS-type selector queries by default (that I know of).
Converting between Javascript objects and Clojure data structures - I had to scratch my head a bit the first few times I ran into this, but there are lots of code snippets on Stack Overflow and various other places around the web. I was able to quickly develop a few reusable idioms to handle this.
Lazy sequences and side-effects - people with more experience in FP might not have gotten stuck on this, but this was another head scratcher for me. Basically any type of DOM manipulation is a side-effect, so if you're app relies on that, you'll need to occasionally force evaluation of a lazy seq.
The browser-connected REPL takes a few manual steps, but it's well documented, and extremely useful. It's just not as easy as running "lein repl". The default compiler is not integrated with lein either, and is not automated, but lein cljsbuild is available as Kevin mentions. I ended up using Chris Granger's cljs-watch.
In any case, if you can't find it through Google, it takes all of about 15 secs to get your question answered on #clojure IRC.
My current setup includes VimClojure and a browser-connected REPL in my terminal. I'm using Noir on the backend, and the included Google Closure libraries on the front-end. I tried to minimize the number of additional dependencies (perhaps irrationally), so I opted out of using the remotes from fetch (formerly pinot), and just used goog.net.XhrIo calls to the noir backend to acheive a similar effect. I did find the crate library to be perfect for dynamically creating DOM objects. You can write something like [:form [<form body...>]] instead of "<form> <form body...></form>", and it's nicely highlighted with Clojure syntax. For debugging, I just use Chrome's debugger. It's compiled JS, but it's easy to figure out where you're at. All of your functions are at the bottom of the script. You're not going to have a lot of state to track in the actual Javascript either, so most bugs are easily sniffed out, at least in my somewhat simple app. Sorry for the long post.
- In Noir I was able to make the jump from "getting started" to "building my own app" fairly quickly.
- After getting a somewhat-viable backend, I hit a pretty steep learning curve trying to figure out how to hook in some Clojurescript.
- I started looking at Clojurescript One, however, I've found it to be a bit of a firehose. I'm intrigued by their development ideas, but I ultimately just want to pick and choose a few things that I can integrate into my existing Noir backend. The Clojurescript repl is pretty sweet though.
- I think I might just use the Domina library in isolation, and use the cljsbuild approach in this article. I will try to revisit Clojurescript One later as I gain a little more experience.
I don't think this is true. I'll concede that it may be a requirement for certain things like an ORM API, but in the general case, it's bad practice. The mere act of adding a getter violates immutability.
Is this a controversial stance? It seems like common sense, unless I'm misunderstanding something.
EDIT: To clarify: I assume he's saying "don't add accessors by default for all private members unless you need to, because you can always go back and add it if you really need it", which is common sense for any project, external or internal. I'm pretty sure he's not saying "don't add accessors, just use public members", which is controversial, IMO, even for internal projects.