A cache is a pretty simple concept that shows up in a lot of different areas in computing. In almost all cases, a cache serves basically one main purpose. The key idea is to speed up access to data that is needed frequently. What that data actually is could vary depending on the context.

One example most people are familiar with is the apps on your phone. So let’s start there. Let’s say you’re listening to a song on your favorite music playing app. You’re absolutely hooked on to the song and you can’t get enough of it. So you keep mashing that repeat button and listening to the same song over and over again. Now, the actual contents of the song are not stored on your phone by default. When you install a music streaming service, you’re not installing the millions of songs in their library onto your phone automatically. That would be ridiculous.

Instead, once you listen to a song, the app is smart enough to make a copy of it on your phone. So the next time you try to listen to the same song, the app uses the copy for playback rather than downloading it again. This is great for two reasons. Not only are you doing the streaming service a favor by relieving some pressure from their servers, but you’re also saving some of your own precious bandwidth and data charges you’d spend grabbing the song each time.

You can already start to see how this approach would be useful for other things as well, such as images, videos, your message history, or anything else that doesn’t change too frequently.

Another example you’ve probably already experienced is the browser cache on your computer. The idea, again, is very similar. Websites are rarely just blobs of text anymore. They’re comprised of images, videos, and a whole lot of data that can be expensive for your network. So instead of fetching every single resource every time you visit the website, some of theses resources are cached by your browser the first time you visit. Every subsequent visit then relies on reading at least some of the information from this cache.

This is all great, of course. Caches are great. They speed up access to things and save you some $$$ in network costs. They make lives easier for developers. Everybody wins. So what’s the catch?

Well, the problem is that at the end of the day, the data stored on your local device (whether your browser or your phone) is just a copy of whats on the server. It’s not the real thing.

So if the data on the server has changed since the last time your cache was updated, the thing you’re seeing is likely out of date. This isn’t usually the end of the world. Sometimes, it just means you don’t see your friends’ latest profile pictures as soon as they‘re updated. But this is a conscious tradeoff that needs to be made by the developers, and it might not always be worth it. You might have noticed that clearing your browser and app caches can sometimes fix weird bugs.

The other downside is that caches take up space. A lot of space. In fact, you can see just how much space some of the apps on your phone are using by taking a casual look through your phone’s settings. This isn’t a problem if you have a lot of storage at your disposal, but if you’re running even slightly out of date hardware, this can be noticeable.

And lastly, even though we’ve talked about caches only in the contexts of your apps and browsers so far, they’re a critical building block for computers at the hardware level. The CPU in your computer executes, to use the scientific term, a crap ton of instructions every second.

Just like before, in order to speed up operations, the CPU maintains a local copy of data that it needs frequently in a hardware cache. Also, the CPU might have multiple levels of caches. The levels closest to the CPU are the fastest but can store the least amount of data. Each successive layer is slower but can store more data. For example, you might have heard of the terms L1, L2, and L3 caches when shopping for a new computer.

Caches are a powerful concept that is seemingly everywhere once you start looking for it!

You’ve probably had times when you’re visiting a website or using an app and notice something just slightly off. Maybe the colours seem a little off, or maybe the layout of the app has changed just a tiny bit. Only for it to fix itself the next time you go back. Or you might have noticed that the version of the app that you’re seeing is not exactly the same as your friends. One possible explanation for this is that the app might be running an A/B test behind the scenes.

A/B tests are a commonly used approach for companies to validate changes to their products before releasing to the entire user base. The basic idea behind an A/B test is to present a change to a small segment of the overall audience, and see how it impacts their behaviour. Any change you make could either have a positive or a negative impact on your product. Or in some cases, you might see no impact at all.

Let’s say you operate a small e-commerce store selling T-shirts. Off late, you’ve noticed that your sales numbers aren’t quite up to the mark. You’d like to investigate the issue and hopefully make some changes to your website that would invite users to spend more of their money. Before you sink your dollars into expensive marketing campaigns, you want to make sure that the store itself is optimized. Obviously, you don’t want to redesign the entire store. But you do want to make some quick changes to boost performance.

Maybe you’ve noticed that the position of the “Add to Cart” button, all the way at the bottom of the product page, is not ideal.

You suspect that if the button were placed in a more prominent location, it would catch more eyes and perhaps invite more users to complete the checkout process sooner, and make you more money.

Sounds reasonable. But how would you validate this? Well, one way is to just make the change and see what happens. If you switch things up and start making more money, boom. Problem solved.

This would be a fine approach under a lot of circumstances. If your changes are unlikely to cause massive shifts in user behaviour, that would be acceptable. But if your users are sensitive to changes in your product, or if these changes can negatively impact your bottom line, you might want to be a little more cautious.

To continue our slightly silly analogy, what if the button is actually perfectly placed? What if moving to a different location comes across as too aggressive for your customers, deterring them away altogether? You want to verify your hypothesis, but you also want to minimize the risk. Hedge your bets, so to speak.

One way you could mitigate this risk is by, surprise surprise, using A/B tests. In order to truly validate your idea, you want to run a scientific experiment of sorts. In this case, we’d create a new version of the website with the button in a different, more prominent, location. However, the key is that we serve this version of the website to only 50% of all users. The other 50% continue to see the original website with the button unchanged. This gives us two user groups to compare.

In an ideal scenario, we might want to eliminate all other differences between the two variations, such as the product type the user is purchasing, the time of day, their location etc. We want to be sure that any differences in the user’s shopping behaviour are purely due to the design changes. If you’ve noticed, this is a lot like conducting a scientific experiment. But for our fictional website, let’s assume we arbitrarily decide which user gets to see which variation.

Now, with our control group and challenging group in place, we simply monitor the numbers associated with each variation.

In this case, for example, you could check the user’s click-through rate (how often users are clicking on the “Add to cart” button) to see if there are any significant differences between the two.

Based on the experiment, you might conclude that there is, in fact, no difference between the two versions. This tells you that your initial hypothesis was incorrect and you need to look for other things to change. Or you might discover that you were right all along, and decide to roll out these changes to your entire user base (and enjoy the increased profits).

If all of this sounds too scientific, it’s because it usually is a scientific process. Understanding user behaviour is complicated and A/B tests can often get quite granular. They require a significant amount of statistical knowledge to extract any meaningful insights. But they’re also are a very powerful tool if used properly.

As users, we’re subject to A/B testing all the time without realizing it. In fact, any given product could be running multiple tests simultaneously as long as those tests don’t overlap. Here’s a Netflix blog explaining just how religiously they use A/B testing to make their product better over time.

So the next time you see things that seem off when browsing the internet, you know what’s going on.

For better or worse, for the average user, search engines are the gateway to the internet. When trying to find relevant information on the web, most people tend to go to their favorite search engine, type in a couple of keywords and visit the first handful of links that show up. Aside from a handful of frequently visited websites, this is how most people access the internet.

Unfortunately, what this also means is that if your website doesn’t show up in those first few search results, chances are that people aren’t really finding out about your website, and you aren’t getting any traffic. In fact, research suggests that 90% of users don’t even bother clicking past the first page. If they don’t find a result they like on the first page, they would simply tweak their search keywords and start over.

So you can see why for any new website, be it a blog, or a local business, or an e-commerce store, having a good search result ranking is crucial. This is what is referred to as Search Engine Optimization.

There are a few different search engines out there. Each one has its own unique way of ranking search results. Since Google is the most popular search engine today, most people tend to focus on improving their rankings on their system alone. However, all search engines share some similarities. Ultimately, the search engine’s job is to make sure that the results that are being served are not only relevant to the user’s query, but that they are also a legitimate source and provide a reasonable user experience.

For example, one factor that is common to pretty much all search engines is the number of backlinks for a given page. This is the number of other web pages on the internet that link back to a particular page. The assumption is that the more backlinks a page has, the more reliable it is. This is similar to the citation model that scientific journals use for determining the reliability of a published paper.

Another important rule of thumb is the performance of a particular page. Web pages that are really slow to load offer a sub optimal experience for the customer and are typically penalized by search engines, while fast pages are bubbled up. Similarly, “fresh” content is usually preferred over stale ones. This is why it is important for your blog to continue to publish great content. As the information on your page gets outdated, so too will its search engine ranking.

Ultimately, every search engine is different. And even though two search engines might look at the same factor, it does not mean that they would prioritize it the same way. For example, even though both Bing and Google care about backlinks, one might give it a lot more weight than the other when it comes to making a ranking decision. But since all search engines are trying to reward good behavior, your efforts at increasing visibility on one platform should have some effect on the other as well.

Given just how important search engine rankings are for a business, it isn’t hard to see why SEO has grown into an $80B industry. Hopefully this post gave you a basic understanding of what exactly SEO is and how it works!

A couple of weeks ago Canada released the COVID Alert app to the general public. The app is intended to help tracing efforts in the province to curb the spread of COVID-19. Understandably, there are some questions regarding its privacy and security implications. Although I focus here on the Canadian version of the app, the underlying architecture is used by a lot of other public health authorities all over the world. You can find the full list of countries here.

The first important thing about COVID Alert is that although the app itself is being branded and released by Health Canada (and other public health authorities) much of the core technology is provided by Apple and Google for iOS and Android respectively.

Earlier this year, Apple and Google, in a joint effort, released a framework called the Exposure Notification System (ENS) designed specifically for building COVID tracing apps. The framework provides a set of tools for developers on both platforms and is intended to be used by public health authorities all over the world. It has been created with the explicit goal of preserving user privacy by design in an effort to encourage broader adoption. More on that here.

As of now, the system is 100% opt-in. You don’t have to download the apps if you don’t feel comfortable. Nor would you be forced to opt-in at a later stage. However, the success of the program does depend on having a certain percentage of the population signed up.

The mechanism itself is fairly straightforward and uses a decentralized approach. Let’s say we are living in an ideal scenario where a majority of people have the app on their phone. Once you install it, it runs in the background and sends out randomized “codes” every 10–15 minutes via Bluetooth.

These codes are essentially just gibberish and not tied to you in any way. Over the course of the day, you would generate dozens of these codes. For simplicity, let’s say that your code never changes and is fixed to something ridiculously simple like12345.

Phones that are near you, within a distance of 10m, and also have the app installed, are listening for these codes. If you’re hanging out with a friend, or at a busy supermarket, your phone will be exchanging codes with those around you. Your phone will store the codes that it “came in contact with”. And likewise, all the phones around will you store your code. At this point, all data is decentralized, meaning that the information is stored purely on phones and not on a server somewhere.

Now, hypothetically, one of the people you ran into at the supermarket later tests positive. The person can then tell the app that they’ve been infected. In most cases, they would be required to submit some sort of medical proof or confirmation from a public health authority. In Germany, for example, you would scan a QR code issued by the health authority confirming your diagnosis. This is to prevent people from falsely claiming that they’ve been infected to intentionally create false alarms.

The app would then upload all of the codes issued to that person over the last 14 days to a web server. Or in our simplistic model, the single code that they were assigned, say 56789. The server is only storing a master list of these “infected” codes.

As the final step, your app downloads a list of these infected codes from the server a few times a day and compares them against all the codes of other people that you have run into. If it finds a match, it means that you’ve been in contact with an infected person and you’re at a higher risk and are notified immediately. This would then likely translate into a higher testing priority for you. And likewise, if you test positive, then the people that came into contact with you, and so on.

The “privacy-protecting” approach comes from the fact that the system does not theoretically need access to your location or GPS at any point. If your location is needed for any reason, you will be prompted for permission. Nor does it need access to any sort of personal information. The only thing the system really needs is a Bluetooth based device. Additionally, your codes never leave your phone unless you get infected, meaning that nobody gets access to your data, including the health authorities.

Whether or not this technology is too far reaching, or not extensive enough, is a whole other debate. But at the very least, I hope that having a better understanding of the underlying tech can help folks make an informed decision about whether or not they’d like to opt in.

In Canada, the source code for the application is freely available on GitHub. I highly recommend taking a look if you want to get your hands dirty and dive into some code or send in some patches! :)

Cloud computing is a roughly 400 billion dollar industry that has completely transformed the way software gets built today. But cloud computing as we currently use it is a fairly recent idea.To fully understand what it is and why it is all the rage, you first need to understand what came before it.

Let’s say it’s 1995 and you’re a young founder of hot internet startup. You’ve a great million dollar product idea that you’re ready launch. In order to release your product, you need some infrastructure. At a high level, this would be all the web servers needed for your customers to access your website and interact with it along with some form of storage to store data for them.

Now, because you don’t just have a couple of hundred servers just lying around in your basement, a logical thing to do would be to go out and buy some cheap hardware. You would hook up all these servers together, set up your website and be off to the races. This acts as your own mini data center.

Of course, if things go well and you start adding more users to your website, your hardware requirements would increase as well. You would then continue to add server capacity to meet your growing demand. This already starts to create a few problems:

• You require at least some initial capital to purchase all your servers. This might not be a huge factor nowadays due to the constantly decreasing prices of compute power, but could be a decisive factor previously
• As the number of servers grows, so too does the time you’ve to spend maintaining them. You’ve to make sure that the servers are always up and running, they have sufficient memory, they have up-to-date security patches, and so on.
• Despite your best estimations, you will never truly be able to guess exactly how much capacity you need at any point in time. You will either need to go back for more hardware sooner or later, or you will have servers that aren’t really being used.

These problems are exactly where cloud computing comes into the picture. Cloud computing providers take away the hassle of maintaining your own servers and data centers. They tend to own and operate their own data centers, sometimes in multiple locations all over the world, that you can then use to host your application’s infrastructure. You can still use these hosts as you normally would, and do everything with them as you otherwise would, only that now they’re not in the same room as you.

Effectively, this is the difference between renting something and buying it outright. Most providers offer a flexible payment model where you only pay for the infrastructure that you use. If your application needs to only be active for three hours a day, you only pay for server usage during those three hours.

You also offload the maintenance responsibilities to the cloud provider. The provider is responsible for making sure the servers are always up and running and replacing or retiring them when they reach their end of life.

The biggest advantage with moving to a cloud provider the ability to handle unpredictable demand. As we talked about before, if you’re a young startup, it’s likely not easy to figure out what your demand will look like from one day to the next. If your app suddenly explodes in popularity, you might find that your existing server capacity is not enough to serve the growing demand and you might suddenly need to add more compute power in the middle of the night. A good problem to have, but a problem nonetheless.

Most cloud providers make it really straightforward to add or reduce server capacity in just a few clicks. In some cases, they might even automatically adjust the capacity based on increasing demand without you having to lift a finger. All of this frees you up so you can spend more time focusing on your core product and solving problems for your customers.

Having said all of that, there are still a lot of reasons why some companies may want to own their own infrastructure. For one, some companies might want the peace of mind that comes with having data stored in your own data centers under your supervision rather than trusting third parties. In some cases, you might need your data to reside with certain geographic boundaries for legal reasons. Or, it just might be more cost effective for you to own your own hardware. But regardless, cloud computing as a trend is here to stay.

Satellite internet is in the spotlight a lot these days. After seemingly already having passed its heyday, it appears to be making a comeback, thanks to work being done by a lot of major tech players such as SpaceX. But in order to understand what it is and how it works, let’s first talk about how the internet works in the first place.

When you really break it down, the internet is just a collection of files on a bunch of computers spread all over the world. When you visit a website, all you’re trying to do is access the contents of a file that is stored on a computer located potentially thousands of kilometers away. This file makes its way to you by traveling in the form of electric transmissions through physical cables.

Even when you’re connected to the internet wirelessly, either through WiFi or cellular data, there is a physical point of contact between you and “the rest of the internet”. This could be the cell tower maintained by your data provider or the modem inside your house. These devices connect to other routers on the internet through a wired connection.

The exact form of that connection could vary. If you are old enough, you probably remember the days of Dial-Up internet when you couldn’t access the telephone lines in your house if someone else was connected to the internet. This is because the telephone and internet would share the same cable so that only one of them could be used at once. These days Cable Internet and DSL both work in a similar manner by sharing infrastructure with your Cable TV and telephone lines (but manage to bypass the limitations of dial-up).

Fiber internet has also gained a lot of popularity lately. Unlike DSL and Cable, fiber optics rely on the transmission of light in glass cables to relay signals from one end to the other, which is typically a lot faster than electronic transmission through copper cables, resulting in faster internet speeds.

However, the downside to all these approaches is that they require a huge amount of physical infrastructure to carry signals all over the world. The so-called “Internet Backbone” consists of millions of kilometers worth of fiber cables laid all over the world along with a set of powerful routers known as Internet Exchange Points. There are even cables buried in the deep sea that move signals across continents!

The cost of building this infrastructure is a major factor in the internet speeds you get access to. And it gets worse in rural, remote regions where it is usually isn’t worth the investment to build all this expensive infrastructure, resulting in slow or no internet at all.

And this is exactly the problem that satellite internet aims to solve. Rather than rely on connections here on Earth, satellite internet aims to move them up into the sky.

Instead of connecting to a modem/router in your house, you would instead connect to a satellite transmitter/receiver which communicates with the satellite. The satellite would then, in turn, communicate with other satellites in the sky, similar to how signals on the ground move from one point to the other, until finally reaching the destination computer.

The benefit is that even though the transmission of the signal from the dish to the satellite might be slow, the transmission between satellites is extremely fast. This is because light travels fastest when inside a vacuum. Almost 1.5 times faster.

This is especially great when you consider that the only thing you really need to access the internet is a satellite receiver. Meaning you could get online even if you live in a small, rural town that would otherwise have very limited internet access — or none at all.

The downside now is that because there is no physical medium of transportation involved, the signals are traveling completely wirelessly. Meaning that they are a lot more susceptible to things like weather interference. There is also the additional risk of polluting the night sky by littering it with so many satellites (this is not even taking account of the obvious limitation that the earth is flat and none of this is supposed to work in the first place).

But regardless, if you’ve ever owned a satellite-based TV, you also probably know how frustrating it can be to get the dish to point in just right the direction to maximize the signal quality. But again, if you consider that the alternative for a lot of people would be no internet at all, then the benefits should quickly outweigh the risks.

Satellite internet is not a new concept, of course. It has been around for quite some time. However, current implementations rely on satellites in the so-called Greater Earth Orbit (GEO) which is much further away from us and rely on a handful of satellites at most.

But off late, this form of internet delivery has been seeing a lot of traction again thanks to investments by some large players, looking to build satellite constellations much closer to us, in the Low Earth Orbit (LEO). Whether or not these investments will materialize is hard to say, but it is hard to argue that all this is anything but futuristic.

You’ve probably seen a ton of websites lately showing you popups about how they use your cookies, and your data. But what exactly is a cookie? And how does it work?

Cookies are a very clever concept, really. At the most basic level, you can think of cookies like pieces of information that are created by a website and stored by your browser, on your behalf.

For example, if you visit medium.com, Medium could choose to store some arbitrary information on your browser that it would like to receive the next time you visit their site. Technically, this can just be any text, really. There are no limitations on what can go inside a cookie. The key thing to remember, though, is that this data is sent to the website with every request you make.

Let’s start with one of the simplest, but most common use cases for a cookie — authentication. Chances are that you log in to at least half a dozen websites every day. Or you visit websites where you’ve already signed in once, and the browser just seems to “remember” that you’re logged in. It would probably be annoying if you’d had to enter your credentials every time you visit the website and certainly very annoying if you had to do so every time you navigated to a new page.

When you visit the website for the very first time, you’re likely prompted for your credentials. You happily enter your username and password. Your browser then sends your credentials to a server, which in turn verifies whether or not they’re valid. If they are, congratulations. You can now access your account. But in addition, the server also sends back an additional piece of data. This piece of data is unique to you and is what the website uses to identify you for all future requests.

Think of this as checking into a hotel. The first time you check into the hotel, you’re asked to provide some form of ID. This is so that the hotel can verify that you’re, in fact, you. But once your identity is verified, you’re given your key tag. You can use this key tag to enter your room, move around in the hotel or order room service. Your identity doesn’t need to be verified since you already have the key tag. It would be a shame if you had to whip out your driver’s license every time you wanted to access the laundry.

Of course, authentication is not the only reason websites use cookies. Another common reason to use them is to store your preferences.

When you visit a website that offers content in multiple languages, you select your preferred language. The website could decide to store your preference in a cookie so that the next time you visit the page, it already knows what your preferred language is.

This is why clearing cookies on your browser can sometimes cause websites to “reset”. Since they’re designed to not store any long term data anyway, clearing them doesn’t usually cause any lasting harm. Cookies are also only accessible to the website that set them. Medium can’t access the cookies set by LinkedIn, and vice versa. This security is guaranteed by your browser. This stops websites from snooping around for your data and accessing your cookies on other websites.

Because of their simplicity, cookies also play an important role in advertising. Just as cookies can be used to identify your preferences and authentication sessions, they can also be used to identify your browsing activities. And although websites can’t technically access others’ cookies, there are some workarounds that can be used instead.

The one downside to cookies is that they get sent to the web server with every request you make, whether or not the server actually needs them. This is great in some circumstances, but other times it might actually just bloat web requests unnecessarily.

Modern browsers offer something called a “local storage” which allows websites to store information directly on your computer instead and access it locally whenever needed. Websites today usually some combination of both local storage and cookies to create the experiences you see!

Regardless, cookies are a simple but powerful building block of how the internet works today. Next time you see a website with an updated cookie policy, you know what you’re signing up for.

The development industry has been seeing a growing towards software that is openly available, shunning proprietary software. For new developers, the reasons for this can be a bit confusing. So let’s try to break things down.

For a piece of software to be open source, it simply means that the source code is openly available for anyone to see, contribute to, and in most cases adapt for your own needs. For example, if you’re curious about how Firefox works under the hood, you can simply visit their source code page and take a look for yourself. Assuming, of course, that you have some basic development knowledge and are able to make sense of the codebases.

You cannot, on the other hand, find the source code for something like Microsoft Office. Or iOS. These software are considered proprietary or “closed source”. The companies writing these software have poured years, if not decades, of research and development into polishing them. From their perspective, releasing the code publicly would not be a great decision.

The differences between open source and closed source software are pretty simple and obvious at the surface. But beyond just the philosophical differences, they lead to very different business models and monetization strategies.

A common perception among a lot of people is that paid software must necessarily be better. After all, the companies are that producing the software need to turn a profit, and so they’re incentivized to make it better so that more people would buy it. Those same incentives simply don’t exist in the open source community.

This is a very logical line of thinking and is true in a lot of cases. But it isn’t true always.

Let’s take Linux as an example. Linux is a desktop operating system just like Windows and MacOS — the two dominant operating systems today. While Windows and MacOS make money directly from end consumers, Linux does not. Instead, it is available for free for anyone to use and modify.

And yet, when it comes to market share of operating systems for web servers, Linux well and truly dominates the industry. And when it comes to supercomputers, Linux has an astounding 100% market share. Price is obviously a huge factor here as companies want to save on licensing fees, but there are also other reasons such as increased security and reliability that make Linux extremely competitive. Similarly, open source databases such as MySQL and Postgres account for nearly 50% of the database market — a number that has been constantly increasing for the last decade.

The prevailing mindset among the open source community is that the software is more reliable simply because of the number of developers working on the project. This would seem counter intuitive but the idea is that because the code is openly available, if there is a bug in the system, sooner or later someone would identify it and put in a fix. The code is available for everyone to scrutinize and dissect making it more secure by default.

At this point, it would be very reasonable to ask how exactly open source software makes money. And the answer is, it depends. Obviously, most people contributing to open source software aren’t going to make any money from it. If you were to submit a patch to an open source library tomorrow, you wouldn’t do it with the intention of making a buck, but rather as a way to give back to the development ecosystem — one that has hopefully favored you a lot too. Tons of open source software are supported by developers working on projects in their spare time.

This does not mean, however, that open source software is all about altruism. Companies like Red Hat, for example, have built multi billion dollar businesses by selling support services and technical expertise on open source software. Companies make money not by selling the underlying software, but rather the infrastructure around it — such as hosting services or technical training.

Additionally, tech companies are increasingly becoming reliant on open source software and so have a vested interested in making sure that the software remains up to date and secure. It is not uncommon for some companies to dedicate developers just to support open source software development. This effectively outsources some of the development efforts to the community but makes the software available to everyone in exchange — a win win situation.

The entire industry is seeing a massive shift towards open source software and regardless of where you stand on its viability, it is important to understand the basic philosophy behind it. Hopefully this post helped with that. If there are other specific topics you’d like to see discussed please leave a comment below! :-)