Core Properties of Your Software

Fri, 25 Jan 2019 00:00:00 +0000

As engineers, when we discuss how to build a new piece of software, it’s often useful to try to answer the following question: What are the core intrinsic characteristics that our system needs to have?

Why do we need to ask this question? Software architecture is a lot about choosing one approach over another or, in other words, it is a lot about making compromises. The overall quality of your software will heavily depend on the compromises you made early in the process.

Think of it this way: let’s say you’re going to climb a mountain and you’re packing your backpack. What are the items you’re going to take with you? Warm jacket - essential. A stack of books from your home library? This can significantly slow you down so better to leave them at home. A pair of hiking boots? Certainly! An umbrella? There’s likely a more convenient way to deal with rain in this case.

You can’t have a software system that is extremely fast, secure, reliable, flexible, portable and simple all at the same time. You have to lower the bar around some aspects while meeting your core requirements.

For example, I would very much like my bank to ensure my digital accounts are properly secured whereas I can tolerate its mobile app being a bit slow sometimes. On the other hand, I wouldn’t expect their promotional webpage to require me to use multi-factor authentication in order to show me mortgage rates, it just needs to present information in a clear and accessible way.

When deciding on intrinsic characteristics of a software system it’s sometimes helpful to know “what’s in store” - have in front of you a list of those that you think about often. You can even go through the list and ask questions like “Do we care about this?”. If the answer is “Yes”, then you could dive deeper and form concrete requirements. If the answer is “No”, it’s helpful to elaborate on why you don’t necessarily need your software to have that kind of property. And actually, regardless of the answer, I highly recommend capturing the “why” - it’s going to save you a lot of time down the line (especially when your system is mature and went through a few large iterations, people might start questioning it’s core properties and have the initial rationale written down and readily available is going to help with re-assessments).

Here are some items that I try to keep in mind when going through design phase:

Correctness

This might surprise you but sometimes it’s enough for your software to be only approximately correct. For example, sometimes having highly-performant program which gives correct results in 80% of all cases is much-more desirable than having a slow program which is correct 90% of the time.

Security

Do we store sensitive user data that we need to protect? Do we need to require authentication to access certain parts of the system? Are there different types of users that we need to treat differently? Do we need extra security given how we distribute our software (e.g. a mobile app which is on user’s device)?

Performance

Everyone likes it when software runs fast but sometimes you need to prioritize other things over raw performance. What is the nature of operations our program is performing? Should we optimize for reads or writes? Do we need to think about improving perceived performance (i.e. parts of the screen loading independently which allows the user to interact with an app before things fully load)?

Scalability

Related to performance, here you’d want to understand how you’re going to handle increasing system load (which might be based on the volume of requests, input/output data size, etc.). When we reason about approaches to scalability, often we consider horizontal (have more machines) and vertical (have more resources on each individual machine) scalability as some of the quick wins that can be taken.

Portability

Do we need to support multiple platforms (e.g. PlayStation and Xbox for games)? If the new platform is released tomorrow, should we be ready to support it (e.g. a new mobile operating system)?

Simplicity

Here it’s useful to think about the “cost of change” as a measure of how complex, time-consuming and risky it would be to introduce new changes to the system. When talking about user interfaces, we may want to choose one UI framework over another simply because it’s easier to use it (although, it might not be as powerful) and we have good knowledge around it. When looking at the back end, loose coupling and fine-grained components help with this quite a bit.

Extensibility

Here the main question is usually: should we allow altering functionality of our software with the logic that has not originated from our software (e.g. plugins and various extensions that take advantage of multiple extensibility points)? Depending on the degree of extensibility you may end-up with quite complex system so watch out for this one.

Accessibility

This is more applicable to user interfaces and behaviors. It’s often a good idea to ensure your software is accessible to various categories of users (e.g. people with disabilities). Although, sometimes you might be designing something that is targeting a very specific persona (e.g. building a sonar with haptic feedback to help visually-impaired people navigate their surroundings).

Safety

In some cases you need to perform extra due diligence to ensure your software is safe for people to use. For example, when designing a program that controls an industrial press machine, you probably want to ensure an operator can’t accidentally activate it (which, in turn, may cause damage to other hardware or an injury to a coworker).

Hope this helps. If you have any questions, feel free to ping me on Twitter (@volpav).

Happy building!

Building Cloud Platform At The Bank

Wed, 12 Jul 2017 00:00:00 +0000

Distributed computing is hard to get right, as long as your system consists of more than just a web server and a database. Now, I can go and leverage tools like AWS, Azure or GCP and this engineering challenge becomes much more approachable. But what if I’m in a closed ecosystem such as a bank (of course, a result of being highly regulated and having strong controls in place to manage customers’ money)? Well, it wouldn’t be that bad if banks weren’t known to be slow, dated and inefficient when it comes to their tech (although financial institutions like Scotiabank have begun to change that image in the last couple of years). Modernizing a bank? It’s definitely an interesting journey with many learnings so let’s take a peek.

Problem Statement

When I came to Scotiabank last year, I joined a brand new department. Our ultimate goal was to help make this organization a true technology company, modernizing what exists and paving the way for rapid innovation (while meeting the requirements of regulators and maintaining the confidence of our customers). The challenge that I was given was one of the most ambitious: to help standing-up a general-purpose cloud platform that would allow application teams to care less about infrastructure and focus on creating amazing experiences.

Getting Started

Now, where do you even start? So many different things come to mind, for example:

The system needs to be reliable, secure and performant;
It needs to integrate nicely with existing tools and processes;
There needs to be a team that will maintain it as well as support its users;
We need to “sell” it to developers, get them excited, train them if needed;
…

Despite all the great thoughts and ideas that are circling inside your head, what you should start with is: figure out what already exists and why it doesn’t work. You don’t want to be building this platform just because the word “cloud” is so trendy these days. On the other hand, stories like “it takes us a week to do a deployment” or “we have no good way of debugging this code in production so we just restart our JVMs every night” or even “we can’t use Node.js because the internal ecosystem for it pretty much doesn’t exist” - these should be music to your ears, it’s something concrete you can work with!

Let’s now consider three classical aspects: people, process and technology.

People

This department is striving to hire the best local talent. We wear no suits and we stay away from internal politics. Our mission is of a cosmic scale yet we try to stay laser-focused. We’re looking for great thinkers and problem solvers who have diverse experience with today’s technology. It’s true, though, that it’s somewhat difficult for us to attract talent: hearing the word “bank” sometimes makes the opportunity seem far less attractive than it really is.

In every interview that I conduct these days, I always mention that, in regards to what we do, as much as it is a technology challenge, it is also a people challenge. Take this company’s average software developer: you’re most-likely looking at a person who has spent quite a few years at this bank, who knows his or her abilities and limitations (as a technical expert), who has an established way of doing things. When it comes to modern technology and cloud in particular, these individuals may have very limited to no experience with it. So how do you bring them along to this new reality? How do you educate them, and how do you turn them into your biggest advocates? You don’t want to just tell them exactly what to do - rather, you want to give them the right tools and help them realize the full potential. Then, observe the magic as it happens.

Process

When we started this, I don’t think anyone on the team truly realized what we were getting ourselves into when it comes to working with existing processes. Yes, some of them do make a lot of sense (for example, application’s cryptographic material is managed by a dedicated team). But how about the ones that clearly seem outdated, overlapping or redundant? And what about those that are just too slow, requiring a lot of manual effort?

The approach we’ve taken was: challenge everything and educate respective owners. With this in mind, it’s important to understand why things are the way they are and how it needs to work instead. Truth is: this is your reality so the sooner you learn how to navigate it (and later, make alterations to it) - the greater results you’ll be able to achieve, quicker.

Technology

This was (quite obviously) the most interesting part for me. Some of the biggest challenges we were encountering throughout the way were related to (surprise!) security. Now, just to make it clear: we’ve set up the platform on a public cloud and there’s been a lot of work done to make sure all of it is highly secure and compliant with the right policies.

But at the end of the day, to an organization that’s heavily regulated, it’s understandable that anything that is not inside a private data center has historically been considered non-secure by default. While management says they want to change this, established processes run deep. The implication of this? As mentioned earlier, we worked closely with our reviewers to help them understand: “there’s nothing to be afraid of in this case”. Yes, other times it really felt like trying to fit a square peg in a round hole and we had to compromise on a few things. But if you look at it holistically (and take into account that what you’re looking at is not the final state of the system), we managed to get to quite robust implementation (and not just in terms of security).

From the automation aspect, what we’ve achieved is having the following in place:

Project-related: requesting a developer account, provisioning a sandbox environment, managing your team’s access to the project;
Capacity-related: auto-scaling policies, “disposable” environments;
Deployment-related: ability to release new code daily, while meeting all of the existing control objectives (including code quality, security and audit);
Infrastructure-related: on-demand services (e.g. cache), elastic runtime that requires no upfront provisioning or configuration, upgrade and backup pipelines;
Delivery-related: thanks to all of the above, the process around obtaining production readiness sign-off for a new application is now much smoother since a lot of things are already covered;

Where We Are Now

The active work on building the platform started in December, 2016 and by mid-May, 2017 (roughly just 6 months after) the platform was live. At the time of writing this post we have a number of applications running in production and serving real customers. We also have:

Highly-available cloud platform with good support model in place;
Rapid CI/CD pipeline allowing application teams to push their code into production on a daily basis;
Comprehensive onboarding and training process and a team of engineers ready to help;
Validation that what we imagined when we started this journey is possible and that this company is truly committed to transform itself technologically;

(on the picture above: celebrating first application’s production launch)

What Is Next

The work has already been started on the next iteration of the platform, making it even more reliable and secure, offering more services and expanding our user base. If you want to be a part of it (and, as I mentioned, there are other cool things that we’re working on at this department) - shoot me a message and let’s talk!

Sprites is Now Open-Source

Mon, 10 Oct 2016 00:00:00 +0000

As some of you may’ve heard, back in May I’ve made a tough decision to shut down Sprites after almost two and a half years of working on it. I’m now excited to announce that the complete source code of the app as well as all the related services have been open-sourced and are now available on GitHub under “Sprites” organization.

Points of Interest

There’s “Architecture and Design Notes” document which will give you a good overview of how the software is structured and what are some of the tools and libraries that were used (and why). There’s quite a few pieces that can potentially be reused (e.g. the whole rendering engine, support for live data feeds, voiceover support, etc.).

One of the greatest features is support for video export. There’s a native component that enables this - I encourage you to check it out, it’s somewhat generic and there’re some good notes on how it works.

What’s Next

I hope you can find some use in the source code. If you have any questions - don’t hesitate to reach out to me and I’ll clarify anything.

Caching HTTP Responses With Angular

Wed, 26 Aug 2015 00:00:00 +0000

I came across a nice little challenge the other day: we noticed that our Angular application can sometimes be a bit too chatty with our backend so we’ve decided to eliminate some of the unnecessary (redundant) API calls by caching initial responses on the client. Changing application logic was not really an option at that time so I tried to see how this can be done with the help of Angular middleware of some sort. Surprisingly, Google yielded no suitable solution, so I came up with my own which I’d like to briefly describe in this post.

The Idea

The idea is to have an HTTP interceptor which uses the return value of URL.createObjectURL method as a substitute for the actual request URL so that instead of making a trip to the server, the user agent would instead load in-memory data.

Let’s see how the above can be implemented.

The Implementation

First, let’s define a skeleton for our HTTP interceptor:

As you can see, we’re relying on browser’s support for “URL”, “Blob” and “WeakMap” APIs (we are pretty ambitious/experimental with the latter one - this is mostly for code clarity, though, and so this dependency can easily be eliminated). If there’s no support for a particular API, there will simply be no caching involved and no errors will be thrown.

Next, let’s take a look at the high-level implementation of the interceptor hooks:

The logic is the following: if on HTTP response we can find a corresponding cache rule, we’d store the response data internally so that on HTTP request if the data has already been stored for to the given rule, we’d point to that data instead.

Now, let’s take a look at our cache rules:

We are pretty naive in a sense that we try to match the URL completely when we are being asked for a cache rule that corresponds to a given HTTP request configuration. That is okay, though - often, this is exactly what you’re looking for (and it was enough in my case so I decided to not over-complicate the code with unnecessary functionality like matching by pattern). Also, our “logout” rule has an “onInsert” handler which we use to actually invalidate the entire cache when the user logs out of the system.

Finally, the part that deals with the actual caching looks like the following:

The most interesting part is the “set” method which makes a use of URL.createObjectURL method for making our data available via in-memory URL (and what we store ourselves is just this URL).

Here’s how to register our interceptor:

That’s it! The full source code is available here: Caching HTTP requests with Angular.

Conclusion

By using an HTTP interceptor we made sure our caching layer is pluggable and can be taken out at any time with zero impact on the rest of the codebase. Also, I find the use of object URLs to be pretty elegant solution in this case (although, please, do let me know if there’s a better way of implementing request caching).

How I'm Building Sprites

Sun, 22 Feb 2015 00:00:00 +0000

It’s been more than a year since I started working on Sprites, a tool for making infographics and online presentations. This post is about how I’m building the product as a single engineer/designer.

At a Glance

I started working on Sprites back in September 2013. The early prototype has seen light in February 2014, in May I announced a public beta and the “version 1” of a product was released in September 2014. Right now we have over 10,000 users and we grow about 10% a month. We’re not profitable yet but plans are big and we believe that we’re moving in a right direction.

We are currently a team of two (Denny is responsible for all the sales, marketing and PR). I’ve personally designed, implemented and continue to maintain 99% of the system, even though I’m looking forward to get some help with all this.

Quick note about the application: it’s a single web node which is hosted on Azure. We’ve recently become members of Microsoft BizSpark and so I’m very happy that we can leverage Azure without too much worrying about our monthly bills (being able to use tools like Visual Studio for free is such a great perk as well).

Technology

Since the majority of my professional expertise resides around Microsoft technology stack (particularly, .NET), it was an obvious choice for me to use this company’s tools for building Sprites. Now, I do like to explore other universes like Node.js, Scala, Rails and even a little bit of PHP but this time I had a different plan: to make something concrete, useful and functional without spending too much time learning (and fighting) the new framework, library or an IDE.

Frameworks and Tools

Sprites is an ASP.NET MVC4 web application with the back-end written in C#. It’s a fairly standard set-up if you think in terms of middleware and an asset pipeline: I use default minification and bundling mechanism, the UI is just a bunch of partial Razor views and I don’t even bother loading them on-demand (it’s all still quite lightweight so I’m not worried). For interactions with the client-side code there’s a number of WebAPI endpoints (more on that later).

On the front-end I use LESS for managing all the styles as well as TypeScript for all the client-side application logic. Now, it’s worth mentioning that I’m super-happy with how TypeScript makes it possible for me to write more robust and efficient JavaScript, faster. On top of all the great features it has (like modules, interfaces and inheritance, generics, etc.), there’s also an amazing support for it in Visual Studio (great IntelliSense, “Go to definition”, refactoring, auto-generation of source maps). I’ve been using TypeScript on a number of projects, large and small, and I never regretted the choice.

As for the JavaScript frameworks being used, the editor is built with Knockout. Not because it’s is my favorite MVVM implementation but again, mainly because I knew it pretty well. I also wanted to start with a bare minimum, not introduce unnesesary complexity and not import stuff that I won’t need (speaking of Angular or Ember - definitely good candidates but felt to heavy when I was starting). I also use jQuery here and there, Moment and a coule others. The rest if completely custom (based on a concept that every piece can be reused which I later hugely benefited from when implementing real-time collaboration).

Database

When I was sketching the data model and the overall flow of an application, it felt like NoSQL would do the job quite well: the entities were somewhat complex and so it made sense to represent them as graphs or documents, I needed fast writes for the good editing experience, I knew my models will evolve fast and so I wanted to avoid RDBMS enforcing any kind of schema, I wanted to use LINQ but I didn’t want to use Entity Framework (largely because it felt like shooting birds from the cannon).

I made some research and decided to go for RavenDB. I chose it because it’s written specifically for .NET, very easy to set-up and painless to use in a default configuration, fully transactional, with configurable consistency model. For the record, I did use MongoDB on my previous startup, but was left with mixed feelings (its incredible ability to loose data even when there’s almost no load on the system, was making me furious sometimes). I also wanted to try Azure DocumentDB but found the pricing a bit too expensive.

API

As I mentioned, since the entire UI gets loaded when you open Sprites editor, there’s only data that flows between the client and the server as you work with the tool. For this purpose I’ve created a number of WebAPI endpoints (again, fairly standard configuration). In order to make an API a bit more secure, I first made sure I only communicate through the SSL (my personal opinion is: why wouldn’t you want to use SSL on your website when it’s so cheap these days and also considering how other people and organizations invade into people’s privacy). Next, it’s all behind Forms Authentication which is driven either by standard username/password combo or via OAth (I’ve used DotNetOpenAuth). I’ve also implemented a sort of gate keeper which would check every incoming API request by examining its type, HTTP headers, cookies as well as a special, short-lived token (re-issued every now and then). If the request is note sane, it’s discarded. Now I think this gate keeper was a bit of an overkill but back then I didn’t want people discovering the API to abuse it so I’ve tried to make it a bit more secure.

Background Workers

Sprites uses a number of background workers for things like email dispatching, video publishing, export, etc. These workers are currently implemented as Windows Services (I’ve used WCF boilerplate). The communication between the application and the worker is organized by using queues to make it all a bit more scalable. I have my own tiny implementation and I use Amazon SQS for some of the stuff. It all works quite well.

Design

I don’t have a degree in design and I never studied design but I truly enjoy designing things myself. I’m not ashamed of saying that I borrow a lot of inspiration from other people. I don’t blindly copy the work of others though, instead I’d learn how the particular piece is done, why it’s done this way and then maybe try to implement something similar. I love all the aspects of web design in particular: how the main blocks are positioned, the choice of colors and fonts, the flow of an application, the user experience. I respect (and try to study) good copy-writing and I admire clear communication, pithiness and ease of use.

I design everything myself. Mostly, because I can but also because it’s hard for me to express to other people how I want this particular element to look like and behave and what kind of emotions it should trigger. But don’t think that I’m a rare species, a software engineer who can also deliver a visual aspect of a product. It’s been a long way of trials and errors and my first projects looked really ugly comparing to how I though they were looking.

Delivery

As a startup, you need to be able to iterate quickly, delivering new features, bug fixes and other updates at a rapid phase. You need to consistently tweak your market fit, you need to please your early adopters, you’re too unstable to practice long development cycles.

I release new versions of Sprites several times a day. For now I don’t use any sort of continuous delivery (I’d go for Octopus Deploy, though). Instead, I use Web Deploy and just release from within Visual Studio. It’s super-convenient, fast and very easy to set-up.

Working Overnight

It’s worth mentioning that I also have a full-time job. With this, I can only work on Sprites during night time and sometimes on Saturdays, so I have to maintain a high level of self-discipline and motivation: I don’t play video-games, I rarely go out, I get up at 5:30 am and I exercise at the climbing gym three times a week. Generally, I try to follow my own productivity tips but here I’m just saying that it’s very possible to combine the sort of things I mentioned (startup, full-time job and a few other bullet-points), you just need to prioritize stuff a bit more carefully.

Meetings and Tasks

Meetings should be short, concise and on-target. I try to do a weekly live meetings at a nice indie coffee shop and I use Slack and Google Apps for Business for any other occasion.

While Slack is a perfect work chat, I use Trello to track all the tasks. Those that are product-related and involve writing some code, eventually become GitHub issues (I’d mirror Trello tasks in GitHub because it’s a nice way for me to track code changes in relation to an actual task but at the same time it’s much better to have a central place for all the work-related activities planned, whether this involves development hours or not).

Conclusion

I’ve touched upon several aspects of me working on Sprites and I hope my overview was clear and useful for some. If you have any questions, feel free to ask them here or shoot me an email at volpav@gmail.com.

A Few Tips For Staying Productive

Tue, 15 Jul 2014 00:00:00 +0000

People sometimes ask me how do I manage my time considering all the different things that are currently happening in my life: normal full-time job, one side project, another a bit more serious side project, consulting initiative, sport and few other things. I thought it’d be beneficial for some if I share my experience in trying to squeeze as much as possible from each day with minimum risk of burning out.

Prioritize Ruthlessly

One of the most important aspects of my daily routine is ruthlessly prioritizing all the things that come to my plate. This is achieved by setting your short-term (long-term) goals and demoting everything that has nothing to with those (of course, there are exceptions to every rule, but let’s not consider them for now). Does this email really require immediate response (hint: it almost never does. If it did, it wouldn’t have been an email, it would have been an IM message or a phone call)? Do I have to attend this meeting when I’m in a middle of solving a technical challenge (another hint: avoid meetings at all costs - in 99% of all cases meetings are pure time-killers). Do I have to buy a new laptop whereas my 6-year old one works just fine and instead I can spend this money ordering a couple of VMs from Amazon to enable new features for my customers? In general, I think it’s a good practice to always ask these questions whenever something appears on your horizon:

Does this align with my current goals?
(if answered “Yes” to the first question) Do I have to take immediate action on this?
(if answered “No” to the first question) Can I throw it away and if I do, what are the implications?

Depending on the answers to above questions, it becomes much more clear what goes in (and where should it appear in your to-do list) and what falls out.

Value Your Time

This often involves saying “No” to other people and I know that for some this can be a hard thing to practice but trust me - at the end of the day you’ll thank yourself for not wasting time on things that don’t really matter. You need to remember that your time is the most valuable asset you have and the way you use this asset directly impacts pretty much everything in your life. For example, I don’t play video-games because I always feel kind of empty after half an hour spent not doing anything useful (if I want to have a break from work, I’d rather go out to have some fresh air or watch a documentary). I also choose carefully what movies to watch and what books to read because I’d like not only to entertain myself but also to maximize the value I get from spending time this way.

Work Smarter, Not Harder

We all know that working 12-hour a day won’t bring you any good. Yes, there are times when you need to have a short “sprint” but don’t make it a daily habit. Working more hours doesn’t mean you’ll be achieving more. In fact, you’ll be achieving less over time because the emotional baggage and the fatigue will wipe out all your productivity. Instead of pushing yourself towards the burnout, make a small plan for every day. I’m not a fan of maintaining to-do lists so I just plan a small set of tasks in my mind every morning. Keeping the list small helps me to remember it and also makes it possible for me to actually cross off all the items I planned for a day. Having this sort of daily thinking also helps me to evaluate tasks before I get to them so by the time I’m actually starting working on something I already know what am I going to be doing during the next hour or so (for example, thinking about how to implement a particular Sprites feature during dinner eliminates the need to “pause” the execution when your fingers are already on the keyboard).

Get Up Earlier

Average adult needs around seven hours of sleep but we all know that there are plenty of people who manage to sleep less (or sleep differently). For example, Marissa Mayer is alleged to sleep only four hours (I hope this is not the reason she overslept her meeting during Cannes Lions advertising festival in France) and some people like to take a nap during the day because this makes them more productive. As for me, I like to get up early (around 6 AM during the week) because I found out that I’m usually much more productive between 7 AM and 10 AM comparing to the rest of the day. This is especially the case with my current place of work: it’s an open space so when it’s early in the morning and there’re no people at the office, there’re no distractions and I can stay focused longer. It was hard getting up that early at the beginning (especially if you go to bed at 11 PM or 1 AM) and what I was doing to exercise myself is I was shifting my alarm clock to wake me up 15-30 minutes earlier every month (for example, 8:30, 8:00, 7:45, 7:30 and so on). Try this technique and see if it works for you. As a general advise, you probably don’t need seven or eight hours of sleep - your body just got used to this schedule but it doesn’t mean you can’t change it (and bring more productive hours to the table).

Diversify Your Lifestyle

Just like working a lot won’t make you more productive, having the same monotone lifestyle can lead to a loss of motivation and even depression. People whose daily work implies certain amount of creativity involved (artists, designers) know what I’m talking about - your brain needs to be “entertained”, this way inspiration comes naturally and you feel better in general. I use several tricks to diversify my daily routine a bit:

Every other day I take a different path to work (I have several which I choose from depending on the mood).
Even though my day usually starts at 6 AM, sometimes I hang out in bed until 8:30 and arrive to the office purposely late (at around 10 AM). Bringing a minor chaos like this refreshes me very well.
“Adventure Sundays” - trying new things on a weekly basis. It doesn’t have to be a big adventure - things like trying a new board game or eating something you never considered tasteful before would work. Although I couldn’t make it a weekly practice, I still dream about experiences like this.

Don’t forget to exercise your body just like you do so with your brain. With Sprites getting more traction my training schedule was nearly ruined but I still try to be at the gym at least twice a week. Alternation of mental and physical work is one of the best ways for me to sustain stress, feel healthier (not only physically but also mentally), stay motivated and be in a good mood.

Spend Some Time Doing Nothing

No matter how carefully I follow all the above, sometimes I just need to “reset” myself. My schedule doesn’t seem to be too extreme but from time to time I feel like I need to “pause” things and in this case I spend some time literally doing nothing. This can be just laying on the couch and having some deep thoughts, going to the park and enjoying the nature in a quiet corner on the bench, taking a 3-hour midday nap and so on. I take this as a great ability because I know how many people are struggling to not check their Facebook or Twitter for even 20 minutes. Being able to abstract myself from everything around gives me a big push afterwards.

Conclusion

I hope that some of the things I mentioned here will work for you as well. If you have any questions or would like to share your own productivity tips, feel free to express yourself in the comments.

What To Expect From HTTP 2.0

Fri, 31 Jan 2014 00:00:00 +0000

It’s been over 14 years since the last version of the HTTP protocol (HTTP 1.1) was published in 1999. It would be fair to say that HTTP is an exceptionally successful protocol. It’s an application-layer protocol which means that it’s agnostic to things like transport (e.g. TCP, UDP) and session (SSL/TLS) which, in turn, makes it much easier to incorporate the use of the HTTP on variety of platforms. It’s also text-based which greatly helps us understand, debug and interpret its messages in our own applications. But the Web is evolving, and evolving very quickly. There are now many scenarios in which certain improvements to the HTTP would make our lives much easier and our applications much more secure, performant and scalable. That’s where the HTTP 2.0 comes to play. In this article I’m going to give you an overview of some of the features and capabilities that we should expect in the final version of the specification.

Bandwidth And Latency

Let’s start by discussing the main idea behind HTTP 2.0. Some time ago several folks at Google decided to find out what are the bottlenecks in terms of the actual page load times. So, what they did is they took several large web sites, isolated them in an environment with the fixed latency (e.g. 100 milliseconds) and started measuring the page load times by gradually increasing the bandwidth while keeping the latency constant. The results were pretty interesting: when you go from, let’s say, one Megabit to two you see a 50% performance improvement. But as you increase the bandwidth further, those improvements get smaller and smaller. So, basically, after a certain threshold the bandwidth doesn’t matter anymore and what really becomes crucial in how fast your website is (in terms of resource load times and network utilization) is the latency that you have between the client and the server. Overcoming the latency-related issues is one of the main goals behind HTTP 2.0.

HTTP 2.0 And SPDY

It’s fair to say that HTTP 2.0 is an evolution of SPDY, a protocol originally developed by Google. The main idea behind SPDY was very similar - to improve the overall performance of the web applications and to accommodate to the ways HTTP is leveraged these days. I think, SPDY had great success: Google themselves reported that many of their web applications (such as Gmail, Google Drive and Google+) got significant performance boost by leveraging SPDY. Other companies took notice and incorporated SPDY into their products as well (for example, Twitter, Facebook and WordPress officially support this protocol). Apache and Nginx web servers support SPDY via extension modules and the protocol is supported in all major browsers (including Internet Explorer). So, as I mentioned earlier, at least the first drafts of the HTTP 2.0 are largely based on the SPDY specification and these two protocols share a lot of concepts.

TLS And Protocol Negotiation

I’ve seen some questions on the Internet regarding whether the web server must support HTTPS (via SSL/TLS) in order to be able to communicate with the clients over HTTP 2.0. To answer this question let’s examine the two possible scenarios:

The client makes HTTP 1.1 request to the “http” URI.
The client makes HTTP 1.1 request to the “https” URI.

Please note that here we’re assuming that the client (web browser) itself supports HTTP 2.0.

When the “http” URI is requested, the client will try to “upgrade” to HTTP 2.0 by sending the request headers similar to the following:

In case the web server supports HTTP 2.0, it will answer with HTTP 101 “Switching Protocols” and all further communication will be performed via HTTP 2.0.

When the “https” URI is requested, the protocol negotiation will happen on the TLS level using the application layer protocol negotiation extension (TLSALPN).

There’s nothing in the specification that says that web servers must only allow SSL/TLS (and, therefore, refuse to serve requests over plain text) in order to be able to communicate via HTTP 2.0 (there’s a statement that says that the given HTTP 2.0 implementation must support TLS 1.2 but this doesn’t mean the client has to use it so it’s not the same thing). Although, it seems that there’s been a number of proposals among the IETF working group members to make this a mandatory. Furthermore, it seems that Firefox, for example, wouldn’t allow HTTP 2.0 over clear text (or at least, this was the case till recently - please correct me if I’m wrong).

So, to sum-up, it’s not clear yet whether your web application has to be HTTPS-enabled in order to leverage HTTP 2.0. For me, HTTPS doesn’t look anymore like a privilege but it’s rather such a normal thing to see on the Web these days so whenever you’re publishing something - make it a bit more secure, add SSL/TLS layer.

Update: Ilya Grigorik also informed me that the current plan for Chrome is to support HTTP 2.0 via TLS only.

Request Multiplexing

HTTP 2.0 introduces a feature called request multiplexing. What it allows is to maintain multiple HTTP requests concurrently. To better understand how HTTP 2.0 multiplexing works, let’s start by examining how HTTP 1.1 deals with multiple requests.

When the client issues an HTTP 1.1 request the web server has to fulfill it before any other request from the same client can be sent via the given TCP connection. Although, HTTP 1.1 introduced the default “Connection: Keep-Alive” semantics (the same TCP connection can be used for serving multiple requests/responses), it’s certainly not enough and doesn’t make your application nearly as scalable as it can be with HTTP 2.0.

Now let’s dig into how HTTP 2.0 maintains requests. First, there’s a concept of streams which is (citing the specification) a bi-directional sequence of HEADERS and DATA frames exchanged between the client and the server (don’t be confused by the HEADERS here as it doesn’t mean the “traditional” HTTP headers but rather the HTTP 2.0-specific ones). Also, we’ve just encountered one more important concept - frames. Frames are basically an atomic piece of data transmitted over the given stream. Every frame consists of a type, stream identifier, some flags, and, finally, the actual data.

Now the main beauty of all this is that with HTTP 2.0 multiple open streams can exist at the same time within the same TCP connection and so we can send data through these streams as it becomes available and not wait for an earlier open stream to close. HTTP 2.0 also introduces a flow control meaning that we can prioritize streams and therefore give a web server some hints on which data is more important for the client and which isn’t.

Header Compression

It may sound a bit silly but HTTP headers can have a certain impact on the overall performance of your web server (or network infrastructure). They’re being sent with every request/response, their values change rarely so in most cases we’re simply losing the bandwidth by transmitting them. HTTP 2.0 introduces header field compression meaning that all HTTP headers are sent compressed and divided into so-called header block fragments. One thing to notice, though, is that HTTP header compression doesn’t preserve the relative order of header fields but personally, I can’t see this as an issue (if the application expects headers to arrive in a certain order, there’s certainly something wrong with the way it’s implemented).

Server Push

Server push is another great enhancement that is coming with HTTP 2.0. This feature allows the web server to “push” resources to the client. There are several scenarios when this can be very helpful: for example, server push can be used when the web server “knows” the client will need a given resource (an image, a JavaScript file or a stylesheet) in the future. I’m not sure whether HTTP 2.0 server push has anything to do with the technique of the web server communicating back with the client when there’s a certain event happens on the server side but this scenario can easily be implemented using Server-Sent Events technology which is supported by all the major browsers (although, not by Internet Explorer - what a shame), standardized by W3C and plays nicely with SPDY (and so it should with HTTP 2.0).

Conclusion

HTTP 2.0 looks very promising and will certainly not only improve our web applications’ performance but also improve the way we design and build them. We will no longer need to concatenate our JavaScript and CSS files in order to optimize network utilization, we also won’t need to use image sprites and implement domain sharding. I’m personally looking very much forward to when the specification will be finished and companies will start adapting to it.

At the end, some links to study:

Also, just a day before this article was published, Mark Nottingham (from IETF HTTPbis Working Group) wrote an excellent blog post on the very same subject (even the title of the article is similar :-). Check it out!

I also gave a small talk about HTTP 2.0 at work. You can download the slides from here: goo.gl/fMqjf5.

Re-Discovering Microsoft Web API

Fri, 29 Nov 2013 00:00:00 +0000

Many applications and services these days are being implemented with the use of Web APIs. Some of these products provide publicly facing API endpoints (Facebook Platform), others utilize service oriented architecture internally (Amazon) and of course, there are those that combine both techniques (Azure). Before building a Web API, you need to consider the possible use cases and so your design and implementation must reflect (and accommodate to) those. In this article I’m going to cover some of the not-that-widely-used but extremely useful (in certain cases) features and patterns that can be leveraged in ASP.NET Web API framework.

Since this article is somewhat big, here’s a table of contents:

Asynchronous actions
OData
Batching
CSRF prevention
Request throttling
Long-running tasks and progress
Conclusion

So, without any further delays, let’s begin!

Asynchronous Actions

Many people often get confused whether they should make their Web API actions asynchronous by returning “Task” along with marking the action method with “async” keyword. Generally speaking, the use of asynchronous actions is beneficial when the work you’re doing inside the action method is either network-bound (e.g. calling a web services) or I/O-bound (e.g. reading a large file from disk). Also, you can dramatically improve the responsiveness and resource utilization if you run a number of such work items in parallel (e.g. by using “Task.WhenAll”). With CPU-bound work (e.g. processing the large in-memory structure using LINQ), there’s no benefit of making your actions asynchronous. In fact, there is even a slight overhead that involves the use of task scheduler and context switches.

Here’s a typical example of asynchronous Web API action method:

Notice the use of “GetStringAsync” in conjunction with “await” keyword. This will allow the current thread to be released back to the thread pool without being blocked by the inner web request. When the response arrives, another thread pool thread is going to pick up the work which is parsing the output and returning the list of blog posts.

OData

Open Data protocol (OData) is a standard for providing CRUD (Create Read Update Delete) access to the data via web services. OData is an open standard which was initially developed (and which is being actively maintained) by Microsoft. OData adds a ton of useful functionality to your web endpoints and really empowers your data in many ways.

OData is a huge topic and without going into much detail, I’d like to give you a quick overview of the support for this technology in Web API. But first, a couple of words about the use cases, namely when OData can be extremely useful as well as when you probably want to avoid it. Personally, I think OData makes perfect sense as a higher level infrastructure DAL (Data Access Layer) in a SOA-based scenarios. Let’s say you have a bunch of internal data services that communicate with each other. In this case, in terms of data processing, you’d probably want to provide as much flexibility with these services as possible (e.g. service discovery and proxy code generation, LINQ over web service, etc.). On the other hand, when designing a public API for third parties, unless you have a lot of compute power under your belt, you’d probably want to limit the number of operations available on your data to a reasonable sub-set. Otherwise, it might be hard to scale such a web service (e.g. clients performing rich queries using “$filter”, “$expand” and/or “$orderby” which can result in a heavy load on your data warehouse because the actual data is not optimized for such queries). So, when designing a data service, you need to choose what makes most sense considering the purpose of the service plus the possible use cases.

Let’s now take a look at the example of a simple OData service as well as the code for consuming this service. For those using Visual Studio 2013, the good news is that OData scaffolding has been greatly improved in this version of the IDE. I’m using Visual Studio 2012 and the first thing I do is I create an MVC4 project using an “Empty” project template. The next thing is to add Web API 2 OData support using NuGet (just search online for “OData” in the package manager). Make sure you uninstall existing Web API packages first and install Web API 2 bits instead (along with OData support mentioned earlier).

Now, let’s define the data we’re going to expose over the web service:

After we’ve defined our data entities, we now need to define an EDM model that will expose the definition of our data to the clients:

In the example above I’m also defining OData route for the newly created EDM model using “MapODataRoute” extension method. Finally, here’s our controller class that connects our data with operations that are available on it:

Notice the use of “QueryableAttribute” as well as the return type of “IQueryable”. These two will enable rich OData queries over the collection of blog posts.

Now when the service is implemented, let’s try consuming it. For this purpose I created a simple console application (File -> New Project -> Visual C# -> Console Application). As I mentioned earlier, one of the cool things about OData services is that they’re fully discoverable (via the “#metadata” suffix), so to make our life easier, we’re going to add a service reference (via “Add Service Reference…” dialog) to our data service. In my case, the URL of the service is “http://localhost:51743/odata/” (for the simplicity, I chose to host this example using IIS Express).

After the service reference has been added, here’s how easy it is to consume the data (I’ve told Visual Studio to put service proxies into the “BlogPostsService” namespace):

Notice how we’re using LINQ over web services which is super nice.

Batching

I’m really excited about the new batch support that just came out with the release of Web API 2 OData. Batching is a way to pack several different API requests into the single HTTP POST request. The framework middleware then unpacks the request and re-routs the individual requests to the appropriate API methods. Similarly, multiple responses are then going to be packed together and sent back to the client as a single HTTP response. This feature allows you to decrease the traffic between the server and the client dramatically making the entire communication much less “chatty” (and therefore, making your API more scalable).

Let’s take a look at how to integrate batching support into your API. As an example, I’ve created an MVC4 project (again, using the “Empty” project template). As with the previous example, you’ll need to uninstall existing Web API package and install Web API 2 instead (no need to install OData support since we’re not going to use it here).

The first thing we need to do is we need to register a special route that we can forward all our batches to. Here’s how it’s done:

Next step is to add an API controller. We’re going to use the domain model with blog posts from the previous example and the controller itself is looking extremely simple in this case:

(don’t be confused with the new “Add” method on the repository class. This method simply adds a new object to the underlying collection and returns that object).

As you can see, our API controller is totally unaware of the batch handler registered earlier. This is, of course, logical: there should be absolutely no difference from the API point of view between performing a batch and a normal (single) request. The batching is handled on the transport level down the stack.

Now, to demonstrate the use of batching I’ve created a tiny JavaScript library (the source code of the library can be found here: https://github.com/volpav/batchjs). Here’s how the main view looks like:

The central part of the view is the call to the “ajaxBatch” method. The semantics of this method are more or less the same as with the native jQuery “ajax” method, although there’s only one actual HTTP request that is being made and the batch contents is specified by defining the “data” array. Notice that there’s also an additional argument “data” which is passed to “complete” handler. The argument contains an array of object, where each element of the array corresponds to a single API response within the batch (the library assumes that the order of the responses within the batch is the same as the order of the requests, although this can be customized at the server level). Each element represents an object with two fields: “status” (HTTP status code, e.g. 200) and “data” (evaluated response data, if any).

CSRF Prevention

Cross-site request forgery (CSRF) is a type of a website (web service) vulnerability when unauthorized calls to the service are made through the malicious “man in the middle” software/person. These types of attacks are very popular because they’re easy to perform and because there’re many developers who violate the concepts of HTTP and neglect even the basic protection. This is, of course, much more relevant when dealing with public APIs rather than the ones that are designed for (and exposed to) internal systems. A simplest example of CSRF can be a the following: imagine that you’re logging into your favorite social network. When the authentication is done, the server will most likely establish a user session associated with the currently open browser window. Now, let’s say, someone sends you a link which looks the following: “http://mysocialnetwork.com/like?post=123”. The thing is that the developer of the website violated the behavior of the HTTP GET request - it’s designed to be idempotent, meaning that the requests of this type must only retrieve the data but not alter it. When you click a link, the browser redirects you to the the given URL where the session has already been established. Before you realize what happened, you “like” someone’s picture or product without explicitly doing so. A more sophisticated example may involve the use of session cookies (e.g. when you check “Remember me” while logging into the website) as well as the malicious website which contains a form, which, upon submitting it, sends a hidden request to the website where you authenticated yourself earlier. In this case the browser will happily pass session cookies along with the request and it doesn’t really matter whether this is a GET request or not.

One way you can protect your API from CSRF attacks is to use anti-forgery tokens, a functionality which is available in ASP.NET MVC and which can be easily leveraged in Web API. The idea is to have two tokens, which are going to be sent with every API request. One token is sent with the cookies, the other - with form data. These tokens later are going to be validated and if the validation fails, the client would get HTTP 403 “Forbidden”.

Let’s modify our previous example to support CSRF protection. First, let’s create a test view:

In order to protect our “Post” method inside the “PostsController” we need to have a way to validate the request before the action gets executed. With ASP.NET MVC you can just decorate the method (or the entire class) with “ValidateAntiForgeryToken” attribute but, unfortunately, this attribute has no effect when using Web API so we need an alternative. The way we’re going to approach this shortcoming is we’re going to write a custom authorization filter (I called it “ApiValidateAntiForgery” to eliminate any confusion with MVC):

The newly created attribute can now be applied to the “Post” action method like the following:

Now if we submit the form, we’d get an error. In order to get rid of it, we need to supply authorization tokes. This is done the same way as with ASP.NET MVC, by putting the call to “Html.AntiForgeryToken” method inside the form:

Now the request passes the validation and we get the response from our API.

In cases when the call to the API needs to be made using AJAX, we’d use a slightly different solution - we’d pass the tokens with the custom request header. Here’s how it’s done on the client:

Also, we now need to modify our validation logic to take the “RequestVerificationToken” header into consideration:

After performing these changes, our solution is going to work both with normal submission as well as with AJAX-based one.

Request Throttling

Request throttling is a way to limit the number of web requests according to a given rate. When working with Web APIs the term that corresponds to request throttling is either “Rate limiting” (for example, Twitter or Facebook), “API limits” or “Quotas” (for example, Google), or “API throttling” (for example, Amazon). Request throttling helps making your API more scalable by refusing requests from clients that are currently over the limit and therefore, “making room” (keeping resources available) for those clients who’re within the given rate. An example of a rate limiting can be the following statement: “Any particular client is only allowed to make up to 10,000 API requests per month”. By “client” I don’t necessary mean the physical machine, it can also be specific customer account (referenced by an API key, username-password pair or something else that can be used to uniquely identify the client in the system).

Request throttling is not natively supported in ASP.NET Web API but it’s very easy to implement the basic functionality using a custom HTTP handler. If you’re familiar with ASP.NET MVC, you can think of HTTP handlers as something which is very similar to action filters. Handlers get executed quite early in the pipeline allowing the developer to easily abstract the infrastructure functionality (such as rate limit checking) from the business logic and make the application code more modular and less coupled.

Let’s take a look at the example. We will start with defining a type that will represent an API limit:

Next, we create our custom HTTP handler by deriving from “System.Net.Http.DelegatingHandler” and overriding “SendAsync” method:

The high-level logic is pretty straightforward: before each API method call, we’re retrieving API limit for a given client and checking whether the limit has been exceeded. If so, we’re aborting any further execution by returning HTTP 400 “Bad Request”. Otherwise, the execution continues normally.

There’s a bunch of helper methods that are used inside “SendAsync”. Here’s the implementation:

As you can see, first of all we’re using a static in-memory dictionary to maintain the list of API limits together with the current usages per client. Of course, this is very naive implementation since this data will be lost with every app pool recycle but it’s here just to demonstrate the concept. Another thing worth mentioning here is that we identify the client by his IP address (but, as I mentioned earlier, the way you do this depends on what you “target” by throttling). For this purpose we use the “GetClientByIpAddress” extension method:

We can now plug our custom handler in by adding it to a “MessageHandlers” collection which is available on “GlobalConfiguration.Configuration” object (this must be done on application start).

Long-running Tasks And Progress

Long-running tasks always looked to me as kind of a Holy Grail for many web developers. Every now and then you see questions being asked on StackOverflow as well as new blog posts being written about how you can incorporate this kind of functionality into your ASP.NET application. Most of these techniques and solutions, though, are quite fragile and can’t really be used in a real world scenario. The reason is simple - HTTP is stateless and any good framework (such as ASP.NET MVC) should embody this stateless nature and, by doing so, it encourages you to write more scalable and robust web applications. In other words, ASP.NET wasn’t designed to support this kind of scenarios. For example, there’re multiple different reasons why app pool can recycle and you’d need a lot of extra functionality to make your long-running tasks sustain this behavior. Any work that requires a substantial amount of time (as well as additional amount of computational power) to complete must be off-loaded from the front end of your web application.

For service-oriented applications, one of the ways to be able to have long-running tasks can be having a dedicated service for this purpose (let’s call it a background worker). If you’re working with Microsoft stack, a really nice option (in my opinion) is to create a WCF service and host it outside of the HTTP context (e.g. by hosting it inside the Windows service) so all the possible issues mentioned earlier will be avoided. Another good alternative is to use .NET Service Bus, although I’m not going to cover it in this article.

Now, how do you make it possible for the consumer of your service to know what’s the progress of performing a given tasks (how far did it get, when is it going to be completed, etc.)? The simplest solution is to periodically query the service for the progress information. While this will work, this is also not very scalable solution since we don’t want to bombard our background worker with requests while there hasn’t been any progress so far. The more correct way to solve this problem is to allow the service to “push” information about the progress (when it’s available) back to the client. With WCF this can be achieved by using callback contracts together with one-way operations.

As an example, I’ve created a simple application which parses a structure of a given website by following all internal links. The application consists of WCF service, hosted inside the console app, as well as ASP.NET MVC front end with some Web API endpoints for some AJAX-based scenarios. While I’m not going to demonstrate the entire source code here (it’s available at https://github.com/volpav/webapi-sitemapservice), I’d like to show you the key parts of the application.

First of all, let’s look at the service contract definition:

As you can see, we have two contracts: one is implemented by the service, another one (callback contract) - by the client. The callback contract can be retrieved by the service using “OperationContext.Current.GetCallbackChannel” construct. This enables the service to call back the client the similar way the client would call the service.

Here’s the part of the consumer functionality that enables communication with the service:

For the simplicity, I’m storing the progress information (as well as all the results) in a static in-memory dictionary: the two calls -“SitemapManager.Current.OnProgress” and “SitemapManager.Current.OnCompleted” - simply update the data in the dictionary whereas the Web API endpoints access this data (instead of accessing the service layer directly).

Conclusion

No doubt, ASP.NET Web API is a great tool for those looking to create their own APIs for the modern Web. This framework addresses many different use-case scenarios and is quite flexible to accommodate to almost every need. I hope that, by reading this article, you learned something new and that some of the information presented here will be useful in your daily developer adventures.

Below I’ve gathered some links to resources that can help you get a better understanding of topics covered in this article (some of the resources apply to ASP.NET MVC but certainly can be treated as guidelines for Web API as well):

Asynchronous actions
OData
Batching
OData & Batching - client-side libraries: One, Two
CSRF prevention
One-way calls, callbacks and events in WCF
Long-running tasks and progress (example)

I also had a chance to present the above to my fellow colleagues as part of our “Lunch & Learn” initiative. Here are the slides: http://bit.ly/191xhNp.

Tail Recursion And Trampolining In C#

Fri, 27 Sep 2013 00:00:00 +0000

There’s a very interesting course on Coursera which started earlier this month. It’s called “Functional Programming Principles in Scala” and it’s being taught by Martin Odersky, the guy behind Scala programming language. Since I wanted to learn Scala for quite some time now, I thought I’d be a good opportunity so I joined. It’s been a great experience so far and I feel like I’m re-exploring the principles, paradigms and power of functional programming. I even caught myself on a thought that it would probably be a good idea to teach Scala or Haskell (instead of Basic, Pascal or C) as a first programming language at schools because it instills you the style of writing elegant and performant programs. One of the terms that popped up several times during the course and the one I knew very little about was the term “tail recursion”. I immediately started researching whether this is something that can be leveraged in C# and this article is the result of my research (there’s actually a plenty of articles on the subject out there and the goal of this one is to give the reader a quick and concise overview rather than stuffing the article with a lot of theory and huge code snippets).

What Is Recursion

Generally speaking, recursion is when the function calls itself (usually, with a different set of parameters). This allows solving a problem in terms of solving the same problem but on a smaller scale. For example, finding a factorial of a number N can be expressed as multiplying N by factorial of a number M such as M = N - 1. Of course, many problems can be solved without using recursion and depending on a programming language of choice there’re certain pitfalls (like, stack overflow) that you should be aware of when going for recursive solution. On the other hand, there’s a wide range of problems where the use of recursion not only greatly generalizes the solution but also makes the code much more readable, maintainable and elegant. An example of such problem can be finding a shortest path in a maze by using Lee algorithm.

As I mentioned earlier, one of the drawbacks of using recursion is a chance of exceeding the maximum stack depth (which is defined by the execution environment) since every time the recursive call happens, the runtime needs to preserve the state of the current stack frame (which might be needed upon the return from the recursive all) and, therefore, create a new one. Let’s take a look at the recursive implementation of factorial:

As you can see, the return value of factorial(n) depends on the return value of factorial(n - 1). For every recursive call to factorial(n - 1) the CLR is going to create a new stack frame, so if we assume that the value of a numeric type we’re using is never going to overflow (for this purpose I used hypothetical “BigInt” type), then there’s a risk of getting “StackOverflowException” for very big initial values of “n”.

What Is Tail Recursion

Tail recursion is a method of implementing recursive solutions when the recursive call happens to be the last action in a method. Let’s take a look at the modified implementation of factorial which now uses tail call:

The conceptual difference between the first and the second example is that in the former case the call to factorial(n - 1) is not a tail call since it’s not the final action (we multiply the result of a call by the current value of n) whereas in the latter case we always pass around an additional parameter called “current” which serves as an accumulator and makes it possible to implement tail-recursive solution.

Why Implement Tail Calls

The huge benefit of using tail calls is that since they’re the last actions within the method, the current stack frame can be reused for the next recursive call - you basically don’t have any state to preserve since you’re not going to need it after the return from the recursive call. This means that the entire recursive flow can be executed on the same stack frame eliminating the possible stack overflows (and also speeding up things). This approach is called tail call optimization and in case of .NET or Java, it’s a compiler that is responsible for performing it (by emitting the correct IL opcodes). Of course, this kind of optimization is supported by functional programming languages like Scala of F#.

Tail Call Optimizations In C#

Unfortunately, tail call optimizations are not performed by C# compiler (although tail calls are fully supported by CLR since .NET 4.0). You can easily verify this by running our tail-recursive factorial example and putting the breakpoint inside the “accumulate” method. Every time you hit the breakpoint, you can see that the stack trace grows in size (Debug -> Windows -> Call Stack). I wonder whether C# compiler team decides to implement the support for tail calls at some point (the faster, the merrier - in my opinion, it’s a huge win).

The Technique of Trampolining

In case tail call optimizations can’t be leveraged, there’s a well known workaround of using the technique called “trampolining” which can be implemented in any language that supports higher-order functions (C# is one of those languages). The main idea is to execute the method in a loop whereas the method itself can either return a final result or a new set of arguments. Let’s take a look at how we can change the tail-recursive implementation of factorial to use trampolining.

First, let’s define the return type for our “bouncing” action (which is to be executed in a loop):

As you can see, we can either pass the next two arguments (the values for the “current” and “n” parameters from the tail-recursive example) or pass the end result (in this case “HasResult” is set to “true” which tells the caller to break from the loop).

Here’s the implementation of the trampoline itself:

The implementation is pretty straightforward: the action method continues to “bounce” as long as the final result is not available. In this case, the action method returns the next set of its arguments on every iteration.

The trampoline-enabled factorial implementation will now look like the following:

Conclusion

Tail recursion is a very powerful technique of implementing recursive solutions without worrying about exceeding the maximum stack size. It’s very sad that C# compiler doesn’t implement tail call optimizations but as you just saw, trampolining is one of the ways of preserving the recursive nature of our solution but executing it in imperative fashion. Since the action method (which is called “iteration” in our example) is executed in a loop, stack trace has a constant size throughout the entire computation process.

These are the articles I found useful while studying the subject:

Why Knowing English Is Important For Every Software Developer

Mon, 02 Sep 2013 00:00:00 +0000

At first, I wasn’t sure whether to write this post in English or in Russian. On the one hand, it’s aimed at those who are not proficient in English so it seemed logical to write it in Russian. On the other hand, I also have many friends who are neither from Russia nor they’re native English speakers and so I can imagine that my thoughts here would also be interesting for them to go through. As you can see, I chose the latter. This blog post is about why I think it’s very important for any software developer to know English on at least an intermediate level, both in terms of non-verbal (reading/writing) and verbal (speaking) types of communication.

The Way You Manage Yourself

I know many people (software developers) who are perfectly fine with not using English on a daily basis. They prefer books translated to their native languages (usually those are “hard copies” rather than e-books), they use localized software (for example, Russian Windows, Visual Studio, SQL Server, and so on), they receive global news from the national content aggregators and news portals, in case they need help online, they usually turn to domestic communities (localized documentation, Q&A sites and forums, etc.), things like that. And it’s perfectly fine, all this usually works quite well. But let’s take a look at the disadvantages.

First, let’s talk about translated books. The main problem with those (as I see it) is that it usually takes quite a lot of time before the translation hits the market. One of my friends recently bought the translation of Jon Skeet’s C# in Depth, second edition whereas I (almost at the same time) bought the third edition. I’m not saying that the information from the second edition is way too old already, but let’s face it: technology these days evolves so quickly that it’s sometimes doesn’t even make sense to publish a hard copy because by the time it sees the light, there will be so many changes and additions to the subject that it will require writing a new edition. Another problem with translations is that sometimes the translator doesn’t have enough understanding of the subject in order to properly “project” the knowledge into a new language (as an example, there’re quite a lot of complains regarding the translation quality of the second edition of C# in Depth).

Next is localized software. While I can understand why people are buying translated books, it’s a complete mystery for me why software developers are installing localized copies of specialized software (for example, a .NET developer using a Russian version of Visual Studio). The biggest issue here is that it’s often very hard to find a solution to a problem with particular tool or framework (for example, you get a weird .NET exception or the project build fails) if all you have is a bunch of localized error messages . The original documentation is always much better than any of its localizations plus resources like Stack Overflow can really save you a lot of time as well as nerve cells.

The situation with news is similar to the one with books. News are useful when they’re fresh and although it doesn’t take long to translate a single news article, things like the competence of the translator (same as with books) as well as the ability to consume the related information (for example, nobody translates comments, while they can provide a much better insight of the situation than the article itself) often make it more difficult to keep your hand on a pulse of technology.

The Way You Represent Yourself

Here’s something very important: your ability to express yourself in English can directly affect the ability of people around you to judge about your level of professional expertise. This is something I experienced personally as well as observed from the side. At my previous company we had a group of developers working remotely from Ukraine. Every now and then, we were having Skype meetings where we were planning next iterations, discussing current issues, etc. None of the Ukrainian guys had a particularly good verbal English and what I noticed is how my colleagues were communicating with them (not only via voice chat but also by email). It seemed that those Ukrainian guys were treated more like junior developers (basic stuff was always clarified, intense audit from the lead/manager was an ordinary thing, etc.) rather than developed professionals. The funny thing is that I knew what they were capable of doing since we could speak Russian to each other and I could tell that those guys had enough knowledge and experience in what they were doing. From my point of view it was their English that resulted in making a bad impression of themselves as professional developers. And it’s not the only example, I’ve seen other cases like this.

Paul Graham recently made a remarkable statement about one of the reasons they don’t accept people to Y Combinator. He said literally the following: “One quality that’s a really bad indication is a CEO with a strong foreign accent.”. While there’re now many people who disagree with his statement (even those who spotted a racist tone in what he said), I think he’s generally right. Why would I, as an investor, trust someone my money if that someone can’t even properly pitch his idea so it’s at least understood by everybody? I think that the same logic can be applied to software developers with a bad English: nobody is going to hire you as an architect or a team lead, if you can’t even express your thoughts using a proper technical terminology.

The way you act now If you thought about yourself while reading the above, you know that you probably need to improve your English. I’m not going to suggest anything here because I think that there’re different techniques that work for different people. Someone learns better by watching movies with subtitles, by reading books with the dictionary and by playing video games (yes, a lot of people actually improve their foreign language skills by playing video games localized to that language). Others just take classes and receive knowledge from the teacher. If you have a possibility to communicate with the native speaker on a daily (weekly, monthly) basis, that’s great, that would probably help you a lot. Personally, I was just switching more and more to the English “content” (uninstalling all localized software, switching from national news channels to The Verge, TechCrunch and Hacker News, etc.).

The Japanese translation of this article is now also available.