SoNerdy LLCThis is my blog about technology or whatever else is on my mind.https://sonerdy.com/
Testing Elixir<p>I’ve posted in the past on <a href="/elixir/2016/08/05/elixir-without-mocks.html">avoiding mocks in Elixir</a>.
I decided to give some more thorough explanation and examples in the form of video.
I had fun with this one. The video explains common patterns for isolated testing without mocking.
I also quickly cover the <a href="https://hex.pm/packages/double">Double</a> library that I wrote for building injectable stubs for this kind of testing.</p>
<iframe width="560" height="315" src="//www.youtube.com/embed/cyU_SFyVRro" frameborder="0" allowfullscreen=""></iframe>
Fri, 21 Apr 2017 00:00:00 +0000https://sonerdy.com/elixir/2017/04/21/testing-elixir.html
https://sonerdy.com/elixir/2017/04/21/testing-elixir.htmlMicroCast 03 - Elixir Railway Programming<p>Piping functions together is really convenient in many cases, but sometimes you need
more advanced error condition handling.</p>
<h2 id="well-cover">We’ll cover</h2>
<ul>
<li>The problem with piping functions together</li>
<li>Railway programming in Elixir - http://www.zohaib.me/railway-programming-pattern-in-elixir/</li>
<li>:ok and :error tuples</li>
<li>One workaround: using ‘with’</li>
</ul>
Thu, 29 Dec 2016 00:00:00 +0000https://sonerdy.com/elixir/2016/12/29/micro-cast-03-elixir-railway-programming.html
https://sonerdy.com/elixir/2016/12/29/micro-cast-03-elixir-railway-programming.htmlMicroCast 02 - Elixir Avoiding Mocks<p>From a Ruby/RSpec background, it may seem odd that mocking is discouraged in most cases in Elixir. In this case we're going to talk about why that is, and do some live coding on examples.</p>
<h2>We'll cover</h2>
<ul>
<li>The existence of mocking libraries</li>
<li>Stubbing dependencies</li>
<li>Getting "Mock" behavior without a library
<ul>
<li>Setting up return values</li>
<li>Verifying parameters</li>
<li>Using built-in message passing</li>
</ul>
</li>
</ul>Tue, 20 Dec 2016 00:00:00 +0000https://sonerdy.com/elixir/2016/12/20/micro-cast-02-elixir-avoid-mocks.html
https://sonerdy.com/elixir/2016/12/20/micro-cast-02-elixir-avoid-mocks.htmlMicroCast 01 - Elixir Inline Docs<p>
Elixir provides really cool built-in documentation features.
Let's take a looks at some of that!
</p>
<h2>We'll cover</h2>
<ul>
<li>Reading documentation from iex console</li>
<li>Reading documentation from VIM</li>
<li>Other documentation resources</li>
<li>How to write your own docs?</li>
</ul>
Fri, 09 Dec 2016 00:00:00 +0000https://sonerdy.com/elixir/2016/12/09/micro-cast-01-elixir-inline-docs.html
https://sonerdy.com/elixir/2016/12/09/micro-cast-01-elixir-inline-docs.htmlElixir Without Mocks - A Succinct Example<p>Wrapping my head around why mocking is less favored in Elixir than in Ruby (and other languages).
Here's an example asserting that a function is called and matching the arguments without any mocking tools.</p>
<figure class="highlight"><pre><code class="language-elixir" data-lang="elixir"><span class="k">defmodule</span> <span class="no">NoMocksTest</span> <span class="k">do</span>
<span class="kn">use</span> <span class="no">ExUnit</span><span class="o">.</span><span class="no">Case</span>
<span class="n">test</span> <span class="sd">"</span><span class="s2">says hello to the console"</span> <span class="k">do</span>
<span class="no">NoMocks</span><span class="o">.</span><span class="n">process</span><span class="p">(</span><span class="n">io_stub</span><span class="p">)</span>
<span class="n">assert_receive</span> <span class="p">{</span><span class="ss">:puts</span><span class="p">,</span> <span class="sd">"</span><span class="s2">hello"</span><span class="p">}</span>
<span class="k">end</span>
<span class="k">defp</span> <span class="n">io_stub</span> <span class="k">do</span>
<span class="p">%{</span><span class="ss">puts:</span> <span class="k">fn</span><span class="p">(</span><span class="n">msg</span><span class="p">)</span> <span class="o">-&gt;</span> <span class="n">send</span><span class="p">(</span><span class="n">self</span><span class="p">(),</span> <span class="p">{</span><span class="ss">:puts</span><span class="p">,</span> <span class="n">msg</span><span class="p">})</span> <span class="k">end</span><span class="p">}</span>
<span class="k">end</span>
<span class="k">end</span>
<span class="k">defmodule</span> <span class="no">NoMocks</span> <span class="k">do</span>
<span class="nv">@io</span> <span class="p">%{</span><span class="ss">puts:</span> <span class="o">&amp;</span><span class="no">IO</span><span class="o">.</span><span class="n">puts</span><span class="o">/</span><span class="m">1</span><span class="p">}</span>
<span class="k">def</span> <span class="n">process</span><span class="p">(</span><span class="n">io</span> <span class="p">\\</span> <span class="nv">@io</span><span class="p">)</span> <span class="k">do</span>
<span class="n">io</span><span class="o">.</span><span class="n">puts</span><span class="o">.</span><span class="p">(</span><span class="sd">"</span><span class="s2">hello"</span><span class="p">)</span>
<span class="k">end</span>
<span class="k">end</span></code></pre></figure>
Fri, 05 Aug 2016 00:00:00 +0000https://sonerdy.com/elixir/2016/08/05/elixir-without-mocks.html
https://sonerdy.com/elixir/2016/08/05/elixir-without-mocks.htmlSQL Footprint - A gem for working with legacy Rails apps<p>I just wanted to leave some notes on <a href="https://github.com/covermymeds/sql_footprint">a new gem</a> that I and some folks from my day job put together to solve a couple of specific problems. The sql_footprint gem tracks queries that ActiveRecord uses when you run your tests, and creates a footprint.sql file showing what queries are actually being executed. It also canonicalizes and dedupes similar queries so you're just seeing unique types of queries in the footprint.</p>
<h2>Why is this useful?</h2>
<ul>
<li>Helps to identify potentially dangerous/bottleneck queries more clearly within pull requests/code review.</li>
<li>Helps to identify db dependencies when breaking a monolith architecture down into separate services and databases.</li>
</ul>
<h2>Identifying bottlenecks</h2>
<p>SQL Footprint shows you when you're doing something in the DB that hasn't already been done. Imagine finding this code in a pull request:</p>
<p><figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"> <span class="no">Customer</span><span class="p">.</span><span class="nf">where</span><span class="p">(</span><span class="ss">last_name: </span><span class="s2">"Smith"</span><span class="p">)</span> </code></pre></figure></p>
<p>Seems harmless, but do we already query by last name in our app? Rather than search your entire code base looking for queries that might be doing something similar, you can simply look at your SQL Footprint:</p>
<p><figure class="highlight"><pre><code class="language-sql" data-lang="sql"> <span class="k">Select</span> <span class="o">*</span> <span class="k">from</span> <span class="n">customers</span> <span class="k">where</span> <span class="n">last_name</span> <span class="o">=</span> <span class="s1">'value-redacted'</span><span class="p">;</span> </code></pre></figure></p>
<p>If you see this in the diff for your sql footprint, you know you're breaking new ground with this query. You should probably talk to your database folks about any optimization concerns. Likewise if you see the removal of expensive queries, maybe you can go ask your DBAs to buy you a beer? SQL Footprint buys you beer. That's just how it works. :)</p>
<h2>Breaking down monoliths</h2>
<p>One of the things that can be difficult in breaking a monolith architecture into smaller services is deciding if/when/how to break down the monolith sql database that you likely have all your data in. SQL Footprint is just one way of getting a good view of what objects in your database are depended upon by application components. Especially if you're taking the approach of breaking things into APIs/Microservices before splitting the DB. By getting a service-by-service footprint, you should be able to see where database dependencies overlap and where they don't. For example, if your "CustomerService" is the only service that ever touches the customers table, you know you can (if you want) pull that table into it's own database and let the custoemrs service "own" that.</p>
<p>Hope this is useful for some of you! I know we're making great use of it so far. Let me know if you have any questions or suggestions for improvement.</p>Tue, 31 May 2016 00:00:00 +0000https://sonerdy.com/ruby/2016/05/31/sql-footprint.html
https://sonerdy.com/ruby/2016/05/31/sql-footprint.htmlSaving a Base64 Encoded File w/ Elixir<p>Just wanted to document this for future use:</p>
<figure class="highlight"><pre><code class="language-elixir" data-lang="elixir"><span class="p">{</span><span class="ss">:ok</span><span class="p">,</span> <span class="n">data</span><span class="p">}</span> <span class="o">=</span> <span class="no">Base</span><span class="o">.</span><span class="n">decode64</span><span class="p">(</span><span class="n">base64_string</span><span class="p">)</span>
<span class="no">File</span><span class="o">.</span><span class="n">write</span><span class="p">(</span><span class="sd">"</span><span class="s2">/tmp/file.gif"</span><span class="p">,</span> <span class="n">data</span><span class="p">,</span> <span class="p">[</span><span class="ss">:binary</span><span class="p">])</span></code></pre></figure>
<p>That's it!</p>
Mon, 23 May 2016 00:00:00 +0000https://sonerdy.com/elixir/2016/05/23/saving-base64-encoded-file-in-elixir.html
https://sonerdy.com/elixir/2016/05/23/saving-base64-encoded-file-in-elixir.htmlFixing Single Responsibility Principle<p>Sara Mei's talk at Windy City Rails (<a href="https://vimeo.com/136245794" target="_blank">Is Your Code Too SOLID?</a>) this year got me thinking.</p>
<p>Single Responsibility Principle is broken!</p>
<p>
Don't get me wrong. I love SRP.
<a href="http://articles.coreyhaines.com/">Corey Haines</a> once told me that SRP is likely the basis for all other principles and patterns.
That may or may not be true, but the fact is, this principle is super important and well known among software developers.
</p>
<h2>Single Responsibility Principle (According to Uncle Bob)</h2>
<blockqoute>
<p>
A class should have one, and only one, reason to change.
</p>
<footer><cite title="Uncle Bob">Uncle Bob</cite></footer>
</blockquote>
<p>I know this isn't the only definition of SRP, but it's a common one that a lot of people are first introduced to.</p>
<p>How could it be that something so fundamental to the way we write code could be flawed?
I think the answer lies in the many discussions I've had about SRP:
"If you exactly follow SRP, your code will be terrible." or "You can take it too far."
I don't hear that nearly as much about other principles.
Why is that?</p>
<p>I think the reason for this lies in the word "single" and the phrasing of "only one reason".
A design that truly attempts to break down classes to the level that you could only conceive of one reason to change that class is not always the most communicative design.
Sometimes, it's best to keep a couple of closely related "responsibilities" together in a class just for clarity.
This is especially true when those two responsibilities are not very complex.
Also, you can usually move these things to separate classes later as the design grows and changes.
I think this is typically what people mean when they are looking for that "right" level of SRP in their design.</p>
<p>Having said all that, I am merely suggesting that we slightly refine this principle to more accurately represent this pragmatic process for applying SRP in our design.
In keeping with the "S" in solid, I think this would be a more appropriate principal:</p>
<h2>Suitable Responsibility Principle</h2>
<blockquote>Every class should have a minimum and cohesive set of reasons to change.</blockquote>
<p>This principle is less specific about an ideal number of reasons for change, but highlights the importance that these reasons must be cohesive.
We're leaving room for pragmatism while still clearly defining what makes objects too complex.</p>
<p>Maybe I've got the wrong idea here.
Maybe principles are supposed to be more mathematic and exact.
I just think "Suitable Responsibility Principle" more effectively encourages an appropriate design for the situation.
</p>
<p>I'm very curious to see what folks think! Please comment!</p>
Thu, 17 Sep 2015 00:00:00 +0000https://sonerdy.com/general/2015/09/17/fixing-single-responsibility-principle.html
https://sonerdy.com/general/2015/09/17/fixing-single-responsibility-principle.htmlPragmatic Testing With Webmock<p>CoverMyMeds has posted my blog post on a pragmatic approach to testing HTTP heavy applications with webmock.
Check it out on ScriptScribe: <a href="https://www.scriptscribe.org/testing/pragmatic-testing-with-webmock/">Pragmatic Testing With Webmock</a></p>
Wed, 15 Apr 2015 00:00:00 +0000https://sonerdy.com/ruby/2015/04/15/pragmatic-testing-with-webmock.html
https://sonerdy.com/ruby/2015/04/15/pragmatic-testing-with-webmock.htmlTop 3 Reasons Why Dependency Injection Containers Are Not Idiomatic Ruby<p>If you aren't already aware of what dependency injection (and containers) are then you should begin by reading my post <a href="/general/2014/12/30/what-is-dependency-injection.html">What Is Dependency Injection?</a></p>
<p>A little over 6 months ago I took a full-time Ruby development job at <a href="https://www.covermymeds.com">CoverMyMeds</a>.
My past has primarily been as a Microsoft stack developer, but I've dabbled with Ruby (and other languages) for side projects since around 2008.
Going full-time with Ruby made me want to work much harder on making sure my Ruby code was idiomatic.
I've learned some really cool things, but one thing that was somewhat challenging was giving up dependency injection.
This post will cover the top 3 reasons I think dependency injection has diminished value in Ruby.</p>
<h2>Isolated Testing Doesn't Require Abstract Types In Ruby</h2>
<p>In a static language like C#, you'll typically want to depend on an interface so you can use stubbed or mocked implementations during testing.
In a dynamic language like Ruby, the interface isn't needed.
Also, you can stub methods on objects even without injecting your own implementation.
Here's an example test using RSpec to setup expectations.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"> <span class="n">describe</span> <span class="s2">"MyObject"</span> <span class="k">do</span>
<span class="n">subject</span> <span class="p">{</span> <span class="no">MyObject</span><span class="p">.</span><span class="nf">new</span> <span class="p">}</span>
<span class="n">let</span><span class="p">(</span><span class="ss">:test_data</span><span class="p">)</span> <span class="p">{</span> <span class="p">[</span> <span class="s1">'testing'</span><span class="p">]</span> <span class="p">}</span>
<span class="n">it</span> <span class="s2">"gets data from a dependency"</span> <span class="k">do</span>
<span class="c1">#stubbing the Dependency.get_data method to return whatever we want</span>
<span class="n">expect</span><span class="p">(</span><span class="no">Dependency</span><span class="p">).</span><span class="nf">to</span> <span class="n">receive</span><span class="p">(</span><span class="ss">:get_data</span><span class="p">).</span><span class="nf">and_return</span><span class="p">(</span><span class="n">test_data</span><span class="p">)</span>
<span class="n">subject</span><span class="p">.</span><span class="nf">process</span>
<span class="k">end</span>
<span class="k">end</span></code></pre></figure>
<h2>Simplified Initializers</h2>
<p>One of the advantages of using a container for dependency injection in C# is that you can avoid using the 'new' keyword.
This means that the constructor signature can change without going through your code and changing every place that this class is being instantiated.
In Ruby however, if you're avoiding the dependency injection pattern altogether, then you are much less likely to suffer from this problem.
Adding a dependency to a Ruby class doesn't typically change the initializer.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"> <span class="k">class</span> <span class="nc">Customer</span>
<span class="c1"># these parameters stick to domain related things</span>
<span class="k">def</span> <span class="nf">initialize</span> <span class="nb">name</span>
<span class="vi">@name</span> <span class="o">=</span> <span class="nb">name</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">save</span>
<span class="no">Database</span><span class="p">.</span><span class="nf">save</span> <span class="nb">self</span>
<span class="c1">#We can add a dependency on a logging class without injecting it</span>
<span class="no">Logger</span><span class="p">.</span><span class="nf">log</span> <span class="s2">"Saving customer: </span><span class="si">#{</span><span class="nb">self</span><span class="p">.</span><span class="nf">name</span><span class="si">}</span><span class="s2">"</span>
<span class="k">end</span>
<span class="k">end</span></code></pre></figure>
<p>This might seem super-obvious, but if you're used to C# like me, you know what it's like to be bitten by code like this when trying to isolate classes for testing.
Remember though, that's not a problem anymore because of #1!</p>
<p>Another nifty thing you might utilize would be hash initializers.</p>
<h2>Dependency Injection Without a Container</h2>
<p>You don't need a container to do dependency injection!
If you have a case where you really want to pass dependencies in to the initializer, just do it.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"> <span class="c1">#instead of this</span>
<span class="k">class</span> <span class="nc">MyObject</span>
<span class="k">def</span> <span class="nf">process</span>
<span class="no">Dependency</span><span class="p">.</span><span class="nf">new</span><span class="p">.</span><span class="nf">get_data</span>
<span class="k">end</span>
<span class="k">end</span>
<span class="c1">#do this!</span>
<span class="k">class</span> <span class="nc">MyObject</span>
<span class="k">def</span> <span class="nf">initialize</span> <span class="n">dependency</span>
<span class="vi">@dependency</span> <span class="o">=</span> <span class="n">dependency</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">process</span>
<span class="vi">@dependency</span><span class="p">.</span><span class="nf">get_data</span>
<span class="k">end</span>
<span class="k">end</span></code></pre></figure>
<p>The great thing is that you're not preemptively doing this just for testing purposes.
You can use this when it fits into your design, and avoid it otherwise.
And no need to define an interface. Yay dynamic typing!</p>
<p>If you want to hear me babble about this topic in a lightning talk at Steel City Ruby Conf, check out the video! This was a spontaneous talk so I didn't cover everything I wanted, but I did my best!</p>
<iframe width="560" height="315" src="//www.youtube.com/embed/nHl5Fx5KK6U" frameborder="0" allowfullscreen></iframe>
<p>As always, I'm curious for feedback.</p>
Wed, 31 Dec 2014 00:00:00 +0000https://sonerdy.com/ruby/2014/12/31/top-3-reasons-dependency-injection-not-idiomatic-ruby.html
https://sonerdy.com/ruby/2014/12/31/top-3-reasons-dependency-injection-not-idiomatic-ruby.html