$ brew install fortune
$ brew install cowsay
$ fortune | cowsay
----------------------------------------
/ Retirement means that when someone says
| "Have a nice day", you actually have a |
shot at it. /
-----------------------------------------
^__^
(oo)-------
(__) )/
||----w |
|| ||
You can install an SSH key by executing
ssh-copy-id user@servername.com
Now you can log in to the remote server with your password and ssh-copy-id will do the rest.
Append your public ssh key to the authorized_key file on the server.
As a one-liner:
cat ~/.ssh/id_rsa.pub | ssh user@servername.com 'cat>> ~/.ssh/authorized_keys'
Both commands pretty much do the same. The first way is way easier though.
The next time you can connect to the server using your SSH key.
ssh user@servername.com
Do you know the feeling of copy and pasting the signup-link from this development.log? There’s a better way to do this.
For our development environment, we use MailCatcher.
MailCatcher runs a super simple SMTP server which catches any message sent to it to display in a web interface. Run MailCatcher, set your favorite app to deliver to smtp://127.0.0.1:1025 instead of your default SMTP server, then check out http://127.0.0.1:1080 to see the mail that’s arrived so far.
In this blogpost, I show you how we set it up in our projects.
MailCatcher is a wonderful way to preview all the mails your Rails App sends in the development environment.
Add MailCatcher and Foreman to your Gemfile :
group :development do
gem 'mailcatcher'
gem 'foreman'
end
Run bundle install.
Create a file named Procfile. This is used to start Rails and MailCatcher together with one simple command.
web: rails s
mail: mailcatcher -f
The last step is to configure Rails to send emails to MailCatcher:
Add these 2 lines to your config/environments/development.rb.
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = { address: 'localhost', port: 1025 }
Now you can run foreman start every time you want to start Rails.
This will start Rails and MailCatcher (which listens on port 1080).
Every time Rails sends an email, MailCatcher will receive it and display it on at http://localhost:1080/.
You can toggle between the HTML and the text portion of the email, and even inspect the source.
Good news for you. You can also use MailCatcher without Rails.
gem install mailcatcher1025.mailcatcher.MailCatcher is one of these tools that we end up using whenever we start to send emails in a new project. I hope you like it as well.
At our cooperative (TechGenossen) we used Gmail as our Email-Provider at first. But we found Gmail to be too expensive for our many members.
So, we decided to self-host our emails.
Setting up your email server can be quite hard and involves many moving parts. Fortunately, we found Mail-in-a-Box, a fantastic open-source project, which helps you set up a mail server in no time.
Mail-in-a-Box lets you become your mail service provider in a few easy steps. It’s somewhat like making your own Gmail, but one you control from top to bottom.
Technically, Mail-in-a-Box turns a fresh cloud computer into a working mail server. But you don’t need to be a technology expert to set it up.
Source: mailinabox.email
Mail-in-a-Box features an
It is easy to set up on fresh Ubuntu 14.04. machine.
curl -s https://mailinabox.email/setup.sh | sudo bash
The software will guide you through the installation.
All you have to do is change some DNS-Records and voilà — it works out of the box.
As the admin of the server, you regularly receive emails about how to maintain the box.
I am pleased with the mail server and with the project.
When I started to pair-programm I had absolutely no idea what I was doing. I sat next to another programmer and we started. Occasionally it worked, but more often it was a frustrating experience.
Maybe you are new to pair programming and want to give it a try, or you have trouble getting started. Then this blog post is for you.
I show you how we pair at Gutefrage.net. Some of this advice is really obvious — but much of the other stuff we figured out the hard way through pairing over and over again.
“Lightspring/Shutterstock.com”
Probably your workspace is not suited for 2 people working on it for an extended amount of time. So, before you even begin: Be a good host: Adjust your environment for pairing.
Move away the piles of paper, the dishes, and your backpack under the table. Clean your table. Don’t let the navigator feel like he is just a visitor.
Now move 2 chairs in front of the table. If you do not pair all the time, it is also ok to keep a few spare chairs scattered through the office.
Now take a good look at your screen(s). Can you see them from both perspectives? Is the contrast high enough?
Especially with notebook screens, it can happen that the person sitting next to you will have such a bad contrast that it might be hard for your pair to see what you are doing. If this is the case, get a monitor that both of you can watch.
Place a second mouse/keyboard combo on your desk. It’s nice for the navigator to point to code or be able to write a chunk of pseudocode, and it costs nearly nothing.
Adjust your font size to 16px or 18px. I know this seems ridiculously big, but it will be much nicer for the navigator to look at it. (And also for you, of course)
Now close all your programs. E-Mail clients, IRC, Instant Messenger are of-limits during pairing in my opinion. You will have time for checking this stuff in between the pairing session.
Prepare an editor/IDE that both of you can use. Get an environment ready that works, check out the project, run the tests.
You should know each other’s schedule. I find it frustrating if my pair has to leave in 15 minutes. Better to know in advance.
Now the navigator should grab a notepad and a pencil. Also prepare a timer.
A kitchen timer works fine, alternatively search for “Pomodoro Timer” on Google.
Grab a coffee, go to the restroom, and prepare yourself to focus for the next 25 minutes. Close open loops that might distract you during this time.
At the beginning of each session, the navigator sets the timer to 25 minutes.
Then talk about what you want to do on a high level. Both of you should have a good idea about the scope of the task ahead and what steps are involved.
If the task consists of multiple steps, the navigator should write down a list off these steps.
Pick the best step to start with and write the first test. Try to get the test right, so you both understand what needs to be done.
TDD is especially effective with pairing, it communicates what you want to do, and it will focus both of you on the next step.
Now the driver’s responsibility is to implement the code. Explain what you are doing along the way. Do not concentrate that much on the big picture, but try to get the task at hand done. Trust your navigator to keep the larger picture in sight.
Whenever there are alternatives ways to do it, and you are not sure — ask your navigator what to do.
Let the navigator guide you through the list of tasks. Ask him how to proceed if you are unsure.
Ensure that you work on the tasks on the list.
If you discover additional tasks — it often does make sense to postpone them and focus back on the problem at hand. It’s your responsibility that both of you don’t forget them — so write them down.
Keep engaged with the driver and try to understand what the driver does.
When you notice that the Driver get’s stuck, unstuck him. Even if you don’t know the answer to the problem at hand — ask him a question.
Point out typos or problems if the driver does not see them himself. Is the code understandable? Are the variable names ok? Is the class getting to bloated? Do an on-the-fly code review. Mention problems. But do not micromanage, of course. — Just like in a normal code review.
Pull the driver out of the implementation if you have the feeling that you should change the angle. Discuss it with him.
“pio3/shutterstock.com”
You should communicate all the time! In a good pairing session, it really feels like you are working on this in unison. As the driver you can focus on getting the tests passed and as the navigator you can keep the pair going in the right direction, ensuring an excellent quality.
Communicating right is maybe the hardest part for most programmers — just keep doing it. It’s a skill that you can acquire and if the pair is really attuned to each other after many sessions this will feel like second nature to you.
Concentrate on the task at hand for 25 minutes. Do not watch your emails, do not take breaks, try to stay engaged. It is expensive for 2 programmers to become distracted.
Work step by step from your list. After you have finished a step, take it off the list and start working on the next step.
Don’t argue too much. This is not an ego game — if both of your solutions are equivalent, just decide and keep going ;)
The session ends after 25 minutes. Take a break of at least 5 minutes. This is the time to grab a coffee, to visit the restroom, check your mails and take a break.
Good pairing is intensive. You will need the break, especially if you want to work for a few hours in a pair.
After each pairing session, switch roles. We solve this with a WIP commit to the feature branch, then we change workstations.
After the break is over, start another pairing session if needed.
Getting started with pairing is no easy feat. Don’t get discouraged. It is worth to learn it.
In a future blog post, I will describe the many problems that you might encounter during pairing and how to tackle them.
I hope after reading this little primer you get the idea how this could work and be sustainable. Since this are not best practices by any means, feel free to implement pairing your own way.
If you have experience pairing or tried this out: What are your thoughts about this? How do you pair?
Castle 11 from Bill Ward’s Brickpile. (CC BY 2.0)
Since quite a while, I try to find a good solution for sharing my dotfiles between my different computers.
I started with chef — Unfortunately, this did not work so well. Especially if you also want to use your dotfiles on a server. Also, it felt a little complicated.
The next approach I took was putting my dotfiles into my Dropbox and symlink them. This worked ok. But Dropbox on a server? No way.
So, I kept looking. A few days ago, I stumbled over
homesick — an astonishing rubygem that manages your dotfiles.
First install homesick:
gem install homesick
Now create a “castle”. A castle is a collection of dotfiles.
homesick generate ~/dotfiles
This creates a git repro with a /home folder inside. Just put your dotfiles / dotfolders in there. Then push the stuff to GitHub.
Now install the castle with homesick.
homesick clone https://github.com/foo/dotfiles.git
Now let homesick do its magic.
homesick symlink dotfiles
All the dotfiles from within this castle will be symlinked.
Please do not put sensitive information into you dotfiles.
Especially ssh keys, bash histories and passwords in configuration
files do not belong on GitHub.
Seriously. It’s magical. This is one of those things that you try out, and you ask yourself how you could possibly live without it.
Interested? Have a look at my dotfiles.
From time to time, I really want to make it hard for me to seek for distractions.
I found myself using the nice Mac OS X tool Freedom all the time. Freedom disables the network connectivity, which means no Twitter, Facebook etc.
But when I revisited the site, I found that the author now charges $10 for it - That’s just a little too expensive in my opinion.
So, I went out, and it took me 5 minutes to come up with freedom.sh.
# !/bin/bash
echo "Enough of this filthy internet" | cowsay -s
sudo route -n delete default &> /dev/null
Cowsay required. (If you prefer not to install cowsay just remove the line!)
________________________________
< Enough of this filthy internet >
--------------------------------
^__^
(**)_______
(__) )/
U ||----w |
|| ||
To reenable your internet, you have to add back the default route or restart your computer.
Little update (18.09.21): I do use Freedom now. It got even more expensive - but it syncs between all my devices and changed from a internet kill-switch to something even more useful. I found it great to disable news sites and other addictive sites during corona.
Last week, my colleagues at Gutefrage.net, and I had our second
Coding Dojo.
I learned an important lesson — even though this wasn’t the first time I practiced the kata.
The task was to create a class that decomposes natural numbers into its prime factors.
Additionally, the factors should be sorted ascending.
Examples:
1 => \[] # Since 1 is no prime ;)
5 => \[5]
10 => \[2,5]
75 => \[3,5,5]
You get the idea ;)
This sounds simple and like a perfect candidate for an
Introduction to TDD, right?
Unfortunately, this kata is a bit tricky.
The first tests are straightforward:
module PrimeFactorDecomposer
def decompose(number)
if number < 4
number
else
[2,2]
end
end
end
describe PrimeFactorDecomposer do
include PrimeFactorDecomposer
it "returns no prime factors for 1" do
decompose(1).should be_empty
end
it "decomposes 2 into 2" do
decompose(2).should be == [2]
end
it "decomposes 3 into 3" do
decompose(3).should be == [3]
end
it "decomposes 4 into 2,2" do
decompose(4).should be == [2,2]
end
end
Now decomposing 5 would be a nice test? Right? Since 5 is a prime, it would only return 5. But how can we find out if it’s a prime?
So, we could write a function that finds out if 5 is prime. Hm, that seems hard.
What about 6? But then we have to develop an algorithm that works — otherwise, we would just move sidewards and add conditionals.
You do not know how to solve the problem. Not everything is as simple as the FizzBuzz Kata.
Adding another test alone does not suffice. It’s a common hurdle for newcomers to TDD.
Grab a sheet of paper and think about the algorithm. Or do a little spike until you fully understand the problem. Every so often it’s just not true, that a design “magically” emerges.
You need sound knowledge about where to go — otherwise you will have problems with TDD along the way. Then you have to lean back and think a little or get feedback from something else than your tests.
TDD is cool, but it cannot solve every problem. Especially not complicated algorithms (this is a straightforward one, of course).
Another personal learning for me was to watch myself better, when I do a kata the first time.
When the design does not emerge from the tests — I should listen to them. Maybe they want to tell me that I have absolutely no idea what I am doing and that I need to think more…