&yet

It's one thing to have a web application in production that requires active monitoring (you are monitoring it right?), but it's another issue completely when that web application contains a "contact us" form. All good teams will use various tools to gather emails so they can manage their subscriber lists appropriately, and that's the rub; what happens when code changes in the app that impacts the form?

Nothing – why? Because you will be blissfully unaware your form is failing unless you test it.

Testing a web form is what we are going to demonstrate using Python and the Mechanize library. Mechanize allows you to load a page, inspect any forms on the page and then manipulate the form just as a user would.

Let's see some code!

Last month at JS.LA, Internet "Luke" Karrys gave a great introduction to Ampersand.js.

Ampersand.js is a highly modular, loosely coupled, non-frameworky framework for building advanced JavaScript apps.

We'll let Luke explain:

Last week, Google Chrome started to support the next generation video codec VP9 for WebRTC (which is highly experimental in the developer version and you need to enable it, so the ETA for this is probably going to be mid-2015). That is good news because VP9 is going to offer better video quality at the same bandwidth (another way to look at it is that VP9 gives you the same quality at lower bandwidth, although at the expense of computational power, i.e. your mobile device gets warmer).

I immediately wanted to implement and test the feature, if only so I could add Chrome 41 to the long list of versions that I managed to crash. However, this turned out to be harder than it initially seemed.

Let me try to explain the issue with an example of a videochat that has three participants, two of which support VP9: Suppose that those clients use an XMPP MUC for having the conference, supported by an SFU like the Jitsi videobridge (which is what we do in the next version of Talky). The browsers announce their capabilities ("I implement VP8," "I implement VP9," a Firefox browser might even do H.264 and VP8) through Entity Capabilites when joining the MUC.

So the first two browsers know they both implement VP8 and VP9 and use that list of codecs when calling the RtpSenders .send method for the first time. That RtpSender object is another improvement that came from ORTC. If everything goes well, they will enjoy the superior quality of VP9.

Articulating our decision making is a huge part of our jobs as designers. Every day we should be asking ourselves “Why did I decide to do it this way?” Our coworkers, clients, and users will be asking the same question, so we may as well be prepared.

Everything we add or leave out is the result of decision making. Sometimes we’re called to explain decisions around entire layouts and other times it’s just the exact shade of grey we chose for a horizontal rule. Big or small, it’s important to understand why we land on the solutions we do.

Below are six common decision patterns I’ve seen in my time as a designer. Note that these aren’t specifically ordered and I’m not suggesting any one is best. It’s important first to recognize our behavior before deciding what makes the most sense for our project which, as always, depends.

Decisions made by other people

Eons ago when our story first began, I told you how I needed to make a client app more consistent and efficient by implementing optimistic concurrency and JSON Patch in our model layer.

As I said before, in our app, we combine both of these forces for an efficiency and consistency one-two punch. As I worked through the integration and some other requirements, I realized that a third module that combined the previous two and added some sane defaults for conflict resolution would be really helpful, so I built one. It's called ampersand-model-optimistic-update-mixin. Say that five times fast, or just call it AMOU (pronounced "ammo").

What it does

Let's recall our good buddy Franco from last time, and suppose that his data is edited by two different people working from the same base version:

A core tenet of any Operations Team is that you must enable developers to change their code with confidence. For the developer this means they have the flexibility to try new things or to change old, broken code. Unfortunately, however, with every code change comes the risk of breaking production systems, which is something Operations has to manage. A great way to balance these needs is to continuously test new code as close to the point of change as possible by reacting to code commits as they happen.

At &yet the majority of the code that is deployed to production servers is written in NodeJS, so that's the example I'll use. NodeJS uses npm as its package manager, and one aspect of npm is its ability to define scripts that are to be run at various stages of the package's lifetime. To make full use of this feature we need a way to run the defined scripts at the point that a developer is commiting code, as that is the best time to do validation and testing of the newly changed code.

Fortunately an npm package exists that will do just that - precommit-hook. It installs the required pre-commit hook into your project's .git metadata such that just before git actually performs the commit, it will run the defined set of scripts or run the lint, validate, and test scripts by default. We can use this to run any check we need, but for now I will describe how to run a script to scan the project's dependencies for any known security vulnerabilities using retire.js.

First we need to add retire.js to the project's package.json and add a reference to it so the pre-commit hook will run it:

Microsoft recently announced they will support Object RTC and now everyone is talking about ORTC and how they will support it.

What is this all about and what is ORTC anyway?

In essence, ORTC is an alternative API for WebRTC. It is object-oriented and protects developers from all that ugly Session Description Protocol (SDP) madness. Some people call it WebRTC 1.1, or maybe WebRTC 2.0.

So... will &yet (and Otalk) (and Talky) support ORTC? Of course!

The most important job of a leader is to listen and listen well. What sets a great leader is her willingness to give of her time and energy. And although listening requires a large amount of both time and energy, it makes people feel valued and needed, a goal which all leaders should aspire to.

Leaders need to have–or learn to develop–the humility it takes to truly listen. Not just to hear what people are saying directly, but to be an investigative listener, to pay attention and discover things in the organization that may be unseen, whether they be positive and negative. And if you do uncover a dark, hard problem, fear not! Chances are good that the solution is shrouded in wisdom which will serve you well in the future.

What other good can you do by listening? Well, the list is probably way longer than this, but here are a few gems I've discovered along the way. I'm sure you'll find your own treasure, too.

• You create and build trust
• You learn to trust the team
• You build confidence
• You discover and support people's passion for their own personal growth
• You inspire collaboration
• You empower the PEOPLE

Today's entry: Building the Mixins!

This post is second in a three part series that I started with a little bit of background last week.

Building the optimistic concurrency mixin

Following the Human way, I made the optimistic concurrency mixin a CommonJS module and published it with npm. It's called ampersand-optimistic-sync, but we'll call it AOS here. AOS replaces the sync method on your Backbone or Ampersand models. Since sync is the core Ajax method, extending there allows AOS to read and write the versioning headers it needs.

"If you don't monitor it, you can't manage it."

In the last installment of our Tao of Ops series I pointed out the above maxim as being a variation on the business management saying, "You can't manage what you can't measure" (often attributed to Peter Drucker). This has become one of the core principles I try to keep in mind while walking the Operations path.

Keeping this in mind, today I want to tackle testing the TLS Certificates that can be found everywhere in any shop doing web related production - something that needs to be done and can be rather involved in order to do properly.

According to Wikipedia TLS Certificates are: