Forem: AKQA Leap

Using Google Cloud Firestore with Django's ORM

Luke Benstead — Mon, 20 May 2024 14:34:06 +0000

Django has long been the most popular Python framework for developing web applications. One of its most powerful features is its built in object-relational mapper (ORM) which is designed to flexibly and safely interact with SQL databases in an abstract way.

A long time ago, a fork of Django called “Django-nonrel” experimented with the idea of using Django’s ORM with a non-relational database; what was then called the App Engine Datastore, but is now known as Google Cloud Datastore (or technically, Google Cloud Firestore in Datastore Mode). Since then a more recent project called "django-gcloud-connectors" has been developed by Potato to allow seamless ORM integration with Google Cloud Datastore.

The intention was always to expand that functionality to other Google hosted no-SQL databases, and today I’m pleased to announce that django-gcloud-connectors now has support for Google Cloud Firestore in Native Mode. This means you can now build a robust Django-powered website or API driven from a Firestore database which could for example be shared with your Firebase backed mobile application.

It might seem that using Django’s relational mapper on a non-relational database would be like forcing a square peg into a round hole - but it turns out that the Django ORM works quite elegantly with a non-relational database, and gives you the tools you need to build reusable patterns to get the most out of a massively scalable database.

Take for example the schemaless nature of a non-rel database like Cloud Datastore which allows each document to have different properties to the other documents in the same table; while powerful, in practice you generally need a schema to write code against and to ensure that your data remains consistent. Django’s model structure allows you to maintain a schema (with validation) that can change over time. You can leverage model signals, field defaults or request middleware to migrate data on the fly, without the need for running potentially slow or disruptive database migrations. You hardly need to worry about the database at all while developing, simply add a new model or field in your code and use it. Django with a non-relational database is great for rapid prototyping.

There are limitations of course; non-relational databases don’t do complex queries - you can’t perform joins; you can have foreign keys, but you can’t fetch or order across those relations in one database query; you can have many-to-many relationships, but not with Django’s ManyToManyField (you need to use a custom list field instead). You might just find some queries are impossible.

These limitations mean you have to solve problems in a slightly different way. You’ll find you’ll design your models around the queries you need to make; you’ll sometimes have to pre-calculate things when you save a document to make it possible to quickly query for it later, or perhaps use other services like Big Query or background task processing.

But you can almost always assume that once your code works, it’ll scale well no matter how much data you throw at it; there’s no risk of running an unindexed query on a million rows, or having to think about database replication or sharding. You can rapidly build a product for a startup and know that things will just ramp up when it hits the big time.

I highly recommend you give it a try, simply follow the instructions in the django-gcloud-connectors repository and you’ll be up and running in no time. If you’re hosting on Google App Engine you might also be interested in the Djangae project which provides useful utilities and Django apps to integrate with Google Cloud services.

Why accessibility should be a priority, not an afterthought

Alexandra Stoica — Thu, 20 May 2021 16:07:10 +0000

We often talk about user-centered design and development, however the process rarely includes accessibility and UX research with users with disabilities or impairments. (Web) accessibility is the practice of making your websites usable by as many people as possible, thus providing equal access to information and communications technologies, including the Web, to people with disabilities or impairments. Simply put, accessibility is a basic human right.

Accessibility is good for all users

Over one billion (or 15% of the population) people live with some form of disability. Some examples may include auditory, cognitive, neurological, physical, speech, and visual disabilities or impairments. While a disability means that the person finds it difficult to perform everyday tasks to a level that is considered normal for most people, an impairment is medical and represents a condition or symptoms that a person experiences (i.e., low vision). These conditions can be permanent (i.e., I am deaf), temporary (i.e., I have an ear infection), or contextual (i.e., I am on a busy train and do not want to play audio). This hardly makes accessibility an edge case. Technology has been playing a crucial role in facilitating our day to day tasks, but is this the case for everyone?

In this TEDxMIT talk, Judy Brewer describes how we should strive for an accessible future: accessible technology provides unprecedented opportunities for people with disabilities. For example, people with visual impairments can now read the news thanks to the screen reader, and people with speech and motor impairments can use eye-gaze to speak with others.

But it does not stop there, essential for some and useful for all, accessibility supports social inclusion: other groups, such as older people or people in developing countries can greatly benefit from accessible and assistive technology. Different situations can hinder the experience of anyone using the web, such as watching a video in a loud environment without captions, or using the web with a poor Internet connection.

Accessibility is good for the business

While the Web offers great potential, implementation matters, otherwise this potential remains unrealised. The World Wide Web Consortium (W3C) have defined a wide range of recommendations for making web content more accessible based on three conformance levels: A, AA, and AAA (from least to most accessible). Sadly, despite all of this, most websites still fail to adhere to Web Accessibility Guidelines (WCAG) as oftentimes in software development, accessibility is an afterthought, treated as a feature, rarely tested for, and not properly considered in the design stages.

Conversely, inaccessible websites hurt business. For example, failure to adhere to WCAG negatively affects SEO (search engine optimisation), which results in Google Search ranking inaccessible websites lower than more accessible ones. Moreover, accessible and inclusive design thinking can lead to numerous business outcomes, helping digital products be more flexible, address unanticipated problems, and drive innovation.

The role we play

Inclusive design and accessibility need to be an integral part of the full product lifecycle. Everyone should know about accessibility. At Potato, we use guilds as a way to educate, encourage, and raise awareness of important aspects of product development and challenge ourselves to do better. In 2019, we established the Accessibility Guild to make accessibility part of our product thinking and culture. As members of the guild, we meet regularly to discuss accessibility topics, organise company-wide talks, learn from each other, watch accessibility-related talks, and audit digital products.

Whether you are an engineer, a designer, a product manager, or whether you work in technology or not, we all play a role in building a more accessible future. It is by no means an easy task, but fortunately we have many resources that can help us get there. You might add captions to your Instagram stories, or add alt description to your Twitter images, so next time you make a mark on the World Wide Web, I encourage you to simply ask yourself: is this accessible?

Resources

GAAD

Accessibility - W3C

What is accessibility? - MDN

The A11Y Project

WebAIM: Web Accessibility In Mind

Web Content Accessibility Guidelines (WCAG) Overview | Web Accessibility Initiative (WAI) | W3C

The Business Case for Digital Accessibility | Web Accessibility Initiative (WAI) | W3C

Web Accessibility and SEO

Inclusive Design Principles

How Designing For Disabled People Is Giving Google An Edge

How I learnt about accessibility as a junior developer

How the Web works.

Matte — Fri, 29 Jan 2021 11:59:20 +0000

If you're starting out in web development or are a bit rusty about the general scaffolding and technologies required to make the web possible, this high level overview could help you avoid time-consuming setbacks. Knowing how the web works enables developers to make informed architectural decisions, pinpoint bottlenecks and errors, and build solutions that are optimised for the medium they're intended for. My intention is to provide enough clarity on the topic without delivering overwhelming details. So let’s begin. Firstly, we’ll set out to define some core concepts, then run through some key processes and technologies. Finally, we’ll wrap up with how these technologies and processes are used to execute the loading of a web page.

Networks

Devices can be connected through a wireless medium such as Wi-Fi or a physical medium such as ethernet cable. Two or more connected devices are considered a Network. When connected these devices can communicate with one another. Wirelessly and physically connected devices can be a part of the same network. This is the founding principle of the Internet. The Internet is a network, a global one.

The Internet

This global network connects millions of computers, each able to communicate with one another. This connection allows us to email, share files, transfer data, play games, stream films and access the World Wide Web. An Internet service provider (ISP) is an organisation that provides services for accessing and using the Internet.

The World Wide Web

Although commonly used interchangeably The World Wide Web, or simply the Web, isn’t the same as the Internet. To help articulate this difference, think of the internet as the roads that connect towns and cities together. The world wide web contains the things you see on the roads like houses and shops. The vehicles are the data moving around - some go between websites and others will be transferring your emails or files across the internet, separately from the web. Another way to look at this difference is; the Internet is infrastructure while the Web is the service on top of that infrastructure. As such, the Internet makes the Web possible but the two are not the same.

There are some underlying differences in the technologies and processes used between services such as email, streaming and browsing the Web. However this is beyond the scope of this article where we’re focusing on the Web.

Clients and Servers

When using the Web we rely on a client-server relationship. Clients, such as web browsers, request and receive information from servers. Servers, on the other hand, receive requests and deliver responses to clients. Requests and responses are dispatched in the form of HTTP messages.

A client, in this instance a laptop, and a server demonstrating the request/response communication relationship.

A client is not always the device the user interacts with. A server can also be a client as shown here.

HTTP/HTTPS

Hypertext Transfer Protocol is the protocol used between clients and servers to communicate. Assets such as images, text, documents, video and audio can all be transferred through HTTP messages.

Remember our response and request messages? These are the two types of HTTP messages. Both are composed of the following components: a start-line, some headers, an empty line and finally an optional body component. See MDN for the specifics of an HTTP request.

The S in HTTPS indicates a greater level of security and requires an SSL certificate to use. These certificates ensure transferred data is encrypted making it harder for intermediary parties to read the contents of the messages passed between servers and clients. In other words, this layer of security helps to ensure data (including confidential or sensitive information) remains undisclosed for everyone but its intended recipient.

SSL in action. Note the padlock icon to the left of the URL. This indicates the use of HTTPS and so we can have greater confidence that our security is protected.

You can also click on the padlock icon to show relevant information.

TCP/IP

Transmission Control Protocol (TCP) is responsible for ensuring data requested through HTTP gets to you in one piece as quickly as possible. It does this in a few key ways:

Firstly, it divides data into packets.
It then transports these packets individually taking steps to mitigate risk of delay or delivery failure. Such risks include network congestion, unpredictable network behaviour and network traffic, that is, the amount of data moving across a network at a given point in time.
Finally, it reassembles these packets ensuring all data is accounted for and in the correct order.

Internet Protocol (IP), amongst other things, provides an address system known as IP addresses. All internet connected devices have a unique IP address which takes the following format: 000.000.000.000. The most recent version of IP addresses, IPv6, exists for the purposes of relieving a projected shortage of IP addresses which have the following format: 0000:0000:0000:0000:0000:0000:0000:0000. You can find your IP address by searching for “What is my IP” in your browser. These addresses are used to ensure data is delivered to the correct host. Essentially TCP/IP is how and where data gets delivered.

DNS

A Domain Name Server can be thought of as a huge address book and is typically provided by domain name registrars. Typing a domain name into a web browser’s address bar triggers a request to a DNS server. The DNS server communicates with a hierarchical chain of independent, task specific DNS servers until the IP address of the requested domain is found. This IP address is then returned as a response to the client. The client can then request the resources it needs to load a web page from said IP address. DNS servers fall into one of four categories: Recursive resolvers, root nameservers, TLD nameservers and authoritative nameservers.

Let’s look at the DNS system in a step-by-step narrative. A resolver sits between the client and the remaining nameservers (root, TLD and authoritative), it receives requests in the form of domain names from the client.

Having received a request, the resolver sends domain information onto the root nameserver in the form of a request of its own. A response from the root nameserver directs the resolver to the TLD nameserver. TLD nameservers contain information specific to a domain extension, be it .com, .co.uk, .org, etc.

The resolver, now knowing which TLD nameserver to communicate with sends a request to said server. A response directs the resolver to the authoritative nameserver. Sending a request to the authoritative nameserver is resolved in a response containing an IP address. At this point the resolver has communicated with each of the DNS server types and has obtained all the information it needs.

The resolver then caches the data to speed up future requests to the same domain and responds to the client with the obtained IP address. The client, having obtained the IP address, now knows where to request domain specific resources from in order to render a webpage.

Throughout this process there’s a consistent pattern of whittling down where to look in an effort to locate the resources the client needs to render a webpage. In brief this takes the form of going from domain name, to the domains extension type (.com, .net, .org) to specific IP.

URL

IP addresses aren’t particularly easy to recall from memory. This is where URLs come in. A URL is a human readable address for locating resources needed to render a site.

A URL is constructed of different parts, each serving a purpose. Let’s take a URL and break it down into its individual parts.

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

Protocol (http):
This sets the protocol in which data is transferred across the Web.

Host (www.example.com):
This is what is used alongside DNS lookup to find the IP address of the server that contains our resources.

Port Number (80): These are sometimes seen in URLs. By default, HTTP uses port 80 and HTTPS uses port 443, but a URL like http://www.example.com:8080/path/ specifies that the web browser should connect to the HTTP server running on port 8080 of the target machine.

Path (/path/to/myfile.html): This is the path to the required resource on the server.

Query String (?key1=value1&key2=value2): Query String parameters are a list of key/value pairs separated with the & symbol. Values are optional.

Fragment (#SomewhereInTheDocument ): A fragment links to part of the resource itself. On an HTML document, for example, the browser will scroll to the point where the fragment is defined.

Loading a web page

Now we know the processes involved in obtaining an IP address let's look at how a client goes about rendering a page. Our client, having received the appropriate IP address from a DNS lookup, can request resources from the server specific to the submitted domain name. The server's initial response contains the pages HTML. The parsing of this HTML by the browser includes sending additional HTTP requests for any resources the file references. Typically this will include Javascript and CSS but can also include images, fonts, audio and many other asset types.

Having acquired the assets it needs, the browser runs through a series of processes. Firstly the HTML is transformed into a Document Object Model (DOM). The CSS is then transformed into a CSS Object Model (CSSOM). These two models are then combined to form the Render Tree.

The browser then uses the information from the Render Tree to perform layout and painting of the elements which make up the page. The Layout operation is concerned with calculating the size and location of each element. The Paint operation is concerned with creating layers for the visible properties of each element such as border, background color, gradient, shadow etc. The final step in the process is the Compositing operation where the browser begins to render to the screen. It’s worth noting that these steps can occur after the initial page render as well. For example, the Paint step would be required during resize and animation events too.

This sequence is known as the Critical Rendering Path, something worth getting familiar with. It helps developers pinpoint performance bottlenecks and to reduce heavy rendering tasks that would affect a users experience.

For further reading on these processes I recommend this article on how the browser renders a web page. Google provides resources that cover performance, here’s their overview page titled critical rendering path. It covers a broader base and makes note of key things to avoid such as render-blocking CSS.

In Summary

We’ve covered a huge chunk of the processes and technologies involved in making the web work. From submitting a URL through to the page being rendered on your device. This article is intended to be a succinct overview of the ecosystem as a whole, as such, potentially overwhelming details have been deliberately omitted. Don’t let that stop you from taking what you now know and conducting your own further research. I hope you’ve found this useful, if anything you’re better prepared for making informed architecture decisions and understanding where bottlenecks or errors may be happening. At the very least you’re now equipped to effectively answer the common “What happens when you submit a URL?” interview question!

Validation of the tech roundup providing statistics for Android Developers

agata — Tue, 24 Nov 2020 12:18:53 +0000

We're reaching out to Android Developers who would like to share their thoughts and help us validate the user journey of the tech roundup providing statistics for Android developers across the world.

Please comment or email agata.stasiuk@potatolondon.com if you'd like to help.

One Engineer's Journey with Mental Health

Michael Strutt — Mon, 19 Oct 2020 16:30:22 +0000

My name is Michael Strutt and I have Generalised Anxiety Disorder (GAD). I was first diagnosed in my early teens, and it has impacted my life to a greater or lesser extent at different times since then. As of January this year I have been having weekly sessions with a Therapist. In light of World Mental Health Day and the increasing spotlight that mental health has seen this year, I would like to share my story, as both a person and an Engineer.

I’m going to start with some personal history, both because I’m telling my story here and because I think it adds good context. If you want, you can skip to the part where I start talking about the industry as a whole. Or if you’re only interested in what I’m doing to manage things now, that’s cool too. For the rest of you, this is my story:

Getting in to coding

I got into building websites quite early on in life. I discovered it right at the start of high school and just got the bug. When I started out it was a great creative outlet for me, building something and seeing the results instantly. It was also a very interesting way for me to connect to the world in a way I had never experienced before. An early site I built offered solutions to common beginner problems with Ubuntu Linux. I was amazed that I could put a tutorial or the solution to a problem out there, and it would help a person I had never met living on the other side of the planet.

As I got older I started to notice the way that I felt when I coded. I could get absorbed in a way that I never found with books. I could really focus my mind on a task without it wandering. I could solve a problem and challenge myself to learn and become better. I felt calmer, accomplished and motivated. I didn’t feel the anxiety so much when I was writing code. It offered me an escape (and in a far more productive way than that time at University when I lost the best part of a month to The Elder Scrolls: Oblivion). Although I didn’t learn this until later in life, I was dealing with anxiety by engaging the logic centers of my brain in order to think more rationally and feel better. A technique often taught in Cognitive Behavioural Therapy (CBT).

In this post I’m going to talk a lot about some of the things that have impacted my mental health in a negative way, but I want to stress at the start that coding has had an overall incredibly positive effect for me. Some of my happiest times professionally have been when I’ve been getting stuck in and coding all day on some really challenging problems. It has continued to be a creative outlet for me. I love the satisfaction and instant gratification of typing a few lines of code and hitting refresh in the browser to see the results. The sense of accomplishment I felt when after a full day of planning and writing out about a page of trigonometry on a notepad, I finally cracked the equation of how to center an item on the page while it was adjusted to have a shrinking 3D perspective. Please try to keep this in mind as you read on.

Starting a career as an Engineer

I was in a very fortunate situation after high school. Sixth Form was an obvious choice, my parents were there to support me, and the offer I received from my first choice of University was well below the grades I was predicted to achieve. I studied Computer Science, I wanted to specialise into Web Development, but my Dad advised me to keep my options open. On my course, we were highly encouraged to do a year in industry, and again I was fortunate enough to land my first pick of positions. My outlook was really positive. I had found this thing that I loved, that I had an aptitude for, and that now somebody was prepared to pay me a salary to do. It was my dream scenario.

There was an amazing honeymoon period on that first job. I was learning every day, keeping my brain active and engaged, stretching my comfort zones by doing new things. I was very smug to be exceeding the expectations that they had for an intern and receive all of the praise that went with it. I very quickly believed that things would be like this forever. That I would continue to soar and be praised and that everyone who told me they saw me doing great things in x years time was right. I mapped out a highly ambitious (although I didn’t think that it was at the time) trajectory for myself in my head. This came back to bite me later.

Early career progression

Everyone goes through life at their own pace, and each and every one of those paces are completely fine. I write this, and logically I know that it is true, but I still struggle to fully believe it. Career progression is a big area of comparison in the industry.

Caveat: this section is written from memories that have almost certainly been recalled through a lens that favours me. I’ve tried to remove the bias towards myself as much as possible, but I’m sure there will still be some left

I’ve always been "the smart one" in my friend group growing up and at school. That experience translated into expectations of success in the workplace. I was moving from the small town to the big city where I would be recognised with titles and of course money. In my internship I was flying high on the praise of outperforming my position and people seeing great things for me. I had really high expectations of myself.

I don’t want this to sound like I’m just nursing my ego here, and I’m certainly not complaining about the very comfortable start that I had in life. I am fully aware of just how fortunate I am to have two loving and supportive parents who nurtured my abilities and provided me with a safety net to fall back on when I needed it. I know all of this. What I’m trying to say is that the reality of the situation was a really hard pill to swallow for me.

I progressed from intern to junior very quickly. I secured a job for when I graduated at the end of my internship, and they even agreed to pay me a retainer salary during my studies. I expected this trajectory to continue up, but it slowed and for a while felt like it had stopped. I stayed in that role for nearly 2 years. I became increasingly frustrated at the lack of progression, at the lack of pay increase. I watched coursemates soar and become indispensable at their startup, cashing in vast stock options at IPO or jet-setting around the world to open new offices for the company.

Meanwhile I was taking on more responsibilities, learning new frameworks and practicing new ways of working. I got to the point as a Junior Engineer where I was the unofficial manager of our intern, doing check-ins and goal setting with them, and I was front-end lead on a project for a high-profile project that had 2 seniors on the team. Rather than seeing these things for the achievements that they were, and the foundation of valuable skills that got me to where I am today, all I focused on was how I wasn’t being financially compensated for this increase in ability and responsibility, and how I wasn’t being recognised with a change in title. Why should I put in all this work when I’m being paid half as much as the people I’m teaching? Don’t get me wrong, these things are important. Everyone deserves to be fairly compensated for the work they put in. But for a time it was the be-all and end-all of my career (and, to and extent, life) satisfaction.

These 2 years had a big impact on my mental health, and in the year that followed I reached probably the lowest point that I’ve ever felt for such a period of time. I had a panic attack while out in public. Thankfully it only happened once, I’d always been able to hide them away before, but the fear of it happening again was debilitating. I was so anxious about it that I was quite literally hiding from social interaction with friends. I became very insular. I moved back in with my parents for a while (for various reasons), and tried out a course of medication that I really didn’t get on with. I felt defeated. I thought that there was no escape, and in my mind, resigned myself to feeling like this forever.

The strain of the work

The work is very mentally challenging, that’s part of what made it appeal to me, a new problem to solve every day. But at times, this gives way to some very negative feelings. How do you deal with finding a problem that you don’t seem to be able to solve? Why does everyone around me seem to be solving problems faster than me? Is this code good enough? What will the other people on my team say when I put this up for review? I’m not going to dive into imposter syndrome. It’s something that a lot of engineers have experienced at some point or another in their career, and there is already some very well written content out there that I would encourage you to read.

Further comparisons

We all know we shouldn’t compare ourselves to others. I have a quote pinned to the notice board in my bedroom that reads "the only person I am competing with, is the person I was yesterday". It’s a lovely sentiment, and one I try to keep in mind, but it’s very easy to forget in a career that seems to be set up for comparison and competition. As part of the job, you spend a lot of time looking at other people’s code. Whether it’s a code review for one of your colleagues, diving into the inner workings of a library you’re using, or simply looking for answers on StackOverflow, it will take up a significant portion of your time.

You end up seeing a lot of code that is better than yours. It can be hard to remember that this isn’t because you are objectively worse at coding than the other person. But it’s because this is what that person chose to focus on. They may have learned an entirely different set of things to you that lead them to this place, or may even have had vast amounts of help with it. You also don’t see the struggles that they went through to write this code. You only see the end results. This can be an awesome opportunity to benefit and learn from all the hard work someone else went through to get to the best result, or it can highlight to you just how much you don’t know. It took me quite a while to shift my mindset to the former, sometimes it’s still a bit of both.

Code review is a very common best practice for the industry. Most places have it as an integral part of their workflow. When I was introduced to it I found it really tough to begin with. It felt like I was pouring my heart and soul into my work and offering it up to be shot down and torn apart. This couldn’t be further from the truth. Ultimately the goal is for the best code possible to be in a project, for issues to be spotted and addressed before they make it live, and to raise the overall standard of the team. It took me longer than I would like to admit to see it this way. It was only when I stopped having my code reviewed that I realised I missed it. I wasn’t learning as fast anymore. I actively went and sought out other reviewers and ended up getting mentored by the Technical Architect at the time who didn’t even write the same language as me, but made the time for me all the same (the first of many thanks in this article goes to him). After this it became a requirement for me in all future roles, to be able to surround myself with people who knew more than I did about something so that I could learn it from them. Since then I always try to put the same effort into code reviews that I received back then, and will always take the time to explain something fully to someone who is keen to learn.

Stresses of the job

There can be a lot of time-related pressures in software engineering. Deadlines might be looming, sometimes moving closer. It can be very difficult to account for every possible thing that needs to be done to build a finished product. You can run into issues or constraints that suddenly add more to your workload, or the simplest of tasks on the surface could end up taking the longest amount of time due to hidden complexity. It can be very hard to explain all of this to someone who ultimately doesn’t really understand what it is you are doing, yet gets to have the final say in budget and timeline. It’s been this way in the industry for years. My Dad would laugh at some of my stories from my first job because of how familiar they sounded to his experiences 30 years before me.

I have on rare occasions done some crazy hours to get a project finished for the agreed launch timeline. I have started working on a launch blocker after dinner at the office, and pushed through until I had to catch the last tube home. I was then back in the office the next morning for a successful 8am launch. I’m completely okay with this. In fact I’m proud of it. But this is very much the exception and not the rule. For some this is not the case, and even for me there was a time (with a past employer) when it felt like the only reward for finishing ahead of schedule was starting the next project early, but if the timelines ever slipped it was the team’s responsibility to get things back on track by whatever means necessary.

There are a lot of things that are changing in favour of team health and reducing these kinds of pressures. From the processes we use to run projects, to the way we try to sell a team with an objective for a period of time rather than a fixed scope of delivery. Even big companies are moving the launch date of huge game releases to make sure things are done properly without putting the team through hell.

I know that I am very fortunate not to have experienced the worst of these stresses myself. I’ve heard horror stories from others in the industry (some I’ve known, some from around the world) that are far worse than anything I’ve experienced, and I count myself lucky to have had people around me a lot of the way who would fight my corner and make my well-being a priority. But even with all of this there have been times when the pressure has taken its toll on me, where I’ve felt completely overwhelmed by everything I have been juggling, and when the stress I have been feeling has resulted in some serious burn-out and even pretty serious illness.

This past Christmas, I was burning the candle at both ends pretty hard, feeling the added pressure of a new role and some pretty big shoes to fill. I was so burned out when I finally stopped and took some time off, that it was only then that my body was able to recover enough to start fighting a virus I had picked up, and I was ill for a full month. It was a real wake-up call to start making my well-being more of a priority than I had been. Also, a big thank you to the Coach at Potato who helped me slow down when I was in danger of doing this the year before when I got stressed out about all the complications in my house purchase. She made time in her busy day just to sit and listen to me and allowed me to get things off my chest and just take some time to breathe.

The mental load

Being an Engineer can both help and hinder my mind. In the same way that a really complex problem at work can be a really great thing to occupy your mind, it can also be really hard to let go. When the work you are doing is physically in the office, it’s easy to leave it behind. When the work that you are doing is happening in your mind, it’s very hard to leave that behind (something that has been exacerbated by lockdown). I have had many nights where I was laying awake problem solving, either consciously or subconsciously sifting through the details and trying to find a better way. I’ve even woken up in the night with a sudden realisation of how to re-architect something and been scrambling for pen and paper to write it down before it fades away. If this is something that happens to you, I strongly recommend keeping a pen and paper on your bedside table so you can get these things out of your head.

I very recently put a lot of work into trying to fix my sleep by following the advice of Sleepio. If you’re having trouble sleeping and are willing to make some serious adjustments to your lifestyle to improve it, then I would highly recommend their course.

Opportunities for growth

I don’t want this post to be all doom and gloom. I have a huge amount to be thankful for about my career and the industry I have chosen to work in, I really can’t see myself working in any other. There are a lot of upsides to it.

Tech industry jobs generally offer a greater degree of flexibility than jobs in other fields. You get some companies with amazing benefits packages that these days often include support for your well-being and mental health. Being entirely cloud-based and working on laptops has been extremely useful for being able to work from anywhere in the world too. Something that has been especially useful this year.

There are also a lot of opportunities to move outside of your comfort zone. Early on in my career, I challenged myself to slowly increase my confidence in being more client facing and took the opportunity to learn how to participate in, then lead, technical interviews.

I can’t say for sure how typical this is of the industry for lack of personal experience, but working at Potato really helped to normalise the idea of mental health for me. A couple of my colleagues were very open in talking about the fact that they had been to therapy at some point in their life. In the time I have been here, I’ve listened to 4 lightning talks from people about their experiences in topics such as therapy, mindfulness, meditation and personal stories with mental health. It was really eye opening for me that people talked about these things as if they were normal, because they are normal. I don’t know how much longer it would have taken me to ask for help without this experience normalising the idea for me.

A big thank you to everyone at Potato who helped change my perspective on therapy and personal development. In particular my former manager, Adam, who challenged me to confront my professional fears as well as sharing his own experiences. He also recommended to me a book that I’ve bought about 5 copies of for friends and colleagues over the past year: Feel the Fear and Do it Anyway. Quick plug for Adam’s new start-up FidlLeaf: Wellbeing + Personal Growth Platform.

My turning point

The turning point for me was public speaking. It’s something I have had a fear of for as long as I can remember. But at the same time it’s something that I have always wanted to be able to do.

There were a lot of things I knew I could do to make it easier, from how to find the right subject matter, an event with a supportive crowd and how to practice it until I was confident I could deliver. With the help of my manager at the time and one of our Coaches we broke down all the things I could do into a plan and a series of small steps to get there.

I started small, a lightning talk with one other Engineer that was mostly a demo. Then another shared talk that was more of a technical explanation. Each time these were practiced and rehearsed, they were delivered to an audience of friendly Potatoes (not literally, that’s just how we refer to ourselves at Potato) who were supportive and gave feedback when it was asked for.

The next challenge I gave myself was to take a ridiculous subject and still try to make a 5 minute solo talk about it engaging and entertaining for the audience. I delivered a lightning talk titled "Crumpets and Crumpet-Based Life Hacks" and to this day it’s probably the best received talk that I have delivered.

Finally I found a suitable event to deliver my first public talk at. Potato were hosting DJUGL’s lightning talk events, so the location and a good proportion of the audience would be familiar to me. I prepared a talk about the work experience programme we’d been running at Potato that year, why I felt it was so important, and trying to encourage other companies to give it a go. I practiced a lot (both solo and in front of others), refined it with their feedback, and got to the point where I had learned my speech off-by-heart. I knew I could do all of these things to help myself feel more prepared for it and take the edge of the anxiety. But the thing that really surprised me was that after all of this practice, I no longer felt anxious about the public speaking. I was actually excited to share what I had learned and possibly encourage others to do the same.

This is why it was such a turning point for me. I realised that I was capable, through a bit of hard work and perseverance, of no longer experiencing anxiety about something that used to cause me significant anxiety. It made therapy seem like a much more viable option for me.

Getting help

Asking for help was possibly the single hardest thing I had to do. I was in a very fortunate situation at Potato. We have access to NABS who, among a whole host of other services, offer a series of free therapy sessions to people who need it.

As part of this you have to ring up and speak to someone on the phone and explain the difficulties you’re experiencing and why you would like help with them. I have always found it difficult to talk about my anxiety. I think for me there’s a real sense of shame associated with it, and feeling like I’m failing at something that everyone else is coping fine with (which isn’t true). I get choked up and emotional when I talk about my experiences. In part I relive them as I talk, and getting choked-up for me made it even more difficult, because I was terrified of someone seeing the crack in the facade.

I’m working on this one in therapy, still. I know it’s okay to feel and to express my emotions. I’m sharing a lot more openly about it. But I notice how much my view was shaped by the world I grew up in. This bullshit concept of "big boys don’t cry" that was perpetuated in 90s pop-culture, where a man who expressed his emotions was either a woman or gay. It’s wrong on so many levels.

I hid myself away in one of our smallest meeting rooms in the office for that call, and I’m not ashamed to say that I spent the 15 minutes I had after it ended bawling my eyes out. Then composing myself so that nobody else would see. I’ll throw in a quick thank you here to the person who dropped everything they were doing to get me through that evening, and their ongoing support in my journey. I won’t name them, but it’s an easy guess.

Ongoing support at work

Talking about my mental health in a professional context felt like a really big deal at the time, but it went far more smoothly than I thought.

I spoke directly to our Tech Director and Head of People about it, and honestly the reaction was incredible (thank you Luke & Steph). They told me to make my well-being the top priority. We’d reduce my workload as needed, and I could be completely flexible with my working hours. I was given the freedom to fit my work in around the way I was feeling on any given day and take time out for my therapy sessions in the middle of the day. I was encouraged to take more breaks. We already have an uncounted paid leave policy at Potato, but being told to make more use of it really helped to eliminate any of the guilt I was feeling for taking a week off just to recharge at home without going anywhere.

I was able to do this for as long as I felt I needed to, with no pressure at all from work. I’m mostly working as normal again now, although I still finish early on Tuesdays for therapy.

What I’m doing to manage things now

I’m in a much better place than I was this time last year. I remember on the previous World Mental Health Day wanting to simply tweet out that anxiety was something I was dealing with, and even the thought of that filled me with dread at the time. Now I feel (mostly) comfortable sharing my story publicly, and more than that, I actively want to. Through sharing, I hope to be able to help others in some way, or at the very least normalise the idea of mental health a tiny bit more.

I’m still going to therapy. I started with CBT, learning some skills I can use to manage my anxiety when I experience it. Now I’m doing Psychotherapy with the same therapist to look at some of the underlying reasons that I’m experiencing it and work through them. I don’t see myself stopping this any time in the near future, and I’m totally okay with this.

I have formed a bunch of healthy habits that are helping me to manage things:

Journaling - I journal very often, most evenings. Just writing down all the things that are on my mind, challenging my overly negative thoughts and occasionally writing myself a letter as if I was talking to a close friend who was going through this (we can be way harsher to ourselves than we would be to anyone else).
Gratitude - I keep a gratitude journal. At the end of each day I try to write down 3 good things that happened, or that I’m thankful for that day. I’m up to about 700 entries now.
"Yay me" book - This is something I’ve only recently started (the name inspired by a former Coach Community Lead at Potato). Essentially I’m gathering some of the nice things or successes that either I have thought about myself or have heard from others. I’m grouping them roughly into areas (like professional, personal, relationships) so that if I’m feeling negative, I have a source of positivity to balance things out.
Exercise - I’m a big believer of "healthy body, healthy mind". I used to say that I went a little crazy if it had been more than a week without riding my bike. Last year I took up running as it’s a bit easier to fit into the day. Until I started therapy, doing some hard cardio every couple of days was my crutch. Then I got quite ill and everything fell apart. These days I try and fit in a couple of runs and a couple of workouts each week.
Mindfulness / meditation / yoga - Definitely something I’d like to do more of. I meditate only really when I want to calm down, but it’s effective. I started the 30 days of Yoga with Adriene early in lockdown but haven’t finished it yet. Mindfulness is a huge topic, but for me focusing on my breathing is really something that helps bring me back into the moment when I’m spiraling. I’m a big fan of box breathing and count out the seconds by tapping on my finger tips in turn to add extra mental focus.
Being more open - this was a tough habit to form for me. I have generally been quite guarded and have spent many years absolutely terrified of people finding out about my anxiety. But hiding it away reinforces the idea that there is something to hide, that there’s something wrong or to be ashamed of. There isn’t. I took baby steps to begin with, I would answer truthfully if directly asked. Then I made the therapy block in my calendar visible to others, I started mentioning it in conversation when relevant. Now this post. It’s something I’m still working on, but I’m really proud of the progress I’ve made.

On that last point. I want to thank the two guys at Potato who really changed my perspective on this. It was late January, we were in a coaching triad, I had just started Therapy and wasn’t in a good place at all. When I was asked how I was at the start of the session, I pretty much just broke down into tears, the mask I wore at work came off completely. They handled it really well. At the end of the session one of them commented on how they had no idea I was going through something like that. That it helped them to see that other people had bad days too, and see someone else finding things tough. It helped to normalise what they felt at times. That conversation was probably the biggest inspiration for this post.

Also, I highly recommend the free mental health chatbot app: Woebot. It encourages you to check in, teaches you about various little techniques you can use for self-care, helps you form healthy habits and generally is packed with great little bits of information and encouragement.

Wrapping up

There’s a lot more I could write in this post (there are also many more people I would like to thank), if there’s interest then I’ll gladly do a follow-up. Mainly this was an exercise for me in sharing, and reinforcing to myself that there is no shame in the journey I have gone through, that it’s nothing to hide. I tried to give it a reasonable narrative so that it flowed a bit more naturally than the jumble of thoughts that I wanted to get down. If you take one thing away from this article, let it be this: It’s okay not to feel okay, but you don’t have to stay feeling like that, and you are not alone.

Photo by Finn on Unsplash

Server Side Rendering React App with Deno

Francesco Leonardi — Wed, 24 Jun 2020 12:42:08 +0000

Intro

Two of my favourites things are React and dinosaurs.
In this article I will show how I’ve put them together to develop a server side rendering React application with Deno.

Project Setup

I will assume that we are all familiar with React and Deno. Knowing that Deno is pretty new, if you don’t know how to install it and how it works, I would highly suggest you to have a read at this great introduction before diving into this article.

Now let’s start creating the project structure and the files needed for this tutorial, I’m using Visual Studio Code but any editor will do.
Open your terminal and type:

mkdir deno-react-ssr && cd $_
code .

This will create a new folder called deno-react-ssr and will open it with vscode.
In this folder we will need to create three files, app.tsx that will contain the code of the React component, server.tsx for the server code and deps.ts will contain all our dependencies. Think of it as our version of a package.json.
You will end up with a structure like this:

.
├── app.tsx
├── deps.ts
└── server.tsx

Setting up the dependencies

In deps.ts we will have to export all the dependencies needed for this application to run.
Copy the following code and add it to your file.

// @deno-types="https://deno.land/x/types/react/v16.13.1/react.d.ts"
import React from 'https://jspm.dev/react@16.13.1';
// @deno-types="https://deno.land/x/types/react-dom/v16.13.1/server.d.ts"
import ReactDOMServer from 'https://jspm.dev/react-dom@16.13.1/server';
export { React, ReactDOMServer }
export { Application, Context, Router } from 'https://deno.land/x/oak@v4.0.0/mod.ts';

As you can see, in Deno you import the modules directly from a url.
I’ve decided to import React and ReactDOMServer from jspm as suggested in the documentation for third party modules but you can use any other CDN that provides the same modules.

One unusual thing that may stand out to you could be this:

// @deno-types="https://deno.land/x/types/react/v16.13.1/react.d.ts"

Since we are using typescript, this line of code will inform Deno of the location of the types it needs to import and will affect the import statement that follows. A more exhaustive explanation can be found in the Deno Type Hint manual.

I’ve also decided to use Oak, a middleware framework for Deno's http server that also provides a router, so I’m importing all the modules we will use in the server in addition to the Context type that typescript requires.

Create your React component

This is how our app.tsx component will look:

import { React } from "./deps.ts";

const App = () => {
  const [count, setCount] = React.useState(0);

  const garden = {
    backgroundColor: 'green',
    height: 'auto',
    fontSize: '30px',
    maxWidth: '400px',
    padding: '20px 5px',
    width: '100%'
  };

  return (
    <div className="pure-g pure-u">
      <h2>My DenoReact App</h2>
      <button className="pure-button" onClick={() => setCount(count + 1)}>Add a 🦕 in your garden!</button>
      <p style={garden}>
      { Array(count).fill(<span>🦕</span>) }
      </p>
    </div>
  );
};

export default App;

As with any standard React component, we start by importing React from our deps.ts file.

Then we are going to declare our App component that uses hooks to implement a simple button counter that allows you to add as many dinosaurs as you want in your personal garden!

Setting up the Server

For the server I’m using Oak and the code in server.tsx will look like this:

import {
  Application,
  Context,
  React,
  ReactDOMServer,
  Router,
} from './deps.ts';

import App from "./app.tsx";

const PORT = 8008;

const app = new Application();
const jsBundle = "/main.js";

const js =
`import React from "https://jspm.dev/react@16.13.1";
 import ReactDOM from "https://jspm.dev/react-dom@16.13.1";
 const App = ${App};
 ReactDOM.hydrate(React.createElement(App), document.getElementById('app'));`;  


const html =
  `<html>
    <head>
      <link rel="stylesheet" href="https://unpkg.com/purecss@2.0.3/build/pure-min.css">
      <script type="module" src="${jsBundle}"></script>
    </head>
    <body>
      <main id="app">${ReactDOMServer.renderToString(<App />)}</main>  
    </body>
  </html>`;

const router = new Router();
router
  .get('/', (context: Context) => {
    context.response.type = 'text/html';
    context.response.body = html;
  })
  .get(jsBundle, (context: Context) => {
    context.response.type = 'application/javascript';
    context.response.body = js;
  });

app.use(router.routes());
app.use(router.allowedMethods());

console.log(`Listening on port ${PORT}...`);

await app.listen({ port: PORT });

As always we need to import all the dependencies we will use in our server.
We will also import our App we created earlier, as you can see the extension .tsx is required in Deno so don’t forget it!

Next step is to create our Oak server application and we’ll also need to define some routes:

'/' will serve our HTML page that contains the rendered app.
'/main.js' will serve our application code that is needed to hydrate the client side React application.

Finally we tell our application to use the route we just created and start listening on port 8008. You can notice I’m also using router.allowedMethods(), it’s a middleware that lets the client know when a route is not allowed.

Run the application

Running the SSR React application we just created is extremely simple, you just need to use the following command:

deno run --allow-net ./server.tsx

Deno is built secure by default, that means that a Deno application will not be able to access your network, to overcome this we'll just need to use Deno's --allow-net flag.

Now the only thing missing is to open http://localhost:8008/ and enjoy your new App!

Conclusion

I hope you enjoyed the brief tutorial illustrated in this article and I’m looking forward to seeing what will happen next and how more complex applications can be built with this stack.

If you are still unclear about anything we’ve done or want a full reference of the code, here’s the GitHub repository.

An Introduction to Deno

David Gauld — Wed, 03 Jun 2020 08:53:46 +0000

Since its introduction in 2009, Node.js has gained huge popularity and usage. But with that, issues with its ecosystem, feature adoption and dependency bloat have started to surface.

So, in true JavaScript community style, there's a new kid on the block: Deno 🦕

What is Deno?

Deno is a new runtime for JavaScript and Typescript, built on Google's V8 engine and written in Rust. It was started by Ryan Dahl (who famously started Node.js) as an answer to the problems he saw with Node.js and its ecosystem.

Ryan announced the project a couple of years ago at JSConf EU during a talk in which he went into some detail about regrets he had over Node.js, particularly around decisions he did (or didn't) make along the way. It's definitely worth a watch.

Although seen as a Node.js successor, there are some major differences between the two:

Deno has no package manager.
Deno implements a security sandbox via permissions.
Deno has a standard library for common tasks.
Deno has first-class TypeScript support.
Deno will be able to be compiled into a single executable.

No package manager

Instead of the complex module resolution that Node.js supports, Deno simply uses URLs for dependencies and doesn't support package.json. Import a relative or absolute URL into your project, and it'll be cached for future runs:

import { listenAndServe } from "https://deno.land/std/http/server.ts";

Third party modules can be added to Deno's website via https://deno.land/x/.

Security

By default, a Deno application will not be able to access things like your network, environment or file system. Unlike Node.js, in order to give an application access to this sandboxed functionality you'll need to use one of the provided flags:

$ deno run server.ts --allow-write

You can see all of Deno's supported security flags by running deno run --help.

Standard library

Much like Go, the Deno team maintains a core, stable set of utilities in the form of a standard library. These cover utilities such as logging, http serving and more. If you need to implement a feature, it's probably best to check the standard library first to see if it's already supported.

You can see what's available in Deno's standard library via its source code.

TypeScript

Unlike Node.js, Deno has first-class support for TypeScript (most of its standard library is written in it). This means that ES modules and all the goodness of static typing are available right from the start, with no transpilation required on the user side. It's worth noting however that Deno still needs to compile TypeScript to JavaScript behind the scenes, and as such incurs a performance hit at compile time unless the module's already been compiled and cached.

If you'd rather not use TypeScript, Deno supports JavaScript files too.

Single executables

Although not implemented yet, one future ambition is to allow a Deno application to be compiled down into a single executable. This could vastly improve and simplify the distribution of JavaScript-based applications and their dependencies.

You can track the progress of single executable compilation on GitHub.

Running Deno

Now we know what Deno is, let's have a play with it.

The Deno website provides plenty of installation options, but since I'm using macOS I'll use Homebrew:

$ brew install deno

Once installed, deno should be available to use from your terminal. Run deno --help to verify the installation and see what commands it provides.

Deno also gives the ability to run applications with just a single source URL. Try running the following:

$ deno run https://deno.land/std/examples/welcome.ts

Download https://deno.land/std/examples/welcome.ts
Warning Implicitly using master branch https://deno.land/std/examples/welcome.ts
Compile https://deno.land/std/examples/welcome.ts
Welcome to Deno 🦕

Deno downloads the module from the provided URL, compiles it and runs the application. If you visit the above module's URL in your browser, you'll notice that Deno also provides a nice browser UI for the module's source code, which in this case is a simple console.log statement.

Of course running arbitrary third party code like this should always be treated with caution, but since it's an official Deno example we're all good here, and as mentioned above, Deno's security flags should help limit any potential damage.

You'll also notice that if you run the same command again, the welcome.ts module isn't redownloaded. This is because Deno caches modules when they're first requested, allowing you to continue work on your project in places with limited internet access.

If for any reason you want to reload any of your imports, you can force this by using the --reload flag:

$ deno run --reload https://deno.land/std/examples/welcome.ts

Building your first Deno app

To demonstrate a few of Deno's features, let's dive into a simple API example. Nothing too complicated, just a couple of endpoints. And in true Potato style, we'll use different types of spuds for our test data.

It's worth noting beforehand that this demo won't rely on any third party modules, and will use an in-memory data store. There are plenty of libraries (some are linked at the bottom of this article) that aim to make this simpler, but for now let's stick with vanilla Deno!

Setting up the server

Firstly, let's create a TypeScript file. Don't worry too much if you're not familiar with TypeScript, you can use plain JavaScript too. I'll create mine at server.ts.

Next, we need to set up a simple web server. As we've already seen, Deno has a standard library that contains some useful functions with one of these being the http module. Taking inspiration from Go, there's a helpful listenAndServe function that we can use:

import {
  listenAndServe,
  ServerRequest,
} from "https://deno.land/std/http/server.ts";

listenAndServe({ port: 8080 }, async (req: ServerRequest) => {
  req.respond({ status: 204 });
});

console.log("Listening on port 8080.");

What's happening here? Firstly, we import the listenAndServe method from Deno's http module, and the ServerRequest interface to allow TypeScript type checking. Then, we create a simple server that listens on port 8080 and responds to all requests with a HTTP 204 No Content response.

As mentioned above, by default Deno will prevent our application from accessing the network. To run this successfully, we'll need to use Deno's --allow-net flag:

$ deno run --allow-net server.ts

We can verify our application is running correctly using cURL in another terminal tab:

$ curl -i -X GET http://localhost:8080

HTTP/1.1 204 No Content
content-length: 0

Environment variables

To show how environment variables are passed to Deno, let's add support for a dynamic port number since this is a common use case amongst production servers. Deno provides the Deno.env runtime library to help with retrieving the current environment variables:

import {
  listenAndServe,
  ServerRequest,
} from "https://deno.land/std/http/server.ts";

const { PORT = "8080" } = Deno.env.toObject();

listenAndServe({ port: parseInt(PORT, 10) }, async (req: ServerRequest) => {
  req.respond({ status: 204 });
});

console.log(`Listening on port ${PORT}.`);

We can now pass a custom port to our application when running it. One thing to note here is that we need to convert the port variable to a number, since all environment variables are passed as strings and listenAndServe expects a number for the port.

When running this, we'll also need to use the --allow-env flag to grant the application access to our environment variables:

$ PORT=6060 deno run --allow-net --allow-env server.ts

Routes

For the sake of simplicity, we'll implement a very simple router ourselves using a good old fashioned switch statement.

Firstly, let's create some empty route handlers. We'll create two: one to allow a new spud type to be added to a list, and another for retrieving the current list. For now, let's return a HTTP 204 No Content response so that we can test our application along the way:

const createSpud = async (req: ServerRequest) => {
  req.respond({ status: 204 });
};

const getSpuds = (req: ServerRequest) => {
  req.respond({ status: 204 });
};

Next, let's create a handleRoutes method that'll act as our router:

const handleRoutes = (req: ServerRequest) => {
  if (req.url === "/spuds") {
    switch (req.method) {
      case "POST":
        createSpud(req);
        return;
      case "GET":
        getSpuds(req);
        return;
    }
  }

  req.respond({ status: 404 });
};

Here, we're checking every incoming request URL and method, and directing the request to the appropriate function. If neither the URL nor the method matches anything expected, we return a HTTP 404 Not Found to the user.

Finally, let's call the handleRoutes function from our original server and add a try statement around it to catch any errors and return an appropriate response:

listenAndServe({ port: parseInt(PORT, 10) }, async (req: ServerRequest) => {
  try {
    handleRoutes(req);
  } catch (error) {
    console.log(error);
    req.respond({ status: 500 });
  }
});

Using a try statement and catching errors in this way is usually a good idea with Deno, since unlike Node.js a Deno application will exit when it encounters an uncaught error.

We should now be able to send POST and GET requests to http://localhost:8080/spuds and get an expected HTTP response:

$ curl -i -X GET http://localhost:8080

HTTP/1.1 404 Not Found
content-length: 0

$ curl -i -X GET http://localhost:8080/spuds

HTTP/1.1 204 No Content
content-length: 0

$ curl -i -X POST http://localhost:8080/spuds

HTTP/1.1 204 No Content
content-length: 0

Create handler

Next, let's add an in-memory store for our spud types:

const spuds: Array<string> = [];

In order to process the incoming spud data, we'll need to be able to parse the request's JSON body. Deno doesn't have a built in way of doing this at the time of writing, so we'll use its TextDecoder class and parse the JSON ourselves:

const createSpud = async (req: ServerRequest) => {
  const decoder = new TextDecoder();
  const bodyContents = await Deno.readAll(req.body);
  const body = JSON.parse(decoder.decode(bodyContents));
};

What's happening here? Essentially, we're first using the Deno.readAll method to asynchronously read the contents of the request body (a Reader) as bytes. We then decode that into a UTF-8 string, and finally parse it as JSON. Phew.

We can then proceed to add the spud type to the store we created earlier, and return a HTTP 201 Created response. Our final create handler should look something like this:

const createSpud = async (req: ServerRequest) => {
  const decoder = new TextDecoder();
  const bodyContents = await Deno.readAll(req.body);
  const body = JSON.parse(decoder.decode(bodyContents));

  spuds.push(body.type);

  req.respond({
    status: 201,
  });
};

Get handler

To implement our GET handler, we'll essentially reverse the operation we wrote above by using Deno's TextEncoder. We'll then set the relevant header to "application/json" using Deno's Headers class and return the spud data with a HTTP 200 OK response:

const getSpuds = (req: ServerRequest) => {
  const encoder = new TextEncoder();
  const body = encoder.encode(JSON.stringify({ spuds }));

  req.respond({
    body,
    headers: new Headers({
      "content-type": "application/json",
    }),
    status: 200,
  });
};

Final application

Our final file should look a bit like this:

import {
  listenAndServe,
  ServerRequest,
} from "https://deno.land/std/http/server.ts";

const { PORT = "8080" } = Deno.env.toObject();

const spuds: Array<string> = [];

const createSpud = async (req: ServerRequest) => {
  const decoder = new TextDecoder();
  const bodyContents = await Deno.readAll(req.body);
  const body = JSON.parse(decoder.decode(bodyContents));

  spuds.push(body.type);

  req.respond({
    status: 201,
  });
};

const getSpuds = (req: ServerRequest) => {
  const encoder = new TextEncoder();
  const body = encoder.encode(JSON.stringify({ spuds }));

  req.respond({
    body,
    headers: new Headers({
      "content-type": "application/json",
    }),
    status: 200,
  });
};

const handleRoutes = (req: ServerRequest) => {
  if (req.url === "/spuds") {
    switch (req.method) {
      case "POST":
        createSpud(req);
        return;
      case "GET":
        getSpuds(req);
        return;
    }
  }

  req.respond({ status: 404 });
};

listenAndServe({ port: parseInt(PORT, 10) }, async (req: ServerRequest) => {
  try {
    handleRoutes(req);
  } catch (error) {
    console.log(error);
    req.respond({ status: 500 });
  }
});

console.log(`Listening on port ${PORT}.`);

Let’s give this a test:

$ curl -i --data '{"type": "maris piper"}' -X POST http://localhost:8080/spuds            

HTTP/1.1 201 Created
content-length: 0

$ curl -i --data '{"type": "king edward"}' -X POST http://localhost:8080/spuds            

HTTP/1.1 201 Created
content-length: 0

$ curl -i -X GET http://localhost:8080/spuds                            

HTTP/1.1 200 OK
content-length: 54
content-type: application/json
{"spuds":["maris piper", "king edward"]}

If you'd rather, you can view this file as a Gist or run it directly with the following command:

$ deno run --allow-net --allow-env https://gist.githubusercontent.com/dcgauld/205218530e8befe4dfc20ade54e7cc84/raw/9eff7733cf017f33b2bf3144937f97702ae4fc63/server.ts

We just created our first Deno application!

Conclusion

Hopefully this article has given you a glimpse into the world of Deno, and some inspiration to start using it for future projects. I'm excited to see what the future holds for the project, especially around things like single file executables and the potential to run certain Deno modules in the browser.

If you'd like to learn more about it and its features, I'd really recommend giving the Deno manual a read.

Useful links

Official Deno examples
Deno manual (includes information about Deno’s built in formatter and testing library)
Deno standard library
awesome-deno

We created our first Deno API with no third party modules, but there are many libraries out there already that aim to simplify that process. Some examples:

How Potato Code Remotely

Luke Benstead — Thu, 21 May 2020 08:17:15 +0000

At the time of writing, we’re in the middle of the COVID-19 lockdown. As with most other companies, the lockdown has required us at Potato to rapidly change the way we work day-to-day. We’re a tech company, so that has given us a big advantage in this rapid and unsettling change of routine. But as a company, we’ve historically encouraged our engineers to travel into our central London office most of the time. Working from home has always been a perk at Potato, but never the default position.

Fortunately we’ve been unintentionally preparing for this day by making the right choice of tools. In this post I hope to give an overview of our toolset, and how it’s allowed us to continue to operate as normal.

Cloud-First

Right from the beginning of Potato, we’ve always pushed to use tools that are hosted by others. We’ve never wanted to spend our time being sysadmins, and we’ve always resisted the urge to host anything inside our offices. We wanted all of our stuff to be available anywhere, from any platform. In the past the option of running a VPN, and hosting software internally has come up, but we’ve steadfastly refused the temptation to do so - the risk of losing access, of having to maintain it, and of a single point of failure (what if the office burned down?!) were all reasons to avoid it.

Also, we wanted to make sure that any of our Engineers could deploy any of our projects from anywhere with an Internet connection. In the past we’ve deployed from trains, planes, pubs, and on one occasion a long while back - a locked bathroom (long story!).

Finally, if anyone ever had their laptop stolen out of the back of a van while climbing (true story), nothing would be lost if everything is saved online.

For this reason, (along with our Google history) we’ve based all of our internal systems on Google’s GSuite. Potato runs on Google Docs, Sheets, Calendar and of course Gmail. This has given us access to everything from anywhere, and the decision to base everything around GSuite has allowed us to continue working seamlessly despite now all being remote.

Slack / Google Meet

For communication, we’ve been long-time users of Slack, (although before this we were pretty sold on Hipchat). As it’s cloud-based we’ve just continued messaging as normal without disruption (though probably making a bit more use of threads to keep things organised).

For video calls we’ve always used Google Meet (previously Hangouts). The number of ad-hoc catch-ups has increased, and we hold daily drop-in sessions for people who just want a bit of socialising. On Fridays we’ve rebooted our traditional TPIF (Thank Potato It’s Friday) into a virtual mass video call, armed with beverages of choice and reams of friendly banter!

GitLab

A couple of years ago we moved all of our development over to GitLab. The intention was to bring all of our end-to-end product development life-cycle under one tool. Although we had the option of hosting GitLab ourselves, using GitLab.com’s hosting has saved us the overhead of managing it, and of course it means that our project management tools are available from anywhere.

Now that we’re all a bit more involved in using GitLab directly day-to-day, we’ve also implemented a Chrome/Firefox extension that makes things a little easier.

Visual Studio Code - Live Share

The ability to grab another developer to help solve a problem has always been a key part of Potato culture, and historically one that required that other dev to be in the same room. When we were forced into remote working this was one area where we needed to find a new tool to help us, and we did so by using Visual Studio Code’s “Live Share” plugin. This plugin lets you host a programming session that you can invite others to collaborate in (think Google Docs, but for code editing). Combined with a Google Meet call it makes for a great, and simple pair-programming experience.

Figma

The final tool in our toolbox is Figma. Until recently our designers were heavily invested in using Sketch as their main design tool, but we’d noticed issues even ahead of the lockdown that made this problematic.

Firstly, it broke the cloud-first rule. Sketch ran locally, saved files locally, and it wasn’t cross-platform which caused a load of headaches for our Linux-using developers. We came up with workarounds for these things (e.g. using the “Measure” plugin for detailed exports, teaching the designers how to use Git etc.) but it never really fitted the culture of Potato.

Then Figma came along, and not only did the designers find that it was a better tool, but it’s based in the cloud and so is platform-agnostic.

Honourable Mentions

In addition to our development toolset, we use a number of other web-based tools day-to-day, these include:

Harvest + Forecast - for time tracking and project scheduling
Bamboo - for managing our people
Trello - For workshopping and lightweight task tracking
TrakStar - For managing the career progression of our people # Summary

There we are, a complete toolset for seamless remote working - that were built up accidentally by just following the rule that our stuff should be accessible from anywhere, and we don’t want to be the ones running it!

Parcel and Rust: A WASM Romcom

Alex Eales — Fri, 15 May 2020 10:37:07 +0000

Web Assembly (WASM) and Rust have been growing and evolving over the last couple of years, so what’s it like to use them together?

Introduction

I’ve wanted to use Rust and WASM for a while due to a number of reasons: small bundle size, low-level access with reliable performance, and all the perks that come with Rust (strong type safety, zero-cost abstractions, etc.). So, when I was presented with the opportunity of 2 weeks off-project learning, there was no excuse not to give Rust and WASM a try!

What followed over the next 2 weeks or so was a bit of a programming rollercoaster for me, something all programmers have been through many times. But when it came time to write my experiences up for this article, I noticed there was a pattern, this experience wasn’t just any rollercoaster…it mapped perfectly to the structure of a Romcom! So, to explain and analyse this not officially supported pairing of a web application bundler and a systems programming language, we will be following the standard 10 part Romcom format, for structure and a bit of comedic relief.

Part 1: “An Unfulfilled Desire”

Another reason I wanted to use Rust and WASM is because it was new and shiny, plus it would be nice to hook up the Rust program to a nice web interface. One problem, Rust and WASM is only officially supported with Webpack as a bundler. To me, Webpack was that Ex in a Romcom, it was never a good relationship and we could never make it work. But, it seemed that it may be a necessary evil to reach my goal of making something using my lost love, Rust.

Part 2: “Meet cute”

So, I grudgingly start to clone the Rust WASM Webpack template as I’m flashed back to a previous project, watching myself as I battle with Webpack trying to compile a Single Page App (SPA). The list of dependencies growing with every plugin. I spam Ctrl + C, “No there must be something else” I think. And that's when it hits me, “Parcel! I remember it saying something about WASM?” I think as I quickly navigate to the Parcel website, and there it is, this is what I have been looking for, and after a quick npm install, I’m head over heels.

Part 3: “Happy Together”

One npm init and npm install -D parcel-bundler later and we are off to the races. Parcel supports importing .rs files in JS and TS out of the box so in a simple HTML5 boilerplate with a main.js I do just that. The rust file contains a simple function which when given 2 numbers returns their sum, some extra Rust to tell the compiler not to mangle the function name and it’s done! The JS calls this function and displays the output in the DOM, a simple example but this seems to have everything I need…

Part 4: “Obstacles Arise”

But, as with most romcoms, a bump in the road pulls the relationship into question. For Rust and Parcel, this issue was returning or accepting strings in functions. No matter what I did, it wouldn’t work and streams of undefined would plague my console. Although there seemed to be a solution, the well supported “wasm_bindgen” package provides a polyfill for things missing between Rust and JS! So, make a Rust project with a cargo.toml, add the wasm_bingen crate, import and run… oh wait. Parcel doesn’t seem to work with wasm_bindgen even with a plugin someone on a GitHub issue cites as the solution...what now?

Part 5: “The Journey”

After a few minutes of frantic Googling and skim reading GitHub issues and various tutorials on blogs I find an alternative package, stdweb. Seems to have most of the functionality of wasm_bindgen and a handy tutorial with how to set it up with Parcel! A quick switcheroo of the packages in the cargo.toml, some slight code tweaks and we are back on course with strings being returned and received in this simple app. Time to start making something slightly more complex...a simple genetic algorithm simulator!

Part 6: “New Obstacles”

Okay so new project, Parcel - installed, Rust module - created, stdweb - installed lets get this show on the road! In my head the idea is simple, make a struct in Rust to represent the Genetic Algorithm Simulation, add some methods to it to get the population or simulate a generation, and then simply instantiate and use it in JS. Can’t be too hard surely (foreshadowing)! Lets just make the struct, seems to be instantiating in JS, lets add some methods onto the struct… wait...what? It seems exporting structs is temperamental at best when using stdweb and parcel am I back to square 1 already?

Part 7: “The Choice”

All seems lost, I’m out of viable Rust packages to try and have a console littered with errors, is there nothing I can do? In a last ditch effort I tried manually compiling the .wasm file myself and importing it but after 5 edits to the Rust file I can already feel this getting tedious… As I crawl through GitHub issue after GitHub issue webpack comes up again and again as the solution, maybe I need to accept defeat and go back.

Part 8: “Crisis”

F*** I’m going to have to use Webpack, I think as I go back to the start and open the Webpack Rust template, defeated.

Part 9: “Epiphany”

As the Webpack Rust template repo clones I took to Google one last time, using one of my old searches, hoping for a miracle. Wait, what's this? A GitHub issue about Parcel and WASM_Bindgen which wasn’t there before? The Google search index must have only just found this to be relevant? Hold on, someone has linked a template here for Rust, WASM_Bindgen, and Parcel! Thank the Search Engine Gods the project may be saved!

Part 10: “Resolution”

There it was, under my nose the whole time on the rustwasm GitHub repository. I quickly cloned the repo and followed the set-up instructions and it all worked flawlessly. In the end this search had become a real Cinderella story with the perfect match being found on the stroke of midnight.
So now, time to make something cool with it! I didn’t want to focus too much on the front end and slaving over SCSS making it look nice, so I turned to an old friend: TailWindCSS, a utility-first CSS framework which I have set up with PostCSS and Parcel before. With all that done I build out a simple layout with a side panel for configuring the simulation and a main panel to hold the results of the simulation. After deciding on the look and feel of the page I start to make some TypeScript components for controlling and displaying the simulation.

Finally after getting the site up and running with some mock data from a simple set_interval I start to hook it up to the WASM. It ends up being remarkably simple, just import the module object from the Rust projects’ cargo.toml and then all the structs and functions are attached to it! A few little tweaks and testing and what do you know, it's all working and converging! A little bit of cleanup and then I deploy it on Firebase and it’s hosted happily ever after.

Conclusion

Now this article has been a bit of fun writing in this style and talking about a project I’ve genuinely enjoyed every minute of, and every up and down. But, what is it actually like using Rust and Parcel? I can wholeheartedly say it is a true pleasure...once you find the right resources. Parcel just makes it so easy with no configuration needed for most projects, and although it might not be as fast on larger projects it will give the big dogs a run for their money 9/10 times!

As for Rust and WASM it was everything I expected and more. Rust has always been a language I have loved programming in and, although it's a challenge, it never gets old. However, if I am to complain about one thing about this experience, it would be the lack of intellisense on the exported JS module. It may not be an issue when you write the tiny Rust file being compiled but I can see this being painful on larger projects using Rust, WASM, and Parcel.

In conclusion, if you have ever had a little voice telling you to give Rust or WASM a go, I would highly recommend it and maybe consider using Parcel to avoid the emotional rollercoaster I went on to get it done!

GitLab Details Sidebar

Michael Strutt — Tue, 12 May 2020 10:23:53 +0000

Why and how we created the GitLab Details Sidebar extension for both Chrome and Firefox.

The issue at hand

Like many companies, at Potato we use GitLab as part of our everyday product development workflow. It’s feature-rich, open source and the team are great at taking on feedback and feature requests from the community.

It seemed however, that one area of GitLab seemed to suit the Engineer mindset much more than it suited the Product mindset. Our Product Leads had a persistent issue with the GitLab boards where they were unable to see or edit descriptions and comments of the issues directly from the board view. This was a feature that those who had previously been familiar with tools such as JIRA particularly struggled with.

We did a bit of searching around and found that this issue had already been raised. It wasn’t in a state where merge requests were being accepted, or the final direction had been decided. So we set about seeing what we could do to address the issue ourselves in as lean a way as possible. A design had already been put together on the issue in question, so we had everything we needed to jump straight into dev tools and start tinkering.

Rapid prototyping

After exploring a couple of different approaches, it became clear that the fastest way to get a feature-rich details view would be to use the details page itself, leveraging an iframe to include it into the existing sidebar. As well as being simple to execute, this would ensure that any updates to the functionality of the details page would be reflected in our extension. Then it was a case of adding a click event to listen for when an issue was clicked on, and reading the URL for the link to update the source of the iframe.

The next thing to validate was how to inject the iframe into the page of everyone who wanted it. A Chrome Extension seemed like the obvious candidate here, as most of us use Google Chrome at Potato, and they can be easily ported over to FireFox to extend the reach (and also to please our Tech Director, Luke). I hadn’t personally built a Chrome Extension before, but a quick bit of research showed that a feature called Content Scripts would give us a simple way to inject CSS and JS files onto pages that match our URL pattern.

Defining the MVP

Once we’d proved to ourselves that this was possible, and we had a sensible direction in place, we wanted to define the minimum set of requirements that would make this extension useful. The goal was to get this to real users at Potato and see if we can improve the workflow for our Product Leads. After a quick brainstorming session, the set we came up with was:

Ability to see and interact with the issue details view directly from the board
Option to toggle the expanded details view
Expanded state should persist between tickets and on reload
Users should still be able to interact with the full board in the background
Expanded view is not appropriate for small screens
Details view should have a stripped back UI to integrate better into the sidebar

Polishing up the MVP

We had a few things to do to get from the proof of concept that we were copy-pasting into the developer console to our first release candidate, some of which proved easier than others. Saving the toggled state was simple enough. The toggle relied on flipping a boolean in the code and updating some CSS classes accordingly. localStorage seemed like a good candidate for the implementation as the extension is installed at a browser level, just like the scope of localStorage. All that needed to be done to persist the state was writing the new state every time it was changed. Then on initialisation, read this value back from localStorage (converting between string and boolean).

One thing that proved more challenging was correctly handling the creation of new issues on the board. Using Mutation Observer seemed like a good fit for this, and it was a good excuse for me to try it out with a more complicated use-case. Initially this seemed really simple to filter the mutations down to the creation of new cards but there were a few edge cases. Dragging and dropping created clones of each card, but this could be fixed by tracking which issue numbers had been seen before. The final hurdle was to handle the startup when all of the issues were being added to the board asynchronously. We didn’t want this to treat each card being added to the board the same way as a new issue being created. As the cards are added all at once, a simple debouncing of the function handling new cards being added reduced the occurrences down to a single firing of the event that could be safely ignored until user interaction.

Finally, to get things ready for internal testing, we needed to create a store page, give our extension a name and capture a screenshot of the extension in action.

Internal dogfooding & finishing touches

The newly named GitLab Details Sidebar was very well received across the teams at Potato. People across the disciplines found it a useful addition to their workflow and it swiftly became the most installed internal Chrome Extension at Potato. From this use we discovered and fixed a few bugs, and got some good feedback on some potential future enhancements.

As well as offering some bug fixes, one of my colleagues made a great contribution to speed up the workflow. Using GitLab’s CI pipeline to automate the release process, uploading a zip file directly to the Chrome Web Store, then publishing the extension via the API. Now anyone in the team can release a successful commit from master without having to build anything locally.

Publish to the world

Finally we were ready to share our creation. We included a simple popup-window to show some info about the extension and link back to the issue board and the source code and then change the extension from private to public and republished.

You can find the GitLab Details Sidebar on the Chrome Web Store and on the Add-ons for Firefox site where you can install it completely free. We fully welcome any feedback or feature requests. Hopefully this extension will improve your daily workflow just as much as it has ours.