InRhythm

Your partners in accelerated digital transformation.

Web Engineering

Practice What You Preach

As agile practitioners and thought leaders in software engineering, when we work onsite at our clients’ offices, it is important that we deliver our best. After all, as consultants, we are viewed as experts brought in with the expectation that we instrument and equip them with high velocity teams. In this regard, as we heard from our CEO, Gunjan Doshi, in last weeks Learning & Growth Newsletter, we are agile craftsmen. Our challenge is how we can balance learning on-the-fly while integrated onsite with our clients and managing their project expectations.

It is one thing to operate as a living lab when you are shielded inside the walls of your company’s office. With the right culture, mistakes will be expected and valued. When they result in a learning opportunity they ultimately drive a new insight into efficiency and judgement, however, when you are working onsite with a client, it can be an entirely different experience. Mistakes can result in injured productivity or be viewed as an inhibitor to progress and improving velocity.

Clients understand that software development is partly intuitive as much as it is scientific, and even masters of the craft will occasionally misjudge. Agile methodologies instill the mindset that we constantly iterate upon and improve our solution as well as our process. This not only holds true in what we craft, but also from within ourselves.  As agile craftsmen it is our responsibility to analyze our own efforts, understand and mitigate risks, decipher inefficiencies in complexity, and test and implement modern approaches, all on behalf of our clients. 

As each of us continues on our own path of learning, an opportunity to support each other within our living lab presents itself. We are a community traveling in the same direction. Such says the African proverb, “If you want to go fast, go alone. If you want to go far, go together”. We are bar-raisers and we travel together. In this sense, all of our clients can benefit from any of our thought leaders.

There will be times where we struggle. Perhaps, through a buggy release or during the release of a new product with unanticipated difficulty. We must take feedback with fortitude and cannot be afraid to pivot our strategies, evaluate new implementations, test and ultimately learn.

Learning by doing is often the best form of instruction. Agile craftsmen must recognize that failure is a part of the development process. As Robin Arzon would say, “Failure is the platform to which we build upon”. Often times success only provides validation and feedback is an essential aspect of agile development supporting the continuous loop through which we design, implement, test, and learn.

Earlier this summer, the much anticipated release of Apache Kafka 2.3, a vastly popular component in microservice architecture, enabling streaming and real-time processing of records, was met with its own challenges. One of the persistent bugs was related to the user unsubscribe functionality. This was obviously a critical part of their offering today given the growing requirements related to data privacy and simply an essential aspect of any offering to ensure customer satisfaction. I’m sure everyone will agree, in today’s modern service oriented technology landscape, that the customer is in control and products must incorporate their needs if they wish to remain in business.

It’s simply not easy to project our own living lab culture when onsite with a client. The pressure is already high to meet deadlines and each of our own efforts is codependent on others’ to execute and deliver. Another factor can be pride. Nobody wants to err and be labeled as the bottleneck.

So how will you manage to accomplish this? Observation and communication. Follow what the signs say in the subway stations and airports. “If you see something, say something.” This is actually universal advice and is highly applicable to agile development efforts. By remaining sharply aware of what you’re doing and how that work is impacting those around you, your sprint, project, and team, you will be in a better position to anticipate potential challenges and outcomes. You can then communicate these as you predict them or as they are happening so that you can work collaboratively with your client and your colleagues onsite to address them. Sometimes simply managing expectations can afford you the opportunity to make mistakes, and as we know, making them earlier saves future development efforts.

Failing is a part of the process and not having the visibility and foresight to identify and cross-communicate about potential issues creates risk and impedes high-velocity teams. Agile craftsmen are expected to be nimble minded, to think and learn fast. We are expected to err on occasion and it’s all about how we handle that situational awareness and how we are communicating to others so that we all learn and grow together.

The Magic of Service Workers

When we think about building modern web applications, we think about being online, about updating users with the latest news and offers. We think about flashy, and attractive animations. In the process of building a web application we often forget that the reality can be dramatically different. We are so busy focusing on the design, content, digital marketing that we forget one of the most important parts of keeping the website running – the users. In reality our users are located in various parts of the globe. They could be offline, or browsing on an old device using often flaky connection, or simply have limited data. How can we make sure that everyone has relatively the same experience using our product, no matter in what conditions they are using it?

What is a service worker?

If you heard of PWAs, you also heard of service workers, but what are they, how do they work, and what does it have to with anything?

A service worker is a JavaScript execution context that has its own event loop and node document dependency. In simpler terms, service workers are simply event driven JavaScript scripts running on their own thread in the background, separate from the browser.  They don’t have access to the DOM and they are not attached to a single page, like regular JavaScript files. Their main role is to handle events fired by the browser, or your webpage, and intercept network requests.

You can think of it as a gatekeeper for your network requests. Service workers have a total control over every request made from a website. Since they run in the background, they don’t need the webpage to be open. That gives them ability to listen and respond to events such as push messages sent from the server to the browser.   

How does a service worker work?

As we said before, service workers are based on JavaScript. Now, how do they do all that magic? Why would you want to add more code to your project? Why can’t you just use regular JavaScript file? Let’s consider two scenarios – a website with and without a service worker.

Scenario no. 1 – without service worker

You go to a website. Your browser makes a request to the server. The server responds with index.html file. Your browser parses through that file and makes additional requests to the server for the remaining files necessary to render the page. After the page is rendered you can enjoy using the website. You close the tab. What happens when you come back to that page? The process starts all over again. Now imagine that in the middle of that process you lost the connection. Bad news, once the connection is back the process will start all over again. Simply said, every time the connection is lost, the page is gone. If you don’t have access to the server, you simply don’t have access to anything.

Scenario no.2 – with service worker

You go to the website. Your browser makes a request to the server. The server responds with index.html file. Your browser parses through that file and finds service worker. The service worker is being downloaded, installed, and activated. Your browser continues making requests as usual, then renders the page. You use the page, and as usual, leave the page at some point. The process doesn’t seem any different, until you come back to that page. The logic behind service workers kicks in after it was installed and activated. With that being said, service worker won’t work until you return to the page after initial installation. From that point service worker will handle all coming and going requests. In the case that you lost connection, the page can still be loaded from the cache. The true power of service workers is ability to run in the background. This means that even if you leave the page, service worker will make sure that the content gets updated, and when you return, it’s ready to be loaded immediately. Imagine working all day and not using your precious phone. After work you get on the train, the connection is lost immediately and you can’t access any social media. Aha! Here comes a surprise. Your best friend service worker was busy all day preloading all new content for you. Now you can open your favorite page and be updated on what your friends ate for a dinner. How awesome, right?

Security concerns

What about malicious code running in the background of your phone hijacking all requests, you may ask?

With great power comes great responsibility. Using service worker, you can easily hijack connections, modify them, and fabricate responses. To prevent these malicious activities service workers can only be registered over a secure connection. You don’t need to worry about it during development process – localhost is considered to be secured. However, you definitely have to take care of the SSL certificates once your web app goes live. You can opt for paid or unpaid certificate. Should you decide to save some money on that step Let’s Encrypt is a free, automated, and open certificate authority.

Service worker lifecycle

Since service worker runs in the background, it has a separate lifecycle from the web page.  Let’s have a look at its cycles.

Registration

In order to use its abilities, service worker has to be registered first. You should be aware that service workers are fairly new technology, and they are not yet supported by all the browsers. According to caniuse.com the browsers that are currently not supporting service workers are: IE and IE Mobile, older versions of Edge and Firefox, Opera Mini, and Android Browser. Hence, before we register service worker, we should check if the browser that is currently used by our user supports service workers. In the case that service workers are not supported, JavaScript code will skip service workers, and continue running. If the browser supports service workers, and the page never had a service worker before, or the current service worker had been updated, the browser needs to fetch a new service worker, register and install it. Service workers don’t require user’s permission in order to be used. The user won’t be even notified of their existence.

Figure 1 main.js

Installation and caching

After the registration of a service worker is completed, it triggers installation process. This is a perfect time to pre-cache all of the resources needed for the shell of our app.


Figure 2 sw.js

Activation

Once the service worker has been installed it’s then activated. The service worker will now control all pages under its scope. You may now ask: what happens when after some time our cache gets outdated? The browser doesn’t know which cache we are going to use, but storing all outdated caches takes a lot of space. The activation process seems to be a great place to solve this issue.

Fetch and updating cache

After the service worker was activated, it can now control events such as fetch, message, and push events which occur whenever network request or message is sent from the page.

Termination

In order to save memory, the browser can terminate the service worker.  It will be restarted as needed.

Scope

When the service worker is registered, it will only handle requests within its scope. What it really means is that your service worker will only have a power over the scope that it is placed in. If you place the service worker in root folder, that service worker will be in control of all other pages. However, if your service worker is placed in a particular folder, it will then have control over that folder only.

What you should also remember is that any page can register a service worker, there are no limits to the amount of service workers, but once they are installed, they will be there forever, or until they are manually unregistered by the user.

Caching strategies

There are a handful of useful cache strategies, but choosing the right one always depends on the needs of your application. Let’s have an overview of a few of most common strategies.

Cache first, then network – if the request matches the cache entry, otherwise try to fetch the resource from the network. This is a great strategy for storing commonly used files such as components. However, you should be careful when using this strategy for the application data or resources that change often – you may get old data.

Network first, then cache – using this method you will try to fetch the resources from the network. If the network request is unsuccessful, the browser will try to fetch the resource from the cache. This is a good method to use for the apps containing a lot of fresh data, such as social media platforms, game leaderboards, or articles. This method guarantees that the network request for freshest data will be attempted, however it is unsuccessful, you will still see the old data. The major flaw of this strategy is that when the user has a slow or intermittent connection, they will have to wait either until the data gets loaded from the server, or until the request times out.

Cache only – using this method, your browser will try to resolve the request from the cache. If the resources are unavailable, the request fails. This is a great option for making sure that no network request is made, for example when you turn on save battery mode on your device.

Cache then network – this strategy is ideal for data that updates frequently or when it’s important to get the data on the screen as fast as possible.  Using this method, you would make two parallel requests – one to the network and one to the cache, then display the cached version first, and update the UI once network response arrives, unless the network data returns before the cache.

Progressive enhancement

Service Workers are a new technology, currently supported by Chrome, Firefox, Opera, and Samsung Internet (coming up in Edge and Safari). What happens if the browser that you are using doesn’t support them? The browser will simply ignore the part of code responsible for Service Worker and default to its natural behavior. Simply said, you won’t benefit from Service Worker, but it won’t break anything as well.

Push Notifications

What are push notifications?

Push notifications are messages that are ‘pushed’ from the server user’s device. They allow us to communicate with the users even if the browser is closed. The ability to reach out to users at any time gives us a is incredibly powerful way to engage with the user, bring them back to the application.

Structure

Push notifications consist of two building blocks: the Notifications API, and the Push API. The first one lets us to display the messages to the user, while the latter is responsible for handling the Push Messages received from the server, even when the app is closed. The Notification and Push API’s are built on top of the service worker API, which responds to push message events in the background and links them to the application.

Push API

Push messages meant to become notifications are sent from a server directly to the push service, and contain the information necessary for the push service to send it to the right client and wake up the correct service worker. This process happens even when the browser is closed and the service worker is deactivated. When the service worker receives the message, it wakes up to display the message and then deactivates again. However, if the user decides to interact with the notifications service worker wakes up again, this time to handle that user’s interaction.

Notifications API

This API is solely responsible for displaying the notifications to the user. This API uses the same mechanisms as native apps, giving the notifications a completely native look and feel.

Permission

Before the notifications can be displayed, the applications need to prompt the user with permission request. The user’s response is the stored along with the app, so when the user comes back, the window does not pop up again with the same request.

Background Sync

Background synchronization is a relatively new but very important feature, as it allows you to synchronize the data even if the user is offline. Let’s imagine, that the user started filling out the form while online. By the time the form was ready to be sent, the user was already offline. How frustrating it really is when at the end of filling out form you can’t save them, all the data is gone and you have to start over when the connection is back? Thankfully using background synchronization allows us to proceed with sending the data to the server. How does it work? You would probably think that we simply send the request, that request is stored in the cache until the connection is back, right? Unfortunately, you can’t cache ‘POST’ requests. So how do we do it then? We need to register sync tasks, in other words we need to tell the service worker that there are some tasks that require to be taken care of when the connection is back. But where is that data that we want to send stored in the meantime? IndexedDB is the best place to store the data requested to be sent. When the connectivity is reestablished the sync event fires, and the service worker executes all tasks it has stored. The beauty of this feature is that user doesn’t have to have the browser open – everything happens in the background!

Summary

Service workers possibilities are countless, and this article only touches on a few of them, but be sure that mastering your service worker skills and caching techniques will make your web apps reliable, fast and engaging whether your users are offline, online or using flaky connection.

Structuring and Serving PWAs with the PRPL Pattern


It’s been over 10 years since the release of the first model of the iPhone. Back then, most people had primitive mobile devices, limited mostly to making calls and receiving brief text messages. Anything close to decent was considered a pleasant user experience when it came to mobile. Nobody was concerned about the status quo, because nobody was using unstable mobile devices on a daily basis to browse through sites, make purchases, etc. (at least, not yet).

Over the years, however, a powerful shift has moved users’ primary point of entry from desktop machines with fast, reliable network connections to relatively underpowered mobile devices with connections that are often slow or flaky. Unfortunately, Google reports state 53% of users abandon sites that take longer than 3 seconds to load; the average load time takes up to 19 seconds on a 3G connection and 14 seconds on a 4G connection. Now you might ask yourself: right, but how does that happen?  Why does the page load take 19 seconds? I wrote some CSS, it is responsive, it should work! Here’s the problem: the UI looks like it works, but it doesn’t work in the real world. If you think about your mobile users, a good amount of them are still using median devices—the ones they receive for free with a new mobile plan, with just 1GB of RAM. They are a little (or even a lot) better than years ago, but still slow and suffering from poor connectivity.

There’s clearly a significant gap between today’s consumer expectations, the capabilities of their devices, and the mobile behavior of most sites. The patterns we have developed for building feature-rich web apps are just not sufficient for a mobile device user anymore. In order to create the best experience, the PRPL pattern can be key to improved mobile website development and user experience.

PWAs to the Rescue

When trying to ensure that a web app is suitable for a mobile device, most organizations develop responsive apps. It could appear as a great solution to our previously mentioned problem: the pages automatically respond to the screen size, UX stays consistent across all platforms, and we only have one code base for both mobile and desktop platforms. Unfortunately, this solution comes with some limitations. Responsive Web Design has clear network dependency; as soon as the connection is lost, your page is gone. If your connection is slow, you will automatically see layout and UI glitches.

Responsive Web Design is a fast and simple solution—it doesn’t solve all problems, but it does solve some of them, and quickly. It works best, however, when it naturally moves on to Progressive Web App. While PWAs are quite new and emerging, this architecture allows your app to inherit all main behaviors of RWD such as push notifications or GPS awareness, but also offers some advanced features. Not only is the app visible immediately after entering the page, but it also works better on a slow internet connection. What’s more, thanks to clever caching methods, your content can be visible and flawless even if you are not connected to the internet.

One of the ways to achieve that improved behavior lays in a pattern for structuring and serving Progressive Web Apps with emphasis on the performance of app delivery and launch. It’s known as the PRPL pattern: push, render, pre-cache, and lazy-load. It is not a specific technology or tools, but more of a mindset and a long-term plan for improving the performance of mobile web. The specific implementation of each of the steps is out of the scope of this article, but feel free to do additional research for more information.

Page Loading Process  

What does it take to load a page, from the moment you first open that page to the moment it’s fully loaded and you can interact with it? When you try to open a site on a mobile device, an initial request is sent to a remote server somewhere far away. After some time, the server brings the response, usually in the form of an HTML document. After that, your browser runs through the HTML file to check what other resources are needed; for each additional resource, your browser needs to make a separate call to the server in order to get that resource. You’ve probably noticed: that’s a lot of calls. How do we optimize that performance?

Push Critical Resources

Not every file in your application has the same level of importance. Browsers know this, and using their own heuristic they are able to decide which files they should be fetching first. It’s useful to also tell the browser which files are more important to us. There are multiple ways of preloading critical resources faster. Some of them include rel=”preload” and rel=”prefetch”, however you may also want to explore webpack options. It may be useful to keep in mind that prefetch is better for getting ready the resources needed for different navigation routes.  In general, both of these methods allow you to mask the initial latency by preparing the resources that are important but usually take some time to load. This way your browser reads through HTML and instantly warms up the connection with the source, so by the time the browser got to the last line of the HTML file, the resource is ready to be rendered.

Render the Initial Route as soon as Possible

Providing basic user experience as soon as possible is critical when it comes to convincing users that the site they entered is worth staying on. How does it feel when you open a site that starts loading, and the only thing you see for the next 15 seconds is a blank screen? I always ask myself: is it loading? Is my connection not working? Maybe it’s my phone that is not working? Downloading and processing external stylesheets is probably blocking the content from being rendered until the whole process has finished. That creates an opportunity for improvement.

There are some parts of an application that can be pushed earlier to provide some basic user experience and assure the user of the loading progress. One method is to extract styles responsible for minimum initial rendering and inlining them in the HTML document. You can either implement that solution yourself or use already existing packages such as critical package. This way the browser would be able to render the styles right away.  Another approach to improve first paint is to server-side render the initial HTML of your page. This displays content immediately to the user while scripts are still being fetched, parsed, and executed. However, this can increase the payload of the HTML file significantly, which can harm the time it takes for your application to become interactive and thereby respond to user input. There is no single correct solution to reduce the initial load of your application, and you should only consider inlining styles and server-side rendering if the benefits outweigh the tradeoffs for your application.

Pre-cache Remaining Routes

As you probably already noticed, minimizing server-side trips can be crucial in the process of shortening page load time. Here’s where the service worker really shines. Using a service worker cache allows you to store the resources that make up the shell. On repeat visits, your browser can fetch assets directly from the cache rather than the server. This way your user will not only be able to use your application offline, but also enjoy a much faster page load. You can either create the service worker file and write the logic yourself, or use libraries such as Workbox that can make this process easier.

Lazy-Load

We’ve arrived at the moment when all of our assets are finally delivered by the server at the speed of light, but the initial paint is still slow; what’s taking so long? Almost always the most expensive asset happens to be a JavaScript bundle. From the moment it gets loaded to the moment the UI gets fully interactive, your browser goes through a few phases: it has to download the files, parse through them, compile, and finally execute. In simple terms, after your browser’s received all the resources, it now has to compute what all the files combined together look like, and how they work together. The bigger the bundle you ship, the longer it will take for the browser to parse through it and put it together.

What does it really mean for the user? Shipping a large bundle of JavaScript can significantly delay how your user will be able to interact with UI components. That means your user will be tapping on the UI without anything meaningful happening. The previously mentioned phases don’t take a lot of time on a desktop machine, but on a median mobile device, it can take forever. So how do we manage to quickly load the rest of the code necessary for the application to run? Should we just load the entire code all at once?

Instead of providing users with all of the code that makes up the entire application as soon as they land on a site you could split the code based on used routes, otherwise known as code splitting. The idea behind it is to give the user small chunks of the code that takes the currently used route. As the user navigates through the site, the browser makes additional requests for more of the fragments of code that haven’t been cached yet, and creates required views, known as lazy loading. This is another feature that you could implement yourself, but it may be worth it to use existing packages and plugins instead, such as an aggressive splitting webpack plugin.

Summary

Nowadays, through improvements in Internet browsers, the expectations toward mobile websites are set very high. The purpose of the first websites over 20 years ago was simply to share information; these days the Internet provides everything from grocery shopping, maps, real estate, social networks, chatting, tickets…everything. If you are hoping for maximum engagement from your customers, improving their mobile experience by delivering content fast and reliably may be the way to go.

 

InRhythms engineers leverage their passions to provide the best user experience for large-scale enterprises leading their fields. Subscribe below for the latest in thought leadership, or reach out to see what our rapid development strategies can do for your latest project.

Shape the Future of Web Engineering with Us

My relationship with InRhythm began about 4 years ago when I did a Node.js workshop with the team. I was impressed at how the CEO, Gunjan Doshi, kept in touch, regularly checking in with me over the subsequent years. When the opportunity to collaborate happened, I jumped at the chance.

By then the company that had grown in size to nearly 150 consultants. Approximately 50 of those are web engineers; in my role as the Web Practice Lead, I work tirelessly to supply this team with mentoring, tools, connections, and anything else they need to succeed. I do this with the aim of preparing engineers for opportunities after InRhythm when what they learn here brings them success there. We maintain long-term relationships with our people after they leave because we’re genuinely invested in their career success. The strength of that community is what sets us apart.

JavaScript is eating the world of software and there’s no doubt that web development is going to continue to grow and expand in complexity. The continued acceleration of innovation in the Web sphere—from React to WASM—is an incredible validation of the field. Anyone using a phone or a laptop or a tablet is using software a web engineer built.

For me, Web Engineering is the most exciting type of software development, unlike any other—multidisciplinary, blending the hardest engineering problems with design-based thinking. A full-stack web developer might work on an AI algorithm and its human interface on the same day. I regularly receive calls from teammates working through a new perspective on an old idea, reminding me of just how innovative the practice of Web Engineering remains.

When you join the Web practice you’ll join a team that works on some of the most advanced systems in the world, with some of the largest organizations in the world. I’m amazed when I learn about the incredibly exciting and complex software our team is building. It’s my job to ensure that they—and you—are ready to learn and grow in that environment. As we look toward the future of web engineering, it benefits our company and our consultants to stay in the know.

All of this knowledge culminates in InRhythm University, a learning and growth program developed through inter-team collaboration and client outreach. The InRhythm University curriculum is comprehensive, and in keeping with our company’s mission everyone who joins InRhythm gets this education for free. Check out an overview of the kind of curriculum we offer for our consultants to take their skills to the next level:

Section 1: Computers!

Space and Time: Big O Notation

You cannot excel as a developer if you cannot state clearly and scientifically the cost of your code in terms of space (memory) and time (how long will your function take given 1000 items? How about 1 billion?).

Bits and Bytes: Bitwise Manipulation

Developers push bits and shove bytes around. You probably know about flipping bits between `1` and `0`, and what it means when someone says “megabyte.” Do you know why 1^1 === 0? There are a lot of powerful ideas to apply once you do.

Concurrency

Looking to learn more about using generators, callbacks, Promises, async/await to manage asynchronous workflows with JavaScript? Good! Managing concurrency is perhaps the most important concept to learn when building on modern systems. You’ll need to master it. We show you how.

Functional Programming

You don’t have to learn Haskell to understand functional programming. You can use JavaScript right now to engage with the extremely powerful ideas present in functional programming flows. You’ll learn about pure functions, side-effects, immutable data, and (probably) become a better programmer.

MVC and Classic OO. Bonus: How JS prototypes fit into this.

Can you easily describe the difference between prototypal and classical inheritance OO ideas? You should. You will. By modeling complex scenarios in both paradigms you will learn the pros and cons of each approach, and more importantly, learn how to choose between them.

Data Structures and Algorithms

Software engineers are largely becoming data engineers. Managing application state, immutable or otherwise, is no longer something other people worry about. That means you will need to understand the kinds of data structures and efficient mutation algorithms the smart people in the CompSci room have developed to help us do our jobs.

Trees and Graphs

Folders and files. You know about those kinds of trees. If you’ve used an outliner someone wrote a graph traversal algorithm for that; you’ve probably written one if you’ve ever walked a directory. Ever use Bitcoin? Here we focus on these specific data structures. This is one of the most powerful, and frankly fascinating, pure computer science topics every engineer should get a handle on.

Section 2: The Modern Web Stack

The DOM

No matter how elegant the abstraction of your build pipeline or transpiler or template system is, what it produces is always going to be the same: HTML, JavaScript, and CSS, all linked together within the Document Object Model that your browser or other Web View must process and render. If you do not understand, at a deep level, what is happening when a DOM is built or updated or otherwise modified you, fundamentally, do not understand Web Engineering. Those who master this section do.

Deep JavaScript

Time to dig into the docs. No, really. We’re going to go through the fundamental ideas that power the JavaScript language. You’re going to learn about execution contexts and scopes, and how and why those exist, to create the JavaScript language that we’ve all come to know and love.

Deep Node

JavaScript is on the server now, have you heard? It’s true! NodeJS frees up all the skills you’ve learned about events and event loops and gives you superpowers on the server. Want to write a command-line tool to do automatic deploys? How about building a text parser that powers a chatbot? How about building APIs used by dozens of teams spread across the globe speaking multiple languages? This is the beginning of the path to going full-stack.

Deep React

Time and time again our clients come to us and ask for modern React engineers. We have some of the best. We even do workshops with companies to level up their teams. You’re going to get to the level they want to reach by working through this section.

Debugging and Testing

Did you know that you can link a Node server to DevTools such that you can debug live code and even trace performance of your server code down to the function level…in your browser? Know the difference between unit tests and functional tests? Still using console.log for everything? There are options. You will learn to effectively test software and squash bugs and your life will be better for it.

The Network

Do you know what happens when you enter a URL into a browser? Do you read network packets when debugging API failures? When is a REST architecture appropriate? Cookies or tokens or something else for identity management? Access management? When is caching appropriate, and what is latency anyway? You must burn this knowledge into your bones if you are to build modern, distributed systems. Let’s get started.

Forward!

Every graduate of IRU has mastered the technologies and techniques that we know work at the highest levels of industry through continuous repetition of this process. The IRU program teaches students actionable skills through real-world scenarios. Using proprietary internal development tools, IRU simulates realistic client problems (not half-implemented “TODO” applications or “Hello World” demos) which students work through under the guidance of our senior trainers. Our engineers are given the thinking tools they need to:

1.  Intelligently analyze complex systems to find weaknesses and inefficiencies.
2.  Create a range of solutions and intelligently determine both the right solution and the right success criteria.
3.  Model and test the solution in collaboration with all stakeholders to validate the solution
4.  Analyze the results, measure against success criteria, and restart the process on failure.
5.  Standardize success into repeatable guidelines and share that knowledge with all stakeholders
6.  Repeat this process, without fear of revisiting old successes (the status quo).

The responsibility of transforming digital businesses requires earning buy-in for change from our clients and consultants. At InRhythm we empower the creativity of our people—we don’t accept the status quo. Perfectionism is not our goal; continuous improvement is. We believe in adaptive change, especially when it comes to growing the careers of our consultants. I am similarly focused on ensuring the growth of those in my practice, both as engineers and colleagues, to make us all better representatives of InRhythm and our industry.

Ready to take your skills to the next level? We’re hiring. I hope to hear from you soon.