Archive for July, 2017

My Morning Ritual

I’ve introduced morning rituals in my life a long time ago. These rituals change over time, based on whatever’s going on in my life, as well as what constraints I have, what resources, etc.

Currently, here’s what my morning ritual looks like (starting after hitting the snooze button a few times – a bad habbit I need to break! – and going to the bathroom):

  1. Stretch: I stretch my body, mostly using a foam roller like this one, to roll my legs and back and get things back into place;
  2. Water: After so many hours without drinking or eating anything, I like drinking about a glass of water so that my body can flush its system; 🙂
  3. Protein shake: I don’t feel like having a large breakfast in the morning, so I at least try to get some protein, which will help me not feel hungry way before lunch time;
  4. Meditate: I’ve blogged about how meditation is paying off. I’ve been meditating for 15 minutes for several months. I’m thinking about going up to 20 minutes soon. 
  5. Journaling: For many years I’ve been writing down things I’m grateful for. For the last several months I’ve been using the 5-Minute Journal, which just adds a little more structure to it;
  6. Watch to short inspirational video or listen to song that gets me going:  I may either watch a video off the QuickTalk YouTube playlist Short, or listen to a song off my Morning Songs playlist;
  7. Organize my day: I first review things that I know are going on that day and then set up my Daily Execution note, which drives my day;
    8. Quick email scan: this happens real quick! I barely skim over email subjects, specifically looking for anything that could somehow mess up with my plans for the day (set in #7). For instance, maybe a meeting got cancelled last minute, or something urgent has come up and I must include in my agenda for the day. 
  8. Go to work!

Seriously, I do NOT read emails in the morning. I ONLY go through subjects and see if there’s anything that could change my agenda for the day. I’ll only spend more time checking email once my main activies have been put in motion at work.

Also, I do NOT check any social network in the morning.

Important: I set my cellphone to “flight mode” when I go to bed, and I only set it back when doing step #8 above; that way, I don’t hear and dings for new messages in the middle of the night, and I don’t take the risk of seeing updates on my cell phone when I pick it up to run my meditation app, so I don’t get any interruption.

I’d like to add workout to my morning ritual, but I haven’t found a way to make that work with my current constraints. Anyway, as it is now, my morning ritual is helping me get ready for the day and get a sense of being productive since early in the morning.

Leave a comment

Why the Dark Background?

Once in a while I hear comments like “so, you’re one of those who like everything dark…”, as people look at how some environments are set on my computers. Those comments make me think about my reasoning behind that choice.

Of course, some people choose to go dark just to go with the flow (“That’s what the cool kids are doing…”). That’s not my case.

I’m getting old. This is what my screen used to look like when I started working with computers some 25 years ago:

The software I wrote used to look like this:

At some point, things started to light up and MS Windows brought white background to everything. As I worked with MS Visual FoxPro, and then Visual Studio, as far as I remember, white background was all we could use, so I got used to it, but I always felt it a little “too much” on the eyes.

Once Visual Studio allowed me to switch to a dark color scheme, I embraced it, and that’s how I’ve had it set for a long time:

I do the same thing with Gmail and any other tool that allows me to:

What about the other tools that don’t let me go dark? I don’t care, I just use them regardless. The important thing is that the tool where I spent most of my time is set to my liking.

And why do I prefer it dark? I do because it looks calmer as I read through the text.

Leave a comment

The Death of MS Paint and Producing Good Results

.I heard the other day that MS Paint is getting killed off, so I felt I needed to pay my tribute to it.

Before becoming MS Paint, that tool used to call Paintbrush.

Back in high school, my class was using Windows 3.1, and we were given a special homework assignment: drawing something (anything) in Paintbrush. I decided to try drawing this cover artwork of a Batman comic book (which was probably the current issue at the time). This is the original cover:

I spent about 4 hours on a Sunday afternoon and was satisfied with the result. When I showed it to the class, a lot of people thought I had cheated and scanned the cover. The professor trusted me from previous works I had turned in, but still, he told the class he’d know if I had cheated when he analyzed the digital BMP file. He was very impressed by this work, even more so considering I had used just a regular mouse to draw the thing.

Unfortunately, I’ve long lost the original file. Many years ago I found an old copy produced by an old dot-matrix printer, which I then scanned (ironic, I know!) and kept around. That’s what you see below:

Not bad, is it? I really hoped I had the original file, which definitely looked better than the scanned dot-matrix printed version.

Moral of the story: most of the time, we do NOT need fancy tools to achieve great results!

Leave a comment

What and How Much Do I See on the Screen?

It seems like there’s a recurring topic going on here: I’m very picky about how much stuff (and what stuff exactly) I see in my work area! (See list of posts related to that down below).

Several years ago I was trying out different DAW software (Digital Audio Workstation) to record my music. I’ve tried at least half a dozen of them. I’m NOT a recording engineer; all I wanted was something where I could press a big red button so I could start play my instruments and have it recorded.

Most DAWs I found failed that simple requirement as I was presented with extremelly convoluted user interfaces in which I simply could not figure out how I could plug my guitar and start recording it. I’m both a software developer and a musician, and still, I couldn’t figure out how to do this one simple thing!!

Such user interfaces made me feel stupid and I want to deal with them. I eventually found this one DAW that satisfied my needs as a hobbyist musician.

Simplicity is key for productivity, and that applies to setting up the development tools we work with, as well as the code we write. Polluted tools get in the way of reading code. Convoluted code gets in the way of understanding what it does.

Clean up your development environtment! Clean up your code! Clean it up!! 🙂

Some of my posts related to my take on optimizing what I see on my screen as a developer:

Leave a comment

Writing code is cheap. Understanding it, not so much.

Writing code is really cheap! There are three ways to do it, and you can use them all:

  1. Use a code generator (CodeSmith, T4, or your own);
  2. Use a micro code generator (templates in VS, Resharper, CodeRush,…);
  3. Take a touch typing course and get good at it!

Then comes the time we need to change the code. That’s the hard part, right? Well, not necessarily; there are tools that can help with that, too. If the change you need to make is to refactor the code, there are tools that do a wonderful job at that. The problem is understanding the code well enough so we can change it!

We spend little time writing code. We spend a LOT of time reading it. Doing things that can help us understand the code later on down the road is a must. Writing good tests is one of those things. Writing clean code is another.

The quicker you understand the code you’re facing, the more confident you’ll be making the right changes to it.

Code must be written with care. So must be tests. Tests provide a big help in understanding why certain code exists. Tests must be written in a way that they’re easy to understand.

When writing test setups (like setting up mocks and stubs, for examples), consider putting that logic behind a method that explains the intent behind that setup. This will help the reader quickly understand what’s going on, and it’s easy enough to jump into the details when appropriate.

The same goes for production code: consider putting expressions used in an if-block behind a method that describes the question being asked. In other words, instead of writing if (user.Age >= 13 || user.Age <= 19) {}, consider writing if (user.IsTeenager()) {}.

Leave a comment

What is the Difference Between TDD and BDD?

This is a question asked many times: What is the difference between Test-Driven Development (TDD) and Behavior-Driven Development (BDD).

In my mind, I’ve accepted the following explanation:

Doing TDD, I write the code I want to have;
Doing BDD: I describe the behavior I need to have

I use both approches together: I start writing my tests in terms of GWT (Given-When-Then), describing
the behavior I need to have, and as I implement those individual steps I write the code I want to have.

This is the simplified explanation that works in my own mind, and it has taken many years for it to take that shape. It may not work to others, but I’m sticking with it for the time being, at least until I find a better way to explain it.

I sense there’ll be more posts coming up expending on this subject. 🙂

Leave a comment

No GWT? No code!

As I mentioned in my post on Test Style: AAA or GWT, I’ve deliberately started thinking of everything in terms of GWT (Given-When-Then). So, when I’m beginning to write a new test, instead of writing this:

// Arrange
// Act
// Assert

I write this:

// Given
// When
// Then

Regardless of the style, though, if I can’t think of what should go in each one of those sections, I may have one of two problems:

  • I don’t have enough requirements, or
  • I don’t understand the requirements I have

I’ve gotten into the habit of thinking this way: No GWT, no code!

The reason for that is: if I either don’t have enough requirements or don’t understand the ones I have to a point where I can’t fill out my GWT sections, then I should NOT be writing any code. Whatever code I write is very likely to be thrown away, and unless I have a lot time in my hands to be simply toying with writing code, I should refuse to write any code and go find help to have a clear idea about what I’m supposed to implement.

Leave a comment

Test style: AAA or GWT?

Many years ago, after really getting into writing tests, I fell into the same trap newcomers do: my test code was very messy! Eventually, I heard of the AAA-style of organizing test code. AAA stands for Arrange-Act-Assert. There are several posts out there that show it. Here’s a link to one, in case you don’t know what this is all about.

After years of following that format, I learned about BDD (Behavior-Driven Development), and that’s where I learned about GWT (Given-When-Then).

Several years ago, I stopped thinking about AAA when writing any kind of test and got convinced that I should always think in terms of GWT. Why? Because AAA is too technical, while GWT works well both for technical people as well as for business or QA folks. Now, why’s that important?

For me, when I want to get feedback by having my code reviewed, if I stick with the GWT mindset, I can get pretty much anybody involved with the project to help me review my code. That means I can easily work with another developer, business analyst, or QA guy.

So, when I’m about to write tests, instead of thinking how I’m going to…

  • Arrange my test, I think what I’m Given
  • Act in my test, I think When something happens…
  • Assert the results, I think if that something happens Then this is what I expect as the outcome.

In both styles, the structure of the test is pretty much the same. However, this shift in how I approach coding makes me think more from a business-oriented point of view, and this mindset opens up possibilities regarding the number of people I can collaborate with in order to build a better product.

Leave a comment

Toggling Visual Studio CodeLens On/Off

As I’ve mentioned before (here, here, and here, at least), I’m very specific as to how much stuff I want to see on my screen as I’m working with code. Visual Studio can be very cluttered depending on how we set it up; so much so that sometimes I feel like just open my cs files in Notepad!

One of the things I think get in my way is the feature CodeLens in VS. While it does provide good information and access to useful things, I hate it being on my face all the time! I rather it only show me the goodies when I need it.

Gladly, I found information on this link that shows how I can create a shortcut to toggle CodeLens on and off (I’ve also found out about the Visual Commander extension, which I hadn’t seen before).

One thing in that post that wasn’t clear is the name of the command I need to bind the shortcut to. I thought it’d be the name of the command I created in Visual Commander, but that wasn’t the case. Editing the command in Visual Commander, I noticed Command01 right before the name I gave to the command:

And that’s what I needed to look for in the Keyboard dialog in VS:

I’ve bound the command to the Shift+Alt+CL shortcut (for CodeLens).

Now, if I toggle the feature On, I see all of the extra stuff it shows me:

Otherwise, I get to focus only on the code (which is what I want 98% of the time!):

The less stuff there is mingled in the code, the easier it is for me to read and understand it.


SpecFlow: My preference for the step definition style

When using SpecFlow’s dialog to generate step definition skeletons, the default style is “Regular expressions in attributes”:

That produces results like this:

That looks very messy to me. The regular expression text can be read easily, but then the PascalCase method underneath looks like it is too much. I see redudant code. I see dead code. 🙂

I personally like the “Method name – underscores” style better:

That looks a lot cleaner to me. Yes, I am a little biased after having spent several years in Ruby-land, but hey, I had adopted this style in C# before that. While this is not a common format for method names in C#, I don’t really care, as nobody should be calling this methods in the common way anyway, so I rather follow a style that makes the code read better, without junk around that doesn’t add anything to my understanding of the code.

Note: by the way, I do rename those p0 and P0 references!!