DEV Community: Angus Allman

The Best Free Django Hosting and Deployment in 2022

Angus Allman — Mon, 29 Aug 2022 07:59:26 +0000

TL;DR PyHost is a great Heroku alternative.

The world of Django hosting has been turned on its head. As of 25th August 2022, Heroku has announced that it will be discontinuing the free service it offers from 26th October 2022 onwards. What does this mean for Django developers looking to get a site quickly deployed so you can show friends and family your exciting new project? It means a whole world of options just became more viable and PyHost is one of them.

What does PyHost offer?

At its core, PyHost is a server provisioning system. You tell it what server you want and it goes and creates it. However, it installs everything you need to get your Django site up and running based on the information you give it. Need an older Python version or a different DB driver? No problem!

Once you’ve filled in the form, PyHost will set up your server (there’s a lot to install so it can take about 5-10 minutes at times) and then you’re in. Simply connect your server to your Git provider (Github, Gitlab, and Bitbucket). Then you can create your site from an existing git repo and you’re away.

Deploying a site

PyHost keeps track of all its deployments so you can read the logs and see what, if anything, went wrong. Sometimes it could be as simple as not having an OS environment variables set.

It’s still actively worked on

PyHost just works. It feels like magic having the site set up without having to put any work in. All the best systems have areas they could be improved upon, though. This is why it’s reassuring to know that PyHost is still actively in development and being built upon. With new features released frequently and existing bugs squashed faster than you can say “Django” you're in good hands.

On top of constant development, there’s also one-to-one email support available for any issues or questions which may arise. I’m always happy to help!

Not convinced?

If you’d like to try PyHost but are still unsure, then please drop an email to admin@pyhost.io with any questions or queries. PyHost has a free plan available to everyone and that will never change. At the moment you can create a server and as many sites as you like but only with pyhost.io subdomains. If you want to use a custom domain then, for now, you’ll need to use at least the basic plan. I’d say that’s fair though 😉.

Conclusion

PyHost is a valuable tool for any Django developer, whether they’re a beginner or a dab-hand at all things Python. It deploys and hosts your site to your own server, unlike many other Django hosting solutions, which means that you get to stay in full control and which makes Django a fantastic Heroku alternative since their dropping of their free plan. So come and give it a try! Like I said before, please do not hesitate to shoot any questions over to admin@pyhost.io and I’ll be sure to get you pointed in the right direction.

Thank you for reading and if you feel like someone you know or your Twitter followers could benefit from this post then don’t forget to share!

PyHost is on Twitter @pyhost so don’t forget to mention us!

How to Filter Complex Javascript Arrays

Angus Allman — Tue, 29 Mar 2022 16:42:39 +0000

TL;DR I've revived an open-source npm package that I initially built a couple of years ago but have given some TLC in the last few days. You can find it here: https://github.com/allmanaj/or-where.

A few years ago, a colleague and I were faced with a problem. We had to make a dashboard with dynamic, intelligent filters for multiple types of data from objects to strings. Usually this would have been a relatively simple thing to accomplish with Javascript's filter() function but in this instance we had no real way of knowing what the user was going to try and filter on since the data could vary so much. To help solve the problem, I built a small, single JS file which allowed us to construct logic like Laravel's Eloquent queries. It meant that we could turn a long, meandering condition inside the filtering function to look more like English. Ultimately, we loved working with it and I released it as a small npm package.

Let's take a look at an example and see how it makes life simpler for developers who find themselves with a whole load of data and no easy way to filter it:

// without or-where
users.filter(user => {
    return (user.name == 'Angus' || user.name == 'Jess' || user.name == 'Aaron') && user.age >= 25;
});

//with or-where
filter = new Builder(users);
filter.whereIn('name', ['Angus', 'Jess', 'Aaron'])
      .where('age', '>=', 25)
      .get()

Even in this relatively basic example it's easy to see the benefits of it. Rather than needing to read the logic gates and pay attention to the brackets, you can read the query like it's English.

Using the built in methods (where(), orWhere(),... etc) you build up a query which is eventually passed to Javascript's filter() method when you call get(). That's all there is to it! You can create incredibly flexible queries with a few simple building blocks leaving your code readable and efficient. What's not to love?

You can find the full documentation on github: https://github.com/allmanaj/or-where. Feel free to contribute or open an issue if there's a feature you feel the package is missing!

I'd really appreciate it if you'd take a look and share it with anyone who might find the package useful, and leave a star if you're feeling generous 😉

How I Learned to Love Remote Working

Angus Allman — Thu, 20 Aug 2020 22:40:32 +0000

I hate working remotely.

Well… at least I did. For some reason, it never clicked with me. I always found that I couldn’t focus on one task for any amount of time before I ended up on YouTube watching videos which, realistically, I have no interest in. I mean, sure, watching someone build perpetual motion machines is great every now and then but not when you’re 3 hours into a video hole putting off fixing a bug.

I’m not sure whether it was the fact I didn’t have a choice about going remote (thanks, COVID) or whether I just needed to give it a chance but I’ve found that remote working is amazing.

As with everything in life, there are upside and downsides to being a remote worker (See this great article about what can go wrong when companies move towards remote) but these are the stand-out points that make being a remote web developer right for me

The 10-second commute

I’ve not been late to work in months! Also, as long as you don’t have daily video stand-ups, then rock up in pyjamas, why not? I would get dressed at some point in the morning though or I find that it throws me all out of whack otherwise.

Saving all kinds of money 🤑💰

Working in London, and I’d assume it’s the same in most towns or cities, I got into the habit of popping into my favourite coffee shop for breakfast if I left my house in a rush, or sampling the delights of the god knows how many great restaurants in Soho. No matter what I did, it all added up.

No word of a lie, since I’ve been working remotely, I’ve managed to save more money than I’ve ever had in my account up until now. It’s an amazing feeling and it’s also allowed me to move to a house so we’re no longer in an old, pokey one-bed flat in the London commuter-belt all because of remote working. There’s that and having that little cushion behind me is a great feeling.

No Strings Attached

Tying quite neatly to my last point about moving house. You can go anywhere. You’re not tied to a certain radius around your company’s office so that you can have a reasonable commute. You’ve got the 10 second commute now, so go where you like.

Always wanted to bum around in the Mediterranean for a bit? Go for it! just make sure you have a steady internet connection and the world’s your oyster. While I run the risk of being cliché, I feel that no phrase sums it up better than the old adage: “Home is where the Wi-Fi is”.

Work on what you want

I’m a busy boy. I have PyHost, this blog, and about half a million other half-finished side-projects on the go (who doesn’t). I never had the time, or the dedicated work-space to spend on them before.

A particularly effective way of making the time, I’ve found, is starting “work” a little early to give you 40-mins to an hour to focus your projects before you have a full day doing actual work. This way you’re working on your projects when you’re most fresh and not drained from the 9-to-5.

The bonus of having more hours of the day to myself and not spent on a train is that I get to spend more time at home with my partner and seeing family. It’s the best of both worlds.

You want a long lunch?

Go for it. As long as you don’t have a call or anything then who's going to see?

𝓣𝓻𝓮𝓪𝓽 𝔂𝓸' 𝓼𝓮𝓵𝓯

Micro-managing is a thing of the past

There’s no one to come and breathe down your neck and ask whether the feature is done or the bug is nearly solved or any of that off-putting stuff. Essentially, it’s liberating. I feel trusted to do good work and know that if I need to then I can reach out and ask someone but other than that, as long as I deliver, I can make the whole process as collaborative or as independent as I like.
And I can spend all day on a call to a colleague just chatting shit if I like (hypothetically of course, I wouldn’t dream of it)

To sum it up

In the end, it all boils down to freedom. The freedom to work at your pace and do it on your terms makes the world of difference when it comes to work-life balance and my general attitude towards work. There are also so many fewer possible stresses. If I have a bad day, then it’s because of something at work and not just an idiot on the drive home. I feel great not having had to travel for an hour and a half each way to my office and, on the odd occasion that I work late, I’m at least not getting home at 10PM anymore.

If you’re debating working from home and think that these reasons sound good enough to you, then I wholeheartedly recommend it! Welcome to the club. We don’t have membership cards yet but I’ll get my people on it 😉

How do you find working remotely? Love it or loathe it, let me know over on twitter @allmanajD!

That’s all from me, have an awesome day. ✌️

Launching my first Saas Product

Angus Allman — Fri, 10 Apr 2020 11:02:36 +0000

What is it?

In short, PyHost is a server provisioning tool for Django apps. Basically, it gets your Django apps deployed in minutes with no need to even touch the command line. It can create a new server for you or connect to an existing one, install everything you need to host Django apps, and manage your sites, SSH keys, environment variables and databases. Whether you have a new domain or just want to use a subdomain is up to you but PyHost accommodates both.

Why did I build it?

I've played with a load of web frameworks over the years and always had a bit of a soft spot for Django. I spent MONTHS building an app with a Django API but when it came to deploying it I just couldn't. It took me weeks of learning about Linux servers and Apache and SSH and a number of other technologies which, for someone new to Sys-Admin, were incredibly intimidating to even get anywhere close to having a setup I was happy with and that wasn't breaking constantly.

Over the next year I naturally absorbed information about servers and deployment through my job at an agency called Purr Group. I then decided that I'd had enough of messing around with servers and it taking hours to deploy a site so I built PyHost (which meant messing around with servers and spending countless hours deploying sites for over a year, but it felt worth it!).

Who is it for?

I've built PyHost for absolutely anyone who uses Django (and maybe Flask too in the future - but that's a whole different blog post). It makes deploying your very first Django application a breeze but also saves more experienced developers time by taking care of the boring stuff so they can spend more time on what they want to be doing - building.

How can I use it?

To use it, head to pyhost.io and click on 'Sign up now!'. The docs are located at docs.pyhost.io and should contain most information you need to get going! I'm also happy to answer any questions either here in the comments, or via email at admin@pyhost.io

Leave any comments below, I can't wait to hear what people think!

So what actually is Nginx? (Linux Sys-Admin for web devs)

Angus Allman — Fri, 07 Feb 2020 17:46:01 +0000

We've all been there

Getting to the point of having a site looking beautiful and polished with only one problem... no one can actually see it yet. This is where the whole painful deployment process kicks off. A search for "How to deploy a your stack site" will return a slew of options but some things seem to crop up time and time again no matter what tech you're using. Nginx

What is it?

The official word (from the Nginx site) is:

NGINX is open-source software for web serving, reverse proxying, caching, load balancing, media streaming, and more.

Put simply, it's the thing that handles communication between the web server and your site. Whether that be reading the domain that's been requested by the user and handling it by pointing the request to the correct files, or sending it elsewhere (reverse proxy).

When you access a website, say ilovenginx.com, it always sends a request to a server somewhere in the world (for more info on how this works read about DNS). Now that the request's reached the server it needs to know what to do with it and that's where Nginx comes in. Using it you can create config files that contain instructions for what to do when a request to ilovenginx.com arrives at the server.

Hit the ground running

Nginx creates a load of files in the /etc/nginx directory as soon as it's installed. This is where you want to create your config files because without them Nginx is useless and won't do a thing.

Inside /etc/nginx and you'll see a myriad of files and folders but the ones we want are sites-enabled, and sites-available.

sites-available is where we create and edit our Nginx config files and sites-enabled contains symbolic links (symlinks) to our config files in sites-available. The point of this is that you can have as many config files as you want available to use but only actually have the important ones which your site(s) use enabled.

The config files

If you head into the directory /etc/nginx/sites-available there will be a file named 000-default.conf. If you want you can open that up and take a look at the base config file template.

I'm fairly sure that these config files look bewildering to even the most experienced developers and I'll be creating a line-by-line breakdown of one of these files in another blog post (coming soon) but let's not get bogged down in the details here. Fundamentally, these files are a list of instructions that tell Nginx what to do with requests that arrive depending on which domain they're for and what port they arrive at (usually port 80 for HTTP requests, or port 443 for HTTPS).

A brief rundown

As with all systems like this, there is a great deal which I could discuss here and an endless list of varying commands which do plenty of different, unique things, however below, I’ve listed a few of the most important lines from a config file with a brief explanation of what they do.

server {} - Creates a new Nginx server to handle requests (all Nginx commands should be within a server block)

listen - Defines which port the this server should handle requests from.

root - Points to the directory which your site is stored in. The path will usually contain /var/www if you use Nginx's defaults.

index - Tells Nginx a list of files in the root directory to use to run the site. You can use space-separated file names in the order which they should be tried

server_name - Defines the domain name that you want this server block to handle requests for. You can list multiple domains here e.g:

server_name example.com www.example.com;

Conclusion

That just about does it for the basics of Nginx! While it can seem complicated and like something that only advanced devs know there’s no need for it to stay that way. What it does under the hood is all kinds of magic but at its core it’s an elegant way to tell your server how to handle requests, get your site live and show it to the world. As I mentioned there will be another post coming soon which will be a deep dive into a real Nginx config file and how it does its wizardry line-by-line. If there is anything you feel could be added to this post or you have any questions then leave them in the comments below!

Sys-Admin for Web Devs (Intro to DNS)

Angus Allman — Wed, 23 Oct 2019 18:56:50 +0000

I’ve bought a domain and built a site… now what?

At some point in the process of building and deploying a site, you’ll need to dig into the dark confusing world that is DNS. DNS stands for Domain Name System (you'll usually find it in the settings of a domain which you own, possibly under Advanced DNS) and handles the translation of a URL that you type into the browser to an IP address that the computer can visit in order to load a website.

There are several different types of DNS records that you’ll more than likely encounter throughout your site deployment journey. DNS can handle translation, redirection, email and a whole host of other things but for now, I’ll just cover the most commonly used ones.

Anatomy of a DNS Record

DNS Records are made up of 3 main parts: type, host, and value. Type will be the name of the record and there may be a dropdown to choose it from, both host and type should be strings made up of letters, numbers, and punctuation. You may sometimes see an '@' symbol in the host field. This means that the host is set to the domain on which you’re editing the DNS. For example, if you see an A Record which looks like the following... (Screenshots come from Namecheap)

...then it’s pointing the domain you’re editing to the IP address in the value section of the record. You’ll also see that there’s a TTL field. This stands for Time to Live and acts as a sort of expiration date for the record and “dictates how long the record will be cached by resolving nameservers, browsers, etc.” ( dnsmadeeasy.com )

A Records

These are the simplest record which I’ve already kind of explained but I'll run over it again with a bit more detail.
Firstly, the 'A' stands for 'address' and according to DNSimple

An A record is used to find the IP address of a computer connected to the internet from a name.

When someone goes to a web address, the A record acts as a signpost and points the request to the IP address which is in the value of the record. To create a new A record you need to choose 'A' as the type from the dropdown and define either '@' or the subdomain name you wish you point to an IP in the host and then the IP in question in the value field. For example, if you have a site called myblog.com and you want a subdomain which you use for development called dev.myblog.com then you can use an A record to define it by putting "dev" into the host field and adding the IP of the server where your code is into the value field.

CNAME

CNAME (Canonical Name) records can be used to alias one name to another. A CNAME record has to point to another domain and should never point to an IP address. If you take domain.com and www.domain.com as examples then, domain.com would have an A record that points it to an IP whereas www.domain.com would have a CNAME record with the value domain.com or '@' (remember this symbol points to the domain that you are currently working with).

TXT Records

TXT Records are more or less just a way to store extra data in the DNS or a domain. They allow a kind of key/value store at the domain level and are useful when using your domain with 3rd party services. Online services like Mailgun (a great tool for email management) or Firebase(great for serverless app development and data storage) may ask you to add these records to your DNS to make sure that you own the domain. This way they can query the DNS and look for the TXT record that they're after.

MX Records

MX (mail exchange) records are used to tell email delivery agents where to deliver emails to. In other words, these are what you need to configure in order to be able to use a domain in an email address.
Systems like Mailgun, Google and other email providers talk you through the process of configuring these when you set up a new email domain.
You can supply multiple different MX records, as you can with all DNS records, but the difference here is that you can specify a priority level. The priority level means that if the MX record with the highest priority fails to send the email, then it will try the record with the next highest priority and so on. If all of them fail then the email doesn’t send.

Conclusion

That just about does it for a quick intro to DNS and the most commonly used records. There's plenty more that can be said about DNS (most of which I don't even know yet) but at the very least I hope you've come away from this knowing more than you did when you started reading. If there are any questions or you just want to say 'hi' then leave a comment below! If you're interested in more of this content then let me know and give me a follow on twitter @allmanajD.

Sys-Admin for Web Devs (File Permissions)

Angus Allman — Tue, 23 Apr 2019 17:48:12 +0000

Sysadmin can be a tough nut to crack

It's something that we all come across at one point or another so I thought why not try to de-mystify the basics a little bit.

Fundamentals

When it comes down to it, all files and directories on a server have a few things in common:

They belong to a user
They belong to a group
They have access permissions

There are 3 types of permission which a user can have for a file/directory.

Read - The file can be read
Write - The file can be written to
Execute - The user can execute the file

There are also 3 different groups of users in terms of their relationship to the file.

The owner of the file
The group of users who can access the file
The rest of the world

What this actually means

Typing ls -la in almost any directory will show you all of this information. It will look something like this:

-rwxrwx--- 2 admin dev-team 4096 Apr 23 06:22 file-for-my-group
drwx------ 2 admin admin    4096 Apr 23 06:21 my-private-files
drwxrwxr-x 2 admin admin    4096 Apr 23 06:21 public-files

I've set up this example to show file/directory permissions and users/groups.

That long sequence of letters breaks down the permissions which each user has for (in this case) that directory.

This breaks down into 4 groups of file permissions. As an example, let's take a look at the permissions of the public-files directory and break it down:

drwxrwxr-x

d shows that the file is a directory (a normal file will just have a dash in this first spot)
The following 3 letters (rwx) shows that the user who owns the file can read from, write to, and execute the file
The second set of 3 letters (again rwx) shows that all users in the same group as the file can read from, write to, and execute the file
The final 3 characters (r-x) shows that all other users (those who aren't the owner or in the group) can only read from and execute that file.

In short, it looks like:

Changing Permissions

Now that we know how the server knows what we can and can't access, let's look at changing it.

Remember the example from before?

-rwxrwx--- 2 admin dev-team 4096 Apr 23 06:22 file-for-my-group
drwx------ 2 admin admin    4096 Apr 23 06:21 my-private-files
drwxrwxr-x 2 admin admin    4096 Apr 23 06:21 public-files

Let's say that I now want anyone who's not in the correct group to access the file-for-my-group document. At the moment, you can see that people outside of the group cannot read, write, or execute this file, but I now want to allow anyone to be able to read it.

I would use the chmod command to do this. This command takes several arguments which looks as follows:

chmod [options] [permission] [file to change]

By permission I mean a sequence of 3 numbers which denotes the access levels and the information that we've been through above. We make this code by assigning each of the different permissions (read, write and execute) a number

read - 4
write - 2
execute - 1

If I want to read, write and execute the file, the number used will be7
(4 + 2 + 1). If I only want to allow reading and execution, the number will be 5 (4 + 1) and, logically, if I don't want to allow any of the above the number will be 0.

Knowing this, we can now assemble the three numbers we need in order to denote these new permissions. If I want the owner to have full access (7), the group to have full access (7) and the rest of the world to only have read access (4) then the number will be 774.

To use this in the case of the chmod command it will look like this:

chmod 774 file-for-my-group

Conclusion

And there we have it! A brief rundown of how server permissions work on Linux systems. There is much more depth to go into (security risks, making entire directories inaccessible, and changing the permissions of an entire directory of files etc.) but this was just meant to be an introduction to get you up and running with Linux and how its files work. Any questions or comments at all leave them down below!

How to Deploy a Django Site in 2022

Angus Allman — Mon, 22 Sep 0003 00:00:00 +0000

It’s a confusing place out there. You’ve built a great site with Django and the next step is getting it in front of people… but where to start?

A quick google of “Deploy Django Site” shows a whole host of responses and so today I’m going to try and break down the main ones and my personal favourite.

Heroku

Firstly, there’s one of the biggest names in the deployment space: Heroku.
Heroku offers hosting solutions on their servers and is mostly managed through the terminal. They are tried and tested industry-level hosting perfect for professionals.

Heroku offers free plans as well as a very flexible pricing model allowing the user to pay for only what is used.

While this is an elegant solution for some, it’s daunting for people who haven’t got much exposure to the command line and tutorials online can be unclear, in my experience.

Digitalocean Marketplace

Up next is DigitalOcean. DigitalOcean offers a solution in their Marketplace which creates a new “Django Droplet” for you in their system, allowing you to upload your site to their containers, configure it and deploy.
This is a great solution for those who are comfortable with the command line and managing linux systems but, let’s be honest, it’s no mean feat to learn all you need to know about managing linux servers through the terminal.
This solution is also a one-time thing. It spins up the droplet for you and that’s it. Any further systems administration which is needed is done manually which can be time-consuming and confusing (I’ve been there).

The cost for the droplet is no more than a regular DigitalOcean droplet with all the same options, however, it’s worth noting that these "Django Droplets" can only be spun up in the San Francisco data center which may not be ideal for some users in other parts of the world.

PyHost

PyHost offers a comprehensive system for deployment and system management.

The system allows users to create a server on DigitalOcean in any of their available data centers. It’s also possible to manually connect a VPS from another provider as long as it’s the correct OS and version (Debian 11). PyHost dynamically generates and runs scripts on your server, in addition to server setup like DigitalOcean provides, it also allows deploying of individual sites from Github, Bitbucket and Gitlab. If you don’t want to you’ll never have to access your server’s command line to get a simple site up and running. You are able to create new databases and manage users, get 1-click SSLs for your sites and configure environment variables through the system’s UI. Extensive documentation is available here and will guide you through the whole process.

You host the site yourself, maintaining all the power while never needing to bother with the terminal ( although that option is available, should you want it). Win/win!

PyHost boasts a free plan which allows deployment of one site with an auto-generated subdomain, as well as paid plans with more flexibility and power.

Conclusions

In summary, there are lots of options available to the modern Django developer in 2022. Deployment is a confusing and often intimidating process that isn’t helped by the amount of choice on offer.

If you are comfortable with the terminal and want something that does a few things well, then Heroku and DigitalOcean are your best bets. However, if you want to spend as little time worrying about systems administration as possible then PyHost is the one you want. I truly believe that PyHost takes the weight off the developer and allows them to focus on what matters to them, the code. So get out there and build amazing apps and don’t sweat about hosting anymore because PyHost’s got your back