Someone on the Grails mailing list was asking for docs for newbs. When I started in on Grails I put together this Grails reference doc. It’s mostly useful as a suppliment to the official grails docs that puts the core stuff you’ll probably want to know in one place. This is NOT a tutorial. It’s crude. It’s rough and it’s haphazard, but if you’re new to Grails you may find it useful.
Some of you have gotten the distributed version control religion (If you
haven’t, you should read my
Best
Practices essay) but are stuck with Subversion (or CVS) either because
that’s what they use at work or because some part of your deployment systems use
it. You may also want to combine them simply because of the power of svn
externals which lets you pull in some of your code from constantly updated ,
Subversion Based, 3rd party repositories. Using SVN with a distributed version
control system also gets you a cannonical, no doubt about it, central repo,
instead of just a repo that everyone agrees to call the central one, plus you
can utilize all those nifty notification and stats tools people have written for
svn.
What makes this work so easily is the fact that Darcs stores everything in one
_darcs directory instead of the SVN / CVS approach of throwing files in every
single directory. There are a ton of reasons to use Darcs (or it’s competitors)
when working in a corporate env (even one that uses SVN / CVS) but my favorite
is that you get the full benefit of version control on all your work and can
check in all the buggy crappy unfinished code you want without polluting the
central repo that affects other developers (until you want to). It’s my
practices to do a checkin when I leave work every day, no matter if I’m finished
with what I was working on or not. With Darcs it doesn’t matter, because I won’t
break anyone elses unit tests because it’s just my personal version control
system that’s effected. When I’m done with whatever I was working on and it
passes all the tests I can push it back out to other developers. Along the way
I’ve been able to make as many revisions of the files as I wanted to without
screwing anyone else over.
For those of you who have to use Subversion / CVS at work sneaking Darcs in for
your personal benefit it trivial. Just follow these steps for each branch (in
svn / cvs ) that you need to work on.
So you’ve convinced everyone to use Darcs. Yay, but for whatever reason you’ve
decided to keep SVN. Just follow steps 1-5 above. You could theoretically check
in your _darcs dir but I suspect that might just lead to more headaches than
it’s worth, especially when you consider how easy it is to create a new darcs
repo (steps 2.1-2.2) and the fact that you only have to do this the first time
you check something out, which is to say, almost never.
If you’ve tried checking your _darcs dir into svn please add a comment so that
I, and others, can learn from your experience.
[Update] Related posts:
Using Darcs with SVN / CVS Flow Chart
Why you should be using a distributed source control system
I wrote this essay a while ago and have been tweaking it based on the feedback from those I’ve sent it to (thanks guys). There are a few things I’d like to change still but I’m going to go with the “Release early. Release often” mantra on this one. I think it’s more important that it get out there than it being perfect.
Best Practices for Web Developers introduces the idea of Heuristically Driven Development ( HDD ) as it applies to web development, but honestly almost everything in there is applicable to all forms of development. There’s an HTML version and a PDF version and your feedback would be greatly appreciated and help to make the next iteration of the document better.
I’d include it here but it’s just too long for a blog post.
You really don’t want to become a programmer.
How do I explain to you that programming is an endeavor of passion?
You look at it and see text on a screen and a good paycheck.
I see problems begging for solutions.
You see tasks to be completed.
I see mountains to be scaled, and wells to be dug.
You think, “I could sit at a desk and poke at a computer all day.”
I forget there is a desk, what day it is,
or that my chair’s been broken since I started here.
You try and do the tasks set before you.
I work binary clay into sculptures,
sometimes bland and functional,
sometimes grand and fanciful,
but always striving, always trying to
become.
You don’t want to be a programmer.
You either are one or you aren’t.
No school can teach you to love.
They can only give you skills.
And, what good is knowing how to sculpt
if you don’t find wonder in the David?
You’ll spend your days chiseling at stone.
Clink. clink. clink.
I’ll spend my days striving for beauty.
You’ll go home bored and unfulfilled.
I’ll go home thrilled.
It’s like drugs for us. There’s an adrenaline rush.
We solve it! We did it!
You… you get to move on to the next task.
You don’t want to become a programmer.
We’re born, not made.
It is passion, and skill, and art.
We’re obsessed with the problems.
We love, and hate, the insanity of the bugs
that offer themselves up to us.
“Why does it do that?! That makes no sense!”
we cry with mock outrage, secretly thrilled.
The hunt is on.
You… “You’ve got another problem with your app,
and, oh yeah,
you’ve got 20 minutes before they need to demo it.”
Raganwald
suggests, with good reasons, why you
shouldn’t
over-think FizzBuzz. Obviously I took
a
different view of it and yet I still agree
with all of his points.
So, I’d like to counter with some reasons why
you should
over-think FizzBuzz, and why I did,
because I don’t think I did a great job of explaining that in my last post. But
first, lets assume you’re not being asked to solve it on a whiteboard while the
interviewer waits. In that case my 400(ish) line solution is completely
inappropriate. In fact, anything but a quicky solution is inappropriate. Lets
also assume that in submitting an over-thought solution to FizzBuzz you make it
perfectly clear that you know it’s
over-thought and what you were hoping to achieve by going to such ridiculous
lengths in your creation.
As I mentioned in
FizzBuzz
rethink hundreds of programmers rushed to
solve FizzBuzz in the comments of the various posts about it and many of them
got it wrong. I suggested that this was a classic example of what’s wrong with
this industry. And the reason I believe that is exactly why I think FizzBuzz
should be over-thought.
As sad as it is that there are so many
“programmers” out there who can’t successfully solve the FizzBuzz problem I
believe it’s even sadder how many companies are allowing their programmers to
take a half-assed approach to software development. There are far too many who
still think that writing unit tests isn’t worth the time, or that since they
can’t possibly test for every possible scenario they’ll test for none. Some
don’t even use version control. These companies, like the people who rushed to
post FizzBuzz solutions without really reading the instructions, allow their
developers the slap together the first thing that comes to mind and rush it out
the door without any real clue if it’ll break anything else when deployed, if it
really meets the clients needs, or, in the case of the posters, if it will make
them look like an idiot for not even being able to correctly solve FizzBuzz.
With the previously stated assumptions in mind
an over-thought FizzBuzz solution is excellent because it tells the employer
that:
It’s great for the interviewee because if the
employer starts bikeshedding you know you don’t want to work for them. If the
interviewer does “grill you over why your solution doesn’t use the
Y
Combinator to implement compose", as Raganwald suggests, then you know these people may actually have brains, and I would much rather work for people with brains who will challenge me. If the challenge comes in the form of suggesting you're a loon for such an extreme solution it's an opportunity to defend why you think it's good and see how they deal with a person willing to stand up for their craziness. You'll quickly learn if they’re
the kind of company where they expect you to roll over and acquiesce to their
suggestions or if they are willing to have a real debate with you. Either way
you learn a lot about the employer that will help you decide if you’d even want
the job. It’ll also give them a good idea of how you handle your peers
suggesting that you’ve done something wrong.
I’m not sure I want to work for someone who can’t see the value of an
intentionally over-thought FizzBuzz like mine.
Or maybe overthink would be more appropriate….
[UPDATE] I’ve written a followup about why an over-thought solution like the one proposed here can be / is a good thing. And just to be blazingly, obviously, painfully clear on the matter. I donot think that every problem should be over-thought to the degree I took this. My solution represents a crazy amount of code for such a small problem. It’s intended as an example of how I’d mentally approach a real and complex problem presented by a client.
The FizzBuzz test was conceived by Irman and posted here:
http://tickletux.wordpress.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/
It was to be used as a method for weeding out applications for developer
positions who couldn’t code anything and the original test instructions
were to:
Write a program that prints the numbers from 1 to 100. But for
multiples of three print “Fizz” instead of the number and for the multiples of
five print “Buzz”. For numbers which are multiples of both three and five print
“FizzBuzz”.
ANY developer should be able to write a solution to this and many did
in the comments of the original post and other posts that referenced it.
Unfortunately, as a number of bloggers pointed out, many of the people who
rushed to post solutions GOT IT WRONG! Mostly this was a result of just not
reading those three sentences carefully enough. I know, you’d think you
wouldn’t have to re-read those…
The solutions people were posting were inadvertently providing a classic
example of what’s wrong with how so many developers approach professional
software projects, which means that FizzBuzz is a better interview test than
anyone seems to realize. How a person approaches this problem for an
interview is a great example of how they’ll approach other problems
they’re faced with should you decide to hire them.
I’ve been coding professionally for over a decade now and along the way I’ve
learned a number of things; things that I’d like to see addressed either in
code or by the questions an interviewee asks in response to the test. So lets
set the stage for something a little different.
First, we’re going to assume that it’s been explained that the FizzBuzz test
is based upon a children’s game of the same name.
In this game a group of children sit around in a group and say each
number in sequence, except if the number is a multiple of three (in which case
they say “Fizz”) or five (when they say “Buzz”). If a number is a multiple of
both three and five they have to say “Fizz-Buzz”.
Second, you have to remember that this is for an interview so the
response should not only display that they CAN code but, hopefully, give an
idea of how they’d approach the task of writing software for one of the
interviewer’s clients because if someone’s hiring you to code then there’s a
client (even if it happens to be the same company). Seeing if the interviewee
can make this logical leap without being told is another part of the test.
Third, after explaining the game the test is based on and with the assumption
that the person knows this is for an interview use the same instructions.
Click here to see my solution or pretend you’re an interviewee and write something to impress then see how our solutions compare.
