Run gem install behind a firewall in Windows

I’m contracting at a client running a Novell network and wanted to create some small little ruby scripts to automate some tasks for me. But I ran into problems using gem install behind their firewall. I’m getting the following error:

ERROR: While executing gem … (Gem::RemoteSourceException) HTTP Response 407

Here is the steps I followed to get gem install working on my windows xp machine in painstaking detail:

Firstly we need to set the HTTP_PROXY environment variable. I’ve played around with different options, using uid and pwd and other suggestions, but all I needed was the following:

1. On the desktop right click the ‘My Computer’ icon and select properties.
   
2. Now you can either add the HTTP_PROXY variable to the ‘User’ or the ‘System’ variables by clicking the ‘New’ button.
   
3. Within the new system variable dialog, specify ’HTTP_PROXY’ as the variable name and in the value area a url in the following format – http://%5Bproxy_ip%5D:%5Bproxy_port%5D – i.e. http://127.168.1.3:5865
   

Next we install the Ruby Win32 SSPI which gives ruby the ability to authenticate with ISA natively. We need this library because as far as I understand, it patches the Open-uri library because of some incompatibilities with windows. Anyways, follow the following steps to get it working:

1. Download rubysspi from the Ruby Win32 SSPI project page(also available as gem install rubysspi but that doesn’t help much, does it?)
2. Install the gem locally using the following command: gem install [local_path_to_gem]\rubysspi-1.2.3.gem i.e. C:\gems\rubysspi-1.2.3.gem
3. Now copy the spa.rb file from the gem install directory and paste it in the site-ruby directory. i.e. If ruby is installed in C:\ruby, then the paths should be:
   • origin path – C:\ruby\lib\ruby\gems\1.8\gems\rubysspi-1.2.3\spa.rb
   • destination path – C:\ruby\lib\ruby\site_ruby\spa.rb
4. Find gem.bat in your ruby bin directory (C:\ruby\bin) and replace the last line (i.e. "%~d0%~p0ruby" -x "%~f0" %*) with the following line – @"ruby" -rspa "c:\ruby\bin\gem" %1 %2 %3 %4 %5 %6 %7 %8 %9
5. Test you can access the remote ruby gems by executing the following command: gem list rails -r
   
6. You should see similar output as shown above.

Now we can work again without any issues when trying to install or update gems.

Enjoy!!!

Technorati Tags: Ruby, Rails, XP

It’s Not Just Stand-up

Martin Fowler posted this great article written by Jason Yip on Stand-up meeting patterns. Who would have thought that a soft process like a meeting can be described like a pattern. This is well worth the read. Here is an excerpt from the article:

The daily stand-up meeting is simple to describe: the whole team meets every day for a quick status update. This short definition does not really tell you the subtle details that distinguish a good stand-up from a bad one.

People who have experienced good stand-ups will generally know what can be done when things aren’t working well. This capability is obviously less likely for people with limited experience to reflect on. I’ve written this paper as an attempt to partly compensate for inexperience by describing the benefits and consequences of common practices for daily stand-ups. These patterns of stand-ups are intended to help direct the experimentation and adjustment of new practitioners as well as provide points of reflection to experienced practitioners.

Enjoy!

Everything you know is wrong

While I was searching for more information on Behaviour Driven Development, I ended up at Dave Astels blog. Now, many of you in the same headspace as me would probably point out that Dave is one of the pioneering thinkers in this area. Rightly so, but what I found was an interesting post regarding Agile. The first line of the post reads as follows:

I’m in Allen Holub’s talk this morning… “Everything you know is wrong: Inheritance and getters/setters are evil”.

When I read this statement, I found myself almost instantly offended. How can you make a statement like this? Do you want to tell me most of the other leading technical thinkers are WRONG? I mean, come on… We have been practicing Object-Orientation since the middle eighties and all our languages today is build to enable us to develop Object-Oriented software. I continued to read the post and then I found this paragraph:

Allen started off with the classic “tell, don’t ask” talk. He makes a very good point that hadn’t occurred to me before. To really get benefit out of an Agile process (specifically XP) you NEED to be doing OO properly. If you aren’t, you will fail.

I have made this exact point a while back when we where discussing Test-Driven Development. As any TDD zealot knows, you cannot effectively do test-driven development without having loosely coupled objects. Why? The reason is that when you are test-driving a piece of behaviour, you want to be able to test the behaviour in isolation. And to be able to do that, you need to Mock out external dependencies, and to mock the dependencies, you need to expose the dependencies as an interfaces. This brings me back, to another point. State based vs. Interaction based testing. When I started to get into TDD a few years back, I found doing Test-Driven Development was really-really hard. Why? Because I was only doing, state based testing. Since I learned to think in terms of the behaviour that I am trying to implement, I found writing the specifications (tests) are easier and my objects became more cohesive. On to the next interesting bit:

Next Allen moved to why encapsulation is so important and why getters & setters are such a problem. Don’t bother getting flustered about that idea.. he’s 100% on the money. If you disagree you need to learn what OO is. One nice soundbite: “Doing it this way (interface based, using design patterns) lets me have to think less. Thinking is hard… I’d rather just program.”

I agree with Dave on this one. Take for instance the Command-query Separation principle, as soon as you know and understand the principle, you consciously try to adhere to the rules of the principle. By doing this, your code starts to have less public properties and you get methods that are performing only one responsibility. I’m not trying to say that the Command-query Separation principle is the solution to the problem, but that knowledge of Object-Oriented principles will lead you to writing better, more bullet prove code. The Command-query Separation principle is only one in a multitude of Object-Oriented principles.

The bottom line(s):

1. There is no such thing as perfect
2. Design is a series of trade-offs
3. assess risk, then make reasonable decisions
4. there’s often is a better way of doing things than the first way you think of

tags: bdd, oop, tdd, xp

Extreme Programming in Practice

Jefferey Palermo has the following posts about how Extreme Programming helped his team to successfully deliver their software system to their client. He highlights not only the good that he experienced, but also speaks about the bad and ugly:

• Release retrospective on extreme programming practices
• Code analysis from an XP project
• TDD makes refactoring easy
• TDD reveals poor class design
• TDD speeds up unit testing

I’d recommend these posts. The posts are really informative!

 

tags: agile, design-patterns, code-smells, code-construction, refactoring, tdd

Misconceptions of Extreme Programming

Ralf’s Sudelbücher had a post about Collective code ownership is limiting software quality where he is saying that CCO is just a coping technique.

I think that he is missing the point of CCO completely. He is mainly talking about technology. Probably every professional developer out there today will tell you that it is impossible to be an expert in every conceivable area of software. The field of software development is too big and wide for any one developer to have an expert understanding of the whole discipline. I personally believe you should have a good base to work from (Good OO understanding) and a general understanding of technologies available. Now, at the same time the team should spread the technology research between them.

In our company, we might have four or five projects running at the same time. We have SQL experts, but they also have general programming capabilities. Thus giving our team the ability the share the unique knowledge between project teams as needed and at the same time spreading the SQL knowledge through pairing with non-SQL experts when implementing specific SQL functionality. Thus, the project does not have a bus factor at any point. We have a concept of assigning specific technologies the company thinks it needs to invest in, to technology groups. These might be three or four individuals in a group to research and become experts in a specific technology.

On another point he makes, when using TDD to drive your implementation and code, at some point if you have done it incorrectly, the code will hurt you. Why? Because you will have HIGH coupling between your object and you will start to feel the pain of fragile, breaking test. So what does this mean? Developers today still write procedural code. Go look at some of your code that you’ve written maybe yesterday, run a metrics tool like SourceMonitor over it, and if you find any code above 10 in Cyclomatic Complexity, I can guarantee you’ve written procedural code that is breaking some sort of OO rule. (Single Responsibility, Open Close, etc). I’ve written a code project article on exactly this type of code and how easy it is to write code with high complexity.

The way TDD forces you to write loosely coupled code is through having to replace external dependencies in the class under test with Stubs or Mocks using Inversion of Control and Dependency injection. Moreover, because Mock frameworks normally can only mock interfaces, this will force you to communicate to the external component through an interface, which means you have low coupling between these two components. Knowing Design Patterns will also help you to practice TDD more efficient.

On another note, I think he is also missing the relationship between the XP practices and the roles these practices play in supporting each other. If you look at CCO in isolation, you are missing crucial benefits you are getting when you look at CCO in context to the other practices. What do I mean? Well, all the practices of XP support each other and as a whole make developing software easier and more productive, reducing the risk of failure. Have a look at this essay explaining this in more detail.

 

tags: xp, tdd, standup, codemetrics, code-smells

Currently listening to: 1 – Winamp *** 124. Paul Oakenfold – New York disc 1

Code Metrics, Code smells and Refactoring in Practice

In this article I describe how our team uses metrics to identify code smells and apply refactorings to correct these code smells. This example is real simple but it shows exactly how some of the eXtreme programming practices are helping our team to maintain our code. 

 

Our team uses eXtreme programming practices to manage development on a mission critical system for a large retail chain. We have not adopted all the practices, but use the majority of the practices.

Here is a list of the practices we use:

• Test-Driven Development (VSTS Testing Tools)
• Collective Code Ownership
• Coding Standards (FxCop, Code Metrics)
• Continuous Integration (Daily builds, but we are looking to implement a CI environment soon.)
• Planning Game ( Iteration planning and daily standup meetings )
• Customer Test (Fit, VSTS Web Tests)
• Small Releases (Fortnightly UAT Releases)

Every morning at the standup meeting the team lead will report on the nightly integration build.

This report includes the following metrics:

• Unit tests passed, failed, ignored
• Fit test passed, failed, ignored, exceptions
• Test Coverage (Should be more than 80%)
• Cyclomatic complexity (Should be less than 10)
• Code Instructions (Should be less than a 100)
• FxCop rule validations

Each day metrics are compared to the previous day and overall the project manager tracks these metrics to get an overall feel for the health of the project.

You can find the rest of the article here.

 

tags: agile, ci, code-smells, codemetrics, refactoring, standup, userstories, xp

Currently listening to: 19 Vegas Soul-Junk Funk – Winamp *** 46. DANNY TENAGLIA – 19 Vegas Soul-Junk Funk

Visual Studio 2005 Unit Testing Code Snippets

In this article I describe how our team uses metrics to identify code smells and apply refactorings to correct these code smells. This example is real simple but it shows exactly how some of the eXtreme programming practices are helping our team to maintain our code. 

Our team uses eXtreme programming practices to manage development on a mission critical system for a large retail chain. We have not adopted all the practices, but use the majority of the practices.

Here is a list of the practices we use:

• Test-Driven Development (VSTS Testing Tools)
• Collective Code Ownership
• Coding Standards (FxCop, Code Metrics)
• Continuous Integration (Daily builds, but we are looking to implement a CI environment soon.)
• Planning Game ( Iteration planning and daily standup meetings )
• Customer Test (Fit, VSTS Web Tests)
• Small Releases (Fortnightly UAT Releases)

Every morning at the standup meeting the team lead will report on the nightly integration build.

This report includes the following metrics:

• Unit tests passed, failed, ignored
• Fit test passed, failed, ignored, exceptions
• Test Coverage (Should be more than 80%)
• Cyclomatic complexity (Should be less than 10)
• Code Instructions (Should be less than a 100)
• FxCop rule validations

Each day metrics are compared to the previous day and overall the project manager tracks these metrics to get an overall feel for the health of the project.

You can find the rest of the article here.

tags: agile, ci, code-construction, code-smells, codemetrics, mstest, refactoring, tdd, xp

Currently listening to: 1 – Winamp *** 53. Darren Emerson – Uruguay disc 1

Pondering Agile…

Jay Kimble had a rant about the Waterfall process and here are some quotes from his post:

“I got into IT to program computers; I love programming. I didn’t get into IT so that I could write technical specifications. “

The first thing to hit us was the change control process which can be a fairly lengthy process… one size fits all; if you are deploying a small intranet site or a major mainframe change it all travels through the same process. Change management is absolutely essential (don’t get me wrong), but the problem has been that the company itself is reactive, so every mistake by someone ends up causing more paperwork for everyone else. Next we added Design docs, and from there who knows where, but we’re pretty much in full SLDC.

IMO, waterfall (SDLC) looks like “death by paperwork” to me.

I think Jay has a point here… These business management processes are overbearing and waste a lot of time. Just the other day I’ve spent two weeks updating a technical spec and only spent a week building the system. I could have done the system without updating the spec and would have saved two weeks, where we could have spent on additional features for the system.

tags: agile

Currently listening to: cevin fisher – it’s all good – Winamp *** 501. cevin fisher – it’s all good

Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience

I’ve been listening to the Agile Toolkit’s Pod cast featuring Arlo Belshee and his experience on Promiscuous Pairing and the Least Qualified implementer.

Now what can be so interesting about pair programming you ask?

Well, in the podcast Arlo talks about how his team started to experiment with the XP processes and found that when they used metrics to measure how well they where doing when Pair programming, they found that using a concept of “Beginners Mind” when pair programming by making sure they have a least qualified member in a pairing all the time they where able to greatly improve their productivity.

So how does it work?

A pair of programmers will start out with the least qualified developer paired with another developer working on a specific piece of code, then after 90 minutes the most qualified developer in the pairing moves on to another pairing and become the least qualified developer. The developer left in the original pairing becomes the most qualified developer and thus become the teacher for the new developer in the pairing. Thus the new developer is now the least qualified developer in the pairing. And so after 90 minutes, the cycle starts over…

It is really quite interesting and thought provoking when you listen to the conversation and read the paper.

tags: xp, testing, pairprogramming

Currently listening to: p *** 536. delerium – silence(dj tiesto mix)

Kent Beck – Developer Testing

Pod casting has become really popular in the last year or so and I am starting to really enjoy listening to all the proffesionals having their say.

I’ve found this new Technical IT related padcast site with the following pod cast by Kent Beck: Kent Beck – Developer Testing

More about the site:

IT Conversations is a listener-supported web site. Many listeners contribute to our tip jar, but others contribute in a different way: They’re the people behind the scenes who volunteer their time to write and debug the software, write the descriptions, track down the photos, and engineer the audio of IT Conversations programs. Go check them out, they’ve got some really cool stuff to listen too…

tags: xp, testing, tdd

Currently listening to: dance – Winamp *** 290. mark siegenthaler – fast dance