Automate your Jabbr chat using Github Hubot all running on a Windows machine

I previously talked about “Running Github Hubot on a Windows machine”, “Using Github hubot and Appharbor service hook to get deployment status in Campfire/HipChat rooms” or even “Starting TeamCity builds from HipChat using Github Hubot”.

All those solution rely on an external chat service either Altassian HipChat or 37signals Campfire.

If you want to have your own all integrated experience with all your tools running on premise I propose to look how you might do that using Jabbr and Hubot on a windows machine.

Jabbr is a chat application built with ASP.NET and SignalR. It is open source, available on Github, and provided by David Fowler. Easy to install too as you will see.

To install it the only thing you will need to do is to clone it from Github. You might use Github for Windows then you are one click away from having the clone on your local machine, just visit Jabbr Github page and click Clone in Windows button.

Next step is to create a database named Jabbr, for example in Sql Express.

Finally run the build.cmd from the Jabbr cloned folder which will produce a site folder in the target folder of the Jabbr cloned folder.

Then leverage WebMatrix by right clicking ‘Open as a Web Site using WebMatrix’ and finally click Run.

You should end up with your own local installation of Jabbr, something like the following

Then create a user using /nick [user] [password]

Now let’s create a Jabbr room which will be joined by our Hubot later on.

You just need to use the Jabbr command: /create [room]

Let’s use Development as the name of our room.

Now we are ready to install the second part of our solution Hubot.

Hubot comes with the notion of adapters which makes it very flexible toward what system it can connect to. In our case we would like to have Hubot connecting to Jabbr so we need a Jabbr adapter. Thanks to Scott Moak for creating one which is available here.

But before we need to to install nodejs and Hubot, just follow my previous post “Running Github Hubot on a Windows machine” which is still working with nodejs v0.8.2.

Update: After a short discussion with Tom Bell (@thetombell) on Twitter it is clear that I made too complicated. Thanks Tom for pointing out the easiest way!

So here it is!

mkdir hubot-local

cd hubot-local

npm install hubot

cd node_modules\hubot

npm install https://github.com/smoak/hubot-jabbr/tarball/master

So now we need to integrate Scott Jabbr Hubot adapter. To achieve that from the same prompt your installed Hubot, you will need to install one dependency of the Jabbr adapter which is njabbr so go on and type

npm install njabbr

Now you would need to clone Hubot Jabbr adapter and get the file src/jabbr.coffee and copy it in the adapter /hubot/src/adapters folder of hubot.

Finally just adapt the /hubot/src/robot.coffee to add the new Jabbr adapter like this

HUBOT_DEFAULT_ADAPTERS = [ "campfire", "shell", "jabbr" ]

 

And the last step is to configure some environment variable used by the Jabbr adapter so that hubot connects to the Jabbr chat application and room.

In this example I used the excellent WebStorm from JetBrains but you could do it directly from your environment.

Update: if you don’t have WebStrom you might use PowerShell and

$env:HUBOT_JABBR_PASSWORD = ”HubotPwd”

$env:HUBOT_JABBR_ROOMS = ”Development”

$env:HUBOT_JABBR_HOST = ”http://localhost:17221”

Update: Settings the environment variables like shown previously uses a process-level environment variable (that is, an environment variable that is only visible to, and lasts only as long as, your current PowerShell session). To create more permanent environment variables (i.e., user-level or machine-level) you need to use the .NET Framework and the SetEnvironmentVariable method

[Environment]::SetEnvironmentVariable("HUBOT_JABBR_PASSWORD", "HubotPwd", "User")

[Environment]::SetEnvironmentVariable("HUBOT_JABBR_ROOMS", "Development", "User")

[Environment]::SetEnvironmentVariable("HUBOT_JABBR_HOST", "http://localhost:17221", "User")

Now the only differences from what we have seen in the previous article "“Running Github Hubot on a Windows machine” is that we need to run hubot with the following command line specifying that we want to use the Jabbr adapter:

node .\node_modules\coffee-script\bin\coffee .\bin\hubot –a jabbr

And again the magic starts

As you can see we have Hubot joining our Jabbr Development room and replying to our command. For sure all our Hubot scripts are working, so it lets me check and start builds on TeamCity, but also see AppHarbor deployment status. It is very really easily extendable with new hubot scripts written in CoffeeScript. So it let you customize and automatize most your daily processes. A big win!

Continue Reading »

An article by Laurent Kempé 7 Comments

Starting TeamCity builds from HipChat using Github Hubot

After writing about “Running your TeamCity builds from PowerShell for any Git branch” I’d like to talk about another integration which is using Github Hubot so that the build could be started directly form a chat room.

So using the same idea, which is to extend our development environment, we implemented a way to start TeamCity builds directly from our HipChat room. You could do the same from Campfire for sure.

The main idea of this is to have our daily tools right at our disposal where we spend a good part of our days, chat rooms.

First we had to install Github Hubot and we have chosen to use Heroku which offer free hosting for one of their web dyno. They even offer what they call Hubot Factory which is a way to allow people to easily and quickly deploy new instances of Hubot to Heroku. In fact we went with a manual installation described on this page “Hubot for HipChat on Heroku”.

The idea is still the same we need to run TeamCity builds by “Accessing the Server by HTTP”.

This time we want to have Hubot calling the TeamCity server so we need to add a new CoffeeScript to the scripts of Hubot which will launch the HTTP request needed.

Our script is heavily inspired from the TeamCity.coffee script, and here is a first version:

# Starts a build on TeamCity.
#
# You need to set the following variables:
# HUBOT_TEAMCITY_USERNAME = 
# HUBOT_TEAMCITY_PASSWORD = 
# HUBOT_TEAMCITY_HOSTNAME = 
#
# start build buildId -- Starts TeamCiyt build using buildId
module.exports = (robot) ->
  robot.respond /start build (.*)/i, (msg) ->
    username = process.env.HUBOT_TEAMCITY_USERNAME
    password = process.env.HUBOT_TEAMCITY_PASSWORD
    hostname = process.env.HUBOT_TEAMCITY_HOSTNAME
    buildName = msg.match[1]

    msg.http("http://#{hostname}/httpAuth/action.html?add2Queue=#{buildName}")
      .headers(Authorization: "Basic #{new Buffer("#{username}:#{password}").toString("base64")}",
               Accept: "application/json")
      .get() (err, res, body) ->
        if err
          msg.send "Team city says: #{err}"
          return

By the way I started to learn CoffeeScript so this is more hacking then something really productive.

And here is the result in our HipChat room asking hubot to start a build with the command:

hubot start build bt21

I will talk in another post about the last part which shows the status of the build in the chat room.

Continue Reading »

An article by Laurent Kempé No Comments

Running your TeamCity builds from PowerShell for any Git branch

I love TeamCity and use it since a while to automate my build/release processes. As human we should never do the work a machine can do, we have certainly better and more interesting things to do.

The habit I saw in the different projects I worked for is to create new TeamCity builds for the branches you work on. It take quite some work to do, even with templates…

So I came with another way of doing it. It is leverage Git, PowerShell and the possibility to run TeamCity builds by “Accessing Server by HTTP”. Basically you just need to make a HTTP request to an Url like this:

http://testuser:testpassword@teamcity.jetbrains.com/httpAuth/action.html?add2Queue=bt10&system.name=<property name1>&system.value=<value1>&system.name=<property name2>&system.value=<value2>&env.name=<environment variable name1>&env.value=<environment variable value1>&env.name=<environment variable name2>&env.value=<environment variable value2>

We will also use the possibility to pass custom parameters (system properties and environment variables) through the HTTP request.

The parameter we want to pass is the Ref name of the Git VCS Root, so we start by setting it using a configuration parameter called BuildRefName, as this:

Then we need to add a configuration parameters for our TeamCity project with the name BuildRefName which we currently set to master, so that if the parameter is not defined it will default to this value:

Now that we have configured this you can already start a build from your browser by calling the URL!

http://testuser:testpassword@teamcity.jetbrains.com/httpAuth/action.html?add2Queue=bt10

Be sure to replace bt10 with your build id.

Nice ,but we want to get a step further and be able to start the build from PowerShell, which is quite easy!

To achieve this goal you add those two functions to your PowerShell profile:

function Get-Web($url, 
    [switch]$self,
    $credential, 
    $toFile,
    [switch]$bytes)
{
    #.Synopsis
    #    Downloads a file from the web
    #.Description
    #    Uses System.Net.Webclient (not the browser) to download data
    #    from the web.
    #.Parameter self
    #    Uses the default credentials when downloading that page (for downloading intranet pages)
    #.Parameter credential
    #    The credentials to use to download the web data
    #.Parameter url
    #    The page to download (e.g. www.msn.com)    
    #.Parameter toFile
    #    The file to save the web data to
    #.Parameter bytes
    #    Download the data as bytes   
    #.Example
    #    # Downloads www.live.com and outputs it as a string
    #    Get-Web http://www.live.com/
    #.Example
    #    # Downloads www.live.com and saves it to a file
    #    Get-Web http://wwww.msn.com/ -toFile www.msn.com.html
    $webclient = New-Object Net.Webclient
    if ($credential) {
        $webClient.Credentials = $credential
    }
    if ($self) {
        $webClient.UseDefaultCredentials = $true
    }
    if ($toFile) {
        if (-not "$toFile".Contains(":")) {
            $toFile = Join-Path $pwd $toFile
        }
        $webClient.DownloadFile($url, $toFile)
    } else {
        if ($bytes) {
            $webClient.DownloadData($url)
        } else {
            $webClient.DownloadString($url)
        }
    }
}

function tcBuild([string]$branch) {

	$url = "http://YourServerUrl/httpAuth/action.html?add2Queue=YourBuildId"

	if ($branch) {
		$url = $url + "&name=BuildRefName&value=" + $branch
    }
	
	$credentials = New-Object System.Net.NetworkCredential("Username", "Password")

	Get-Web $url -credential $credentials
}

Please adapt the tcBuild script by replacing the YourServerUrl, YourBuildId, Username, Password by your personal values.

The first function Get-Web is from this blog post: “Microcode: PowerShell Scripting Tricks: Scripting The Web (Part 1) (Get-Web)”.

The second, tcBuild, is quite easy and is the one you will use to start a build on the TeamCity server.

My workflow now is the following one:

1. I commit on my local Git repository then
2. when I want to run a build I push to the centralized Git origin repository in my branch then
3. I start my build on the Git Branch from PowerShell by typing :

> tcBuild Jobping-10-NewFeature

where Jobping-10-NewFeature is the name of my Git branch.

This is quite cool and give me also the possibility to run kind of personal builds!

Continue Reading »

An article by Laurent Kempé 2 Comments

Application Acceptance Testing

Yesterday evening I found a set of Google blog posts talking about web application acceptance testing which reflect Google experience through “Several years of experience across multiple project teams”.

This reflect lot of points I brought into our discussions either at Innoveo or Jobping; best practices, screen/page object, dev. language, recording/coding, BDD..

Here are the blog posts:

• Survival techniques for acceptance tests of web applications (Part 1)
• Survival techniques for web app acceptance tests, Part 2: increasing effectiveness and utility
• Web app acceptance test survival techniques, Part 3: Musings

And the key points I extracted from those three blog posts:

Best practices to have long-lived tests

“Acceptance tests must meet the needs of several groups, including the users and the developers. Long-lived tests must be written in the language of each group, using terms users will recognize and a programming language and style in which the developers are competent.”

“Utilities such as recording tools can help reduce the effort required to discover how to interact with the web application. The open-source test automation tool Selenium (http://seleniumhq.org/) includes a simple IDE record and playback tool that runs in the Firefox browser. Recorded scripts can help bootstrap your automated tests. However, don’t be tempted to consider the recorded scripts as automated tests: they’re unlikely to be useful for long. Instead, plan to design and implement your test code properly, using good software design techniques.”

“Several years of experience across multiple project teams have taught us that the tests are more likely to survive when they’re familiar and close to the developers. Use their programming language, put them in their codebase, use their test automation framework (and even their operating system). We need to reduce the effort of maintaining the tests to a minimum. Get the developers to review the automated tests (whether they write them or you do) and actively involve them when designing and implementing the tests.”

“Isolate things that change from those that don’t. For example, separate user account data from your test code. The separation makes changes easier, faster, and safer to implement, compared to making updates in the code for each test.”

“Robust tests can continue to operate correctly even when things change in the application being tested or in the environment. Web applications use HTML, so try to add IDs and CSS classes to relevant elements of the application
…
Try to avoid brittle identifiers, such as xpath expressions that rely on positional data. For example, /div[3]/div[1] becomes unreliable as soon as any of the positions change – and problems may be hard to identify unless the change is easy to identify.
…
Add guard conditions that assert your assumptions are still accurate. Design the tests to fail if any of the assumptions prove false.
…
Try to only make positive assertions. For example, if you expect an action to cause an item to be added to a list, assert that after the action the list contains the expected value, not that the list has changed size (because other functionality may affect the size). Also, if it's not something your test is concerned about, don't make assertions about it.”

“Informative tests
Help your tests to help others by being informative. Use a combination of meaningful error messages and more detailed logs to help people to tell whether the tests are working as intended and, if problems occur, to figure out what’s going wrong.”

“Taking screenshots of the UI when a problem occurs can help to debug the issue and disambiguate between mismatches in our assumptions vs. problems in the application.
…
Debug traces are useful for diagnosing acute problems, and range from simple debug statements like ‘I made it to this point’ to dumps of the entire state of values returned from the application by our automation tool. In comparison, logging is intended for longer-term tracking of behaviour which enables larger-scale thinking, such as enabling a test to be reproduced reliably over time.
…
Good error messages should say what’s expected and include the actual values being compared. Here are two examples of combinations of tests and assert messages, the second more helpful than the first:

1. Int actualResult = addTwoRandomOddNumbers();

assertTrue("Something wrong with calculation", actualResult % 2 == 0);

2. Int actualResult = addTwoRandomOddNumbers(number1, number2);

assertEquals(String.format("Adding two odd numbers [%d] and [%d] should return an even result. Calculated result = %d", number1, number2, actualResult) actualResult % 2 == 0);”

“My advice for developing acceptance tests for Web applications: start simple, keep them simple, and find ways to build and establish trust in your automation code.
…
The value of the tests, and their ability to act as safety rails, is directly related to how often failing tests are a "false positive." Too many false positives, and a team loses trust in their acceptance tests entirely.
…
Acceptance tests aren’t a ‘silver bullet.’ They don’t solve all our problems or provide complete confidence in the system being tested (real life usage generates plenty of humbling experiences). They should be backed up by comprehensive automated unit tests and tests for quality attributes such as performance and security. Typically, unit tests should comprise 70% of our functional tests, integration tests 20%, and acceptance tests the remaining 10%.”

“Lots of bugs are discovered by means other than automated testing – they might be reported by users, for example. Once these bugs are fixed, the fixes must be tested. The tests must establish whether the problem has been fixed and, where practical, show that the root cause has been addressed. Since we want to make sure the bug doesn’t resurface unnoticed in future releases, having automated tests for the bug seems sensible. Create the acceptance tests first, and make sure they expose the problem; then fix the bug and run the tests again to ensure the fix works.”

About Screen/Page objects

“Effective test designs

By using effective test designs, we can make tests easier to implement and maintain. The initial investment is minor compared to the benefits. One of my favourite designs is called Page Objects (see PageObjects on the Google Code site). A PageObject represents part or all of a page in a web application – something a user would interact with. A PageObject provides services to your test automation scripts and encapsulates the nitty-gritty details of how these services are performed. By encapsulating the nitty-gritty stuff, many changes to the web application, such as the reordering or renaming of elements, can be reflected in one place in your tests. A well-designed PageObject separates the ‘what’ from the ‘how’.”

BDD – Behavior Driven Development

“Another effective test design is based on three simple words: ‘given’, ‘when’, and ‘then’. As a trio they reflect the essential elements of many tests: given various preconditions and expectations, when such-and-such happens, then I expect a certain result.

// Given I have a valid user account and am at the login page,

// When I enter the account details and select the Enter button,

// Then I expect the inbox to be displayed with the most recent email selected.”

To me all those points are valid ! And the best is that most of them aren’t bound to a technology, a framework or whatsoever.

I could apply those principles on different applications built using ASP.NET MVC, WPF, Java JSF with different frameworks like MSpec, Watin, White, Selenium, JUnit/NUnit…

You might read more about this on the following posts:

• Automated WPF functional tests using White
• White’s tip for your automated WPF functional tests
• Automated functional tests using Watin and MSpec
• ASP.NET MVC 2, MSpec and Watin
• From WPF functional Unit Tests to Specifications using MSpec and White

Continue Reading »

An article by Laurent Kempé No Comments

Five Ways To Build Team Trust & Framework for Feedback

I am for quite some time now working on the Agile subject and tonight I read two very interesting posts that I wanted to share and keep track of.

The first one was posted by Mike Bria on InfoQ and is called Five Ways To Build Team Trust, in which advises are given to help trust form within teams.

1. Address Issues Directly.
2. Share Relevant Information.
3. Follow Through on Commitments or Give Early Notice When You Can't.
4. Say No When You Mean No.
5. Show What You Know and What You Don't Know.

The second post, “How I learned about Feedback” is from Ola Ellnestam, Agile Coach, Systems developer, Agile Practitioner, and is an excellent report on experiences applying a “feedback framework” learned from a workshop held by Esther Derby and Diana Larsen.

Framework for feedback

Esther Derby and Diana Larsen introduced me to a ‘Framework For Giving Feedback’. It looks like this.

• Create an opening
• Describe the behavior or results
• State the impact
• Make a request

I find this framework very easy to use and powerful. So, when I’m about to give feedback in tough or new situations I try to run through the scenario in my head, creating an imaginary outcome of the conversation. This has helped me several times. Lets look at the ‘meeting issue’ again.

Enjoy

Continue Reading »

An article by Laurent Kempé 1 Comment

Follow up on “Reducing ORM Friction” by Rob Conery

In my development process I do use what Rob is describing in his post “Crazy Talk: Reducing ORM Friction” with some slight differences.

For example I developed Tech Head Brothers portal this way, as Innoveo Solutions web site. I use TDD and Domain Driven Development and I keep the mapping as one of the last step for my implementation.

I do have a generic Repository interface as following:

My ORM mapping tool of choice is Euss. And here comes the slight difference, I do have one implementation of my interface leveraging Euss, and that’s it. All different possibilities are handled by Euss. During my work on the definition of the domain I took the habit to use an Euss XML Engine or an Euss Memory Engine. I use those two engine for my unit test and my real application.

Following the lean principle I postpone the choice of the data repository till the last minute, when I know more about the real need. So it really happen that I stay with an XML Engine so that all my data are stored in an XML file. If I need more I go to an Euss SQL Mapper Engine and then define the mapping.

So I moved to the ORM framework the different implementations.

Now I am still free to go to another ORM, or something else, by using the interface IRepository.

I used several time this technique and I am currently happy about it.

Continue Reading »

An article by Laurent Kempé 1 Comment

Attending “Agile Perspectives, Industry and Microsoft” PDC2008 Pre-Conference Session

I just registered online to PDC2008 and will attend the following Pre-Conference session:

Agile Perspectives, Industry and Microsoft

Presenter(s): Mary Poppendieck, Grigori Melnik

Agile development is here! During this all-day agile session Mary Poppendieck, author of "Lean Software Development: An Agile Toolkit" will share profound insights that will optimize your agile processes. The session will focus on best practices and advice to avoid the most common pitfalls for teams practicing or moving towards agile. During the second half of the session, Grigori Melnik, Technical Program Manager in Microsoft Patterns & Practices team, will share the lessons learned his team has acquired over many, many agile projects. The session will close with a panel - including Mary, Grigori, and a few guest speakers - for you to ask your tough questions around agile development.

About the presenter(s):

Mary Poppendieck started her career as a process control programmer, moved on to manage the IT department of a manufacturing plant, and then ended up in product development, where she was both product manager and department manager. After Mary left the corporate world in 1998, she found herself managing a government software project where she first encountered the word "waterfall.” When Mary compared her experience in successful software and product development to the prevailing opinions about how to manage software projects, she decided the time had come for a new paradigm. She wrote the award-winning book "Lean Software Development” to explain how the lean principles from manufacturing offer a better approach to software development. Over the past six years, Mary has found retirement elusive as she lectures and teaches classes with her husband Tom. Based on their on-going learning, they wrote a second book, "Implementing Lean Software Development.” A popular writer and speaker, Mary continues to bring fresh perspectives to the world of software development.

Grigori Melnik is a Senior Product Planner in the patterns & practices group at Microsoft, leading the Process & Engineering focus area. Prior to that, Grigori was a researcher, software engineer, coach and educator with 15+ years of meaningful industrial and research experience. His areas of expertise include agile methods, empirical software engineering, software testing and test automation, and software economics. Prior industrial engagements include Microsoft Canada Money and SmallBiz portals, Pan-Canadian Online Learning Portal, and The Canadian Agile Network - Le Réseau Agile Canadien. Grigori is an agile enthusiast who has been involved with the agile community since 2000. He is a regular contributor and speaker to software engineering conferences and workshops around the world. Grigori is the Program Chair of the Agile 2008 conference and a member of the IEEE Software Advisory board.

Some month ago I was asked at Innoveo Solutions to introduce some agile project management in the form of Scrum.

So I am delighted to have the opportunity to attend such a full day of Pre-Conference with Mary Poppendieck on this topic.

Continue Reading »

An article by Laurent Kempé No Comments