I’m about to move subscribers from the old domain host to the new one. The url remains the same, it’s just that the domain is now self-hosted.
Email subscribers will continue to receive email notifications of new posts as before, but WordPress.com followers will only see new posts in the Reader. They will not receive email updates unless they subscribe to receive those on the new site, which they can do via the Subscriptions widget at the bottom of the sidebar.
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
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
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
I got confused after using the word “his” to explain the genitive case of the definite article (here).
It’s especially confusing because the possessive pronoun for 3rd person plural (ie “their”), is the same word (“τους”) as the accusative form of the definite article for male plural (here), but NOT the same as the genitive form of the definite article for male plural (which is “των”).
Anyway, just to note that the definite article and the possessive pronoun are often, but not always, the same.
Ha. This is quite funny really. I started this blog thinking I would use it to store all the gazillions of notes I make about code-related matters. But I make notes about EVERYTHING.
I can’t resist posting this one here. Just in case some random person finds it useful (see image above).
I bought a kit from Amazon, but the instructions were pretty woeful and at first I was rather mystified. But eventually I pieced it together made that image (^^), printed it out and put it in the box with this press stud kit:
I’m a bear of little brain, and when I encounter a concept for the first time I need it to be explained in simple terms with very clear examples. If I can’t find such an explanation, I will attempt to write it myself and place it here.
Sometimes even if I do find a simple summary, I’ll re-explain it in my own words to consolidate my own understanding.
I make no claims for the accuracy of my understanding, and I welcome corrections and clarifications in the comments box.