Setting up a Raspberry Pi with Ubuntu

https://medium.com/a-swift-misadventure/how-to-setup-your-raspberry-pi-2-3-with-ubuntu-16-04-without-cables-headlessly-9e3eaad32c01

Step 1: Preparation

Get your Raspberry Pi 2 or 3, an SD memory card with 8Gb or more memory (class 10 or more), a micro USB cable (for power), an ethernet cable and the Wifi USB dongle.

Step 2: Flashing Ubuntu 16.04 server minimal on the SD card

Download Ubuntu server minimal from here. This is a flavour of Ubuntu server, which have been stripped out of everything which is not strictly necessary, so it’s very light.

Now you have to flash the image on the SD card. On the web you will find a lot of multi step command line guides. But that’s nuts, since there’s a great apps, called Etcher.io, that make the process incredibly simple, fast and safe.

Download Etcher app (for all platform), then select the Ubuntu image, the SD card (which you have to insert in your computer) and flash it. Few minutes and it will be done and verified.

Put the SD card into the RPi, you’re ready to rock!

Step 3: Ssh-ing into your RPi

After you’ve inserted the freshly backed SD card into your RPi connect the ethernet cable between the RPi and your router. Turn the RPi on by connecting the micro USB cable to the electricity or to your computer.

Wait few minutes, since the first boot takes longer than usual. Then open your router’s dashboard and look at the ethernet connected devices. You will see a device hostname ubuntu-minimal. Take a note of the IP of that device.

Open your terminal and type:

You should be in!

You are now connected to the RPi via the network. The only problem is that you still need to keep the RPi connected to the network throughout the ethernet cable. But let’s address that.

Step 4: Going wireless

First we need to update the operating system:

Install the wifi support:

Now reboot. It’s important to do it now, since my wireless interface changed name after this step. From a nice “wlan0” to a weird “wlx000f6005a699”.

Attach the USB dongle to your RPi. Then, ssh again into it. Then, list the wireless network interfaces with:

Take note of the wireless interface name (e.g. wlan0 or wlx000f6005a699).

Open the network interfaces configuration:

At the bottom of the file add (replacing the wlan0 with the name of your interface):

Now, open the wireless configuration file:

and add at the end of the file the informations about your wifi network:

Save and exit the editor. Remove the ethernet cable and then reboot:

Now in about 30 seconds your RPi should be up an running. If you try again to ssh into the RPi (still looking for its IP in the router dashboard), you should just be able to connect to it via wifi!!

Step 5: Ssh-ing into the RPi with a dynamic IP

As you’ve already noticed, checking the the RPi’s IP every time you want to connect to it, it’s a bit of a pain in the ass.

So, let’s install avahi which will make you able to connect to the RPi via its hostname.

Now, after a reboot, you will be able to ssh into the machine:

Step 6: Securing the ssh authentication

I suggest you to secure your login with a rsa key authentication and enabling it only the port 22.

From your Mac laptop:

Now you should be able to ssh into RPi without password:

The-wise-guy-last-step: Backup your RPi

It’s very easy to burn an SD card by writing to it too many times. Or irreversibly fuckup your configuration by doing what sudoer should not do. Cloning your SD card, as an image that you can flash on a new card when you need it, is the perfect backup strategy. Here you find how.

You are now ready to install Swift 3.0 developer preview on your sexy Raspberry Pi Ubuntu box.

Injecting twig template names into html source on develop environment

After working on a few big projects, or jumping into existing big projects one trick that helps people get up to speed quickly is highlighting which template has been used at which point in the views. With the Twig tpl system that is reasonably simple:

Assuming a custom php project you can control most from a single render function.

Now you need you twig debug template

 

In the render function you can see I also include some custom twig functions, these come from a file like this:

 

Sort a multi dimensional array

Function to sort php multi-dimensional arrays

eg

Laravel and the lighter sibling

 

Symfony has it’s lightweight sibling, and they called it Silex.

Under the hood of Laravel is Symfony, yet Laravel somehow managed to make a light weight version of the Laravel stack that runs faster that Silex… they called it Lumen:

https://lumen.laravel.com

And as with the Laravel framework it has some beautiful documentation to go with it… Nice work Taylor Otwell!

(Laravel has got to be one of the few if not only frameworks out there that really just works. On top of that, I rarely find the need to stray away from the official documentation either. Why can’t all frameworks be like that! It cannot be that hard can it?)

Nice article on VueJS and server side rendering

Server-side rendering is all the rage right now. But it’s not without its downsides. Pre-rendering is an alternative approach that may even be better in some circumstances.

In this article we’ll explore how pre-rendering works with Vue.js and look at two examples; one with a Node.js project, one with a Laravel project.

Server-side rendering

One of the downsides to Javascript-based apps is that the browser receives an essentially empty page from the server. The DOM cannot be built until the Javascript has been downloaded and run.

This means that the user has to wait a bit longer to see anything. It can also have an impact on SEO if crawlers can’t see content of the page quickly.

Server-side rendering (SSR) overcomes this issue by rendering the app on the server so that the client receives the complete DOM content when the page is loaded, before Javascript is even run.

So instead of the browser receiving this from the server:


With SSR it receives a page with complete content:

Server-side rendering cons

  • Your app will need to be executable on the server, so you’ll need to design your code to be “universal” i.e. it works in both the browser and a Node server.
  • Your app will run on each request to the server, adding aditional load and slowing responses. Caching can partially alleviate this.
  • You can only do SSR with Node.js. If your primary backend is Laravel, Django etc you’ll have to run a Node server alongside the main backend to take care of SSR.

… Head over to this link for the rest of the article:

http://vuejsdevelopers.com/2017/04/01/vue-js-prerendering-node-laravel/