Category: Programming Tools & Languages

Paired Programming: Useful Articles, Resources and Research

Paired Programming: Useful Articles, Resources and Research

During my talk at NDC London this week, I promised to publish a list of resources you can use if you are trying to persuade people of the efficacy of paired programming as a software development technique. Here it is!

(incidentally, the image is of Sal Freudenberg and me doing some remote pairing – we use Zoom and we find it works really well – I often forget we are not in the same room).

Martin Fowler webinar, new Refactoring book

Martin Fowler webinar, new Refactoring book

These may well be the notiest notes I’ve ever published, but just in case they’re of any use to anyone… if nothing else they may whet your appetite for the new edition of Martin Fowler’s Refactoring book.

I confess I never read it first time round (not on purpose, just there are so many books in the world and so little time…), so I’m looking forward to reading it this time. It hasn’t come out yet in the UK but should be some time in the next few weeks. Mine is already on order [drums fingers impatiently].

So anyway, Martin did a webinar today on the topic of his new book, and here are my notes:

Refactoring should be done via small changes

  • v small semantics-preserving changes
  • So small they’re not worth doing on their own
  • String together small changes to make a big change

When adding new functionality:

  • Alternate between refactoring and adding functionality
  • Often it’s easier to add new functionality if you refactor first
  • Balance between adding new functionality and refactoring – it’s a matter of judgement

V1 of Martin’s Refactoring book vs v2

  • Some things that were included in the first book he decided not to include I the second
    • Eg Unidirectional vs bidirectional – not important
  • Some things he thought were too trivial for the first book, he has now changed his mind about and included
    • Eg moving statements within a function
  • Most notable changes = no longer centrally object-oriented
    • “Extract function” used throughout instead of extract method
    • One of the refactorings is around the choice between OO and non-OO
    • The most visible thing here is the choice of language (javascript)
    • But language is not necessarily relevant anyway
  • OO vs functional
    • He doesn’t see that as a huge shift
    • OO should still have functional elements – referentially transparent
    • They are overlapping paradigms, not distinct

Favourite refactorings?

  • “Split phase”
    • Hunk of computation which can sensibly be divided into two phases with a data structure communicating between them
    • Eg parsing – separate the tokenising out – deal with a series of tokens instead of a stream of text
    • But if you split a loop, what if you are introducing performance problems? See below…

Performance and refactoring

  • Split loop is something people often worry about because it will run the loop through twice
  • Most of the time it doesn’t matter – a push for clarity will not change the performance of the code
  • Most of the time by refactoring you open up an opportunity for performance improvements you would never have noticed otherwise
  • Then again you should run performance tests frequently
  • Not necessarily with every build, but every day or two
  • But most micro-changes have no impact on performance
  • You will only find real performance impact by performance testing

Recommendations for other books?

Refactoring architecture:

  • Always have to ask, how do you make the smallest possible change?
  • Eg extracting a data-intensive microservice from a larger system
  • Most of the moves are happening within the monolith BEFORE you start firing up the external system
  • Then you move stuff in really small pieces
  • Things that change for similar reasons should be together – you need to see the relationship between them

Branching / trunk-based development

  • Develop on a branch and merge at the end, with branch being long-lived – days, weeks or months
    • Still a really common pattern
  • But if something has been refactored, you don’t find out until you merge – this can blow up on you
    • It means you become scared to refactor! There’s a disincentive.
  • Continuous integration: Integrate with each other fully at regular intervals – at least once a day
  • Every day you receive everyone else’s code changes and push your own changes back
  • Removes the big painful merge problem – not saving up for a big horrible crunch
  • Adage of Apollo – it hurts if you do it more often (?)
    • Sorry, I wrote this down but I’ve since Googled it and I don’t really know what it’s about – I may have misheard!
  • Open source development:
    • Actually this CAN be a good place to use branches, because everyone working separately and you can’t guarantee all changes should be merged
  • People call it trunk-based development but “continuous integration” is a better name because that’s what it’s really about
  • People worry about continuous integration but it’s less painful than they think
    • If you do integration every day it becomes easier and less painful until you stop even noticing

Responsibility

  • Keep code base in healthy state
  • If not you are stealing from colleagues, clients and employers!
  • But no point saying you should do it for moral reasons, that won’t motivate people to do it
  • It’s economic: Want to get more changes out more quickly
  • It’s professional: We’re being paid to produce features rapidly
  • It’s not up to managers or business: They don’t know how to keep code healthy – that’s what they pay us to do

Refactoring and design patterns – are they incompatible?

  • With a lot of patterns, you shouldn’t introduce them right away cos they’re not appropriate and you don’t require the full strength of them yet, particularly the more complicated ones
  • Introduce patterns as a result of refactoring: Refactor towards them
  • This was recognised by the original Design Patterns authors (Gamma, Helm, Johnson, Vlissides)
  • Also Josh Kerievsky: Refactoring to Patterns

Code smells

  • Code smell of the week!
    • “This week we will look at long methods” – whenever we find them we try to refactor them

When not to refactor!

  • Code that is never touched
    • Sitting behind an API, working quite happily, doesn’t need to change – doesn’t matter if it’s a mess!
  • Don’t clean code all in one go – just a little bit more every time you go in
    • Over time that will concentrate your efforts where they are most needed – ie areas modified most frequently

Refactor as a step in the red-green-refactor cycle

  • You should only refactor when tests are green
  • Sometimes that means you have to remove a failing test, refactor, then put the failing test back in again
  • Ralph Johnson, John Brant, Don Roberts wrote the first Smalltalk refactoring book (A refactoring tool for smalltalk?)

If you don’t have tests you can’t refactor?

  • “Probably safe” refactorings? Interesting route to go? Not a great thing for most people to focus on, requires a lot of expertise
  • For most people you should have tests as well – after all, how do you know whether you’re breaking what’s currently there?

Final takeaway:

  • Small steps, commit frequently.
  • Then you can always roll back.
Getting Started with .Net Core, ASP and WebAPI

Getting Started with .Net Core, ASP and WebAPI

I followed this tutorial, which is very good: https://docs.microsoft.com/en-us/aspnet/core/tutorials/web-api-vsc?view=aspnetcore-2.1

There were some gotchas though, so (as always) I made notes:

  • Whenever you add new code you have to stop running and rebuild before you can send successful requests.
  • When you do a POST, the port number is 5001 or 5000: It’s whatever you’re using in the browser for GET requests
  • When you add the Update method, you have to send another POST to create a new Todo item before you can update it. The url is the location field from the response of the POST.
  • When you add the Delete method, use the GET request in the browser to find the Ids of existing items so you know what you can delete. The url is the same as the Update url, with appropriate Id added on. Use the GET request to check whether deletes have worked. Use the POST to add elements you can then delete.
  • When you add a new database context you need to update the dependency injection stuff in Startup.cs and you need to make sure your POCO class has an Id property.

See also the following two posts:

Converting a .Net Standard console app into a .Net Core console app

Converting a .Net Standard console app into a .Net Core console app

If you have a simple .Net console app and you’d like to convert it into a .Net Core app so that you can run it from the command line on any platform (as long as you install .Net Core), here’s what to do:

  • Remove the following files and folders from your project:
    • Bin folder
    • Obj folder
    • Packages folder
    • Properties / Assemblyinfo.cs
    • config
  • Create a new temp folder and run this command in that folder: dotnet new console
    • Take the csproj file created by that command and use it to replace the csproj file in your original project (using the name of the original csproj file).
    • !! If your original csproj file was in a nested folder, the new csproj file will have to be in the root.
      • But your program.cs file can stay where it was.
      • Or you can create a *.sln folder at the root level and add references to any nested csproj files.
        • To create a sln file: dotnet new sln
        • To add a csproj file (in a nested tests folder) to your sln file: dotnet sln add .\tests\tests.csproj
    • Command line: dotnet restore
    • Now you can build and run the new project from the command line: dotnet run
  • Check the old project for packages to include:
    • Look in packages.config
    • For instance, if you see a line that looks like this:
      • <package id=”NUnit” version=”3.11.0″ targetFramework=”net452″ />
    • …you need to run this on the command line: dotnet add package nunit -v 3.11.0
    • !!! If NUnit is one of the packages, you need to do some extra actions – see Adding NUnit tests to a .Net Core console app.
  • Gotchas:
    • You can’t build and run a console app in Visual Studio if the code is in Google Drive. You’ll get a very generic uninformative error – “Unable to start program … refresh the process list”.
    • If you try to add the NUnit package manually, you may get errors. Follow the actions in Adding NUnit tests to a .Net Core console app to fix.
      • Otherwise you may get the following errors:
      • 1) “Unable to find tests” Fix this with the following command (check version – this was Oct 2018): dotnet add package Microsoft.NET.Test.Sdk -v 15.7.2
      • 2) “Program has more than one entry point defined”. This is fixed by adding the following sub-element to a <PropertyGroup> element in your csproj file:
      • 3) “No test is available”. Fix this by adding the NUnit3TestAdapter package (at time of writing – Oct 2018 – this was version 3.10.0).

See also the following post:

Feelin’ Groovy (“Unable to resolve class” or “Configure Groovy SDK”)

Feelin’ Groovy (“Unable to resolve class” or “Configure Groovy SDK”)

I was working with some Groovy scripts in IntelliJ today – a first for me. I came up against a couple of simple getting-started issues… I’m just making notes about them here. There are notes here on two errors I came across: “Unable to resolve class” and “Configure Groovy SDK”.

  1. “Configure Groovy SDK”:
  • On command line:
    • This: brew install groovy
    • Then to run a script: groovy path/to/file.groovy
  • In IntelliJ:
    • Install the groovy plugin
    • Open the folder containing the scripts
    • When it says “Groovy SDK is not configured for module ‘my-module’” or “Configure Groovy SDK”
      • Click the link with the “Configure Groovy SDK” message (top right in IntelliJ)
      • Click Create
      • (Find your Groovy installation:
        • On the command line: brew ls groovy
        • This will give you something like this: /usr/local/Cellar/groovy/2.5.2/bin/groovy
        • Then you need to find your libexec folder – probably at same level as bin folder – in my case it’s here: /usr/local/Cellar/groovy/2.5.2/libexec)
      • Find the libexec folder, select it and click open
      • More here: https://stackoverflow.com/questions/46123890/configuring-groovy-sdk-within-intellij-idea
    • Now you can run a Groovy script by clicking the big green Play button, top right
    • To pass parameters into a script:
      • Top right, click the little down arrow next to the name of the script
      • Click Edit configurations
      • Fill in Program arguments

 

2. “Unable to resolve class” 

  • This can happen when your classes are in a package and you try to run your script from the command line.
  • It will start in the folder the class is in, then from there it will look for a further folder structure – eg if your package is clare.is.cool then it will look for the folder structure clare/is/cool from the path of the groovy script.
  • The solution is to set the classpath on the command line when running the script, and start further back in the directory tree.
    • For instance if your class is here: c:\overall\path\clare\is\cool\MyScript.groovy
    • Then you run it like this: groovy -cp c:\overall\path c:\overall\path\clare\is\cool\MyScript.groovy
    • (or if you have already navigated to c:\overall\path\clare\is\cool, you can just run groovy -cp c:\overall\path MyScript.groovy)

More here: https://stackoverflow.com/questions/45072923/groovy-unable-to-resolve-class