From 2d8cb5d6f81f2c0c79c5b3f01ee62a4793361064 Mon Sep 17 00:00:00 2001 From: Thomas Mahler Date: Sat, 29 Jul 2023 17:37:54 +0200 Subject: [PATCH] improve the intro --- docs/atom.xml | 16 ++++++---------- ...2023-07-29-clean-architecture-revisited.html | 16 ++++++---------- docs/rss.xml | 16 ++++++---------- .../2023-07-29-clean-architecture-revisited.md | 17 +++++++---------- 4 files changed, 25 insertions(+), 40 deletions(-) diff --git a/docs/atom.xml b/docs/atom.xml index d5df33a..cdeb1ab 100644 --- a/docs/atom.xml +++ b/docs/atom.xml @@ -24,16 +24,12 @@

Interesting design challenges in seemingly simple programs

-

The other day I was writing a Haskell program with quite a limited scope:

- -

The task at hand sounded simple enough to just start coding without too much upfront thinking. -This blog post is about the process of discovering the shortcomings of my initial design and how I improved them by some simple refactorings. -As all the interesting stuff happened in the API access, I’ll focus on that part of the code.

-

In order to allow you to experiment with the code yourself, I’m not using the proprietary API of my original project but rather a publicly available REST API (https://openlibrary.org/developers/api) in this blog post.

-

The initial design

+

The other day I wrote a simple Haskell program that retrieves data from a REST API and processes it. +The task at hand sounded simple enough to just start coding without too much upfront thinking.

+

This blog post is about how I discovered the shortcomings of my original design and how I improved it with some simple refactorings. +Since everything interesting happens in the API access, I will focus on this part of the code.

+

In order to allow you to experiment with the code yourself, I’m not using the proprietary API of my original project but rather a publicly available REST API (OpenLibrary).

+

The original design

So without further ado, let’s start with the domain data types:

data Book = Book
   { bkTitle   :: String,
diff --git a/docs/posts/2023-07-29-clean-architecture-revisited.html b/docs/posts/2023-07-29-clean-architecture-revisited.html
index 33aaac7..601cdd7 100644
--- a/docs/posts/2023-07-29-clean-architecture-revisited.html
+++ b/docs/posts/2023-07-29-clean-architecture-revisited.html
@@ -62,16 +62,12 @@ 
Clean Architecture Revisited

 
 

 
Interesting design challenges in seemingly simple programs

-
The other day I was writing a Haskell program with quite a limited scope:

-
    
-
  • retrieving data from a REST API
    • 
-
  • storing the data in CSV files.
    • 
-

-
The task at hand sounded simple enough to just start coding without too much upfront thinking.
-This blog post is about the process of discovering the shortcomings of my initial design and how I improved them by some simple refactorings.
-As all the interesting stuff happened in the API access, I’ll focus on that part of the code.

-
In order to allow you to experiment with the code yourself, I’m not using the proprietary API of my original project but rather a publicly available REST API (https://openlibrary.org/developers/api) in this blog post.

-
The initial design

+
The other day I wrote a simple Haskell program that retrieves data from a REST API and processes it.
+The task at hand sounded simple enough to just start coding without too much upfront thinking.

+
This blog post is about how I discovered the shortcomings of my original design and how I improved it with some simple refactorings.
+Since everything interesting happens in the API access, I will focus on this part of the code.

+
In order to allow you to experiment with the code yourself, I’m not using the proprietary API of my original project but rather a publicly available REST API (OpenLibrary).

+
The original design

 
So without further ado, let’s start with the domain data types:

 
data Book = Book
   { bkTitle   :: String,
diff --git a/docs/rss.xml b/docs/rss.xml
index aea4712..75fd2de 100644
--- a/docs/rss.xml
+++ b/docs/rss.xml
@@ -20,16 +20,12 @@
 
 

 
Interesting design challenges in seemingly simple programs

-
The other day I was writing a Haskell program with quite a limited scope:

-
    
-
  • retrieving data from a REST API
    • 
-
  • storing the data in CSV files.
    • 
-

-
The task at hand sounded simple enough to just start coding without too much upfront thinking.
-This blog post is about the process of discovering the shortcomings of my initial design and how I improved them by some simple refactorings.
-As all the interesting stuff happened in the API access, I’ll focus on that part of the code.

-
In order to allow you to experiment with the code yourself, I’m not using the proprietary API of my original project but rather a publicly available REST API (https://openlibrary.org/developers/api) in this blog post.

-
The initial design

+
The other day I wrote a simple Haskell program that retrieves data from a REST API and processes it.
+The task at hand sounded simple enough to just start coding without too much upfront thinking.

+
This blog post is about how I discovered the shortcomings of my original design and how I improved it with some simple refactorings.
+Since everything interesting happens in the API access, I will focus on this part of the code.

+
In order to allow you to experiment with the code yourself, I’m not using the proprietary API of my original project but rather a publicly available REST API (OpenLibrary).

+
The original design

 
So without further ado, let’s start with the domain data types:

 
data Book = Book
   { bkTitle   :: String,
diff --git a/posts/2023-07-29-clean-architecture-revisited.md b/posts/2023-07-29-clean-architecture-revisited.md
index 9e8474c..e60c83f 100644
--- a/posts/2023-07-29-clean-architecture-revisited.md
+++ b/posts/2023-07-29-clean-architecture-revisited.md
@@ -1,7 +1,7 @@
 ---
 title: Clean Architecture Revisited
 author: Thomas Mahler
-tags: haskell, clean architecture, domain driven design, functional programming, decoupling, dependency injection, higher order functions
+tags: haskell, clean architecture, domain driven design, functional programming, decoupling, dependency injection, higher order functions, patterns, refactoring, unit testing
 ---
 
 
@@ -10,18 +10,15 @@ tags: haskell, clean architecture, domain driven design, functional programming,
 
 ## Interesting design challenges in seemingly simple programs
 
-The other day I was writing a Haskell program with quite a limited scope:
-
-- retrieving data from a REST API
-- storing the data in CSV files.
-
+The other day I wrote a simple Haskell program that retrieves data from a REST API and processes it.
 The task at hand sounded simple enough to just start coding without too much upfront thinking.
-This blog post is about the process of discovering the shortcomings of my initial design and how I improved them by some simple refactorings.
-As all the interesting stuff happened in the API access, I'll focus on that part of the code.
 
-In order to allow you to experiment with the code yourself, I'm not using the proprietary API of my original project but rather a publicly available REST API (https://openlibrary.org/developers/api) in this blog post.
+This blog post is about how I discovered the shortcomings of my original design and how I improved it with some simple refactorings. 
+Since everything interesting happens in the API access, I will focus on this part of the code.
+
+In order to allow you to experiment with the code yourself, I'm not using the proprietary API of my original project but rather a publicly available REST API ([OpenLibrary](https://openlibrary.org/developers/api)).
 
-## The initial design
+## The original design
 
 So without further ado, let's start with the domain data types: