diff --git a/Gemfile b/Gemfile new file mode 100644 index 0000000..8a6c583 --- /dev/null +++ b/Gemfile @@ -0,0 +1,4 @@ +# frozen_string_literal: true + +source "https://rubygems.org" +gem "github-pages", group: :jekyll_plugins diff --git a/Gemfile.lock b/Gemfile.lock new file mode 100644 index 0000000..a650df8 --- /dev/null +++ b/Gemfile.lock @@ -0,0 +1,285 @@ +GEM + remote: https://rubygems.org/ + specs: + activesupport (8.1.3) + base64 + bigdecimal + concurrent-ruby (~> 1.0, >= 1.3.1) + connection_pool (>= 2.2.5) + drb + i18n (>= 1.6, < 2) + json + logger (>= 1.4.2) + minitest (>= 5.1) + securerandom (>= 0.3) + tzinfo (~> 2.0, >= 2.0.5) + uri (>= 0.13.1) + addressable (2.9.0) + public_suffix (>= 2.0.2, < 8.0) + base64 (0.3.0) + bigdecimal (4.1.1) + coffee-script (2.4.1) + coffee-script-source + execjs + coffee-script-source (1.12.2) + colorator (1.1.0) + commonmarker (0.23.12) + concurrent-ruby (1.3.6) + connection_pool (3.0.2) + csv (3.3.5) + dnsruby (1.73.1) + base64 (>= 0.2) + logger (~> 1.6) + simpleidn (~> 0.2.1) + drb (2.2.3) + em-websocket (0.5.3) + eventmachine (>= 0.12.9) + http_parser.rb (~> 0) + ethon (0.18.0) + ffi (>= 1.15.0) + logger + eventmachine (1.2.7) + execjs (2.10.1) + faraday (2.14.1) + faraday-net_http (>= 2.0, < 3.5) + json + logger + faraday-net_http (3.4.2) + net-http (~> 0.5) + ffi (1.17.4-x86_64-linux-gnu) + forwardable-extended (2.6.0) + gemoji (4.1.0) + github-pages (232) + github-pages-health-check (= 1.18.2) + jekyll (= 3.10.0) + jekyll-avatar (= 0.8.0) + jekyll-coffeescript (= 1.2.2) + jekyll-commonmark-ghpages (= 0.5.1) + jekyll-default-layout (= 0.1.5) + jekyll-feed (= 0.17.0) + jekyll-gist (= 1.5.0) + jekyll-github-metadata (= 2.16.1) + jekyll-include-cache (= 0.2.1) + jekyll-mentions (= 1.6.0) + jekyll-optional-front-matter (= 0.3.2) + jekyll-paginate (= 1.1.0) + jekyll-readme-index (= 0.3.0) + jekyll-redirect-from (= 0.16.0) + jekyll-relative-links (= 0.6.1) + jekyll-remote-theme (= 0.4.3) + jekyll-sass-converter (= 1.5.2) + jekyll-seo-tag (= 2.8.0) + jekyll-sitemap (= 1.4.0) + jekyll-swiss (= 1.0.0) + jekyll-theme-architect (= 0.2.0) + jekyll-theme-cayman (= 0.2.0) + jekyll-theme-dinky (= 0.2.0) + jekyll-theme-hacker (= 0.2.0) + jekyll-theme-leap-day (= 0.2.0) + jekyll-theme-merlot (= 0.2.0) + jekyll-theme-midnight (= 0.2.0) + jekyll-theme-minimal (= 0.2.0) + jekyll-theme-modernist (= 0.2.0) + jekyll-theme-primer (= 0.6.0) + jekyll-theme-slate (= 0.2.0) + jekyll-theme-tactile (= 0.2.0) + jekyll-theme-time-machine (= 0.2.0) + jekyll-titles-from-headings (= 0.5.3) + jemoji (= 0.13.0) + kramdown (= 2.4.0) + kramdown-parser-gfm (= 1.1.0) + liquid (= 4.0.4) + mercenary (~> 0.3) + minima (= 2.5.1) + nokogiri (>= 1.16.2, < 2.0) + rouge (= 3.30.0) + terminal-table (~> 1.4) + webrick (~> 1.8) + github-pages-health-check (1.18.2) + addressable (~> 2.3) + dnsruby (~> 1.60) + octokit (>= 4, < 8) + public_suffix (>= 3.0, < 6.0) + typhoeus (~> 1.3) + html-pipeline (2.14.3) + activesupport (>= 2) + nokogiri (>= 1.4) + http_parser.rb (0.8.1) + i18n (1.14.8) + concurrent-ruby (~> 1.0) + jekyll (3.10.0) + addressable (~> 2.4) + colorator (~> 1.0) + csv (~> 3.0) + em-websocket (~> 0.5) + i18n (>= 0.7, < 2) + jekyll-sass-converter (~> 1.0) + jekyll-watch (~> 2.0) + kramdown (>= 1.17, < 3) + liquid (~> 4.0) + mercenary (~> 0.3.3) + pathutil (~> 0.9) + rouge (>= 1.7, < 4) + safe_yaml (~> 1.0) + webrick (>= 1.0) + jekyll-avatar (0.8.0) + jekyll (>= 3.0, < 5.0) + jekyll-coffeescript (1.2.2) + coffee-script (~> 2.2) + coffee-script-source (~> 1.12) + jekyll-commonmark (1.4.0) + commonmarker (~> 0.22) + jekyll-commonmark-ghpages (0.5.1) + commonmarker (>= 0.23.7, < 1.1.0) + jekyll (>= 3.9, < 4.0) + jekyll-commonmark (~> 1.4.0) + rouge (>= 2.0, < 5.0) + jekyll-default-layout (0.1.5) + jekyll (>= 3.0, < 5.0) + jekyll-feed (0.17.0) + jekyll (>= 3.7, < 5.0) + jekyll-gist (1.5.0) + octokit (~> 4.2) + jekyll-github-metadata (2.16.1) + jekyll (>= 3.4, < 5.0) + octokit (>= 4, < 7, != 4.4.0) + jekyll-include-cache (0.2.1) + jekyll (>= 3.7, < 5.0) + jekyll-mentions (1.6.0) + html-pipeline (~> 2.3) + jekyll (>= 3.7, < 5.0) + jekyll-optional-front-matter (0.3.2) + jekyll (>= 3.0, < 5.0) + jekyll-paginate (1.1.0) + jekyll-readme-index (0.3.0) + jekyll (>= 3.0, < 5.0) + jekyll-redirect-from (0.16.0) + jekyll (>= 3.3, < 5.0) + jekyll-relative-links (0.6.1) + jekyll (>= 3.3, < 5.0) + jekyll-remote-theme (0.4.3) + addressable (~> 2.0) + jekyll (>= 3.5, < 5.0) + jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) + rubyzip (>= 1.3.0, < 3.0) + jekyll-sass-converter (1.5.2) + sass (~> 3.4) + jekyll-seo-tag (2.8.0) + jekyll (>= 3.8, < 5.0) + jekyll-sitemap (1.4.0) + jekyll (>= 3.7, < 5.0) + jekyll-swiss (1.0.0) + jekyll-theme-architect (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-cayman (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-dinky (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-hacker (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-leap-day (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-merlot (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-midnight (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-minimal (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-modernist (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-primer (0.6.0) + jekyll (> 3.5, < 5.0) + jekyll-github-metadata (~> 2.9) + jekyll-seo-tag (~> 2.0) + jekyll-theme-slate (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-tactile (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-time-machine (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-titles-from-headings (0.5.3) + jekyll (>= 3.3, < 5.0) + jekyll-watch (2.2.1) + listen (~> 3.0) + jemoji (0.13.0) + gemoji (>= 3, < 5) + html-pipeline (~> 2.2) + jekyll (>= 3.0, < 5.0) + json (2.19.3) + kramdown (2.4.0) + rexml + kramdown-parser-gfm (1.1.0) + kramdown (~> 2.0) + liquid (4.0.4) + listen (3.10.0) + logger + rb-fsevent (~> 0.10, >= 0.10.3) + rb-inotify (~> 0.9, >= 0.9.10) + logger (1.7.0) + mercenary (0.3.6) + minima (2.5.1) + jekyll (>= 3.5, < 5.0) + jekyll-feed (~> 0.9) + jekyll-seo-tag (~> 2.1) + minitest (6.0.3) + drb (~> 2.0) + prism (~> 1.5) + net-http (0.9.1) + uri (>= 0.11.1) + nokogiri (1.19.2-x86_64-linux-gnu) + racc (~> 1.4) + octokit (4.25.1) + faraday (>= 1, < 3) + sawyer (~> 0.9) + pathutil (0.16.2) + forwardable-extended (~> 2.6) + prism (1.9.0) + public_suffix (5.1.1) + racc (1.8.1) + rb-fsevent (0.11.2) + rb-inotify (0.11.1) + ffi (~> 1.0) + rexml (3.4.4) + rouge (3.30.0) + rubyzip (2.4.1) + safe_yaml (1.0.5) + sass (3.7.4) + sass-listen (~> 4.0.0) + sass-listen (4.0.0) + rb-fsevent (~> 0.9, >= 0.9.4) + rb-inotify (~> 0.9, >= 0.9.7) + sawyer (0.9.3) + addressable (>= 2.3.5) + faraday (>= 0.17.3, < 3) + securerandom (0.4.1) + simpleidn (0.2.3) + terminal-table (1.8.0) + unicode-display_width (~> 1.1, >= 1.1.1) + typhoeus (1.6.0) + ethon (>= 0.18.0) + tzinfo (2.0.6) + concurrent-ruby (~> 1.0) + unicode-display_width (1.8.0) + uri (1.1.1) + webrick (1.9.2) + +PLATFORMS + x86_64-linux + +DEPENDENCIES + github-pages + +BUNDLED WITH + 2.4.10 diff --git a/blog/2017-09-07-introducing-command-handler.html b/blog/2017-09-07-introducing-command-handler.html index dea2568..f1b6518 100644 --- a/blog/2017-09-07-introducing-command-handler.html +++ b/blog/2017-09-07-introducing-command-handler.html @@ -160,7 +160,6 @@

Introducing Command Handler

problem_description: str -

A command object is a small object that represents a state-changing action that can happen in the system. Commands have no behaviour, they’re pure data structures. There’s no reason why you have to represent them with classes, since @@ -209,7 +208,6 @@

Introducing Command Handler

self.issue_log.add(issue) -

Command handlers are stateless objects that orchestrate the behaviour of a system. They are a kind of glue code, and manage the boring work of fetching and saving objects, and then notifying other parts of the system. In keeping with @@ -240,7 +238,6 @@

Introducing Command Handler

issue.mark_as_resolved(cmd.resolution) -

This handler violates our glue-code principle because it encodes a business rule: “If an issue is already resolved, then it can’t be resolved a second time”. This rule belongs in our domain model, probably in the mark_as_resolved @@ -258,7 +255,6 @@

Introducing Command Handler

issue_log.add(issue) -

If magic methods make you feel queasy, you can define a handler to be a class that exposes a handle method like this:

class ReportIssueHandler:
@@ -266,7 +262,6 @@ 
 Introducing Command Handler

        ...
-

However you structure them, the important ideas of commands and handlers are:

  1. Commands are logic-free data structures with a name and a bunch of values.
    2. @@ -375,7 +370,6 @@

    Introducing Command Handler

    expect(self.issues[0].description).to(equal(desc)) -

    There’s not a lot of functionality here, and our issue log has a couple of problems, firstly there’s no way to see the issues in the log yet, and secondly we’ll lose all of our data every time we restart the process. We’ll fix the diff --git a/blog/2017-09-08-repository-and-unit-of-work-pattern-in-python.html b/blog/2017-09-08-repository-and-unit-of-work-pattern-in-python.html index 36412cd..64815c9 100644 --- a/blog/2017-09-08-repository-and-unit-of-work-pattern-in-python.html +++ b/blog/2017-09-08-repository-and-unit-of-work-pattern-in-python.html @@ -74,7 +74,6 @@

    Repository and Unit of Work Pattern

    issue_log.add(issue) -

    The IssueLog is a term from our conversation with the domain expert. It’s the place that they record the list of all issues. This is part of the jargon used by our customers, and so it clearly belongs in the domain, but it’s also the @@ -106,7 +105,6 @@

    Repository and Unit of Work Pattern

    self.output.write(1) -

    Because we had the great foresight to use standardised ports, we can plug any number of different devices into our circuit. For example, we could attach a light-detector to the input and a buzzer to the output, or we could attach a @@ -133,7 +131,6 @@

    Repository and Unit of Work Pattern

    self.on = False -

    Considered in isolation, this is just an example of good OO practice: we are extending our system through composition. What makes this a ports-and-adapters architecture is the idea that there is an internal world consisting of the @@ -161,7 +158,6 @@

    Repository and Unit of Work Pattern

    json.dump(f) -

    By analogy to our circuit example, the IssueLog is a WriteablePort - it’s a way for us to get data out of the system. SqlAlchemy and the file system are two types of adapter that we can plug in, just like the Buzzer or Light classes. In @@ -186,7 +182,6 @@

    Repository and Unit of Work Pattern

    filter(foo.latitude == latitude) -

    We expose a few methods, one to add new items, one to get items by their id, and a third to find items by some criterion. This FooRepository is using a SqlAlchemy session @@ -209,7 +204,6 @@

    Repository and Unit of Work Pattern

    if item.latitude == latitude) -

    This adapter works just the same as the one backed by a real database, but does so without any external state. This allows us to test our code without resorting to Setup/Teardown scripts on our database, or monkey patching our ORM to return @@ -226,7 +220,7 @@

    Repository and Unit of Work Pattern

    request.

    What does a unit of work look like?

    class SqlAlchemyUnitOfWorkManager(UnitOfWorkManager):
-    """The Unit of work manager returns a new unit of work. 
+    """The Unit of work manager returns a new unit of work. 
        Our UOW is backed by a sql alchemy session whose 
        lifetime can be scoped to a web request, or a 
        long-lived background job."""
@@ -238,7 +232,7 @@ 
     Repository and Unit of Work Pattern
    
 
 
 class SqlAlchemyUnitOfWork(UnitOfWork):
-    """The unit of work captures the idea of a set of things that
+    """The unit of work captures the idea of a set of things that
        need to happen together. 
 
        Usually, in a relational database, 
@@ -267,7 +261,6 @@ 
     Repository and Unit of Work Pattern
    
         return IssueRepository(self.session)
    -

    This code is taken from a current production system - the code to implement these patterns really isn’t complex. The only thing missing here is some logging and error handling in the commit method. Our unit-of-work manager creates a new @@ -287,7 +280,6 @@

    Repository and Unit of Work Pattern

    unit_of_work.commit() -

    Our command handler looks more or less the same, except that it’s now responsible for starting a unit-of-work, and committing the unit-of-work when it has finished. This is in keeping with our rule #1 - we will clearly define the @@ -341,7 +333,6 @@

    Repository and Unit of Work Pattern

    expect(self.uow.was_committed).to(be_true) -

    Next time [https://io.made.com/blog/commands-and-queries-handlers-and-views] we’ll look at how to get data back out of the system.

    diff --git a/blog/2017-09-13-commands-and-queries-handlers-and-views.html b/blog/2017-09-13-commands-and-queries-handlers-and-views.html index b0a2246..47f427f 100644 --- a/blog/2017-09-13-commands-and-queries-handlers-and-views.html +++ b/blog/2017-09-13-commands-and-queries-handlers-and-views.html @@ -87,7 +87,6 @@

    What is CQS ?

    return self.light_is_on -

    In this class, the is_on method is referentially transparent - I can replace it with the value True or False without any loss of functionality, but the method toggle_light is side-effectual: replacing its calls with a static value would @@ -116,7 +115,6 @@

    What is CQS ?

    return json.dumps(open_issues) -

    This is totally fine unless you have complex formatting, or multiple entrypoints to your system. The problem with using your repositories directly in this way is that it’s a slippery slope. Sooner or later you’re going to have a tight @@ -130,7 +128,6 @@

    What is CQS ?

    uow.commit() -

    Super convenient, but then you need to add some error handling and some logging and an email notification.

    @app.route('/issues/<issue_id>', methods=['DELETE'])
@@ -157,7 +154,6 @@ 
    What is CQS ?
    
     return "Deleted!", 202
    -

    Aaaaand, we’re back to where we started: business logic mixed with glue code, and the whole mess slowly congealing in our web controllers. Of course, the slippery slope argument isn’t a good reason not to do something, so if your @@ -185,7 +181,6 @@

    What is CQS ?

    return jsonify(view_builder.fetch()) -

    This is my favourite part of teaching ports and adapters to junior programmers, because the conversation inevitably goes like this:

    @@ -225,7 +220,6 @@

    Why have a separate read-model?

    assignee.queues.inbox.add(task) -

    ORMs make it very easy to “dot” through the object model this way, and pretend that we have our data in memory, but this quickly leads to performance issues when the ORM generates hundreds of select statements in response. Then they get @@ -310,7 +304,6 @@

    Application Controlled Identifiers

    return "", 201, { 'Location': '/issues/' + str(issue_id) } -

    There’s a few ways to do this, the most common is just to use a UUID, but you can also implement something like hi-lo. diff --git a/blog/2017-09-19-why-use-domain-events.html b/blog/2017-09-19-why-use-domain-events.html index 8403615..6936a45 100644 --- a/blog/2017-09-19-why-use-domain-events.html +++ b/blog/2017-09-19-why-use-domain-events.html @@ -145,7 +145,6 @@

    Mapping our requirements to our domain

    expect(self.issue.state).to(equal(IssueState.AwaitingTriage)) -

    We’re introducing a new concept - Issues now have a state, and a newly reported issue begins in the AwaitingTriage state. We can quickly add a command and handler that allows us to triage an issue.

    @@ -161,7 +160,6 @@

    Mapping our requirements to our domain

    uow.commit() -

    Triaging an issue, for now, is a matter of selecting a category and priority. We’ll use a free string for category, and an enumeration for Priority. Once an issue is triaged, it enters the AwaitingAssignment state. At some point we’ll @@ -180,7 +178,6 @@

    Mapping our requirements to our domain

    uow.commit() -

    At this point, the handlers are becoming a little boring. As I said way back in the first part [https://io.made.com/blog/introducing-command-handler/], commands handlers are supposed to be boring glue-code, and every command handler has the @@ -225,7 +222,6 @@

    Mapping our requirements to our domain

    self.email_sender.send(email) -

    Something here feels wrong, right? Our command-handler now has two very distinct responsibilities. Back at the beginning of this series we said we would stick with three principles:

    @@ -290,7 +286,6 @@

    Mapping our requirements to our domain

    self.email_sender.send(email) -

    We don’t really need a unit of work here, because we’re not making any persistent changes to the Issue state, so what if we use a view builder instead?

    class SendAssignmentEmailHandler
@@ -312,7 +307,6 @@ 
    Mapping our requirements to our domain
    
         self.email_sender.send(email)
    -

    That seems better, but how should we invoke our new handler? Building a new command and handler from inside our AssignIssueHandler also sounds like a violation of SRP. Worse still, if we start calling handlers from handlers, we’ll @@ -360,12 +354,12 @@

    Mapping our requirements to our domain

    class MessageBus:
 
     def __init__(self):
-        """Our message bus is just a mapping from message type
+        """Our message bus is just a mapping from message type
            to a list of handlers"""
         self.subscribers = defaultdict(list)
 
     def handle(self, msg):
-        """The handle method invokes each handler in turn
+        """The handle method invokes each handler in turn
            with our event"""
         msg_name = type(msg).__name__
         subscribers = self.subscribers[msg_name]
@@ -373,7 +367,7 @@ 
    Mapping our requirements to our domain
    
             subscriber.handle(cmd)
 
     def subscribe_to(self, msg, handler):
-        """Subscribe sets up a new mapping, we make sure not
+        """Subscribe sets up a new mapping, we make sure not
            to allow more than one handler for a command"""
         subscribers = [msg.__name__]
         if msg.is_cmd and len(subscribers) > 0:
@@ -386,7 +380,6 @@ 
    Mapping our requirements to our domain
    
 bus.handle(cmd)
    -

    Here we have a bare-bones implementation of a message bus. It doesn’t do anything fancy, but it will do the job for now. In a production system, the message bus is an excellent place to put cross-cutting concerns; for example, we @@ -404,7 +397,6 @@

    Mapping our requirements to our domain

    return "", 201, {"Location": "/issues/" + str(issue_id) } -

    Not much has changed here - we’re still building our command in the Flask adapter, but now we’re passing it into a bus instead of directly constructing a handler for ourselves. What about when we need to raise an event? We’ve got @@ -425,7 +417,6 @@

    Mapping our requirements to our domain

    cmd.assigned_by)) -

    I usually think of this event-raising as a kind of glue - it’s orchestration code. Raising events from your handlers this way makes the flow of messages explicit - you don’t have to look anywhere else in the system to understand @@ -445,7 +436,6 @@

    Mapping our requirements to our domain

    self.events.add(IssueAssignedToEngineer(self.id, self.assigned_to, self.assigned_by)) -

    There’s a couple of benefits of doing this: firstly, it keeps our command handler simpler, but secondly it pushes the logic for deciding when to send an event into the model. For example, maybe we don’t always need to raise the @@ -461,7 +451,6 @@

    Mapping our requirements to our domain

    self.events.add(IssueAssignedToEngineer(self.id, self.assigned_to, self.assigned_by)) -

    Now we’ll only raise our event if the issue was assigned by another engineer. Cases like this are more like business logic than glue code, so today I’m choosing to put them in my domain model. Updating our unit tests is trivial, @@ -485,7 +474,6 @@

    Mapping our requirements to our domain

    self.assigned_by))) -

    The have_raised function is a custom matcher I wrote that checks the events attribute of our object to see if we raised the correct event. It’s easy to test for the presence of events, because they’re namedtuples, and have value @@ -540,7 +528,6 @@

    Mapping our requirements to our domain

    self.publish_events() -

    Okay, we’ve covered a lot of ground here. We’ve discussed why you might want to use domain events, how a message bus actually works in practice, and how we can get events out of our domain and into our subscribers. The newest code sample diff --git a/blog/2019-04-15-inversion-of-control.html b/blog/2019-04-15-inversion-of-control.html index 088e89c..cba8af9 100644 --- a/blog/2019-04-15-inversion-of-control.html +++ b/blog/2019-04-15-inversion-of-control.html @@ -111,7 +111,7 @@

    Removing cycles by inverting control

    There are a few ways to tackle a circular dependency. You may be able to extract a shared dependency into a separate module, that the other two modules depend on. You may be able to create an extra module that coordinates the two modules, instead of them calling each other. Or you can use inversion of control.

    -

    At the moment, each module calls each other. We can pick one of the calls (let’s say A‘s call to B) and invert +

    At the moment, each module calls each other. We can pick one of the calls (let’s say A’s call to B) and invert control so that A no longer needs to know anything about B. Instead, it exposes a way of plugging into its behaviour, that B can then exploit. This can be diagrammed like so:

    B plugging into A

    @@ -140,12 +140,10 @@

    Conclusion: complex is better than complicated

    Simple is better than complex.
    -

    But also that

    Complex is better than complicated.
    -

    I think of inversion of control as an example of choosing the complex over the complicated. If we don’t use it when it’s needed, our efforts to create a simple system will tangle into complications. Inverting dependencies allows us, at the cost of a small amount of complexity, to make our systems less complicated.

    diff --git a/blog/2019-08-03-ioc-techniques.html b/blog/2019-08-03-ioc-techniques.html index 6303baf..9a30102 100644 --- a/blog/2019-08-03-ioc-techniques.html +++ b/blog/2019-08-03-ioc-techniques.html @@ -81,7 +81,6 @@

    Abstractions, implementations and interfaces — in Python

    print("Woof.") -

    In this example, Animal is an abstraction: it declares its speak method, but it’s not intended to be run (as is signalled by the NotImplementedError).

    Cat and Dog, however, are implementations: they both implement the speak method, each in their own way.

    @@ -100,7 +99,6 @@

    Polymorphism and duck typing

    make_animal_speak(Dog()) -

    The make_animal_speak function need not know anything about cats or dogs; all it has to know is how to interact with the abstract concept of an animal. Interacting with objects without knowing their specific type, only their interface, is known as ‘polymorphism’.

    @@ -115,7 +113,6 @@

    Polymorphism and duck typing

    print("Woof.") -

    Even if Cat and Dog don’t inherit Animal, they can still be passed to make_animal_speak and things will work just fine. This informal ability to interact with an object without it explicitly declaring an interface is known as ‘duck typing’.

    @@ -132,7 +129,6 @@

    Polymorphism and duck typing

    notify(customer, event) -

    We may even use Python modules:

    import email
 import text_message
@@ -142,7 +138,6 @@ 
    Polymorphism and duck typing
    
     notification_method.notify(customer, event)
    -

    Whether a shared interface is manifested in a formal, object oriented manner, or more implicitly, we can generalise the separation between the interface and the implementation like so:

    Diagram of implementation inheriting abstract interface

    @@ -167,7 +162,6 @@

    Technique One: Dependency Injection

    print("Hello, world.") -

    This function is called from a top level function like so:

    # main.py
 
@@ -178,7 +172,6 @@ 
    Technique One: Dependency Injection
    
     hello_world()
    -

    hello_world has one dependency that is of interest to us: the built in function print. We can draw a diagram of these dependencies like this:

    Main pointing to hello_world pointing to print

    @@ -192,7 +185,6 @@

    Technique One: Dependency Injection

    output_function("Hello, world.") -

    All we do is allow it to receive the output function as an argument. The orchestration code then passes in the print function via the argument:

    # main.py
 
@@ -203,7 +195,6 @@ 
    Technique One: Dependency Injection
    
     hello_world.hello_world(output_function=print)
    -

    That’s it. It couldn’t get much simpler, could it? In this example, we’re injecting a callable, but other implementations could expect a class, an instance or even a module.

    With very little code, we have moved the dependency out of hello_world, into the top level function:

    @@ -229,7 +220,6 @@

    The Configuration Registry

    output_function("Hello, world.") -

    To complete the picture, here’s how it could be configured externally:

    # main.py
 
@@ -243,7 +233,6 @@ 
    The Configuration Registry
    
     hello_world.hello_world()
    -

    The machinery in this case is simply a dictionary that is written to from outside the module. In a real world system, we might want a slightly more sophisticated config system (making it immutable for example, is a good idea). But at heart, any key-value store will do.

    @@ -266,7 +255,6 @@

    The Subscriber Registry

    print(f"Hello, {person}.") - 
    # john.py
 
 import hello_people
@@ -275,7 +263,6 @@ 
    The Subscriber Registry
    
 hello_people.people.append("John")
    - 
    # martha.py
 
 import hello_people
@@ -284,7 +271,6 @@ 
    The Subscriber Registry
    
 hello_people.people.append("Martha")
    -

    As with the configuration registry, there is a store that can be written to from outside. But instead of being a dictionary, it’s a list. This list is populated, typically at startup, by other components scattered throughout the system. When the time is right, @@ -309,7 +295,6 @@

    Subscribing to events

    subscriber() - 
    # log.py
 
 import hello_world
@@ -322,7 +307,6 @@ 
    Subscribing to events
    
 hello_world.subscribers.append(write_to_log)
    -

    Technique Three: Monkey Patching

    Our final technique, Monkey Patching, is very different to the others, as it doesn’t use the Inversion of Control pattern described above.

    @@ -341,7 +325,6 @@

    Technique Three: Monkey Patching

    hello_world.hello_world() -

    Monkey patching takes other forms. You could manipulate to your heart’s content some hapless class defined elsewhere — changing attributes, swapping in other methods, and generally doing whatever you like to it.

    Choosing a technique

    diff --git a/blog/2020-01-25-testing_external_api_calls.html b/blog/2020-01-25-testing_external_api_calls.html index 7673685..b14af5e 100644 --- a/blog/2020-01-25-testing_external_api_calls.html +++ b/blog/2020-01-25-testing_external_api_calls.html @@ -91,7 +91,6 @@

    Writing tests for external API calls

    # knows how to save itself to the DB. like Django. -

    We want to sync our shipments model with a third party, the cargo freight company, via their API. We have a couple of use cases: creating new shipments, and checking for updated etas.

    @@ -107,7 +106,6 @@

    Writing tests for external API calls

    sync_to_api(shipment) -

    How do we sync to the API? A simple POST request, with a bit of datatype conversion and wrangling.

    def sync_to_api(shipment):
@@ -121,7 +119,6 @@ 
     Writing tests for external API calls
    
     })
    -

    Not too bad!

    How do we test it? In a case like this, the typical reaction is to reach for mocks, and as long as things stay simple, it’s pretty manageable

    @@ -138,7 +135,6 @@

    Writing tests for external API calls

    ) -

    And you can imagine adding a few more tests, perhaps one that checks that we do the date-to-isoformat conversion correctly, maybe one that checks we can handle multiple lines. Three tests, one mock each, we’re ok.

    @@ -179,7 +175,6 @@

    Writing tests for external API calls

    ) -

    And as usual, complexity creeps in: