Sunday, January 17, 2016

The Book of F#, Chapter 1: Meet F#

This chapter is really covering the basic points about how to lay out an F# file, and what the language does at a high level. That said, there are some pretty big differences from C# that are worth pointing out.

As well as being a functional-first language, F# is a full-featured OO language with some imperative constructs also available. I’m not sure whether this will turn out to be something that I like or not, but it’s worth bearing in mind.


Files and (lack of) folders

In terms of immediately noticeable things, there are a couple of quirks with the project hierarchy: there are no folders, and files are executed in the order in which the appear in the project. Thus, dependent items must be declared in files below their dependencies.

The benefit of this is that the compiler can infer much more about your code and give unrivalled type inference. It also avoids recursive definitions. Both of these seem like good things! I haven’t been caught out by the execution order yet but I’m sure that day will come.

Though not explicitly stated in the book, it also seems to encourage the user to create small projects . Imagine a project that has 5 folders, each with 5 source files in — a fairly common occurrence in C#, but the idea of having 25 files in a single-level hierarchy and making sure they are in the right order scares me.


Whitespace matters

Whitespace is also significant - code inside a block must be further indented than the opening line. I’ve found this to be annoying, to be honest. I can understand the reasoning behind it (no curly braces!!) but I’m just not used to it yet. This is especially obvious when pasting in code snippets from the book: having to change the indentation of the block block can be cumbersome. A simple example of this nesting from the book is:

let isEven number =
  if number % 2 = 0 then
    printfn "%i is even" number
  else
    printfn "%i is odd" number

We can group by namespaces and modules. Namespaces look pretty much as they don in C#. To my eyes, a module looks analogous to a C# class, but I might prove to be mistaken by the end of the book!


It returns results!

The next important point is that F# is an expression-based language; nearly everything that is evaluated returns a result. This contrasts with C# where only non-void methods do so! One corollary of this is that basic blocks such as if statements need to be looked at in a different light: they return a result! Going back to the previous code snippet, it means that we can write the routine as:

let testNumber = 10
let evenOrOdd = if testNumber % 2 = 0 then "even" else "odd"
Console.WriteLine evenOrOdd

In this simple example we could have done the same in C# using the ternary conditional operator

var evenOrOdd = (testNumber % 2 == 0) ? "even" : "odd";```

but that’s certainly not so in more complex scenarios.


Entry Points

Getting into an application is a bit different too: we define an [<EntryPoint>], rather than a Main method in C#. This is a bit nicer for me than C# as it gives more control over naming:

[<EntryPoint>]
let MyProgram argv =
  // do some stuff
  0

It’s also worth noting that here, as everywhere else in F#, the compiler assumes that the last expression evaluated is the return value. This means we don’t need to use a return keyword. I’m undecided on this one yet, as I think that using return makes it really obvious when you want to exit a routine.


The Reverse Polish Notation calculator

The chapter finishes with a great example that showcases some of the most powerful features of F#: pattern matching, concise syntax, type inference, and recursion. It introduces a basic parser that can take a string defined in Reverse Polish Notation and perform the required computation.

This would normally be done by creating a mutable stack and pushing/popping from it:

  • split the string into a list of characters;
  • push characters onto the stack until we see something that looks like an operator;
  • when we get an operator, pop twice from the stack (these will be numbers);
  • apply the operator to thee two numbers;
  • push the result onto the stack;
  • repeat until our input list is empty;
  • pop the last remaining number from the stack, which is our result.

I’m not going to write the C# code for this, but it would no doubt require an Enum for the operators, a Stack<int>, a while loop, and some other stuff. What I will do is copy the code from the book (which can be found from the book’s homepage if you want to dig into them:

module TheBookOfFSharp.RpnCalculator

open System

let evalRpnExpr (s : string) =
  let solve items current =
    match (current, items) with
    | "+", y::x::t -> (x + y)::t
    | "-", y::x::t -> (x - y)::t
    | "*", y::x::t -> (x * y)::t
    | "/", y::x::t -> (x / y)::t
    | _ -> (float current)::items
  (s.Split(' ') |> Seq.fold solve []).Head

No stack, no loop, no enum.

It’s different, for sure, and if you’re new to F# and functional programming in general I bet you’ve got no idea what’s going on!

Let’s say the input to this function is the string "4 2 5 * + 1 3 2 * + /". The first thing that happens is it gets turned into an array of characters via (s.Split(' ').

So far, so C#. What happens next is a bit trickier to read: the array that we’ve just created gets sent to the function Seq.fold as its third parameter (the function solve is the first, the empty list [] is the second).

What this will do is recursively call solve taking in a list called items (think of this as our stack!) and a single value from our original array of characters, and do this until there’s nothing left. The empty list just tells it what to initialise items to.

Lastly, the solve function does the business. It uses pattern matching (match) to say that: if we have an operator (one of "+", "-", "*", "/") as the incoming current character, and if the items list has at least two things in it (i.e. it is of the form y::x::t), then remove the first two things in items, apply the operator to them, and stick the result back on the front. In the case that we don’t match this pattern (i.e. we have a number), just stick that in items.

Running through our example, we will therefore:

  • Put 4, 2 and 5 into items
  • Take 5 and 2 out, multiply them (*), and put the result (10) in
  • Take 10 and 4 out, add them (+), and put the result (14) in
  • Put 1, 3 and 2 in
  • Take 2 and 3 out, multiply them (*), and put the result (6) in
  • Take 6 and 1 out, add them (+), and put the result (7) in
  • Take 7 and 14 out, divide them (*), and put the result (2) in
  • Finally, the Head command tells us to take the first things out of items: our answer, 2. (It works!!!)

Writing it in prose like I have just done, it sounds very similar to the enum/stack/loop form that we thought we didn’t have! Implicitly, of course, we still have all of these items, but it is striking to notice how we can express the computation in very different constructs.


Wrapping up

Most of what was in this chapter is ‘information only’. That is, it’s really useful to know, but there are no real ‘wow’ moments.

The example at the end of the chapter was somewhat more involved than I was expecting, and took me a few minutes to figure out what was going on. Once you see it, the code looks terse and elegant. Until that point, however, it feels slightly impenetrable to the outsider.


Next time, the F# interactive tool!

The Book of F# - Introduction

In my previous post I said that, as a means of reinforcing my own learning, I would be going through The Book of F# and giving my own thoughts on what’s inside.

Before I dive into the contents, let me answer a few questions.


What do I know already?

I’ve been programming in C#, the object-oriented big brother of F#, for the past two years. Whilst I am not yet expert in the language, I feel able to express what I need to in C# code.

On the other hand, I don’t feel fully comfortable with the object-oriented (OO) paradigm . My view on what software does is (perhaps overly) simple:

Data comes in one end, gets acted upon, and goes out the other.

The astute observer will notice that, whilst not incompatible with OO principles, this view is closer aligned to Functional Programming. The amount of scaffolding required to do a simple computation in C# often surprises me, and feels inefficient.

This combination makes F# attractive: a functional-first language that harnesses the power of the .NET Framework sounds like a great mix of simplicity and familiarity.

To boot, I also did Erik Meijer’s fantastic course on edX, Introduction to Functional Programming. This introduced me to some concepts that seemed to align closer with my logical reasoning about software, things like pattern matching and recursion.

Complicating matters further, my favourite bit about programming C# is having access to the System.Linq Namespace. Note the precise vernacular — I didn’t say that my favourite bit was LINQ (which I have never used, and never intend to), and I also said ‘having access to…’. This is because the bits that I like are actually part of the .NET Framework, and so can be used by any language that runs on the CLR, including F#! (yes, I know that they can’t be used in the same way because they use C#’s extension methods, but we’ll come to that).

So here I am: a C# developer that doesn’t quite feel natural writing fully object-oriented code, loves the functional-style of the extension methods on IEnumerable<T> with their expression trees and lambdas, and has had a taste of ‘pure’ functional programming via some basic examples in Haskell.

Time to go functional, then?


Why am I learning F#?

It’s quite a simple reason, in a way. There are bits of C#, bits of .NET, bits of functional programming, bits of object-oriented programming, all of which I think are great. Wouldn’t it be awesome if there was a language where I could use all of them?

And that is the question I am truly asking: is that language F#? On the face of it, it could be. On the other hand, it could be that it combines the worst bits about all that I mentioned above! It’s worth figuring out, though.


What am I trying to get out of the book?

The answer to my question!

This may be flippant, but it sums it up. I’m looking at the book as a window into the language from the perspective of an experienced C# developer:

  • How does the syntax compare: it is more natural, less natural, or about the same?
  • What about functionality: how does it integrate with the .NET Framework?
  • Does it help with writing complex or long-winded calculation routines?
  • How are the elements of functional programming and object-oriented programming interleaved?
  • Is it possible to build enterprise applications with it?
  • Are there enough tools available to ensure code quality?

These can be combined:

Would I write a new project in F#?

If I can give a good answer to that by the end of the book, I will be happy.


And so to the book.

The Foreword and Preface got me hooked straight away. Both the author Dave Fancher and the technical reviewer Brian Hunter talked about their journey into F# in strikingly similar fashion to my spiel above. Dave was a C# developer who loved LINQ but hated the verbosity of C#; Brian is another functional convert who is furthermore convinced that OO programming is harmful, spreading of the dangers of mixing data with behaviour.

The best sentence was actually a printing of someone else’s quote, so I will cross-reference it here (source Joe Armstrong):

“You wanted a banana, but what you got was a gorilla holding the banana and the entire jungle.”

That chimes with some of my gripes about C# — I find it a constant struggle not to end up passing around references that refer to, essentially, an entire jungle.

Next came a short introduction, where we learnt about F#’s interoperability with other .NET langauges as well as its functional-first approach. Again, these are two points that really make the language appeal to me. I already use lots of the .NET framework (familiarity), and am able to tie in functional concepts with my own way of logical thinking (simplicity).

From here, the book is organised into twelve chapters, each building on the last. To help move around them, here’s a copy of the table of contents, with links updated as I write the posts:

After these are all done, I’ll refer back to this post with an answer as to whether I would use F# for a new project or not.

Saturday, January 16, 2016

Another Kind of Training

It’s safe to say there’s been more action in my life off this blog than on it for the past few years. Cycling has been and gone; I’m sure it will return at some future date.

What is here to stay though, is code. Software is eating the world and I am no exception — what started off as a means to an end is now a nascent career as I’ve been working as a Software Developer for just over two years.

There are tens of thousands of software blogs already out there, yet here I am starting up another.

Why?

In this decade there is such proliferation of information. It has been quoted that we see more information in one day than our ancestors saw in their lifetimes. I find myself more and more often asking myself: how much of what I’ve read, watched or listened to has actually sunk in?

I suspect the answer is not very much. As someone who thrives on knowledge and learning, this frustrates me. What do I have to show for the ten hours a day spent at work writing code, reading blogs and articles, not to mention the time spent generally skimming twitter for other interesting developer tidbits? In the past year alone I have ‘learnt’ so much, only for most of it to fail to penetrate my long-term knowledge base. To give this some scale, I’m pretty sure I’ve watched all of the videos, done all of the courses, and read all of the books listed below:

Online Courses

Exploring C# 6 with Jon Skeet
Algorithms: Design and Analysis
Erik Meijer: Introduction to Functional Programming
M101N: MongoDB for .NET Developers

Other videos

Martin Fowler: Introduction to NoSQL
Joshua Bloch: How To Design A Good API and Why it Matters
Brian Fitzpatrick & Ben Collins-Sussman: The Myth of the Genius Programmer
Robert C. Martin: Clean Architecture and Design
Jon Skeet: Abusing C#
Dr. Don Syme: Introduction to F#

Books

Sam Newman: Building Microservices
Pramod J. Sadalage & Martin Fowler: NoSQL Distilled
Glenn Block et. al.: Designing Evolvable Web APIs with ASP.NET

Blogs

Martin Fowler: Bliki
Eric Lippert: Fabulous Adventures in Coding
Mark Seeman’s blog
The Clean Code Blog by Robert C. Martin

… and plenty more that I have forgotten entirely, not to mention those unrelated to software development!

This is where my blog renaissance comes in. Whilst I have ‘done’ all that listed above, my Definition of Done has been pretty nonexistent. I’ve made some notes, done a few exercises here and there, but most just passively watched a video or read an article and promptly forgotten 90% of the content.

Not any more.

From here on in, I will be consuming less, but learning more. When I dive into an in-depth book, online course, multi-part blog topic or video lecture, it’s going to be distilled here: a book will have a chapter-by-chapter breakdown; a course will have a prĂ©cis of the lectures along with exercise solutions; the salient points of a blog series will be summarised.

All of this will be for one reason, to ensure that I really learn this stuff. The act of crystallising and expressing my thoughts on a topic will require me to understand it at such a deeper level than just passive reading or viewing. Hopefully, along the way, people will read this and learn something too. Or at least very least, correct my mistakes and start up some engaging conversations.

So without further ado, let me introduce the first topic:

The Book of F#

Over the next eight weeks I’ll be going through the book, poking at its contents and summarising what I’ve learnt on here. I’ll explain why I’m going through this book, what I’m trying to get out of it, and how I will be doing so.

Monday, January 21, 2013

Training Summary: Transition, Week 2

It seems like I have slipped behind with these summaries, so expect them to come thick and fast over the next couple of days. The second half of my transition was over the New Year, and due to very good weather conditions for the time of year I spent the vast majority of time on the roads doing some longer steady sessions. I put in a bit of intensity - the 4x1' session on Thursday to start boosting my anaerobic capacity, and the 6x3' on Sunday to start VO2 max work (which will be a major goal in the following 8 weeks)

I had a few bike problems with punctures and a tyre blowout, but got a lot of training in and was quite tired by the end!

GOAL: As with Transition Week 1, no pre-set goal.

Monday: 75' steady + rollouts   

Data: ave: 225 W (237 NP), hr 141, cad 91   

Notes: Indoors on turbo so HR a bit elevated. Last 30' of first hour around 250-260 W before 4 x rollouts @ 320-350 W

Tuesday: 3h easy/steady   

Data: 2h44m, 17.1 mph, hr 134, cad 85   

Notes: Puncture half way so rode home on very soft tire (slow!!), also moved saddle down 5mm and forward a bit (road bike)

Wednesday: 3h easy/steady   

Data: 3h15m, 17.9 mph, hr 136, cad 87   

Notes: Lack of puncture definitely made it faster! Headwind-ish for the majority of the way out, then tail for last 20 miles

Thursday: 2h inc 4x1' @ 170-200%   

Data: Pieces: 1: 562 W, 2: 527 W, 3: 518 W, 4: 548 W   

Notes: Done into headwind between Fencott & Murcott. Solid numbers but looking to hit 600 soon.


Friday:
2h easy   

Data: 1h53m, 17.4 mph, hr 133, cad 86   

Notes: Recovery spin, felt sluggish to begin with.

Saturday: 2h steady   

Data: 1h49m, 17.1mph, hr 144, cad 83   

Notes: Solid steady ride then massive tyre blowout related adventure. Messed around on the turbo for 20 mins on the TT bike too

Sunday: 6x3' @ 115-120%   

Data: 1: 385 W, cad 96, 2: 382 W, cad 95, 3: 386 W, 89 rpm, 4: 384 W, 93 rpm, 5: 380 W, 91 rpm, 6: 392 W, 93 rpm   

Notes: Trying out head tuck position, seemed ok. Need to fix speed sensor to TT frame though! HR also playing up. Interval 4 felt best cadence wise.

Bike Totals: 15h16m, 810 TSS

Summary: Lots of good mileage in, but I definitely don't have the time to be doing this every week!

Monday, January 14, 2013

'The **** that kills'

Referring to a thread on the informative Google Group 'Wattage', this is the idea that training at the 'Sweetspot' intensity is the best way to improve your power numbers during the winter.

Put simply, the Sweetspot as defined by Dr Andrew Coggan is demonstrated by this graph:


The idea is that there exists a region that lies somewhere around 85-95% of your FTP in which you are able to:

1) train extensively in this region on any given day
2) repeat such sessions on a day to day basis without accumulating large amounts of fatigue
3) increase your threshold power when already reasonably fit

Returning to the Wattage thread, the author recounts his anecdotal evidence of significant training in this zone. His routine consisted of doing a turbo session every day from Monday to Friday that included 2x20' intervals ranging from 85-92% FTP, followed by a long steady ride on Saturday and a ride with some harder work on Sunday. He comes to the conclusion (paraphrased in the title) that the training is extremely effective.

At first glance, it seems to me that following this protocol means you miss out on training at your race pace intensity (let's say you are training for a one hour race that you will complete @ 100% FTP). This breaks one of the seemingly fundamental tenets of athletics, that you 'train how you race, race how you train', i.e. that honing in your race pace is of great importance to achieve success.

Combining this with the table below which outlines the expected physiological adaptation from training at certain zones (again from Dr Andrew Coggan), it would seem that removing race pace work from your program is not the ideal way to go.


Adaptation\Zone Z2 (60-75%) Z3 (75-90%) Z4 (90-105%) Z5 (105-120%) Z6 (above 120%)
Increased Lactate Threshold ✓✓ ✓✓✓ ✓✓✓✓ ✓✓

However, having considered the matter following my own 12 week base period in which I did sessions of various types at intensities anywhere between 80-100% of FTP, I can see some clear benefits to the 'Sweetspot' approach that go beyond the realms of physiology.

I am, of course, referring to the mental benefits of such training. I will give two examples that I believe illustrate the superiority of Sweetspot training over Threshold training:

1) 2x20' on the turbo

I am using this because it was the session outlined in the 'Wattage' thread, and also because it is common for cyclists to do 2x20' @ 100% FTP on the turbo.

Doing this session at 100% is tough. Although this isn't necessarily a bad thing, I think that:

- If you have to use a large amount of motivation and willpower for your regular turbo sessions, the risk of 'burnout' is increased.

- Doing this twice a week is thus about the maximum possible, and so you are only getting in 80' of work at your FTP

- On a given day during a hard training block, you won't be able to sustain 100% FTP for the whole hour that you could if fresh and rested - the number is probably more like 30'.

- As such, you leave the session feeling like there is no way that you could sustain that power for a whole hour!

At 90-95%, these negative issues are removed. The session is mentally very easy at 90%, and a bit tougher at 95% but still very comfortable. It's easy to see how you could carry on at that wattage, and you aren't left dreading your next turbo session. Doing it 5 days a week is manageable, giving you 200' of work at these intensities. 

2) 2 hours, including 60' @ 90% on the road.

The Sweetspot intensity comes into its own in this session. As a relatively new time-triallist, the thought of going hard for a whole hour can be daunting.

The pacing bands are so small - 5% too hard and you will be done after 20'. 5% too low and you will lose a minute or possibly more, which is not good for an important race.

However, this minute loss for going too easy isn't that much from a training perspective. If we increase the pacing 'mishap' to 10% too easy, then you have essentially done 60' @ 90%. The figure isn't exact, but you are likely to only gain 2:00-2:30 were you to do the course @ 100% (assuming constant pacing, flat course, no wind).

As such, you can establish a great baseline for your race pace by doing the session outlined. If the course has hills, you will be able to get some idea of how if will feel on the day to push a bit harder on them. If there is wind, you will be able to tell what that might feel like, too.

Not only that, but you will complete the course in a decent time, with total confidence that you can repeat it on race day. For example, if you are aiming to do a 25 mile TT in 57-58 minutes, you will ride 60 or 61 minutes for the course @ 90% (with kind-ish weather conditions).

From this starting point, you can identify where those last 3 minutes of improvement will come from. Sure, they will come from putting out 10% more watts, but the where and how you will put down these extra watts becomes more obvious.

On an undulating course, you might decide that you will stick to this 90% value on the flat sections and push on to 105% or perhaps a bit more on the uphills.

On a windy course, you may decide that you only need to ride at 90% with the tailwind, and 105% with the headwind.

On a flat course, you might decide that your baseline moves up to 95%, saving those last few watts for any small inclines and potentially for the last quarter of the race in which you ride at a minimum of 100%.

Overall, having this 'worst case scenario' (this is, only riding at 90% FTP for a 25 mile TT) already under your belt in training means that you will never lose more than a couple of minutes from your best possible time in a race, and that you are likely to figure out how not to lose these couple of minutes pretty quickly.

Summary

Sweetspot training has both physiological and mental advantages vs threshold training

- On the turbo, it is repeatable and requires less willpower (of which everyone has a finite amount)

- On the road, it establishes a baseline for your performance that you have 100% confidence in being able to achieve on race day.

Saturday, January 05, 2013

New Year's Resolutions

Everyone makes them, but few stick to them.

To me, the key is to be more specific than making a general, sweeping statement concerning some aspect of your life that you wish to improve. The classic 'eat better, drink less, exercise more' just isn't going to work in the majority of cases. Moreover, laziness is often quoted as the reason for the failure of these resolutions but is rarely the true cause.

To illustrate an alternative method, I will now make my own resolutions (a few days late, I know, but then I have done 15 hours of training and lost a kilo of weight since January 1st anyway, so I am not too concerned).

The process will be to isolate the aspect of life (mainly sport for me) that I wish to improve, find something specific within that I am not wholly satisfied with, and come up with a simple and realistic plan to improve it. By following this method, I will ensure that the things I resolve to do are things that I want to do, done in a realistic fashion.

Ad so, I will begin:

Nutrition:

- I am happy with my current weight, plus or minus a couple of kgs. As such, the effort required to lose weight is larger than both my desire to do so and the benefits that it would reap.

- However, diet quality is something that can suffer, especially when I am tired from training. The ease of eating a ton of bread or cereal to satisfy my hunger makes it something that I do too often given the lack of nutrients in these meals.

- My goal, therefore, is to reduce the amount of 'empty calories' that I take in after sessions. I have noticed that this relies heavily on satiety, which can be increased with protein and fat rich foods.

- My resolution is to have a thick protein shake with milk after all training sessions, along with a couple of pieces of fruit and a handful of nuts.

This should allow me to recover from the session without having 200g of carbs in the form of peanut butter sandwiches or wheat based cereal. I can then have a normal lunch or dinner in due course (my '3 square meals' tend to be balanced and nutrient rich with lots of veg, good fats, and moderated carbs anyway)

Core strength:

- I don't believe that my core strength is a big limiting factor in my performance. Therefore, I often skip my planned core sessions.

- I think that a cause of this is a lack of precise scheduling. I plan to do the sessions on the same days as my recovery rides (Monday & Friday) but inevitably forget.

- Incorporating a core circuit into the to my recovery rides, thus treating them as an integral part of the session, might go some way to improving my 'hit rate' with regard to the core work.

- My goal is to do 2 core workouts of 20 minutes each per week, every week.

- My resolution is to do them immediately before my recovery rides. Don't get on the bike until its done. If I have to cycle 20 mins less on a recovery day, then such is life.

Training:

- I tend to be well enough motivated to do my key workouts of the week, often on the turbo. However, when faced with medium or long roads rides and below average weather, I take the easy way out and sick to the turbo again

- For example, if I plan to do 2 hours with an hour of tempo, then it really should be done on the road in the TT position to get the right sort of practice in. On the turbo, the session end up being 90' (too short!) and I often don't do the whole hour of tempo in the aero bars due to the lack of comfort (restriction of hip movement on the stationary rig makes it uncomfortable, not a poor bike fit!)

- This is occasionally due to lack of daylight hours (easier to do it in the dark on the turbo at 5pm than on the road in the light at 2pm or in the morning) and occasionally due to the weather ('oh, it's a bit wet, let's not get the race bike dirty')

- When I have done these sessions outside, not only have I thoroughly enjoyed them, but I have found them very useful in terms of training effect. 3 hours on the road just isn't the same as 2 on the turbo, whatever others may say (a Watt hour is a Watt hour!)

- All that I need to do is figure out the best time of day for me to do these sessions. If its raining, I do own a rain jacket. It's light from 0800 to 1630 even at this time of year, that's enough time for a bike ride.

- If I am riding with someone else and they are expecting me, then I inevitably do the ride outdoors.

- My goal is to do my designated road rides actually on the roads

- My resolution is to plan these rides well in advance, preferably with a ride partner.

Training (II):

- I rely heavily on carbohydrates before training, which I think is more mental than anything else. I find it tough to contemplate a session before breakfast or if I feel I haven't eaten enough.

- During training I don't face the same problem, and am happy to do 2 hours or more with just water and BCAAs in my bottle.

- Not eating before a morning session, if its not intervals, will likely lead to a greater ability on the part of my muscles to use fat as a fuel source. This will certainly lead to better performance in longer endurance events, and may also improve performance at the lactate threshold (thought the research behind the second part is lacking)

- If I give myself time for breakfast before a planned morning session, I will end up eating it.

- My goal is to do any non-interval morning sessions in a fasted state.

- My resolution is to schedule these rides for such a time that I don't have time to eat, or to plan other things to do before the ride that will take the place of breakfast.

Racing:

- Studying photos of me racing, my head is often not in the most aerodynamic position, especially when I don't know the course that I am racing on

- I have gone to some effort to put the rest of my body in a good position, but the head is a significant source of drag that I haven't minimised.

- Whilst training, especially on the turbo, there is no obvious reason to put your head in the tuck position and a reason not to: it's uncomfortable! However, I am unlikely to adopt a position in a race that I don't use in training.

- During road intervals, I wear a different helmet and so again the impetus to achieve the correct position is reduced.

- My goal is to get my head out of the wind during races

- My resolution is to practise this whenever I use the aero bars in training and to wear my race helmet when doing intervals on the road, or even on the turbo if its cold enough.

Summary:

Analysing a small goal in the method presented above will lead to a resolution that is Specific, Measurable, etc (c.f. the traditional SMART goal setting system)

None of the areas I outlined require significant amounts of willpower to achieve on a regular basis, leaving all my willpower for those gruesome lactate tolerance sessions.

This will ultimately make it much more likely that the resolution is stuck to. A broken resolution does more harm than the good intention behind its conception.

Tuesday, January 01, 2013

Training Summary: Mid-Season Transition, Week 1

You won't find this part of the training year in the textbooks, but I think it's a great way to keep things going over the Christmas and New Year period. The idea came from my rowing background, whereby we would put in three months of predominately steady-state type training in running up to the middle of December, and then have 10-12 days to train on our own before resuming squad training in the New Year.

The New Year work would typically progress quite quickly into work at race pace and above. In between, I always found it most valuable to try and mix up the training and do things that we didn't normally do during squad training. Since squad training consisted of 2 sessions a day with long blocks between steady and threshold intensities, I would try and stay clear of this range and do some harder training above threshold along with some work at the low end of steady.

I found on a number of occasions that this worked not only to make me feel fit and strong after the Christmas break, but also to recharge my mental batteries. As such, it is something that I will implement in my bike training.

The basic idea is not to stress too much about getting in work at certain intensities. Go out and so some steady work, but also do some high intensity bursts to try and wake up my anaerobic system after 4 months of dormancy. This is reflected in my (rough) plan for the fortnight (as always, at https://docs.google.com/spreadsheet/ccc?key=0AheXzGGp8uk3dEhoU19KZmhGTzVISmQ3ZVRIbTZYV0E#gid=1)

GOAL: None, really. Should be clear from the above that goal setting is not necessary.

Monday: Turbo 1h45 steady

Data: 224 W (228 NP), hr 135, cad 93

Notes: Got a bit wet towards the end.

Would have preferred to go for a spin on the roads as it was a medium day post-race but it was showery, so I stuck with the turbo (and still got caught in the rain). Standard session.

Tuesday: Turbo 60' + rollouts

Data: 200 W (221 NP), hr 131, cad 92. Rollouts varied from 300-400 W

Notes: Christmas morning. Intended to be a tune-up session before the Boxing Day TT.

Wednesday: 12 x 1' on 1' off @ 300-410 W (up 10 each time)

Data: See WKO file (http://tpks.ws/72rF)

Notes: All done in TT bars, fun little session.

Definitely in keeping with the spirit of this fortnight's training. I got up far too late to go to the TT so decided to start off at a solid threshold-type level and just increase the power each minute until it got significantly harder. Perhaps not the kind of session that will elicit long term sustainable progress, but I only had 40 minutes and it got me breathing hard.

Thursday: am: 90' steady, pm: 50' inc 25' @ 85%, 10' @ 100%

Data: am: 228 W (238 NP), hr 137, cad 88. pm: 25' @ 282 W, hr 158, cad 91, 10' @ 308 W, hr 169, cad 88

Notes: am: very windy & the odd puddle. pm: last minute of the 10 had dodgy wattage, true avg maybe 305

Put in a big day of training after the Boxing Day indulgence that was our family party. My initial plan was about 2 hours of solid work on the road but I again got up a bit late and only had 90 minutes before brunch, so stuck the bike on the turbo before dinner to do a second session with some moderate intensity in it.

Friday: Turbo 85' inc 6x1' @ 310, 350, 390, 430, 470, 510 W

Data: See WKO file (http://tpks.ws/U0my), but final minute @ 532 W

Notes: Done in base bars, last couple were pretty hard. 4' rest in between.

This was to be 4x1' anaerobic, and so I decided to put in a couple of easier minutes in to get warmed up, as well as allowing me to feel my way into these high power intervals as I haven't done them using a power meter before. In the future these sessions are going to be much harder, but at least I now have some idea of what I can do. I think 500 W for all four pieces is a good target for next time around.

Saturday: 2x20' @ 90%

Data: 1: 285 W, hr 166, cad 87, 2: 289 W, hr 171, cad 89

Notes: Felt pretty shocking.

No idea if that was due to fatigue or dodgy power readings or food or whatever, but the numbers were well down for the RPE - felt almost like threshold!

Sunday: 2 x tabata (8 x 20'' on MAX, 10'' off easy)

Data: See WKO file (http://tpks.ws/LQRz)

Notes: 500+ to start, settling around 460 once up to speed.

Had about half an hour to train in (again). Decided in the interest of tiring myself out to do some old-fashioned HIIT. Went with the Tabata protocol as I know that it ruins you pretty quickly, especially with the large amount of torque required to speed the turbo wheel up 8 times in 4 minutes!

Bike Totals: 9h08m, 562 TSS

Summary: Always a very busy week with lots of distractions from training, but I think I managed a solid effort.