Springest Developer Blog

Vacancy: senior frontend developer in Amsterdam

Wed, 18 Oct 2017 00:00:00 +0000

We want Springest to become the largest source for learning in the world. From books and e-learning courses to on-site trainings, we help our users discover, compare, and book everything they need to reach their personal and professional learning goals.

We have a strong product focus in which everything revolves around the users of our Dutch, German, Belgian, UK, and US sites. Next to that, more and more organisations are using our SaaS tools to stimulate and manage learning for their employees.

Working at Springest

We are looking for a senior Frontend Developer to join our growing engineering team. We don’t have managers at Springest, but processes, and we feel that individuals taking responsibility is very important. At Springest, you will work in close collaboration with product owners, marketing, and sales colleagues. You are also a member of our development team where we discuss architecture, infrastructure, and keep a close watch on security and performance.

Our main application runs on Ruby on Rails backed by Postgres, Redis and Memcached. Next to that we rely on Elasticsearch to power our search which is a big part of our product. We also have some smaller Go and Elixir projects in production.

We are hosted on AWS and make heavy use of their offerings like RDS, CloudWatch, Elastic Beanstalk and EC2 Container Service.

For our frontend stack, we work with Slim, Sass & CoffeeScript. Some libraries we use are jQuery, Bourbon/Neat and Backbone (but mainly we care about using the right tool for the job!).

In our product development flow we often use tools like Balsamiq and Sketch for designing features. As a Frontend Developer, both your creative & technical input can help to refine the output.

Next to our main application we build internal tools whenever necessary to help ourselves and our growing Learning Advisor team. It is extremely rewarding to see small development projects make a big impact for other Springeteers, which in turn can result in more of our visitors being helped of course!

We also do a regular internal hackday where we drop everything and work on something completely different. We might give a new programming language a shot, try out an idea someone’s been toying with for a while or hack on some actual hardware. A lot of hackday ideas actually became super important for our business. Check this recap of a recent hackday to read more about why we organise them.

Your New Colleagues

At Springest you will work with around 50 colleagues (that’s not all of us and no we’re not always in full cowboy gear, this was our Western themed SpringFest!) who all are very skilled at what they do and all of them have a healthy dose of nerd skills that we really value. Our Product Owners also regularly ship code!

Springeteers are a happy bunch and we often get together outside work to enjoy free time as well. Our office is a cosy place where anything goes and where we all take good care of together. If you’re not good at ping-pong yet, you have a good chance of becoming good here as well! 🏓.

We are all active organisers and members of Meetups and other forms of knowledge exchange (learning is our hobby!) and we participate quite actively in the Amsterdam startup ecosystem. In addition to that we get a lot of attention for Springest being the poster boy of how Holacracy and GTD can work for an organisation, which in turn is due to our organisational structure without managers and other unnecessary overhead.

Some of your challenges

helping to finish implementing our redesign (example before-after)
helping to craft the user experience for our big but inspiring challenge: building the ultimate product for 21st century Learning. We’re currently one of the best-known platforms where people book their classroom and e-learning courses. But in our quickly-evolving society, people continuously supplement their learning profile with personal & social learning experiences. Because you learn every day: from articles, books, meetings & inspiring conversations. For this, we need the best possible backend + frontend + AI force we can gather. We’re well on our way, but we can’t wait to strengthen our team with extra frontend power.
bringing our internal styleguides to the next level to help the whole Product Development team of full-stackers become full-stackier

What we expect from you

You work well in a team, and want to make the team greater than a sum of its parts.
Engagement in what it is that you are building and who you are building it for. We want you to feel involved and come up with ways to make Springest better.
The drive to improve yourself and our organisation and deliver high quality work.
You have a broad interest and deep knowledge. We are all about learning and sharing knowledge.

What You Get From Us

Apart from Springest being the coolest company you will ever work for, there are a few extras:

We are very remote friendly.
At least a € 1,000 education budget per year to spend on training, courses, and conferences.
Stock options after 2 years.
A cool workplace in the center of Amsterdam with height adjustable desks that you can sit and stand at, table tennis, a massage chair, and balcony with a barbecue.
A Macbook.
All software and hardware you need to do your job and have an optimal workflow.

Contact Rik Matena (rik@springest.com) for questions and applications. Please include links to your Github and LinkedIn profiles.

Checkout these links to get to know more about us:

Hubot: Get notified in Slack on merge conflicts

Mon, 21 Aug 2017 00:00:00 +0000

This is the final out of three posts where I will explain how to hook up Hubot to Github’s API. The goal of these posts is to get notified in Slack when your pull request becomes unmergeable.

Read “Hubot: get it running locally in Slack” and “Hubot: listen to Github’s pull request events” to get up to speed and get the code that this post builds upon.

Connect to Github’s API to check the merge status of a pull request

Is your pull request event set up and your bot listening to your webhook? Great! Let’s do something with that data.

Here you can find an example of the data you’ll receive on pull request events. As you can see there’s a mergeable key. This is either null, true, or false. You want to send a notification to Slack when the value is false.

Hubot has built-in event listener methods: emit and on. With these methods, you can create your own event that Hubot will listen to. You define an event with emit and you listen to it with on.

You can use these methods to handle errors. Wrap your data assignment in a try/catch block and create an error event if there is one:

  robot.router.post '/hubot/github/:room', (req, res) ->
    room = req.params.room

    try
      data = req.body
    catch error
      robot.emit 'error', error

Then somewhere in your script you can add:

  robot.on 'error', (error) ->
    #process the error

Now that you have that sorted, you can set the values you need to work with. In this case: the Slack room name to post in and the pull request url, id and status. Add the following above the catch error line:

  pull_request =
    {
      room: room,
      url: data.pull_request.url
      pullId: data.pull_request.number
      pullState: data.pull_request.state
    }

The room is needed for the Slack notification. The url and number are needed for the GET request you’ll send to Github’s API in order to check the pull request’s merge status. The pull request’s state is needed to filter events on pull requests that are not open. Let’s do that first, because there’s no point in checking for a possible merge conflict in closed ones.

  if (pull_request.pullState == 'open' || pull_request.pullState == 'reopened')
    # do stuff

Tip: throw a console.log() in your code to see what data you have available and know what you’re working with.

When someone pushes to a branch that has a pull request, the payload is sent immediately. The result is that the initial value of mergeable in the data object is unknown. The main reason is that it takes a few seconds until the merge status is known because the code has to be compared to the master branch. In order to know if the pull request has a merge conflict, therefore unable to merge with the master branch, you have to check its merge status via the Github API.

You can use Hubot’s http call methods, that enable you to send GET requests. In this case to the Github API. Let’s create a method that takes care of this and add it at the top in github.coffee , above the export function:

  getRequest = (robot, data, callback) ->
    url = "#{url}/YourRepoName/#{data.repository}/pulls/#{data.pullId}?access_token=#{token}"

    robot.http(url)
      .headers('Accept': 'application/rubyon')
      .get() (err, res, body) ->
        callback(err, res, body)

  module.exports = (robot) ->

The method accepts 3 arguments: the robot instance, data and a callback function.

Notice that the url variable uses data.repository and data.pullId. These come from the pull_request object that you pass as the data argument. There’s also an access_token variable at the end. This is needed in case of a private repository. You can set one here. If your repo is public, you do not have to include the token in the url. What follows is the GET request to that url.

Create another method underneath called checkMergeStatus:

  checkMergeStatus = (robot, data) ->
    getRequest robot, data, (err, res, body) ->
      try
        response = JSON.parse body
        mergeStatus = response.mergeable
      catch error
        robot.emit 'error', error

This method uses your getRequest method and stores the mergeable value. Now, if mergeStatus is false, you want to send a notification to your Slack channel. If it is true you do not have to do anything. If it is still unknown, you want to re-check. Add the following to the checkMergeStatus method, inside the try block:

  if (mergeStatus == false)
    # send notification
  else if (mergeStatus == 'unknown')
    setTimeout ->
      checkMergeStatus(robot, data)
    , 1000
  else
    # do something?

As you can see, if the second condition evaluates to true, the checkMergeStatus will keep calling itself with 1000ms (1sec) intervals, until it changes.

Send a notification to your Slack channel on a merge conflict

Here’s where the previously mentioned emit method comes in handy again. You can create a merge_conflict event for when the status is false. Make sure it has the values you need in your Slack notification:

  if (mergeStatus == false)
    robot.emit 'merge_conflict', {
      room: data.room,
      pullTitle: response.title,
      author: response.user.login,
      pullUrl: response.html_url,
      pullId: response.number
    }

All that you have to do now, is to get Hubot to take action as soon as the merge_conflict event happens. You can let Hubot ‘listen’ to it by using the on method. I moved the code for this to a separate script called merge_conflict_notifier.coffee in the scripts folder:

  module.exports = (robot) ->

    robot.on 'merge_conflict', (merge_conflict) ->
      room_id = robot.adapter.client.rtm.dataStore.getChannelByName(merge_conflict.room).id
      message =
        {
          "text": ":no_entry_sign: Merge conflict: <#{merge_conflict.pullUrl}|##{merge_conflict.number} #{merge_conflict.pullTitle}> by #{merge_conflict.author}"
        }

      robot.messageRoom room_id, message

In order to post a message to a room via Slack’s API, you need to have the room’s id. robot.adapter.client.rtm.dataStore.getChannelByName(<your room name>).id will get that for you.

The message is formatted according to Slack’s requirements. More information about message formatting can be found on their website.

Keeping track

But what happens if someone is going to commit several fixes to their branch but the merge conflict does not get resolved right away? You do not want to spam your Slack channel because that is super annoying. Therefore it would be a good idea to keep a list of the pull requests that have a merge conflict and remove them if they are resolved.

At the top of the github.coffee, add an empty array called unmergeablePulls. Now you can add some code to keep track of them. Add the following above the checkMergeStatus method:

  unmergeablePulls = []

  addPullIdToList = (pullId) ->
    return false if pullId in unmergeablePulls

    unmergeablePulls.push pullId
    return true

  removePullIdFromList = (pullId) ->
    return if pullId == null

    indexOfPullId = unmergeablePulls.indexOf(pullId)
    unmergeablePulls.splice(indexOfPullId, pullId)

Now you can use these methods in the if/else block within the checkMergeStatus method and add the id of the pull request when there’s a merge conflict. When the id has already been added, the notification is skipped. When there is no longer a merge conflict, the id is removed from the list:

  if (mergeStatus == false)
    if addPullIdToList(robot, data.pullId)
      robot.emit 'merge_conflict', {
        room: data.room,
        pullTitle: response.title,
        author: response.user.login,
        pullUrl: response.html_url,
        pullId: response.number
      }
  else if (mergeStatus == 'unknown')
    setTimeout ->
      checkMergeStatus(robot, data)
    , 1000
  else
    removePullIdFromList(data.pullId)

Hubot has a robot.brain method that lets you store key-values to Redis. This could also be used to keep track of the id’s, but for now this is how I made it work.

You can deploy your Hubot to Heroku. Hubot provides documentation on how to do that.

I hope these 3 posts have helped you get an idea of how Hubot works, the advantages of a chatbot in general and how it can enhance your productivity/workflow.

Happy hacking :)

Efficient and effective working: a Product Tank meetup with special guest David Allen

Fri, 23 Jun 2017 00:00:00 +0000

We were proud to host the ProductTank AMS June 22nd meetup about efficient and effective working at Springest.

As a product-y person, you are usually required to communicate often and with many people. How do you make sure you still have time for “deep work”?

None other than David Allen, creator of the Getting Things Done Time Management method, opened the evening. He made an entertaining plea for you to not attempt to store all your new ideas in your brain. That thing is already busy enough dealing with the 50.000 conscious and subconscious decisions you make each day. “Your mind is a crappy office.” Tough to argue with.

David also gave the crowd a sense of how his company has been running on Holacracy –an operating system for organizations– for the past 6 years.

This served as a nice bridge to Jaap-Willem Mol from VergaderVerkalking (“if you’re not Dutch and you manage to pronounce that, I’ll buy you a beer”). Jaap-Willem talked about the three basic principles that lie central to effective meetings: rules, roles and feedback. He had a good tip: find inspiration for more effective meetings in the Holacracy Tactical & Governance meeting at Springest video produced by VergaderVerkalking.

Dennis Paagman, Product Owner & Developer at Springest, closed the round of presentations. He showed how GTD & Holacracy help us be productive and aligned on our goals, from the whole company down to each circle and individual role. Some concrete examples included quick peeks at our publicly visible & continuously evolving Holacratic structure at roles.springest.com, and an example of our actual current OKRs (Objectives and Key Results).

ProductTank organizer Iris van de Kieft closed the event by hosting a nice panel session with the three speakers and an engaged audience.

Thanks to the audience, the speakers and ProductTank. We love hosting meetups at our Springest HQ (with a view over the IJ river!). For example, we’re actively involved in the Amsterdam & Netherlands communities for Product, Holacracy and Ruby. So, reach out to Dennis if you’re interested! We’re also hiring backend/frontend/full-stack developers, spread the word!

Photo’s taken by Mark Mulder, Developer at Springest.

Hubot: listen to Github's pull request events

Wed, 29 Mar 2017 00:00:00 +0000

This is the second out of three posts where I will explain how to hook up Hubot to Github’s API. The goal of these posts is to get notified in Slack when your pull request becomes unmergeable.

If you have never worked with Hubot in Slack before, read the first post: “Hubot: get it running locally in Slack”

Github’s API

Github offers an extensive API to connect to your repositories and automate your daily development workflow. Their documentation is very detailed and extensive and they have excellent guides to help you get started. For the goal of this post, I’ll focus on Pull Request events.

Enable Github’s Pull Request events

As said above, the goal of this project is to get notified in Slack when a merge-conflict occurs. Luckily, Github supports webhooks. That means you can get them to notify you whenever an event, like a push or a commit, happens, which in turn enables you to check the status of your pull request. Read more about all the events at https://developer.github.com/webhooks/

Send events to a webhook.

When an event happens on a pull request, Github gathers all relevant data and sends that event (a payload) to the URL of your choosing. This is called a webhook.

To set this up, go to the settings page of your repository. Select Webhooks. Then click the add webhook button. You have to provide a so called payload URL which is the webhook URL. Since you are running everything locally, you do not yet have a public URL.

Set up ngrok

Ngrok is a tool that enables you to expose your local webserver to the internet. Download it here. Unzip it from your bot’s directory. This will install a small executable in your bot’s root directory:

  $ unzip /path/to/ngrok.zip

Run it on port 8080, which is Hubot’s default port:

  $ ./ngrok http 8080

You should see something like this:

  ngrok by @inconshreveable

  Tunnel Status                 online
  Version                       2.1.3
  Region                        United States (us)
  Web Interface                 http://127.0.0.1:4040
  Forwarding                    http://a3b9e4e6.ngrok.io -> localhost:8080
  Forwarding                    https://a3b9e4e6.ngrok.io -> localhost:8080

  Connections                   ttl     opn     rt1     rt5     p50     p90
                                0       0       0.00    0.00    0.00    0.00

You can use the http:// URL for now, you can open that in your browser to see a nifty web interface.

Set up the webhook.

Copy and paste the entire URL, ending with .io into the Payload URL field of the form. Append /hubot/github/general to the URL. The /hubot part is important because it is a requirement. The next part, in this example /github, can be anything you like and /general is the room’s name in Slack (which you are free to change as well).

Make sure the content type is set to application/json and skip the secret field for now. The secret is used to protect your endpoint so we know that messages are coming from Github, but for brevity we’ll leave this up to you, the reader.

Select Let me select individual events. In this case you only want to receive pull request events. Click Add webhook.

Note: Every time you restart ngrok, you’ll get a new URL. Make sure to update it in your Github repo settings.

Test the webhook.

You will see a list of recent payload deliveries underneath your webhook form right after you save it. There is also a red error mark next to the first delivery.

Now check ngrok in your console. You should see this:

  HTTP Requests
  -------------

  POST /                         404 Not Found

This means 2 things:

The request was received by your local server. Yay!
The endpoint it’s routed to, doesn’t exist yet.

Note: If you do not have your bot running, you’ll see a 502 Bad Gateway error.

Make Hubot listen to the webhook

In order to get rid of the 404 error, you have to setup an endpoint in your bot that will execute your code when a payload is received. In your favorite editor (I use Vim), create a new coffeescript file called github.coffee inside your bot’s scripts directory.

First things first, export a function:

  module.exports = (robot) ->

This is a requirement and part of the anatomy of a Hubot script. The robot parameter is an instance of your bot.

Create the endpoint:

  robot.router.post '/hubot/github/:room', (req, res) ->
    room = req.params.room
    data = req.body

    console.log("== Pull request data received: #{data.pull_request.number}")

robot.router is a built-in Hubot method. By adding .post you create a route for POST requests. Naturally, if you want to create a route for GET request, you simply call .get .

The string '/hubot/github/:room' is the webhook URL you set up in your Github repo, where :room is a variable you have to define. The callback, (req, res) is called when a POST request comes in. Save the room name and the JSON object that contains all data in 2 variables: room and data. Then, to check that it works, the pull request’s number is printed out and will show up in your terminal.

Finally, you want to tell Github you’ve successfully processed the request. You can do that by sending a success response:

  res.send 'OK'

That’s it! Your Hubot is now listening to pull request events from Github. You can now move on to do stuff with the data you receive

Hubot: get it running locally in Slack

Wed, 15 Mar 2017 00:00:00 +0000

This is the first out of three posts where I will explain how we hooked up Hubot to Github’s API. The goal of this is to get notified in Slack when your pull request becomes unmergeable.

A Springest Hackday idea

At Springest we hold regular hackdays. The purpose of these days is to learn, have fun together and work on something that is related to Springest, but isn’t part of our daily work-routine. It can be anything from hanging a swing in the office to building the company’s internal Facebook app called Sputr.

Starting the day, we all share our ideas during stand-up and we get to work. Either solo or in a team.

‘Get slack notifications when a pull request becomes unmergeable’ was one of the ideas on our hackday-list that I thought was interesting to work on.

In this post, I’ll explain how to run Hubot locally in Slack, so you can test-drive your code.

So what is Hubot, anyway?

Hubot is a chat bot by Github. It is open source and written in CoffeeScript and Node.js. You can automate processes with Hubot through scripts, or just add some flavor to your team’s culture. At Springest, our bot is called ‘Ingrid’. She notifies us about all sorts of things that happen on the Springest website and we can tell her to do stuff for us, like deploying, share support ticket info or give someone karma. All by messaging in Slack.

Slack is a messaging app for teams. Messaging is categorized in channels that everyone is free to follow or not. It enables us to easily communicate with each other.

To install Hubot, you need to follow these instructions:

Node.js and npm

Open your console and check if you have installed node.js and npm:

  $ node -v
  # should output node.js version
  $ npm -v
  # should output npm version

Node.js is a server-side JavaScript environment and npm is a package manager for node programs.

If nothing exists, install node.js by downloading it here. This will also install npm.

Make sure you have the latest version of npm installed, by running:

  $ npm install npm -g

If you have never installed hubot before, you need to install its generator. Otherwise you can skip this step.

  $ npm install -g yo generator-hubot

Let’s run it!

Now that you have the generator, add a directory for your bot and create it. I asked my six-year-old son what name he would give a robot, if he would have one. He said ‘Stone’ because robots are hard like stone. So I called it Stone for this example, no questions asked.

Create your bot (just hit ‘enter’ for all questions) :

  $ mkdir stone
  $ cd stone
  $ yo hubot

  ? Owner irisbune <xxxxxxx@gmail.com>
  ? Bot name stone
  ? Description A simple helpful robot for your Company
  ? Bot adapter campfire
     create bin/hubot
     create bin/hubot.cmd
     create Procfile
     create README.md
     create external-scripts.json
     create hubot-scripts.json
     create .gitignore
     create package.json
     create scripts/example.coffee
     create .editorconfig
                       _____________________________
   _____              /                             \
   \    \             |   Self-replication process   |
   |    |    _____    |          complete...         |
   |__\\|   /_____\   \     Good luck with that.    /
     |//+  |[^_/\_]|   /----------------------------
    |   | _|___@@__|__
    +===+/  ///     \_\
     | |_\ /// HUBOT/\\
     |___/\//      /  \\
           \      /   +---+
            \____/    |   |
             | //|    +===+
              \//      |xx|

  loadDep:mime-db → request ▄ ╢████████████

Check if it is alive and kicking by running:

  $ bin/hubot

If all went well, you should now be able to chat with your bot in the console. Type ‘your-bot-name the rules’ and see if you get a reply.

Move from console to Slack

Create an account on Slack if you do not have one yet. I’ve created my own personal channel, to test this bot before implementing the code in Ingrid, our company bot. Once you have your own channel set up, go to https:// yourslackchannel .slack.com/apps/A0F7XDU93-hubot and click on the green button, ‘Add Configuration’.

Add your bot’s username and hit ‘Add Hubot Configuration’.

Keep this page open, because you need to copy the environment variable in order to run your bot in Slack.

Slack adapter

Now that you’ve configured your bot in Slack, and got your token, you have to install the Slack adapter and your bot is setup to run locally:

  $ npm install hubot-slack --save

Open Slack on your computer and restart your bot with Slack’s environment variable, followed by a call to hubot’s scripts, plus the adapter flag:

  $ HUBOT_SLACK_TOKEN=your-hubot-api-token ./bin/hubot --adapter slack

Invite your bot to your #random Slack channel (/invite @botname) and test it out by typing @botname pug me

Congratulations! You are now ready to hook up Github’s pull request events.

Vim: Buffers, Tabs, Windows & Modes

Fri, 29 Jul 2016 00:00:00 +0000

This is the third and last post in this Vim series. You might be interested in reading through my previous posts before you continue reading (especially if you are a real beginner):

In this post we will talk about buffers, tabs, windows and the different modes that you can find in Vim. Let’s jump in!

Buffers, windows and tabs

If you are moving to Vim from another editor like SublimeText or Atom, you are used to working with tabs in a certain way. Specifically, a tab represents an open file, and as soon as you close it, it goes away. A web browser follows this same principle as well.

Vim has a system for tabs too, but it works in a completely different way from what you are used to. I got quite confused by this when I first started with Vim, so don’t panic if that’s the case for you as well. You are not alone!

In Vim, there are three levels of view abstraction: buffers, windows, and tabs. Let’s look at each of them from the ground up, since it’s the best way to understand the differences in concept and learn how to use them properly.

Buffers

A buffer in Vim is an open instance of a file. This means that the file may not be visible on the current screen, but it is saved somewhere in memory.

Whenever you open a file in Vim, that file gets put into a buffer that will remain in memory until you explicitly delete it with a call to :quit or :bdelete. You can list all buffers currently open within a Vim session by typing :ls.

Let’s look at some other useful commands:

zz - Center the current line within the window
zt - Bring the current line to the top of the window
zb - Bring the current line to the bottom of the window

Although files in Vim’s buffer may not be visible at all times, its functionality is analogous to how you use tabs in familiar text editors.

Windows

A window in Vim is a viewport onto a single buffer. You can open a new window with :split or :vsplit, including a filename in the call. This opens your file as a new buffer (again, similar to a tab in a traditional editor) and opens a new window to display it.

This is what a Vim session with multiple windows open (horizontally and vertically) looks like:

Windows are also referred to as Splits.

Let’s look at some useful commands:

:new [filename] - Open a new window above the current window
:vnew [filename] - Open a new window beside the current window
:split <filename> - Edit the specified file in new window above the current window
:vsplit <filename> - Edit the specified file in a new window beside the current window
<Ctrl-w>h,j,k,l - Navigate to the window in the given direction

Tabs

Finally, a tab in Vim is a collection of one or more windows. This allows you to group windows in a useful way.

Let’s look at some related commands:

:tabnew - Open a new tab
:tabedit <filename> - Edit the file with the provided name in a new tab
gt - Go to next tab open
gT - Go to previous tab
<Ctrl-w>T - Break the current window out to a new tab

Modes

Enough about navigation for now. Let’s move on and talk about the different modes that you will find in Vim’s world!

Vim is a “modal” editor, which means it has various modes that change its behavior in response to your key presses. This modal nature is at the core of Vim’s power, so it’s very important to understand it in order to use Vim in the most efficient way.

Vim has three different modes: insert, normal and visual. Let’s now look at them one at a time.

Insert Mode

When you use other editors like SublimeText or Atom, you’re always working in insert mode. In this mode, characters appear immediately in the buffer as you type them. You can enter insert mode by pressing i in normal mode.

However, Vim prioritizes moving through a file and making targeted edits, which are done in normal mode.

Normal Mode

Normal mode is the default mode Vim starts in. You are expected to be in this mode the most of your time, while using all motions and operations that we saw in the previous post.

This fits with the idea that we, as developers, spend the majority of our time moving and editing within a document, rather than simply adding long blocks of text.

Visual Mode

In more familiar text editors, a block of text can be selected by clicking the mouse and dragging over a number of lines or characters. Vim introduces Visual model, which allows you to reuse all motion commands and operators that there are to manipulate blocks of text.

Enter Visual mode by pressing v in normal mode. Move the cursor using all the normal motions, and Vim will highlight from where you started to where you move the cursor. You can use a number of keys such as d, x, or c to operate on the visual selection, similar to how these keys would operate in normal mode.

Sometimes you will need to operate on entire lines. Visual Line Mode turns out to be very useful in these cases, and it can be started by pressing V from normal mode.

But what about selecting a column of text? Vim’s got you covered too, enter Visual Block Mode by pressing <Ctrl-v> from normal mode. Here is a list of the common visual block operations and their mapping:

d, or x - Delete the visual block selection
c - Change the visual block selection
r - Replace all characters in the block with the next character you type
I - Insert text before the block
A - Insert text after the block

Be aware that when you change or add any new text, Vim will only show the change happening in the first line of the block. After you complete the change/insertion and hit <esc>, it will replicate to all lines.

Stay Normal

If you only take one thing away from reading this blog post, let it be this: Normal mode is your best friend!

Avoid staying in insert mode for extended periods of time. And also, don’t move along the file while in insert mode. It might be difficult in the beginning, but once you get used to it, you will see how much faster you become. ;)

Wrapping up

This series is a quick introduction to the infinite world of Vim. It is a tool help you get started, but remember that learning Vim is a nonstop continuous process. Stay on it, make it part of your daily life, and every time that you find yourself doing something in a very inefficient way, you know what to do… Go online, look for a friend and ask for help!

Vim: Motions & Command Language

Mon, 25 Jul 2016 00:00:00 +0000

This is the second post in the vim series. You might be interested in reading through my previous post before you continue reading (especially if you are a real beginner):

5 Tips to Survive Your First Week

In this post we will dive into some subjects that you need to master when working with Vim. The very first one is motions, also known as how to get your cursor where you want it.

Motions and Moving

Developers spend a lot of time navigating files and positioning the cursor where needed, and not much time typing new code. It comes as no surprise that Vim is optimized for this situation and has many ways to efficiently move the cursor where you want it.

Motions are defined as the commands you use to move around Vim.

Moving within a line

These are the most important key bindings for moving within a line:

h, l - move left/right by character
w - move forward one (w)ord
b - move (b)ackward one word
e - move forward to the (e)nd of a word

Before we move forward, let me give you a pro tip: Whenever you find yourself repeating or holding down a motion key to move around, take a second to consider if there is a better way of doing what you are trying to accomplish. Most probably there is one ;-)

Jumping within a line

But what if you want to move to a specific character within a line? Try any of these:

f<char> - (f)ind a character forward in a line and move to it
T<char> - find a character backward in a line and move un(t)il it
t<char> - find a character forward in a line and move un(t)il it (one character before)
F<char> - (f)ind a character backward in a line and move to it
$ - go to the end of the line
0 - go to the beginning of the line

Moving between lines

I know, I know… most of the files you work with contain more than one line! So here it is: How to move between different lines:

j, k - move up/down one line
H, M, L - move (H)igh, (M)iddle, or (L)ow within the viewport
Ctrl-u, Ctrl-d - move (u)p or (d)own
/ - search for any word in the file
n - repeat last search
N - repeat last search in opposite direction
<NN>G - (G)o to the line number NN
G - go to the end of the file
gg - go to the beginning of the file

Command Language

Enough movement for now! Next let’s focus on one of the most powerful and unique aspects of Vim: Vim’s Command Language. Vim uses a concise and expressive language of key mappings that allows us to describe every edit we want to make. And it is worth investing the time needed to master it!

Editing Command Syntax

Just as any sentence is made up of a verb and a noun, an editing command is made up of two parts: an operation and a section of text. For example, take the commands for “delete this word”, “change the next sentence” or “copy this paragraph”. They all have the same structure:

<number><command><text object or motion>

The number is used to perform the command over multiple text objects or motions, e.g., backward three words, forward two paragraphs. This number is optional and can appear either before or after the command.
The command is an operation, e.g., change, delete (cut) or yank (copy).
The text object or motion can either be a text construct, e.g., a word, a sentence, a paragraph, or a motion, e.g., forward a line, back one page, end of the line.

Let’s look at each of these one at a time.

Commands

Find below some of the most useful operator mappings:

d - (D)elete
c - (C)hange
y - (Y)ank or copy
>, < - indent, dedent
= - reformat (reindent, break long lines, etc.)

The simplest commands are made by repeating the operator a second time to act on the current line. For example, where d is the operator for delete, dd will delete the whole line. Each of yy, cc, >>, == behave similarly.

Using Motions

We can also identify text by using any motion. Just like you can use w to move to the next word, you can use dw to delete to the next word. This also includes more complex motions such as t, which will wait for you to specify a character to go up un(t)il.

Herein lies the magic of Vim: Just by following these rules, you can create any variation of the delete operation by combining it with any motion. Let’s look at some examples:

dw - delete to the next word
dt, - delete up until the next comma on the current line
de - delete to the end of the current word
d2e - delete to the end of next word
dj - delete down a line (current and one below)
dt) - delete up until next closing parenthesis
d/rails - delete up until the first search match for “rails”

Using Text Objects

You can think of text objects as a kind of “noun” that can be used in place of motions to define a range of text from anywhere within it. Let’s look at some examples:

iw, aw - inner word, a word
ip, ap - inner paragraph, a paragraph
i), ap - inner parenthesis, a parenthesis
i', a' - inner single quote
i", a" - inner double quote
it, at - inner tag, a tag

Check out this blogpost for a nice rundown of the different text objects available and practical examples.

You can also get a full listing from within Vim by typing :h text-objects.

By now you might be wondering if there are any best practices to help you decide when to use motions and when to use text objects. A command using a motion, for example cw, operates from the current cursor position. A command using a text-object, for example ciw, operates on the whole object regardless of the cursor position. Although this requires one more character, it saves you the time and effort of moving the cursor into the “right” position.

That’s why it’s generally accepted that you should try to use text objects rather than motions whenever possible.

Wrapping up

Are you still curious about the infinite world of Vim? In the next post I will focus on windows and tabs, modes and plugins. So stay tuned!

Vim: 5 Tips to Survive Your First Week

Mon, 18 Jul 2016 00:00:00 +0000

Some months ago I organized a workshop at Springest to share the basics of tmux and Vim with the rest of the team. I already wrote a post about tmux. And now it’s time to say something about Vim!

I will be splitting the content of the workshop into different posts, this being the first one where I will focus on how to survive your first week!

It goes without saying that as software developers, our jobs depend on continuous learning. It’s therefore incredibly useful to jump in as a beginner on new tools and subjects from time to time. So why don’t we all give Vim a try today? Here are 5 tips to help you go through your very first days.

Vimtutor

Vim comes along with its own interactive tutorial: Vimtutor. Following the tutorial takes about 30 minutes, where you will learn your first Vim commands: how to create and open files, make changes and save them, etc.

Open up a shell, type vimtutor and you are ready to go!

Avoid too much configuration

Vim allows you to configure and extend its behavior almost without boundaries. Be careful here, since it is recommended to spend your first weeks getting to know Vim’s core behavior and its default key bindings. Try to stay away from any type of customization or configuration. I promise that when you look back in the future, you will thank yourself ;)

However it is totally allowed to borrow some basic configuration from a friend. Personally I learn things much better if my screen looks nice (I guess because of my design background), and the default vim colors were not so appealing for me. So some configuration was needed in my case. Back then, I borrowed Mike Coutermarsh’s configuration. But you can check out my .vimrc as well if you prefer.

If you encounter any issues when using my configuration, ping me on twitter and I’ll help you out.

Build up a cheat sheet

There are some very good cheat sheets out there when starting to learn vim, like this one, that can serve as a great reference. However it is very important that you build up your own while you are learning.

For those of you familiar with Asana, I created a single project when I started learning: Mastered Vim. I was regularly adding new tasks (following different topics, like motions and moving, windows, tabs, etc.) and writing down all related key bindings in the task description. Every morning before jumping into Vim, I would review all of them and mark any task that I could already remember as completed!

This method worked great for me, and I encourage you to do the same.

Ask for help

There will be moments in which you need to ask for help. In this case, you have several options:

Vim’s Built-In Help - Great resource when you know exactly what you are searching for. Open up vim and type :help <vim-command>. From there you can follow any tag under the help by typing Ctrl + ].
Vim Wiki - Visit this site when you have other more general questions, like how to re-indent a whole file.
Friends - At Springest there are other people that use Vim too. We created our own #vim channel in Slack. I love it when I go there with a question aiming for a very direct answer and see others starting a discussion about the different ways in which it can be accomplished within the Vim world!

Stick with it

Last but not least, you need to make a commitment to yourself - keep going when the landscape gets dark. Normally it takes about a week to feel productive again. From there on you can only continue getting more and more efficient, which is something that definitely helps you grow as a developer. Enjoy the journey!

Vacancy Senior Ruby on Rails Developer in Amsterdam

Wed, 06 Jul 2016 00:00:00 +0000

Link to Dutch version

We want Springest to become the largest source for learning in the world. From books and e-learning courses to onsite trainings, we help our users discover, compare, and book everything they need to reach their personal and professional learning goals.

Working at Springest

We are looking for senior Ruby developers to join our growing engineering team. We don’t have managers at Springest, but processes, and we feel that individuals taking responsibility is very important. At Springest, you will work in close collaboration with product owners, marketing, and sales colleagues. You are also a member of our development team where we discuss architecture, infrastructure, and keep a close watch on security and performance.

We are hosted on AWS and make heavy use of their offerings like RDS, CloudWatch, Elastic Beanstalk and EC2 Container Service.

Hackdays!

We do a regular internal hackday every month where we drop everything and work on something completely different, which we feel is super valuable for coming up with new ideas. We might give a new programming language a shot, try out an idea someone’s been toying with for a while or hack on some actual hardware (that’s our temperature sensor above in its beginning stages!).

A lot of hackday ideas actually became super important for our company, its a great chance to experiment with something that could grow out to become a key factor of our business.

Check this recap of a recent hackday to read more about why we organise them.

Your New Colleagues

What we expect from you

You work well in a team, and want to make the team greater than a sum of its parts.
Engagement in what it is that you are building and who you are building it for. We want you to feel involved and come up with ways to make Springest better.
The drive to improve yourself and our organisation and deliver high quality work.
You have a broad interest and deep knowledge, certainly not just in/about Ruby. We are all about learning and sharing knowledge.

What You Get From Us

Apart from Springest being the coolest company you will ever work for, there are a few extras:

We are very remote friendly.
At least a € 1,000 education budget per year to spend on training, courses, and conferences.
Stock options after 2 years.
A cool workplace in the center of Amsterdam with height adjustable desks that you can sit and stand at, table tennis, a massage chair, and balcony with a barbecue.
A Macbook.
All software and hardware you need to do your job and have an optimal workflow.

Contact Mark Mulder (mark@springest.com) for questions and applications. Please include links to your Github and LinkedIn profiles.

Checkout these links to get to know more about us:

Springest June Hack Day Recap

Wed, 15 Jun 2016 00:00:00 +0000

An Inside Look at Our Awesome All-Company Hackathons

Hack Day has long been a tradition on the Springest team. We’ve built some amazing prototypes in ridiculously short timeframes — some of which have gone on to become real product features.

Uniquely, we also don’t limit Hack Day to the development team. From marketing to sales and customer support, everyone at Springest takes part in our monthly all-company hackathons.

Why we hack

We have a few core goals for each hack day:

Innovate: Work on something not on our usual roadmap.
Learn something: Try out a new coding language, service, or skill.
Have fun: Whatever you do, it should inspire you.

Preparation

All month long, Springeteers are encouraged to keep track of inefficiencies in their workflow and brainstorm possible solutions.

Is there a boring, repetitive task taking up way too much of your time? Let’s find a way to automate it. Is there a key metric that takes forever to compute? Let’s write a script to calculate it for you.

For coders and non-coders alike, there are plenty of awesome tech tools to hack your way to a more productive workday.

For high-tech solutions, developers are brought in for cross-team collaborations, which often produce the most interesting results. For example, our grumpy Smooth Operations team ended up with a Raspberry Pi hooked up to a temperature sensor, complete with on-demand Slack notifications.

Execution

Hack Day starts at 9:30am with an all-team meeting. We each present our ideas to the group, which often involves convincing other skilled team members to join in on a big idea. Afterwards, we’re all free to choose what we work on, and we turn on some music before settling into our projects.

Result

5pm is demo time. While some still hunch over our computers making final tweaks, the rest of us crowd into the kitchen to see whatever working (or almost-working) prototypes made it out the door.

While we don’t have prizes or accolades for “winning” ideas, there is always plenty of beer and applause to go around.

And what exactly did we achieve this month? Here’s an inside look at this month’s Hack Day projects:

Revenue Wall of Fame

Hacker: Ewout Meijer, Director of Corporate Partnerships

Problem: We hit revenue records all the time, but we have no easy way to see whether a high number is our true ‘record’ without looking it up. That’s lame - we should know when to celebrate!

Hack: Display the “Revenue Record” output of our Google Sheets metrics on a giant screen, so everyone can see it and get stoked.

Gym Class Line Jumper

Hacker: Liz Hubertz, Software Developer

Problem: Gym classes are always full, and you have to be SO fast to register when a “you’re off the wait list!” email is sent. This decreases workday productivity, because you’re always looking out for that email.

Hack: Used Zapier to trigger a webhook when the email is received, then built a small Rails app to handle the automatic login and registration process. Classes are thus instantly booked upon receipt of the “you’re off the wait list!” email.

SSL Quality Slack Notification

Hacker: Tim Flapper, Software Developer

Problem: We currently have no way to easily and conveniently monitor our SSL setup. Wouldn’t it be awesome to get a notification right in Slack? Yes.

Hack:

Learning Advisor Booking Scoreboard

Hackers: Midas and Merel, Learning Advisors (Customer Support)

Problem: An important part of measuring the success of our Learning Advisors is knowing how many bookings they achieve per week. This data therefore needs to be easy to find and visible for everyone.

Hack: By linking Slack with Google Docs with Zapier, they made an automated scoreboard that keeps track of how many bookings were done by Learning Advisors and how many were done by users themselves on our site. The scoreboard will be displayed on the TV screen in the Learning Advisor corner, so they can always see how they are performing that week.

New Springeteer Onboarding Program

Hackers: Debbie van Veen, Smooth Operations Lead and Anne Nynke Jansma, Learning Advisor

Problem: Our current onboarding process feels like it can be improved, but we don’t have any data to back up how or why!

Hack: Next to partially rewriting our onboarding help articles and making clearer tasks, they also created a survey for new Springeteers to track how often our tools are used and what people think of the program / what they miss.

Automated Inbound Lead Email Flow

Hacker: Sofie Angevaare, Marketing

Problem: We lose out on a lot of useful leads by not using smart enough filters on our inbound flow.

Hack: Brand new automated e-mail flow that identifies whether our users should be followed up on by our provider sales team, plus a Slack notification whenever a key user is identified.

Polish ALL the Things!

Hacker: Rik Matena, Product Owner

Problem: Rik has been working on an internal customer support tool called Scoutest for awhile, but there are always improvements to be made. As a technical guy in his own right, he also helped out non-tech folks with their hacks.
Hack: Awesome UX improvements and a working and beautiful display for Ewout’s Wall of Records hack.

ASQ API

Hacker: Dennis Paagman, Product Owner and Developer

Problem: We want to use data from our internal tool ASQ in external applications, which generates key metrics based on saved SQL. This allows us, for example, to automate filling in KPI metrics in our Google Sheets.

Hack: Built the API! Awesome!

Pldealio

Hacker: Dennis Paagman, Product Owner and Developer

Problem: It would be nice to visualise our corporate sales pipeline, but deals take a long time to go through - making it seem like not much is happening.

Hack: Pldealio deal pipeline timeline!

Learning Advisor Reviews

Hackers: Zoe van Dantzig and Maarten Butterman, Learning Advisors

Problem: Our product focuses on quality reviews, so why don’t we let our users review our customer support team?

Hack: Created Springest trainer accounts for each Learning Advisor. Customers can now rate our customer support team in the same way that they rate trainers on the Springest website.

Notifilter API & Slack Bot

Hacker: Mark Mulder, Software Developer

Problem: Mark built an awesome internal tool called Notifilter that would be super useful with an API, because that would allow us to grab statistics and re-use these numbers in Sheets, post them to Slack, etc.

Hack: Notifilter API and Slack Bot is now live!

Final Thoughts

I hope our examples give you some inspiration to try out your own all-company hackathon. While not all of our hacks will survive the test of time, Hack Days promote inter-team communication, collaboration, and learning. Plus, it’s a great way to ultimately boost employee happiness and productivity — not to mention an excuse to drink beer during work hours. ;-)

P.S. Think Hack Day sounds awesome? We’re always hiring talented developers, and you can contact us on Twitter @SpringestOps or by email at mark@springest.com.

Springest Developer Blog

Vacancy: senior frontend developer in Amsterdam

Working at Springest

Your New Colleagues

Some of your challenges

What we expect from you

What You Get From Us

Hubot: Get notified in Slack on merge conflicts

Connect to Github’s API to check the merge status of a pull request

Send a notification to your Slack channel on a merge conflict

Keeping track

Efficient and effective working: a Product Tank meetup with special guest David Allen

Hubot: listen to Github's pull request events

Github’s API

Enable Github’s Pull Request events

Send events to a webhook.

Set up ngrok

Set up the webhook.

Test the webhook.

Make Hubot listen to the webhook

Hubot: get it running locally in Slack

A Springest Hackday idea

So what is Hubot, anyway?

Node.js and npm

Let’s run it!

Move from console to Slack

Slack adapter

Vim: Buffers, Tabs, Windows & Modes

Buffers, windows and tabs

Buffers

Windows

Tabs

Modes

Insert Mode

Normal Mode

Visual Mode

Stay Normal

Wrapping up

Vim: Motions & Command Language

Motions and Moving

Moving within a line

Jumping within a line

Moving between lines

Command Language

Editing Command Syntax

Commands

Using Motions

Using Text Objects

Wrapping up

Vim: 5 Tips to Survive Your First Week

Vimtutor

Avoid too much configuration

Build up a cheat sheet

Ask for help

Stick with it

Other posts in this series

Vacancy Senior Ruby on Rails Developer in Amsterdam

Working at Springest

Hackdays!

Your New Colleagues

What we expect from you

What You Get From Us

Springest June Hack Day Recap

An Inside Look at Our Awesome All-Company Hackathons

Why we hack

Preparation

Execution

Result

Revenue Wall of Fame

Gym Class Line Jumper

SSL Quality Slack Notification

Learning Advisor Booking Scoreboard

New Springeteer Onboarding Program

Automated Inbound Lead Email Flow

Polish ALL the Things!

ASQ API

Pldealio

Learning Advisor Reviews

Notifilter API & Slack Bot

Final Thoughts