On Not Giving a Fuck

This is just to say.
Not a single fuck was given today.

readImage

Today I realized I’ve spent way too much time giving a fuck about shit that just doesn’t matter. I see now how closely not giving a fuck ties in with Buddhism. It is not about disregarding everything and being reckless. Rather it is about focusing on what matters and what is important to you and letting the rest of the bullshit go. In other words, enlightenment is not giving a fuck.

That’s a simple idea to conceptualize but to truly live by not giving a fuck requires a lot of life experience. It means dealing with enough crap in your life that you can easily recognize what will have lasting importance in your life and what is just crap that won’t matter to you in the long run.

A warning here is important: Not giving a fuck is not about being jaded or cynical. Jadedness and cynicism lead to nihilism. By the nihilist point of view life is meaningless and even giving a fuck about not giving a fuck is pointless.

Rather the point is to become grounded in your reality. Grounded in what it is that matters to you. Grounded in what is worth giving a fuck about to you. When you are firmly grounded in this every fuck you give will matter. It will matter to you and people will recognize this. It may or may not matter to them but they will at least respect the firmness of your conviction whenever you do give a fuck.

If you live by this people will accept when you don’t give a fuck. Everyone wants you to give a fuck about the shit they give a fuck about. But too often we get caught up in giving a fuck about shit that doesn’t matter and everyone knows this. When you say “no I don’t give a fuck” you are letting people know that you do not want to be caught up in their bullshit. People will either recognize that and accept it or start creating more bullshit.

By reserving your fucks to only what truly matters to you you are living in balance like a Buddha. You spend no extraneous effort on what is not important to you. You are connected and grounded in reality. Any facade you were trying to uphold and maintain falls away and only your true being remains. Once you are comfortable with that your life opens up and becomes spacious enough to be filled with what truly matters to you. Things such as love, happiness, joy, caring friendships, health, and wealth will replace all the shit you wasted your time and energy giving a fuck about.

Posted in Uncategorized

Seven Tips From Ernest Hemingway on How to Write Code

With apologies to Mike Springer.
Image

Before he was a big game hunter, before he was a deep-sea fisherman, Ernest Hemingway was a craftsman who would rise very early in the morning and write code. His best applications are masterpieces of the modern era, and his prose coding style is one of the most influential of the 20th century.

Hemingway never wrote a treatise on the art of writing code. He did, however, leave behind a great many comments in scripts, web sites and applications with opinions and advice on programming. Some of the best of those were assembled in 1984 by Larry W. Phillips into a book, Ernest Hemingway on Writing Code. We’ve selected seven of our favorite quotations from the book and placed them, along with our own commentary, on this page. We hope you will all–programmers and users alike–find them fascinating.

1: To get started, write one true test.

Hemingway had a simple trick for overcoming programmer’s block. In a memorable comment in AMoveableFeast_spec.rb, he writes:

# Sometimes when I was starting a new program and I could not get it going,
# I would sit in front of the fire and squeeze the peel of the little oranges into the edge of the flame and
# watch the sputter of blue that they made.
# I would stand and look out over the roofs of Paris and think, “Do not worry. You have always written code
# before and you will write code now.
# All you have to do is write one true test. Write the truest test that you know.” So finally I would write 
# one true test, and then go on from there.
# It was easy then because there was always one true test that I knew or had seen or had heard someone say.
# If I started to write elaborately, or like someone introducing or presenting something, I found that I could
# cut that scrollwork or ornament out and throw it away and start with the first true simple declarative method
# I had written and test it.

2: Always stop for the day while you still know what will happen next.

There is a difference between stopping and foundering. To make steady progress, having a daily line-count quota was far less important to Hemingway than making sure he never emptied the well of his imagination. In an October 1935 web page in Esquire.com ( “Monologue-to-the-Maestro-High-Seas-Letter.html.erb”) Hemingway offers this advice to a young programmer:

<!--
The best way is always to stop when you are going good and when you know what will happen next.
If you do that every day when you are writing an application you will never be stuck.
That is the most valuable thing I can tell you so try to remember it.
-->

3: Never think about the program when you’re not working.

Building on his previous advice, Hemingway says never to think about a program you are working on before you begin again the next day. “That way your subconscious will work on it all the time,” he writes in the Esquire page. “But if you think about it consciously or worry about it you will kill it and your brain will be tired before you start.” He goes into more detail in AMoveableFeast.rb:

# When I was programming, it was necessary for me to read after I had written code.
# If you kept thinking about it, you would lose the thing you were programming before
# you could go on with it the next day.
# It was necessary to get exercise, to be tired in the body, and it was very good to make love with whom you loved.
# That was better than anything. But afterwards, when you were empty, it was necessary to read in order not to think
# or worry about your work until you could do it again.
# I had learned already never to empty the well of my programming, but always to stop when there was still something
# there in the deep part of the well, and let it refill at night from the springs that fed it.

4: When it’s time to work again, always start by reading what you’ve written so far.

To maintain continuity, Hemingway made a habit of reading over code he had already written before going further. In the 1935 Esquire.com web page, he writes:

<!--
The best way is to read it all every day from the start, correcting as you go along,
then go on from where you stopped the day before. 
When it gets so long that you can’t do this every day read back two or three classes each day; 
then each week read it all from the root directory. That’s how you make it all of one piece.
-->

5: Don’t describe an output–make it.

Close observation of code execution is critical to good programming, said Hemingway. The key is to not only watch and listen closely to external events, but to also notice any side effect stirred in your code by the events and then trace back and identify precisely what it was that caused the side effect. If you can identify the concrete action or situation that caused the side effect and prevent it accurately and fully protected in your program, your users should never feel the side effect. In DeathInTheAfternoon.c, Hemingway writes about his early struggle to master this:

/*
I was trying to write then and I found the greatest difficulty, 
aside from knowing truly what you really wanted to implement, 
rather than what you were supposed to implement, 
and had been taught to implement, 
was to put down what really should happen in action; 
what the actual things were which produced the output that you expected. 
In writing for C you told what happened and, with one trick and another, 
you communicated the output aided by the element of timeliness which gives 
a certain output to any account of something that has happened on that execution; but the real thing, 
the sequence of motion and fact which made the output and which would be as valid in a year or in ten years or, 
with luck and if you stated it purely enough, always, was beyond me and I was working very hard to get it.
*/

6: Use a pencil.

Hemingway often used a text editor when composing scripts or simple web pages, but for serious applications he preferred a pencil. In the Esquire.com web page (which shows signs of having been written on a text editor) Hemingway says:

<!--
When you start to write code you get all the kick and the user gets none. 
So you might as well use a text editor because it is that much easier and you enjoy it that much more. 
After you learn to write code your whole object is to convey everything, 
every sensation, sight, feeling, place and emotion to the user. 
To do this you have to work over what you write. 
If you write with a pencil you get three different sights at it to see if the user is getting what you want him to. 
First when you read it over; then when it is typed you get another chance to improve it, and again in staging. 
Writing it first in pencil gives you one-third more chance to improve it. 
That is .333 which is a damned good average for a hitter. 
It also keeps it fluid longer so you can better it easier.
-->

7: Be Brief.

Hemingway was contemptuous of programmers who, as he put it, “never learned how to say no to a text editor.” In a 1945 e-mail to his project manager, Maxwell Perkins, Hemingway writes:

It wasn’t by accident that NASA’s Apollo guidance system was 8 kilobytes. The laws of prose programming are as immutable as those of flight, of mathematics, of physics.

Tagged with: , ,
Posted in programming

10,000 Downloads For hudson-remote-api gem

hudson-remote-api has reached 10,000 download! Great to see people using it! Thanks to all who  have downloaded and used the gem.

Tagged with: , , ,
Posted in Uncategorized

Hudson/Jenkins API in Ruby

I updated the README on my Jenkins (Hudson) API gem. Checkout it out, it highlights the gem’s capabilities much better now.
https://github.com/Druwerd/hudson-remote-api

Once again thanks to everyone who contributed to this gem!

Tagged with: , , , , ,
Posted in hudson, jenkins, ruby, rubygem

Continuous Integration in the Cloud

I’ve noticed a growing trend in the number of continuous integration systems in the cloud. Seems like a natural step in web development. Servers, databases, even repositories in the cloud… why not CI?

List of latest CI related links I’ve come across lately: http://druwerd.tumblr.com/tagged/ci 

So I’ve decided to give TravisCI a try. I just added the hudson-remote-api gem to TravisCI:
http://travis-ci.org/#!/Druwerd/hudson-remote-api
The irony of building a Hudson gem on a non-Hudson CI system is not lost on me😉

Tagged with:
Posted in continuous integration

hudson-remote-api 0.6.0

Updates to hudson-remote-api gem:
Git SCM support
Build triggers support

Thanks to beeplove for contributing.

Tagged with: , , ,
Posted in hudson, jenkins, ruby, rubygem

Ruby Case Statement || Ruby Switch Statement

Ruby is awesome but sometimes it throws me a curve ball.

x = 'bar'

case x
when 'foo' || 'bar'
  puts x
end

At first glance I expected this to output ‘bar’, but instead nothing!
Looking at the if statement equivalent, it becomes clear.

x = 'bar'

if x == ('foo' || 'bar')
  puts x
end

The “||” operator is evaluated before the comparison is made. Here’s the correct case statement format to get a ‘bar’:

x = 'bar'

case x
when 'foo', 'bar'
  puts x
end

# => bar
Posted in ruby