• Skip to main content
  • Skip to footer

InRhythm

Your partners in accelerated digital transformation

  • Who We Are
  • Our Work
  • Practices & Products
  • Learning & Growth
  • Culture & Careers
  • Blog
  • Contact Us

best practices

Apr 17 2018

On the subject of Learning and Growth

Here at InRhythm, we’re passionate about Learning and Growth. Normally I don’t unnecessarily capitalize words, but that’s the subject of this post and I think it’s important to emphasize those words and what they mean. We define Learning and Growth as the process of becoming a better, more advanced person, capable of handling new and familiar situations more efficiently and effectively. So why are learning and growth so important to us? Because our people want it!

What’s the problem?

Across all industries, but especially in the consulting industry, employee retention is a big issue. Consulting has one of the highest turnover rates of all industries. Historically, a lot of consulting companies have employed a more dog-eat-dog mentality. “We’re in an industry that’s all about the bottom line, so why shouldn’t we treat our employees the same way?” – these companies employ a strategy along the lines of “grow or go,” treating employees like they must either climb the corporate ladder or get out because there’s no room for those who do not aspire to be the CEO. The problem here is that not everybody wants to be a CEO and that is okay.

Employee retention is almost exclusively a function of employee satisfaction. In all cases of turnover (voluntary or involuntary termination), it is due to poor employee satisfaction. Terminations are largely based on performance and there is an established correlation between employee satisfaction, productivity, and retention. Keeping employees happy and productive requires a large investment by employers, but those that have made the commitment find that the return on their investment far exceeds what they invested. Which brings us again to what satisfies employees? How do employers keep them happy?

Broken attempts to fix it…

A lot of people are aware of the correlation between employee satisfaction and employee retention. There are a multitude of issues that could lead to dissatisfaction such as poor management or no trust between coworkers, but I want to focus on learning and growth. I’ve seen many different employers try to make their employees happier but their efforts are usually a little misguided. They try things like snazzing up the office with new decor, mandatory team-building exercises, holiday parties, or just throwing money at the problem and offering people bonuses or incentives. The last one is actually the most problematic. Studies show that once people reach a “comfortable” income level (adjusted for your location) they’re much less concerned about exact dollar amounts and more about their lifestyle. A raise will simply not keep people around as much as getting their own office and/or fixing whatever cultural problem they’re suffering from.

How we address it

We try to give people exactly what they want. Across the board, most people look for jobs to be growth opportunities. They want their position to be something they learn-into and then later something that provides them more contextual and higher-level growth. Very few people, especially in this industry, want to just do what they already know how to do. They want to do something slightly different to keep their brain and their career growing.

“Our people are the most important part of our company. It’s not the budgets, it’s not the office and the toys, it’s not messaging or branding… It’s the people that we work with.”

We try to provide growth in several ways. First, we only take on projects working on modern, interesting tech; our people don’t want to work on legacy apps maintaining code written years ago, they want new stuff where they can stretch their creative muscles. Only taking on modern projects means potentially turning down lucrative projects, but we also have the peace-of-mind that the whole team isn’t going to quit in 2 weeks. We also host a TON of learning events. So far this year we’ve worked on meetups exploring best practices in VueJS, CSS, and UX Design. We get good attendance at these meetups and I think it’s because our people really yearn to learn. We’re also very into finding learning resources for our people. Personally, I make sure to share as much interesting stuff on Slack as I can so that the team can benefit from the same interesting bits that I benefit from. We have a huge bookshelf at the office with books on all sorts of topics: Philosophy, Management, Coding, Interviewing, Business Development…

One of the reasons I joined a consultancy and InRhythm, in particular, is because of the opportunity for learning and growth and I wasn’t disappointed. Since I started here, I’ve been able to work on multiple client sites, learning about different cultures and processes. I’ve been able to work on different JavaScript frameworks that I might not have worked on otherwise. I’ve played different roles in the company and best of all: I’ve been able to spend time with a diverse group of interesting people. This kind of positive experience is easy to reproduce, all you have to do is listen to your people. If they say they want learning and growth, give it to them! If they say they want better snacks or more wall art or the budget to go to a conference, give it to them! Those happy, learning, growing employees will produce more than any others you’ve had before and they’ll stay with the company for a nice long time.

Additional Resources:
  • https://americanstaffing.net/posts/2014/10/01/climb-continues

Written by Jack Tarantino · Categorized: Agile & Lean, InRhythm News, Learning and Development, Talent · Tagged: best practices, Business Development, growth, Learning, Teaching

Mar 30 2018

CSS the Right way

With Sari Morninghawk!

Sari walks us through CSS best practices to help you keep your styles neat, tidy, and easy to maintain. If you couldn’t make it, check out the video below and make sure to sign up for our next workshop via Meetup!

Written by Jack Tarantino · Categorized: Code Lounge, Design UX/UI, Events, InRhythm News, Learning and Development, Software Engineering · Tagged: best practices, CSS, development

Mar 26 2018

Debugging Node without restarting processes

This post is another by InRhythm’s own Carl Vitullo. For the full, original post check out “Debugging Node without restarting processes” on hackernoon. Make sure to follow him on Twitter and in Reactiflux!

I’m typically a frontend developer, but every now and then I find myself writing or maintaining some backend code. One of the most significant drawbacks I’ve encountered when switching contexts to Node is the lack of the Chrome Developer Tools. Not having them really highlights how hard I lean on them during my day to day in web development. Luckily, there are options for enabling them, and they’ve gotten much more stable and usable in recent times. Node has a built in debug mode that allows you to connect to the DevTools, and there’s a package called node-inspector that connects automatically.

It’s worth noting that versions of Node < 8 use a now-legacy Debugger API. Node 8 introduces the Inspector API, which better integrates with existing developer tools.

There’s one common theme that I’ve encountered when using these methods: they must be invoked when starting the node process. The other day, I found myself with a process in an odd state that I’ve had trouble reproducing, and I didn’t want to risk losing it by restarting the process to enable the inspector.

However, I found a solution — no less, a solution from the official Node docs.

A Node.js process started without inspect can also be instructed to start listening for debugging messages by signaling it with SIGUSR1 (on Linux and OS X).

This only applies to unix based OSes (sorry Windows users), but it saved my bacon in this case. The kill command in unix may be ominously named, but it can also be used to send arbitrary signals to a running process. man killtells me that I can do so using the syntax, kill -signal_name pid. The list of signal names can be enumerated with kill -l, shown below.

$ kill -l
hup int quit ill trap abrt emt fpe kill bus segv sys pipe alrm term urg
stop tstp cont chld ttin ttou io xcpu xfsz vtalrm prof winch info usr1 usr2

By default, kill sends an int, or an interrupt signal, which is equivalent to hitting ctrl-c in a terminal window. There’s a lot of depth to process signals that I won’t get into (I encourage you to explore them!), but towards the end of the list is usr1. This is the SIGUSR1 that the node docs are referring to, so now I just need a pid, or process ID, to send it to. I can find that by using ps and grep to narrow the list of all processing running on my system

$ ps | grep node
9670 ttys000 0:01.04 node /snip/.bin/concurrently npm run watch:server npm run watch:client
9673 ttys000 0:00.46 node /snip/.bin/concurrently npm run watch:server-files npm run watch:dist
9674 ttys000 0:33.02 node /snip/.bin/webpack — watch
9677 ttys000 0:00.36 node /snip/.bin/concurrently npm run build:snip — — watch
9678 ttys000 0:01.65 node /snip/.bin/nodemon — delay 2 — watch dist ./dist/src/server.js
9713 ttys000 0:01.00 /usr/local/bin/node ./dist/src/server.js
9736 ttys003 0:00.00 grep — color=auto node

My output is a little noisy due to a complex build toolchain that spawns many processes. But I see down towards the bottom the right process: node ./dist/src/server.js, with a pid of 9713.

Now I know the signal name is usr1 and the pid is 9713, so I need to run.

$ kill -usr1 9713

It runs with no output, but I check the logs of my node process and see

Debugger listening on ws://127.0.0.1:9229/ad014904-c9be-4288–82da-bdd47be8283b
For help see https://nodejs.org/en/docs/inspector

I can open chrome://inspect, and I immediately see my inspect target.

I click “inspect”, and I’m rewarded with a Chrome DevTools window in the context of my node process! I can use the profiler to audit performance, use the source tab to add break points and inspect the running code, and use the console to view logs or modify the variables in the current scope, just like I would on the web.

Written by Carl Vitullo · Categorized: InRhythm News, Learning and Development, Software Engineering · Tagged: best practices, Chrome, CLI, Devtools, Inspector, JavaScript, kill, Linux, Node, Processes, Signals

Mar 02 2018

One-directional data binding without frameworks

This post is another by InRhythm’s own Jack Tarantino. For the full post and additional links, check out the original “Frameworkless JavaScript Part 3: One-Way Data Binding” on his website.

The following article is one in a series about writing client-focused JavaScript without the help of libraries and frameworks. It’s meant to remind developers that they can write good code on their own using nothing but native APIs and methods. For more, check out the original article on writing small JavaScript components without frameworks and the previous article on templates and rendering.
This article is intended to be a deep-dive into data-binding, how it works, and how you can do it without frameworks like Angular, React, or Ember. It is strongly recommended that you read the previous article before this one.

1-way data-binding

1-way data-binding is “a method of putting data into the DOM which updates whenever that data changes”. This is the major selling point of the React framework and with a little effort you can set up your own data binding with much less code. This is particularly useful when you have an application that sees routine changes to data like a simple game, a stock ticker, or a twitter feed; objects needs to have data pushed to the user but no user feedback is required. In this case, we need an object with some data in it:

let data_blob = {  
  movie: 'Iron Man',
  quote: 'They say that the best weapon is the one you never have to fire.'
}

A Proxy:

const quote_data = new Proxy(data_blob, {  
  set: (target, property, value) => {
    target[property] = value
    console.log('updated!')
  }  
})

And a poor DOM node to be our guinea pig:

<p class="js-bound-quote">My favorite {{ movie }} quote is "{{ quote }}".</p>  

In this case, we need the data_blob to serve as a storage unit for the proxy. Proxies in ES6 are a convenient way to trigger callbacks when certain actions are taken on an object. Here, we’re using the proxy to trigger a callback every time somebody changes a value in the data blob. We don’t have a way to update the text in the DOM node yet though so let’s set that up:

const quote_node = document.querySelector('.js-bound-quote')

quote_node.template = quote_node.innerHTML  
quote_node.render = function render (data) {  
  this.innerHTML = this.template.replace(/\{\{\s?(\w+)\s?\}\}/g, (match, variable) => {
    return data[variable] || ''
  })
}

This gives us a quick and dirty way to update the node’s inner HTML with some arbitrary data. The only thing needed to connect our new script with the proxy is to substitute the console.log call with quote_node.render(data_blob):

const quote_data = new Proxy(data_blob, {  
  set: (target, property, value) => {
    target[property] = value
    quote_node.render(data_blob)
  }  
})

With all this setup, we can add a quick script to prove that our DOM node is, in fact, updated every time we change the data blob. The exact same way that we want things to happen with a framework but with no external dependencies and WAY less code.

const quotes = [  
  "What is the point of owning a race car if you can't drive it?",
  "Give me a scotch, I'm starving.",
  "I'm a huge fan of the way you lose control and turn into an enormous green rage monster.",
  "I already told you, I don't want to join your super secret boy band.",
  "You know, it's times like these when I realize what a superhero I am."
]

window.setInterval(() => {  
  const quote_number = Math.floor(Math.random() * quotes.length)
  quote_data.quote = quotes[quote_number]
}, 2000)

This adds a script to change to a random quote every two seconds. Check out the working example below:

This is a little sloppy, as it only works for one node, one time. Let’s clean things up a bit and add constructors for both the nodes and Proxies. Continue reading on jack.ofspades.com…

Written by Jack Tarantino · Categorized: Software Engineering · Tagged: best practices, JavaScript

Jun 05 2017

Vim, Tan, Laundry: Navigating the World’s Best Editor

The question that has bedeviled scholars and scientists alike for millennia: how in the world does one quit Vim?

View post on imgur.com

One quits Vim by typing  :q and then hitting enter. Now that you know how to quit…

why should you opt to stay inside of Vim?

Why use it in the face of other, more modern text editors, like Sublime, Atom, or VS Code? I personally elect to use Vim because it is a modal text editor, and this allows for compose-able commands. But what does this mean?

Let’s start by examining what modal means. In this context, the word “modal” means that in the course of editing a piece of code, Vim users will switch between one of multiple different modes for different functionality. Has your terminal ever shunted you into Vim, and you try to type but haven’t seen the words appear on screen? Worse, you can’t exit, and are forced to close the browser tab for want of understanding how to leave this 40 year old text editor? This is because you are not in the mode that allows you to type characters directly into the screen. You are in the default mode, one that is most useful for moving around the document (as well as copy and pasting). This is called “normal” mode. If you want to type out something, you would enter another mode, named “insert mode” to actually insert characters in the screen.

We will primarily focus on these two modes. Note that once you enter a mode OTHER than Normal mode, you can exit back to it by pressing  <Esc>. Some people remap the caps lock key to be an escape key. The workflow should be to enter insert mode through one of the commands below, enter your text, and then hit the  <Esc>  key to enter back into Normal mode.

If you do something wrong while following this tutorial, or would like to experiment with something and then want to undo it, then know that the undo command in Vim is u while in normal mode. If you’re in insert mode, hit the  <Esc> key to re-enter normal mode and then press u.

To start, type  vim test.txt  into your terminal and hit  <Enter> . You should immediately be entered into Vim with a blank file named “test.txt”. So let’s explore. First, we enter insert mode, which will let us start typing. Listed below are some common commands to enter insert mode. For now, you don’t need to worry about all of these, as it’ll be more fun to experiment once you’re move familiar moving around Vim.

i to enter insert mode and not move the cursor.

a to move forward one space and enter insert mode.

I (an uppercase i, not a lowercase L) to jump to the beginning of a line and enter insert mode.

A to jump to the end of a line and enter insert mode

s to delete the character the cursor is on and enter insert mode.

C to delete to the end of the line and hit insert mode.

cc to delete everything in the line, leaving a blank line, and enter insert mode.

These are all useful but for now, since this is a blank document, just hit i, or if you have already entered text, hit <Esc> and hit the letters ggdG, which should clear your document so you can proceed, then hit i (don’t worry, you’ll understand what all those commands mean by the end of the post).

This will bring you into insert mode. Once inside insert mode, Vim works like any normal text editor: You can type characters into it and see them entered into the file (on in Vim parlance, the “buffer”) on screen. But this isn’t what we’ll be spending most of our time in. Type the following sentences, hitting the enter key at the end of each line to insert line breaks like you would in MS Word…

Vim is the best!

Even though it's slightly annoying.

But it's still worth learning.

…and then hit  <Esc> to exit back to normal mode.

Now that you’re in normal mode, try typing  h. You’ll notice that h is not inserted into the file, as the case would in any other text editor. Instead, you’ve moved your cursor back one character. That’s because in normal mode, all of the keys have different functions, with the h,j,k, and l keys primarily focused on moving around.

h will move the cursor one character to the left

j will move the cursor up one line

k will move the cursor down one line

l will move the cursor one character to the right

These are by far the most important (and used) commands to hit in normal mode, the equivalent of the arrow keys in other text editors.

If Vim’s movement were only restricted to these four keys, and you could do nothing else with them, I would have abandoned the editor a long time ago. Fortunately for us, there are many more ways to move around a Vim buffer. The following are only a couple of the many commands (you can see even more in the cheat sheets listed below). After all, as programmers, we do not spend most of our time writing code, we spend most of our time moving around code, copying it, deleting it, and changing it.

w will move the cursor forward one word.

e will move the cursor to the end of the current word.

b will move the cursor back one word.

0 will move to the beginning of the current line

$ will move to the end of the current line

gg will move to the top of the document

G will move to the bottom of the document

Let’s put to use some of your newfound knowledge. Type gg to move to the top of the document and 0 to move to the beginning of the line. Then, hit i to enter insert mode and enter the words “I have discovered that ” so that your document now looks like that following.

I have discovered that Vim is the best!

Even though it's slightly annoying.

But it's still worth learning.

Great! You’re getting the hang of things. But three lines isn’t very hard to move around in. Let’s make a document with dozens of lines, something that, were we using Sublime or Atom, would be far more cumbersome to navigate. Stay tuned for Part 2, where we will accomplish this by getting into the one of the most common problem areas in Vim for beginners: copying and pasting, or in Vim lingo, yanking and putting.

Written by Ian Shuff · Categorized: Software Engineering · Tagged: best practices, keyboard shortcuts, vim

  • « Go to Previous Page
  • Go to page 1
  • Interim pages omitted …
  • Go to page 3
  • Go to page 4
  • Go to page 5
  • Go to page 6
  • Go to Next Page »

Footer

Interested in learning more?
Connect with Us
InRhythm

110 William St
Suite 2601
New York, NY 10038

1 800 683 7813
get@inrhythm.com

Copyright © 2023 · InRhythm on Genesis Framework · WordPress · Log in

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT