Sunday, February 18, 2007

Super Developer as recruiters said

At one user group meeting, recruiters said that companies are asking for so-called Super Developer, who can use e.g. Java, PHP as needed.

At that time, I thought that it is difficult to be such a developer unless you are in an Agile software development environment, especially, Extreme Programming using Pair Programming.

In Extreme Programming, developers work on different tasks, e.g. front-end, server-side, database, environment settings, switching to work on different tasks often. But if you work in non-Agile environment, you are only assigned to one task, such as front-end GUI development and you never have a chance to even look at the code for the rest of the system.

One recruiter said that you need to be able to work on both Agile and non-Agile environment. Of course, she is just a recruiter and doesn't know what is actually involved in software development. But you can't ask a developer to be a Super Developer while you are demanding him/her to work in non-Agile environment.

Also, I thought that they are missing that each language has its pitfalls. How can one person know the pitfalls when he/she is working on many languages for a short period of time each? What I observed from those developers is that they tended to use wrong solution for each language because they didn't know that there is a better proper well-established solution in a particular language because he/she hadn't had enough time to learn about them.

I also think that it may be an organizational problem in the companies that they demand Super Developer. Aren't they using improper stale technologies instead of improving to use better technologies that have learned from the mistakes made by other technologies in the past? If that's the case, even if the companies bring Super Developer, he/she cannot solve the fundamental problem and as he/she works in such an environment, he/she eventually stops being Super Developer because he/she is constrained to use only the technologies the companies force.

Instead, I agree with what Scott W. Ambler said in his essay on Generalizing Specialists.

Friday, February 16, 2007

Set up Pound to use HTTPS with Mongrel

I wanted to use HTTPS and followed what is written in Pound Best Practice Deployment and Pound Installation mostly. Also Think Again! >> Mongrel is useful.

Briefly, the following is what I did:
1. Install Pound
$./configure --prefix=/usr/local
$ make
$ sudo make install
2. Update mongrel to 1.0.1 (because I had one older one)
$ gem update mongrel
3. Install mongrel_cluster gem
$ gem install mongrel_cluster
4. Configure Pound
4-1. Created pound.cfg under /user/local/etc.
4-2. Filled the pound.cfg with the following content:

ListenHTTP
Address 0.0.0.0
Port 80
Service
BackEnd
Address 127.0.0.1
Port 8000
End
End
End

ListenHTTPS
Address 0.0.0.0
Port 443
Cert "/usr/local/etc/test.pem"
# pass along https hint
AddHeader "X-Forwarded-Proto: https"
HeadRemove "X-Forwarded-Proto"
Service
BackEnd
Address 127.0.0.1
Port 8000
End
End
End

4-3. Generated test certificate
$ openssl req -x509 -newkey rsa:1024 -keyout test.pem -out test.pem -days -nodes
5. Configure Mongrel Cluster and start Mongrel with Cluster
$ cd railsapp
$ mongrel_rails cluster::configure -p 8000 -N 1 (I set the number of clusters to be 1.)
$ mongrel_rails cluster::start
6. Start Pound
$ sudo pound -f /usr/local/etc/pound.cfg

Note:
The following command shows Help for Mongrel (e.g. "mongrel_rails cluster::stop" to stop Mongrel with Cluster):
$ mongrel_rails help

Tuesday, February 06, 2007

Friday, February 02, 2007

Uncle Bob's blog about Specs vs. Tests

Specs vs. Tests.

I like RSpec myself and Behavior-Driven Development in general.
But never thought of it in the way Uncle Bob described.
Also the comments to the blog by Michael Feathers and others are interesting.
Interesting reading.

I just wish I could work with developers like them.