Always Get Better

Speed Up Page Load By Tricking the Browser

November 25th, 2017

Nettiquette is built into web browsers. When you go to download a page, its contents will load in at a max of 2 files at a time (by default). So if there are 12 CSS and JS files, you’ll only get 2 at a time until you load them all.

The good news is you can trick browsers into doing more at a time.

Enter subdomains.

Offload your CSS to css.yoursite.com, and your JavaScript files to js.yoursite.com. Now your website will load 6 files at a time (2 CSS files, 2 JavaScript files, 2 HTML/Image files from your main site).

It doesn’t matter if each subdomain is pointing to the same website. Web browsers go by the site URL and nothing more.

HTTP/2 is supposed to eliminate this problem, of course, but in the meantime doing this helps when you can’t crunch down your files any more.

Fun With Amazon X-Ray

November 19th, 2017

While riding on the train the other day, I was watching The Man in the High Castle on Prime and thought I recognized the actor on screen. “Too bad they only show the main actors. It would be nice if we could get a listing of who is in each scene,” I thought to myself. Imagine my surprise when I found out the app does exactly that.

So Cool

The info screen doesn’t just show the main actors for the show like I thought, it shows who is in the current scene!

It even changes as the scene changes. If you leave the info screen on, the actor list updates in real time as actors enter and leave the screen.

Trivia

The info screen doesn’t just show which actors are in the scene, it shows trivia about things going on in the scene; either actions of the characters or story background based on what’s being said.

As the action unfolds, the info changes to provide even more context.

How It Works

As best I can tell (maybe someone has better information?) the x-ray data is filled in large part algorithmically.

The main actor data comes from IMDB. I assume Amazon is using facial recognition technology to match profile photos with actors in each frame. Background actors aren’t included so there’s some intelligence there to either filter out people by screen time or dialogue.

There’s no way everything is done automatically, so there has to be a human component in there as well. Very likely they are using something like mechanical turk to have humans verify the raw data and add contextual tagging.

Your World Augmented

When I think about “augmented reality” this is the kind of thing I’m excited to see. Computer systems that provide more context about the world around us, not try to replace it entirely. Humans augmented by machines to make our whole experience better.

Next time you ask “who is that actor!?” try checking the app you’re watching – it may be able to tell you more authoritatively than a Google search or the person you’re sitting with.

Don’t Trust Your App to Node.js

October 14th, 2017

One of the most common questions I get is around my bullishness toward Node.js. People assume because I wrote two books about it, I should be an expert in all things Node (nope!) or at least a major cheerleader for it (hah!).

My problem has never been with Node or even Javascript. I use both every day and will be the first to reach for them when a problem needs solved. Just not for web development. I’ll stick to PHP or .NET for that.

Again: Node is great, but it isn’t the platform for the web.

Don’t take my word for it. During a recent Mapping the Journey podcast, Ryan Dahl (Node’s creator) echoed these sentiments:

So, kind of the newer versions of Javascript has made this easier. That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever. (Source)

Bottom line is: pick your tech stack based on your objectives, not because something was cool today.

5 Ways to Keep Your Web Server Secure

September 19th, 2017

Equifax recently revealed that they were hacked and exposed the personal information of over 143 million people. You may not be sitting on such identity-theft rich material, but keeping your server secure is absolutely a must for any business. Fortunately it really isn’t very hard to achieve and maintain a decent level of protection.

1. Hire a Competent Developer

Cloud computing makes web servers super accessible to everyone; unfortunately that means it’s really easy  to get a website running and get a false sense of security thinking everything is right when it’s not. A lot of developers claim they can do it all for you when all the really know is how to install Apache but not how to lock it down.

A good giveaway is: If your developer can’t get by without using a gui tool or web interface to set up and administer the website, they don’t have any business on your server. These are great tools for setting up local development environment but they take shortcuts to make things more convenient for the user – not to improve security.

So if your guy doesn’t have deep command line knowledge and the ability to work without these tools, fine. He’s still a great developer, he can build  you a secure website following all the security best practices. He just doesn’t have any business touching your web server; have someone else set up the “live” environment.

2. Lock Down Ports

When you’re setting up a web server, lots of supporting programs get started that don’t directly affect your website. Things like email, ICMP, DNS, time and DHCP are important to keep the system running but have no business leaving the local network. Everything that you don’t absolutely need to access should be locked down. No access except from inside the server.

Web services like Apache and nginx are specifically designed to prevent people from using them as attack vectors to control your system, and they get compromised routinely. MySQL has no chance at all – don’t open it to the outside world… ever.

3. Separate Database Servers

It’s super common to find database servers improperly configured so they become a major security hole. On MySQL, most people don’t know to add users better than “GRANT ALL PRIVILEGES ON x.* TO y@z;”. Since the SQL server itself is often running with elevated system access, it only takes a single unsecured query to let people create files wherever they want on your server.

The easiest way to prevent this from affecting your websites is to move SQL to another server. Not only do you get the bonus of having a machine configured exclusively for web work and another exclusively for DB work, but bad things happening on one won’t mean bad things happening on the other.

4. Keep Up With Software Patches

If you want to keep your server secure, keep it updated right away when vendors release updates for their software.

In a world full of zero-day exploits, any software with a security update is definitely a risk. Maybe even part of a malware package being sold in some dark corner of the Internet.

Don’t be a victim, keep your server secure by keeping it up to date.

5. Enforce User Permissions

One of the most compelling reasons to use Linux traditionally has been the strong separation between services using user permissions. Even Windows Server supports it these days.

If you’re using PHP, don’t use Apache’s modphp, use php-fpm. Set up your pools to give each website its own user. Again it’s all about compartmentalization. Bad things will happen and a good sysadmin makes sure the damage done by those bad things gets contained to a small area.

BONUS #6: Keep Your Server Secure by Never Logging In

Never allow yourself or anyone else to log into the web server.

There’s no reason for it. If you need to deploy a website update, use a CI tool like Jenkins. If you got rooted, trash the server and launch a new one.

People make mistakes, people forget about config changes, people can’t be trusted. You don’t need to worry about password scheme, RSA keys, iptables goofs or any of a million common problems if you just acknowledge the human risk factor and remove it from the equation.

When we move to programmed servers, we make it easier to bring new people on board, faster to verify and test new software versions, more repeatable in the case of a data failure, and more secure across our entire network. Don’t make humans do the work of computers, automate all the things!

Reverse Proxy with IIS and Elastic Beanstalk

September 4th, 2017

Suppose your main website is a .NET/IIS stack running on AWS Elastic Beanstalk, and you decided to add a WordPress blog to the mix. Instead of having http://blog.yourdomain.com and http://www.yourdomain.com, you want to host the blog from a subdirectory at http://www.yourdomain.com/blog. There are a few ways you can go about this; this post will go through how to set up a reverse proxy to a dedicated blog server.

You have two options:

1. Host WordPress in IIS – Not fun. You need to configure IIS to run PHP, host a MySQL database, and manage your WordPress file directory and updates in an environment where user uploads and core files can get trashed at any minute when EB rolls out a new server. It’s possible to run an amazing HA WordPress install on Elastic Beanstalk (topic for another post) but in a subdirectory directly hosted in Windows/IIS? Not for the feint of heart)

2. Host WordPress on a Linux server somewhere else and reverse proxy – Let’s do this instead.

Basically you set up WordPress and get it to look how you want, configure it to respond to your domain, then configure IIS to fetch your blog URLs and return them whenever a request comes through to the blog subdirectory on your main site. Every other directory is served from your .NET app as normal.

Reverse Proxy a WordPress blog with IIS

Important: The final step to this is the most important bit if you’re running on Elastic Beanstalk. Make sure you follow it in order to actually enable IIS’ proxy module, which does not come pre-installed on Elastic Beanstalk’s AMI.

Configure WordPress to Respond to Your Domain

Add this section to the bottom of wp-config.php, just before the require_once for wp-settings.php. This tells WordPress to ignore its default server settings and use your website as its base path.

$hostname = 'www.yourdomain.com';
$_SERVER['HTTP_HOST'] = $hostname;
define('WP_HOME','https://www.yourdomain.com/blog');
define('WP_SITEURL','https://www.yourdomain.com/blog');
$current_url = 'https://' . $hostname . $_SERVER['REQUEST_URI'];

Configure IIS Paths

The reverse proxy makes use of the rewrite in IIS. To turn this on for your blog, add the following to the directive in your web.config file:

 <rewrite>
   <rules>
     <rule name="Reverse Proxy to blog" stopProcessing="true">
       <match url="^blog/(.*)" />
       <action type="Rewrite" url="https://blog.yourdomain.com/{R:1}" />
     </rule>
   </rules>
 </rewrite>

This tells IIS to redirect all requests beginning with “blog/” to your WordPress blog. IIS will reach out to your blog server as if it is the requestor, fetch the page, and return it as if the blog were hosted from within IIS itself. The {R:1} variable carries forward any path information to the blog — so your theme files, user uploads and static assets will all pass through.

If you deploy your site and try to access your blog page now, it won’t work. You’ll see a ‘404’ response code even though the rules are definitely set up properly. The final step to this is enabling the Application Request Routing module on IIS – this is not enabled by default in Elastic Beanstalk’s version of Windows.

Enabling the Reverse Proxy Module on Elastic Beanstalk

You could Remote Desktop into your web server machine and manually enable the ARR module, but it would stop working the next time your environment flips, the server gets reloaded for any reason (which can happen even if you are doing all at once deployments and not adding/removing machines), or nodes get added to your environment.

We need to make sure the module gets installed and checked every time you deploy your files, so it’s always present and available to use even when new machines come online.

To do that, we’ll use the .ebextensions scripting hooks to download, install and configure ARR every time a deploy runs.

1. Download the ARR Installer

Download the 65-bit ARR installer (from here) to S3 so it is available to your VM when it boots. We want to install to S3 instead of pulling directly off Microsoft’s servers because we can’t rely on outside links being available when we need to deploy, and if our VM happens to be inside a VM without a NAT then we can use Amazon’s S3 internal endpoints without needing to configure any more advanced network.

2. Add an ebextension hook

In your .ebextensions folder (at the root of your unzipped deploy package), add a new config file (install-arr.config) to instruct Elastic Beanstalk how to install the extension:

packages:
  msi:
    ApplicationRequestRouting: "pathtoyourinstallerons3"

commands:
  01_enablearr:
    command: "C:\\Windows\\system32\\inetsrv\\appcmd.exe set config  -section:system.webServer/proxy /enabled:True  /commit:apphost"

The packages/msi lines tell Elastic Beanstalk to download and run the installer. Since you won’t be physically present when that happens, the script will automatically accept all the license agreements and silently run.

The appcmd command instructs IIS to enable the reverse proxy module, which turns your rewrite instructions into actual reverse proxy commands. Now if you visit www.yourdomain.com/blog/, you will see your WordPress blog.

Bonus: Trailing Slashes

If you visit www.yourdomain.com/blog without a trailing slash, you won’t see the blog. You don’t want to start the rewrite rule at this level because your reverse proxy will try to access blog.yourdomain.com// (with a double slash) for all dependent resources, which can cause problems with WordPress’ routing.

For this case, I like to redirect to a trailing slash at the IIS level. Every time someone comes to yourdomain.com/blog, they will redirect with a clean 302 status command to yourdomain.com/blog/. Just add this rule in your section of web.config

<rule name="Add trailing slash to blog reverse proxy" stopProcessing="true">
  <matchurl="^blog$"/>
  <action type="Redirect" redirectType="Permanent" url="{R:1}/"/>
</rule>

The regular expression in the match url tells the web server this should only apply to the “blog” path, that is, nothing before or after the word “blog”. This lets you have “blog” in other parts of your URL without accidentally redirecting valid pages.

Automate Squarespace Development with Expect

March 9th, 2017

We have a love/hate relationship with Squarespace’s developer platform. I think they really need to decide whether they’re a design company or a web hosting platform and stop doing 50% of each. But anyway…

Sometime in the last year they added a local development server that really helps speed up the process of building things for their platform. It doesn’t fully replace the “make change and deploy live” workflow, but it is super useful for testing basic layout updates for side effects.

Since I use a password generator, logging into my Squarespace account to do any development work involves cracking open 1Password and copy/pasting into the terminal. After a few weeks of that I decides there had to be a better way so I created this shell script to take care of the setup.


#!/usr/bin/expect
spawn squarespace-server squarespacewebsiteaddress --auth
expect "Squarespace email:"
send "squarespace username\r"
expect "Squarespace password:"
send "password\r"
interact

Hope this helps out someone who is as lazy as I am.

Speed up Deployments in Azure Web Apps

March 4th, 2017

Is it possible to speed up deployments in Azure Web Apps? Without resorting to temporary fixes?

My biggest pain point with Azure is the length of time it takes to push changes. My e-commerce project has a simple architecture with a smallish number of dependencies but takes over 35 minutes to complete a build. Although there’s no downtime during the process, you don’t want to sit around waiting. Fortunately it’s easy to speed up deployments in Azure.

Problem: Starting from a Bad Place

Here’s what I’m dealing with: 35 minutes to push each commit.

35 minutes - yikes! Time to speed up deploymentsKeep in mind – this is a simple website. .NET Core MVC6 with some NuGet dependencies. On a local system it takes about 3 minutes to go from a fresh clone to a running app.

When you factor in configuration differences and thing you need to check off when setting up a live environment, that 35 minutes makes this project pretty unwieldily.

The problem stems from the way Azure deploys apps to the service fabric. Everything in your app is shared with mapped network folders which is why things like session state and file uploads are available to every instance. That’s great if you have a complicated stateful app setup, but we’re building totally RESTful services (right?) so we don’t need that feature.

Building from a network drive is a problem for web apps because our npm and bower repositories generate tons of tiny files that absolutely suck to synchronize across a network drive.

Solution: Speed Up Deployments by Skipping the Network

Instead of waiting for the same files to synchronize across the network, use the Git repository on the local machine. This skips the network latency and does all the deployment work on the local machine.

Using local cache for Git deployments

In your Application Settings, add a key for SCM_REPOSITORY_PATH with the value D:\local\repository.

Now my deployments are 10 minutes – a big improvement.

Speed up deployments on Azure by using local drive for buildsStore the Right Things

10 minutes is a big improvement but I know we can do better. Looking through my project I find 100MB of content images that should really be part of a CDN. Now my repo is only 8MB and the deployment time is slashed again.

Respectable build times5 minutes, now that is a respectable build time.