Ville Immonen:

JavaScript is evolving and new ES2015 and ES2016 editions (previously known as ES6 and ES7, respectively) pack a bunch of new features and Babel makes it very easy to use of them today. These features make some previously essential functions from utility libraries obsolete.

 there’s been an explosion of people and companies looking to do interesting things with their data. I’ve been lucky to work on dozens of data-heavy interfaces throughout my career and I wanted to share some thoughts on how to arrive at a distinct and meaningful product.

I’ve been doing a lot of data-driven interface work over the last few years and the advice in this article is spot on.

Michael Feathers:

It’s funny. I can’t count the number of times I’ve seen organizations with large monolithic software applications move toward SOA. It’s easy to think that we’ve learned a lesson in the industry and that services are just the new “best practice.” Surely we would’ve started with them if we were just starting development now. Actually, I think the truth is a bit more jarring. Different architectures work at different scales. Maybe we need to recognize that and understand when to leap from one to another.

The process space has similar issues. If we cargo-cult anything from the small team space into the large organization space, we’re falling prey to a blind spot. We’re missing an opportunity to re-think things and figure out what works best for small teams, interacting teams, and large-scale development. They may be quite different things.

I agree that the rules are different for different organisation sizes. I like Michael’s comparison of moving across organisation sizes to state transitions in physics.

Vsevolod Dyomkin:

At Grammarly, the foundation of our business, our core grammar engine, is written in Common Lisp. It currently processes more than a thousand sentences per second, is horizontally scalable, and has reliably served in production for almost 3 years.

Simon Marlow:

Haskell isn’t a common choice for large production systems like Sigma, and in this post, we’ll explain some of the thinking that led to that decision. We also wanted to share the experiences and lessons we learned along the way. We made several improvements to GHC (the Haskell compiler) and fed them back upstream, and we were able to achieve better performance from Haskell compared with the previous implementation.

Agile Tortoise:

Terminology for iOS is based on WordNet, a great semantic lexical reference. We do not offer a full Mac app for Terminology, but have prepared a dictionary using this same great data for use in the built-in OS X Dictionary app.

Brian Marick:

So, interesting: an enormous amount of effort is spent on apps that convert map/vector-structured data into map/vector-structured data.

However, because of the mindshare dominance of object-oriented programming that came because of Java - “Smalltalk for the masses” - it’s hard for most people to think of an approach other than a pipeline of structured data -> objects -> structured data. The tools and frameworks and languages push you toward that. So: a programming model tailored to objects with serious lifetimes has been used for data that lasts only for one HTTP request.

Dave Copeland:

We’ve given up on “fat models, skinny controllers” as a design style for our Rails apps—in fact we abandoned it before we started. Instead, we factor our code into special-purpose classes, commonly called service objects. We’ve thrashed on exactly how these classes should be written, so this post is going to outline what I think is the most successful way to create a service object.

Some good advice for building service objects in Rails.

Michael Snoyman:

As of today Front Row uses Haskell for anything that needs to run on a server machine that is more complex than a 20 line ruby script. This includes most web services, cron-driven mailers, command-line support tools, applications for processing and validating content created by our teachers and more. We’ve been using Haskell actively in production since 2014.

An experience report on using Haskell in production.

Tony Morris:

In this talk, I will explain to you how list folds work using an explanation that is very easy to understand, but most importantly, without sacrificing accuracy.

I particularly like the constructor replacement analogy for foldr.

Elisabeth Hendrickson:

I prefer:

• Recovery over Perfection
• Predictability over Commitment
• Safety Nets over Change Control
• Collaboration over Handoffs

Ultimately all these statements are about creating responsive systems.

When we design processes that attempt to corral reality into a neat little box, we set ourselves up for failure. Such systems are brittle. We may feel in control, but it’s an illusion. The real world is not constrained by our imagined boundaries. There are surprises just around the corner.

Dijkstra:

I have told this story to different audiences. Programmers as a rule are delighted by it and managers, invariably, get more and more annoyed as the story progresses; true mathematicians, however, fail to see the point.

Ron Garret:

The Lisp model is that programming is a more general kind of interaction with a machine. The act of describing what you want the machine to do is interleaved with the machine actually doing what you have described, observing the results, and then changing the description of what you want the machine to do based on those observations. There is no bright line where a program is finished and becomes an artifact unto itself.

RDX:

Having deployed a variety of Ruby apps (Rails and non-Rails) over the course of many years, here are some lessons I’ve learned to keep things afloat.

Yehuda Katz:

• In Rust, as in garbage collected languages, you never explicitly free memory
• In Rust, unlike in garbage collected languages, you never explicitly close or release resources like files, sockets and locks
• Rust achieves both of these features without runtime costs (garbage collection or reference counting), and without sacrificing safety.

This post contains a nice summary of Rust’s ownership model.

Dorian Taylor:

If 90% of every­thing is crap, the obvious strategy should be to produce as much crap as you can afford, because the other 10% will be spectacular.

Scott Wlaschin:

But now we have something much more abstract, a set of generalized requirements that can apply to all sorts of things:

• You start with a bunch of things, and some way of combining them two at a time.
• Rule 1 (Closure): The result of combining two things is always another one of the things.
• Rule 2 (Associativity): When combining more than two things, which pairwise combination you do first doesn’t matter.
• Rule 3 (Identity element): There is a special thing called “zero” such that when you combine any thing with “zero” you get the original thing back.

With these rules in place, we can come back to the definition of a monoid. A “monoid” is just a system that obeys all three rules. Simple!

…

To sum up, a monoid is basically a way to describe an aggregation pattern – we have a list of things, we have some way of combining them, and we get a single aggregated object back at the end.

The first of three posts that give a simple definition of what monoids are and the benefits they provide.

The more Google pushes the sophistication of its web development tooling, the more we all benefit.

Paul Ford:

I erased most of my TODO list since I really only need to stay alive and listen to people and everything else is a lie.

Martin Fowler:

Kent Beck came up with his four rules of simple design while he was developing ExtremeProgramming in the late 1990’s. I express them like this.

• Passes the tests
• Reveals intention
• No duplication
• Fewest elements

Loup:

Object Oriented Programming died several times already. This time might be the last.

Nevan King:

In iOS 8, this code doesn’t just fail, it fails silently. You will get no error or warning, you won’t ever get a location update and you won’t understand why. Your app will never even ask for permission to use location.

I just got bitten by this while updating an app. This post goes through what is needed to fix it.

Michael Johnston:

You cannot build a 60fps scrolling list view with DOM.

The Flipboard team have gone to great lengths to get the performance they want from the browser.

Everything is rendered to canvas elements. They’ve created their own representation of elements which they pool aggressively to avoid GC hits.

This is another place where React’s virtual DOM comes into its own. Flipboard use React to render to canvas elements. They’ve wrapped this up into react-canvas.

This is an extreme approach but the app feels slick because of it.

Bob Nystrom:

When they create 4089 libraries for doing asynchronous programming, they’re trying to cope at the library level with a problem that the language foisted onto them.

Each of those function expressions closes over all of its surrounding context. That moves parameters like iceCream and caramel off the callstack and onto the heap. When the outer function returns and the callstack is trashed, it’s cool. That data is still floating around the heap.

The problem is you have to manually reify every damn one of these steps. There’s actually a name for this transformation: continuation-passing style. It was invented by language hackers in the 70s as an intermediate representation to use in the guts of their compilers. It’s a really bizarro way to represent code that happens to make some compiler optimizations easier to do.

No one ever for a second thought that a programmer would write actual code like that. And then Node came along and all of the sudden here we are pretending to be compiler back-ends. Where did we go wrong?

Red and Green callbacks:

It’s actually worse, every Javascript programmer who has a concurrent problem to solve must invent their own concurrency model. The problem is that they don’t know that this is what they are doing. Every time a Javascript programmer writes a line of code that says “on this do that” they are actually inventing a new concurrency model, and they haven’t a clue how the code will interleave when it executes.

What’s even more difficult to understand is errors. Errors in multi-threaded callback code with shared memory is something that would give me an extremely large headache.

The in-language mixing of synchronous and asynchronous calls makes code hard to reason about. The language-side simplicity of Ruby or Java’s concurrency model is something I have taken for granted.

Michael Feathers:

I strongly believe that there is a law of conservation of complexity in software. When we break up big things into small pieces we invariably push the complexity to their interaction.

Adam Wiggins:

Make it real

Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don’t say you did something, provide a URL that proves it.

Plenty more great stuff in there.

Mike Caulfield:

Wiki is a relentless consensus engine. That’s useful.

But here’s the thing. You want the consensus engine, eventually. But you don’t want it at first.

It’s funny, I was looking over this keynote last night, and I saw this line and realized — this is the simplest explanation of federated wiki.

James Clear:

In my opinion, this is the greatest success “hack” there is. If you live in an environment that nudges you toward the right decision and if you surround yourself with people who make your new behavior seem normal, then you’ll find success is almost an afterthought.

Systems are better than goals.

Tom Stuart:

Monads are in danger of becoming a bit of a joke: for every person who raves about them, there’s another person asking what in the world they are, and a third person writing a confusing tutorial about them. With their technical-sounding name and forbidding reputation, monads can seem like a complex, abstract idea that’s only relevant to mathematicians and Haskell programmers.

Forget all that! In this pragmatic article we’ll roll up our sleeves and get stuck into refactoring some awkward Ruby code, using the good parts of monads to tackle the problems we encounter along the way. We’ll see how the straightforward design pattern underlying monads can help us to make our code simpler, clearer and more reusable by uncovering its hidden structure, and we’ll end up with a shared understanding of what monads actually are and why people won’t shut up about them.

The accompanying video is short, snappy, and to the point.