I’ve used the term *Feature Factory* at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

How do you know if you’re working in a feature factory?

Many developers have been voicing their concerns about Agile being broken lately. Among them are prominent figures like Robert C. Martin and Kent Beck – two of the people who charted the Agile Manifesto. Some of the most frequently-mentioned problems with Agile are: Agile ignores technical debt; frameworks like Scrum are just “red tape,” which they were never supposed to be; programmers are asked to commit to arbitrary estimates and deadlines and never get the time to think thoroughly about the features they’re creating. So if we can acknowledge and work on these problems, perhaps we can fix Agile.

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

The goal of this article is to provide a historical context of how JavaScript tools have evolved to what they are today in 2017. We’ll start from the beginning and build an example website like the dinosaurs did — no tools, just plain HTML and JavaScript. Then we’ll introduce different tools incrementally to see the problems that they solve one at a time. With this historical context, you’ll be better able to learn and adapt to the ever-changing JavaScript landscape going forward. Let’s get started!

According to Google’s own Page Speed Insights audit (which Google recommends to check your performance), the AMP version of articles got a performance score of 80. The non-AMP versions? 86. Mind you, the AMP versions are hobbled - unauthorised javascript interaction is forbidden by Google, so you can’t vote or comment in place - it’ll kick you to the full version of the page. This is the fruit of weeks of labour converting the site: a slower, less interactive, more clunky site.

WireMock is a simulator for HTTP-based APIs. Some might consider it a service virtualization tool or a mock server.

It enables you to stay productive when an API you depend on doesn't exist or isn't complete. It supports testing of edge cases and failure modes that the real API won't reliably produce. And because it's fast it can reduce your build time from hours down to minutes.

Vanna is an internal feature flagging service used at PBS. It helps deliver new features to users quickly and safely. This is an example client implementation for browser based Javascript.

More info in this article at Dev.to.

Är du nyfiken på programmering och digitalt skapande? Kodboken är sajten för dig som vill komma igång med kod.

Verkar ha en del övningar bland annat i att skapa musik och spel i Scratch. Värt att kolla på.

This series of posts is about the Commodore Amiga. Thousands of words have already been written on the Amiga, and I will not add anything but "milestone" to the adjectives used to describe it. This post and the following ones are not intended to be a complete and well-organised review of the architecture. Instead, they will be more a set of "lab notes" for myself that I write while I explore the platform. I put them on the blog in the hope that they will be useful for other programmers that try to crack the same problems.

The goal of this project is to create a universal database of disallowed usernames for web applications. This repository contains a list of keywords that should be banned/disallowed to prevent users from registering with, on your software projects and apps to prevent impersonation and phishing on your platform.