Embrace the crash.
Simple Docker containers from S3 on EC2 instances.
Ember is underrated.
I’m going to explain the Donald Trump phenomenon in three movies. And then some text.
After fighting with Docker on OSX and the need for 2-way syncs, fsevents, etc. I developed a desire to get back to a simple(r) development on a linux based VM. This project is a jumping off point.
The idea of this series was to teach enough Haskell to be able to read Simon Marlow’s book of the same title. It turned out to be both a Haskell course and a selection of topics on parallelism and concurrency. There should be something interesting for both total beginners and experts.
These videos contain some good introductory material to Haskell and great coverage of monads and the IO monad in particular1.
Milewski also has a video series on Category Theory which I’ve yet to watch.
Skip to the 5-1/2 and 6-1/2 videos for the monad stuff. ↩
Good tips for structuring your Slack channels.
Viewing software architecture decisions as selling options.
Temporal and spatial locality have a significant bearing on how we operate.
Eight simple rules for a robust, scalable CSS architecture.
Excellent list of tools for diagnosing performance issues on Linux.
An engineer’s career retrospective.
Boilerplate for developing Elm apps on Webpack.
Retaining Ruby’s chained Enumerable style, but finding a way to inject names that reflects the application domain.
A nice post on setting up decent keybindings in Emacs.
Another crack at the debt metaphor.
Grep all the things.
Nice coverage of different hypertext types. Start with HAL.
A nice broad coverage of the topic.
There’s a clear trend toward more powerful systems over time, especially when judging by language popularity rather than languages simply existing.
I still firmly hold the belief that iOS applications are either loss leaders or loss generators, that iOS devices themselves are thick terminals, and that a proper iOS execution strategy must be backed with a useful service either involving real world consequences (i.e. get a ride or get groceries delivered), or a wider cross-platform strategy (i.e. build your document on one platform, revise on another).
Airtime uses AWS Simple Notification Service (SNS) and AWS Simple Queue Service (SQS) to power the pub/sub event backbone that connects producer services to consumer services.
A loosely-coupled, event-based architecture based on AWS services.
A collection of practices and patterns out in the wild.
Zsh does so much.
Nice tour of Unix and zsh.
I don’t understand a bunch of this but it has me intrigued.
The versioned, forkable, syncable database
A nice example Elixir/Phoenix application.
A curated list of awesome Amazon Web Services (AWS) libraries, open source repos, guides, blogs, and other resources.
Soundcloud’s experience building an application using React Native.
A look at using queues for submitting commands.
A nice outline of VPCs subnets and friends.
Feel the Burr.
Sandi Metz being awesome. Highlighting extraction of variants and null objects.
Getting my guitar back on.
Micheal Lewis on a 14 year old stock manipulator.
Take it. It’s yours.
For the security conscious and paranoid.
A list of everything that could go in the <head> of your HTML document.
What is the CAP theorem for teams? Moving together balanced against moving forward.
Decent coverage of private and public subnets, NATs, and Internet gateways.
A wish list of future features for Rails. Some nice ideas in here.
curl wrapper that uses chrome cookies.
First time played in seven years.
Advice for us all.
A nice run down of how SSL/TLS works and its vulnerabilities.
A good template for elaborating site performance.
A deep dive into aspects of building an Event Store.
Guidelines for using rspec.
Music makes repetitive tasks more enjoyable.
Recreating shots from films.
Lots of great tips in here.
Models are used to save money when designing. i.e. The maths came second as a cheaper way to build stuff. When your end medium is so malleable you can design in it.
Good to see this kind of information shared.
Mathmetical tools to aid software development.
Recycle your infrastructure frequently to minimise security holes.
Strategies for dealing with Slack.
Nice concept summary.
Add placeholder image colours to images.
Computers and how we suck at it all.
Lots of meaty stuff.
A look at what engineering means, its history, and how software fits in.
Your own index is something you put in the back of the book (or the front if you prefer). It’s a list of the book’s themes and topics that most resonate with you, and the pages which have the best quotes and ideas around those topics.
I’ll use an index card to do this for the ebooks I read.
Amazing what’s happened in ten years.
An extensive look at what it takes to be a senior engineer.
Rackt is a GitHub organization that was created to ensure critical open source projects in the React community receive long-term support and maintenance.
We believe these four principles will provide a strong ecosystem of our open source projects by ensuring projects have active and enthusiastic owners and contributors.
Jesper Louis Andersen:
I’m very fond of Erlang creator Mike Williams point: “If you don’t make experiments before starting a project, then your whole project will be an experiment”
If we instead ask about prototyping, then we need a programming language with certain traits. The team is usually small, so we need an expressive language, and we need to address the core kernel of the system in isolation, first. We don’t need a lot of interfacing to foreign systems and in general we won’t care too much if the system we build is fast. Also, we usually won’t need to operate the prototype in production, since it is simply a proof of concept.
At work this past quarter, we painstakingly started three new projects at work. I say “painstakingly” because every project required decisions to be made around tooling depending on the scope & needs.
Ultimately, the problem is that by choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.
the React ecosystem have, largely, opted for discrete modularization at the cost of terse APIs by offloading their architectural underpinnings to the user and, as a result, worsen the developer experience in aggregate.
2016 will likely involve a serious, focused conjoining of projects, tools, and language features to merge the best and brightest packages/tools/boilerplates into more formalized projects. — Matt Keas in State of the Union.js
The approach that I now use for releasing code into the wild is governed by an approach called the “100:10:1 method,” a term coined by Nick Bentley.
I think I will give this a try.
One of Elm’s goals is to change our relationship with compilers. Compilers should be assistants, not adversaries. A compiler should not just detect bugs, it should then help you understand why there is a bug. It should not berate you in a robot voice, it should give you specific hints that help you write better code. Ultimately, a compiler should make programming faster and more fun!
I’ve enjoyed stretching my brain a bit whilst learning Elm. These changes will improve the learning process tremendously.
If you use PostgreSQL this is a nice native Mac OSX client.
A properly formed git commit subject line should always be able to complete the following sentence:
If applied, this commit will your subject line here
- If applied, this commit will refactor subsystem X for readability
- If applied, this commit will update getting started documentation
- If applied, this commit will remove deprecated methods
- If applied, this commit will release version 1.0.0
- If applied, this commit will merge pull request #123 from user/branch
The purpose of a self-imposed deadline is to sharpen the edge of your prioritization sword and stake a flag of coordination for the team. It’s not a hill to die on. It’s not a justification for weeks of death marching. It’s a voluntary constraint on scope.
Yes, deadlines are wonderful! They’re the tie-breaker on feature debates. They suck all the excess heat out of the prioritization joust: “Hey, I’d love to get your additional pet feature into the first release, but, you know: THE DEADLINE”.