();
I had a HTC Desire for nearly six months. Sadly, about a week ago, it passed away. The desire was my first smart phone and I think it’s true what they say; the first love is the deepest.
The desire was an excellent phone, I have no complaints, but it was a mistake for me. I like to jump off boats, walk in the rain and generally not have to obsess about protecting an expensive electronic device. The desire was my business phone so once the autopsy was complete it needed a replacement quickly. I called my carrier and they told me I could have a new phone for $720. No thanks. So I went looking for a cheaper alternative that still has all of the features I require.
In the end I settled on the Desire’s kid brother, the HTC Wildfire. The wildfire is currently selling for less than half the price of the Desire. It is another Android/HTC Sense phone but with less memory, a slower processor, and an inferior screen.
Apart from 3d graphics and high-res video the Wildfire can do everything that the Desire can do; the Desire just does it better.
Apart from 3d graphics and high-res video the Wildfire can do everything that the Desire can do; the Desire just does it better.
It can run apps, manage my email, surf the web, watch flash movies, make phone calls, use SMS and provide high speed internet access to my laptop. Also, the wildfire is a slightly more comfortable size, has significantly better battery life and a superior power button (the power button on the Desire is too easy to activate accidentally). For the price ($350) the Wildfire is a terrific smart phone.
The wildfire’s interface is noticeably slower, the text rendering is awful and the reduced screen area occasionally causes problems on interfaces that were clearly designed for a larger screen. Of all the inferiorities of the wildfire it is the screen that bothers me the most. It simply looks terrible in comparison to the Desire.
With my current carrier both of these phones are available on a $49 plan, so you would be insane to chose the Wildfire. However, if I had to pay for the phone I’d get the Wildfire and give my wife the spare $450 to spend on something pretty.
These days it seems that everyone has a crush on Ruby. I presented two sessions at this year’s Adelaide Code Camp: BDD with StoryQ and I Am IronRuby. After the standard IronRuby demonstration (creating a new project and scaffolding) I showed off some of what I like about Ruby. I started with a file containing Ruby comments describing nice features of the language. Then I worked my way through the script writing the Ruby to demonstrate each feature. The result is similar to my JavaScript Koans, but without the executable tests.
I hereby invite you to publish something similar in your language of choice.
# ruby is a scripting language
# code in a file is executed when it is parsed
puts "I am alive world"
# variable declaration
person = 'liam'
# string interpolation
puts "#{person} is alive"
# class definition
class Person
#constructor
def initialize
# member variables
@name = 'liam'
end
def name
# implicit returns
@name
end
# method definition
def do_something
yield self
end
end
# blocks
liam = Person.new
liam.do_something do |person|
puts person.name
end
# dynamic
def liam.age
27
end
puts liam.age
puts liam.send('age')
# destructuring assignment
a,b = 1,2
puts a
puts b
# arrays
trolls = ['Ted', 'Bill', 'Bert']
trolls.each do |troll|
puts troll
end
# other functional methods
big_trolls = trolls.map {|troll| troll.upcase}
# methods defined directly
def print_trolls(trolls)
trolls.each do |troll|
puts troll
end
end
# optional parenthesis
print_trolls big_trolls
# all statements return a value
odd = true
print(if odd
"3"
else
"4"
end)
# ranges
(1..5).each {|number| puts number}
('a'..'z').each {|letter| puts letter.upcase}
# first class regular expressions
if /fox/.match "quick brown fox jumps"
puts 'contains fox'
end
# substitution
puts("I am a cat person".gsub /cat/, 'dog')
# inverse conditionals
six_equals_nine = false
puts "6 is not nine" unless six_equals_nine
# OO style null checking
you_got = nil
puts you_got.nil?
For..
There is a good deal of Ruby envy among the more outspoken .NET developers. This post is an attempt to aggregate the many blog posts from .NET developers expressing their love of ruby.
Why I Like Ruby
Why I Like Ruby, Part 2: Blocks
Contrasting Ruby and C# Using My College Friends
Ruby For .NET Developers
What is so great about Ruby?
Silly thing I want from Ruby in C#
Essence and ceremony, Ruby and C#
Why I Love Ruby
Why you don’t need dependency injection in ruby
I don’t know how this blog is going to evolve
I know there have been a lot more of these but this is what I could find quickly. If you have a good link that belongs on this list leave it in the comments.
Michael Minutillo posted the texas hold ‘em coding challenge to the oz alt.net mailing list. The challenge is to write a program that can take poker cards as input and return information about what hands players have and who is the winner.
Solving this problem in my 9-to-5 language (c#) is not interesting to me, so I chose to do it with my beloved CoffeeScript.
The first challenge I faced was one that I have been working on for months – how to compile CoffeeScript on Windows. CoffeeScript has no runtime, it must be compiled to javascript and the supported engine for doing this is Node.js, which doesn’t work very well on Windows. Following much trial and error I eventually settled on a JavaScript environment based on jslibs put together by Alisey Lebedev. I use a slightly modified version that makes it easier to compile multiple CoffeeScript files at once.
Exercises like this one lend themselves to TDD. CoffeeScript compiles to JavaScript, and there are many test frameworks available for JavaScript. I chose QUnit because I am familiar with it from my JavaScript Koans work. QUnit allows me to write tests like:
module('card');
test('construction', function() {
var two_clubs = new Card('2c');
equals(two_clubs.index, '2');
equals(two_clubs.suit, 'c');
});
and when I run the tests I can a nice output like:
The goal of these challenges is to publish solutions so we can learn from each other. I used this as a motivation to learn git and github. For other windows developers wanting to start down this road my advice is:
I don’t usually like screencasts (except mine ;) but Bobby’s is perfect for git beginners. I literally typed along with Bobby.
My solution is available in all its CoffeeScript glory. It’s not entirely complete but this has taken forever and I had to draw the line. If you download the source you can run the tests by opening the file tests.htm in any browser other than IE. If you want to experiment with the solution you can make changes to the CoffeeScript source files and recompile with:
bake compile
bake compile
To run the application once compiled
bake run
bake run
you should see the following output:
IMPORTANT: Before reading this post open this link and let it play.
This is my response to the 2nd Developer Blog Banter. The question asked?
The first developer blog banter was about technology stack.
I organise tests into two groups: slow and fast. That is the only dichotomy that I care about. I try to run the fast tests all the time (using testdriven.net keyboard shortcuts). The slow tests are run less frequently such as when I change something external or when I think there is a chance I may have broken something as well as during the continuous integration build.
The majority of my tests are written as BDD style executable specifications using StoryQ. I spoke about this at the South Australian code camp and I will be presenting a new and improved version at CodeCampOz. This is obviously a topic close to my heart; I presented similar material at this year’s Seattle Code Camp. I test this way to realise the following benefits:
To briefly summarize the storyq approach, you start with a story like:
Story: Customer Complaints In order to get satisfaction As a customer I want to submit a complaint
From which we can derive scenarios to specify the feature by example. We use the familiar given, when, then syntax to separate the context and the observations from the event:
Scenario: Stupid Complaint Given I am a customer and my complaints are stupid when I complain then my complaint is ignored
Scenario: Valid Complaint Given I am a customer and my complaint is valid when I complain then my complaint is handled and the manager contacts me to apologise
StoryQ provides a GUI tool which converts these scenarios into boilerplate code:
[TestFixture]
public class StoryQTestClass
{
[Test]
public void CustomerComplaints()
{
new Story("customer complaints")
.InOrderTo("get satisfaction")
.AsA("customer")
.IWant("to submit a complaint")
.WithScenario("stupid complaint")
.Given(IAmACustomer)
.And(MyComplaintIs, ComplaintValidity.Stupid)
.When(IComplain)
.Then(MyComplaintIsIgnored)
.WithScenario("valid complaint")
.Given(IAmACustomer)
.And(MyComplaintIsValid)
.When(IComplain)
.Then(MyComplaintIsHandled)
.And(TheManagerContactsMeToApologise)
.ExecuteWithReport(MethodBase.GetCurrentMethod());
}
private void IAmACustomer()
{
throw new NotImplementedException();
}
private void MyComplaintIs(ComplaintValidity validity)
{
throw new NotImplementedException();
}
private void IComplain()
{
throw new NotImplementedException();
}
private void MyComplaintIsHandled()
{
throw new NotImplementedException();
}
private void TheManagerContactsMeToApologise()
{
throw new NotImplementedException();
}
}
If we run the tests now the output shows, as expected, that nothing is implemented.
The developer’s job is now clear: to get all of the tests to green. When that is done we know that the requirements have been satisfied:
The way of working that I have described is similar to the workflow implemented by many ruby developers using cucumber. Where they typically choose to have their tests interact with their application’s interface I usually try to test against the layer immediately below the user interface. I developed this approach after listening to Hanselminutes episode 151 - Fit and Fitness with Ward Cunningham and James Shore. In that episode Ward says:.
This comment resonated with me because of the pain that I had been experiencing with UI tests. I still do the occasional UI test but I believe that attempting to prove that an application satisfies it’s requirements by testing through the UI is frustrating and ultimately futile.
Until next time, take care of yourselves and each other.
As we speak (figuratively) a group of 50 aspiring entrepreneurs are gathered in an abandoned warehouse deep in the heart of the upmarket Sydney suburb Redfern for Sydney Startup Camp IV.
Their hosts, Bart Jellema and Patrick Driessen, have been guiding the participants through the process of starting a new technology business, accelerated so that the process fits into a weekend. There has been brainstorming, product development, marketing plans and pitches to the press and investors. The atmosphere is overwhelmingly enthusiastic and creative. It is a reminder of what talented people can achieve with the right intrinsic motivation. Conversely, it is a reminder of the spectacular waste present in some large organisations, who could not achieve in a year what the teams here are achieving in a weekend.
Yesterday, Catherine Eibner presented Microsoft’s startup offering, Biz Spark. It was a tough assignment since only one of the teams had chosen to work with Microsoft tools (other that powerpoint!).
Part of the experience has been to push the physical boundaries – working around the clock. The diet has also suffered. Check out my biscuit smiley face.
If you are here at Startup Camp feel free to add a link to your product to the comments.
I have waged and long and bloody battle to find a way to work with CoffeeScript on Windows – and now I finally have!
The first step is to get CoffeeScript from github. You can either pull the source with git or download an archive after some hardcore archiving action.
The CoffeeScript compiler is written in CoffeeScript and provided in compiled JavaScript form. Therefore, we need a server-side JavaScript environment to execute the compiler and transform our CoffeeScript scripts into JavaScript that a browser can execute. Somehow, in my struggles I missed JSDB, a minimal server-side JavaScript environment. JSDB comes as a zip archive. To access the shell simply unzip and run jsdb.exe. From the shell you can execute any JavaScript that does not rely upon browser objects.
The basic steps to compile coffeescript are:
Here is an example:
It would be nice to be able to pass a directory to the compiler and have it compile all of the CoffeeScript files to JavaScript. I created the following scripts to do that, based on the work of TBD. Both files should be placed in the CoffeeScript bin directory. When complete a directory can be compiled by calling Coffee.bat and passing the path to jsdb.exe and the directory to be compiled as follows:
coffee.bat “..\jsdb\jsdb.exe” “d:\scripts”
coffee.bat “..\jsdb\jsdb.exe” “d:\scripts”
Coffee.bat
@echo off
if "%~1" == "" goto usage
if "%~2" == "" goto usage
%~1 -nojit jsdb.js %~1 %2
goto end
:usage
echo coffee.bat [path_to_jsdb.exe] [directory_containing_coffee_files]
goto end
:end
jsdb.js
load("..\\extras\\coffee-script.js");
writeln(system.arguments[1]);
system.setcwd(system.arguments[1]);
var files = system.files('*.coffee');
function getSource(filename) {
var sourceStream = new Stream(filename);
return sourceStream.read(1000000);
}
function getJavaScript(coffee) {
return CoffeeScript.compile(coffee);
};
function writeJavaScript(javaScript, filename) {
var javaScriptStream = new Stream(filename.split('.')[0] + ".js",'wt');
javaScriptStream.write(javaScript);
}
for (var i = 0; i < files.length; i++) {
var coffee = getSource(files[i]);
var javaScript = getJavaScript(coffee);
writeln(javaScript);
writeJavaScript(javaScript, files[i]);
}
Here is the result of compiling the examples from the CoffeeScript home page. The output is saved to cs_examples.js:
When working with multiple IIS worker processes it is useful to be able to correspond the processes to application pools. The command to do this in IIS 7 is:
%windir%\system32\inetsrv\appcmd.exe list wp
%windir%\system32\inetsrv\appcmd.exe list wp
The output looks like:
WP "3948" (applicationPool:Classic .NET AppPool)
WP "3948" (applicationPool:Classic .NET AppPool)
You can see the PID (3984) and the name of the application pool. The PID can be used to find the process in task manager and the Visual Studio Attach to Process dialog.
Following my announcement of a javascript koans project I am pleased to announce that I have published a draft of the project on google code. The topic ‘about prototypal inheritance’ is empty at the moment because I don’t feel that I understand it enough to write the koans.
Please download and play with the draft JavaScript koans. Let me know if you learn something.