Raspberry Pi WIFI bridged access point

I usually rely on a wired ethernet connection in my home office, enabled by a powerline adapter running through the mains wiring to the house, where the other end connects to one of the ethernet sockets on an Airport. Yesterday I took delivery of a shiny new Macbook Pro and was reminded that they now only have Thunderbolt 3 sockets, making my Thunderbolt to ethernet adapter redundant. Thanks a lot Apple, that’s another expensive white adapter to add to my box of random useless adapters, and another one or two to buy (I still need a USB port for a couple of things, and displayport/ HDMI for an external monitor or two).

Luckily I had a spare Raspberry Pi 3 B+ lying around, and after a couple of false starts, I now have a bridged wireless access point in the home office, bridging the wired ethernet connection from the powerline adapter. Bridged works best for me so that I still get an IP address assigned via DHCP from the Airport, in the same IP range – it just keeps things simple. I’ve given the PI access point a unique SSID rather than mirror the one used in the house because sometimes it’s useful to know which one you’re connected to.

Installing and configuring the software

This is the how-to I followed: Setting up a Raspberry Pi as a bridged wireless access point. I’m not going to repeat all the steps here, but for what it’s worth, one of my false starts was the result of this part:-

To use the 5 GHz band, you can change the operations mode from hw_mode=g to hw_mode=a.

Apparently this works for Raspberry Pi Model 3B+ onwards, but it just didn’t work for me – the access point didn’t show up. After changing it back to the default “g” it works fine. The powerline adapters (and the mains wiring they use) already limit the speed of the connection a fair amount, so i’m not too bothered about this.

The other false start was following a completely different how-to, which only resulted in locking myself out of the pi via ssh and creating an access point which didn’t provide internet access!

Freerange Freelance (aka Camper Van Things) integrated into this blog

Back in 2010 I started writing about “Remote Working”, initially on this blog, then split off into a separate “Rick on the Road” blog, written using my own (now abandoned) database-less blog software, which I called “eatStatic”. I even did a talk on this subject at the Anywhere Working event in 2013, talking about a summer spent freelance working from France, while touring France with my family in a vw beetle. A few years later, the blog morphed into “Camper Van Things” where the focus became more about the vehicle used for my nomadic working aspirations, than the work itself. Then I rebranded it as “Freerange Freelance”, to bring the focus back onto the remote working lifestyle. Just like this blog, each iteration eventually got a bit neglected, until some time last year, I mothballed it.

Seeing as I had already written some migration scripts to migrate content from my static blog engine to WordPress, it didn’t take much to adapt the script to pull content from the wordpress API and merge it with content from this blog. You can find all that content under the category “on the road“. I should probably take all of this as a warning about buying new domain names on a whim, and creating niche blogs!

 

My current tools and tech in 2019

I try to avoid jumping on every new trend which comes along in the web world, especially over the last few years, where things seem to have moved very fast, with javascript frameworks becoming obsolete before i’ve even got round to trying them, but I also need to keep my skills and tech relevant. Here’s what i’m using as of late summer 2019.

Editor/IDE

I’ve been consistently using Sublime Text (Version 2 because I never got round to upgrading to 3) for years as my code editor, though i’ve never really taken full advantage of the extensions and customisations available. It just works and I saw no real need to change. One thing it has never done well is working over ssh, or rather from a mounted sshfs folder on a mac. I have occasional need to do this, when using the likes of nano in a terminal doesn’t feel good enough, and it’s one thing that I missed from Coda, when I used that for a while, years ago.

Then after spotting a tweet from an old colleague mentioning remote SSH editing in VS Code (via the Remote – SSH extension), I thought i’d take a look at it. Firstly, having used old-skool Microsoft Visual Studio in the past, I was surprised to see that Microsoft had built and released such a cool free editor, with builds for windows, mac and even linux. It’s already become my default editor – the intellisense and built-in terminal and git functionality is really good. There’s a lot there to explore and a ton of extensions. It also looks good.

Languages and frameworks

Most of my work is currently PHP. I no longer feel the need to apologise for that! PHP 7 is mature, stable and fast. I work on a couple of legacy PHP projects, one of which uses a combination of bespoke MVC code, an old fork of codeigniter (currently being refactored out) and Redbean ORM, and the other uses Zend framework, but is being re-built as a de-coupled app with Lumen (micro-framework by Laravel) on the back end and Vue.js on the front-end.

I haven’t done any web projects with Python recently (though i’m keen to try Pyramid), but I have been using it for a custom FTP server, using pyftpdlib (yes, FTP – for an old-skool EDI project – an old, but still very widely used technology where XML and FTP are used to exchange data – probably predating the invention of JSON and REST). I’ve also been using python for a raspberry pi datalogger project, reading serial data from microcontrollers via USB and then relaying it to a REST API.

JavaScript-wise, I still use bits and pieces of  jQuery to get stuff done while I learn Vue.js properly, which is happening as part of a current aforementioned web app rebuild. We settled on Vue.js instead of React because Vue seems to be a popular component in the Lumen/Laravel ecosystem.

For CSS, i’ve settled for now on SASS and Gulp. Sass is a keeper, i’m just using Gulp until I find something that I like better. I tend to use Susy for grid/layout.

Ansible is my go-to tool for devops – I use it to provision web servers and for formerly manual tasks such as migrations of websites, moving content between dev, live and staging on wordpress sites etc. For local development of any sort I almost always use Vagrant now, with an ansible provisioning script, which gives me a very portable set-up, provided I have enough RAM to keep multiple virtual machines running as I juggle projects.

During my last foray back into a day-job (back in 2016), working at an agency, I got a fair amount of experience using wordpress as a CMS, including for some fairly complex projects, relying heavily on the Advanced Custom Fields (ACF) plugin. Now, historically I haven’t always been a fan of WordPress, but it proved to be an excellent tool when used with ACF, making the creation of custom page types incredibly quick and easy compared to other Content Management Systems i’ve used, and even compared to using frameworks which would be my usual preference for custom content. Being able to create custom fields, included nested repeater fields via the WordPress admin, having the field definition saved to the filesystem and then versioned in GIT for seamless syncing to production is a game changer!

 

What is a Full Stack web developer?

TL;DR It’s just a convenient term to describe a web developer who does both front and back-end, and maybe some other things .

I label myself as a Freelance Full-stack Web Developer (or Fullstack, for those who like to join two words together into non-existent ones) , but what does that actually mean?

Web developers who write HTML, CSS and (maybe) JavaScript, but don’t do any server-side code (e.g. PHP, Python, Rails etc.) might call themselves “Front-end” developers. Web developers who only do server-side code, and never do any HTML, CSS or (browser-based) JavaScript might refer to themselves as “Back-end” developers.

Therefore someone (like me) who does both Front-end and Back-end code might refer to themselves as a Full-Stack developer.

But there’s usually more to getting a website or web app built and up on the internet than just writing code.

There’s (sometimes) provisioning servers, installing web server software, installing database software and other dependencies. There’s setting up development, staging and live versions of websites, setting up domain records for websites and mail servers and installing SSL certificates. That might be the job of a sysadmin and/or DevOps specialist, but some web developers might take on that part of the job, either by choice or by necessity.

Most web apps need a database, and this database might need designing, optimising and maintaining. That’s a job for a DBA if you are lucky to have one, but i’ve only worked for one company who had a dedicated DBA, so that job usually also falls to a developer.

There’s often plenty more roles that make up the stack – testers, technical project managers, UX, Designers, and in some companies there will be dedicated individuals or teams for all of these roles, but for a small agency or freelancer, often these are taken on by a full-stack web developer.

Now just like Front-end and Back-end are made-up terms, so is Full-Stack. For me it’s just a convenient way of saying that i’m not just a front-end developer, or not just a back-end developer, I do both, and some other things.

Jack of all trades, master of none?

Hey! I resemble that remark! Actually I prefer to say “Jack of all trades, master of some“. I’d like to get better at all of the various roles that make up my workload, but people dedicated to a particular role exclusively will inevitably master skills in that area that I probably won’t.

But there’s more parts to the stack, can you do all those too?

A heated discussion on a local web dev forum had people extrapolating “the stack” to include hardware and low-level operating system code (and maybe beyond?) at one end. I neither do that stuff, or consider it as part of the web-development stack.

At the other end people were adding in any role that could possibly related to the development of a website or web app – account handlers, financial directors, accountants, HR, office manager. Although as a freelancer I have to take on some of those roles myself, I don’t consider them to be part of the web-development stack!

Deploying and maintaining a website using git

I’ve kind of used git to deploy/ manage php/ static websites for a while now, but in a very luddite way – basically sshing into the webserver, cloning a repo into my site root directory, then hiding the .git folder in the Apache config.

After recently starting a new job and inheriting some web sites and web apps and starting to take the whole “devops” thing more seriously, I was pleased to see a better technique in place than the one i’ve been using.

The basic premise is this – a repo is set up on the web server as a remote outside of the web root, but configured so that the checkout working directory is another directory. The advantage of this is that there is no need to ssh into the webserver to update the code, as a post-update hook can be used to checkout the updated files.

In addition to this, we usually use tools such as gulp to process scss and minify and js, so the post-update hook can also be used to process these on the server after checkout.

Going into more detail, here is the config of the remote git repo on the webserver, this could be somewhere like /var/sites/mysite_git

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
worktree = /var/sites/mysite
[receive]
denycurrentbranch = ignore

and in hooks/post-update on the remote, something like:-

git checkout -f
cd /var/sites/mysite
gulp build