rocu.de
About me Archive Replies Imprint Privacy Also on Micro.blog
  • fortune | cowsay

    $ 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 |
                    ||     ||
    
    → 7:51 AM, Sep 4
  • How to install your SSH key on a remote server

    1. Nice way

    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.

    2. Manual way

    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' 
    

    Conclusion

    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    
    
    → 7:00 PM, Oct 26
  • Rails: Preview your emails with MailCatcher

    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.

    Installation

    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).

    Using MailCatcher

    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.

    And what if I do not use Rails?

    Good news for you. You can also use MailCatcher without Rails.

    1. Just install MailCatcher via gem install mailcatcher
    2. Point your application to send mails via SMTP to port 1025.
    3. Run mailcatcher.
    4. Go to http://localhost:1080/.

    Conclusion

    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.

    → 8:00 PM, Oct 22
  • Host your emails with Mail-in-a-Box

    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

    • IMAP-Server
    • An easy to use Control-Panel
    • Nextcloud for contacts
    • Roundcube for webmail

    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.

    → 8:00 AM, Oct 22
  • A short primer on Pair Programming

    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”

    Preparations for your first pairing session

    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.

    Physical preparation of your workspace

    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.

    Prepare your hardware

    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.

    Prepare your computer

    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.

    Talk to your partner

    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.

    Grab Essential tools

    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.

    Immediately before every session

    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.

    The first pairing session

    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.

    Write a test first

    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.

    Driver

    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.

    Navigator

    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.

    Talk, talk, talk!

    “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.

    General behavior

    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 ;)

    After the session

    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.

    Conclusion

    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?

    → 10:00 AM, May 26
  • How to manage and share your dotfiles using homesick

    Castle 11 from ‘Bill Ward’s Brickpile’. (CC BY 2.0)

    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.

    How to set it up

    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.

    This is wonderful!

    • You feel at home at each of your servers in no time
    • You share your dotfiles with the world
    • You can learn from others and refine your files
    • You can put essential little scripts into a .bin directory.
    • The castle concept allows you to try someone else’s dotfiles

    A word of caution

    Please do not put sensitive information into you dotfiles.
    Especially ssh keys, bash histories and passwords in configuration
    files do not belong on GitHub.

    Try it!

    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.

    → 11:00 AM, Jan 22
  • Script to disable internet connectivity for Mac OS X

    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.

    → 9:00 AM, Sep 30
  • Lessons from the prime factorization dojo

    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 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.

    Performing the kata

    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 the trouble begins

    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.

    What’s the problem?

    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.

    How to solve this?

    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.

    Learnings

    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…

    → 6:22 PM, Sep 29
  • RSS
  • JSON Feed
  • Surprise me!