So if you’re anything like me and you are very excited about something, you want to celebrate it.
If you are me, two of those things are Christmas and &yet.
This being my first Christmas with &yet, I wasn’t entirely sure what to expect. I mean, I assumed it would be nothing short of awesomeness, I just couldn’t picture it in my head.
Sometime in the spring of this year, the &yet team caravanned down to the lovely southeastern Washington outpost of Walla Walla for a day of team reflection, hanging out, and planning. It was a beautiful day and we took advantage by wandering around the Whitman College campus and talking about what we like about the team and ways to improve the team.
It's now months later, and I was to have followed up long ago with a summary of actions we can take to be more awesome. I kept putting it off (not awesome) and recently got called out (awesome). Get with it Zanol.
Deploying a production application can be quite the chore. On the road to &! 2.0, our processes have changed significantly. In the beginning stages of &! 1.0, I hate to say it, but deploys were a completely manual process. We logged in to the server over SSH, pulled from Git, and restarted processes all by hand. Less than ideal, to say the least.
Managing those processes was just as bad; we were using forever and a simple SysVInit script (those things in /etc/init.d for you non-ops types) to run it. When the process would crash, forever would restart it and we'd be happy. Everything seemed great, but then one day we accidentally pushed broken code live. What did forever do? Kept trying to help us, by restarting the process. The process that crashes instantly. Several CPU usage warning emails from our hosting provider later, we realized what had happened and fixed the broken code. That's when we realized that blindly restarting the app when it crashes wasn't a great idea.
Since our servers all run Ubuntu, we already had Upstart in place so swapping out the old not-so-great init.d scripts for the new, much nicer, Upstart scripts was pretty simple and life was good again. With these we had a simple way to run the app under a different user (running as root is bad, please don't do it), load environment variables, and even respawn crashed processes (with limits! no more CPU usage warnings!).
“Your onboarding sucks, guys.”
In between bites of breakfast, our friend, Pradeep Elankumaran (Kicksend CEO), was giving us feedback on using And Bang 1.0 right after the initial release.
We got a lot of input in the early beta days of And Bang and had already made some iterations based on that feedback. But Pradeep was one of the few folks we’d sent an invite to without having some discussion about the app as they were using it for the first time.
A big driver for And Bang was that it was all supposed to be "glowingly" realtime. Many apps that have some sort of "realtime" component have it sort of "tacked-on" to a more traditional request/response based infrastructure. We wanted the whole experience and the whole technology stack to be realtime.
When I first started tinkering around with building a team task tool a few years ago, I grabbed a set of what were my familiar tools at the time. Django, MySQL and a bit of jQuery.
As it turned out, if you want to build a highly interactive, multi-user, realtime application, Django or Rails and relational databases are not necessarily the right tools for the job.
When I joined &yet this last January, &! (And Bang) 1.0 was already launched. A lot of the work had been done by one or two members of the &yet team.
But, And Bang was a product of the company, not just a couple of people, so we had to find a way to better enable contributions from the rest of the team. Its core ideas were us—so very us—so why shouldn’t more of the team be enabled to contribute on a significant level?
Significantly increasing the number of contributors is more difficult than you might imagine. I pushed very hard to empower team members to contribute as much as possible. These efforts paid off, the team was energized to help but we also learned a few thing along the way.
At &yet, we’ve used a lot of different project management tools for our work building web software for human people.
If you’re like us, it’s always hard to find one collaboration tool that “fits” and really helps you get things done. One day we realized:
Project management tools are primarily great at managing things you’re going to do later. They’re planning tools, not doing tools. To manage the work you're doing, you need completely different tools.
The development of our favorite teamwork tool, And Bang, has had such a significant impact on our company’s trajectory that we wanted to take some time out during this holiday season to share some of what we've learned with our community and fellow And Bang users.
This December, we’re rolling out the first ever And Bang Advent.
We’ll highlight different perspectives and pieces of the puzzle that we’ve delightfully (and/or painfully) come across during our journey from And Bang 1.0+ to the mysterious 1.5 that we never shipped, to our present work pushing to ship And Bang 2.0.
Whenever there is discussion on this topic, there's always someone who asks, "What is realtime?"
The answer, as it turns out, has several layers.
On the surface, realtime is about websites which dynamically update from outside data sources without user intervention.
This sounds rather uninteresting to many, as this has been done since the days of Yahoo! Chat in 1994, but there is more to it than that.
We asked Portlandians about realtime technologies—and, um, they answered!
DISCLAIMER: No hipsters feelings were harmed in the making of this video.
Film by Miss Melanie Brown
Music by YACHT
Yeah, that’s correct. We’re changing the name of our conference on realtime technologies.
(Who does that? I dunno. Uhhh, I guess: “us”?) But—more importantly—why?
We got a few good chuckles from folks from the name "The Keeping it Realtime Conference" But, we've gotta be honest: it's a really long mouthful, and people who want to talk about it get confused with how to shorten it into an abbreviated mouthful—oh, and then!—people who read “krtconf” have no idea what the heck the conference is actually about.
Basically, it’s a fun name, but we’d rather have something that people just “get”.
These days, more and more HTML is rendered on the client instead of sent pre-rendered by the server. So If you're building a web app that uses a lot of client side javascript you'll doubtlessly want to create some HTML in the browser.
First a bit of history. When I first wrote ICanHaz.js I was just trying to ease a pain point I was having: generating a bunch of HTML in a browser is a pain.
Why is it a pain? Primarily because JS doesn't cleanly support multi-line strings, but also because there isn't an awesome string interpolation system built into JS.
The joy of independent software is that some of the most successful people also happen to be some of the most generous, friendly, and fascinating.
We feel lucky to have been invited in to Panic's headquarters to interview founders Cabel Sasser and Steven Frank. We loved what they had to say about shipping, building a business, being a team, and leadership.
Just like their products, these two guys have immense character--in both senses of the word.
The single biggest challenge you'll have when building complex clientside application is keeping your code base from becoming a garbled pile of mess.
If it's a longer running project that you plan on maintaining and changing over time, it's even harder. Features come and go. You'll experiment with something only to find it's not the right call.
I write lots of single page apps and I absolutely despise messy code. Here are a few techniques, crutches, coping mechanisms, and semi-pro tips for staying sane.
This week is the 20th anniversary of one of the worlds largest and longest running hacker conferences, DEFCON.
&yet Security Officer Adam Baldwin will be presenting Friday at 5:30 PM on “Blind XSS (cross-site scripting)”.
Adam’s talk will announce the release and demonstrate the xss.io toolkit. xss.io is a platform to help ease cross-site scripting (xss) exploitation. We use this tool to to demonstrate to our clients the severity and exploitability of vulnerabilities we find in their web applications.
Adam will also announce [redacted] during the talk, which will also aid in the exploitation of web applications.
Futurists tend to see gadgets and computers as assistants to our lives, but they're still just tools. I think we're close, we just need to combine some technologies that already exist and add a little context.
But what's really the problem?
Here we are, in the future, and boy is it overwhelming. I have a phone with several hundred "apps", about 400 websites I care about, a desktop at home and a laptop for work, a tablet, and maybe someday I'll have some Google glasses. Do I need all of this? Probably not, but it makes for some easy context. I use each device for different purposes, but what if my devices were more aware of what I was doing?
Our team loves to do great things and get stuff done. We know that doing good work is how you get to do more of what you're passionate about, so we always aim to go above and beyond.
We build products like And Bang, our team collaboration app—and, in doing so, create new tools and techniques that help others do new and innovative work in their products. Disqus, for example, uses Thoonk as a critical piece of its realtime commenting architecture.
We build things and provide consulting for clients, including companies whose names we can't mention but who nonetheless you know well and whose products you're almost certainly attached to all day long.
The other day, DHH[1] tweeted this:
Forcing your web ui to be "just another client" of your API violates the first rule of distributed systems: Don't write distributed systems.
-- DHH (@dhh) June 12, 2012
In building the new Basecamp, 37signals chose to do much of the rendering on the server-side and have been rather vocal about that, bucking the recent trend to build really richly interrative, client-heavy apps. They cite speed, simplicity and cleanliness. I quote DHH, again:
It's a perversion to think that responding to Ajax with HTML fragments instead of JSON is somehow dirty. It's simple, clean, and fast.
-- DHH (@dhh) June 12, 2012
This morning I had an epiphany of sorts.
I received yet another recruitment message from a high profile tech company. I'm sure many of you receive lots of them, too. But this time, as I was reading the email, I realized that I can't think of a job offer that would convince me to walk away from my current employer.
Why? I work at a weird company. A company where most of us are pretty happy with our work, our co-workers and our employer most of the time. You see, at &yet, we have discovered that the keys to employee happiness are simple. They are not a set of HR tricks or esoteric geek benefits. Employees are humans, and the keys to our happiness are the keys to human happiness.
I believe that everyone is on this little planet for a reason and is 'wired' to be truly amazing at a handful of things (at least a handful, maybe more). Because of this feature of our existence, we are most likely to be happy if we are able both to discover and to do those things. The chances skyrocket if we can also do them with excellence, companionship, and appreciation.
Panic is on &yet's short list of Hero Companies.
We had the privilege of interviewing founders Cabel Sasser and Steven Frank shortly before Panic shipped their highly anticipated web development app, Coda 2.
Here's one segment in which Cabel is asked about building "minimum viable products".
Recently it was disclosed that the NPM registry leaked the usernames, salts and sha1 hashes of registry users. Essentially this amounts to a breach of about 4k user accounts.
The issue has since been taken care of and users are being asked (not forced) to change their passwords. The leaked data has been available for a very long time, probably since the registry has been using couch. Everyone should be resetting their passwords. Now.
I first found out and notified Isaac about this on 3/1/2012. I only found out about this because I was looking for potential ways that &! could be compromised.
One of the ways we build our development and production environments is by using npm to install packages. I was curious just how hard it would be to compromise the integrity of packages published to the registry, turns out not very. It’s great to point out however that npm is meant to be a distribution channel. It’s a free and open service in which anybody can distribute packages. It’s not meant to provide any level of integrity and quality checking. As developers we are responsible for the code that executes in our environments. Maybe checking verified packages into your projects repository isn’t such a bad idea after all.
&yet's ops and security guys hash it out in this latest vodcast.
Nathan Lafreniere talks about what's in his devops toolkit, his code deployment process, how ops can help maintain code quality, and his new documentation library, ape.
Adam Baldwin discusses his new Node.js header security library for express, helmet, a few headers that most apps should be including by default now, and some random bits about realtime security.
Fortunately for you this particular cut doesn't include Adam singing Russian Unicorn but it does feature a yeti and Adam doing what he would consider dancing.
When I was at FOSDEM last weekend, I talked to several people who couldn't believe that I would use Redis as a primary database in single page webapps. When mentioning that on Twitter, someone said, "Redis really only works if it's acceptable to lose data after a crash."
For starters, read http://redis.io/topics/persistence. What makes Redis different from other databases in terms of reliability is that a command can return "OK" before the data is written to disk (I'll get to this). Beyond that, it is easy to take snapshots, compress append-only log files, configure fsync behavior in Redis. There are tests for dealing with disk access suddenly cut off while writing, and steps are taken to prevent this from causing corruption. In addition, you have redis-check-aof for dealing with log file corruption.
Note that because you have fine tuned control over how fsync works, you don't have to rely on the operating system to make sure that operations are written to disk.