In my experience, a good-enough specification for a pURI should specify:
- How many segments are there and if teams and service owners can add new segments
- What is the encoding and escaping expected for the text
- What in the identifier should be treated as opaque data as opposed to parts where consumers can make assumptions about data formats
We’ve been playing with almost the exact same scheme recently for some of our services.
From my point of view, the CQRS-induced complexity is largely accidental, and thus can be avoided. To illustrate my point, I want to discuss the goal of CQRS, and then analyze 3 common sources of accidental complexity in CQRS-based systems.
I find myself nodding to the sentiments of this post. It feels like doggedly pursing a theoretical ideal can lead to unnecessary difficulty in CQRS implementations.
Magnets blasting your head.
That’s gonna take a while.
Just in case.
I feel like we’ll be needing more and more of these.
How to follow good practices with Bash.
Presented with typical beauty from The Food Lab.
Designed by Jørn Utzon.
From MIT 15.S50 Poker Theory and Analysis.
An introduction to unix sockets in Ruby.
Forty years of work.
Want multiple Gmail web UIs next to each other? This is your bunny.
A catalog of logos, symbols, and trademarks.
Jesper L. Andersen:
In the recent years, I have adopted a method for system design, which I think yields good results. For a lack of better word, I overloaded “stack” yet again, and use it as a metaphor for this design.
The baseline is level 0 in the stack, and now we try to move the system upwards in the stack by adding another level. It is important to stress that transitioning is a best effort method. We make an attempt at increasing the operational level of the system, but if we can’t we stay put at the current level.
Jan Stenberg quoting Eric Evans:
Evans points out that a microservice, which should be autonomous, can be a good bounded context, but emphasizes that this does not mean that a service always is a bounded context, something that developers sometimes interpret it as.
Some interesting points in here about using multiple bounded contexts within a system to make it easier to work on.
Sometimes a model is a little incomplete, lacking the ability to handle all the cases it’s meant to handle. Instead of creating a model that is able to handle more cases but feels awkward, an alternative may be to create a function that deals with cases not handled by the model. Such a function works with lots of if-then-else statements, staying away from any high-level concepts to avoid creating yet another model. An abstraction that is leaking or confusing should not be used at all. Evans notes that it’s better to use if-then-else instead of creating an illusion of an elegant model. Such a model may even prevent finding a working model. He believes that this is a great example of a trade-off, aiming for a good but not perfect design.
I think this is a pragmatic approach. Finding an all-encompassing model can be paralysing.
The Mikado Method is a structured way to make major changes to complex code. It helps you visualize, plan, and perform business value-focused improvements over several iterations and increments of work, without ever having a broken codebase during the process.
In any kind of process planning in a factory, people know the price of running the plant at 100% utilisation: it gets sensitive to small errors. So nobody does that.
A look at error handling in event sourced systems.
HST reads his essay documenting his dabbling with electricity.
A solid React/Redux boilerplate.
Simplicity of programme, Kettlebell, and not training till failure.
KD plus f-bombs.
Plug in and get some work done.
Flying car concept.
Protecting artists from the banned countries.
An example application built with React + Redux that includes auth and remote data fetching.
in this post we will dissect an SSL certificate and try to understand it!
Are we all a projection from some two dimensional image?
I don’t even.
Nice QA checklist for launching a website.
… smaller subsystems communicate via agreed-upon contracts (commands and events). Each has their own data store. Eventsourcing and the CQRS pattern are used to reduce coupling (and therefore the potential for side effects) to a minimum.
What makes the combination of event sourcing, Domain Driven Design and CQRS so attractive is that it can greatly simplify building software which keeps subsystems cleanly separated and independently maintainable as more features are added over time, akin to what we have learned to do for cars, spacecraft and toasters.
Migrating an existing application to Docker.
Determining string size based on timing of web responses.
A collection of information about the PagerDuty incident response process. Not only how to prepare new employees for on-call responsibilities, but also how to handle major incidents, both in preparation and after-work.
Allows you to spoof your mac address. Useful for airports.
SVG Minifier web app.
CQRS event store in Elixir using PostgreSQL for persistence.
A tool that combines traceroute and ping.
Learnings from about 300 hours spent responding to security incidents and data breaches.
Call something X at first.
A long list of sci fi books to read.
Always interesting to see the books he recommends.
James Ross presenting concept maps.
Tips for working together asynchronously.
Graphviz is handy for generating diagrams from code.
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 particular.
Milewski also has a video series on Category Theory which I’ve yet to watch.
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.