Always Get Better

Never stop looking for ways to improve

by Mike

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.

by Mike

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.

 

by Mike

LAMB-da - Serverless Contact FormsServers are a pain to run. They break, get hacked, need updating, and generally need your constant attention or that site you posted two years ago won’t work when you need to make a change. Static sites are a beautiful dream, but what do you do when you need user input? You don’t want to use a third-party service just to get rare contact forms from your visitors. It’s stupid to run a web server to handle this; that completely eliminates the whole purpose of creating a static site. What you need are serverless contact forms.

Architecture

I use Wufoo forms for most of my static sites but today I’m switching to Lambdas. To start, I have a static Jekyll site uploaded to S3. I have a CloudFront distribution set up for edge-caching and SSL. Now I’m going to add a contact form that reaches through AWS’ API Gateway to execute a node.js script hosted on Lambda.

Here is the general data flow:

Serverless Contact Forms Architecture

Serverless Contact Forms Architecture

Email Script

I first write a simple Node.js script that validates the contact form parameters then pumps the messages into the Sendgrid API. You can swap in your preferred client. AWS SES is a popular one for sure and a nice way to keep everything under one umbrella.

Setting Up the Lambda

First create a blank template.

Serverless Contact Forms start with a blank lambda

Serverless Contact Forms start with a blank lambda

Next create an API Gateway trigger for the Lambda. I set my security to ‘Open’ because I am allowing anonymous traffic to send contact forms.

Serverless Contact Forms API Gateway Settings

Serverless Contact Forms API Gateway Settings

Finally, upload the contact form script. Since I’ve used libraries other than Amazon’s own I need to zip everything up and send it as an archive.

Serverless Contact Forms Lambda Setup

Serverless Contact Forms Lambda Setup

Configuring the API Gateway for Serverless Contact Forms

Now that the Lambda function has been created it’s time to open it to the outside world. Go to the ‘API Gateway’ service, find your endpoint, and choose Actions -> Create Method. Add a POST method pointing to your Lambda function’s name.

Serverless Contact Forms API Gateway Setup

Serverless Contact Forms API Gateway Setup

You need to enable CORS because you will be using AJAX to submit the form. This is a cross-domain request while we’re testing it out.

lambda-cors

Then deploy the API. The default environment is prod, which is good enough for our purposes.

lambda-5

Finally you see the the endpoint URL you will use for your form.

lambda-6

Serverless Contact Forms

That’s the backend all set up now you can build out the contact form your visitors will use to contact you. Here’s mine. It’s super ugly but it gets the point across.

When you hit submit the send function executes, posting the email address and message to the endpoint and alerting the results. Nothing fancy, and obviously you would need to code in all the proper validation and UI stuff to make this pretty.

CloudFront Configuration

I can get into the static site setup later, but for now I’m working from an existing distribution.

Since CORS is all set up you could use the endpoint as-is and just launch your contact form, but that’s not as elegant as posting to the same domain as the form itself. You can achieve this illusion because CloudFront is able to forward POST requests now.

Add the origin for the API to the distribution.

lambda-7

Tell CloudFront to forward (and not cache!) your contact form by adding a behaviour for the path where you want to host the form. The path name should match your API resource name:

lambda-8

For this to work make sure you choose the Allowed HTTP Methods option with POST. Setting the Forward Headers option to ALL causes CloudFront to use the origin cache settings (no cache) which will let more than one person use your contact form.

Profit

Overall this feels like it is a longer process than it should be. The first time I did this it took almost 5 hours, but now that I know the process I’m sure next time will be a lot faster. Figuring out the right folders and permission settings (for CORS) was the most finicky part of the process, but the API Gateway has an informative test tool that helped a lot.

This is only going to get better, and Lambda is a fantastic cost-effective tool for replacing on-demand tasks where you would once need to spin up and support a whole server. Serverless contact forms are definitely the way to go if your site is otherwise static.

by Mike

It seems like every time I log into my AWS account there are a ton of new services waiting to be discovered. (Not to mention dozens in early preview that don’t even show up in the main list.) I feel like keeping up with what’s going on in that space is becoming a full-time job all by itself. The most exciting new update is the Certificate Manager – pushing us one step closer to “https everywhere”.

S3’s static website hosting is a fascinating service. If you are able to design your site entirely using third party APIs (or even better, none at all), it’s possible to fully host your site through CloudFront. Think unlimited scalability, super fast edge-based response times. A parenting blog I manage as a static site (using Jekyll) has consistent response times all around the world. Improving response times for off-continent visitors has definitely had a big impact on session times.

HTTPS and Static Sites

Amazon has done an incredible job making certificate provisioning easy. To add a new SSL certificate to your Cloudfront-based static site:

1. Go into your Distribution
2. Under the ‘General’ tab, click ‘Edit’
3. Choose ‘Custom SSL Certificate’ and click the button “Request an ACM Certificate”
4. Make sure to type both your naked domain and “www.” variant in the certificate
5. After confirming the certificate, go back to your distribution’s general settings and select it
6. Wait 15 minutes and profit(?!)

Of course if you’re starting a new site the same steps mostly apply, you can add a certificate right from the creation wizard.

What about cost? FREE. You do not have to pay a thing for SSL certificates using this service.

Redirect Non-HTTPS Traffic to HTTPS

The next thing you should think about doing is redirecting all non-HTTP traffic to HTTPS. Yours is a professional site, or at least should look like it was created by a professional. Having that little lock icon next to your address says “I’ve thought this through and know what I’m doing”. Anyone can toss up a website, not everyone is advanced enough to know about secure sites.

Error on Existing Sites

If you’re already running a (non-HTTPS) website through Cloudfront using S3 websites, the default origin behaviour is to “Match Viewer” when it comes to HTTPS. S3 sites do not support HTTPS so you will get a big ugly error.

The fix it:

1. Go to your Distribution
2. Under the “Origins” tab, choose your S3 origin and press the “Edit” button
3. Find “Origin Protocol Policy” and choose “HTTP Only”

while you’re there, make sure SSLv3 is NOT selected under “Origin SSL Protocols”. SSLv3 is bad news bears insecure – we don’t want that!

Limitations

The biggest drawback to Cloudfront’s SSL solution is you are pretty much stuck with server name indication (SNI), sharing your SSL connection with hundreds of other sites. For most people this shouldn’t be a problem, but if your audience is stuck in 2005 and hasn’t upgrade to Vista or better by now, their browsers are not going to be able to access your SSL site this way.

Cloudfront offers IP-based SSL for $600 a month, which is overkill unless your company has seriously deep pockets (seriously, if your goal is free SSL certificates you aren’t going down this option). If SNI is out of the question for you, your best bet will be an elastic load balancer pointing at a small server – you still get the benefit of free SSL certificates that never need maintenance and you get your own IP address.

by Mike

Malware found in Xcode (xcode-ghost)People rely on their app stores to provide safe and high quality software for their phones and tablets. With iTunes in particular, we trust Apple’s strict review standards will raise the bar for quality and protect us from the shady apps and trojans we might find on file sharing services and third party app stores. What happens when that trust is misplaced?

A bunch of popular apps on Apple’s App store shipped with malware in September. “Popular”, of course, refers to app used by more than 500 million iPhone users primarily in China where the malware originated. Some apps, like WeChat, are also used in the west but by-and-large the affected programs are names written in hanzi most of my readers would not be able to pronounce let alone install to their devices.

What does the malware do?

First off, what can you expect to happen if your phone gets infected?

This post from MacRumours summarizes things pretty well, but the highlights are:

  • Sends device information, phone number and ID to C2 (command-and-control) servers
  • Fake system alerts phishing for passwords
  • Access clipboard (including stealing secrets from your password manager)
  • Hijack URL opening

We’re not talking about phone-takeover threat levels, which is a testament to the sandboxed environment apps run in. These functions are available to pretty much any developer — you’re not supposed to use the device ID but you can get it if you want it.

How Did Malware Get On the App Store?

The first thing that most people are asking is: how did this happen? With Apple’s notoriously stringent app review process, how did apps with this vulnerability get through?

As it turns out, developers chose to download updated versions of XCode from file sharing networks rather than directly from Apple. XCode is a huge download (larger than 3Gb) so downloading directly from Apple can take a long time. In order to save time these developers thought it would be a good idea to trust an unsigned version rather than the one from Apple.

How Did Malware Get Through the Walled Garden’s Gates?

But what about the review process? The UUID-gathering portion alone should have been enough to trigger warning flags, right?

Not so, according to people who know.

Although the App Store performs a cursory check of submitted apps for private API usage, the XCodeGhost files were added as a dynamically loaded bundle to the compiled app bundle — in other words, not subject to the code scanning… pretty sneaky.

How to Protect Yourself

How can you protect yourself when the store you rely on for your apps is poisoned?

Not much. Other than inspecting every single network connection there are not a lot of things you can do to detect this kind of activity on your device.

Installing app updates as they become available is the best thing you can do for your phone. Although an attack on this scale was made possible by the single-provider model of the App Store, it’s also true that having the App Store as the centre of the ecosystem is the best way to quickly push out fixes for problematic apps as they are discovered.

by Mike

I never buy warranties for my purchases – if someone is expensive enough it should go on your home insurance policy. If it’s cheap enough, just replace it – we live in a society of garbage anyway. Getting serviced when things break is more often than not a huge waste of time. AppleCare is different.

AppleCare is worth the cost
AppleCare is the exception to my “policy”. Like the rest of Apple’s products it comes with a premium price tag, but unlike many company warranty products, Apple actually seems to stand behind their plans – except, apparently, if your device is damaged by water, but we can talk about that another time.

Fixing a Broken Screen

A few months ago (and not long after I first got it) my phone took a fall onto the pavement and the screen shattered. Not sure why I left it so long but on a whim I loaded up the Store app and booked an appointment to be seen by a “genius” at the nearest Apple store.

An hour later I was sitting at their genius bar with my phone being seen by a blue-shirted worker. No questions asked about how it got damaged, no trying to invalidate the AppleCare plan I had on the phone. The dent in the corner was too deep to replace the screen so they replaced my phone and I was out of there in under 15 minutes.

Without the AppleCare I would have still gotten the refurbished phone, but it would have cost hundreds of dollars. It was disappointing to break my phone when it was brand new, but I’m definitely glad I sprung for the protection plan.

[Edit: February 2016]

Servicing the Battery – AppleCare again

The battery on my Macbook Pro gave out just before a business trip. AppleCare to the rescue again! Without it, I would have been out $600, since the battery is connected to the case and the whole top part over the keyboard needed replacement.

Maybe it’s a bit dirty to have everything so proprietary and tightly packed that your customers are basically forced to buy insurance instead of pay hefty repair things, but based on the bill amounts I saw, the warranty has paid for itself.

by Mike

Over the past year I experimented with working at a standing desk. My setup was a converted “regular” sitting desk with the computer monitor lifted on a set of rubbermaid bins. It wasn’t the most beautiful rig but the ergonomics were right and the screens were at an appropriate level for my height. Unfortunately I didn’t take any pictures of the contraption.

Motivation: Not Wanting to Die

It should come as no surprise that sitting for long periods of time is killer bad for you. When you live a generally sedentary lifestyle, any excuse to get out of your chair is a good one; so my expectation going in was that I would probably be uncomfortable from being on my feet and subtly flexing my knees all day versus sitting.

In reality it wasn’t bad at all. The first two or three days my legs were pretty sore at the end of the day and then my body got accustomed to standing. Many standing desk users suggest putting an anti-fatigue mat down; I never did nor did I find I needed it. The first week I used a few towels to pad my feet from the hard floor but after the initial adjustment I was fine on my own.

Results: More Energy

After sitting at a desk all day I noticed I was always exhausted both physically and mentally after work. I would want to eat dinner and relax on the couch with the kids, maybe watch a movie. I expected to be ready to crash and put my legs up after standing all day, but the opposite happened.

Unlike days spent sitting, when you stand you never stand perfectly still; you’re always shifting your weight from one leg to the other even if you’re not noticing it. At the end of the day I felt wired – I didn’t want to sit at all. I was more likely to go for a walk than to vegetate and zone out after working.

Results: Sharper Focus

After all this I think every company should raise their conference tables and throw away the chairs, or ditch the conference room and go for walking meetings instead. When you’re standing you naturally approach your tasks with more urgency, and have quick brilliant insights. Everything gets done faster because there is less mind-wandering.

For a programmer, this works really well if you are doing a good job at breaking your work down to manageable tasks. A single work unit can be done quickly when there are no other distractions, and standing really helped cut through all those other distractions.

Results: Shorter Attention Span

The major downside I experienced was the flip side of the sharp focus that standing brought. Long monotonous jobs, like data-entry, research, or marathon programming sessions were a lot more difficult to focus on while standing. I would start tasks with a lot of focus but lose interest and need to switch to something else or walk around. This worked well for quick multi-tasking kinds of work, but when something too longer it felt like a struggle.

Mix It Up, Do Both

The standing desk streak was broken when I did some business travel last November. I had to force myself to sit at a desk all day where no standing spaces were available. Turns out, I didn’t hate it as much as I expected.

Nowadays I have a lot of surfaces to work on and I move around throughout the day, switching between sitting and standing positions depending on what needs to be done. The next purchase might be an adjustable desk capable of moving from a sitting to standing layout throughout the day.

I would recommend everyone try working in a standing position at least once. Like me you can try it out quickly without spending a fortune on a dedicated standing desk.