tag:blogger.com,1999:blog-63177881518522870152024-02-08T03:59:59.281-08:00Marian SchubertMarian Schuberthttp://www.blogger.com/profile/05554845434051483299noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-6317788151852287015.post-4402429629416516592016-03-17T10:20:00.000-07:002016-03-17T10:20:13.842-07:00Making Leiningen faster using aliasesLeiningen is a great tool which I use daily when working with Clojure. Therefore I want it to be as fast as possible.<br />
<br />
Over the time, several plugins and dependencies did end up in my <code>~/.lein/profiles.clj</code> file. But the thing is, that each plugin or dependency slows down every lein invocation (e.g. <code>lein new</code>,<code>lein repl</code>, …). It doesn't matter whether the plugin is actually used or not.<br />
<a name='more'></a><br />
For example I'm using <a href="https://github.com/xsc/lein-ancient">ancient</a> plugin which will find outdated dependencies in a project. Common practice is to put such plugin into <code>:plugins</code> vector of the <code>:user</code> profile in <code>~/.lein/profiles.clj</code>.<br />
<pre class="src src-clojure" style="border: 1px solid rgb(204, 204, 204); box-shadow: rgb(238, 238, 238) 3px 3px 3px; margin: 1.2em; overflow: visible; padding: 1.2em 8pt 8pt; position: relative;"><span style="font-family: inherit;"><span style="color: #b3b3b3;">{</span><span style="color: #111111;">:user</span> <span style="color: #b3b3b3;">{</span><span style="color: #111111;">:plugins</span> [[lein-ancient <span style="color: #111111;">"0.6.8"</span>]]<span style="color: #b3b3b3;">}}</span>
</span></pre>
<br />
But I don't use this plugin too often. So I not happy paying 250ms startup penalty whenever I run Leiningen. Fortunately it's possible to fix that using aliases (and also profiles if you like). So now I'm using:<br />
<pre class="src src-clojure" style="border: 1px solid rgb(204, 204, 204); box-shadow: rgb(238, 238, 238) 3px 3px 3px; margin: 1.2em; overflow: visible; padding: 1.2em 8pt 8pt; position: relative;"><span style="font-family: inherit;"><span style="color: #b3b3b3;">{</span><span style="color: #111111;">:user</span> <span style="color: #b3b3b3;">{</span><span style="color: #111111;">:aliases</span> <span style="color: #b3b3b3;">{</span><span style="color: #111111;">"ancient"</span> [<span style="color: #111111;">"update-in"</span> <span style="color: #111111;">"</span><span style="color: #111111;">:plugins</span><span style="color: #111111;">"</span>
<span style="color: #111111;">"conj"</span> <span style="color: #111111;">"[lein-ancient \"0.6.8\"]"</span>
<span style="color: #111111;">"--"</span> <span style="color: #111111;">"ancient"</span>]<span style="color: #b3b3b3;">}}}</span>
</span></pre>
<br />
This way the ancient plugin will be included in <code>:plugins</code> only when I really use it. Leiningen is now fast(er) again!Marian Schuberthttp://www.blogger.com/profile/05554845434051483299noreply@blogger.com1tag:blogger.com,1999:blog-6317788151852287015.post-14035912192882654632015-11-18T03:47:00.001-08:002015-11-18T03:47:55.159-08:00CIDER slows down Leiningen startup. Here is how to fix that.Official <a href="https://github.com/clojure-emacs/cider#setting-up-ciders-nrepl-middleware">CIDER documentation</a> recommends putting CIDER into user's profile.
<pre>
<code>{:user {:plugins [[cider/cider-nrepl "0.9.1"]]}}
</code>
</pre>
If you don't need to have it available all the time, but only when you run <code>lein repl</code>, you can move it into <code>:repl</code> profile.
<pre>
<code>{<strong>:repl</strong> {:plugins [[cider/cider-nrepl "0.9.1"]]}}</code>
</pre>
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).
Marian Schuberthttp://www.blogger.com/profile/05554845434051483299noreply@blogger.com5tag:blogger.com,1999:blog-6317788151852287015.post-70833202872610183042013-08-30T15:49:00.001-07:002013-08-31T11:23:36.730-07:00String Calculator Kata in Clojure (Emacs)<p>
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.
</p>
<p>
<iframe width="636" height="477" src="//www.youtube.com/embed/lfStMiDzOF4?rel=0" frameborder="0" allowfullscreen></iframe>
</p>
<p>
In order to get quicker feedback I had to modify the <code>clojure-test-mode</code> to display test failures right inside current Clojure buffer. Fortunately Brian Marick already implemented this for the <code><a href="https://github.com/marick/Midje/wiki/Midje-mode">midje-mode</a></code> so I just reused parts of his code. I'll probably send pull request to <code>clojure-test-mode</code> when I implement it correctly. You can find the code which I'm currently using in my <a href="https://github.com/maio/dotfiles/commit/4d135730524fd88c2ba14bfe7c0d6e67aeab8bc0">dotfiles repository</a>. It's really great that one can easily extend/modify Emacs to match his needs.
</p>
<p>
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 <code><a href="https://github.com/winterTTr/ace-jump-mode">ace-jump-mode</a></code> I didn't have to touch the mouse at all.
</p>Marian Schuberthttp://www.blogger.com/profile/05554845434051483299noreply@blogger.com1tag:blogger.com,1999:blog-6317788151852287015.post-5279443603654334512013-08-27T11:03:00.001-07:002013-08-27T11:19:01.185-07:00Getting the feel for the Light Table's instarepl (screencast)<p>
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 <a href="http://www.lighttable.com">Light Table</a> 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 <a href="http://osherove.com/tdd-kata-1/">String Calculator</a>. I recorded screencast of this experiment which you can see below.
</p>
<p>
<iframe width="636" height="477" src="//www.youtube.com/embed/GPdDL8WrqLc?rel=0" frameborder="0" allowfullscreen></iframe>
</p>
<p>
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 <code>add</code> 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... :)
</p>
<p>
<strong>Q:</strong> Does the Light Table contain some Clojure documentation functionality? E.g. something like eldoc-mode / clojure-cheatsheet in Emacs?
</p>Marian Schuberthttp://www.blogger.com/profile/05554845434051483299noreply@blogger.com6tag:blogger.com,1999:blog-6317788151852287015.post-51901707264851165192013-06-21T05:30:00.000-07:002013-06-21T05:33:57.666-07:005 common problems of (our) test code<p>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 <em>bad test code which will make your life miserable in the long run</em>.</p>
<p>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 <a href="http://coderetreat.org">Coderetreat</a> events in the <a href="http://coderetreat.cz">Czech Republic</a> so I have probably seen it all. Good stuff as well as bad stuff. :)</p>
<p>So without further ado, here is the list:</p>
<a name='more'></a>
<h4>
<a name="test-is-not-being-executed-at-all" class="anchor" href="#test-is-not-being-executed-at-all"><span class="mini-icon mini-icon-link"></span></a>Test is not being executed at all</h4>
<p>This problem is common when you write the test after you are done writing your production code. It happens when you place test file in a wrong directory, you forget test annotation required by your test framework or there is some other reason that your test is not visible to the test runner. <strong>This problem is pretty hard to spot because everything seems fine, and all the tests are passing.</strong></p>
<p>This comes with all the benefits of dead code hanging around. It will eventually get out of sync with the production code, and person who will encounter it will probably get really confused. It's even worse when combined with other smells.</p>
<p><em>Solution</em>: <strong>Make sure that you see your test fail!</strong> Just break your production code and see that it will get noticed by your test suite when you run it. This way you will ever commit test which is not being executed. If your development environment differs from others (e.g. CI build server environment) make sure that your test will actually get executed everywhere it needs to run.</p>
<h4>
<a name="too-generic-test-names" class="anchor" href="#too-generic-test-names"><span class="mini-icon mini-icon-link"></span></a>Too generic test names</h4>
<p>Sometimes, when programmers are being lazy, they will not take the time to name the tests appropriately.</p>
<p>Example:</p>
<pre><code>sub test_foo : Tests {
is(foo(2, 2), 4);
}
</code></pre>
<p>This name just says that it's hopefully going to test <code>foo</code> function somehow. There is no way for the reader to tell whether the actual test makes sense or even what's the purpose of the <code>foo</code> method. Does it sum the numbers? Multiply them? Or does it simply returns number 4 for any given input? Good test names should make it clear what's being tested, and they should also reveal purpose of the production code (which should also use good naming).</p>
<p><strong>Is it hard to come up with good name for given test?</strong> Your production code may be the problem. Maybe your code does too much or you really don't have an idea what it should actually do? Listen to your tests while you are writing them and fix the problem right away.</p>
<p>Improved example:</p>
<pre><code># better
sub test_foo__returns_sum_of_given_numbers {
is(foo(2, 2), 4);
}
# Test::Spec
describe "foo" => sub {
it "returns sum of given numbers" => sub {
is(foo(2, 2), 4);
};
it "returns 0 for empty input" => sub { ... }
};
</code></pre>
<p>Some test frameworks make writing good test names easier than others. Examples are <a href="http://rspec.info">RSpec</a> for Ruby, <a href="https://metacpan.org/module/Test::Spec">Test::Spec</a> for Perl, ...</p>
<p><em>Solution</em>: Just ask yourself whether it would be possible to <strong>dump existing production code, and rewrite it from scratch just by looking at the tests</strong>.</p>
<h4>
<a name="unhelpful-failure-messages" class="anchor" href="#unhelpful-failure-messages"><span class="mini-icon mini-icon-link"></span></a>Unhelpful failure messages</h4>
<p>Oh man how I love when I break some test, and I get error message which tells me that there might or might not be a problem. Somewhere.</p>
<p><em>Solution</em>: When you are writing test, <em>make it fail</em>, and <strong>check the error message</strong>. Is it obvious from the message what went wrong, and does it point you in the right direction? No? Chances are that you might improve your test code so that it fails in more helpful way. <strong>It might force you to write different test or even alter your production code.</strong> But that's OK, and it's definitely worth it.</p>
<h4>
<a name="setup-data-that-doesnt-affect-test-result" class="anchor" href="#setup-data-that-doesnt-affect-test-result"><span class="mini-icon mini-icon-link"></span></a>Setup data that doesn't affect test result</h4>
<p>Most of the tests require some setup data. Chances are that in order to create this setup data you need even more data which is unrelated to given test. Let's look at this example:</p>
<pre><code>sub order_is_not_valid_when_customers_email_is_invalid : Tests {
my $customer = Customer->new(
name => 'John Doe',
email => 'invalid-email.com'
};
my $order = Order->new(
customer => $customer
);
ok not $order->is_valid;
}
</code></pre>
<p>We are testing <code>Order</code> but it requires <code>Customer</code>. In order to create <code>Customer</code> we have to supply <code>name</code> but production code doesn't care about the name.</p>
<p><em>Solution</em>: Move unrelated stuff out of the test. Use builders and variables with good names defined outside of the test. This will not only make your test more readable but also less fragile as it follows DRY principle.</p>
<pre><code>sub order_is_not_valid_when_customers_email_is_invalid : Tests {
my $order = Order->new(
customer => build_customer(email => $any_invalid_email)
);
ok not $order->is_valid;
}
</code></pre>
<h4>
<a name="magic-values" class="anchor" href="#magic-values"><span class="mini-icon mini-icon-link"></span></a>Magic values</h4>
<p>Test code should follow same principles as clean production code. So it should not contain magic values. </p>
<p><em>Solution</em>: Put your test data into variables with good names so that they reveal intent clearly. E.g. use <code>$any_invalid_email</code> instead of <code>'%#$@%$@#%@#$'</code>.</p>
<h4><a name="conclusion" class="anchor" href="#conclusion"><span class="mini-icon mini-icon-link"></span></a>Conclusion</h4>
<p>In order to get most out of your test suite you should keep it in a good shape. Tests should be there to make future changes of your software easier. If they make your life harder while you are fixing bugs or introducing new features, chances are that your test suite has a problem and you should do something about it. Or it may be that you didn't listen to your tests carefully enough while you were writing them and you production code sucks now.</p>
<p>In this post I wanted to share common problems of our test code. But there is a lot more to writing useful test suites. If you want to learn about this stuff I recommend books "Test-Driven Development By Example", "Growing Object-Oriented Software Guided by Tests" or "The Art of Unit Testing".</p>
<p>If you speak Czech, then you might be interested in articles about TDD by <a href="http://blog.kolman.cz/search/label/TDD">Daniel Kolman</a> or <a href="http://rarous.net/weblog/tag/tdd.aspx">Aleš Roubíček</a>. You might also want to attend future <a href="http://coderetreat.cz">CodeRetreat.cz</a> events where we practice (not only) TDD.</p>
Marian Schuberthttp://www.blogger.com/profile/05554845434051483299noreply@blogger.com0tag:blogger.com,1999:blog-6317788151852287015.post-65305973580638239322013-04-19T02:11:00.001-07:002013-04-28T06:26:31.842-07:00Using The Command Line <p>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.</p>
<p>This post is based on one of my internal presentations which I created
for my teammates at <a href="http://www.netsafe.cz">Netsafe</a>. It assumes that
you are already familiar with the CLI.</p>
<a name='more'></a>
<p>I'll try to summarize stuff that I find most useful and that I wish I
had known back when I started using Linux. It will certainly not cover
everything as I think that's not even possible. The journey to
mastering the CLI is endless anyways. :)</p>
<p>I'm using BASH as my shell, so some things might differ if you use
something else.</p>
<h4>
<a name="keyboard-shortcuts" class="anchor" href="#keyboard-shortcuts"><span class="mini-icon mini-icon-link"></span></a>Keyboard Shortcuts</h4>
<p>In order to use the CLI efficiently it's good to know some basic keys
to move around and edit text. By default BASH uses Emacs-like keyboard
shortcuts. There is also a VI-like mode but I'm not going to cover
that.</p>
<p>Please note that most of these key bindings also work in other
programs (e.g. mysql) which use the readline library to handle user
input. Some of them even work in OSX GUI applications.</p>
<h5>
<a name="movement" class="anchor" href="#movement"><span class="mini-icon mini-icon-link"></span></a>Movement</h5>
<ul>
<li>
<code>Ctrl-a</code> Move the cursor to the start of the line</li>
<li>
<code>Ctrl-e</code> Move the cursor to the end of the line</li>
<li>
<code>Alt-f</code> Move forward a word</li>
<li>
<code>Alt-b</code> Move backward a word</li>
</ul><p><a href="https://a248.e.akamai.net/camo.github.com/861a37411d2092de4a08de4c715aa90c42b1eb21/687474703a2f2f6d61696f2e637a2f746d702f636c692d6d6f76656d656e742e676966" target="_blank"><img src="https://a248.e.akamai.net/camo.github.com/861a37411d2092de4a08de4c715aa90c42b1eb21/687474703a2f2f6d61696f2e637a2f746d702f636c692d6d6f76656d656e742e676966" alt="movement" style="max-width:100%;"></a></p>
<h5>
<a name="editing" class="anchor" href="#editing"><span class="mini-icon mini-icon-link"></span></a>Editing</h5>
<ul>
<li>
<code>Alt-Backspace</code> Kill the previous word</li>
<li>
<code>Alt-d</code> Kill to the end of the word</li>
<li>
<code>Ctrl-u</code> Kill to the beginning of the line</li>
<li>
<code>Ctrl-k</code> Kill to the end of the line</li>
<li>
<code>Ctrl-y</code> Paste the previously killed text</li>
<li>
<code>Ctrl-_</code> Undo</li>
</ul><p><a href="https://a248.e.akamai.net/camo.github.com/664570e854adc72d691a742756f23454234a9609/687474703a2f2f6d61696f2e637a2f746d702f636c692d65646974696e672e676966" target="_blank"><img src="https://a248.e.akamai.net/camo.github.com/664570e854adc72d691a742756f23454234a9609/687474703a2f2f6d61696f2e637a2f746d702f636c692d65646974696e672e676966" alt="editing" style="max-width:100%;"></a></p>
<ul>
<li>
<code>Alt-.</code> Paste the last argument of the previous command (hit again
to get older items)</li>
</ul><p><a href="https://a248.e.akamai.net/camo.github.com/5a4548dc953378a26f5bbcb083fd65e98eaf5a42/687474703a2f2f6d61696f2e637a2f746d702f636c692d6c6173742d6172672e676966" target="_blank"><img src="https://a248.e.akamai.net/camo.github.com/5a4548dc953378a26f5bbcb083fd65e98eaf5a42/687474703a2f2f6d61696f2e637a2f746d702f636c692d6c6173742d6172672e676966" alt="last-arg" style="max-width:100%;"></a></p>
<p>Personally I find <code>Alt-.</code> super useful. I'm using it several times a
day instead of manually doing copy&paste using mouse or retyping the
thing.</p>
<h5>
<a name="history" class="anchor" href="#history"><span class="mini-icon mini-icon-link"></span></a>History</h5>
<ul>
<li>
<code>Ctrl-r</code> Incrementally search the line history (hit again to get older items)</li>
<li>
<code>Ctrl-g</code> Abort an incremental search and restore the original line</li>
<li>
<code>Ctrl-p</code> Previous item in history</li>
<li>
<code>Ctrl-n</code> Next item in history</li>
</ul><p><a href="https://a248.e.akamai.net/camo.github.com/781a87154e66fdd94a5db437c0e0591dea3b505f/687474703a2f2f6d61696f2e637a2f746d702f636c692d686973746f72792e676966" target="_blank"><img src="https://a248.e.akamai.net/camo.github.com/781a87154e66fdd94a5db437c0e0591dea3b505f/687474703a2f2f6d61696f2e637a2f746d702f636c692d686973746f72792e676966" alt="history" style="max-width:100%;"></a></p>
<h5>
<a name="others" class="anchor" href="#others"><span class="mini-icon mini-icon-link"></span></a>Others</h5>
<ul>
<li>
<code>Ctrl-l</code> Clear the terminal</li>
<li>
<code>Ctrl-d</code> Exit shell</li>
</ul><h4>
<a name="directrory-structure-navigation" class="anchor" href="#directrory-structure-navigation"><span class="mini-icon mini-icon-link"></span></a>Directrory structure navigation</h4>
<p>In CLI one uses the <code>cd</code> command to change the current directory. Plain <code>cd</code>
without any argument switches the current directory to the user's home. It's
the same as typing <code>cd ~</code>.</p>
<p>There are a few tricks which make jumping around easier.</p>
<ul>
<li>
<code>cd -</code> switches to the previous directory (can be used multiple times to jump back and forth)</li>
</ul><p><a href="https://a248.e.akamai.net/camo.github.com/6557afddd050b7eba1bb187fc5481c70e459198a/687474703a2f2f6d61696f2e637a2f746d702f636c692d63642e676966" target="_blank"><img src="https://a248.e.akamai.net/camo.github.com/6557afddd050b7eba1bb187fc5481c70e459198a/687474703a2f2f6d61696f2e637a2f746d702f636c692d63642e676966" alt="cd" style="max-width:100%;"></a></p>
<ul>
<li>
<code>CDPATH</code> - By default <code>cd some-dir</code> changes to <code>some-dir</code> located in
the current directory. If you have a bunch of directories which you
visit often, you can make your life easier with <code>CDPATH</code>. For
example, if you keep all your projects in <code>~/Projects</code>, you can
append this path to <code>CDPATH</code> and use <code>cd project-name</code> to jump to
the given project. It doesn't matter what your current directory is
at the time you run <code>cd</code>.</li>
</ul><p><a href="https://a248.e.akamai.net/camo.github.com/ab330a3406b7581ce9ec02a9fea891b45c873e9d/687474703a2f2f6d61696f2e637a2f746d702f636c692d6364706174682e676966" target="_blank"><img src="https://a248.e.akamai.net/camo.github.com/ab330a3406b7581ce9ec02a9fea891b45c873e9d/687474703a2f2f6d61696f2e637a2f746d702f636c692d6364706174682e676966" alt="cdpath" style="max-width:100%;"></a></p>
<h4>
<a name="completion" class="anchor" href="#completion"><span class="mini-icon mini-icon-link"></span></a>Completion</h4>
<p>If you have the <code>bash-completion</code> package installed and enabled you
will be able to complete almost anything using the <code>TAB</code> key. This
includes directory names, commands, command switches, git branches,
server names, environment variables and so on. If you hit <code>TAB</code>
multiple times it will show possible completions.</p>
<p><a href="https://a248.e.akamai.net/camo.github.com/6778d0fecc6096e4033d94ff44e4f85226191627/687474703a2f2f6d61696f2e637a2f746d702f636c692d636f6d706c6574696f6e2e676966" target="_blank"><img src="https://a248.e.akamai.net/camo.github.com/6778d0fecc6096e4033d94ff44e4f85226191627/687474703a2f2f6d61696f2e637a2f746d702f636c692d636f6d706c6574696f6e2e676966" alt="completion" style="max-width:100%;"></a></p>
</ul><p>Thanks kotfic and pkkm (of #emacs fame) for the grammar check. :)</p>Marian Schuberthttp://www.blogger.com/profile/05554845434051483299noreply@blogger.com0tag:blogger.com,1999:blog-6317788151852287015.post-64736191530085853152010-11-14T06:28:00.000-08:002013-04-28T06:25:41.614-07:00Using Vim for iPhone test-driven developmentFew weeks ago I started toying with an idea of developing iPhone applications. Unfortunately I had never used Xcode or even Mac before so my first encounter with these things wasn't completely painless. After one or two small test applications when I got used to Objective-C and iPhone SDK I realized that I need to customize few things.<br />
<a name='more'></a>
<br />
First of all I had to swap Xcode's editor for <a href="http://www.vim.org/">Vim</a> which is my editor of a choice. I installed <a href="http://code.google.com/p/macvim/">MacVim</a> and configured it as the default editor for all text files in Xcode (Preferences > File Types).<br />
<br />
Now that I got Vim working with Xcode I had to solve another problem, which is essential for me when developing software and that's how to write and run unit-tests. There is really nice documentation at Apple's developers site about <a href="http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iphone_development/135-Unit_Testing_Applications/unit_testing_applications.html">Unit Testing Applications</a> so first part was no-brainer.<br />
<br />
In order to run the tests from Vim I had to find out how to run them from a command-line. That's also pretty easy using <b>xcodebuild</b> script which comes with Xcode.<br />
<br />
I have created a <b>Makefile</b> so I could use <b>make test</b> to run the tests with ease.<br />
<br />
<h4>Makefile</h4><script src="https://gist.github.com/666351.js?file=Makefile">
</script><br />
<br />
To make it work with Vim's <a href="http://vimdoc.sourceforge.net/htmldoc/quickfix.html#quickfix">quickfix</a> I modified my .vimrc so it catches errors and warnings. Also I did set it to run the tests after each save of a .m or .h file.<br />
<br />
<h4>.vimrc</h4><script src="https://gist.github.com/666351.js?file=.vimrc">
</script><br />
<br />
All this made me more confortable so I could focus on actual coding instead of fighting with the Xcode's editor. In next post I would like to show how to make test execution even more automatic and less distracting using <a href="https://github.com/guard/guard">guard</a> and <a href="http://growl.info/">Growl</a>.Marian Schuberthttp://www.blogger.com/profile/05554845434051483299noreply@blogger.com1