Blog

When the EU’s DMA and its cousin, the DSA, passed in 2022, I was surprised.

The US cybersecurity agency analyzed popular open-source projects and found that many widely used projects still contain a lot of unsafe code.

The RIAA joins the New York Times in claiming that training LLMs does not constitute “fair use.”

InterOp has led to a tremendous improvement in browser interoperability, particularly with newer features. So it’s great that they’ve set new goals for 2024.

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?

I am a fan of SpaceX and the work that they are doing to get the human race to Mars and beyond. I am also a fan of having new desktop wallpapers. Browsing the web I saw a link to SpaceX’s unsplash.com profile, and instantly wanted their incredible photos as my desktop wallpaper. My goal was to always have the latest photo without constantly checking the Unsplash profile. So, I put my computer to work.

Last year, Jafar Husain gave a presentation about Falcor and how Falcor has changed how Netflix handles it APIs. Falcor, like Relay, is a clever bit of programming with an alluring promise to simplify network programming via a powerful abstraction. But we’ve already followed this seductive sirens’ song, many times before, and it usually doesn’t end well.

Let’s Encrypt is a free Certificate Authority for TLS, which we believe is a crucial advance for the Open Web. ZeroSSL takes the great work Let’s Encrypt is doing one step farther, by making it easier to create LE certs. So there’s more reason than ever to protect your Web sites or apps with TLS. In this post, we’re going to walk you through using ZeroSSL to generate a cert for Amazon’s API Gateway service. And you won’t need to install a thing!

The following is an excerpt from our upcoming book about remote work, The Global Office.

---

Success stories for remote work are common in the software business. The Linux operating system was developed via remote collaboration, along with all its various distributions, and thousands of other open source software libraries. There’s GitHub and Basecamp (formerly 37Signals) and dozens of lesser known but successful software companies, all of whom work remotely.

These are not curious outliers, nor is our industry unique in being transformed by the technology we’ve created. The Internet is changing work for everyone. Surgeries are being performed by remote control robots. Restaurants are going mobile in the form of food trucks. Just-in-time concert tours are happening in our homes. And during the next decade, millions of knowledge workers will earn their degrees online.

They won’t call it remote work. They’ll just call it work.

This is Greenspun’s Tenth Rule:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

You can tell how old it is by the fact that C and Fortran are given as examples of popular languages. We don’t personally know this Greenspun person, but let’s just assume he hung out with Ada and Alan back in the day.

At any rate, this quote inspired us awhile back to invent the rather immodestly named Yoder’s Tenth Rule:

Any sufficiently complicated C or Fortran program API contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp HTTP.

In other words, HTTP is the new Lisp.

Analytics and machine learning are increasingly relevant tools in the software professional’s toolbox. Statistics and probability now play a greater role than ever in our work.

Games can be a fun “gateway drug” for learning these techniques. In particular, the sports industry has recently turned to mathematics in the quest to gain a competitive advantage. Organizations like FiveThirtyEight, originally known for using polling data to make predictions about political races, now routinely predict outcomes for sporting events based on performance models and historical data.

For example, they predicted the outcome of every game of the NCAA Men’s and Women’s Basketball tournaments. Which raises a question.

How do they make predictions like this?

Recent buzz about Facebook React—I guess there was a conference or an announcement or something?—inspired an internal discussion here at Panda Strike. We’re on the record as not being big fans of the framework, but, as a group of smart, spirited software professionals, we sometimes disagree. Our respective opinions on Facebook React, and possibly many other things, may differ from those expressed on our blog. Which is fantastic. In fact, we’re hoping to bring more of those voices to the blog.

I thought I’d share some of that discussion with you. What follows is an edited transcript of an internal discussion thread. Since I only decided after the fact that it would fun to share it, I’ve changed the names of the folks involved. I’m also liberally paraphrasing in places.

One of the big ironies of the discussion around remote work is that some Agile gurus have said that remote work is incompatible with Agile development. This couldn’t be more false.

The truth is precisely the opposite: remote work is inherently more Agile than any Agile development methodology.

We use Ansible a lot for infrastructure automation.

One of the exciting new features in Ansible 2 is blocks.

Ansible blocks allow you to group tasks and apply things to those groupings.

Docker offers a feature rich platform for Linux containers. Amazon Web Services offers a feature rich platform for cloud computing. Naturally, we want to use them together. In particular, we want to use Docker Swarm running within an AWS VPC. Unfortunately, this isn’t quite as easy as you might think. Here’s our solution.

YAML is our favorite data format. Well, it’s my favorite data format, anyway. Popularized by Ruby and Rails, YAML is powerful and expressive. Consequently, it’s seeing increasing adoption, everywhere from dev ops tools, such as Docker or Ansible, to static site generators.

So it was surprising to discover the relative paucity of tools for processing YAML from the command-line. The few that do exist didn’t meet our needs, so we wrote our own.

HTTP is the world’s most successful application protocol. Yet it is widely maligned and misunderstood. Part of the problem is a poor developer experience. Part of the problem is that a Ph.D. dissertation is usually not the best introduction to a subject. And part of the problem is that building network applications is hard and we blame HTTP for that when we shouldn’t.

But HTTP is conceptually simple. HTTP cares about the things that network applications care about. No protocol can address the needs of every such application but we can try to address the needs they all share, the challenges every network application must deal with.

These are, in no particular order: naming, state, actions, versioning, authorization, caching and compression, and error handling. Everything on that list is essential for building distributed applications. And I don’t think most developers would even argue that point. But they might argue the point that this describes HTTP.

But it does.

The HTTP protocol gets a bad rap. HTTP is simply an application protocol that provides a well-considered set of features for distributed applications. Naming, caching, compression, and so forth, are not superfluous complications introduced by HTTP. They’re just things distributed applications need to do. HTTP is annoying because distributed computing is annoying.

Naturally, developers looked for guidance, and, in doing so, unfortunately turned to REST. But REST is the wrong lens through which to understand HTTP. REST was introduced in a Ph.D. dissertation. Notably, the title of the paper is not A Gentle Introduction To HTTP nor Building Your First Web API nor even Teaching Distributed Computing With Acronyms. In fact, the title of the paper does not mention either REST nor HTTP.

Hiring is hard. Hiring technical people well is harder. Hiring technical people that work remotely is even harder. To be good at it, you need to already be good at hiring. You can build on that to become good at hiring remote workers.

Embracing remote work means hiring from a larger pool of talent. But it also requires being more selective— you only want to consider people who will be successful working remotely. Assuming that you have a high success rate with your existing hiring process, here’s how you can ensure it stays that way when hiring remote workers.

We’re working on a book about remote work. One of our goals is to honestly discuss the challenges in working remotely. We’ve already written about some of them. You may have to change the way you think about managing. You may need to get better at assessing your team’s productivity. You probably will need to adapt your development process. Our upcoming book will dive into these in more detail. But there’s one challenge that I believe is the biggest of them all. And it’s one we haven’t written about, until now.

Brendan Eich’s latest venture is Brave, a browser platform that blocks ads and trackers while encouraging people to pay for content. Brendan has done a lot for the Open Web, founding Mozilla at a time when Microsoft was threatening to turn the Web into a proprietary technology, and working all the while to improve JavaScript. And I don’t doubt that his latest venture is equally well-intentioned:

The Web is always in trouble for some reason or other. I remember when Microsoft came after Netscape and threatened to lock Web standards into IE. Only the Web is so big, with such reach to billions of users, that no one owns it. This means it will always be contested ground.

But the Web today faces a primal threat.

Some say the threat to the Web is “mobile”, but the Web is co-evolving with smartphones, not going away. Webviews are commonplace in apps, and no publisher of note is about to replace its primary website with a walled-garden equivalent. Nor can most websites hope to develop their own apps and convert their browser users to app-only users.

I contend that the threat we face is ancient and, at bottom, human. Some call it advertising, others privacy. I view it as the Principal-Agent conflict of interest woven into the fabric of the Web.

As you may know, Panda Strike is a 100% remote work company. We’ve been so since we started back in 2012. During the past couple of years, we noticed that interest in remote work appears to be increasing. So we thought we’d share what we’ve learned in an ebook on the subject, which we plan on making available in February. Join our mailing list and we’ll let you know when it’s ready.

A Tale Of Two Offices

I came to remote work by accident. Back in the early aughts, I was leading a software development project where we did most of the development offsite in a remote office in Austin, Texas. I’d fly from Austin to Washington, DC, two or three times a month to meet with the client, update them on progress, give them demos, and so on. This worked well. So well, in fact, that I found myself wondering what it was that was so different about this project? We had the usual spate of last-minute changes and unexpected technical hurdles. But my team had met every challenge without appearing to break much of a sweat. Was it the team? Was I just becoming a better leader? Or…was it that we were working off-site?

Troy Hunt recently wrote a blog post with the wonderfully descriptive title, It’s 2016 already, how are websites still screwing up these user experiences?!. Many of the problems Mr.Hunt describes are manifestations of content producers inability to figure out how to make money.

On the one hand, if you’re selling ads, you can end up crossing this weird line where you’re basically telling your readers that you don’t really want them to read your articles. You simply want them to click on an ad. Your content has become subordinate to the ads. Is that really what you wanted?

And then your readers start using ad-blockers and now you’re basically in a fight with them, because they aren’t really your customers, they’re your product.

On the other hand, I keep hearing this refrain that you can’t get people to pay for content. Which is silly, since people pay for content all the time. The real reason people won’t pay for content is because most of the content they’re asked to pay for isn’t unique or valuable.

Estimating the cost and duration of software projects is, apparently, a hard problem. Thus, Hofstadter’s Law:

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

I was reminded of this, and inspired to write this blog post, when I saw an Web app pop up in my Twitter feed. It’s called Guesstimate and it describes itself as “a spreadsheet for things that are uncertain.” There’s even a blog post explaining the idea. It’s a fantastic way to explore the impact even small amounts of uncertainty can have on costs.

As 2015 comes to a close, I thought it would be fun to share a few of our big take-aways. Can you handle the truth?

Well, okay, then.

Without further ado, here are 7 truth bombs about the tech industry in 2015.