Blog

I am very excited to announce [Graphite][], our serverless graph database technology, which we developed with one of our clients and can now share with you. In fact, we’re so excited about this technology, we’re shifting our focus to helping clients leverage it.

Today I’m excited to introduce the Sky client, making it easy to integrate with any Sky API you build. I’m also announcing Panda Sky v2.6, featuring a couple new command line features to help with testing.

Sky 2.5 introduces a new, handy feature: log tailing. You can now look at your entire deployment’s log trace from the comfort of your own terminal.

Happy New Year! I’m proud to announce Sky v2.4. This version includes support for mixins - entities that extend Sky’s deployment and command line features. This post will show you what kind of features are now available, as well as a preview of Sundog, a new project aiming to be a functional version of the AWS SDK.

Mixins add behavior to a type (or class) without relying on inheritance. JavaScript has nice prototype-based types and recently added classes, but lacks first-class mixins. Fortunately, it provides everything we need to implement them. Since we use mixins for Play, our library for creating native Web Components, I thought I’d share our approach here.

We are really excited by the potential of serverless architectures to provide a simpler and more reliable way to deploy modern Web and mobile apps. However, serverless is still relatively new, and, like any new technology, it can be difficult to workt with. We wanted to make it easier, so we built Panda Sky.

We’ve been fans of Web Components since they were first announced. We had the opportunity to experiment with them, and with Polymer, in particular. But we were frankly disappointed in the results. Our team, like many developers, found React, and React-inspired frameworks easier to use. What was missing was the simplicity of React, but for Web Components. So I built it.

Assume (for the sake of argument; no need to tell us why) that one day you find yourself working with Python in Google App Engine, using PyCrypto to encrypt secrets. Unless your plaintexts are always a multiple of 16 bytes in length, you are likely to run into this error:

ValueError: Input strings must be a multiple of 16 in length

The answer is to pad out your plaintext to an appropriate length, but the version of PyCrypto available in App Engine can’t do this for you.

Earlier this year, I received an email from LifeLock warning of the ills of weak passwords. Unfortunately, the folks at LifeLock don’t appear to be experts in effective password strength policies. I want to address the following statement specifically:

[Use] upper- and lower-case letters, special characters and numbers. And make sure the resulting passwords aren’t words found in the dictionary.

In the words of Dwight Schrute: WRONG. In fact, the best method we have for generating strong passphrases—called Diceware—relies on randomly-selected dictionary words.

Google Fiber’s big announcement last week, that they’re going to “pause” the rollout of Google Fiber in new cities, in combination with the resignation of CEO Craig Barratt, led to a lot of speculation that this particular letter in the Alphabet is in trouble. Everyone from Ars Technica to The Washington Post had some fun with this story. We offer a contrarian take.

Google Fiber isn’t in trouble: in fact, it’s poised to completely disrupt the ISP market. In short, Google Fiber is a Death Star.

The following is an edited transcript of an internal Panda Strike Slack discussion, in which we assess implications of the recent IoT-based DDoS attack and conclude that we need to drink delicious beer.

Dan So the Internets are freaking out today about how people’s toasters have become an attack vector.

I’ve worked from home a lot over the past 8 years, for several reasons, but for one vitally important one that isn’t often discussed.

When people talk about working from home they mention something time saving or economical - like saved commute time, money saved eating at home, or the pure joy that comes from getting to wear pajamas all day. The conversation is generally centered around productivity and focus, which is all true and well and good but isn’t the main reason I work from home.

A fun question came up the other day on our internal Slack channel:

For soft-deletes (where we keep a record in the database, but set a flag that it’s been deleted), we’re trying to decide between DELETE or PUT with a body {status: 'deleted'}. That way, we can reserve DELETE for hard deletes. Any recommendations?

Yes, we’ve got recommendations, but they might surprise you.

Apache JMeter is a flexible tool for producing load against an application and measuring the results. We used it on a recent project to measure performance of a large and complex web site. The results of the performance tests required aggregation and visualization.

JMeter has its own built-in distributed performance testing capability. It also has the capability to visualize the test results. We found both lacking.

Roy Fielding’s advice on versioning APIs is, well, succinct:

Don’t.

In a subsequent interview, he elaborates:

Websites don’t come with version numbers attached because they never need to.

Neither should a RESTful API.

But at some point, don’t you have to version something?

One of our favorite patterns at Panda Strike is to have an HTTP API that dispatches jobs to workers. We called this the dispatcher-worker pattern, but its names are exceeded only by its variations. In particular, it’s a variation of the microservices pattern.

So you can imagine our excitement about Amazon’s support for “serverless” architecture, which happens to fit this pattern perfectly.

We’ve made the case on this blog that REST is the wrong way to try and understand HTTP. We’ve also said that it’s worthy of study if only because the Web runs over HTTP. We’ve even contributed a few introductory blog posts to the subject.

But that begs the question—what’s the big picture here? Is HTTP’s success due to the Web or is it the other way around? Is there some brilliant insight that HTTP captures or is Fielding’s dissertation on REST, which he didn’t expect anyone to read (pretty typical for a dissertation), the best we can hope for?