Matt Briggs

"Not all code needs to be a factory, some of it can just be origami" -why, the lucky stiff

Mixins Are Not Always a Refactoring Anti-pattern

| Comments

Steve Klabnik just posted an interesting post about mixins. Steve is a really smart guy, and I usually agree with him, but I think his justification is a little bit weak in this case.

Mixin Refactoring through Class Gutting

Oh man, he is so right that this is an anti-pattern. It happens a lot in ruby, someone says “Hey, this thing is doing too much. The only method of code reuse I really believe in is mixins, so I’ll just take the implementation, and dump it into a mixin.”

By doing that, you haven’t decreased complexity, you have actually increased it by breaking locality. Steve introduces the idea of reducing complexity through ecapsulation (right on), and talks about Data Mapper and Repository. Very OOP, and great solutions, especially in larger systems. Still diggin what Steve has to say.

Method Count as a metric of complexity

Here is where we part ways. Lets take the Enumerable module in the ruby standard library. It adds 94 methods on to a given thing, with the requirement that that “thing” provides an each method.

But enumerable is an “idea”, and if something is enumerable, you sort of know how to work with it — through those 94 methods.

Steve talks about how encapsulation reduces complexity of the implementation, well Enumerable encapsulates the “idea” of enumerating. So that means that when providing a public interface, a data structure can focus on its fairly simple implementation, and only provide the most low level and simplist of methods (each), while bringing in Enumerable and let it do the heavy lifting to give the rich interface that people expect from a ruby data structure.

How is that increasing complexity? When I look at Enumerable, it is talking about a single concept. When I look at array, it is talking about a single concept. The only thing I can change to break the implicit protocol between the two is to break the each method at a fundamental level.

Composition would have been a terrible choice here, I think providing 94 stub methods and an internal enumerator object would just increase the complexity, not reduce it. Providing an enumerator as an external thing would have made the api much more of a pain to work with. Inheritance would be better then composition or separation, but the problem is that Array is a datastructure, it is not an “Enumerable”. Enumeration is an ability, not the root of a concept. I think the best choice here is mixin, and that it is fairly obviously the best choice. And I think most people who have implemented data structures in ruby would agree.

So what we have is something that is close to inheritance, but more of a “vertical slice” of functionality. An “ability” rather then a “thing”. This is what mixins give up, the ability to model “abilities” in a concise way.

What is complexity

Rich Hickey defines complexity as an interleaving of ideas. I think that is a great definition. In the case of Enumerable, you are providing significant functionality through providing a simple implementation, the only interleaving is that each method. Sure, the runtime method count is 94 methods higher, but who cares? When you are calling methods on array, you are thinking of it as a single thing. When you are maintaining array, you don’t have to worry about any interations with enumerable outside of each.

I think that the amount, and shape, of a mixins interaction with its containing class is a good measure of complexity. The amount and shape of a classes interactions with the internals of a mixin is a great metric of complexity. The only thing the number of runtime methods is telling you is that maybe you should be looking at those other things, which isn’t that great a smell.

The important thing here is interactions.

Large classes often become complex. But it isn’t a property of their runtime method count, or even inherant to their lines of code. It is because large classes and large methods tend to interact in ways that are hard to understand. Small classes can get complex too for the same reasons, but the larger the class, the easier it is to get to that place.

Why “Gut the class and dump” it into a mixin doesn’t work

It doesn’t work because you haven’t tackled the complexity of the interactions in the code. Maybe it needs to get pulled into another class, maybe methods need to get merged together. Or maybe you are just talking about an inherantly complex thing, and doing the earlier things will make it worse. In any case it is not the runtime method count that will tell you this, it is analysis of how the class interacts with itself and others.

Complexity Smells

Steve wasn’t writing about complexity smells in a general way, but since I have spent so much time talking about what isn’t a smell, I sort of feel compelled to talk about what is. I am sure he would agree with most, if not all of the following

  • When a mixin mucks with class internals.
  • When a mixin mucks with other mixins.
  • When you read the inheritor of a class, and can’t understand it without reading its parent
  • When you read an inherited class, but can’t understand it without its children
  • When there are so many interactions with other things that you have to read many classes to understand how a single thing works
  • When classes do too many things
  • When classes have too many dependancies
  • When classes are aware of too many other objects
  • When too many other objects are aware of a class

And that is just the tip of the iceburg. I would say that a significant percentage of our job is managing complexity in code, it is a huge and nuanced topic. Mixins are also not a simple thing, and are extremely easy to use in the wrong ways.

The Many Faces of Ruby Callables

| Comments

One of the most valuable ideas from functional programming is the idea of Higher Order Functions, or functions that take functions as an argument. It is such a good idea that it has become part of pretty much every modern language, whether functional or not. Amoung the OO imperative languages that have embraced this idea, the ruby community has probably gone the furthest, where it is the first tool a library writer will reach for more often then not.

The language feature required for this style of programming is known as first class functions, meaning functions that can be defined as a variable, passed around, and called by other parts of code. Ruby has four constructs for this, which are all similar, but have slight differences.

The Block

The idea behind blocks is sort of a way to implement really light weight strategy patterns. A block will define a coroutine on the function, which the function can delegate control to with the yield keyword. We use blocks for just about everything in ruby, including pretty much all the looping constructs. Anything outside the block is in scope for the block, however the inverse is not true, with the exception that return inside the block will return the outer scope. They look like this

1
2
3
4
5
6
7
8
9
10
def foo
  yield 'called foo'
end

#usage
foo {|msg| puts msg} #idiomatic for one liners

foo do |msg| #idiomatic for multiline blocks
  puts msg
end

Proc

The best way to think of a proc is that it is the more general form of a block. A block is tied to a specifc function (the whole coroutine thing), while a proc is just a variable. This means that you can easily convert a block to a proc.

An interesting use is that you can pass a proc in as a replacement for a block in another method. Ruby has a special character for proc coercion which is &, and a special rule that if the last param in a method signature starts with an &, it will be a proc representation of the block for the method call. Finally, there is a builtin method called block_given?, which will return true if the current method has a block defined. It looks like this

1
2
3
4
5
6
def foo(&block)
  return block
end

b = foo {puts 'hi'}
b.call # hi

To go a little further with this, there is a really neat trick that rails added to Symbol (and got merged into core ruby in 1.9). That & coercion does its magic by calling to_proc on whatever it is next to. So adding a Symbol#to_proc that calls itself on whatever is passed in lets you write some really terse code for any aggregation style function that is just calling a method on every object in a list.

1
2
3
4
5
6
7
8
9
10
class Foo
  def bar
    'this is from bar'
  end
end

list = [Foo.new, Foo.new, Foo.new]

list.map {|foo| foo.bar} # returns ['this is from bar', 'this is from bar', 'this is from bar']
list.map &:bar # returns _exactly_ the same thing

This is fairly advanced stuff, but I think it illustrates the power of this construct.

Lambdas

The purpose of a lambda is pretty much the same as the first class functions in other languages, a way to create an inline function to either pass around, or use internally. Like blocks and procs, lambdas are closures, but unlike the first two it enforces arity, and return from a lambda exits the lambda, not the containing scope. You create one by passing a block to the lambda method, or to –> in ruby 1.9

1
2
3
4
l = lambda {|msg| puts msg} #ruby 1.8
l = -> {|msg| puts msg} #ruby 1.9

l.call('foo') # => foo

Methods

Only serious ruby geeks really understand this one :) A method is a way to turn an existing function into something you can put in a variable. You get a method by calling the method function, and passing in a symbol as the method name. You can re bind a method, or you can coerce it into a proc if you want to show off. A way to re-write the previous method would be

1
2
l = lambda &method(:puts)
l.call('foo')

What is happening here is that you are creating a method for puts, coercing it into a proc, passing that in as a replacement for a block for the lambda method, which in turn returns you the lambda. One thing I often use this for is debugging in concert with tap.

1
[1, 2, 3].map {|i| i * 2}.reduce(:+)

This code maps an array of integers to an array of integers that have been doubled, and then sums them. If you want to see the result of the map, you can do something like this

1
[1, 2, 3].map {|i| i * 2}.tap(&method(:puts)).reduce(:+)

tap will yield the thing that it is called on to a block, and then return the original thing. So what I am doing is saying turn puts (which takes a single argument) into a method, coerce it into a block, and give it as the implementation for tap, meaning just puts out the value. Since tap returns the original thing, the rest of the method chain will be undisturbed.

Going Deeper with &:symbol

Lets say you are really digging the trick of &:sym, and you have a case where the block is going to yield additional arguments, but you actually WANT those arguments to be passed in as well when the Obj.send :sym happens. Symbol#to_proc is basically implemented like this

1
2
3
4
5
class Symbol
  def to_proc
    Proc.new { |obj, *args| obj.send(self, *args) }
  end
end

So, &:sym is going to make a new proc, that calls .send :sym on the first argument passed to it. If any additional args are passed, they are globbed up into an array called args, and then splatted into the send method call.

Ruby is pretty awesome

A lot of these capabilities exist in other languages, but very few imperative OO communities have run with them the way that rubyists have. A deep understanding of the tools available is an important part of any ruby developers journey to becoming an expert at the language. Back when I was looking for some new language to try and was trying to decide whether to roll with ruby or python first, rubys block obsession was what made me go ruby.

Awesome Emacs Plugins: CTags

| Comments

I wanted to write a series of posts on awesome emacs plugins I use, since I have put a lot of time and effort into my emacs configs. The funny thing I find about emacs though is that there is such a massive amount of functionality already provided, most neat things plugins do is augment stuff that is already there. So I think most of these posts are going to be a third about emacs, a third about a plugin, and a third about the glue code tying them together :)

Code Tags

The purpose of tags is to parse a codebase, and provide information about its structure (mostly for the purposes of navigation). There are many tools used to create tag index files, emacs even ships with one called etags.

Tags in Emacs

Coming from vim, one of the things I found was that emacs tag handling was inferior to vims for some reason. Most of the time, when I would do a c-] in vim I would land exactly where I would expect to. In emacs, I would find I needed to jump through the matches far more often to find what I wanted.

CTags

One difference was the tagging program. Vim uses something called exuberant-ctags, while emacs uses something called etags. From what I can tell, for the languages I use (javascript and ruby mostly), exuberant-tags does a noticeably better job.

Thankfully, ctags actually supports the format emacs is expecting, you just have to pass a -e argument. I only had to slightly modify my normal ctags command, and I had

1
ctags -e -R --extra=+fq --exclude=db --exclude=test --exclude=.git --exclude=public -f TAGS

The last thing I want to do is have to jump to a terminal and type that out, so I wrote this quick little function in elisp to do the heavy lifting for me

build-ctags
1
2
3
4
5
6
7
8
9
10
11
12
13
(defun build-ctags ()
  (interactive)
  (message "building project tags")
  (let ((root (eproject-root)))
    (shell-command (concat "ctags -e -R --extra=+fq --exclude=db --exclude=test --exclude=.git --exclude=public -f " root "TAGS " root)))
  (visit-project-tags)
  (message "tags built successfully"))

(defun visit-project-tags ()
  (interactive)
  (let ((tags-file (concat (eproject-root) "TAGS")))
    (visit-tags-table tags-file)
    (message (concat "Loaded " tags-file))))

That may be a bit confusing to people unfamiliar with elisp, so I’ll walk through it

1
2
(defun build-ctags ()
  (interactive)

This part means “Make an elisp function called build-ctags, and mark it as interactive so that it can be invoked via m-x”

1
2
(let ((root (eproject-root)))
    (shell-command (concat "ctags -e -R --extra=+fq --exclude=db --exclude=test --exclude=.git --exclude=public -f " root "TAGS " root)))

This means “Make a variable called root that is the result of the eproject-root function” eproject is another library I will cover some other time, but one thing it gives you is a function that returns the root path of the current project. You could just as easily replace it with (rinari-root) (if you use rinari for rails projects) and it would work just as well. I will assume shell-command is self explanitory :)

1
(visit-tags-table)

The last piece just means replace the currently loaded tag file with whats on the disk.

With that function, my navigation became a bit more comfortable in emacs, but I still found sometimes emacs would bring me to really strange places. After a bit of research, I found the incredibly obscurely named tags-case-fold-search variable. From the docs:

Documentation: *Whether tags operations should be case-sensitive. A value of t means case-insensitive, a value of nil means case-sensitive. Any other value means use the setting of `case-fold-search’.

Setting that to nil helped immensely.

etags-select

Now for the actual plugin :) etags-select If there is a single result, you jump straight to it, but if there are multiple results, it will pop up a window showing them all. n will go to the next match, p to the previous, and enter will select the current result and jump to that line.

I made another small command that I could bind to

1
2
3
4
5
6
7
8
(defun my-find-tag ()
  (interactive)
  (if (file-exists-p (concat (eproject-root) "TAGS"))
      (visit-project-tags)
    (build-ctags))
  (etags-select-find-tag-at-point))

(global-set-key (kbd "M-.") 'my-find-tag)

That function will check if the tags file is there, if it is, read it, if not, build it, then run that plugin function etags-select-find-tag-at-point.

To invoke it, put the point on a symbol and hit M-.

.ctags

Last thing, for some better ctags support for rails, and support for OO javascript, add this to your ~/.ctags

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
--regex-ruby=/(^|[:;])[ \t]*([A-Z][[:alnum:]_]+) *=/\2/c,class,constant/
--regex-ruby=/(^|;)[ \t]*(has_many|belongs_to|has_one|has_and_belongs_to_many)\(? *:([[:alnum:]_]+)/\3/f,function,association/
--regex-ruby=/(^|;)[ \t]*(named_)?scope\(? *:([[:alnum:]_]+)/\3/f,function,named_scope/
--regex-ruby=/(^|;)[ \t]*expose\(? *:([[:alnum:]_]+)/\2/f,function,exposure/
--regex-ruby=/(^|;)[ \t]*event\(? *:([[:alnum:]_]+)/\2/f,function,aasm_event/
--regex-ruby=/(^|;)[ \t]*event\(? *:([[:alnum:]_]+)/\2!/f,function,aasm_event/
--regex-ruby=/(^|;)[ \t]*event\(? *:([[:alnum:]_]+)/\2?/f,function,aasm_event/

--langdef=js
--langmap=js:.js
--regex-js=/([A-Za-z0-9._$]+)[ \t]*[:=][ \t]*\{/\1/,object/
--regex-js=/([A-Za-z0-9._$()]+)[ \t]*[:=][ \t]*function[ \t]*\(/\1/,function/
--regex-js=/function[ \t]+([A-Za-z0-9._$]+)[ \t]*\(([^)])\)/\1/,function/
--regex-js=/([A-Za-z0-9._$]+)[ \t]*[:=][ \t]*\[/\1/,array/
--regex-js=/([^= ]+)[ \t]*=[ \t]*[^"]'[^']*/\1/,string/
--regex-js=/([^= ]+)[ \t]*=[ \t]*[^']"[^"]*/\1/,string/

--exclude=*.min.js
--exclude=.git

Navigating with Emacs

I find my experience now much better then it was before, but there is always room for improvement. Any comments, criticisms, or tips that I am missing would be hugely appreciated :)

Why I Like Object#tap

| Comments

In a recent Destroy All Software screencast, Gary mentioned how he really doesn’t like Object#tap. He was using it in this sort of context

1
2
3
4
5
6
7
8
9
10
class StoreCache
  def self.for_term(term)
  begin
    CachedScore.for_term(term)
  rescue CachedScore::NoScore
    RockScore.for_term(term).tap do |score|
      CachedScore.save_score(term, score)
    end
  end
end

He said he didn’t understand why people like that syntax so much, when you could just as easily do

1
2
3
4
5
6
7
8
9
10
class StoreCache
  def self.for_term(term)
  begin
    CachedScore.for_term(term)
  rescue CachedScore::NoScore
    score = RockScore.for_term(term)
    CachedScore.save_score(term, score)
    score
  end
end

with the differences being that the name of the variable is on the left side, and the return is more explicit. I sort of get where he is coming from, but I would not use tap that way.

What Object#tap means to me

I think he (and many others) see Object#tap as meaning “fancy method that give me a 1 character placeholder variable and implicit return”. I see tap as meaning “tap into the object initialization”, or more practically “This entire expression is related to object initialization.”

Typically, I wont use tap unless there is a high degree of locality, and you are talking about left-side = right-side type code. Something like this

1
2
3
4
5
6
def build_foo
  Foo.new do |f|
    f.bar = "Hi"
    f.baz = "Baz"
  end
end

Building out values on an object is an incredibly common pattern that is logically a single thing. Visually, tap is grouping the code for that pattern. Also, I find it reduces density in a place where the additional verbosity really doesn’t add anything in terms of clarity. At work, we are still using 1.8.7 ree, so when we need ordered hashes (often as identifiers for keys on objects), we have a lot of code that looks like this

1
2
3
4
UNIT_OF_MEASURES = ActiveSupport::OrderedHash
UNIT_OF_MEASURES[1] = "Eaches"
UNIT_OF_MEASURES[2] = "Cases"
UNIT_OF_MEASURES[3] = "Pallets"

I think the move from that to tap style is a significant improvement

1
2
3
4
5
UNIT_OF_MEASURES = ActiveSupport::OrderedHash.tap |uom|
  uom[1] = "Eaches"
  uom[2] = "Cases"
  uom[3] = "Pallets"
end

The last thing is the fact that its a single expression. I love implicit returns in ruby where your entire method is a single expression, it feels kind of lispy. Something like this

me likey
1
2
3
def foo
  some_predicate? ? "Hi!" : "Bye"
end

However, I am really not a fan of implicit returns when you just end a function with a bare word. If you are writing imperative style of code, I think each statement should actually be a statement that says what it does. Something like this just sort of feels like a mis-use of a language feature.

ugh
1
2
3
4
5
def foo
  thing = build_thing
  thing.some_method
  thing
end

This is something that I think falls squarely into personal style. But because of how I enjoy writing more expression oriented code, having an expression for a common pattern is a big plus for me.

Another interesting thing to note is that in rails-land, it is very common to use hash initializers for this kind of thing. Something like this

1
2
3
Post.create! author: current_user,
             published: true,
             category: "some-category"

While that syntax is very minimal, I actually prefer the Object#tap style of api, because I find it gives a clearer separation between plain old method arguments, and object initialization.

1
2
3
4
5
Post.create! do |p|
  p.author = current_user
  p.published = true
  p.category = "some-category"
end

Not Hatin On Gary

The dude is awesome, and everyone who is a professional ruby developer really should subscribe to his podcasts. IMO the guy is a master of OO, and his screencasts are far more valuable then 10$ and 15mins of your life per month.

Awesome Emacs Plugins: Evil Mode

| Comments

I want to do a series of posts on some of the cool emacs plugins I use. Before I do that though, I want to talk a bit about why I use and love emacs. The saying “Care about the code, not the tools” is an anathama to me, it is like “Care about breathing, but don’t worry about drinking”. Breathing is incredibly important, I agree, but consuming liquid regularily is pretty high up there on the list too! Anyways, this is my journey through tooling with working with code. This post is going to be a story of epic proportions, with very little “hard” content, but I plan on doing more posts that are more focused on the awesomeness of emacs plugins.

The Dark Years: Integrated Development Enviornments

I used IDEs for years, and while I appreciated the power, there was some things missing. The first thing was even with plugins, the barrier to customization was quite high. I love solving problems with code, and while solving other peoples problems is a fun and interesting (and profitable) endevour, solving your own problems is usually far more satisfying. Second, they are by their nature, built for a specific language and platform. Lastly, they are quite slow, and require quite a bit of resources. At my last job, it would take almost 7 minutes to go from a reboot to everything up and pointing to the right things. Now, even with a boatload of scripts, emacs loads in about 1s.

The Cult of Vim

When I started doing rails work, I started taking vim more seriously. Vim gave me the speed, and the custommizability. I quickly crafted a set of fairly elaborate configs where everything was exactly how I liked it. But beyond that, I discovered what a joy modal editing is. The best way I can describe it is a programming language for editing. The ability to think of fragments of code as objects that i can perform functions on is a wonderful and freeing thing. Once it becomes second nature, it feels like I am talking to my editor in a high level way with my fingers. A nice side effect is that my hands never leave the keyboard. It is highly efficient, but efficiency isn’t even the biggest benefit, it is a joy thing. I find it much more enjoyable to edit code with modal editing.

Eventually you reach a point where you want to be writing your own stuff in vim as well, and you have to start learning vimscript, which is possibly the most terrible language ever conceived of. Vim is awesome, vim plugins are awesome, but vimscript is just one big WTF. More then that, I was starting to get into lisp in a pretty big way, and you can’t compare vim experience to the emacs experience. I also was sort of frustrated by the lack of ability to show the output of an external process in a seperate buffer, especially since I do TDD.

The Light of Emacs

The old arguments between vim and emacs focused on speed, but when you are comparing either to eclipse, the amount of speed difference beween vim and emacs now is unnoticable. Same deal with resources, emacs is sitting at 250megs right now, which is more then vim, but a small fraction of chrome. That brings us to the strengths, which for emacs is it does pretty much everything vim does, but better, except for the act of actually editing text. It also does way more then vim can do, some of it quite unique (org mode) useful (regexp-builder) or suprisingly powerful (calc).

The other major thing is elisp vs vimscript. I have a strongly passionate (bordering on irrational) love of lisp, so for me it was not even worth talking about, something lispy vs a really terrible dynamic imperative language, I will choose the lispy thing every time. elisp is far from the greatest lisp out there, but compared to vimscript it is wonderful. There is also a philsophy in emacs that emacs is a platform, with an editor implemented in it. Vim philosphy is vim is an editor that you can script if that makes you happy. Very different, and since I have such a dedication to my tooling, I definately appreciate the emacs side.

The thing that was always a sticking point for me was modal editing. As much as I love modal editing, I hate emacs editing. There is something about the way my brain works that makes it extremely hard to remember key chords. I can happy do “ci'blahfT;;.” and have no problems, but c-c m-x t will leave my brain after about 10 minutes of not using it.

After some time lusting over emacs and being defeated by its keybindings, I read about viper-mode, which was a vim emulator. I tried it out, but after trying ci" and having it not work, I realized it wasn’t enough. I poked around the internet a bit, and found out about vimpulse, which promised much more in terms of vim emulation. I actually went a day on vimpulse before switching back, there were just too many inconsistancies and other small things that were missing, or not working the way they should.

Evil.

I went a few months, sort of keeping taps on emacs, but not really expecting to be able to switch. Eventually I heard about evil, and I eagerly installed it. Wow. After trying vim emulators in many other editors, which range from the level of viper mode to a bit under vimpulse, evil was like a light in the darkness. These guys really “get” vim, and are serious about re-implementing it. I have been using it for a few months every day, and there are only a few things missing.

  • it ignores punctuation. if you have function foo(){}, and your cursor is at the end of the line, in vim db will leave you with function foo, in evil, it leaves you with function. This is because vim will treat punction as a word, while evil does not. I still find this regularly frustes me.
  • there is no :g. There are a ton of : commands missing, but I find the lack of :g the thing I really miss, since most of the other stuff is covered by emacs functions
  • the b text object is broken in js2 mode. I use js2 a lot, love it, and consider it one of the reasons as a web developer to switch from vim to emacs.

Evil for Vim users

First, in emacs, next line/prev line is c-n, c-p. The reason you need to know this is because there are other emacs major modes that have nothing to do with editing, but will usually use c-n/c-p or n/p as the method to navigate from the next and previous item.

In vim, it applies scripts via various events. Combing two things together means running one event, followed by the other event. In emacs, you are composing modes. Every buffer in emacs has a single major mode, that defines what type of thing you are doing. A major mode could be “ruby”, but it could also be an email client. Emacs is the platform, and a major mode is the application. You also have minor modes, which add additional features to a major mode. I have a plugin called autopair, that will keep delimiters balanced (I use delimMate to do the same thing in vim), that is a minor mode. So your editing experience is basically defined by composing a major mode with multiple minor modes.

This is a really cool thing, if you write vim plugins, usually you see a block where they have to unregister all sorts of things they registered if the filetype changes, that is a non issue in emacs, because nodes are self-contained entities. The bad thing is in the age of web development, we have to deal with files that have multiple major modes (like erb, which can have html, css, ruby, and javascript). This is probably the biggest weakness of emacs at the moment, it was designed with a single major mode per buffer, so you cannot compose major modes. There are many attempted hacks around this, but IMO they are all terrible.

M-x in emacs means “Execute command”. All the commands will be available there. M-x describe-key is extremely useful, you type that then hit a key, and it will tell you what function it is bound to. Once you have that, you can do M-x describe-function and enter that function name to view its documentation.

Lastly, if you are a vim user, you need to know how to bind keys. The idea in emacs is instead of registering keys at a global level, each mode has a keymap that is self contained. So when you compose your modes, you are also composing keymaps. the syntax for keymaps is

keymaps
1
2
3
4
5
6
7
8
9
10
(define-key <keymap> key 'function)

; evil defines 3 maps for the various states, so to
; replicate a mapping I had in vim - nmap Y y$

(defun copy-to-end-of-line ()
  (interactive)
  (evil-yank (point) (point-at-eol)))

(define-key evil-normal-state-map "Y" 'copy-to-end-of-line)

That was a custom function definition, but you can also use any built in function after the '.

Everything in emacs I know, I know by its function name. If I use it a lot, I will map it to a key, so I have pretty much completely ignored the real keybinds.

Evil for Emacs Users

I honestly don’t think I am qualified to write this, because I was never a real emacs user. But if you were ever curious about why people go on and on about how awesome vim is, evil will pretty much give you that experience, and you can have it without leaving the editor you already know and love. I believe evil mode is more effective then traditional emacs, but even if it isn’t I am pretty sure it is more enjoyable. I would strongly encourage people to give it a chance for a month or so with a “Learn vim” tutorial, and see how they find thinking in text objects. We are definately in YMMV territory, but I find it a joy. You may find this post more tailored to your point of view

Repository Pattern in Rails

| Comments

I have been working a lot on an app using MongoDB as the datastore, and Mongoid as the OR/M (or ODM to be more specific). In a relational database, you keep your data as segregated as reasonably possible, and then join it together in appropriate ways when you need it. The up side to this is that it is incredibly flexible, and chances are you wont hit a situation where you need your data in a form that your datastore can’t give to you. The down side is that often, your data has a “natural” way that is joined together, and even though 99.9% of the time you are joining it together in that way, you still pay the cost every time.

In Mongo, your data is stored in that “natural” way in a json format. That means it is harder to shape the data in different ways, but it is free to get the data in the way it is intended to be used.

The Problem

This app was developed using a state-based testing approach, where every test sets up a situation, performs an action, and then asserts on the new state of the world. An interesting side effect of the Mongo way of storing data is that it makes it much harder to test smaller objects in isolation — if a comment is a hash in an array in a post, it is impossible to save without first saving the post. In more complex scenarios, the problem gets much worse, and I am finding that tests that should be rather simple are requiring far more setup then I would expect.

A Solution: The Repository

When it comes to data access, the book Domain Driven Design advocates using a repository layer that separates your domain objects from your data access strategy. This has several benefits:

  • Your domain objects stay simple. Rails developers tend to follow the “Thin controller, fat model” heuristic fairly religiously. There is nothing wrong with that per se, but it sort of implies it is ok to have massive classes that do dozens (if not hundreds) of things, so long as it is the model. The problem with that is that as the complexity of the application grows, these “God” models tend to become harder and harder to maintain — everything interacts with them, and they interact with everything. That kind of situation is what causes even small changes to cause ripples through your entire applications, and makes even simple maintenance tasks become quite daunting.
  • You segregate your interaction with third party code (ActiveRecord, or in my case Mongoid) from the rest of your application. You may say “Why is that necessary when you rarely, if ever change your data storage strategy?” The reason is that you don’t have control over that code, it is managed by a third party. So if they change something, and you are calling their code directly all through your application, your entire application needs to change. I work on quite a large enterprise rails app, and the 2.x –> 3.x upgrade was a huge undertaking, mostly for this reason.
  • By following the Single Responsibility Principal, mocking in tests is a joy. This is going to address the pain I am feeling doing state based testing with a document datastore, and I believe that mockist testing will directly address these problems (I also much prefer mocking, so it is not exactly a direction I am resisting)

First Challenge: Mapping

I have worked on systems in C# with manual object mapping in repositories, and it is a bit of a nightmare. You end up with hundreds of lines of right_side.property = left_side.property code, which apart from being horribly tedious to write, is actually a terrible source of hard to find bugs. Since we don’t have a true data mapper library in ruby, the only way I will even attempt this is if I can automate the process through some clever meta-programming. The first part of that is that I need to be able to retrieve attributes from my domain objects in a simple way, without complicating the objects too much. I also need to be able to get the “schema” out of my model, so I am able to infer what it wants to save and retrieve.

This is going to be a lot of work

The app is currently ~1k loc on the server side, which means it is going to take some time, but is really not an insurmountable task yet. The first step will be figuring out how to tackle the domain model side of the mapping problem, and extracting a domain model out of the current mongoid model. Stay tuned for more!