Sunday, August 14, 2011

Bislet bad web site

Trying to find information about the Bislet swimming pool. The bisletbad.no site is parked. The bisletbad.com web site is unmaintained (no opening hours, incorrect phone number) but the swimming pool is functionning and isn't that bad !

Looks like the new owners are in some kind of domain dispute with the previous ones...

The whois entry of the .com site contains:

Domain Name: BISLETBAD.COM
Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
Name Server: NS3.NETBOX.NO
Name Server: NS4.NETBOX.NO
Name Server: NS5.NETBOX.NO
Status: clientTransferProhibited
Updated Date: 23-sep-2010
Creation Date: 23-sep-2010
Expiration Date: 23-sep-2011

Domain name: bisletbad.com

Registrant Contact:
BISLET BAD LIMITED
Dawson E. Hamilton ()

Fax:
Pilestredet 60
995901099
Oslo, Oslo 0167
NO

Administrative Contact:
BISLET BAD LIMITED
Dawson E. Hamilton (pt@jamfit.no)
+47.23333810
Fax:
Pilestredet 60
995901099
Oslo, Oslo 0167
NO

Technical Contact:
BISLET BAD LIMITED
Dawson E. Hamilton (pt@jamfit.no)
+47.23333810
Fax:
Pilestredet 60
995901099
Oslo, Oslo 0167
NO

Status: Locked

Creation date: 23 Sep 2010 16:03:00
Expiration date: 23 Sep 2011 11:03:00


The old Norwegian company points to http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=995901099 and the company is non existant.

This has been ongoing for months. Why don't they set up a temporary site with basic information (phone number, prices, opening hours) until they resolve their dispute.

Wednesday, April 20, 2011

Scripts pour surveiller une Livebox 2

[For once something in French, as it's targeted to customers of a French ISP]

Mes parents ont des problemes de deconnections sur leur Livebox 2 d'Orange. J'ai ecris un petit script bash pour recuperer les donnees presentes sur les pages de status, generer un fichier de donnees.

Les donnees sont actuellement extraites sous la forme suivante:

20110419-094018;27.5 dB;49.6 dB;8 dB;17 dB;640 kb/s;2304 kb/s;0;0;1850;10091;0;86.201.220.177;00:19:55;mardi 19 avril, 08:22:02;00:18:15;mardi 19 avril, 08:20:04


Le script peut etre utilisee en ligne de commande, ou plus simplement dans un cron.

Une fois les donnees recuperees, on peut par example utiliser gnuplot afin de generer des graphes. Un example de fichier de configuration pour gnuplot est fourni. Dans mon cas il m'a permit de generer:

bandwidth and noise margin over time

Sachant que la livebox tourne probablement sous Linux, il est dommage que la live box n'expose pas ces donnees dans un format facilement lisible par une machine, ainsi que donne access aux logs du systeme. Le kernel etant en GPLv2, il permet cependant la tivoisation...

Dans le cas de mes parents, il semblerait que le probleme soit lie a une marge au bruit fluctuante et trop faible, occasionant les deconnections. La bande passante negociee est parfois relativement faible (e.g. 700 kbps descendant!) et la marge au bruit associee est large ce qui donne une certaine stabilite. Nous allons laisser le script tourner quelques jours afin de voir si certaines periodes sont plus instables que d'autres... Affaire a suivre

Wednesday, March 23, 2011

Trafikanten & open data update - things happened

Following up my post from about 2 months ago, I was announcing good news on the way. As you may already know, the bigs news is finally out there: Trafikanten has opened up their data!

I would like to thank the various people involved in getting this in place, in no particular order, Bent Flyen, Christopher Worren and Jarl Eliassen from Trafikanten, Bjorn Tennøe from Iterate, Marius Mårnes Mathiesen from Shortcut and the numerous people whose name I've forgot along the way.

What's next ?

* I hope that now some people will come up with cool things building upon this free data & API

* yesterday I found farebot for android, and I would love to see the Flexus card data supported by similar applications. I already contacted trafikanten, and will follow up here.

Friday, February 25, 2011

getting svn and git svn to work long paths on windows

It appears that no latest stable SVN client (1.6.15 latest today) work well when working with projects with long paths (i.e. > ~ 250 characters). Noone on the team had problems as they used TortoiseSVN, but I insist on checkout out from the command line, and I also want to use git svn.

Now there's a work-around, but it seems relatively unknown. Yes you read well: use absolute paths instead of relative paths. That's it. Basically do:


$ svn co http://server/project/trunk c:\Projects\project.git


For git svn, from the git batch command line:

$ git svn clone [options] http://server/project/trunk /c/Projects/project.git


It also appears that svn client 1.7, out Q1 2011, will also fix that. But I couldn't confirm it from the roadmap.

Saturday, February 12, 2011

Ignoring JUnit tests at runtime

Sometimes I want to ignore particular test failures. In fact I don't want the tests to run at all because I know they will fail. Not that they are broken, but because they depend on part of the infrastructure that isn't available right now.

E.g. in the web-validators project, I wanted to have the ability to ignore the integration tests (which test remote validation services integration) when the remote sites aren't reachable.

I could also have used Assume, but somewhat I am not completely satisfied with that solution. The Assume calls go in the test code and

  • can't be used at a class level

  • aren't as good from a self-documenting perspective

  • don't have access to method information, e.g. other annotations

  • will execute my test code anyway, which can cause slow-downs, etc (time outs generally take a bit of time to trigger)



I could also have grouped my network dependent tests in a special suite or using a Category, but then I have to enable or disable it myself (i.e. make suites that match my grouping).

I prefer tests that enable themselves automatically.

So I came up with this solution: I have created a new Runner, and a new version of the Ignore annotation called RuntimeIgnore to which I specify optional extra argument(s): the name of a class to instantiate and execute to check whether an ignore condition is satisfied.

The disadvantage of the current patch is that I still have to have my own Runner. I don't like that too much (because to combine multiple enhancements you might have to combine runners) so I submitted an enhancement to JUnit as I merged that approach into the existing JUnit 4 Runner and @Ignore annotation.
Note: the patch isn't fully complete (cleanups, documentation left aside), it's more like a RFC. Feel free to comment.

How could you use this ? Instead of doing something like:


@Category("LinuxIT")
@Test thisTestShouldOnlyRunOnLinux() {
// my test code
}


and then enable your group of tests using Suites.

or

@Test thisTestShouldOnlyRunOnLinux() {
if (notOnLinux()) {
// my test code
}
}


You can do:


@Ignore(ifTrue=NotOnLinux.class)
@Test thisTestShouldOnlyRunOnLinux() {
// my test code
}


The same apply to classes, e.g.


@Ignore(if=NotOnLinux.class)
class MyLinuxTests {
@Test ...
@Test ...
}

You can also take advantage of DRY principles on Convention over Configuration doing


@Ignore(ifTrue=TestNameDoesntMatchPlatform.class)
@Test onLinux_aTest() {
// my test code for Linux
}

@Ignore(ifTrue=TestNameDoesntMatchPlatform.class)
@Test onWindows_aTest() {
// my test code for Windows
}


( in case you haven't followed the above code will not run in code taken from the JUnit official repository ! )

Update 1: after a comment from a JUnit commiter on my pull request/RFC, I made a slightly different version of the patch that doesn't require any change made to JUnit. By using MethodRules intead of a custom Runner, I am achieving almost the same thing. See the change here.

Saturday, February 5, 2011

Sonatype's Hudson's bright future - answer

So Sonatype's Jason Van Zyl posted about Hudson's future. I wonder if that response is related to Hudson-Dev's email thread "The Future of Hudson".

While I agree with some of the things Oracle and Sonatype are doing, I strongly disagree with the wording of this post and some of the comments.


  • "mostly dependent on a single individual for core changes" (aka hudson dependance on KK). There are 115 different contributors in core according to git (for jenkins, but that shouldn't be a big difference in hudson). yes he made the main decisions at start, but there are now more than 350 hosted plugins. From that perspective, his decisions sounded right

  • criticizing jelly ? I agree that it's not the best choice for a project starting today. But it's not that bad. And have you looked at how much code jelly represents in the plugins ? If I look at the official plugins from middle July 2010: 420k lines java, 44k jelly. That's 10%, a huge problem, right? And it's not because jelly didn't make sense for maven that it didn't for hudson. Actually it makes much more sense in hudson than in maven.

  • lack of documentation: most projects lack it. Even Maven

  • "too many forked dependencies". Think of them as patched dependencies, not forks. Who hasn't done that in the enterprise world? You know how hard it is to get a commit upstream sometimes. And it's easy to know why they were forked. Check the release logs for the deps. Or ask !

  • provenance: commits come with issue number and/or link to online discussion / report in the mailing list. Code comes from commits. Do you mean it could have been copied from another project without appropriate copyright ? This can happen anywhere. And it's solved the same way everywhere: by rewriting the code. Nothing dramatic.

  • licensing issues: yes you're right. BTW, mentionning Saas really sounds like attacking Cloudbees...

  • automation tests. Yeah ! All for it. There are 800+ tests right now in test harness. It's not that bad then. And you know how hard it is to come up with a good coverage right ? Maven 2.0.x took a long time to stabilize... As for providing tests for all plugins, it's hard. In maven it's easier because most are not hosted by Apache itself (think codehaus, etc)

  • "maven 3.0 support" in your worklog sounds like hudson/jenkins doesn't support it. How does that run then ? You might want improving it, or providing an alternative. Fine. But don't do as there's no support for maven 3.0 today in hudson/jenkins.

I could go on but I don't want to be too picky.

To summarize. Technical debt ? Oh yeah. Old dependencies? Double that. What kind of old projects doesn't have that ? How many times did you rewrite maven already ? You know it's hard to get it right the first time.

The reason I wanted to answer Sonatype's post was that line.

"Working with the community, Oracle and Sonatype [...]"


I think (and I may be wrong) that you've been working with a subset of the community. You didn't seem to publish your RFEs on the wiki on in Jira when the hudson developers asked (did you?).

You probably worked with Oracle and some of its customers, perhaps getting paid for your company's work. Nothing wrong about that in itself. Even great!

But please don't say 'the community'...

Anyway, the wording aside, I can't wait to see your contributions. I am sure they will help to make Hudson (and indirectly Jenkins) a better product.

Wednesday, February 2, 2011

The Future of Hudson

Unsubscribe @ hudson

Looks like quite a few people think that unssubcribing the developper mailing list is the way to put "the saga behind".

Hudson vs CruiseControl, presentation from 2008

(Note: Because it's historical, I will still keep the hudson name in that post, but that content of course also applies to Jenkins.)

Looks like Google Docs doesn't allow viewing my Open Office presentations. I digged that old Hudson vs CC presentation I made in 2008. You may find some interesting notes in particular:

  • Slide 13: some stats on hudson source

  • Slide 14: some stats on hudson releases where I plotted releases from 1.04 to 1.210 (pretty impressive rate at the time !)

  • Slides 15&16: Hudson success factors

  • Slides 17: Benefits

  • Slides 18: 4 things to do:

    1. Try it

    2. Like it

    3. Use it

    4. Contribute





Enjoy!

Sunday, January 30, 2011

The Hudson rename/fork. Part 1 - a question of fears and mis-communications

(Disclaimer: I am a registered Hudson developer, although I haven't commited much on the project. I use Hudson on site at most clients. I have always been interested in CI and am a former external contributor to the cruisecontrol project. I also voted yes to the fork/rename, for reasons I may explain in a further post)

For those who don't know, the renaming/forking of Hudson into Jenkins was decided a few hours ago, 214 votes against 14.
Although a lot will happen around those projects in the next future, I think it is important to have a look at this event right now.
To me, this renaming/fork symbolizes the big culture gap between open source and corporate driven projects, and I could add, between Sun (RIP) and Oracle.

The information I gathered here come from the different public documents found on the web and a few private conversations/communications with some of the main actors of Hudson's community.

I'll cut this post in 4 sections


The first 2 sections will be addressed in this document, the 2 later ones in a later post.

Thursday, January 20, 2011

Trafikanten & open data update - things are happening!

I am just back from a meeting with Trafikanten (where I met the Advisor for realtime data and the QA responsible). The meeting has been from my point of view pretty constructive. We've then spent a bit of time to better understand our needs. We've exchanged thoughts around their current data offering, the licensing, etc and came up with ideas that I think will make many people happy. I won't say much more for the moment, as I am waiting for them to actually implement the ideas we talked about, but as soon as I know more, you'll be posted. I would like again to thank Trafikanten for their time and I really wish them good luck with their changes. Exiting times!

Monday, January 10, 2011

Trafikanten: meeting on license and open data next week

A follow up after my last post on the topic of opendata/trafikanten. It seems that being constructive and open to new possibilities has some results. Trafikanten is revising their API license, in oart to be attractive to smaller actors as well. They invited me to a meeting on the 20th of January to present and discuss their new license proposal.

If you have some meaning on the topic, feel free to contact me, publicly or privately.

Wednesday, January 5, 2011

Publishing your signed OSS project to the Sonatype OSS repository

One thing I wanted to do was to publish the yui-runner releases to ibiblio. It's now pretty easy thanks to the Sonatype OSS repository, which will help you stage and release your repositories.

See the official Sonatype OSS Maven Repository guide.

Because of a few choices (git, scala), I ran into a few troubles or quirks that are worth noting though. Here's the outline of the procedure I picked up:

  • clean up your POM as per the documentation
  • no need yet to add sections for javadoc, pgp, release etc. They are by default included once the parent is inherited from. If you wish to test javadoc or pgp, you should then enable the sonatype-oss-release profile to your maven execution when needed.
  • if you do add the javadoc attach-sources goal, you might ran into problems that causes the reactor to not find the project's own internal dependencies. This is because I think that particular goal forks maven. See https://github.com/lacostej/yui-runner/commit/7f15baa5a73c0da773a283800521a12d8c20a905
  • you might want to configure the git push off by default (http://jira.codehaus.org/browse/SCM-444). This I think fits well with the staging principle of the Sonatype OSS repo. Use something like:

    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.1</version>
    <configuration>
    <pushChanges>false</pushChanges>
    </configuration>
    </plugin>

  • during release, you might want to add the use of the gpg agent if you don't like to enter your GPG passphrase for every module

    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-gpg-plugin</artifactId>
    <version>1.1</version>
    <configuration>
    <useAgent>true</useAgent>
    </configuration>
    </plugin>

  • the Sonatype OSS repository expects releases to have a javadoc artifact. As the maven-scala-plugin doesn't yet behave like the maven-javadoc-plugin, and doesn't produce nor attach a javadoc artifact to your build, I cheated a bit. This is of course temporary.

  • Deploying will require the use of GPG signatures. This is what i did on Ubuntu 10.10 to get it working as I wanted (with a gpg-agent):

    1. create a signing key:

      jerome@lenovo-w510:~ $ gpg --gen-key
      jerome@lenovo-w510:~ $ gpg --list-keys
      jerome@lenovo-w510:~ $ gpg --keyserver pgp.mit.edu --send-key 576831db3ae26aaf

    2. install the agent:

      root@lenovo-w510:~ # apt-get install gnupg-agent

    3. configure the gpg-agent. Under ~/.gnupg/gpg-agent.conf, write

      pinentry-program /usr/bin/pinentry-gtk-2
      default-cache-ttl 86400
      max-cache-ttl 86400


    4. start the agent and copy the output in the terminal (this can be moved to your DE session startup instead later on)

      jerome@lenovo-w510:~ $ gpg-agent --daemon
      GPG_AGENT_INFO=/tmp/gpg-t61OEn/S.gpg-agent:28820:1; export GPG_AGENT_INFO;
      jerome@lenovo-w510:~ $ GPG_AGENT_INFO=/tmp/gpg-t61OEn/S.gpg-agent:28820:1; export GPG_AGENT_INFO;


  • Now the release takes the form of:

    1. clean your directory (git status, git ignore, etc)
    2. mvn release:clean (optional)
    3. mvn release:prepare
    4. git push --tags && git push (if you disabled push)
    5. mvn release:perform
    6. follow the Sonatype doc for testing your staging repo and releasing it. If you run into problems, don't forget to drop your repo before releasing again.

yui-runner, what it's for ?

I've released the first public version of yui-runner, a small framework for automating the running of YUI javascript unit tests and reporting of their results.

See https://github.com/lacostej/yui-runner

As the main goal is to be able to run your tests from anywhere, the integration is done thanks to a JUnit runner. This means your tests will run in maven thanks to surefire or in your favorite editor.

An example project can be found under https://github.com/lacostej/yui-runner/tree/master/yui-runner-it/src/test/resources.

The project will soon be available on ibiblio, something I'll blog about.

Note: the API for yui-runner is going to change for more flexibility in selecting the URLs to load.