Fotis Alexandrou - Software Engineer

How to prepare your web application for the cloud

Fotis — Sat, 06 Feb 2021 00:00:00 GMT

Crafting a web application that is able to run in the cloud, is a bit different than an application that is built to run on a single web server and some developers learn it the hard way. In order to avoid last-minute surprises and be well prepared for a cloud migration, here's a list of the things you need to consider while you’re still developing the app.

Develop a mindset first

The first and probably the most important thing you need to develop, is a cloud mindset. We need to think that the app is always running in a distributed way, across multiple, disposable instances, even if you plan to deploy it on a single server with everything bundle in it. This way, deploying or migrating to the cloud will be a much easier process, that requires minimal effort. Notice the word disposable we used to describe our instances; this is going to be key for the next things we need to consider.

You also need to keep in mind that hacky solutions like connecting via SSH to run a script, or directly updating the database are off the table as well (it should be off-the table anyway) since, in our theoretical example, we have 30 server instances, the databases are sharded and there is a cluster of cache servers. We can’t "quickly update" our CSS files or upload a file via FTP either, since every file is stored in an Object store which doesn’t support manual updates and served through a Content Delivery Network (CDN) which means that the original file is cached across the globe.

Sounds complicated? Well, it's a different mindset, which means that it might sound complicated at first but it would then become second nature to you and the way you craft your applications. Not having the server for granted and keeping in mind that all services are external and distributed is the key concept. Now let’s break it down into smalller parts.

File Storage

Media files, user uploads, static assets and everything in between, can only live on the server for a short period of time. The storage on cloud instances is usually ephemeral which means that whenever the instance gets terminated, the disks are terminated as well. Now, there is a way to add persistent volumes even elastic file systems that scale to your needs, but this comes with a cost and it’s not the common case for a web application that say, handles user uploads.

Most cloud providers like AWS, DigitalOcean, Azure and others, use something called Object Storage, which can be eloquently described as "a bucket of files". Such buckets can contain media files, the application’s static files, PDF documents or even larger files that need to be downloaded by multiple users simultaneously.

The two common patterns used to upload files to an Object Store, are either a) directly uploading the files when the user has uploaded them on the app via an API, an SDK or a framework library, or b) syncing the server’s file storage with the object store and deleting the files afterwards, with (a) being the common case and best practice and (b) only being used for cloud migrations, where we need to migrate files that the application used up to now, to the cloud.

Every object (file) in the object store, comes with its own permissions and path, as it would in a plain server, with the only exception that the path is now a URL so, instead of storing a file path in the database, you can now store the full URL for the file specified.

A minor caveat here is that if your files need to be public and directly accessed by the users frequently, an object store might prove to be slow, which means that you need to serve the files via a CDN, that "sits" in front of the object store and heavily caches the files until they get modified or said cache expires.

Static assets, can be stored in the object store as well, since the web servers may hold different file paths, depending on your build process, but what needs to be taken into account here, is that since they’re stored in the object store and served by a CDN, there is heavy caching for them. The most popular solution to this issue, is to have a predictable file hash, which is generated by a build tool so that whenever the application serves a different file name, the CDN will retrieve this file from the object store, and cache it globablly all over again.

Session storage

Storing the users’ sessions in the server is another cloud anti-pattern. In our theoretical example where our application is spawned across 30 web server instances, we can’t have the sessions stored there because the user might be directed to a different instance upon every subsequent request. Someload balancers, mitigate this issue by using "sticky sessions" which is an option that can be enabled and instructs the load balancer to use the same web server instance upon subsequent request but, this option comes with a hidden performance cost.

The actual solution to the session issue, is to have a centralized cache storage that is being used for storing the sessions, something like Redis or Memcache. Luckily, all major frameworks and languages have session storage in a separate store built-in, enabling the web server to forget all about session management, hence making our app cloud-friendly.

Retrieving & storing information in cache

Speaking of cache, we can’t really have the cache as a software dependency in our web server, simply because our web servers are too many and the users request might hit a random server where the cache item is missing. Again, a centralized cache store, where we store and retrieve items via TCP is key here. This way, our cache service can scale up or down, depending on our caching needs and our items are available even if the web server instance gets replaced.

If you find yourself in need of having more control of the cache server though, for example if you force-empty your cache periodically or whenever your database schema changes, you might need to do that programmatically by creating a few scripts that run on your deployment tool.

Scheduled jobs

Scheduled jobs (eg. Cron Jobs) can run on your web serve or dedicated worker instances that only do that. The important thing to consider here, is that the worker instances can scale as well. The problem that arises now that our theoretical scenario has 15 worker instances, is that we don’t want them to proces the same data over and over again because a) it would be a waste of resources and b) we might run into problems. Think for example a scheduled job that processes some data, then emails the users about the outcome. We wouldn’t want our users to receive the same email 15 times, do we?

There are two possible solutions to this issue: first would be a mutually exclusive lock and second would be a queue. These two approaches might sound similar but they aren’t really. During the first approach, we "lock" the data that is to be processed, eg. by updating a boolean flag in the database so that the next worker process that runs, excludes this data from what is to be proccessed by it and so on and so forth.

The second option, is to have a queue (for example a First-in-first-out queue) where we enqueue the data that is required by a job to run (by using some central store like Redis), then the worker processes that start, retrieve and delete this data from the queue so that it’s only available to the specific process.

One caveat here, is failure strategy, which means that whenever a worker fails for some reason, they need to somehow handle that, so that no job (or data) gets lost. Practically, you’d have to enquque the message with its original payload again so that another worker picks it up and/or notify the team that something went wrong.

Database migrations

In the beginning of this article, we mentioned that we can’t perform manual database updates, an action which is an anti-pattern in general, not only cloud-based applications. In cloud environments however, the database might have replicas or it can be sharded, making a manual update somehow more difficult.

The solution is to treat every database update as a code change, meaning that your application should leverage database migrations, scripts which handle database versioning in order to update its data and schema.

Conclusion

Crafting a web application for a cloud-based environment relies mainly on a different mindset which forgets all about "the server" and thinking about "the services". Most frameworks and tools these days make our lives easier by embedding cloud tools in our work flow however, we as developers have the responsibility to enable these technologies and use them to the benefit of our users and ourselves.

What to consider when choosing a new tech stack

Fotis — Tue, 26 Jan 2021 00:00:00 GMT

When it comes to creating a new stack, all options are on the table. Some people find it as a fine opportunity to learn a new stack, others prefer stuff they're already familiar with, some others prefer to distribute their codebase in micro-services consisting of various micro-stacks. This process, has triggered a lot of flame wars on Twitter and offices around the world but, believe it or not, performance benchmarks and your peers opinions are not the only metrics you can take into account.

Selecting a technology stack is hard, and requires serious thought, so let's break down the major things you need to consider before creating that git repository and we’ll do that by going through my professional experience, mistakes and flame-wars I had been a part of, so that you don't have to.

<figure class="w-full"> <img class="h-auto max-w-full rounded-lg" src="/images/tt.jpg" alt="image description" alt="Tech team"> <figcaption class="mt-2 text-sm text-center text-gray-500 dark:text-gray-400"> Photo by <a href="https://unsplash.com/@heylagostechie?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">heylagostechie</a> on <a href="https://unsplash.com/s/photos/tech-team?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></figcaption> </figure>

The right tool for the people involved

Every stack will be as useful as the hours and hair it saves for the people developing on it and operating it. Having said that, it's only obvious that your choice should be directly related to your team, whether it's present or not. Two distinct cases here, first would be that the team is already in place which means that the stack’s choice should be based on the team’s modus operandi and another one, for when the team is work in progress.

When the team is already in place or if the team consists of just yourself, the obvious choice would be to go with what they already know. However, there's certain fatigue after some time and people might lean into trying out something new, or the technology that the team is already working on might start to feel outdated. That's when you need to get in touch with your team leaders and really listen to them. Diversing your stack means that you’ll need to have people that are experts in the new field and besides that, you’ll have to factor in the cost for their learning, the technical debt and operations. There also has to be a critical mass that shares the same expertise, since you can’t rely on a single team member to be the source of truth. On the other hand, if you follow an already trusted technology stack, you will be able to deliver faster, the problems you will face will seem as just practice and there might already be a knowledge base for issues that may come up.

Regarding the second case now, you're on a clean slate. You have the freedom to choose any person to join or lead your team, however I’d do some research first; I would research the developer communities for the stack choices I'd have in mind, then look into their rates and activity and compare it with the prospect team size I'd have in mind. It may sound trivia and you might think “oh! the internets will help me find candidates” but it may not seem as easy as it sounds. Building a development team, is actually more on making highly skilled professionals work well with each other so you might have to think twice about your team’s structure.

The right tool for the job

The tech stack is a fun playground where projects come into life, however, projects are defined by timeline, budget, project scope, integrations and scale, among others. Breaking them down into chunks, will help us decide what the right tech stack for the job is:

Tight deadline, limited budget or disposable projects: Most of the times, the right tool for such jobs is something that's “batteries included”, meaning that the suggested solution, should provide all the necessary tooling out of the box or in a way that's saving considerable amounts manual labor and time compared to another solution. For example, a rapid prototype for a product, a disposable “proof of concept” app for a startup, can be made in such a way by using a framework, CMS or site-builder that’s basically designed around solving this problem fast and efficiently.

Highly performant projects: For a project that is designed to receive thousands of requests per second right from the beginning of its lifetime, you may need to bring back in those performance benchmarks we mentioned earlier. Beware, there's a trap here: if you ask the project’s shareholders what the traffic projections for the project are going to be, they will most likely reply with massive numbers and it's expected, since they're vested into the business and they aim for success. However, experience shows that scaling issues will come up gradually and not from day one when the project is not part of an already ongoing project that’s facing massive traffic, allowing you to mitigate them which is cheaper than bullet-proofing your app to prevent them. I'm not implying you should violate all rules and build something that's slow, all I'm saying is don’t over-engineer or over-provision the project and don’t build for massive scale before you wet your feet first.

Projects that rely on integrations: Usually, the integrations that need to take place, are well established software that are either deeply integrated into the project (ie. the project is built around a specific piece of software by using some adapter), or act as an external service, often via an SDK that allows communication over networking. In the first case, the technology is sort of dictated by the integration itself, for example if you want to build a library around Ansible, it has to be done in Python because Ansible itself is written in Python and it would take a lot of effort to use another language, so the decision is easy. In the second case, there are more options however, you need to check whether there is an SDK available and whether it's a stable, fully-featured library.

Open source or portfolio projects: These types of projects provide plenty of room for experimentation, and is actually the right place to show off and play around with various new technologies.

<figure class="w-full"> <img class="h-auto max-w-full rounded-lg" src="/images/tool.jpg" alt="image description" alt="tools"> <figcaption class="mt-2 text-sm text-center text-gray-500 dark:text-gray-400"> Photo by <a href="https://unsplash.com/@hnhmarketing?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Hunter Haley</a> on <a href="https://unsplash.com/s/photos/tool-set?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></figcaption> </figure>

Choose technology that is already familiar, documented, proven & stable

One mistake most of us have ran into, when it comes to using some new technology is that we fall into the hype trap. The internet is a magical place full of potential, advertisements and hyped up new technologies and we, developers like to experiment with all the shiny new objects!

While adding a piece of technology into your stack, you might need to look into the maturity, stability and documentation of it. It also has to be actively maintained and adequately documented. A large following on StackOverflow that would help you with the problems you will run into, wouldn't hurt either.

Speaking from experience, my team once integrated a fairly young document-based database into one of our projects and I bet you are familiar with the product owners’ line: “since this worked for this feature, let’s build on top of that for the next 5 features”. Pretty soon, after torturing ourselves with poor adoption which leads to poor documentation online compared to its older rivals, this database became mission-critical, but we were happy. Until one day they ran out of money and time, and their contributors decided to jump ship, and then we were sad. We didn‘t have the time or resources to maintain the database ourselves of course, so we had to migrate everything into our existing PostgreSQL database which was introduced in 1996 and it’s still one of the most popular open source relational database systems available. This is of course an edge case and doesn’t happen every day, however I’ve seen frameworks, libraries and other utilities die frequently so try to be cautious by making sure everything my team relies upon is current, actively maintained, well documented, stable and most importantly, properly tested.

Sometimes, using such technologies may sound boring and I’m pretty sure there will be other, fancier solutions that will sound much more interesting but that’s exactly the issue. Boring technologies are usually stable, well tested. Ruby on Rails for example, provides the same paradigms and interfaces for the past few years and that may seem boring. The counter-argument to that, is that it took many years for Rails to become “boring” and through the course of those years, thousands of commits were added to make the framework a stable and reliable solution that powers billion-dollar companies all around the world.

If your team is small, a monolith is just fine

I think the title is self-explanatory here, but let me explain why in a screaming Adam Sandler voice: because of all the duplication and networking requests and the operational maintenance your team has to go through. Which leads me to the next chapter:

Running & maintenance costs

There are two types of costs when working with a new technology stack: Implementation and running cost. The first is pretty straight forward, the latter can be predicted, but what about hidden costs? For example how much does it cost to replace a certain piece of the stack and how much technical debt would it introduce?

<figure class="w-full"> <img class="h-auto max-w-full rounded-lg" src="/images/sib.jpg" alt="Simple is beautiful"> <figcaption class="mt-2 text-sm text-center text-gray-500 dark:text-gray-400"> Photo by <a href="https://unsplash.com/@jeffreymwegrzyn?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Jeffrey Wegrzyn</a> on <a href="https://unsplash.com/s/photos/simple-is-beautiful?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></figcaption> </figure>

Don't get fancy

They say “Simple is beautiful” and I can’t really stress this enough: if your technology stack uses 10 different technologies, you’ll have to multiply your web searches for hair pulling bugs, times 10, your package upgrades, your technical debt times 10 and so on. Keeping your stack as simple as you can, will help you focus less on administrative tasks and more on writing features and their tests, that will help the business succeed.

Conclusion

Choosing a technology stack is hard and requires a lot of thought. It’s also a process which affects you team’s day-to-day life and may introduce more costs than you initially accounted for. Don’t get blinded by shinny new objects, choose what works best for your team and your business. Even if it’s a fairly old, boring “been there, done that” piece of software.

Testing your code is not optional.

Fotis — Sun, 20 Dec 2020 00:00:00 GMT

Let’s start with a story...

A quadrillion years ago, I used to work for companies none of which had automated tests in place and believe it or not, testing was not that popular; We wrote the code, tested manually on our local machines, deployed our newly committed piece of art and called it a day. If however, something went wrong, we tried to replicate the issue on a test environment, fixed it, deployed the fix and so on, usually hoping that the fix wouldn't introduce a regression.

Then, writing unit tests somehow gained traction and became popular among developers who liked following best practices but still, there was a lot of ground to be covered in fast-moving startups and agencies, where delivering projects is a time-sensitive thing. I even remember debating the lead developer of a VC-backed startup, who at some point insisted that testing is a waste of time and that's why they didn't do it.

So, is testing our code a waste of time?

No, it's not! Believe it or not though, this was (hopefully isn't anymore) a somehow acceptable opinion a few years back. While testing may require some development time, it actually helps save enormous amounts of time if done properly.

Let's think of the following scenario:

A developer works on Feature X for a few days, completes their work and pushes code to the testing environment.
Then, a QA or the developer themselves tests manually, finds a couple of issues which are then fixed and the project hits production.
The code then interacts with user-input or other existing data in a database and errors occur.
The Product Owner raises a ticket, assigns the QA, the QA reproduces the issue, adds technical information to the ticket, sends it to the developer, they apply a fix and the ticket goes back n forth between the stakeholders until the code hits production.

In the meantime, there might be regression issues and the back n forth continues until at some point the ticket closes, while several others have been raised.

Chaos? Yes. Reminds you of something? It certainly does for me. This was the daily, fire-fighting routine for the lead developer that was mentioned earlier.

Having an efficient and detailed testing suite in place, saves you some of this trouble; The code and tests are written, the QA does what they're supposed to do, (make sure the finished product meets certain quality standards), instead of getting blocked becaused they stumbled upon a tiny mistake that could have been caught beforehand. Ideal? Maybe. Let's now break down the several ways we can save time.

Testing is a safety net, but also a documentation and developer onboarding tool

Usually, the scope of a function is (or should be) limited and, depending on the input, there are certain outcomes. Covering a few default cases, should be a nice way to test said function and save ourselves (and the QA) some time being stopped by runtime errors that would easily be prevented.

If however not all cases were covered and some bug gets reported, it's fine (in fact great!) because this means we're enhancing the testing suite with another case, making our code even more resilient.

Along with this benefit, there lies another: Tests are a great (yet, not the only) documentation and onboarding tool, which means that they should be clear, descriptive and be able to provide a high level overview of what the code should accomplish.

For example, here is an excerpt from a few tests I wrote for a Django view that launches deployment operations:

def it_creates_and_runs_an_operation_given_a_commit_reference(mock_user, create_operation_data):
    # ...
    assert response.status_code == 201
    assert response.data['id']
    assert response.data['kind'] == 'deployment'
    # ...
    assert operation.is_running

def it_creates_and_runs_an_operation_without_a_commit_reference(...):
    # ....
    assert operation.is_running
    assert mock_celery_task.call_count == 1
    assert operation.reference == expected_commit_information['reference']

def it_does_not_start_the_operation_when_another_is_queued_prior_to_it(...):
    # Create an operation that is queued prior to the one we're queueing
    prior = operation_factory.create(...)
    # ...
    assert response.status_code == 201
    # ...
    assert not operation.can_start()
    assert not operation.is_running
    assert not mock_celery_task.call_count
    assert operation.is_queued

We now have of tests, groupped together with descriptive names, that provide an outline that an operation can be started with or without a given reference, and what the expected statuses for the model in the database and the returned HTTP status code should be. When I revisit this example in the future, or whenever a new hire joins the project, it will hopefully be obvious to them, what the expected behavior should be without having to read long documentation. Also, it covers three of the most common cases in the system, related to the "operations" feature.

Keeping tests fast & testing the right things

Assuming you are using a web framework like Django or Ruby on Rails and you need to test an ORM or an ActiveRecord model, it doesn't make any sense to test the .save or .get methods, because they're already tested for you by the amazing people that build the framework of choice. However, testing a custom validator you have added to your model is a requirement.

The scope of a test should be limited as well. Let's take the following real-world example where we use pytest (with some syntactic sugar) to test a celery task that starts a queued deployment operation. The create_container function runs a Docker container, but testing this is a) out of the given scope and b) slow if we create the actual container. The solution to this issue would be to mock the create_container call within the current scope:

@pytest.mark.django_db
def describe_start_operation_task():
    def it_runs_the_task(queued_deployment, mock_container):
        allow(tasks).create_container.and_return(mock_container)
        assert not queued_deployment.task_id
        assert not queued_deployment.container_id

        # run the task
        celery_task = tasks.start_operation.s(operation_id=queued_deployment.id).apply_async()

        # make sure the deployment fields were populated accordingly
        queued_deployment.refresh_from_db()
        assert queued_deployment.task_id == celery_task.id
        assert queued_deployment.container_id == mock_container.id

Sandi Metz and Katrina Owen in their great book 99 Bottles of OOP, clearly and constantly state that the tests should run upon every line of code that gets changed and they're right. In practice, this means that you should be able to run all your test suite as fast as possible.

In our example, we managed to save quite some time by mocking the docker container creation, which is handled internally by a well tested library. Other examples might include external network requests, big files loaded, email sending etc.

You might also have noticed in my examples that there is a certain degree of duplication. This is fine. The tests are not a place to practice DRY; they should be explicit and detailed in order for the other person to be able to understand every tiny bit of the process, but also, doing fancy things usually leads to errors and you do want your tests to be straight-forward and valid.

Meet your new best friends

In the examples provided above, I introduced a few concepts that you might not be familiar with so far, but will become your new best friends when you dive deep into testing: Factories, Fakes, Fakes, Stubs and Mocks. Here's some basic guidelines that would help you decide what you need each time:

If you want an object and with random data, register a factory.
If you need an object with specific, predictable data, go for a fixture.
If you need a simplified version of a method or a class, with limited functionality, fake it.
If you need a set of predefined data returned by a method, stub it.
If you just need to count the calls to a method, mock it.

How having a proper test suite improves your code

Writing code with testability in mind, eventually leads to cleaner code, simply because in order to keep the tests simple, one has to write short-scoped code that is limited to specific things. Long methods that do several things are as hard to test as to maintain so, having testability in mind, meaning that you have to test such pieces of code, practically acts as an incentive to keep the code maintainable.

Finally, refactoring and cleanup tasks, are a lot safer when the code is covered by reliable tests that will stop your deployment when something breaks, which makes such tasks a breeze for the developer.

There's no strategy that's better than others

I am aware that picking a testing strategy and policy could be a difficult task, however I don't think that a team should stress about it, also it should be a choice that's adapted to the team's modus operandi, so that they adapt easily to it and it doesn't seem like a huge shift from what they had been doing so far.

If the team wants to practice BDD and that's something that suits the project, it should be OK. If the team doesn't feel OK about doing TDD where they should write tests in advance, that should be fine as well, because the purpose is to save the team's time, not force strict policies. I am aware that methodologies exist for a reason, but experience shows that as long as the team are not practicingFDD, it should be OK.

Conclusion

No matter how experienced or good we are at what we do, we will make that mistake. In order to avoid that annoying RuntimeError that will disrupt our user's delightful experience, we have to make sure that our code works well no matter what and luckily, we have the tools to do so. Embrace testing, focus on covering as many scenarios as you can and feel comfortable deploying. Even on Friday...

How to fix Sectigo's expired root certificates

Fotis — Sat, 30 May 2020 00:00:00 GMT

As of today (May 30th 2020), Sectigo's root certificates that are usually bundled with any SSL purchase (in my case it was on February 2020, just 3 months ago), are due to expire. Here's a short post on how to deal with this, so that you don't pull your hair as I did.

The problem

You might not be able to identify the issue at once, the browser will display the SSL certificate just fine as it's still valid, however if you have any curl calls or in my case, alerting software such as Pingdom or OpsGenie, you will be getting alerts.

I initially thought it was some system issue but turns out it wasn't, once I ran an SSL test via SSL Labs which showed my intermediate certificates as expired.

The solution

Head over to this support announcement from Sectigo and don't get lured by the "You don’t have to reinstall your certificates" thing. It's clear that it only refers to sites that are being accessed through browsers.
Scroll down and try to identify the modern roots (COMODO RSA/ECC Certification Authority and USERTrust RSA/ECC Certification Authority) and pick the one according to your Certification Authority.
On the pages that open, search for "Download" and download the new roots. Weirdly enough, you'll get file names that only contains digits. Rename them to USERTrustRSAAddTrustCA.crt and AddTrustExternalCARoot.crt accordingly.
Find (or download again) your SSL certificate package, and copy the folder with a different name (eg. STAR_hudabeauty_com_new_sectigo_root)
Replace the files AddTrustExternalCARoot.crt and USERTrustRSAAddTrustCA.crt with the ones you had just downloaded
Chain the certificate again using the order required. On a *nix system the command should look something like that:

cat YOUR_certificate_name.crt \
    AddTrustExternalCARoot.crt \
    SectigoRSADomainValidationSecureServerCA.crt \
    USERTrustRSAAddTrustCA.crt > YOUR_chained_certificate.crt

You now have a new SSL certificate in place, you can copy it over to your server or use it in your Certificate Manager (if you're using any).

Hope this saved you some time.

Using a React Component as a Layout with ReactOnRails

Fotis — Sun, 10 Mar 2019 00:00:00 GMT

New year, new codebase for a side-project of mine, and I decided to go with ReactOnRails, turbolinks and other sorcery that will help me go faster but won't sacrifice code quality.

An issue I found with this approach is that it wasn't clear to me how to render a React Component as a layout, since the yield call in my application.html.erb would render the <%= react_component ... %> part in the view, as described in the ReactOnRails README file. Here's the way I found in order to do so:

Added a react_layout method in my controller. That way I can overload this method in child classes

# file app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  def react_layout
    'LayoutDefault'
  end

  def react_layout_props
    { user: { id: current_user.id } } # ... fill in your layout props
  end
end

Created a ReactHelper module with a react_view wrapper method, which utilizes react_component internally.

# file app/helpers/react_helper.rb
module ReactHelper
  def react_view viewname, props: {}, layout: nil, layout_props: {}
    layout ||= controller.react_layout
    layout_component_props = controller.react_layout_props.merge(layout_props)

    react_component(layout, props: layout_component_props.merge({
      component: viewname,
      componentProps: props,
    }))
  end
end

Replaced calls to react_component with react_view, for example

# file app/views/dashboard/index.html.erb
<%= react_view("DashboardView", props: @props) %>

Dynamically rendered the component requested in the view inside LayoutDefault.jsx

// store this in a location resolvable by webpacker
import React from 'react';
import PropTypes from 'prop-types';

const LayoutDefault = ({ component, componentProps }) => {
  const ViewComponent = ReactOnRails.getComponent(component);

  return (
    <React.Fragment>
      ... Layout area ...
      <ViewComponent.component {...componentProps} />
      ... Layout area ...
    </React.Fragment>
  );
};

LayoutDefault.propTypes = {
  component: PropTypes.string.isRequired,
  componentProps: PropTypes.object,
};

LayoutDefault.defaultProps = {
  componentProps: {},
};

export default LayoutDefault;

And done. The app now renders the react layout and the component I've requested in my view inside.

Pro tip: You need to declare ReactOnRails as a global in your eslint config if you're using a linter (which you should)

Understanding variable assignment in JavaScript

Fotis — Wed, 21 Mar 2018 00:00:00 GMT

Hello `var`, old friend

In days of yore, using var was the only way to declare a variable. Those were interesting times, when developers dealt with hoisting all the time, leading to hair-pulling bugs and unexpected behavior. To better understand what hoisting is, think of the following example:

a = 5;
var a;

console.log(a);

This would actually print 5 instead of undefined, since the compiler hoist the variable declaration within the associated scope and translate the snippet above into

var a;
....
a = 5;
console.log(a)

Same principle applies to functions so the following snippet

foo();

function foo() {
  // magic here
}

where the function declaration will get hoisted within the scope but please note this isn't the case of function expressions, which means that the following example

foo();

var foo = function () {};

would throw a TypeError such as Uncaught TypeError: foo is not a function

ES2015: `let` and `const` are introduced

Fast forward a few years, the let and const keywords got introduced which, along with var, are more ways to bind declarations to their associated scope. By using let we're able to declare bindings that can be reassigned, such as

let a = 5;
...
a = i + b + n;

and so on. This isn't the case with const though, since creates bindings that can only be assigned once, meaning that a block like the following

const a = 5;
a = 12;

would throw a TypeError such as Uncaught TypeError: Assignment to constant variable and so would assignment operators do like a += 10, a++ or even bitwise operators like a <<= 1.

Now, a common misconception that people make (myself included in the past), is that const creates immutable variables which is not the case. const variables are perfectly mutable as shown in the following (working) example:

const obj = { a: 1, b: 2 };
obj.c = 3;

console.log(obj);
// Prints  {a: 1, b: 2, c: 3}

In order to actually make an object immutable, one should use the Object.freeze() method which on strict mode would raise an error, or fail silently otherwise. Please note though, this only performs a shallow freeze, which means we're still able to mutate the properties of the nested obj.o object as on the following (working) example:

const obj = Object.freeze({
  a: 1,
  o: { name: "G.I. Joe", cobra: false },
});

obj.o.cobra = true;

console.log(obj);
// Prints { a: 1, o: { name: "G.I. Joe", cobra: true } }

To make matters a bit more complex, JavaScript provides the Object.seal() method, which prevents new properties from being added to an object and marks all existing properties as non-configurable, but also Object.preventExtensions() which only prevents new properties from ever being added to an object.

If we'd like to compare the three, we'd summarize as follows:

Object.freeze() makes an object's properties immutable, while nested objects' properties are still mutable. Example in non-strict mode:

const frozen = Object.freeze({ a: 1, b: 2 });
frozen.a = 4;
delete frozen.b; // returns false
console.log(frozen);
// Prints the object in its original shape  { a: 1, b: 2 }

Object.seal() allows properties to be changed, prevents them from being added or deleted. Example in non-strict mode:

const sealed = Object.seal({ a: 1, b: 2 });
sealed.a = 5; // property "a" now has a new value
sealed.c = 12;
delete sealed.b; // returns false
console.log(sealed);
// Prints the object without the new properties added but with property "a" mutated  {a: 5, b: 2}

Object.preventExtensions() allows properties to be changed and deleted, prevents new properties from being added. Example in non-strict mode:

const prev = Object.preventExtensions({ a: 1, b: 2 });
prev.a = 5;
delete prev.b; // returns true
console.log(prev);
// Prints the object with a new value for property "a", without the deleted property "b"  {a: 5}

Credits

"ES2015 const is not about immutability" by Mathias Bynens
"Hoisting" on You Dont Know JS
"Block Scoping Revisited" on You Dont Know JS
Object methods on MDN

Being efficient as a remote worker: a study on productivity

Fotis — Mon, 12 Mar 2018 00:00:00 GMT

Either as contractor or full-time employee roles, remote work is a popular trend globally as many companies prefer this type of distributed setup in order to take geographic restrictions and other limitation out of the equation that sets the path to their success. Working remotely is no different than any office job — or at least it shouldn't be — so being a remote worker myself, I thought it would be handy to document the processes I use to work & collaborate effectively as I would on an on-site job.

The workplace and dress code

First and most important is having an isolated space. Personally, I was lucky enough to own a tiny space (I think the word studio is appropriate), in walking distance from my house, that I decided to renovate and convert it into an office space. This gives me the benefit of having to walk to work, which means I have to wear clothes, shoes and actually go to work. Let me quickly refer back to the word "isolated" now, which for me is a key ingredient of efficient remote work; There's no absolute need to rent or buy some space outside your house if it's spacey, it may as well work if there's a spare room or a quiet corner that you can isolate yourself into and can be named "the office".

Attitude is a big part of effective remote work and I've found that having a dress code is important; One wouldn't walk into an office in their jammies or a t-shirt with a ketchup stain on, so why should they do it when working remotely? After all, video calls are part of the game, so being presentable is a must.

Also, forcing yourself to walk for a few minutes (go to the cafe and grab a cup of coffee for example), can prove to be quite helpful as it stimulates the brain, creates the illusion of commuting and prevents you from staying in for days if the office is located inside the house.

Last but not least, clearly stating to yourself and others that you're "at work" sets the tone for how you and your circles approach remote work.

It's all about routine

Daily commute is part of the daily routine for office workers and so is the morning coffee preparation and chit-chat with their co-workers. Remote work eliminates the word "commute" from the last sentence, but it shouldn't alter the essence of it, meaning there should be a routine in place. The main reason behind having a routine, is that our brain has a limited number of decisions it can afford per day, so having a few decisions taken care of, along with a steady sleep pattern, reserves energy and congnitive strength for the hard part of every day: the actual work.

Having a strict timeframe where you walk in and out of the office, is really helpful and can prevent one of the major downsides of working remotely: working all day (and / or night). Yes, contrary to popular belief, remote workers actually work very hard and are very engaged in their work so working the long hours is a common, harmful pattern. Without going into too much detail, working the long hours pattern is harmful because you need energy and time for both working the next day but also for the parts of the day that don't involve work such as friends and family, so having a clear time frame which you should utilize to accomplish everything, has an incremental effect on your productivity.

Planning everything

While trying to avoid the long discussion about estimations — let's assume that the estimations are close to perfect for now — let me just say that missing a deadline is a terrible thing, but it can happen to anyone. Another downside to that is that while the deadline is approaching, one may find themselves working the long hours and derailing their day to day schedule. Planning right and planning daily is the one technique I've found to be most beneficial.

For example, I always have a notebook and a sharpened pencil right next to me. This helps me quickly draw a diagram or write down the basic outline of a class, but I also reserve one page every day for my daily schedule. That being said, I start off every week by outlining the high-level tasks I'm gonna work on, assign the days to them, then quickly move to scheduling my entire day and I mean everything; I break down every task into subtasks that I estimate how long are going to take, then write them down with the actual time of the day that I'm gonna work on them and apply the same pattern to breaks, conference calls, lunch and so on. This works like a charm because of two reasons; First, breaking down a task into tiny pieces, no longer makes the task intimidating (even if one is extremely experienced, a big task is more intimidating than they might think) and instead of over-thinking it, the steps to achieve the task are now in front of me. Second, it's an exercise for my estimation skills which means that I daily practice my answer to the question "how long is this going to take?"

Pomodoro technique and Deep work

The Pomodoro technique is a well known practice among software engineers; You set a timer to 25 minutes, completely focus on a task for 25 minutes, then take a 5 minute break and repeat for all the tasks in your list. This sounds very interesting but I found out that it doesn't actually work for me, as there usually are tasks that require my focus for more than 25 minutes, so I resorted to Cal Newport's approach on Deep Work. Newport in his book, states that large portions of deep, focused and uninterrupted work are key to producing great output but he also mentions (among other Deep Work patterns) that some people achieved optimum performance when 90 minute intervals of deep, meaningful work (eg. engineering a demanding feature on a website) are followed by 90 minute of shallow work (eg. a video call or going through your emails) so, following that example I organize my tasks in a way that follow that pattern. I try to be somehow loose about it and not restrain myself to the 90 minute limit, so I group my tasks into 70-100 minute windows and follow up with just 30-45 minutes of shallow work when necessary or a short break.

Avoiding distractions & Prioritizing communication

There are two ways a distraction can work: you're either the distracted or the distracting person and it has the same damaging effect; The other party has to shift their focus from their current task to the distraction, then once they're done with this, shift focus again to what they were previously doing. This is terrible because most of the times when being in a state of "flow" or deep work (the state that you're so focused that you perform the work with the same ease an established musician plays their hit song), it takes some time to get back to it. The solution to that, is having a policy about distractions and prioritising communications, while clearly communicating this policy with your colleagues and inner circle.

Having a policy about distractions means that you actually take some time and customize the notifications that are sent on your smartphone (the source of all distraction), unsubscribe from newsletters you don't actually read, ruthlessly report as spam every email that you haven't signed up for and quitting social media. I wouldn't advise to go too far and announce "Hey everyone! I'm quitting social media! That's it. We had a good run but now I'm off, deleted everything", just quit (and turn their notifications off). The benefits are remarkable, you're not missing out to anything — unless you think it's a matter of life and death that you read your friend's rant about today's headlines — and you'll find yourself having a lot more time to be really social (as in meeting someone in person).

Prioritizing communication is another key aspect; My policy here is that I never call anyone impromptu, or broadcast messages that might trigger a notification to our messaging tool, have customized notification policies for every software that triggers one, then apply the following pattern: Most of the times the issue I'd like to discuss is not urgent, nor requires the immediate attention of other people involved so, an email or a public message on the communication channel would do. If the issue I need to communicate to another person for is kind of urgent but can wait for a couple of hours, I'd send a direct message, while on the other hand if the issue is critical (meaning that it's a matter of life and death for the business I'm affiliated to — for example a service is down), I'll try to get face time. This strategy can be communicated with your colleagues, supervisor and inner circle, as not all people are familiar with the effort required to stay focused at all cost — for example you might be the only person working remotely in the company.

Avoiding distractions also means that you're not interrupting what you do in order to reply to emails the moment they arrive, daydreaming about a weekend on the beach, preparing coffee, grabbing a soda, having a friend by and so on; The office is isolated for a reason, it should remain as such and remember the attitude: you're at work.

Getting stuck

The hardest part of working remotely is getting stuck; it's very easy to feel in despair and start spreading distractions like a disease, so the ultimate cure is prevention. First, admit that getting stuck is part of the job description as you're trying to solve hard problems all by yourself, isolated, staring at your screen(s) so before you take on a difficult task, try to identify issues that may cause you to google repeatedly for a considerable amount of time and pick your colleagues' brains about them. If you're already in the middle of the task and you can't distract anyone, try talking to yourself — it's not as embarassing as it sounds — a technique called rubber duck debugging, as if you would explain the issue to a complete stranger. In case that doesn't work, just distance yourself from the problem and try to see it as an external party whilst, if you have the luxury of time, engage on some physical activity like a short walk. Walking helps you think because it stimulates your brain and the less busy the walking path is, the better (ie. prefer a walk in a park over a busy street where your brain is actively trying to avoid obstacles). Finally, do a bit of self exploration, because the danger of getting stuck due to a personal issue might be lurking there (for example being tired, or in a bad mood because of an argument with a loved one). Notable mention: don't panic, there are always other approaches you can tackle an issue by.

Keeping a worklog

Sharing updates with your supervisor or clients is important while working remotely. It's an active way to stay in touch and eliminates the need — that you or your supervisors might feel — to prove that you're working by instantly replying to messages or emails. It doesn't have to be super detailed, just an outline of what your current status and what your plan for the next day are. This could as well be a scrum call or a regular email that gets sent out at the end of the day.

Shutdown ritual

Being disconnected is key in being productive so at the end of the day in my case, I just make sure everything that was planned for the day is done, I send out any last emails that are important for the following days, plan the next day and just disconnect. I walk home and then do only what's not work related for example play board games with my daughter, have dinner with my family, read books, watch movies, study, practice and sleep. I avoid checking on emails and phone (with the exception of monitoring tools that might occasionally notify me if there's a critical issue in some service that requires my attention — ie. a website is struggling or down).

Socializing, coffe-breaks

Working remotely means that you don't spend time in restaurants or bars with other colleagues after work, you don't have lunch in the company cafeteria, or the mornign cup of java (no pun intended) while exchanging jokes with a teammate. This is an issue that has to be addressed, since being social is essential to being human. Some suggestions: Having a hobby that requires one to go somewhere, for example, I took guitar lessons every Friday (yes, I was 32 at the time) and it was great because it was a nice chance to disconnect, focus on something that is completely unrelated to what I do every day and interact with other humans (apart from when I studied guitar at home, where nobody wanted to be nearby — apparently I'm not good at guitar, but that's a different subject). Meeting friends for a cup of coffee, movies or drinks is undoubtedly required and helps eliminate the danger of being sucked at what you do, sets a marker on the daily schedule and reminds us what being human is all about: interacting with other humans.

Bonus point: reading lunch breaks

A 45 minute lunch break is vital for the routine, as food provides the energy and stimulates parts of the brain that are responsible for feeling happy. Being away from screens while having lunch is important so I've found that reading a few pages that work related (for example science fiction, literature, essays), improves my focus throughout the day and if I can fit a 10 minute walk in this time interval it can work like magic. Only issue with that, is that it only works when the schedule is not very demanding, otherwise it can act as a distraction.

Credits

Images were downloaded from Unsplash
Why walking helps us think an article on The New Yorker
Stanford's take on how walking improves creativity on their blog
Buffer's State of Remote Work 2018 on their blog
My review on Cal Newport's book "Deep Work" on this blog

How to downsize a root EBS volume on AWS

Fotis — Wed, 14 Feb 2018 00:00:00 GMT

When it comes to increasing the size of an EBS volume, AWS provides clear options and documentation for that. But what happens when you were optimistic about the usage of your root EBS volume or you've now moved most of your data to S3, Glacier or EFS? AWS doesn't give you the option to downsize your root EBS volume but luckily there's a workaround; we can just replicate our (large) volume into a smaller one, and use that as a replacement. This post is a thorough break down of all the necessary steps you need to take in order to do that:

Before you even think about starting, get a snapshot of the volume you want to downsize.
Make sure you read the first step and get a snapshot of the volume you want to downsize (I think it's clear now that you need to backup everything and get a snapshot :P).
Stop the instance that the volume is attached to
Detach the volume from the instance. For the sake of this how-to, we're gonna call this the "old volume"
Create an EBS volume of the desired size, and we're gonna refer to this as the "new volume". In the image, you can see I have the 500GB volume I need to downsize to 80GB.

<div class="image fit"><img src="/images/ebs-1.jpg" alt="EBS Volume downsize - Create the new volume" /></div>
Launch a new EC2 instance. A t2.micro or even a t2.nano would do, and make sure have the right SSH keypair, so you can connect to the instance, which we'll call the "new instance" from now on.
Connect to the new instance via SSH.
By using the AWS Console, attach the volumes to the new instance as follows:
- The old volume as /dev/sdf which in the new instance will become /dev/xvdf
- The new volume as /dev/sdg which in the new instance will become /dev/xvdg
<div class="image fit"><img src="/images/ebs-2.jpg" alt="EBS Volume downsize - Attach the volumes to the new instance" /></div>
Make sure the file system you're trying to resize is in order by running sudo e2fsck -f /dev/xvdf1. If you're resizing a different partition on the drive, change the number 1 to the partition number you wish to resize.
If any errors came up via the e2fsck command, head over to this page to get the right command for the fix. Don't panic :)
We now need to shrink the filesystem to its lowest possible. This process is key for us because we're gonna use dd to copy the contents of the old volume bit by bit. Run:
```
sudo resize2fs -M -p /dev/xvdf1
```
(or change the "1" to your corresponding partition) and make a note of the last line it will print. It will take some time, but the last line would eventually look something like:
```
The filesystem on /dev/xvdf1 is now 28382183 (4k) blocks long.
```
Convert the number of 4k blocks that the resize2fs command printed into MB and round it up a bit, for example 28382183 * 4 / 1024 ~= 110867, so round it up at 115000.
Copy the entire old volume device (not just the partition) to the new volume device, bit by bit so that we're certain we have both the partition table & data in the boot partition:
```
sudo dd if=/dev/xvdf of=/dev/xvdg bs=1M count=110867
```
This is going to take a few minutes, you might as well make some coffee & read a book in the meantime.
You might think (as I did) that we're done, but we're not. You need to follow the next steps in order for your volume to be bootable. Otherwise you'd waste time trying to boot from this volume (as I did). The important thing here, is to use gdisk in order to create create the partition table:
- Fire up gdisk in order to start fixing the GPT on the new volume
```
sudo gdisk /dev/xvdg
```
  You'll get a greeting message and you'll be navigating to your menus by entering letters from now on. You can hit ? if you require help at any point.
- Hit x to go to extra expert options
- Hit e to relocate backup data structures to the end of the disk, then hit m to go back to the main menu
- Hit i to get the information of a partition, then 1 (the number one) to get the information for the first partition on the device
- It would look something like that:
```
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: DBA66894-D218-4D7E-A33E-A9EC9BF045DB
First sector: 4096 (at 2.0 MiB)
Last sector: 1677718200 (at 80.0 GiB)
Partition size: 1677308700 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'Linux'
```
  Copy the GUID under the Partition unique GUID label, (eg. DBA66894-D218-4D7E-A33E-A9EC9BF045DB) and the Partition Name (eg. Linux)
- Hit d and then 1 (the number one) to delete the partition, followed by n and 1 in order to create a new partition on the device
- You'll be asked what your first sector would be, add 4096, then follow the defaults (let it allocate the rest of the disk), then add 8300 as the type (Linux Filesystem)
- Change the partition's name to match the information you've printed before by hitting c, then 1 (for the first partition) and then add the name that the partition previously had (in our example Linux)
- Next, change the partition's GUID by hitting x (to go to the expert menu), c, then 1 (for the first partition), then add the Partition unique GUID that the partition previously had (in our example DBA66894-D218-4D7E-A33E-A9EC9BF045DB).
- We're almost done: go back to main menu by hitting m, then i and then 1. You should get something like what was printed before except now the Partition size should differ. If the Partition unique GUID or the Partition name are different, hit q and start over.
- If everything's set, hit w in order to write the partition table to the disk, y for confirmation and you're (finally) done!
- Now expand your file system because we've shrunk it on step 11 by running:
```
sudo resize2fs -p /dev/xvdg1
```
Done! Detach both volumes, create a snapshot of the new volume and attach it to the old instance as /dev/xvda (root volume).
Keep the old volume around for some time, and only delete it after you're 100% certain that everything is in place. The new instance can be safely terminated though, once your old instance boots up with the new volume.

Bonus (panic) points

If you are dealing with PVM image and encounter following mount error in instance logs
Kernel panic - not syncing: VFS: Unable to mount root
when your instance doesn't pass startup checks, you may probably be required to perform this additional step. The solution to this error would be to choose proper Kernel ID for your PVM image during image creation from your snapshot. The full list of Kernel IDs (AKIs) can be obtained here. Do choose proper AKI for your image, they are restricted by regions and architectures!

(from StackOverflow

Credits

How to (selectively) run multiple processes with Foreman

Fotis — Fri, 02 Feb 2018 00:00:00 GMT

If you're using the foreman gem to manage simple Procfile process setups, there will be a time where you'll just need to run 2 or 3 processes separately. This can be easily achieved if you pass the "formation" parameter or the (undocumented) concurrency parameter to foreman start. So let's say your Procfile is formed as follows

api: bundle exec rails server -e development
listener: bundle exec rake listener:run
workers: bundle exec rake workers:run

and you only need to run listener & workers, you'll have to start foreman as follows:

foreman start -c listener=1,workers=1

where the number stands for the number of the processes you want to start for this service. So, if for example we wish to start 5 processes for the workers, we can simply change this to:

foreman start -c listener=1,workers=5

Additionally, we can use an environment file:

foreman -e env.sh start -c listener=1,workers=5

For more options please visit the foreman documentation page

Deep Work by Cal Newport: The most impactful productivity read so far

Fotis — Sun, 14 Jan 2018 00:00:00 GMT

A bit of a background

For over a decade now, along with my technical skills, I've been trying to make sure that an 8-hour work day is as productive and efficient as it gets. I've had pretty strict rituals, I've been working in an office that's located close, but not within my home, kept todo lists, planned ahead, all evolved around the same principle: being able to produce impactful work within a restricted time frame, without having to work the long hours, in fact, when I had to work the long hours this meant that I wasn't actually as productive as I should be (or some really urgent matter required my attention - ie. some critical bug or some system failure). All of this has worked just fine throughout the years and I'm pretty happy with my productivity, in fact I've become a pretty strong believer that being able to maintain focus and being highly productive is as important as being great at what you do.

In order to validate my processes, I've been reading a lot about how other people structured their work day both working on-site and remote, and once I've switched to being fully remote (back in late 2015) I just wanted to take my productivity to a whole new level: Deep Work.

Deep Work

Deep Work is a state of mind, in which one produces work intensely and at an elite level, completely keeping away from any distraction. In his book, Newport starts by explaining why Deep Work is valuable and why it helps shaping today's economy. It debunks quite a few myths about today's work, such as the open office space, being extremely responsive to communications. He then continues with the rules that apply in order to work deeply and the different approaches to it and since Newport is an academic himself, everything is backed by scientific proof.

His main hypothesis is that even the most innocent distractions can be proven to be harmful and in fact there is a chapter on how our brains' neurons actually rewire themselves to be even more acceptive to distractions when we start giving into their shinny world, while on the other hand, being able to maintain focus can produce rare and valuable results.

The book is split into two main chapters; the first one actually introduces the reader into the world of Deep Work and what are the benefits from it. As expected, right after the first few pages, one gets convinced about the merits of this type of cognitive process, and gets seamlessly drawn into the second chapter which provides a few actionable steps. The highlights for me were his thoughts on being able to "Embrace Boredom", where he explains that trying to avoid boredom is what actually makes our brains more prone to distractions, how being disconnected from work actually works in work's favor, "Quit Social Media" (you didn't see that coming, did you?) but the one that puts all the pieces together is, as expected, the last chapter of the book where Newport explains "How to drain the shallows" and how to be able to enter states of Deep Work throughout the work day, simply by using pen and paper.

Conclusion

Deep Work isn't a self-help book with a cheesy cover, it neither is a click-bait post on a popular website. This is the product of year-long scientific research on how to achieve more in a distracted economy, broken down by using simple terms and actionable steps. Every knowledge worker should read the book cover to cover, just to get an idea of what they can achieve, if they're willing to adapt to a few very simple (and very sane) rules. It's a book that I nevertheless enjoyed and it has definitely broadened my horizons when it comes to producing meaningful work.

Bonus points

There are quite a few videos of Newport either in TED conferences or the Google Campus. Here's one that I've liked, which is structured around the subject of his other books

You can get the book from amazon.com, amazon.co.uk or amazon.de

Upgrading React Router v4 on an Isomorphic, Redux-powered React web application

Fotis — Thu, 05 Oct 2017 00:00:00 GMT

When working on the next release of ezploy.io (currently moved to stackmate.io), among the many changes I've introduced, I had to upgrade react-router to its latest stable version v4. At first I thought it was a bit of a luxury since I tried to roll out this version for a long time, but then again I thought that it would provide great benefits in terms of security, stability, flexibility and speed, so I went ahead and spent that 3-4 hours anyway; here's the story behind that.

First things first

You have to carefully read the Official migration guide that the awesome contributors of React Router have crafted.

Key Concepts

The first thing you need to know is that the react-router is broken down to several packages that you need to additionally install, since the react-router package is designed as a core package, working both with React and React Native. This is the main reason why you need to familiarize yourself with the react-router-dom package, which you'll be using from now on.

Second, there's no need for having all of your Routes in one file. The routes can now be hosted inside components so you need to refactor your main application's component and your existing routes file; Your main application component should host all the top-level routes from now on and your (existing) routes file should now feature an array of routes (more on that on the next paragraph).

Third, if you're using onEnter, onChange and other hooks like setRouteLeaveHook, you may need to perform a deeper dive on the React Router documentation, and perhaps a quick look at this thread too, as these have now been removed. There's a section at the end of this post explaining what you need to do if you require user confirmation when navigating away from a page (ie. unsaved changes etc).

Fourth, if you're passing params in your data prefetching functions or examining params in your props, keep in mind that params is now a property of match which is the router match object (which we'll talk about in a bit).

Last but not least you may need to spend some time refactoring your imports, since the <Link> component, or the withRouter wrapper for example, are now located in the react-router-dom package.

Isomorphic rendering & data prefetching

In order for the server side rendering to work properly we need to have all data pre-fetched and the Redux store hydrated (if you're using Redux on your stack). This is achieved by having each data-fetching component set up as follows:

class MyComponent extends React.Component {
  static fetchData(dispatch, match) {
    // ... dispatch the appropriate actions
  }

  componentDidMount() {
    const { dispatch, match } = this.props;
    MyComponent.fetchData(dispatch, match);
    // ...
  }
}

Notice how we pass match as the second argument of the fetchData function, this used to be router's params in previous versions, but since params is now a property of match, we pass the match object instead.

Now, remember when we said we don't need to have a central place for your routes? That's sort of true; Not having all your routes in one place, means that each component should be able to declare Routes inside its render function for example, meaning that isomorphic rendering with data prefetching becomes a lot trickier. Not anymore, because now's the time to install react-router-config and setup a fairly big array of objects, containing all the routes in the system (hence the "sort of true" about this argument), much like that:

module.exports = [
  {
    path: '/',
    component: Application,
    routes: [
      {
        path: '/dashboard',
        component: Dashboard,
      },
      // ... more top-level routes here
      // ...
      // a couple of nested routes
      {
        path: '/projects/:id/setup/update',
        component: UpdateProject,
      },
      {
        path: '/projects/:id/setup',
        component: Project,
      },
    ]
  }
]

Having done that, you may now use renderRoutes and matchRoutes on your server side router. You're going to match the route based on the url the user is currently at, then get the components that this route uses, apply the fetchData function and done!

The most common pattern for doing server side rendering, is having a middleware (in our case an Express.js middleware) which renders on all urls (catch-all) and delegates the actual routing to react-router.

If what I've mentioned above sounds familiar to you, your existing code (pre-upgrade) probably uses matchPath function, like this one:

matchPath(req.url, routes).then((error, redirectLocation, renderProps) => {
  // I can has server side rendering in here
});

It's now time for that matchPath function to retire and match your routes with the matchRoutes function, provided by react-router-config. Here's the gist of how my server side router looks after applying the changes (make sure you follow the comments in the code):

// ...
// import the new StaticRouter from react-router-dom and the functions described above from the config package
import { StaticRouter } from 'react-router-dom';
import { matchRoutes, renderRoutes } from 'react-router-config';

module.exports = () => {
  // you might need to avoid using `import` for the routes file,
  // if you're doing hot reloading on the server and you need them to be reloaded
  let routes = require('./routes');

  // catch-all middleware that delegates routing to react-router
  router.use('*', (req, res, next) => {
    // ...
    const context = {};

    // We're matching the route with `matchRoutes`, then we're adding all of the `fetchData` promises in an Array.
    const dataPromises = matchRoutes(routes, req.originalUrl).map( ({ route, match }) => {
      return route.component.fetchData ? route.component.fetchData(store.dispatch, match) : Promise.resolve(null);
    });

    // Once all of the `fetchData` promises have been resolved, we may now proceed with the rendering
    Promise.all(dataPromises).then( prefetchData => {
      // Create a component wrapped in a `<Provider>` containing the store,
      // then render the router inside the provider
      const InitialComponent = <Provider store={store}>
        <StaticRouter location={req.url} context={context}>
          {renderRoutes(routes)}
        </StaticRouter>
      </Provider>

      // Render your Express.js layout with the app and the Redux store hydrated
      res.render('application', {
        reactApp: ReactDOM.renderToString(InitialComponent),
        initialState: JSON.stringify(store.getState()).replace(/</g, '\\u003c'),
      });
    })
    // ...
  });
};

Done! Your app now renders isomorphically, with all the data pre-fetched and the Redux store hydrated. We're not entirely done though, let's just make sure that our client app is up to date, here's the gist again:

import { BrowserRouter as Router } from 'react-router-dom';
import { renderRoutes } from 'react-router-config';

// Import the same long array containing all the routes or just render your main application component here
// in case you find this too much.
import routes from "routes";

// ...
const InitialComponent = (
  <Provider store={store}>
    <Router>
      { renderRoutes(routes) }
    </Router>
  </Provider>
);

ReactDOM.render(InitialComponent, document.getElementById("app"));
// ...

Additional things to consider:

When using nested routes like for example /projects/10 and then /projects/10/member/1, you may need to mark the first one as exact, otherwise you'll end up resolving unexpected components
On the same subject, let's say we have the following route set up

<Route to="/projects/:project_id" component={Project} />

and inside the Project component you have the following route set up:

  // ...
  <Switch>
    // ...
    <Route to="/projects/:project_id/collaborators/:collaborator_id" component={ProjectCollaborator} />
  </Switch>

When visiting /projects/5/collaborators/15, you may not be able to access the :component_id param inside the Project component due to this issue.

If you've been using the setRouteLeaveHook hook to prompt your users before navigating away from a page, you can use the getUserConfirmation. Now, if you need a bit more granularity prompting your users when navigating away from a page, consider using the Prompt component, while if you need to render a custom React component or perform a custom hook when confirming / canceling navigation, there's a nice replacement for that.
If you're using react-router-redux in order to navigate like dispatch(push('/my-url')), you need to upgrade to its next version, as the project has been moved as well. They also provide a comprehensive example in their documentation which features the ConnectedRouter component in order to automatically connect to the store object.

Django Snippets for everyday problems

Fotis — Wed, 17 Aug 2016 00:00:00 GMT

In late 2015 I found myself working with Python, Django and py.test. I was trying to apply some practices that I had been applying for a very long time with different tools, but Django resisted, so here's the survival kit I had while I was struggling not to compare Django with more modern frameworks. I'm sure a more experienced Django engineer would have found more elegant solutions but these actually did the trick for me.

1. HTML arrays in POST requests

Coming from a background that HTML arrays (or Hashes) are posted in forms can cause some pain in Django. If for example you're coming from a Ruby on Rails or PHP background, you may have found easy to access HTML arrays by simply checking the request object in Rails or $_POST array in PHP. So, for example if you need to post the following form:

<input type="text" name="person[name]" value="John">

In Rails for example, by accessing request[:person][:name] you would get the expected result, while in Django this is not the case. In order to do that, the following snippet is what you need

import re
def get_dict_array(post, key):
    """
    Get an entry from an HTML array eg:
    <input type="text" name="person[name]" value="John">
    Usage:
    get_dict_array(request.POST, "person")
    """
    result = {}
    if post:
        patt = re.compile('^([a-zA-Z_]\w+)\[([a-zA-Z_\-0-9][\w\-]*)\]$')
        for post_name, value in post.items():
            value = post[post_name]
            match = patt.match(post_name)
            if not match or not value:
                continue
            name = match.group(1)
            if name == key:
                k = match.group(2)
                result.update({k:value})
    return result

2. Error message overloading for Unique composite keys

Let's say in your database, there is a table with a composite key, for example in a table of users' Portfolio Items, the fields user and url should be unique together. In case you need to customise the error message for when a user enters an item which already exists, then you're in for a surprise: You need to overload the model's unique_error_message method. Sounds dangerous? Probably because it is...

def unique_error_message(self, model_class, unique_check):
        if model_class == type(self) and unique_check == ('user', 'url'):
            return _("There already is a portfolio item with the specific url")
        else:
            return super(MyModel, self).unique_error_message(model_class, unique_check)

3. Not able to chain scopes (use QuerySet instead of ModelManager and `objects = QuerySet.as_manager`)

If you have created a model in django and you want to set a few scopes for it, you might need to use a ModelManager, right? Well, sort of... You see, chaining ModelManager objects can be painful, so if for example you need to have

Users.objects.active().social_user().all()

you might get a few not-so-clear error.

The most solid approach I've found, is the following:

Declare a QuerySet instead of ModelManager
In your model, you can set objects = QuerySet.as_manager() to use your custom objects manager.

Example:

from django.db import models

class AccountQuerySet(models.QuerySet):
    # ... other scopes here ...

    def active():
      """Filter accounts by active status"""
      return self.filter(is_active=True)

class Account(models.Model):
    # ... fields go here ...
    
    objects = AccountQuerySet.as_manager()

4. Converting `QueryDict` to plain `dict`

Casting a QueryDict to a plain dict might sound like a trivial thing, but you need to be aware of the following caveat: QueryDict.dict() and dict(QueryDict...) return different things, as shown in the output below

In [3]: QueryDict("utm_source=email_campaign").dict()
Out[3]: {u'utm_source': u'email_campaign'}

In [4]: dict(QueryDict("utm_source=email_campaign"))
Out[4]: {u'utm_source': [u'email_campaign']}

5. Package seems missing even though you have just installed

You have just installed a package, for example boto and you want to run a command, for example fab. If you receive the following error:

ImportError: No module named boto

all you have to do is:

export PYTHONPATH=/usr/local/lib/python2.7/site-packages

or in order to make the change permanent, you need to add this line to your shell's rc file like .bashrc or .zshrc.

6. Uninstall all python packages

Want to start fresh or for some reason remove every python package in your system? There you go:

pip freeze | xargs pip uninstall -y

Git 101 - Workshop on Found.ation co-working space

Fotis — Wed, 25 Mar 2015 00:00:00 GMT

In March 2015, Found.ation invited me to host 2 workshops for how to use Git. The workshops were of great success and I was very happy that people would not also start using Git, but prefer it over other SCM tools. The event was sold out both times, which made me a bit nervous at start but it proved to be a great experience, hopefully for the trainees as well. At the end of the workshop, we gave away 3 GitHub coupons for 6 months, offered by GitHub

You can find the material I've prepared on gitcompanion.github.io and the event page and some photos on Found.ation's website

Images courtesy of [Found.ation](http://thefoun dation.gr/events/educ-ation-class-git-training-101/)

Hacking your workflow - FrontMass 2014 Keynote

Fotis — Sun, 11 Jan 2015 00:00:00 GMT

Right before Christmas 2014, the SKGtech team held a great conference in Thessaloniki, called FrontMass. I was lucky enough to be one of the keynote speakers, covering my favorite topic: How to hack your workflow for better productivity.

My main points were how to effectively use tooling such as vagrant, git and docker to boost your productivity.

Images courtesy of Christos Bacharakis

Switching to Jekyll GitHub pages

Fotis — Sun, 26 Oct 2014 00:00:00 GMT

Goal: An easy to maintain personal website

Being a Web Developer is complicated by itself, so, when it comes to maintaining a personal website about ourselves, most of us are terrible at it. We either envy the fancy-designed websites by hipster designers or we enjoy the simplicity of typography-based designs by UX experts.

But, at the end of the day it all comes down to this; maintaining a personal website should be something simple, so it can be done on a regular basis, right?

Abstracting information

When I decided to re-build my personal website (I take such a decision once every two years or so), I thought I should include all the stuff that all the cool kids do; Portfolio, Client testimonials, Contact form, Pictures of me traveling, Pictures of me giving talks like a rock-star in front of 3 people etc.

No. Here's the thing: If i do all of this, then I would have to maintain duplicate information, because I would update my social profiles anyway. Also, I'm not an agency (at least not anymore), so my work is not that frequently updated. I'll add a page with my open source projects in the near future instead.

Contact forms are easily abused by bots, which led to ~150 very enlightening spam email messages every day. Most of them were about shoes, which is really odd. I would either use CAPTCHA (sic) or create a public email and accept all kinds of spam there.

Keeping it simple

I've added my social media profiles in my contact page, you may use them freely. Kept my homepage clean with all the posts that are recently posted by me.

What was my weapon of choice

Jekyll is a minimalistic static site generator which makes you think how isn't that even more popular. It uses Markdown and HTML, can be run locally and can be hosted on GitHub pages (free).

Shipping it

On a terminal run

$ gem install jekyll

This will install Jekyll as a ruby gem

$ jekyll new my-awesome-website

This will create a new website

Then follow a pretty straight-forward git-based process to publish your website to GitHub pages.

The main benefit is that I don't have to maintain a server, upgrade, care about security updates, running database backups, running a mail server for a mere developer's blog. I can publish to my blog that easily:

$ git commit --all .
$ git commit -m "My new post"
$ git push origin master

There it is! I just published a new blog post simply by doing a git commit without the need of logging into a control panel and without even leaving my IDE.

So, here it is. My new blog, running on GitHub pages, powered by Jekyll, pure Markdown, HTML and Emoji. As a friend says: It's back to the future!

Hope you like it :smile: :beer:

Display PDF in-page without a javascript plugin

Fotis — Tue, 25 Mar 2014 00:00:00 GMT

There are cases where a PDF file is more than a download link and you need to display it inline inside your page. Recently I’ve stumbled upon a conversation where somebody was looking for a good jQuery plugin that displays PDF files. One of the suggestions was the amazing pdf.js which is developed by the Mozilla foundation and it’s pretty much a full blown PDF viewer in your browser.

If you need a really lightweight solution and you don’t mind if the users with browsers that don’t support PDF viewing, don’t view the document, here’s a snippet you may use

/**
 * When browser supports inline pdfs
 * There is no need to append a large jquery plugin that displays them inline.
 *
 * You can actually use an iframe (and style it appropriately)
 * or a link whenever inline PDF viewing is not supported
 *
 * This function is fairly simple and it's only for demo purposes
 */
function appendPdf(id, url) {
    var $el = $('#'+id);
    // Check whether the browser supports displaying pdf files inline (ie. without downloading them)
    if (navigator && navigator.mimeTypes && navigator.mimeTypes['application/pdf']) {
        // You may add extra attributes (eg. to allow transparency) or style the iframe
        $el.html('<iframe src="'+url+'"></iframe>');
    } else {
        $el.html('<a href="'+url+'">Download file</a>');
    }
 }

What we do here is check if the browser has a plugin for a certain mime type (the check

navigator.mimeTypes['application/pdf']

will return undefined if the browser doesn’t have a plugin for that mime type). If the browser does support PDF, we append a simple iframe that can be styled and sized accordingly, or append a link to download the file if the browser doesn’t have a handler for PDFs.

As you can see, it’s a fairly simple solution and significantly lighter than any javascript component.

Vagrant Apache or nginx serving corrupt Javascript and CSS files

Fotis — Wed, 12 Feb 2014 00:00:00 GMT

If you prefer a virtualized environment for your web development purposes, you may find Vagrant a really handy solution. Vagrant is a fantastic tool that creates a virtual machine which can be provisioned with Chef or Puppet and be re-packaged for future distribution.

One thing you may need to setup first would be turning off the sendfile option in your web server, otherwise you might end up getting corrupt static files such as javascript or css files. This is actually a VirtualBox bug, as it was documented in Vagrant’s v1.1 documentation and here’s a simple solution to that:

# A VirtualBox bug forces vagrant to serve
# corrupt files via Apache or nginx
# The solution to that would be to turn off
# the SendFile option in apache or nginx
#
# If you use apache as your main web server
# add this directive in your httpd.conf (or apache.conf)
# configuration file name may vary in various systems
#
EnableSendfile off

# If you use nginx as your main web server
# add this directive in your nginx.conf
sendfile off

Hacking the way you work: My keynote on JoomlaDay 2013

Fotis — Mon, 17 Jun 2013 00:00:00 GMT

<div class="aspect-4/3 w-full mb-10"> <iframe src="//www.slideshare.net/slideshow/embed_code/key/4qTVnDwz4UUeUd" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="100%" height="100%" allowfullscreen

</iframe> </div>

<small> Image courtesy of JoomlaDay Greece Flickr </small>

How GitHub Uses GitHub to Build GitHub

Fotis — Thu, 22 Sep 2011 00:00:00 GMT

This is probably the presentation I've read the most while going through SpeakerDeck or SlideShare. I love GitHub both as a software product and philosophy as a team, so I try to read as much as i can related to them.

Here's a presentation by Zack Holman on How GitHub uses GitHub to build GitHub

Enjoy!

Fotis Alexandrou - Software Engineer

How to prepare your web application for the cloud

Develop a mindset first

File Storage

Session storage

Retrieving & storing information in cache

Scheduled jobs

Database migrations

Conclusion

What to consider when choosing a new tech stack

The right tool for the people involved

The right tool for the job

Choose technology that is already familiar, documented, proven & stable

If your team is small, a monolith is just fine

Running & maintenance costs

Don't get fancy

Conclusion

Testing your code is not optional.

Let’s start with a story...

So, is testing our code a waste of time?

Testing is a safety net, but also a documentation and developer onboarding tool

Keeping tests fast & testing the right things

Meet your new best friends

How having a proper test suite improves your code

There's no strategy that's better than others

Conclusion

Further reading

How to fix Sectigo's expired root certificates

The problem

The solution

Using a React Component as a Layout with ReactOnRails

Understanding variable assignment in JavaScript

Hello var, old friend

ES2015: let and const are introduced

Credits

Being efficient as a remote worker: a study on productivity

The workplace and dress code

It's all about routine

Planning everything

Pomodoro technique and Deep work

Avoiding distractions & Prioritizing communication

Getting stuck

Keeping a worklog

Shutdown ritual

Socializing, coffe-breaks

Bonus point: reading lunch breaks

Credits

How to downsize a root EBS volume on AWS

Bonus (panic) points

Credits

How to (selectively) run multiple processes with Foreman

Deep Work by Cal Newport: The most impactful productivity read so far

A bit of a background

Deep Work

Conclusion

Bonus points

Upgrading React Router v4 on an Isomorphic, Redux-powered React web application

First things first

Key Concepts

Isomorphic rendering & data prefetching

Additional things to consider:

Django Snippets for everyday problems

1. HTML arrays in POST requests

2. Error message overloading for Unique composite keys

3. Not able to chain scopes (use QuerySet instead of ModelManager and objects = QuerySet.as_manager)

4. Converting QueryDict to plain dict

5. Package seems missing even though you have just installed

6. Uninstall all python packages

Git 101 - Workshop on Found.ation co-working space

Hacking your workflow - FrontMass 2014 Keynote

Switching to Jekyll GitHub pages

Goal: An easy to maintain personal website

Abstracting information

Keeping it simple

What was my weapon of choice

Shipping it

Display PDF in-page without a javascript plugin

Vagrant Apache or nginx serving corrupt Javascript and CSS files

Hacking the way you work: My keynote on JoomlaDay 2013

How GitHub Uses GitHub to Build GitHub

Hello `var`, old friend

ES2015: `let` and `const` are introduced

3. Not able to chain scopes (use QuerySet instead of ModelManager and `objects = QuerySet.as_manager`)

4. Converting `QueryDict` to plain `dict`