Software Development13 Jul 2013 08:22 am

I have been doing a lot of data transformation work in CoffeeScript and its features like destructuring assignments is really useful for this. One of the things I needed to do a lot of is given an array of objects, produce an equivalent array of objects having the same data, more or less, but in a different structure.

Originally, to accomplish this, I was following the comprehension example on the CoffeeScript site. With this approach, my code would look something like this:

input = [
  value: 1
  name: 'a'
, 
  value: 2
  name: 'b'
]
 
convert = (objectIn) ->
  id: objectIn.name
  value: "#{objectIn.value}"
 
output = (convert(obj) for obj in input)

This simple example takes an array of input objects and from them produces an equivalent array of output objects where the input “name” property becomes the “id” property in the output and the “value” property is transformed from a number to its string equivalent.

The annoying thing about this approach is the need to define conversion functions for each conversion. I was thinking, boy, wouldn’t it be nice if I could just use a regular for loop where I can put a whole block of transformation code into its body and assign the for loop “results” to the output? But for loops of course don’t return results.

Or do they? This is CoffeeScript after all and “everything is an expression.” Moreover, CoffeeScript is very good at just working the way you want it to (except when you forget the fat arrows of course).

So I tried the following:

input = [
  value: 1
  name: 'a'
, 
  value: 2
  name: 'b'
]
 
output = for obj in input
  id: objectIn.name
  value: "#{objectIn.value}"

And it works. Now why isn’t this documented anywhere?

Software Development01 May 2013 10:16 pm

I love git. At this point I can’t imagine using any other version control system. Admittedly, I have never use Mercurial or any other distributed VCS so my experience may be skewed. Nonetheless, it has a few things about it that annoy me. Perhaps highest among these was the inability to merge my current branch into another.

Mostly, when I am using git, I am following the git flow approach to things. However, I don’t generally install the git flow tool. I am fine with doing things manually from the command line. In fact I think any developer should have to learn how to do git flow without the tool first. Its like learning to code in notepad before installing an IDE. But, I digress.

The issue with git-flow is that when you are merging, first you do a rebase of your current branch onto the target branch (git rebase target) followed by a non-fast-forward merge. What this means is that you have to checkout the target branch and then merge your working branch into it: git checkout target && merge working-branch –no-ff.

This is annoying. If I am on my working branch I just want to do git rebase target && git merge-to target, especially if the name of my current branch is long, which it often is.

So I did some googling and found a stack overflow article on the topic. There were several approaches. I liked Dmytrii Nagirniak’s the best. It uses git’s aliases. I didn’t know git had aliases before this. Indeed they are a bit more powerful that bash aliases, so I tend to think of them more as macros.

In any event, I slightly modified his solution and it works great for what I want. Just add the following to your .git/config:

(If the [alias] section header is already present, just add the definition to the end of your list of aliases.)

[alias]
   #merges the current branch into the specified branch (i.e. reverse of merge).  Returns to the current branch if -r specified.
   merge-to = "!f() { export tmp_branch=`git branch | grep '* ' | tr -d '* '` && git checkout $1 && git merge $tmp_branch && [[ $2 = '-r' ]] && git checkout $tmp_branch; unset tmp_branch; }; f"

After this I got a little carried away and wrote a few other useful alias.

   #Takes to branch names (neither are the current branch) merges the first one into the second one, returning to the current branch.
   merge-branches = "!f() { export tmp_branch=`git branch | grep '* ' | tr -d '* '` && git checkout $2 && git merge $1 && git checkout $tmp_branch; unset tmp_branch; }; f"
   #Moves the branch specified to the hash, branch or tag specified.
   move-branch = "!f() { export tmp_branch=`git branch | grep '* ' | tr -d '* '` && git checkout $1 && git reset --hard $2 && git checkout $tmp_branch; unset tmp_branch; }; f"
.Net Development&Agile Practices&Automated Testing07 Dec 2012 10:47 pm

I have been playing with NBehave, which is a cucumber-like Behavior Driven Development (and testing) framework for .Net. I like it and it has a lot of capabilities in its latest release but there is one thing I don’t like. Why should the failure of one post-condition (a “then” clause) cause the entire given-when-then test set to terminate?

To clarify, the NBehave behavior is that if I have some test setup (some “givens”), “when” I perform my test action, this is usually followed buy multiple “then” post conditions to be tested. NBehave (and I think to be fair most BDD frameworks), stop evaluating post conditions after the first failing one is encountered.

Doesn’t this presume that there is some order dependency between the post-conditions, such that if a prior post condition failed, the rest of the post-condition tests are invalidated? I see no reason to make this assumption. Even if it is the case in some scenarios that post-conditions have dependencies on each other, in my experience this is not the norm. By terminating the test early one is simply depriving the developer of additional information that actually might help in resolving the failed condition.

Thoughts? Am I missing something?

« Previous PageNext Page »