Little 418

The resulting entity body MAY be short and stout

Migrating CloudBleed impacted static websites to Firebase Hosting

Posted by Jen Tong on February 24, 2017

So CloudBleed is a thing, and it’s a bummer for a lot of big websites. But, it’s also a bummer for countless tiny websites that use Cloudflare for Flexible SSL. You know, all those static websites for side projects and silly artsy things. Many of them follow this recipe:

This recipe is awesome for so many reasons. It’s on your own domain, CDN delivery just works, and it’s almost free: all you pay for is the domain registration. I used it a lot myself. But in light of CloudBleed, it’s a good time to consider other options. Here’s the recipe I’m pitching:

  • Static HTML site, likely generated by Jekyll (nothing changes here)
  • Hosted on Firebase Hosting
  • Domain mapped to a your custom domain name
  • Https provided by Firebase Hosting

Why Firebase Hosting

I’m biased (I work for Google), but honestly I don’t know of any other options for free static website hosting that also provide domain mapping and SSL. But here are some cool things about Firebase hosting anyway:

  • The Firebase part is free, so it won’t cost you any more[1].
  • You get real TLS, so you don’t have to feel dirty about using Flexible SSL any more.
  • You get redirects and rewrites!
  • You can lift-and-shift your site with minimal effort, and probably be done by later this evening.

[1] It’s free for sites under 1GB of stuff, and 10GB of traffic. This more than covers all my side projects.

Migration instructions

Oh? So I’ve convinced you to give it a spin? Follow me on a dinosaur filled adventure of static site migration as I migrate dinopacks.com, a silly art experiment with ~10 mb of HTML and images. Once in a blue moon it’ll get a spike of traffic from who knows where, but it generally matches the traffic patterns of my other side project websites.

The files for Dinopacks were previously hosted on Google Cloud Storage, but in an earlier incarnation the files lived on GitHub Pages. It also used Cloudflare Flexible SSL.

Migrating website data

There’s no reason your site can’t be published twice, so start by copying your website data to Firebase Hosting. Once you verify it works, you can move traffic over.

I was able to stick to the Firebase Hosting docs through the whole process.

  1. Go to the Firebse Console, and sign up if you haven’t already.

  2. Create a new Firebase project. You need one for each static website.

  3. This is where you could upgrade to a pay account, but if your site is low traffic like Dinopacks. The free Spark plan will work fine.

  4. Attempt to install (or in my case update) the Firebase CLI.

    $ npm install -g firebase-tools

  5. Fix your npm permissions, which always seem to get weird on macOS.

    $ sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}

  6. Successfully install the Firebase CLI

    $ npm install -g firebase-tools

  7. Authenticate the Firebase CLI.

    $ firebase login
  8. Change into your Jekyll project directory
  9. Make a tiny change to your website, like adding an HTML comment somewhere. This is a marker you can use later to verify that all of your traffic is going to the new host

  10. Init Firebase hosting. You probably only need to diverge from the Firebase CLI defaults once: tell it that your public HTML is in Jekyll’s default directory, _site.

     $ firebase init
 🔥🔥🔥🔥🔥 🔥🔥🔥🔥 🔥🔥🔥🔥🔥🔥  🔥🔥🔥🔥🔥
 🔥🔥        🔥🔥  🔥🔥    🔥🔥 🔥🔥       
 🔥🔥🔥🔥🔥   🔥🔥  🔥🔥🔥🔥🔥🔥  🔥🔥🔥🔥🔥
 🔥🔥        🔥🔥  🔥🔥    🔥🔥  🔥🔥        
 🔥🔥      🔥🔥🔥🔥 🔥🔥     🔥🔥 🔥🔥🔥🔥🔥   ...
            
 You're about to initialize a Firebase project in this directory:
    
     /code/dinopacks.com/
    
 Before we get started, keep in mind:
    
     * You are currently outside your home directory
    
 ? What Firebase CLI features do you want to setup for this folder? Database: Dep
 loy Firebase Realtime Database Rules, Hosting: Configure and deploy Firebase Hos
 ting sites
    
 === Project Setup
    
 First, let's associate this project directory with a Firebase project.
 You can create multiple project aliases by running firebase use --add,
 but for now we'll just set up a default project.
    
 ? What Firebase project do you want to associate as default? dinopackscom (dinop
 ackscom)
    
 === Database Setup
    
 Firebase Realtime Database Rules allow you to define how your data should be
 structured and when your data can be read from and written to.
    
 ? What file should be used for Database Rules? database.rules.json
 ✔  Database Rules for dinopackscom have been downloaded to database.rules.json.
 Future modifications to database.rules.json will update Database Rules when you run
 firebase deploy.
    
 === Hosting Setup
    
 Your public directory is the folder (relative to your project directory) that
 will contain Hosting assets to be uploaded with firebase deploy. If you
 have a build process for your assets, use your build's output directory.
    
 ? What do you want to use as your public directory? _site
 ? Configure as a single-page app (rewrite all urls to /index.html)? No
 ✔  Wrote _site/404.html
 ✔  Wrote _site/index.html
    
 i  Writing configuration info to firebase.json...
 i  Writing project information to .firebaserc...
    
 ✔  Firebase initialization complete!
 $
  11. With that done, you should verify that your site works by going to http://<your project>.firebasepp.com. For example, I went to https://dinopackscom.firebaseapp.com to make sure Dinopacks made it up successfully.

Yay! The content is migrated. That was easy, wasn’t it? Now for the fun part: monkeying around in DNS.

Custom domain stuff

Assuming you want to preserve all those juicy inlinks, you need to migrate your domain name. This part will take a little longer.

  1. Go back to the hosting console for your project, click the Custom Domain button, and fetch the special TXT domain verification record.

  2. You can keep using Cloudflare for DNS, and their fast updates make this process quicker. Go to Cloudflare and add the TXT record. Use an @ to specify TXT records on the root domain.

  3. Wait a few minutes for the TXT records to propagate. You can verify them using the dig command. Correctly set up records should look something like this:

    $  dig TXT dinopacks.com
   
; <<>> DiG 9.8.3-P1 <<>> TXT dinopacks.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
   
;; QUESTION SECTION:
;dinopacks.com.			IN	TXT
   
;; ANSWER SECTION:
dinopacks.com.		300	IN	TXT	"google-site-verification=xWOK-correct_XHorSe09bHSbaTTeryXStapLEA"
   
;; Query time: 53 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Fri Feb 24 15:21:15 2017
;; MSG SIZE  rcvd: 108
  4. Return to the Firebase Hosting console and click Verify.
  5. You have a couple options now: You can add a second TXT record and have a seamless transition (Advanced), or be lazy and accept a security warning for a few minutes (Quick setup). I opted for quick setup, and the warning was gone within a few minutes.
  6. Next, change your A records at Cloudflare to point to the IP addresses provided by Firebase Hosting. Make sure they’re configured to ‘DNS Only’, and not using the reverse proxy. If you have any CNAME aliases, remove them.
  7. Wait for them to propagate. Remember that marker you added up above? It’s a good way to know that things have migrated when viewed from mobile devices. This is also a good time to click around and make sure everything still works.

Cleanup

You’re done! Well, mostly. You could stop now, or you could take a moment to clean up all the clutter you left behind.

  1. Remove those TXT records that you added for domain verification. They’re benign, but they don’t need to be there any more.
  2. Delete the files at your old host. For me this involved deleting the Google Cloud Storage buckets that previously served my content. I could have done this with the command line interface, but I opted to do it from the console’s web interface.
  3. Update your deployment scripts to use firebase deploy.

What ifs?

Call me paranoid, but I’m always cautious about using free services. I do a ‘what if’ thought exercise on their limitations.

  • What if I get a huge spike of traffic and I exceed the Spark plan transfer limit?
    • Pay a few bucks to upgrade to a paid Firebase plan.
    • Or, since Cloudflare is probably still your DNS, you can enable their reverse proxy to reduce load. And yes, I realise the irony of that suggestion.
  • What if I run into a weird problem and I can’t find a solution on Stack Overflow?
    • Use one of your support tickets. (Something I actually did when migrating mimming.com, which had some legacy Firebase weirdness from past adventures.)

Conclusion

So now you’re migrated to another provider, you’re probably not paying any more, and you’re using proper SSL. Doesn’t that feel great? And if you decide you don’t like it, it’s just as easy to move to a different provider later.

If you found this tutorial helpful, let me know! If you have a better place to move your side project static websites, let me know that too. I’d love to share more options with people.

Update

I asked you all for other hosting recommendations, and provider got lots of recommendations: Netlify. I haven’t used them, but they look like another great option to consider.

Moving around the filesystem in vim

Posted by Jen Tong on February 17, 2017

I’m a bit of a vim junkie. Many years ago I was forced to use it in my CS101 class because it was the only text editor available. The first month was pretty rough, but that was probably because we were writing Java without an IDE. Anyway, once I got the hang of it, I was hooked.

I never studied how to be effective with vim, but instead I’ve added a trick here or there over the years. Even 16 years later, I’m still adding tricks to my vim quiver.

My latest new trick is navigating around the file system inside a vim buffer. It feels a bit awkward at the first, but once you get the hang of it, it’s a lot faster than using the OS GUI to find files.

Moving between files

I used open a new vim process from bash, make edits, :wq, find the next file, and repeat. It turns out there’s been a better way the whole time – the edit command: :e.

You give it a file name, and vim switches the buffer that file in the current directory. If the file does not exist, vim will create a new file when you write it.

:e dinosaurs-are-awesome.txt

You can also give it a path to edit a file somewhere else.

:e /secret-stuff/embarassing-fanfics/harry-potter-and-the-cursed-meteorite.md

And use escape sequences to cope with filenames that contain spaces.

:e ~/Downloads/ProposalDeck\ finalVersion\ Copy\ 2.doc

If you made some edits in your current buffer, but want to ditch those changes, add a ! just like you do in a :q!, a.k.a. the only vi command that emacs users know.

:e! philosoraptor.meme

Oh, and if you’re not using tab completion here, you’re missing out. Tab completion works for filenames and directories. Consider it an added incentive to start your commonly edited files and git repos with distinct letters.

Moving between directories

If you know where you want to go, use the :cd command. If you kind of know what you want, use :cd and abuse tab completion.

:cd /tmp

If you have only a vague idea of what you want, you can navigate around directories with the :e command.

:e .

Which yields a screen like this:

Pressing enter opens whatever is under the cursor.

You can move around with arrow keys, but that’d be a sin against vim. Instead, use your vi file navigation-fu. Most of it works, including moving to line number (:42), regex searches (/[hHarry]), and even macros (qa↑↑↓↓←→←→q).

Setting a different default directory

By default vim will start it’s directory context in your home directory. This is a reasonable default, but if you want something different, just add a :cd command to your .vimrc.

:cd ~/dinosaur-fanfics/

Conclusion

So yeah, so that’s how you can move around in vim. It’s also a core feature that I somehow avoided for 16 years.

vim users: Are you still picking things up? If so, tell me about something you picked up recently :)

Non-vim users: 1) why are you still reading? 2) How do you tolerate other text editing interfaces?

Catching up on Data Structures

Posted by Jen Tong on November 4, 2016

I’m pretending to be a Computer Science professor this semester at Xavier of Louisiana. My office hours are always busy, and I spend much of them teaching students the mysterious art of the tech interview: the practice of implementing clever algorithms and data structures on a single whiteboard panel.

But… my last formal training in the topic was more than a decade ago, which is a long time in CompSci land. New techniques have been invented, and others have entered common usage. Many of them are compact enough for whiteboard representations, and current info is often worth a mention in an interview, even if you solve problems with more traditional techniques.

YouTube and MIT Open Courseware to the rescue! I’ve been watching Erik Demaine’s awesome lecture, and feel almost caught up!