~/.lein/profiles.clj file. But the thing is, that each plugin or dependency slows down every lein invocation (e.g. lein new,lein repl, …). It doesn't matter whether the plugin is actually used or not.
{:user {:plugins [[cider/cider-nrepl "0.9.1"]]}}
If you don't need to have it available all the time, but only when you run lein repl, you can move it into :repl profile.
{:repl {:plugins [[cider/cider-nrepl "0.9.1"]]}}
After this, startup time of non-REPL tasks will be much faster (e.g. 2 seconds vs 8 seconds for `lein help` on my machine).
In the previous post I have been evaluating Light Table's instarepl using the String Calculator kata. Performing code katas is great way to improve one's workflow so this time I tried to do the same kata using the Emacs. You can see recorded screencast below.
In order to get quicker feedback I had to modify the clojure-test-mode to display test failures right inside current Clojure buffer. Fortunately Brian Marick already implemented this for the midje-mode so I just reused parts of his code. I'll probably send pull request to clojure-test-mode when I implement it correctly. You can find the code which I'm currently using in my dotfiles repository. It's really great that one can easily extend/modify Emacs to match his needs.
Due to my familiarity with Emacs/Evil I managed to do more stuff in 9 minutes so the resulting code is little bit cleaner than in the previous screencast. Also thanks to the ace-jump-mode I didn't have to touch the mouse at all.
Today I was sitting at a coffee shop and none of the wireless networks worked so I started to explore my local stuff and I did find recent version of the Light Table sitting in my Downloads folder. I didn't have much time to play with any of the previous versions so I thought this could be the good time to give it a try. I was especially interested in how instarepl could help me solve problems in Clojure so I tried it on my favorite code kata called String Calculator. I recorded screencast of this experiment which you can see below.
My first impressions are pretty positive as it helped me multiple times to get the code to work pretty fast. There were also times where I could use a little more help (e.g. it didn't show much useful information in the add function at the beginning). But overall it was pleasant experience and I'm looking forward for future versions. Maybe someday I'll switch from the Emacs/Evil to the Light Table. Or the best stuff will get ported to the Emacs... :)
Q: Does the Light Table contain some Clojure documentation functionality? E.g. something like eldoc-mode / clojure-cheatsheet in Emacs?
So hopefully everyone's writing (unit-)tests for their code these days. Good! If you are one of us, you probably know that there are good as well as bad tests. At the end of the day it's just code like any other. If you don't pay attention you can write some really bad test code which will make your life miserable in the long run.
I have been writing tests for most of my code for years now and did thousands of code reviews for my teammates. I'm also one of the guys who runs Coderetreat events in the Czech Republic so I have probably seen it all. Good stuff as well as bad stuff. :)
So without further ado, here is the list:
The Command Line (CLI) is the primary user inferface of many Unix-like operating systems. Over the years it has evolved into a powerful thing which will make your life a lot easier if you invest some time to learn it.
This post is based on one of my internal presentations which I created for my teammates at Netsafe. It assumes that you are already familiar with the CLI.