Tags: tutorial

44

sparkline

Sunday, July 2nd, 2017

Starting a React-Powered Comment Form | CSS-Tricks

This is a really great screencast on getting started with React. I think it works well for a few reasons:

  • Sarah and Chris aren’t necessarily experts yet in React—that’s good; it means they know from experience what “gotchas” people will encounter.
  • They use a practical use-case (a comment form) that’s suited to the technology.
  • By doing it all in CodePen, they avoid the disheartening slog of installation and build tools—compare it to this introduction to React.
  • They make mistakes. There’s so much to be learned from people sharing “Oh, I thought it would work like that, but it actually works like this.”

There’s a little bit of “here’s one I prepared earlier” but, on the whole, it’s a great step-by-step approach, and one I’ll be returning to if and when I dip my toes into React.

Tuesday, April 18th, 2017

Progressive Web Apps - ILT  |  Web  |  Google Developers

A step-by-step guide to building progressive web apps. It covers promises, service workers, fetch, and cache, but seeing as it’s from Google, it also pushes the app-shell model.

This is a handy resource but I strongly disagree with some of the advice in the section on architectures (the same bit that gets all swoonsome for app shells):

Start by forgetting everything you know about conventional web design, and instead imagine designing a native app.

Avoid overly “web-like” design.

What a horribly limiting vision for the web! After all that talk about being progressive and responsive, we’re told to pretend we’re imitating native apps on one device type.

What’s really disgusting is the way that the Chrome team are withholding the “add to home screen” prompt from anyone who dares to make progressive web apps that are actually, y’know …webby.

Tuesday, March 14th, 2017

terminal & command line video training

An online training course that will banish all fear of the command line, expertly delivered by the one and only Remy Sharp.

For designers, new developers, UX, UI, product owners and anyone who’s been asked to “just open the terminal”.

Take advantage of the special launch price—there are some serious price reductions there.

Friday, March 10th, 2017

153 ☞ A Crash Course in React

This is a nice understandable explanation of the basics of React.

There’s a real skill in explaining something so clearly that even n00bs like me can understand it.

Wednesday, February 15th, 2017

CSS Beating Heart Tutorial. – Cassie Codes

A sweet CSS tutorial that Cassie put together for the Valentine’s Day Codebar.

Sunday, February 12th, 2017

Interneting Is Hard | Web Development Tutorials For Complete Beginners

A nice straightforward introduction to web development for anyone starting from scratch.

Saturday, August 6th, 2016

React Isomorphic Demo

It is possible to use React without relying completely on client-side JavaScript to render all your content—though it’s certainly not the default way most tutorials teach React. This ongoing tutorial aims to redress that imbalance.

Besides the main benefit of server rendering giving faster page loads, it also enables large amounts of the site to run without JavaScript. There are many reasons why you would want this, but my personal reasons are that it allows you to completely drop support JavaScript in older browsers, but still have the site function.

Thursday, July 28th, 2016

Web Design in 4 minutes

This is a wonderful way of progressively explaining the layered approach to building for the web that Charlotte was teaching in her Codebar workshop.

Wednesday, June 29th, 2016

MarkSheet: a free HTML and CSS tutorial - Free tutorial to learn HTML and CSS

This looks like a great resource for beginners looking to learn HTML and CSS.

Monday, June 6th, 2016

Intro to Flexbox

The slides from Arelia’s flexbox talk.

Saturday, December 5th, 2015

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

  • The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.

YES!!!

Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Thursday, April 16th, 2015

100 words 025

I often get asked what resources I’d recommend for someone totally new to making websites. There are surprisingly few tutorials out there aimed at the complete beginner. There’s Jon Duckett’s excellent—and beautiful—book. There’s the Codebar curriculum (which I keep meaning to edit and update; it’s all on Github).

Now there’s a new resource by Damian Wielgosik called How to Code in HTML5 and CSS3. Personally, I would drop the “5” and the “3”, but that’s a minor quibble; this is a great book. It manages to introduce concepts in a logical, understandable way.

And it’s free.

Monday, March 2nd, 2015

Harnessing Flexbox For Today’s Web Apps - Smashing Magazine

More flexbox!

This time it’s a great article by Karen Menezes filled with practical examples showing where you can use flexbox today.

flexbox in 5 minutes

A really handy interactive intro to flexbox. Playing around with the properties and immediately seeing the result is a real help.

Friday, September 12th, 2014

Switching to https

A step-by-step guide to enabling TLS on Apache.

As promised at Indie Web Camp, here are the steps I took to make my site https:// only.

Now, here’s the thing with any of these walkthroughs; they’re all very specific to host/server combo in question. My particular combination is:

  1. Hosting on a Digital Ocean virtual machine running Ubuntu 14.04 (typing lsb_release -a on the server will tell you which version of Ubuntu you’re running).
  2. Running Apache 2.4.7 (typing apache2 -v will tell you which version of Apache is running).

If you’re using another flavour of Linux, or running Nginx, this walkthrough will probably not help you. You’ll also need admin access to the server. If you’re on shared hosting, you may well be screwed from the get-go.

To start with, you need to get your magic certificates from a Certificate Authority. So the first question is: who is a good Certificate Authority?

Choose a Certificate Authority

There is no such thing as a good Certificate Authority.

It’s a racket.

The best you can hope for is to deal with a Certificate Authority that doesn’t charge too much and doesn’t make the process as painful as applying a power drill to your teeth.

My pain was mitigated by my DNS provider, DNSimple. They have a one-clickish process for applying for a certificate. They charge $20 a year for a single hostname, which is not too bad. If that’s still too rich for your blood, you can look into navigating the interface at StartSSL. Good luck with that.

Until last week, DNSimple were using RapidSSL to issue those single-hostname certificates. RapidSSL still issues SHA-1 certificates by default, which is not good. But after a little prompting, DNSimple switched to Comodo for their single-hostname certificates, which means you can get yummy SHA256 encryption.

Make a private key and CSR

DNSimple can even take care of generating a private key and a Certificate Signing Request (the two chunks of encrypted gibberish you need to send to the Certificate Authority to get your certificate). Otherwise you’ll need to generate those for yourself. To do that, ssh into your server and run this, swapping out yourdomain_com for, you guessed it, your domain:

openssl req -new -newkey rsa:2048 -nodes -keyout /etc/ssl/private/yourdomain_com.key -out /etc/ssl/certs/yourdomain_com.csr

..and answer the probing questions that your nosy server will ask of you. You’ll then have two files:

/etc/ssl/private/yourdomain_com.key
/etc/ssl/certs/yourdomain_com.csr

You can then copy and paste the contents of those files when you’re applying for a certificate from your CA of choice. I can’t walk you through that process because, like I said, I managed to skip over it completely by having DNSimple do all the work.

I still had to put the private key on my server so I created the file:

nano /etc/ssl/private/yourdomain_com.key

And then I pasted the private key in there, hit ctrl o and then hit enter to write out the file, followed by ctrl x to close it.

(If some of these command line things don’t work for you, try prefixing them with sudo, try again, and enter your password when prompted.)

See how this is getting more and more specific to my particular combination? Now I’m talking about installing a Comodo certificate (acquired through DNSimple) on Apache 2.4 on Ubuntu 14. If you’re using a Certificate Authority other than Comodo, the next step won’t mean much to you.

Install your certificate on your server

There’s some documentation on the Comodo site for this step. At this point, you should have received a zip file from Comodo with four files:

  1. AddTrustExternalCARoot.crt
  2. COMODORSAAddTrustCA.crt
  3. COMODORSADomainValidationSecureServerCA.crt
  4. yourdomain_com.crt

Open a text editor on your computer and create a new file by copying and pasting the contents of these files in this order:

  1. COMODORSADomainValidationSecureServerCA.crt followed by
  2. COMODORSAAddTrustCA.crt follwed by
  3. AddTrustExternalCARoot.crt

On your server, create a new file by typing:

nano /etc/ssl/certs/yourdomain_com.ca-bundle

Paste in the combined contents of the text file from your computer. Hit ctrl o (followed by enter) to write out the file and ctrl x to close it.

That leaves one file, which is your actual certificate, yourdomain_com.crt

On your server, type:

nano /etc/ssl/certs/yourdomain_com.crt

Copy and paste the contents from the certificate file (yourdomain_com.crt) in there. Hit ctrl o to write out the file and ctrl x to close it.

Set up https on Apache

Remember, this is for Apache 2.4. Things will be subtly different on previous versions. For instance, on Apache 2.4, all the files in /etc/apache2/sites-available must end with .conf; that wasn’t the case with previous versions.

First things first. You need to enable the ssl module for Apache. On your server, type:

a2enmod ssl

(Again, if that doesn’t work straight away, try prefixing it with sudo.)

Now restart Apache:

service apache2 restart

Your Apache server is now capable of serving over https, but you still need to give it more details.

Go into the sites-available directory by typing:

cd /etc/apache2/sites-available

You can see all the files in this folder by typing ls. I’m going to assume that you’ve got the server serving up just one site and that the details of that site are in the 000-default.conf file which serves up your site over port 80. You’ll want to copy any details you have set up in 000-default.conf over to default-ssl, but with the difference that the port number is 443. The top of your default-ssl file should look something like this:

<IfModule mod_ssl.c>
    <VirtualHost *:443>
            ServerAdmin you@yourdomain.com
            ServerName yourdomain.com
            ServerAlias www.yourdomain.com
            DocumentRoot /var/www

It might be that your DocumentRoot is /var/www/html. That’s fine (as long as that’s where your website’s files are actually sitting).

Oh, I should have mentioned: the way that you can examine (and edit) that default-ssl.conf is by typing:

nano /etc/apache2/sites-available/default-ssl.conf

Comment out these two lines by placing a # at the start of each line:

#SSLCertificateFile     /etc/ssl/certs/ssl-cert-snakeoil.pem
#SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Right under those lines, add these:

SSLCertificateFile    /etc/ssl/certs/yourdomain_com.crt
SSLCertificateKeyFile /etc/ssl/private/yourdomain_com.key

Now you’re pointing at your hard-earned certificate and your private key. You still need to point to that bundle file you created earlier.

Comment out this line by putting # at the start of it:

#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

Right underneath it type:

SSLCertificateChainFile /etc/ssl/certs/yourdomain_com.ca-bundle

Now page down to near the end of the file by hitting ctrl v. Right before the closing /VirtualHost tag, add these lines:

SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression off
SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'

That line beginning with SSLCipherSuite needs to be all one line so watch out for line breaks if you’re copying and pasting. It’s quite an impressive bit of unintelligible gibberish, isn’t it?

Write out the default-ssl.conf file by hitting ctrl o, followed by enter, and exit this hellish text editor by hitting ctrl x.

Type this (you might need to sudo it):

a2ensite default-ssl.conf

Do the Apache restart dance by typing:

service apache2 reload

You might see a message like “Could not reliably determine the server’s fully qualified domain name…” Don’t worry about it. If, on the other hand, you see an error message that Apache can’t restart, worry about it.

Open your website in a browser; http://yourdomain.com — you should see no difference whatsoever. But now type https://yourdomain.com (but, y’know, swapping out yourdomain.com for your domain). Again, everything should look exactly the same but with one crucial difference: a shiny green lock in the corner of the URL bar indicating that the site is secure.

Redirect http to https

Once you’re happy with the way the https version of your site is working, you can make it the default.

Before doing this, it’s worth making sure that you haven’t hardcoded any images, scripts, or other external files with http:// URLs. If you’re pointing to third-party resources, most of them should also be available over https. Don’t forget that you can use protocol-relative URLS: //fontdeck.com/etc instead of http://fontdeck.com/etc or https://fontdeck.com/etc.

To switch http requests for your site over to https, you’ll need to edit the file that has your port 80 details. That’s probably 000-default.conf in /etc/apache2/sites-available.

Open up that file:

nano /etc/apache2/sites-available/000-default.conf

The top of the file should look something like this:

<VirtualHost *:80>
    ServerAdmin you@yourdomain.com
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot /var/www

Again, the details might be slightly different for you: your DocumentRoot might by /var/www/html. Either way, add this line right after that DocumentRoot line:

Redirect / https://yourdomain.com/

(Swapping out yourdomain.com for your domain.)

Do the keyboard shortcut mambo: ctrl o, enter, ctrl x.

Do the Apache restart shuffle:

service apache2 restart

Now try visiting http://yourdomain.com in a browser. You should be automatically redirected to https://yourdomain.com …I really hope it works for you.

Enable HSTS

If you’ve made it this far and everything is working, well done! You have patience and fortitude in equal measure.

Go to ssllabs.com/ssltest and paste in your site’s domain name to see how well your site is doing in the security stakes. You’ll be given a grade, which will bring back all sorts of horrible memories of school tests.

If you’ve been given an A grade, there’s a way to level up to A+. You can enable HTTP Strict Transport Security. No, I don’t understand what it means either.

Go back to the command line on your server. You need to enable the headers module for Apache. Again, you may need to sudo this one:

a2enmod headers

Restart Apache:

service apache2 restart

Now dive back into that default-ssl.conf file:

nano /etc/apache2/sites-available/default-ssl.conf

Hit ctrl v to page down to right before that closing /VirtualHost tag. Add this line right after the gobbledygook you added previously:

Header always set Strict-Transport-Security "max-age=63072000"

You know the drill: ctrl o, enter, ctrl x.

Command Apache to restart before Zod!

service apache2 restart

On ssllabs.com/ssltest hit “clear cache” to test your site again. You should be rewarded with a higher grade and a feeling of smug self-satisfaction. Here’s adactio and here’s Huffduffer.

Troubleshooting

I hope that this walkthrough will be of some use to you. But the chances are that unless you are also using Comodo as your Certificate Authority and you’re running Apache 2.4 on Ubuntu 14, there will be some sort of difference between your setup and mine that could render all of this null and void.

If you run into problems, I probably can’t help you. I’m a complete n00b at this stuff, and if it hadn’t been for Tim’s hand-holding, I doubt I ever would’ve managed.

The https page on the Indie Web Camp is a handy resource that links off to other tutorials.

If you’re serving your site on Cloudfront, Josh’s walkthrough should be very helpful.

If you do make the switch from http to https, please, please, please document each step along the way, and then publish it. There are plenty of articles and blog posts telling us why we need to switch on TLS, but not nearly enough articles and blog posts telling us how.

Saying “You should enable TLS—it’s easy!” can be damaging on two counts:

  1. The first part is redundant: we all know that we should be doing this.
  2. The second part just makes us feel bad. It’s like telling someone “You should play guitar—it’s easy!” Yeah, it’s easy if you already know how to play guitar.

If you’re a l33t server wizard and you care about this https stuff—which you almost certainly do—I urge you to divert the time and energy you might consider putting into advocacy and instead put that time and effort into helping n00bs like me. If you can gather willing web developers in the same physical space—like Tim did at Indie Web Camp—I think you can achieve maximum knowledge dispersement. (Perhaps Google/Mozilla/Opera/Microsoft dev rels could sponsor TLS days in various cities and towns?)

The issue with https is not that web developers don’t care or understand the importance of security. We care! We understand!

The issue with https is that it’s really bloody hard.

But it’s worth persevering with it.

Friday, August 29th, 2014

AurelioDeRosa/HTML5-API-demos

A collection of device APIs—which, despite the title, are all JavaScript, not HTML. Each API in the list has a link to its spec, an explanatory article, a demo, and the current level of support.

Monday, August 25th, 2014

How to secure your site in an afternoon - Josh Emerson

Josh walks through the process he took to enabling SSL on his site (with particular attention to securing assets on CloudFront).

Thursday, June 19th, 2014

How To Use Huffduffer (get audio from internet onto phone) - YouTube

Chase Reeves likes Huffduffer so much, he made a video about it.

Tuesday, March 12th, 2013

Learn CSS layout

A handy step-by-step guide to all the ways you can use CSS for layout.

Monday, January 21st, 2013

Front-end performance for web designers and front-end developers by Harry Roberts

A really good introduction to front-end performance techniques. Most of this was already on my radar, but I still picked up a handy tip or two (particularly about DNS prefetching).

At this stage it should go without saying that you should be keeping up with this kind of thing: performance is really, really, really important.