Lucene.Net

1. Intro to Lucene.net
2. Coding your first Lucene.Net project
3. Lucene.net Contrib projects (ie: WordNet)

NHibernate Search

1. Introduction to NHibernate Search using Lucene.net
2. Coding your first NHibernate Search project

Solr

1. Setting up Tomcat/Solr
2. Using HTTP/SolrNet API in a web site
3. NHibernate integration with Solr

here’s my talk from last year with skillsmatter.

PS. I’ve gotten a haircut since then

the first video corrupted on me, there was another guy taping so hopefully posts it soon.

sorry about the shaky cam, It’s a new setup.

This is part of the OpenVolcano 2010 conference that was planned in just a day

There are some new features such as seeing the last 10 builds on the EAP from the taskbar. This way if you’d like to install a highly rated build from a couple days earlier that can be done quickly.

Enjoy,

Resharper Updater 1.3

According to Conway’s Law

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.

Have you ever thought about how much your company culture affects how you code? I do make a bit of a leap between a communication structure and the company culture but I’d argue that they’re the same.

Not long ago I was under the reigns of an evil manager. It was a waterfall project so it was doomed from the start but I was naive. I would work long hours and the manager would ask me to work late everyday.

The software we produced was

1. rushed
2. full of bugs
3. had poor solutions that weren’t thought out

That was my last poorly made piece of software but I bring it up so we can be realistic about the culture in which we build software. Can you think of examples where different cultures have been reflected in the software you make?

At sportinginsider.com we’re a splintered group of developers spread from London to Seoul. We communicate over skype and IM and meet in person every few months. Without collocation its a lot of work to keep communication happening. The communication we have is generally high latency since we’re overlapping at different times during the day. What we produce reflects this broken nature of our communication by separating concerns with SOA and plug-in support.

the quest for quality is a good thing. the quest for perfection gets you no where

the convention I’m using is that

• each plugin is in folder named Something.Addin

In order to compile each plugin into a seperate dll we use the foreach Task.

the property addin.name will contain just the folder name “Something.AddIn” instead of the absolute path that we get from the foreach Task.

I’m using Mono-Addins to provide plugin support to the application which I’ll cover soon.

<target name="-addin-compile">
  <foreach item="Folder" property="folder">
    <in>
      <items>
        <include name="${sources.dir}/*.addin"/>
      </items>
    </in>
    <do>
      <property name="index" value="${string::last-index-of(folder, '\')}"/>
      <property name="addin.name" value="${string::substring(folder,int::parse(index)+1,string::get-length(folder)-int::parse(index)-1)}"/>
      <echo message="Compiling ${addin.name}"/>
      <csc target="library" output="${deploy.dir}/${addin.name}.dll" debug="false">
        <sources>
          <include name="${sources.dir}/${addin.name}/**/*.cs"/>
        </sources>
        <references>
          <include name="System.Configuration.dll"/>
          <include name="${deploy.dir}/mlb.aggregator.common.dll"/>
          <include name="${lib.dir}/mono-addins/*.dll"/>
          <include name="${lib.dir}/log4net/mono-3.5/log4net.dll"/>
          <include name="${lib.dir}/xstream/*.dll"/>
          <include name="${lib.dir}/nhibernate/*.dll"/>
        </references>
      </csc>
    </do>
  </foreach>
</target>

every project has conventions, not every project uses them

If you use to spend time on IRC you know it feels very similar using twitter. Using private accounts we can keep our companies notifications both restrictive and accessible. At our company I’m starting to get interested in more notifications so I can keep track of how what’s happening company wide.

What you’ll need

1. Twitter TeamCity Notifier
2. TeamCity
3. Java 1.6

google code project

The default install of TeamCity installs with Java 1.5 so you’ll want to update to 1.6 if you haven’t already. You can do this by installing the JRE and then copying it into the c:\TeamCity\jre dir.

to check what version of java TeamCity is using try this command

c:\TeamCity\jre\bin\java.exe –version

After you install Java 1.6 you’ll want erase the contents of c:\TeamCity\jre and replace them with the jre folder that you can find under C:\Program Files\Java\. In my case the folder was C:\Program Files\Java\jdk1.6.0_10\jre

Installing Twitter Notifier

1. extract the zip into C:\TeamCity\webapps\ROOT\WEB-INF\lib
2. restart the teamcity service

Configuring your notifications

login to teamcity and goto My Tools and Settings

here you’ll see some boxes to enter your twitter account.

If you click edit you can specify the rules for the notifications

make sure you select all projects and tick off conditions you want to send tweets for

Notifications in action

Now when I trigger a build it notifies twitter.

Don’t worry I’m going to add fields that let you customize messages in the future.

Communication is harder when your distributed

Resharper Updater checks the website behind the scenes for you and changes the icon to one with a star when there’s a new version, so all you have to do when you come in in the morning is close studio and update to the latest version.

You can download it here resharper-updater-1.0.zip

Using Resharper Updater

There’s two ways to access the install

right click for the menu

If you have resharper installed it will tell you there’s no new version

If you Check for update it will tell you what build is available and the icon will change

Otherwise if you choose Check and Install or you double click on the icon it will check,download and run the installer.

There’s definitely room for improvement but this is the bare minimum before I could release it.

Automating your day

I started last week at Open Space Coding Day 1 and I had builds on my mind. I proposed a lot of different topics to code one but reusable build scripts picked up a bit of traction. I ran a quick tutorial on how to get an application compiling and tests running. We used NAnt because that’s what people wanted to learn but there’s plenty of alternatives including Powershell, Rake and MSBuild.

Here’s the repository from our session:

reusable build scripts subversion

When I first started off with build scripts it didn’t take long before they got ugly. Your build script goes from a simple compilation to a monstrous 1000 line file if your not careful. I remember adding all kinds of email notifications and deployment steps that I ended up cutting out during the hand over. I recommend if your new to build scripts and NAnt to read through with JP Boodhoo’s NAnt Starter Series which is a really good starting point.

The main tips for simplifying your build scripts are

1. remove application specific information to a common properties file
2. separate out common targets into separate files which you can include (ie: tests, compile, deploy)
3. keep it simple

I maintain a number of projects for a data mining job and it started to bug me how across different projects on a few scattered lines of the build changed. Even after the tips I mentioned you can still find that you have application specific configurations in your build.

The problem I had was I was repeating myself in the build script and that defeats DRY. The steps I was taking were:

1. compile all the .cs files in my source dir
2. manually set the references for my project
3. copy the referenced DLLs into the output directory

It doesn’t seem like much but anytime you add a reference you need to edit the build file. It ends up looking like this.

    <csc target="library" output="${dir.deploy}/sample.core.tests.dll" debug="true">
      <sources>
        <include name="${dir.src}/*.tests/**/*.cs" />
      </sources>
      <references>
        <include name="${dir.deploy}/sample.core.dll" />
        <include name="../thirdparty/tools/mbunit/MbUnit.Framework.dll" />
      </references>
    </csc>
    <copy todir="${dir.deploy}">
      <fileset>
        <include name="../thirdparty/tools/mbunit/MbUnit.Framework.dll" />
        <include name="../thirdparty/tools/mbunit/QuickGraph.Algorithms.dll" />
        <include name="../thirdparty/tools/mbunit/QuickGraph.dll" />
      </fileset>
    </copy>

The benefit of using csc over msbuild is that it lets you use the Mono Framework just by setting the target framework at command line.

The other problem with this approach is that mono needs reference DLL’s compiled for Mono like MySql Connector and Log4Net.

Cowan.Commons.Nant.ProjectsTask

My solution was to take all the logic I was repeating and put it into a custom task called ProjectsTask. It allows you to use wildcards to specify your projects to compile, which is not supported by SolutionsTask. This task uses XPath on each project file to retrieve references,resources and the project name.

<projects outputdir="${target.dir}">
      <fileset basedir="${sources.dir}">
        <include name="**/*.csproj" />
        <exclude name="*.tests/*.csproj" />
      </fileset>
</projects>

To fix the mono reference problem I’ve included references for both mono and .net in my lib folder but only referenced the .net dll.

\lib\log4net\net-3.5\log4net.dll
\lib\log4net\mono-3.5\log4net.dll

when you compile with mono it notices the net-3.5 directory and tries and finds a mono directory beside it. A new addition to NAnt is that it’s no longer sensitive to OS specific path seperators like / or \.

I still need to specify the build configuration (ie:debug or release) but it’s really simplified things for me.

you can see the code here

Work Smarter not Harder