Jam and Bees

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.