Blog

● posted by Stephanie Maier

We are very excited to announce that the iOS app for Talky is now available for download on the App Store.

(Can I get a woohoo?)

Take a quick look

You’ll use the same approach to starting a conversation as Talky on the web.

One quick tap and you’ll be able to copy the room’s URL, or just click the “+” and send an invite via text or email.

In addition to other iOS users, the people you invite can use Talky on Chrome, Firefox, or Opera on the desktop, or on Chrome or Firefox on Android devices.

(Unfortunately, we regret to inform you that not all Talky conversations will feature the most delightfully amazing Leslie!)

The rest of the story

Not long ago, in January 2014, the conversation around integrating iOS with WebRTC started to gain momentum here at &yet.

With the addition of Peter Saint-Andre, formerly an architect on Cisco’s WebEx service and an area director at the IETF, and WebRTC expert Philipp Hancke to our team, we were poised to take Talky development to the next level.

When we first released Talky in 2013, it was already solving a big problem for our team. Talky gave us the ability to communicate more naturally and effectively, especially as a distributed team. It was originally a demo for SimpleWebRTC, a Javascript library you can use to quickly build apps like Talky. But we had no idea how well it would be received. Talky continues to steadily grow and we love hearing from all our users.

The initial prototype for Talky iOS was created by &yet’s quietly awesome iOS developer, Jon Hjelle. Who, if you know well, was quite displeased with the mention of his name in this blog post. (Hjon, please accept my most sincere apologies!)

The final Talky iOS app was completed in partnership with Steamclock Software. The dev team at Steamclock polished the prototype through some major changes to the WebRTC library, including the very important addition of resilient video support. The end result is a more featureful app and delightful user experience.

The iOS app also paves the way for our forthcoming Talky Pro service, which will give users the same experience as Talky, but optimized for business, complete with personalized branding.

Talky is built on top of the Otalk platform, a suite of completely open and standards-based tools for making modern communication a delightful experience for developers and users alike.

As a team we’re excited about WebRTC and its future contributions to open communication.

If you have a WebRTC project you think we could help with, we’d love to hear about it.

Just want to chat? We’d love to hear from you, too! =)

● posted by Henrik Joreteg

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

Why!?!

We <3 Backbone.js at &yet. It’s brilliantly simple code and it solves many common problems in developing clientside applications.

But we missed the focused simplicity of tiny modules in node-land. We wanted something similar in style and philosophy, but that fully embraced tiny modules, npm, and browserify.

So we made Ampersand.js, a well-defined approach to combining (get it?) a series of intentionally tiny, and loosely coupled modules for building JS apps.

Post-Backbone

Backbone has been praised for its flexibility and simplicity. The fact that Backbone’s author Jeremy Ashkenas and his fellow maintainers haven’t tried to solve every problem has kept it usable for a broad range of application types. Its effectiveness is evidenced by its incredible popularity.

I built my first Backbone app when it was still version 0.3.1, and our whole team has been an avid users/supporters of the project for quite some time. I even got a chance to speak at the first BackboneConf.

Philip Roberts, who has built a big portion of Ampersand.js, got a lot of experience building an incredibly complex Backbone app at his previous company Float. He certainly pushed Backbone to its limits in building complex spreadsheet-esque accounting tools for the web.

Not long after discovering Backbone at &yet, we got really into node.js, which brought with it a module approach and what became an awesome way of managing dependencies that we’ve have fallen deeply in like with: npm.

Nothing has done more for our team’s ability to write clean, maintainable clientside applications than having a really awesome dependency management system and substack’s browserify that allows us to quickly declare/install external dependencies and know that things will Just Work™.

npm has also been the catalyst that enables what has been referred to as the “tiny modules movement”, the basic philosophy of which is that no matter how small or insignificant the problem, you shouldn’t have to solve it more than once.

By giving a module narrow scope and functionality you can actually maintain it without going insane. Also, knowing about and fixing gotchas in a single location means that all modules depending on it also benefit.

After getting addicted to this way of working, many developers, ourselves included, have developed an allergic reaction to libraries and plugins that don’t work that way. Unfortunately, despite its lightweight, flexible approach, Backbone itself doesn’t follow that pattern.

“What? I thought you said Backbone was flexible and modular?”

Yes, but only to a point.

“But, Backbone is on npm!”

Yes, but stay with me…

One of the problems we’ve had at &yet especially when working on large Backbone applications is a sane way to document the type of properties a model is supposed to contain.

Backbone models, by default, don’t enforce any structure. You don’t have to declare anywhere what properties you’re going to store. As a result, people inevitably start saving miscellaneous properties on models from within a view somewhere, and there’s no good way for a new dev starting in on the project to be able to read the models and see exactly what state is being tracked.

To solve this problem and to enforce additional structure, I wrote a replacement model called “HumanModel” that is consistent with the philosophy explored in depth in the book Human JavaScript. This model, which has now morphed into ampersand-model, forces you to declare the properties you’re going to store, and also allows you to declare derived properties, etc.

Originally we used our replacement models within Backbone Collections, but we started running into problems. Backbone generally assumes that you’re storing Backbone.Model models in collections. So when adding an instantiated model to a collection, Backbone would fail to realize that it’s already a model. My patch to Backbone was merged and fixed this, but there have been other areas where we’ve wanted more flexibility.

For example, at times we wanted RESTful collections where data is coming from an API, but other times, we just wanted something like a Backbone collection/model system for managing state in another module, that perhaps had nothing to do with getting data from a REST API. In those cases we didn’t want to make all of Backbone a dependency of our module, just to get evented models.

Over time while building a ton of apps with it, for clients and for ourselves, we’ve kept running into these same types of problems that we attributed to the coupling/bundling of Backbone.

So we started ripping things apart into their own independently published, managed, and versioned modules.

Thus, Ampersand.js was born.

Ampersand.js splits things apart as much as possible. For example, ampersand-collection makes no assumptions about how you’re going to put data into it, what types of objects you’re going to store, or what indices you’re going to want to use to retrieve them. It follows the tiny module pattern.

But, what if you want that stuff?

Well, that’s easy, we just have another tiny module that layers in that functionality.

There’s a RESTful ampersand-rest-collection we just pre-bundle and publish it as a module for convenience, the code that combines them is hilariously simple.

You see the exact same pattern in ampersand-state and ampersand-model. “State” is the base object that “model” is built on. But model goes the additional step of including the RESTful methods.

So what exactly is Ampersand.js? What makes it unique?

In starting to toy with the concept of building out these tools, we wrote a few guiding principles, some of which we’ll no doubt get some flack for. Here they are:

1. Everything is a CommonJS module

No AMD, UMD, or bundling of any kind is included by default. The clarity, simplicity, and flexibility of CommonJS just won. Clear dependencies, no unnecessary wrapping/indenting, no extra cruft. Just a clearly declared set of dependencies in package.json.

Any sort of bundling for any other module system is easy enough to do with any number of tools like grunt or gulp.

2. Everything is installed via npm

This isn’t a diss toward the other package management approaches, it’s just a choice to maximize simplicity. Especially given point #1.

3. Modern browsers by default

We’re unapologetically supporting only IE9+. There are many features of ES5 that enable dramatic simplifications of code that simply were not present in IE before IE9. For reference, check out kangax’s ES5 compatibility table. Not having to shim each and every feature and completely avoiding non-shimmable ones saves you so many headaches that we decided to just draw that line. Bring the haters :)

But again, remember this isn’t an all-or-nothing “framework”. In fact, very arguably it’s not a framework at all. There are pieces here that don’t require IE9 and others that could be converted to solve those problems if they matter to you. It’s just a line we chose to draw in the sand so we could focus our efforts on building for the web’s present and future instead of its past.

4. Strict semver all the things

If you’re unfamiliar with semver, the semver homepage summarizes it in about three sentences. In short, it’s a strict adherence to a versioning scheme for modules that, if followed, allows you to trust minor and patch version updates to not break your code. So, for a dependency you can specify a version like this: “^1.1.0” and know that your code will not break if the underlying dependency is upgraded from 1.1.0 to 1.2.8 because the versioning scheme prohibits breaking changes without bumping the major version number.

This flexibility is very important in clientside code because we don’t want to send 5 different versions of the same dependency to the browser. Loosely declaring dependencies of the building blocks and strictly declaring them in your app’s main package.json can help you avoid a lot of these problems. Combining the way npm manages dependencies with this approach, we can get minimal duplication of shared dependencies.

5. Tiny module all the things!

The smaller the feature set of the low-level modules, the easier it is to avoid breaking changes. Higher-level modules should still exist, but, should primarily be pulling together small modules in a way that makes them more usable. For example: ampersand-rest-collection, component’s “events” module, or component’s “classes” module.

6. Expose the simplest API possible.

Simplicity is a core value. If you don’t actively fight for simplicity in software, complexity will win, and it will suck. This means things like pruning unneeded features and giving everything descriptive names even if they’re longer. That’s what minification is for. We are not compilers, so we should optimize for readability and use tools for optimizations.

While this is going to be a bit controversial, for us the focus on simplicity also means avoiding using promises. There are enough things that are new and intimidating to those building clientside apps. Adding promises makes for an unnecessarily tall cognitive leap.

Not that promises are bad, but the truth is there isn’t as much need for complex flow-control for most clientside things.

And, if you want to use promises it’d be easy enough to write a version of ampersand-sync or ampersand-router that used bluebird or another promise library and slip that into your app.

That’s the whole point of the modularity concept and still: you only include what you ultimately are using!

7. Optimize for minimal DOM manipulation and performance.

It should be easy to create rich user experiences.

There’s a lot of buzz and talk around rendering performance for JS apps. Mostly the answer to these types of performance issues is: “Don’t touch the DOM any more than you have to.”

That’s one of the core premises of libraries like Facebook’s React: only performing minimal changes and batching those changes into RAF loops.

**note: You could very easily use React with Ampersand.js, btw.

In canonical Backbone apps you often re-render the contents of a view if the related model or models change. But, if you’re trying to do things like smooth dragging and dropping, you don’t want to re-render contents of a view each time properties change. Or even if you’re using CSS3 transitions, re-rendering a section of the DOM and adding a class won’t ever trigger the CSS3 transition, because it wasn’t actually transitioned, it was just replaced with another piece of DOM that had that class. So, pretty soon in those scenarios you find yourself writing a bunch of “glue code” to bind things to the DOM and only perform minimal edits.

The point is, there are valid uses of both approaches. So the goal with ampersand-view is a simple way to declare your bindings in your view code. Check out the declarative bindings section of the docs.

You can also just mix and match. In certain cases it may be easier to re-render everything, but declaring very specific binding behavior is also simple without tying you to a template system. It gives you ultimate control. Modularity FTW!

8. Mobile is in the DNA

Think small and light. Optimize and build tools for touch interfaces. Help build the web as the go-to platform for mobile. (You can expect more tools to be released here in the future toward this end.)

9. Unapologetically designed for rich “app” experiences.

These ain’t no websites, pal. If you’re building content sites or sites you want thoroughly crawled this is not the tool for you.

This is for clientside JavaScript applications where the browser is treated as a runtime, not as a document viewer. For more on that, you can read about how we believe the web has outgrown the browser.

10. Embrace offline-first mentality and ServiceWorker all the things as soon as we can.

Yup. These are apps, they should compete with native apps. The thing that’s missing for web to truly be a viable alternative to native apps is good tools for building offline web apps. Again, for more on that read the post mentioned above.

But the point is, in order for an app to work offline it needs to be a true self-contained JavaScript app so that it can run entirely in the client. Since that’s how Ampersand.js is aimed to work, it would be a nice compliment to an offline-first backend like hood.ie.

11. Everything is MIT licensed

Software licensing can suck. Especially when trying to manage licenses of dependencies for a large enterprise project. Picking MIT for all of this stuff simplifies things as much as we can.

12. Love the developer

Don’t ignore developer workflow! We’ve got a few nice things you can see in the app the cli builds that let you simply flip a “developmentMode” boolean to put your app into a live-reloaded, unminified mode, or conversely into a production mode (more below).

The problems with tiny modules

It’s not a silver bullet. One of the biggest challenges for the “tiny module approach” is knowing which tiny modules exist and which ones to use. This can be quite daunting for someone who’s used to grabbing a few jQuery plugins and is new to all of this.

Most of the tiny modules are, well… tiny. These are small pieces of code, not heavily marketed because they’re not necessarily the pride and joy of the developer. Many of them are rather boring and don’t do very much, plus they’re infrequently updated and often they even look unmaintained because frankly, they represent a solved problem that doesn’t need to be re-solved!

Seriously, having published a ton of tiny modules, I sometimes forget about my own modules!

This can make it incredibly hard to get started and this is where frameworks really shine.

So, we’re doing a couple of things to solve that problem for ourselves and others building Ampersand.js apps.

  1. A better starting point: The ampersand cli is a scaffolding tool. It helps you build out a fully working starter app including a hapi or express node server to serve your application. It includes patterns and approaches that we use at &yet for structuring and serving single page apps which we’ve defined in Human JavaScript.

  2. The tools site: tools.ampersandjs.com. This is a site with quick-searchable, hand-picked tools for building Ampersand-style apps. A grab bag of “solved problems” for single page apps, if you will. In addition it updates its url as you search so it’s deep linkable. For example, if you’re looking to do WebRTC stuff: http://ampersandjs.github.io/tools.ampersandjs.com/?q=webrtc

  3. A book describing the philosophy: If you’re looking for deeper explanations of the philosophy and approaches used in the generated app, those are described in a lot more detail in my book Human JavaScript, which along with releasing the framework, we’ve now made available to read online for free.

Massive props to Jeremy Ashkenas and the rest of the Backbone.js authors

Many of the individual modules contain copy-and-pasted code from Backbone.js.

We’re incredibly grateful for Jeremy’s work and for the generous MIT licensing that made Ampersand.js possible.

The future

There’s still a lot to do.

Now that we’ve removed our dependency on Backbone we’re free to edit other things in “core” that we’ve had alternate ideas about.

With the flexibility that comes with the tiny modules approach, it’s easier to do a lot more exploration without having to change core items.

A few examples:

  • domthing - Philip Roberts has built an incredibly awesome DOM-based templating language and a mixin to work with Ampersand.js.

  • bind-transforms - A way to elegantly bind styles like CSS transforms to models. In combination with the cached, evented, derived properties of ampersand-state let’s you build amazing things, like smooth drag-n-drop views.

  • ampersand-forms - A set of tools for building rich, interactive forms.

We’d encourage you to get involved.

For simplicity all the “core” stuff is on Github as its own organization: https://github.com/ampersandjs.

Send pull requests, file issues, and tell the core team that we’re crazy on twitter: @HenrikJoreteg, @philip_roberts, @lynnandtonic, @lancestout, @lukekarrys, and @wraithgar.

For more cool stuff, follow the whole @andyet team on twitter.

Learning even more

To learn more about building advanced JavaScript applications that are as maintainable as they are awesome learn directly from the folks behind ampersand at our bound-to-be-memorable upcoming training adventure — JS for Teams: “It’s Aliiive!”

● posted by Sarah Bray

JS for Teams: It’s ALIIIIVE! is a two-day training adventure happening July 24 & 25 focused on teaching teams how to build advanced single-page apps in a highly maintainable way. Tickets on sale today!

To celebrate, we’re offering $200 off per ticket for the next 5 tickets – use the discount code AMPERSAND at check-out.

The tickets we set aside for our email subscribers already sold out, so don’t miss your chance. Seats are extremely limited.

Enroll now

● posted by Adam Brault

Is there an inherent business risk in letting your top JavaScript developers do their best work?

(What a painful thought!)

It’s one thing to build with the latest tools and techniques, but what happens when the developers who led the way on a given app move on to greener pastures?

JavaScript apps are notorious for being largely written by one “rockstar,” ending up dominated by the most experienced JS dev, the most charismatic person, or at least by the fastest typer.

And the first thing the people who inherit an app want to do is undertake a costly rewrite.

How do you overcome that tendency?

The problem isn’t devs doing their best work. It’s that the software they work on will outlive their attention span and maintenance capability.

So, are JS frameworks the answer?

One key reason enterprises choose highly constrained tools for building with JS: less room for the kind of creativity and innovation that makes a single developer’s work capable of being both high return and high risk.

But tools like those can also disengage veteran JS developers who prefer flexibility and modularity.

In my years of experience working with and managing developers, I’ve learned that developers who are mentally engaged are most capable of amazing work. And developers who are engaged in their work have a stronger desire to keep doing it.

It’s a tradeoff: the risk of losing (or depending on) a very good developer is often mitigated by the same tools that increase the likelihood they will leave—or mentally check out.

The tools that tend to make collaboration and consistency easy can leave very good developers hamstrung.

Learning a framework provides a lot of instant gratification, but we’ve seen frameworks and approaches come and go as the web has rapidly evolved.

Developers who end up learning a framework instead of how to solve problems in JavaScript can limit their long-term potential.

What’s more, JavaScript does not lend itself well to one-size-fits-all frameworks. There are certain types of apps that make sense for certain frameworks, but it’s undeniable that no JS framework is a panacea.

So how do we solve this problem at &yet?

I’d love to say we’ve had this down for years, but we actually stumbled upon the answer.

Our first Node.js based single-page app product, And Bang 1.0, was built largely by Henrik Joreteg and myself; I wrote the CSS and Henrik wrote the rest of the app, both server and client.

At a certain point, we decided to do a major refactor, creating And Bang 2.0.

While building the API for And Bang 2.0 was a full-team effort, getting people involved in the JS app proved tremendously challenging. Folks could contribute to parts of the app, but in the end, it was fully dependent on Henrik because not enough of our team understood the approaches Henrik was taking in building the app.

This presented a huge long-term risk. It wasn’t good for the team, and it certainly wasn’t good for Henrik. We all knew action was needed.

At one point, I recall a few of us taking Henrik out to a really painful lunch.

We told him that despite being the most productive developer on the project, he was no longer allowed to write JS on the app. He could only open issues, write documentation, and educate.

Soon, Henrik’s work documenting the approaches he’d taken on the app sparked involvement from others on the team. Things rapidly got clearer, easier to understand, simpler, more consistent.

The conversations that emerged resulted in many of the philosophies and conventions he eventually explained in his book, Human JavaScript.

Then something amazing started happening.

Where we had previously experienced frustration getting people onboarded in working on our advanced JS apps, we suddenly started to find that from veterans to new developers, these apps “made sense,” and it started to look like collaboratively authored code was the work of one person.

Our team has loved working this way.

Here’s what Philip Roberts said in his first day working on one of our JS apps: “This code is a dream. This is the most organized and understandable codebase I’ve ever seen.”

We released Human JavaScript a year ago to great acclaim beyond our team.

We’ve since decided to follow it up with a highly experiential and interactive training that goes even deeper than Human JavaScript.

JS for Teams: It’s Aliiiive will provide a comprehensive training on the approaches we’ve developed over the course of years.

JS for Teams will help your team build complex but maintainable single-page applications with a modular JS approach.

Registration is extremely limited. Tickets are now on sale. Don’t miss out!

P.S. If you’re interested in custom JS for Teams training for your organization, reach out to us at training@andyet.com.

● posted by Philipp Hancke

A few months ago, WebRTC agitator and yeti-friend Chris Koehnke wrote an excellent blog post explaining that browser-based videochat won’t work 100% of the time without a little help from something called a “TURN Server”. As he put it:

If you're going to launch a WebRTC powered service for financial 
gain, then you need to have done everything within your power to
ensure it works reliably across as many cases as possible.

Chris was satisfied when a few simple tests worked and stopped after that. Well, he skipped the next step.
But that’s reasonable because he was probably bored already (does anyone get excited about TURN servers?) and he doesn’t run a WebRTC powered service himself.

The next step is looking for cases where things did not work and figure out what we can do about it. But hey, we run a WebRTC service called Talky and connection failures are frustrating, so we decided to dig a little deeper.

First, we discovered that there were still browser bugs lurking here.

In Firefox, TURN support didn’t work on Windows at all. This was fixed in less than 24 hours after we reported it, and will be part of the upcoming Firefox 30.

Reporting bugs obviously helps. But seriously, with 300 WebRTC “vendors” out there none of them noticed this?
Maybe no one runs Windows anymore? ;-)

In Chrome, if the attempt to establish a TURN/TCP connection failed (yes, there are networks where port 80 is blocked!), the JavaScript layer was never informed of that fact. It took a little longer between our initial report and the fix, but again the responsiveness of the team was pretty awesome. Not for the first time.

With those bugs fixed, we got to thinking: once we know that a peer-to-peer connection does not work, is there a way to determine why and tell the user about it? It turns out that the information we get from the browser is sufficient to determine whether you can make a connection with any of our TURN servers. When the browser tells us that the connection fails, we can compare the information we receive from both you and your peer. This enables us to determine which network is responsible for this failure - which enables you, dear user, to take action.

Admit it, you’re bored too, aren’t you?

Well, here’s the exciting part.

Yes, it’s frustrating that sometimes Talky may still fail to establish a connection between you and your peer (currently less than 5% of calls). However, as of today Talky tells you that things have failed, and also tells you which end of the connection is the likely culprit. Plus we’ve improved the help page to describe some steps you might take to make it work.

Which means today the Internet just might be a slightly happier place than it was yesterday. :-)

● posted by Jenn Turner

Our partners in the opposite of crime ^Lift Security, are proud to welcome their newest member to our team, builder and breaker of things, Tom Steele.

Besides having the coolest name ever, Tom brings his knowledge of varied languages, passion for open source work, and a strong desire to help empower developer communities through security education and collaboration.

His experience creating the open source project Lair as well as his early enthusiasm and contributions for the Node Security Project are just two of the many reasons we’re glad he joined the ^Lift team.

We’re very excited to have Tom onboard, and for all of the awesome things he’s going to do with the team to help push ^Lift Security to the next level.

● posted by Jenn Turner

Last October, Mike Speegle introduced us to the world of the Tech Republic and the narrative behind RealtimeConf 2013 in his novel, “Something Greater than Artifice.” The book is now available in its entirety for free download at RealtimeConf.com.

Download your copy on Kindle, ePub, or PDF before Monday, May 5 when it will only be available for purchase on Amazon.

If you haven‘t explored the world of “Something Greater than Artifice” here’s what people are saying:

“[Something Greater than Artifice] examines in a new way the implications of our use of technology, while still remaining hopeful–something that is often forgotten in futuristic novels.”

“Allegory is a beautiful tool to help us understand reality and Mike has employed it masterfully.”

“I enjoyed immensely, and will definitely read again.”


Remember, free downloads end Monday, May 5!

● posted by Adam Brault

We are thrilled to release “Something Greater than Artifice”, a tremendous work created by our friend and colleague, Mike Speegle. It’s now available on all kinds of media. (The beautiful cover was designed by Amy Lynn Taylor.)

Mike put months of effort into the first half of the novel, which was released in serial form in advance of RealtimeConf, where the story was concluded as a live stage play.

Immediately after RealtimeConf, Mike went to work concluding the novel. The ending has so much more than was visible in the play at the conference. I highly recommend reading it.

The conclusion is so dramatically powerful that it brought me to tears each of the times I read it while providing feedback on Mike’s drafts. More than that, it’s timely for all the pain and problems that exist within the tech community (heck, even the world).

It really was a privilege to get to work alongside Mike as an encourager and collaborator as he created this incredible work.

So why would &yet put so much investment into a novel? I tried to answer that question in the book’s foreword:


The web isn’t for web developers.

It’s for everyone.

But those of us who consider ourselves “from the Internet” have an important role to play.

My friend Jan Lehnardt has put it well: developers have power as great as alchemy—we truly create gold from inexpensive materials, primarily applying only knowledge of technology.

What will we do with that ever growing power?

Our company, &yet, believes that the world of the future can be one of greater humanity, creativity, kindness, generosity, and freedom—but the same tools at hand to create a better world are the same ones we may wield to ever more efficiently make it worse.

This novel is a call for pragmatic idealists to make a difference in the small ways that really matter.

There is always something greater.

We can be something greater than the small, selfish, fearful version of ourselves.

Our relationships can be something greater than pettiness, jealousy, comparison, and competition.

Our organizations can be something greater than machines that turn humans into crushable, expendable cogs.

And no matter how hopeless or impossible things might seem, there is nothing ever stopping us from making things better than they are right now.

I am incredibly proud to have played a small role in this beautiful piece of art Mike has created. From the very beginning, I have been blown away at the story he has woven from the bizarre set of thoughts initially presented to him. Allegory is a beautiful tool to help us understand reality and Mike has employed it masterfully.

I am additionally grateful to the people who inspired and gave life to these characters, most especially Mike himself, Alana Henderson, and Eran Hammer.

I hope you read this work and ask yourself: “What’s something greater for me?”

● posted by Jenn Turner

RealtimeConf may be over, but now the experience can live on somewhere other than in the hearts and minds of the people who were there: RealtimeConf.com.

Over the past few months, our team has collected memories from the ambitious event, recorded the original music featured there, and discovered the fates of Ros and Gregor in the phenomenal conclusion to Mike Speegle’s novel, Something Greater than Artifice.

We’ve even started planning our next epic adventure, JS for Teams, sign up here to find out about pre-registration.

It was a long road to the Tech Republic, so we hope you enjoy the trip down memory lane, and that you’ll join us on our future treks around the universe.

● posted by Adam Baldwin

In just a few weeks on April 30th, the ^lift security team will host their first secure development training on building secure Node.js web applications in Portland, Oregon.

The ^lift team has designed this training to help you understand the security challenges you will face when developing Node.js web applications and help you build habits that turn security from a worry or an annoyance, into a comfortable part of writing your code from the very beginning.

Seats at this first class are extremely limited, so grab your spot with the team that’s been trusted to secure tools you use everyday like npm, Github and Ginger, as well as leads the Node Security Project. Also discounted tickets are available if you want to bring your dev team (or hack the system and bring a couple friends, we won’t tell anyone).

If you can’t attend this training and you would like the ^lift team to bring it to your area, or even bring it to your dev team, please let us know by sending an email to training@liftsecurity.io

Tickets! Tickets! Get your tickets now!