InRhythm

Your partners in accelerated digital transformation

Software Engineering

What InRhythm’s CEO Walked Away with After the September CTO Breakfast

I run a CTO Breakfast every month at the InRhythm offices in NYC. We had 9 CTOs attend our breakfast on September 11th. This is an invite only event where we spend 90 minutes discussing the most relevant issues and advancements when it comes to running a software team.

Two topics we discussed in this Breakfast were Talent Retention and Microservices.

Here are the key takeaways:

Software Engineering Talent Retention:

  1. The way to retain engineering talent is to increase ownership at the team level. One way to make them feel empowered is to let them pick the tools and technology that they want to use. This is where Microservices and DevOps automation plays an important role.
  2. It is equally important to make engineers feel their direct impact. If you have engineers who are coding without the big picture they are at a bigger risk of being poached.
  3. Providing an outlet to try new things and innovating is important. Things like internal hackathons, Meetups, and 20% time are important.
  4. Provide a clear track for career growth. Make one-on-one’s focused on engineer’s growth and not the project status.
  5. Promoting and hiring from within incentivizes people to stay.
  6. Having a personal budget for engineers also helps. Let them choose their standing desks, key boards etc. These are small perks that can go a long way.

Microservices and DevOps:

  • All the CTOs in attendance have adopted Microservices at different levels and are increasingly investing in DevOps.
  • Services Discovery at an organizational level is still a challenge and an interesting problem to solve.
  • I have found that for every 100 people on your team, you need around 4-5 people on DevOps tooling team to get most benefits. Since there is such a shortage of DevOps talent – a lot of companies have their software engineers doing DevOps.
  • Common platform to implement Microservices is Scala, Java and Node. Scala’s ramp-up takes time and if it is not done right it can slow you down.
  • Most of the teams are also using Docker or evaluating Docker. There are some concerns around Docker but it’s roadmap seems to be addressing those pain points.
  • Planning your journey from a monolithic architecture to a more Microservices architecture is important as it takes several months if not years to get to it.

Our next CTO Breakfast is on October 9th. We will be holding further discussion around Microservices and cover two case-studies.

Written by Gunjan Doshi

InRhythm Hires John K. Paul as CTO

InRhythm is one of NYC’s leading agile software consulting practices in the space of modern UX and robust engineering using HTML5, CSS, Javascript and Node. The company was recently named one of INC’s 5000 Fastest Growing Private Companies for the third year in a row and has just welcomed John K. Paul to its Leadership team as Chief Technology Officer.

The addition of John comes in the midst of a two-year period of unprecedented growth for InRhythm as the business has become a market pacesetter among financial and e-commerce companies. CEO Gunjan Doshi explains, “our goal is to cultivate a world class community of thought leaders and the addition of John to our team will position us to accelerate our goal of creating high-impact modern software at the highest-velocity.”

John brings extensive experience to InRhythm as a technology principal who excels at constructing and advancing software engineer teams and will be leading initiatives focused on expanding their community of HTML5, CSS, Javascript and Node practitioners. He is an experienced, highly visible public speaker who is sought-after by prominent software conferences throughout the United Statesand is a key player within the technology community, particularly in his home base of New York Cityas organizer of the NYCHTML5 Meetup.

John shares, “I’m thrilled to be coming on board to the InRhythm team as it is growing into an engineering powerhouse with incredible momentum. The company’s leadership in technology, high velocity delivery and agile cultivation is so ingrained in this team, that I could feel it exuding from people from when I first stepped into the office. Our dedication to client triumph is plain to see in InRhythm’s approach and I am very fortunate to be working for a company with a proven track record of business success and personal growth.”

Nothing is Impossible – Making the Switch from ES5 to ES6

I have been writing javascript for about a decade now. When I first saw ES6, it felt like JavaScript had been empowered with so many new functionalities, I just had to rewrite everything to ES6. Once I actually begun that process it was tricky in the existing code base and not possible to rewrite everything using pure ES6 functionalities. I took a step back and decided to start with a smaller subset of ES6 features – class, let/const, lexical scoping, and object. Here’s what I learned along the way:

I have been writing javascript for about a decade now. When I first saw ES6, it felt like JavaScript had been empowered with so many new functionalities, I just had to rewrite everything to ES6. Once I actually begun that process it was tricky in the existing code base and not possible to rewrite everything using pure ES6 functionalities. I took a step back and decided to start with a smaller subset of ES6 features – class, let/const, lexical scoping, and object. Here’s what I learned along the way:

Before getting started you need to prepare the development environment with tools to help write code is ES6, I used gulp (Grunt is also a good choice) to build files. Here’s some Gulp plugins you can install to get started with compiling ES6 to ES5 compatibility versions.

Here is a simple gulp file to help get started:

    
    var gulp = require('gulp');
    var babel = require('gulp-babel');
    var concat = require('gulp-concat');
    var eslint = require('gulp-eslint');
    //Register compilation task
    gulp.task('compile', function() {
        // place code for your default task here
        return gulp.src([
            'src/libs/file1.js',
            'src/libs/file2.js',
            'src/xxx.js',
            'src/yyyy.js'
        ])
        // eslint() attaches the lint output to the eslint property
        // of the file object so it can be used by other modules.
        .pipe(eslint({
            "useEslintrc": true
        }))
        //eslint.format() outputs the lint results to the console.
        // Alternatively use eslint.formatEach() (seeDocs).
        .pipe(eslint.format())
        .pipe(babel({
            "sourceMaps": false
        }))
        .pipe(concat('yourfilename-concat.js'))
        .pipe(gulp.dest('dist'));
    });
    //Register default task
    gulp.task('default', ['compile']);
   

Here are some of the things I learned during my rewriting process:

1. Class

Class was really easy to get started, constructor methods really stands out and it offers a much nicer, clearer syntax for creating objects and dealing with inheritance.

Here is a simple class example:

    
    class Meter {
        constructor(config) {
            this.count = config.count;
        }
        getCount() {
            return this.count;
        }
        static reload() {
            window.location.reload();
        }
    }
   

Interesting things for developers from ES5 world to note:

  1. We don’t have to write the function key word when starting new function
  2. No comma needed for adding a new function
  3. We can’t stick default properties to a class like we do with prototypical inheritance, you have to use this.xyz = ‘abc’ from the function to add a property to the instance.
  4. Static functions are not tied to an instance and you can not call it calling this.reload() instead you have to use a constructor to use this method Meter.reload().
  5. Class declarations are not hoisted

It takes some time to forget the practices that we have been following for years, but once you get hold of it, you will never want to go back again.

2. Variable declaration

Let and const are two new ways to declare variables and both of them are block scope.

2.1 Let

Let is similar to var but it is available to the current code block.

    
    function get() {
        if (condition) {
            let value = "xyz";
            return value;
        } else {
            //value does not exist here
            return null;
        }
    }
   

2.2 Const

    
    if (condition) {
        const MAX_COUNT = 10;
        //more code which uses variable
    }
    //MAX_COUNT is not accessible here
   

In the code above MAX_COUNT is declared within the if statement and MAX_COUNT is only available within the block. As soon as the block statement is finished executing MAX_COUNT is destroyed.

Some important facts to notice here:

  1. We must provide a value when we declare constant.
  2. If we try to assign a value to MAX_COUNT again, the line will throw error.

Interesting things for developers from ES5 world to note:

  1. Let and const are not hoisted to functions or block scope – they are not even hoisted within their own block scope.
  2. We must provide a value to the const variable and if you try to reassign a value to a const variable then it will throw an error.

3. Arrow function

This is one of my favorite feature of ES6, functions defined with a new syntax that uses an arrow(=>) and it works as below:

  • Lexical this binding – The value of this inside of the function is determined by where the arrow function is defined not where it is going to be used.
  • Can not be used with new keyword – it does not provide a new keyword
  • Scope remains constant – this value can not be changed inside the function, it maintains the same value throughout the life cycle of the function.
  • An arguments object is not available – you must pass named arguments.

Examples:

    
    var getName = () => "Hetal";
    // will be transpiled to
    var getName = function () {
        return "Hetal";
    };
   

Lexical this binding

This is the most common use case where we had to come up with storing scope in ES5 world and it has been made easy in ES6 with arrow function.

ES5 you would probably write some function like as below:

    
    var Badge = {
        userName: "Hetal",
        getBadge: function () {
            return "<div class='badge'>" + this. userName + "</div>";
        },
        init: function (type) {
            var self = this;
            //notice how difficult it is maintain scope here
            $(document).on("click", function () {
                self.getBadge.call(self, e);
            });
        }
    };
   

ES6 will make same code easier to write

    
    var Badge = {
        userName: "Hetal",
        getBadge: function () {
            return "<div class=‘badge’>" + this. userName + "</div>";
        },
        init: function (type) {
            //using lexical scope,
            //we can write same code in one line as below
            $(document).on(“click”, (e) => { this.getBadge(e)});
        }
    };
   

This is great way to reduce code lines and write clean code.

 

File Size comparison:

The transpiling process adds some extra code to make it compatible with all browsers which increases the size of the final output file. For instance the file (minified and concatenated versions) that I rewrote is 25KB in ES5 javascript but the ES6 version comes out to be 32KB.

To conclude, Initially I thought that it would be really difficult to convert my project into ES6 but once I started taking baby steps by picking some ES6 features, configuring workflow process using gulp, it all eventually fell in place. I really enjoyed rewriting my ES5 javascript project files into ES6 – which also helped me better organize and structure my codebase and opened my mind to a whole new world. I hope what I learned will help someone who has just started converting projects into ES6. Happy coding!

References:
https://leanpub.com/understandinges6/read

Written by Hetal Thakkar

A Sneak Peek of InRhythm’s NYC Meetup on Node.js

On July 15th the crowd gathered at IRHQ for a Meetup on Node.js. Our senior NY consultant guided everyone through an exercise using Node and then we transitioned to hands-on coding. During the workshop we built an SMS-driven customer service tool using PM2, Gulp, React, WebSockets, ES6 Map, LevelDB, Deploying to Heroku, BrowserSync, Twilio(SMS), and more. We gained a good sense of how to build realtime apps with Node.js, set up a live/responsive build process, and deploy to virtual servers for prototyping. There was a lot of discussion surrounding how Node can be applied to solve business problems. The night was a success and we are excited for many more Meetups to come! Take a look!

Who runs the world? Code, Code: What Development Can Teach Us About Creativity and Being Prepared for the Future

I recently read a LinkedIn post by Dan Robinson on the negative effects of social media and sharing designs and it has caused me to wonder if designers can learn more from developers than the value of coding as a skill. Maybe us designers can learn a little something about what it means to have a strong community to draw inspiration from. In his post, Robinson explores issues of self esteem and what inspiration, if any, designers can and should take from others. He highlights a common concern that we may be ‘comparing ourselves to death’ not only as individual human beings with social media and how we compare to others, but also as UX and visual designers because of constant exposure to what others are doing. Harold Bloom was an early analyst of the role of influence and peers on creativity, including his 1973 work called ‘The Anxiety of Influence’, and how the issues of feeling confident in designs will always plague designers, who often are self reflexive in their outlook to begin with.

Being a designer isn’t just about finding solutions – it’s about critiquing a state to improve it for the future, and as a result, criticism is often the default for many of us. Social media, and communities of practice, have value in learning the craft of design, and designer communities like Behance andDribbble help as a place to explore and share concepts and drafts. But, there is a downside to all of this sharing – Dribbble’s concept of a ‘shot’ often leads to designs which only look beautiful in a small, 400×300 pixels canvas. Good designers can become wracked with self consciousness if their design doesn’t look anywhere near as perfect as a final product on Dribbble. Ironically enough, the less glamorous design could be the right solution for a client and their customers even if it doesn’t win any design awards for Best Use of Flat Design on Buttons, or get voted up as noteworthy.  When we do see the perfect final version, we don’t get a feel for all the struggles which occurred behind the scenes. We don’t see the designs which were thrown out, and more disturbingly, few requirements or constraints (business or technical) are stated in a case study that accompanies that final image. Often there’s no case study at all – just an image, and people may see these final designs as solutions worth emulating. When designing more complex, enterprise transactional applications, is a simple, elegant, stylized shot found on Dribbble really the best source of inspiration? Should redesigns that focus on polish and the continual sharing of final products really be leading designers to late night bouts of existential anxiety?

How do other creative professions in technology – particularly, developers – deal with anxiety from creativity and comparing their work to others? What can designers learn from developers on how to feel confident with the sharing of their work? From the outside, developer communities appear to be less anxious and ultimately better prepared for the changes of being a professional knowledge worker due to a number of key practices about creativity which have developed as accepted standards. It’s not that designers and other professions don’t have the equivalent practices, but there may be a focus more on processes and practices in the building, and comfort in the ‘draft’ state rather than a focus on a final, finished, polished product. Some of the best developer practices when it comes to creativity include (in no particular order):

  • Pair programming as a practice: A core part of Agile development is developers pairing together to solve a problem. It’s not always a more experienced dev with a beginner – there’s an active sense of people who can be equally experienced working together through the best way to code. You can have two developers well versed in Ruby, who differ in how they construct code. There are often multiple ways to frame any solution, with no clear obvious direction. With pairing, you work through the options, put together multiple minds and find that best solution as you evaluate the options in real time. I’ve paired with designers before, and there is an active movement towards Pair Design as an initiative, but as a rule, it’s rare as an established, encouraged practice. There’s no reason why it should be, especially if multiple designers are working at the same company to help achieve consistent brand standards across products with multiple UIs. Smart companies have an active internal designer community, but in the education of designers, we rarely talk about pairing with individual designers as a practice – it’s usually one designer, and one product. Having an extra mind and set of eyes can help you see things that were missed the first time. I’ve worked with developers who sit with each other – different pairs on different days, and it’s what works for many of them.  Contrast that with the cliche of the Genius Designer silently sitting in the corner working away in his black beret. Perhaps pair designing might bring some of those solitary folks out of their shell and they will recognize the value of learning by collaboration. Maybe this will diminish the Genius Designer myth, too.
  • Communities of practice expressed in products, not just discussion: Developers have code repositories where hacking, experimentation and continual iteration are welcomed in addition to the usual forums for communication. Their tools are built out, languages created, and snippets shared on GitHub or other sites where the purpose is about sharing as much as an active finished product. Granted, it’s easier to share a code snippet than the outputs of a design especially concerning NDAs, and again, designers actively work to share their equivalent tool libraries, templates and pattern language libraries. With developers there’s a narrative that is unconsciously spoken – if you don’t like something and want to fix it, then just fork it, and make it your own. Customize it, hack it, tweak it, build it. We’re starting to see that with designers and developers building third party tools to work with Sketch and other applications, effectively building an ecosystem around the act of creating.  The sheer volume of activity on Github alone indicates that developers have beat designers to the punch, embracing the ‘building is part of being a community’ mission. Creativity for developers is building – constantly, and encouraging others to build off what they’ve done. Any hackathon is an expression of creativity and it can be astounding to watch that creativity happen. When we say ‘creative’, how often do we default to a painting, novel or dance performance? Perhaps we can see hackathons as another kind of performance where the code and collaboration are a dance that can be just as beautiful to watch.
  • Constant evolution of languages: This is a touchy subject, as the amount of coding languages and frameworks is exploding, and at a certain point there may be too many of them for any one developer to keep up with. Still, the amount of active development of new languages demonstrates how developers are constantly pushing the boundaries of what they can do with code, and exploring new ways to do it. Everything we once could do in Flash and Flex is now being replicated with CSS3. Our languages will continue to multiply as our interactive experiences online evolve, and as the devices and ways to experience a product continue to proliferate. As a career in development, it can be exhausting to constantly learn new languages, but as a form of art and creation, it shows people creating. Photoshop was a standard for so many years, and designers are only now in the last couple of years successfully evolving their languages and tools to meet the needs of these more complex and sophisticated products.  In creating new languages, the practice is less about comparing yourself to others’ output than creating something new for the sake of trying to solve a problem.
  • A commitment to continuous learning: As more languages, tools, and standards evolve in how we build products, the only constant in responding to change is adaptation and a commitment to learning. Continuous integration isn’t just about checking in your code – it’s about how we learn and keep learning, keeping our eyes open for what to learn, building upon your existing knowledge and seeing where the past and present apply to the future. Everyone – designers, developers, product, sales and more – has to commit to constant openness to learning and evolving one’s skills. But with development, that learning is embraced at a hyper accelerated rate. You may not need to be an expert in everything, but you need to have an awareness of what matters in technology, and for some concepts, at least a recognition that you have a gap which learning can address, and if you need to know about something quickly, the best source of learning is to start mastering it. Thanks to the always-in-flux nature of Web and development languages and practices, you always have to be actively learning – and there’s a potential for developers to be doing so online quickly.  It’s no surprise that there are more varied ways of learning development and computer science outside of traditional education – the rise of online education points to evolving how we learn, and that evolution speaks to how development addresses creativity, too. No surprise – the rise of the Maker movement has a strong tech focus at its core, and the message of the movement is a positive one. Anyone can be a Maker no matter their education or skills, as long as they’re willing to try creating.

No matter what the medium, creative people will always be strivers, dreamers, the people who crave more, who ask why – and often why not. No matter what the medium (paper and pen, keyboard, paintbrush, or whatever comes next in the future) striving is one of the passions which drives us to improve our craft and seek out new ways to design or develop the products and services that change lives.  The trick for creativity is to remember it’s not a race to compete with the Jones’s and the Dribbbles – it’s to start embracing your inner creative spirit and hacking for the sake of hacking.