Category: Uncategorized

Something neat about  ruby is the equivalence of procs, lambdas and blocks. Take a quick look here:

foo = Proc.new do |x|
puts "In a proc. X is valued at #{x}"
end
foo.call(24)
output -- "In a proc. X is valued at 24"

Pretty simple. Much like an UnboundMethod object, you have to call the proc with call. It can have variables supplied to it with the slide operator ||, or it can inherit the same from the surrounding scope:

x = 1
foo = Proc.new do
puts "In a proc. X is valued at #{x}"
x = 25
end
puts "#{x}"
-- outputs 25

A lambda is an alternative proc syntax. Instead of explicitly creating a proc object, you get an anonymous one still bound to a variable:

bar = lambda { |x| puts "In a lambda. X is valued at #{x}"}
bar.call(32)
--- output "In a lambda. X is valued at 32"

Now, let’s take a look at a block. First, we define a method that yields to a block:

def runnable
puts "Inside runnable."
yield
puts "Still inside runnable."
end

 

Now, we call the method with the same “do” keyword we already used for the proc:

runnable do
puts "I am a block."
end
--output: Inside runnable.
I am a block.
Still inside runnable.

Much as you can insert Proc.call anywhere inside a scope, so you can also insert yield inside a scope and define the proc on-the-fly in a block. Compare the syntax of yielding a variable to that of using a variable with a Proc:

def runnable
puts "Inside runnable."
yield(42)
puts "Still inside runnable."
end
runnable do |x|
puts "#{x}"
end
output -- 42

This allows an associated block to use a variable set within the method. What’s neat, though, is that we can see that the method that yields has a key difference to a Proc: it cannot see into the external scope:

x = 1
def runnable
puts "Inside runnable."
yield(x)
puts "Still inside runnable."
end
runnable do
puts "I am a block."
end
--output - this code fails with an error.

There’s a scope defined by the method, and the variable x is different inside that method than outside of it. 

All this is documented in a github repo: https://github.com/jamandbees/proclambda — feel free to look through the history and goof around.

I had a weird situation at work today. I have a script which runs for a specific amount of time:

script.rb --time 360

I had to add an option to make it run, then sleep, then run, then sleep, and so on. But I also still had to support the total time option.

The first thing I did was come up with a working model inside the code to support “run, then sleep, then run, then sleep”. I decided on a multidimensional array:

timeArray = [[100, 200], [150,300], [10,30]]

And I iterated over each:

timeArray.each do |timeArray|
timeToRun = timeArray[0]
timeToSleep = timeArray[1]
end

Now that was out of the way, I came up with comma-separated-semicolon-delimited strings as a way of specifying this on the command line:

script.rb --runandsleep 100,200;150,300;10,30

I called split on a semicolon first to give me a bunch of arrays containing each comma delimited string, then split on the comma and cast to integers using .to_i:

timesToRun = runAndSleepArgument.split(";")
timesToRun.each do |runAndSleepString|
sleepAndRunTimes = runAndSleepString.split(",")
runTime = sleepAndRunString[0].to_i
sleepTime = sleepAndRunString[1].to_i

All’s well and good, but what if the combination of run and sleep are specified with the total run time?

script.rb --time 150 --runandsleep "30,30;60,60;90,90"

I flopped back and forth for a while. I could preparse the –runandsleep time and if it was greater than the –time then refuse to run. That’d solve it. I could just run for the greater of the two times.

But what if someone enters:

script.rb --time 10000 --runandsleep "30,30"

I could run for 30, sleep for 30, then run for 9940. That had a decent solution.

The problem in my mind here is that I know what these kinds of things are like. I added a command line flag to this script (which is used a lot) called –destroy, because it called the destroyAllHumans function which reset a database. Within a week, the developers and QA were talking about how they were running with DESTROY or not with DESTROY and how it impacted things. As such, I know that the flags enter peoples’ heads. They get inside.

If the flag is non-intuitive, the person using the script is irritated. If the flag is intuitive, the person using the script thinks in terms of the flag.

So I solved the problem thus. You can specify:

script.rb --time 300

or you can specify:

script.rb --time "100,50;100,30;10,100"

Both of the syntaxes really specify a total run time, so why make them different? The script becomes better because it has fewer, more flexible, options.

Maven have a pretty awesome tutorial in their getting started guide here: http://maven.apache.org/guides/getting-started/index.html

The problem is that if you follow it letter for letter, then run:

java -jar target/<jarname.jar>

you receive a “no main manifest attribute” error.

Stackoverflow has a good answer for this problem, but it took a few readings before I understood what they were saying. Here’s a link to the stackoverflow question:

http://stackoverflow.com/questions/574594/how-can-i-create-an-executable-jar-with-dependencies-using-maven

Open your pom.xml and add the section listed:

<build>
   <plugins>
      <plugin>
          <artifactId>maven-assembly-plugin</artifactId>
          <configuration>
          <archive>
               <manifest>
                    <mainClass>fully.qualified.MainClass</mainClass>
               </manifest>
          </archive>
     <descriptorRefs>
          <descriptorRef>jar-with-dependencies</descriptorRef>
      </descriptorRefs>
 </configuration>
</plugin>
</plugins>
</build>

This goes after the URL tag, but before the dependencies tag.

After this, run the following maven command:

mvn clean compile assembly:single

This will output a jar-with-dependencies.jar file in your target\ directory.

 

I’m using Capistrano to automate a distributed environment. I love the tool, but one small thing that I see time and again with it: if a single node in a role cannot be reached, then executing commands on that node will fail.

 

It’s a bit of a bummer, but what’re you gonna do when it’s such a great tool otherwise?

Most every time I write a shell script with bash, I need a date in there somewhere. And most every time, I need to read the man page to work out what the heck the format is I like. Now it’s documented here:

date ‘+%b_%d_%H%M’

This outputs as Name Of Month_Today’s Date_The 24 hour clock time right now.

It’s useful to enclose in backticks:

df -h | mail -s “The disk usage at: `date ‘+%b_%d_%H%M’`” jam@jamandbees.net

 

 

 

I’ve been thinking a lot for the last few days about technical documentation, the notes that we keep as developers.

I’m in the habit of keeping documentation for the current state of the system. That’s always seemed reasonable to me. Whatever version has just been released, that’s documented well and that has always seemed reasonable and good to me.

Now, though, I’m thinking about how when I’m handing a system over to someone else the documentation they want is how the system evolved during development. The “what happened in the past” part of this is captured in version control. The “why were these decisions made” part is not, and that’s a useful piece of the puzzle for anyone who has to maintain someone else’s codebase.

I document the “how to use this” for each stable release of a codebase. I have never written down the “Why I made this decision” bit of things. When I think of how many times I’ve worked on someone else’s piece of code and the details of why this is the implementation became clear because changes started revealing why they were good decisions to begin with, I’m led to wonder if documenting intent is a good idea.

 

Is this what the intention behind commit messages is? The code documents the code, the comments document the pieces of the code that are non-obvious, and the commit messages document the intention behind each change?