Well, that weekend sure flew by, didn't it?
We had a nice change to the routine in that we spent Saturday entirely at home -- we usually have to go to Dundee so the kids can attend their Pokemon/YuGiOh game clubs (they alternate weeks), but neither club met this weekend. So yay! The big news of that day was getting our Nordic Track elliptical machine built. It took two hours, but overall I have nothing but praise for how easy it was to put together. We had hoped that selecting such a well-known brand would result in the quality we wanted, and so far it seems we were right.
Of course, this morning was my first day actually trying to exercise on instead of with it, and I managed a whole six minutes. This was not from aerobic unfitness mind you, but leg weakness. I didn't get out of breath, my legs just ached too much to continue for long. But I suppose the upside is that even at 6 minute increments I should see my strength increase at a good rate. However, I need to stay mindful that if I try to do too much too fast I will seriously crash and burn. And then I'll set myself back days. The difficult part is that I seriously enjoy using an elliptical machine. It's always been my favourite bit of gym equipment and it's a tad annoying that I can only use it for about two 80s songs before my legs say "enough!" ;-)
I read snippets of The Pragmatic Programmer twice last week and plus today, but never got around to writing it up until now. Still taking it on faith that I'll ever use their advice, but here it is.
Tip #36: Minimize Coupling Between Modules
Tip #37: Configure, Don't Integrate
Tip #38: Put Abstractions in Code, Detail in Metadata
Tip #39: Analyze Workflow to Improve Concurrency
Tip #40: Design Using Services (independent, concurrent objects), Not Components
Bend or Break: Flexible Coding
- minimizes coupling between modules
- tries to prevent you from reaching into an object to gain access to a third object's methods
The Law of Demeter for Functions:
- states that any method of an object should call only methods belonging to:
- itself
- any parameters that were passed into the method
- any objects it created
- any directly held component objects
Write wrapper methods that forward requests on to delegates: this makes code more adaptable & robust, but costs more in runtime and space overhead. Must balance these based on other program requirements.
Meta Programming
No amount of genius can overcome a preoccupation with detail. -- Levy's 8th Law
Make code soft: easily adaptable to change
Make systems highly configurable: choice of algorithms, database products, middlewear tech, user-interface style
Use Metadata: data about data; any data that describes the application
Think declaritively: WHAT is to be done, not how.
- forces you to decouple your design which results in more flexible and adaptable programs
- forces you to create a more robust, abstract design by defining details
- you can customize the application without recompiling
- metadata can be expressed in a manner much closer to problem domain than general purpose program language
- you may even be able to implement several different projects using the same application engine but with different metadata
Temporal Coupling
Time as an element of software architecture
Concurrency - things happening at the same time
versus
Ordering - relative positions of things in time
** Being more flexible means more concurrency, less ordering -- less focus on time. **
Design for Concurrency: Objects must be thread safe and present a consistent state.
If we design for concurrency, we can more easily meet scalability or performance requirements when the time comes. And if the time never comes, we still have the benefit of a cleaner design.