This is my blog

Have you ever wanted to ‘cat’ a file directly to the clipboard? OF COURSE, why else would you be reading this sentence?

Simply install ‘xclip’, which is simple also, if you are on ubuntu:

sudo apt-get install xclip

Anything that you pipe to it goes to the X11 clipboard. Once there, you can just hit the middle mouse button to paste it where you want, just as if you had highlighted it. So you can do things like this:

$ cat some.file | xclip
$ nslookup somehost | xclip
$ ./runsomeawesomescriptthatyouwanttheoutputintheclipboard.sh | xclip

WOW what a long day since my last post! IT WAS ONE DAY I SWEAR. Anyway, I put up an information page for the maven-jmeter-plugin up here.

I also set up a google code project here for it.  Please let me know if you have any features or feedback on it.

Thanks!

Recently my co-worker James suggested we automate our tests on our project using JMeter and gave me his webpage about the trials and tribulations he went through to get it set up.  It linked to a wiki page, in which someone had created a JMeter plugin for Maven.

Well awesome, it shouldn’t be too hard to set up.  And it wasn’t, I had the JMeter tests up and running in a short amount of time.  But one of the problems was that I wanted to set it up in a more generic way so that we could define different parameters on each of the CI environments we ran. 

For this task, I first tried using filtering in maven, which I got working.  But what you end up with is a JMX file that is basically unusable by default in JMeter. If you ever wanted to run it again standalone in JMeter, you’d have to modify the variables in the JMX file to work correctly. Vice versa, if you set up your test using JMeter, you have to remember to modify it so that the maven variables you need are in the places you need them.

JMeter already has a system in it where you can define variables in the JMX files (and give them defaults, fancy la la!).  For example, say you want to define a variable for a host name.  Inside your JMeter JMX file, you can do something like this:

<stringProp name="HTTPSampler.domain">${__P(someVariableName, localhost)}</stringProp>

Now, you have defined someVariableName to be a variable within your JMX file.  The second value, in this case localhost, is the default if no variable override has been given.

The way to override these variables is with the -J option on the command, in this form:

-JsomeVariableName=yourhost.com

and all the variables called someVariableName will have the value yourhost.com.

Now, with the minor modifications I have made to the JMeter Maven plugin, you can now define the values for these variables inside of your pom.xml, like so:

<jmeterUserProperties>
      <someVariableName>yourhost.com</someVariableName>
</jmeterUserProperties>

and it is just the same as using -J on the JMeter command line.

The way we’re actually going to use it is to combine it with maven variables, like so:

<jmeterUserProperties>
      <someVariableName>${ourhostname}</someVariableName>
</jmeterUserProperties>

So now, we can just do:

mvn -Dourhostname=ourspecialhost ...

and be able to run site specific JMeter tests with only changing the arguments on the command-line.

I will be putting together a page in the next day or so with all the libraries needed to set this up, similar to the wiki page.

I recently wanted to use a distributed version control system to learn and to try it out, since I have been hearing great things about it.  The only issue is that my team (and like 1 million other teams universe wide) currently uses Subversion, and trying to get them to switch over would be like trying to punch a redwood down.

But! Not all is lost.  You can use git with Subversion.  This can give you some of the benefits of using a DVCS without having to change everything you do.  I believe you can do this also with Mercurial…I went with git because I had read somewhere it had the best support to working with Subversion. AND RANDOM INTERNET BLOGS ARE ALWAYS RIGHT.

First of all, I will say that I used this as a guide when I was working.  It’s a great start to doing this stuff. I’ll also assume you can find and install git on your own, since you’re all-grow’d up now.

Step 1: Creating a local repo

Ok so let’s get started.  The first step is to get the subversion library.  That webpage I gave you gives you four different ways of doing it, but I decided to go with the fourth option, which is cloning the entire Subversion repository.  You can do that by doing:

git svn clone https://svnserver/project/trunk

Now, you should know that this could take a while.  You might as well go and eat dinner for the next three days while this completes.  Just kidding, this took me about an hour or so while I was working remotely over a VPN, so it’s not so bad.  Our project has about 8000 revisions, and about 230 MBs of files.

So you’re probably wondering “But now if I have the whole history, isn’t it going to take like…a bazillion bytes on my disk?”  To that I say “Non”…it uses compression, and my git repo ended up being about 1 MB bigger than my subversion one.

Step 2: Create a branch

From there, you can start working in git!  The first thing you’ll probably want to do is create a branch:

git checkout someNeatoBranch

Now you are working on this particular branch. Note you can do this in one step by doing:

git checkout -b someNeatoBranch

which will create it and put you on it to work.

Step 3: Commit locally

Now you can edit the files to your heart’s content.  And commit locally as often as you like, by doing

git commit -a

You can commit individual files by specifying them, but -a just grabs them all.

Step 4: Commit back to Subversion

Once you’re ready to commit back into the main Subversion repo, first you need to pull all the changes from there, to make sure there are no conflicts. You can do this by using this command:

git svn rebase

This will pull down the latest code and apply your code on top of it, merging if necessary.  Then to commit back to Subversion, you use:

git svn dcommit

And you will notice that your files are committed back to the repo without any more intervention from you!  But where are your comments?  Well, all the comments from the commits you did locally will be used to commit to Subversion.  It will also do that many commits.  So if you did 5 different commits locally, it will turn into 5 different Subversion commits.  As long as your team members don’t worry about the revision number spirialing up towards the heavens, it should be ok.

Step 5: Brunch!

This is a pretty simple workflow to get you started on using git with Subversion, but it’s not even half the story.  There’s so much more powerful stuff with the branching aspect, and I even haven’t tried it yet to share work with my coworkers before commiting to svn (I’m kinda like a git island at the moment).  But try it out, and then check out some of the resources below that helped me get started.

Also, you might want to check how my co-worker James one-upped me.  He was working on some highly experimental code that he wanted to share with a teammate, and created a true git repo in approximately 8 seconds, from existing code.

Resources

• An introduction to git-svn for Subversion/SVK users and deserters
• Git - SVN Crash Course

I had to recently send some modified files to someone so that they could take a look at what I was doing.  OH NOES!  How do I gather them all up at once?

tar cvzf somefile.tar.gz `svn stat | awk '{print "test -f " $2 " && echo " $2}' | bash`

Word.

To break it down:

The svn stat command is getting all the files that have changed obviously.

The awk command its piped to is the real part that’s doing the work.  The awk command prints

test -f file && echo file

Pipe that through bash, and you have commands, which essentially will echo the file if the file is a file. Simple? No? I mean, it will not print it out if it’s a directory, so you don’t have to worry about it adding entire directories.

Surround that whole thing in backquotes (that’s the one with the tilde (that’s the one next to the ‘1′ key ( I’m not telling you where the ‘1′ key is)))  and give it as the argument to the tar command.

I finally upgraded my computer to Ubuntu 8.04, but unfortunately my VMWare server didn’t work any more.  That led me into a whole bunch of things that I noticed wrong with my upgrade.  Allow me to explain the idiocity.

First, for some reason, even after upgrading, I was still booting into the old 7.10 kernel(2.6.22-14). A quick change to the /boot/grub/menu.lst file cleared that up.  I just copied one of the other entries and then modified it so that it pointed to the new kernel (2.6.24-16).

Great.  I booted up and then…had no wireless.  I had forgotten how I set it up before, until I came across this page. For some reason, Hardy breaks newer Broadcom wireless cards (BCM4312, rev. 02 to be exact).  But that page has pretty direct instructions on how to fix your po’ computer…that is, if you have internet…which you probably do, if you’re looking at this page.

Great.  Ok now I can install VMWare.   I had it installed before, but something made it get all scared and I suppose it scurried away to /dev/null for eternity.  Suicide must have been more appealing to the VMWare.

Apparently there are issues with VMWare on Hardy, but following this page seemed simple enough.  Except when I ran:

sudo ./runme.pl

It gave me this error:

A previous installation of VMware software has been detected.

The previous installation was made by the tar installer (version 3).

Keeping the tar3 installer database format.

Error: Unable to execute "/usr/bin/vmware-uninstall.pl.

So great, it left pieces of itself behind, except without a shovel to clean them up with. This was easily cleared up by removing the /etc/init.d/vmware directory.

After that, everything worked great.  I was able to open up my old XP instance perfectly.

As I explained in this post here, we used the magical Maven groovy plugin to check when our EAR gets to big, and fail the build.  It works great, because now we get instant notification in our CI environment when something is amiss, which might get…um…missed.  So our build has been failing lately, intermittently because the EAR has been too big.

The problem was the latest version of the Maven war plugin (2.1-alpha-2-SNAPSHOT) changes the way that skinny WARs are created for packaging in EARs. The documentation hasn’t quite made it to the website yet.  Instead of using <warSourceExludes> to exclude the JARs that you do not want, you have to now use <packagingExcludes>.  It’s described in this bug here.

People who use Linux know that copy/paste is as easy as selecting some text and then clicking the middle mouse button to put that text exactly where you want it. No need to navigate your poor and addled with carpel-tunnel left hand all the way over to the Ctrl-C/Ctrl-V combination, saving precious calories.

I used to use this trick in Firefox also. If you highlighted a URL, you could just hover in the window and middle click in there, and it would take you to the page. This was nice, because if you tried to copy it into the address bar, it would keep the original address in there, and then you would have to backspace it out, blah blah.

For some reason, the newer versions of Firefox seem to have this disabled (I think, unless I disabled it in some stupid way, which is completely possible). To enable it, navigate to about:config. This will take you to the secret preferences of Firefox. There, you can set the middlemouse.contentLoadURL to ‘true’, and get that setting back.

Another one that I like is using Ctrl-Backspace to delete parts of a URL in the address bar. It works great on my windows side, but in Linux, it just deletes the entire bar. To get that setting back, I had to set layout.word_select.stop_at_punctuation to ‘true’.

The about:config has all kinds of settings in there that can help you if you poke around in there.

Recently, we had an issue that came up with creating our EAR for our web applications. We were trying to package up individual WARs in an EAR so they could share the same libraries and such and only load stuff used between them once, to save on memory.

We had it working great and then something ridiculous happened that caused WARs with their complete libraries (as opposed to stripped-down ones) to be included in the EAR, for no apparent reason. This caused a number of headaches and issues with the application, that we didn’t know until it was deployed, because we failed to recognize that the EAR had nearly doubled in size.

You may be wondering, “Hey, I just read two of your dumb paragraphs and I haven’t seen the word ‘groovy’, ‘maven’, ‘magic’, or ‘using’ yet.” Well, wouldn’t it have been nice if we knew instantly that the EAR had grown, when trying to build? That’s where the using the groovy maven magic plugin can help!

My co-worker James and I attempted to use the maven enforcer plugin, but it would have taken too much work and we would have needed to write a custom plugin for it to check the size of the EAR. So we decided to do it with Groovy. Here’s the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<plugin>
  <groupid>org.codehaus.mojo.groovy</groupid>
  <artifactid>groovy-maven-plugin</artifactid>
  <version>1.0-beta-4-SNAPSHOT</version>
  <executions>
    <execution>
<phase>verify</phase>
      <goals>
        <goal>execute</goal>
      </goals>
      <configuration>
        <source>
 
          def ear = new File("$pom.basedir/target/${project.artifactId}-${project.version}.${project.packaging}")
          log.info("${ear?.length()}");
          def maxsize = project.properties['ear.maxsize'];
          if (ear?.length() > maxsize?.toInteger()) {
            fail("EAR Exceeds maximum size allowed.");
          }
        </source>
      </configuration>
    </execution>
  </executions>
</plugin>

This beginning part essentially defines the groovy plugin, and states run the code during the maven’s “verify” phase, so we know that the EAR is already created:

1
2
3
4
5
6
7
8
9
10
11

<plugin>
  <groupid>org.codehaus.mojo.groovy</groupid>
  <artifactid>groovy-maven-plugin</artifactid>
  <version>1.0-beta-4-SNAPSHOT</version>
  <executions>
    <execution>
<phase>verify</phase>
      <goals>
        <goal>execute</goal>
      </goals>
</execution></executions></plugin>

The groovy code is really straight forward. First we get a reference to the file:

13
14

def ear = new File("$pom.basedir/target/${project.artifactId}-${project.version}.${project.packaging}");
log.info("${ear?.length()}");

We’re using variables defined directly in the POM, so we know the name of the file. We also print the length of the file out, for sanity’s sake.

Next we get the max size value:

15

def maxsize = project.properties['ear.maxsize'];

This is defined later in the pom.xml file, under properties:

<properties>
        <ear.maxsize>60000000</ear.maxsize>
</properties>

As you can see, it is set to near 60MBs.

Finally, and obviously, we check the two values against each other, and fail the build if the EAR is bigger than the size allowed.

16
17
18

if (ear?.length() > maxsize?.toInteger()) {
  fail("EAR Exceeds maximum size allowed.");
}

The fail() call in groovy allows you to fail the build with a message attached to it.

So now, if anything fishy happens with the EAR, we’ll be able to know as soon as our CI environment attempts to build it. This is a really simple example, but you could see how integrating groovy into maven could allow for some very powerful things to be done.

Ok, I started this up again since a lot of things are going on with me right now, like a trip to Korea for business and in the process of buying a new house. I cleaned everything out and now it’s back up. Stay tuned…or don’t, I don’t give an eff.