A website about technology, software craftsmanship and the exhilaration of designing abstract structures for concrete use.
Here, I share thoughts about the tools I test and explain the techniques I use. In addition to isolated articles, I develop more in-depth examples in article series. In those, we build fun open-source projects from the ground up.
Open series are: cryptomate, software engineering and python.
After the theory, a quick review of common runtime error handling techniques.
Most ecosystems focus on one, but knowing the others might come in handy in some situations.▸ read more A C++ smart unique_ptr uses exactly the same amount of memory as a
regular pointer, and has zero runtime cost. That is what we love about C++. But what if I need a custom deleter for my pointer? Can I get it at zero cost too?▸ read more We cover the basics of correct error handling, so it is no longer an afterthought.
In previous post, we left some crucial questions unanswered, such as
“What exactly makes an error recoverable?”. In this post, we dive into levels of abstraction and what they mean for error handling.▸ read more In the previous post we designed our testing infrastructure to work with aiohttp.
We will now put that testing infrastructure through a baptism by fire.▸ read more Asynchronous code is the new paradigm in python those last years.
Testing it, though, is significantly harder.
Let's see how to test asynchronous HTTP client code written with aiohttp.▸ read more Remaining ports are much simpler in their scope, and in the fact they do not manage
dynamic subscriptions. We will review them quickly for completeness.▸ read more In the “modules and components” post, we defined the trading port as a gateway
to exchanges, managing a trading account, placing and canceling orders.▸ read more So far, we have been talking about market events, orders and strategies, as
abstract concepts, leaving details to a later point. Now, to design the core of
the strategy engine, we need the full picture.▸ read more Initial design is done. It is now time to start laying the basis of the project.
At this point, there are a few technical choices we can no longer defer.▸ read more We hack together a couple of modules, do quick manual testing. Eventually, the code remains a
hackish mess rotting away which may be fine but a little unsatisfactory.▸ read more We used most of the allocated design time, and our architecture is falling into place.
Spending more time on upfront design will yield diminishing returns at this point.
Here is a quick post index.▸ read more We detail critical parts of the architecture: relationships between main
components, strategy life-cycle and integration examples for both testing and production.▸ read more Event-driven, hexagonal, micro-services… we can quickly trim down the options to a few
candidates. We will then explore, evaluate and select one of them.▸ read more We understand the problem and can start building our high-level architecture. We will start
with mapping the requirements to project elements.▸ read more Constraints, functional requirements, quality attributes. All of those are known as
architecturally significant requirements. Characterizing those is the final step
in our initial “understand phase”.▸ read more We will start our job with identifying all stakeholders we can. Then, depending on how close
to the project they are, we will get to know them and find out their goals.▸ read more A new project with no legacy to accommodate may either be a clean slate or a blank page,
depending on how one looks at it. Before we start filling it, we need to define our strategy.▸ read more A trading bot is an amazing tool. It talks to many third parties.
It requires a rich, flexible toolset to empower its user.
This needs powerful abstractions. In short, it is the
perfect project to start my website with.▸ read moreback to top