Never miss an update:

  • Vim: Motions & Command Language

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

    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!

    Read more
  • Vim: 5 Tips to Survive Your First Week

    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:

    1. 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 + ].

    2. Vim Wiki - Visit this site when you have other more general questions, like how to re-indent a whole file.

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

    Read more
  • Vacancy Senior Ruby on Rails Developer in Amsterdam

    Link to Dutch version

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

    We have a strong product focus in which everything revolves around the users of our Dutch, German, 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 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.

    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.

    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!

    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 our recap of the most recent hackday to read more about why we organise them.

    Your New Colleagues

    At Springest you will work with around thirty 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.

    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 from us or upgrades to your own.
    • 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:

    Read more
  • Springest June Hack Day Recap

    An Inside Look at Our Awesome All-Company Hackathons

    everyone

    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:

    1. Innovate: Work on something not on our usual roadmap.
    2. Learn something: Try out a new coding language, service, or skill.
    3. 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

    ewout

    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

    liz

    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

    tim

    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:

    SSL checker

    Learning Advisor Booking Scoreboard

    midas and merel

    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.

    onboarding

    Automated Inbound Lead Email Flow

    sofie

    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!

    rik

    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.

    Scoutest

    ASQ API

    dennis

    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

    mark

    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.

    Read more
  • Lessons from ITEA 2016: 4 Myths About Tech Startups

    ITEA presentation

    Last week, I was invited to speak to an audience of international students at the 2016 International Talent Event Amsterdam (ITEA). The goal of this event is to help young people figure out how they want to start their careers, and my job was to give them an idea of why they might (or might not) want to pursue life at a tech startup.

    Startup Q&A

    I presented alongside Ruben Nieuwenhuis of StartupAmsterdam and Mariette Ruggenberg of Upstarter, both Dutch natives and veterans of the Amsterdam startup community. My story was a bit different, as I’m an American who before now had only worked in Silicon Valley. I’m also an engineer, which is a very different perspective from life as a startup founder.

    My Background

    As for my story, the first part of my career focused on huge enterprise organizations - we’re talking corporate behemoths like McAfee, Microsoft, Intel and VMware. The second was focused solely on early-stage startups - companies you’ve probably never heard of working out of a tiny co-working space in the Mission district of San Francisco.

    So, what is my advice for students considering a startup?

    Find out what founding or working for a startup really means

    Myth 1: Funding comes first

    Q: I have an idea. How do I get funding to build my business?

    A: By building your business.

    Unless you are well-known to investors or are a serial entrepreneur, you will need a prototype up and running and your founding team put together before you ask for funding. This is the time where you rent out your mother’s basement, survive on ramen noodles, and work your ass off for free until you have something that makes an investor think, “ok, these guys are at least worth a shot.”

    Sure it’s hard work, but so is anything worth doing.

    Myth 2: You don’t need to be technical

    This one isn’t necessarily a myth, but think of it this way: You have two choices. You can spend months or years searching for that special someone who will build your dream for free (and possibly never find them), or you can spend a few weeks teaching yourself a bit of JavaScript.

    If it were up to me, I’d learn that JavaScript. Being “technical” does not mean that you need a PhD in compiler design. You can hire experienced engineers to clean up your mess once your idea gets off the ground. And for that, all you need to learn are the basics - just enough to get a working prototype out into the world.

    Myth 3: You must be a designer, coder, or growth hacker

    A couple of law students asked this question during our panel: “I’m a lawyer, but startups don’t really hire lawyers. Should I learn to code?”

    This struck me as an odd question, seeing as every startup I’ve ever come into contact with has in fact hired lawyers. They just haven’t hired full-time lawyers on staff. (Though I’m sure legal startups like fixed certainly do.)

    If you’re not looking for a career switch, don’t feel like you need to change paths just to fit into the “startup box.” Broaden your view to the entire ecosystem that thrives in places like Silicon Valley to support the growth of small business.

    Are you a lawyer? Check out firms that specialize in helping small businesses get off the ground. Are you a marketing professional? Plenty of agencies contract with tiny startups before they’ve grown large enough for an internal marketing team. And of course, if you’re a recent MBA, you can always try your hand at the venture capital game.

    Myth 4: Startups are better than big companies (or vice-versa)

    The awesome and irritating part about this is that it’s 100% up to you. To figure out which is “better,” you just need to figure out what you want from your next job.

    Both startups and big companies come with pros and cons, and you’ll need to weigh those options against your current career goals. For example, big companies are known for offering generous salaries, growth opportunities, and senior mentorship - but also for prohibitive bureaucracy and skill stagnation. A startup, on the other hand, will give you the opportunity to take on new roles every day, and there’s no question that your work will make an impact. But with that usually comes a drop in salary, free time, and job stability.

    TL;DR: Your career is what you make of it

    Startups and large enterprise companies both have their place, and eventually one will morph into the other (hello Google and Facebook). So students, stop stressing! Building your career is a lifelong process, and you have time to pursue both worlds. In fact, I’d argue that the more experience you have in all sorts of career environments, the more valuable of an employee (and human being) you will be.

    Read more

subscribe via RSS