News aggregator

Chris Lamb: Estimating Training Stress Score (TSS) for running on Strava

Planet ALUG - Tue, 18/02/2014 - 21:17

In cycling, a ride's Training Stress Score is a function of that ride's duration, average power and the intensity of the ride relative to the rider's capability. This Slowtwitch article provides a good overview on how intensity and TSS is calculated on a bike.

However, having TSS values for other sports allows a multisport athelete to take into consideration the physiological cost of activities in different sports. This is achieved by ensuring, say, 50 TSS on the bike "counts" the same as a 50 TSS run.

This can be used to simply determine the length, intensity and scheduling of an athletes next workout (to ensure adequate recovery) regardless of the combination of sports, or to identify the athlete's long-term tolerance to—and targets for—training load using metrics such as Chronic Training Load.

To make this possible when using Strava, I wrote a Chrome extension that estimates the TSS score of a run from its Grade Adjusted Pace distribution:

The "TSS (estimated)" value is calculated by the extension.

Source code is available. If you found this Strava extension useful, you might like my extensions to quickly switch between metric and imperial units or to change the default comparison filter.

Categories: LUG Community Blogs

Dick Turpin: When can I have them?

Planet WolvesLUG - Tue, 18/02/2014 - 13:29
Here's a good one.
Ask me to look at the prices of my quotation. "Can you do anything on the price?"
Ask me for slightly higher spec's. Aye? You just asked me to cut the base price?
Ask me for a delivery date as well. How the feck would I know when I have no idea what you're ordering?
Categories: LUG Community Blogs

Chris Lamb: The effect of pedestaling on TT bike position

Planet ALUG - Tue, 18/02/2014 - 00:19

To "pedestal" an aerobar means to elevate the bars above the basebar using risers instead of using headset spacers:

David Millar, 2010 Giro d'Italia.

You might do this for a few reasons:

  • The rider is in a more aerodynamic position when cornering or descending on the basebars.
  • Lowers the rider's centre of gravity, improving cornering confidence.
  • Less flex when climbing or accelerating under high wattage.
  • Teardrop-shaped risers are more aerodynamic than a cylindrical steerer tube:

So, assuming you currently have a bike that uses headset spacers, what would be the effect on your position if you were to replace, say, a 10mm headset spacer with a 10mm armrest riser?

First, let us consider the effect of removing the headset spacer. The crucial insight is that removing a 10mm spacer will not lower the stack height—ie. the vertical distance relative to the bottom bracket—by 10mm.

This is because spacers are not oriented perpendicular to the ground; they are stacked along the steerer tube at the head tube angle of the frame. We will assume a head tube angle of 72.5° degrees.

We can calculate that removing a 10mm spacer will reduce the stack height by:

sin(72.5°) × 10mm = 9.54mm

... and by the same argument it will also increase the effective reach—ie. the horizontal distance relative to the bottom bracket—by:

cos(72.5°) × 10mm = 3.01mm

Next, let us consider the impact of adding the riser. These are oriented perpendicular to the ground, so its addition makes no further change to the reach. However, we can now calculate the overall change in stack height:

Δ stack = -(sin(72.5°) × 10mm) + 10mm = 0.46mm

We can then repeat the calculation for any length of replacement:

Replacement (mm) Δ stack (mm) Δ reach (mm) 10 +0.46 +3.01 20 +0.93 +6.01 30 +1.39 +9.02 40 +1.85 +12.0 50 +2.31 +15.0 60 +2.78 +18.0

From this table, I can discover that if I were to replace 30mm of headset spacers with 30mm of risers it would:

  1. Increase my effective stack height by 1.39mm (likely neglible).
  2. Increase my reach by 9.02mm. This might require me to use a shorter stem to get the same position. If that was undesirable—for example, if was already using an extremely short stem—I might be forced to abandon the idea altogether.

Three further considerations must be noted:

  1. The resultant low height of the base bar could be quite drastic and prevent you breathing properly whilst climbing.
  2. Having the steerer tube cut down after to removing headset spacers will reduce the resale value of your bike.
  3. You might need to re-cable your brakes as you may have changed the distance the cables must span.

(It may seem odd to provide results for up to 60mm of headset spacers when such a large number of spacers would—at the very least—void one's warranty. However, I suspect such setups are transiently common within the confines of a fitting studio.)

Categories: LUG Community Blogs

Steve Kemp: My pastebin will now run under docker.

Planet HantsLUG - Mon, 17/02/2014 - 19:59

I've updated my markdown-pastebin site, to be a little cleaner, and to avoid spidering issues.

Previously every piece of uploaded text received an incrementing integer to describe it - which meant it was trivially easy for others to see how many pieces of text had been uploaded, and to spider all past uploads (unless the user deleted them).

Now each fresh paste receives a random UUID to describe it, and this means spidering is no longer feasible.

I've also posted the source code to Gitub so folk can report bugs, fork, etc:

That source code now includes a Dockerfile which allows you to quickly and easily build your own container running this wonderful service, and launch it without worrying about trashing your server ;)

Anyway other than the user-interface overhaul it is still as functional, or not, as it used to be!

Categories: LUG Community Blogs

Meeting at "The Moon Under Water"

Wolverhampton LUG News - Mon, 17/02/2014 - 18:00

53-55 Lichfield St
West Midlands

Eat, Drink and talk Linux

Event Date and Time:  Wed, 19/02/2014 - 19:30 - 23:00
Categories: LUG Community Blogs

Dick Turpin: Email expert.

Planet WolvesLUG - Mon, 17/02/2014 - 17:04
Customer: "My emails won't go I keep getting an email saying there's a problem."
Colleague: "Can you send me the bounce-back?"

A few minute later.

Colleague: "You've sent me the emails you're trying to send."

Categories: LUG Community Blogs

Adam Trickett: Picasa Web: 2014-02-16

Planet HantsLUG - Sun, 16/02/2014 - 19:09
Date: 16 Feb 2014
Number of Photos in Album: 1

View Album

Categories: LUG Community Blogs

Adam Trickett: Picasa Web: 2014-02-16

Planet HantsLUG - Sun, 16/02/2014 - 19:09
Date: 16 Feb 2014
Number of Photos in Album: 1

View Album

Categories: LUG Community Blogs

Adam Trickett: Picasa Web: 2014-02-16

Planet HantsLUG - Sun, 16/02/2014 - 19:08
Date: 16 Feb 2014
Number of Photos in Album: 1

View Album

Categories: LUG Community Blogs

Wayne Stallwood (DrJeep): Dancing Ferrofluid first test

Planet ALUG - Sun, 16/02/2014 - 19:03
First attempt, This is using a coil scavenged from an old hard drive. The real project I am working on isn't really about driving it with audio but I just wanted to see how it worked out.

Fed with half wave rectified audio. The coil impedance measured at approximately 6 ohms which was convenient as it's not that far from a loudspeaker coil.

Running it with a 60W amp meant that I only had about 30 seconds before the coil started to overheat. Quite fun though I might try a bigger coil or an array of more small coils.

Categories: LUG Community Blogs

Steve Kemp: Pastebin site with markdown support

Planet HantsLUG - Sun, 16/02/2014 - 17:47

Today I setup a new website:

Something I want, something I'll use, and something that might be useful to others?

Categories: LUG Community Blogs

Aq: More on an Ubuntu Component Store

Planet WolvesLUG - Sun, 16/02/2014 - 15:21

After yesterday’s musings on a “component store” for Ubuntu developers, a few people said “hm that sounds interesting, how would it work?” So I’ve thrown together a little demo.

I should be clear: this is a demo. It’s not a component store; it’s not for real use; you can’t add things to it; you can’t use it in your apps. This is just enough of a test implementation to allow people to talk about whether this is a good idea or not. None of the code I’ve written would be used in a real implementation, if such a thing existed: I don’t do any error checking, I don’t have any tests. It’s just to give a demo of what I think the developer experience of a component store might be like if it existed, which it does not.

First you need the utility which searches the store, which is called ucs. Get it with bzr branch lp:~sil/+junk/ucs-cli. You now have a utility named ucs which can search the component store for components you might find useful in your apps.

Next, an app which uses it. Grab a demo with bzr branch lp:~sil/+junk/ucs-demo-app. You can now load that app into the Ubuntu SDK editor, or just run it from the command line with qmlscene ucs-demo-app/UCSDemoApp.qml. If you do that, you’ll see that it’s missing components: UCSDemoApp.qml:3 "ubuntu_component_store": no such directory. So, the app needs components and they aren’t installed, which is correct. Change to the app’s folder and run ucs install.1

$ cd ucs-demo-app $ ucs install Installing RedButton

and now the app should work: qmlscene UCSDemoApp.qml shows an app with a red button in it. If you look at the source of the app in the ucs-demo-app folder, you’ll see two things that make it different from a stock app:

  1. import "ubuntu_component_store" at the top of UCSDemoApp.qml. This includes components installed from the UCS into the app. You don’t need to individually name the components you import: just import "ubuntu_component_store". The app can then use all the components it asks for, such as the RedButton {} QML Item.

  2. there is an ubuntu_component_store.json file in the app’s folder. This ships with the app, and it describes the components that this app uses. Basically, it is JSON like this: { dependencies: { RedButton: "*" }}, describing that this app requires a component called RedButton and doesn’t care about its version number (hence "*").

So the process for working on an app which uses components from the store is: get the app source, then ucs install. That will install all the components that the app requires, and then you can start hacking on the app.

The process for developing an app which needs components: if you want to add a component to your app-in-progress, then ucs list will show the list of all components (which in this demo is one, RedButton), and ucs install RedButton will install that component2 and update ubuntu_component_store.json to add it to your dependency list. So when developing, just ucs install ComponentINeed, and then make sure that ubuntu_component_store.json is checked into source control and that the ubuntu_component_store/ folder isn’t checked in.

Those of you who have worked with node.js and npm will be thinking: this looks a lot like npm. You are not wrong. I think that that’s an excellent model for building projects. There will be people who say “but what if I want the same component in two projects but I don’t want to have it on my disk twice?” Ignore these people. Make a component store which works on a project-by-project basis; it’s so much nicer. Clearly there’d need to be a bunch more work on all this: ucs search and ucs submit and ucs remove and a web UI to browse everything and API specifications and server scaling and re-running ucs install after you install a component in case that component itself has dependencies and deciding what happens if two components in the same project have the same dependency and actually paying attention to version numbers and, and, and. There’s a bunch of integration which could be done with the Ubuntu SDK editor: if your app ships with an ubuntu_component_store.json file, then run ucs install when you open it. Ship ucs with the SDK. Automatically add ubuntu_component_store/ to bzr ignore. Provide a graphical browser for the list of components. This is not an implementation: it’s a demo. A real version would need a decent amount of thought.

I don’t know whether this would actually take off. I don’t know whether there are sufficient people developing reusable components for Ubuntu apps to justify it. But I think that, if there are, then this might be a good way for someone to go about it.

  1. fill in a path to the ucs utility wherever you branched it, of course, or put it on your $PATH
  2. from wherever the store says it’s hosted. This RedButton component is on github, mainly because ucs downloads a zip file of the component and github helpfully provides them for you, which Launchpad doesn’t. Note that I think that components should not themselves be uploaded to the store; the store just stores a URL for them.
Categories: LUG Community Blogs

Aq: Bad Voltage, apps, and generic components for Ubuntu

Planet WolvesLUG - Sat, 15/02/2014 - 21:19

I wrote a very simple app for Ubuntu for Bad Voltage, the finest podcast in the land. It shows you the list of shows, and lets you play them. Simple. Streaming: there’s no downloading for offline use here, no notifications of new shows; it’s a little app, only. So the first thing you should do is go search for it on your Ubuntu phone and install it.

More interestingly, though, I tried to make this a generic app. That is: the actual code which defines this as a Bad Voltage app looks like this:

import QtQuick 2.0 import Ubuntu.Components 0.1 import "components" MainView { objectName: "mainView" applicationName: "org.kryogenix.badvoltage" automaticOrientation: false width: height: id: root backgroundColor: "black" GenericPodcastApp { name: "Bad Voltage" squareLogo: "" author: "Stuart Langridge, Jono Bacon, Jeremy Garcia, and Bryan Lunduke" category: "Technology" feed: "" description: "Every two weeks Bad Voltage " + "delivers an amusing take on technology, " + "Open Source, politics, music, and anything " + "else we think is interesting." } }

To make a similar app for your podcast, just fetch the GenericPodcastApp.qml file from the Bad Voltage app source, include it in your project, and then use the GenericPodcastApp component. Define a name, squareLogo, author, category, feed, and description, and that’s it; you’re done.

I’d love there to be a whole bunch of generic components like this. Something where I don’t really have to mind how it works, I just grab it from somewhere, drop it into my project, and use it. A QR code scanner, a QR code generator, a circular dial widget, an online high-score table. Obviously it’s possible to make reusable components right now, but there’s no market in them; what I want is something almost like the Ubuntu app store but for developers, where I can look for components, grab one, and insert it into my project, right from the Ubuntu SDK editor. One button-push should update any of these components that I have in my project; that way, if someone fixes a component I can rebuild my app to include it with ease. What I really want is the Ubuntu component equivalent of npm install, I think. The ultimate destiny of any such component is to be so useful to so many people that the Ubuntu core team lift it out of the component store and into the SDK, but it’d be great if it were easier to do this before things get to that stage, and the SDK can’t contain everything. I see no reason why some of these components couldn’t be open source and some sold for money, so there’s potentially an income stream there for Ubuntu developers who make reusable things. GenericPodcastApp is hugely trivial, but an example of the sort of thing that I think could develop. Any component which doesn’t use anything very Ubuntu-specific would work on other QML platforms too, and vice-versa, so the market could even be usable by developers across many platforms.

Categories: LUG Community Blogs

Laura Cowen: Monkigras 2014: Sharing craft

Planet HantsLUG - Fri, 14/02/2014 - 17:06

After Monkigras 2013, I was really looking forward to Monkigras 2014. The great talks about developer culture and creating usable software, the amazing buzz and friendliness of the event, the wonderful lack of choice over which talks to go to (there’s just one track!!), and (of course) the catering:

The talks at Monkigras 2014

The talks were pretty much all great so I’m just going to mention the talks that were particularly relevant to me.

Rafe Colburn from Etsy talked about how to motivate developers to fix bugs (IBMers, read ‘defects’) when there’s a big backlog of bugs to fix. They’d tried many strategies, including bug rotation, but none worked. The answer, they found, was to ask their support team to help prioritise the bugs based on the problems that users actually cared about. That way, the developers fixing the bugs weren’t overwhelmed by the sheer numbers to choose from. Also, when they’d done a fix, the developers could feel that they’d made a difference to the user experience of the software.

Rafe Colburn from Etsy

While I’m not responsible for motivating developers to fix bugs, my job does involve persuading developers to write articles or sample code for So I figure I could learn a few tricks.

A couple of talks that were directly applicable to me were Steve Pousty‘s talk on how to be a developer evangelist and Dawn Foster‘s on taking lessons on community from science fiction. The latter was a quick look through various science fiction themes and novels applied to developer communities, which was a neat idea though I wished I’d read more of the novels she cited. I was particularly interested in Steve’s talk because I’d seen him speak last year about how his PhD in Ecology had helped him understand communities as ecosystems in which there are sometimes surprising dependencies. This year, he ran through a checklist of attributes to look for when hiring a developer evangelist. Although I’m not strictly a developer evangelist, there’s enough overlap with my role to make me pay attention and check myself against each one.

Dawn Foster from PuppetLabs

One of the risks of TED Talk-style talks is that if you don’t quite match up to the ‘right answers’ espoused by the speakers, you could come away from the event feeling inadequate. The friendly atmosphere of Monkigras, and the fact that some speakers directly contradicted each other, meant that this was unlikely to happen.

It was still refreshing, however, to listen to Theo Schlossnagle basically telling people to do what they find works in their context. Companies are different and different things work for different companies. Similarly, developers are people and people learn in different ways so developers learn in different ways. He focused on how to tell stories about your own failures to help people learn and to save them from having to make the same mistakes.

Again, this was refreshing to hear because speakers often tell you how you should do something and how it worked for them. They skim over the things that went wrong and end up convincing you that if only you immediately start doing things their way, you’ll have instant success. Or that inadequacy just kicks in like when you read certain people’s Facebook statuses. Theo’s point was that it’s far more useful from a learning perspective to hear about the things that went wrong for them. Not in a morbid, defeatist way (that way lies only self-pity and fear) but as a story in which things go wrong but are righted by the end. I liked that.

Theo Schlossnagle from Circonus

Ana Nelson (geek conference buddy and friend) also talked about storytelling. Her point was more about telling the right story well so that people believe it rather than believing lies, which are often much more intuitive and fun to believe. She impressively wove together an argument built on various fields of research including Psychology, Philosophy, and Statistics. In a nutshell, the kind of simplistic headlines newspapers often publish are much more intuitive and attractive because they fit in with our existing beliefs more easily than the usually more complicated story behind the headlines.

Ana Nelson from Brick Alloy

The Gentle Author spoke just before lunch about his daily blog in which he documents stories from local people. I was lucky enough to win one of his signed books, which is beautiful and engrossing. Here it is with my swagbag:

My swag bag from #monkigras – I was a lucky recipient of a beautiful, signed London Album by @thegentleauthor

— Laura Cowen (@lauracowen) February 1, 2014

After his popular talk last year, Phil Gilbert of IBM returned to give an update on how things are going with Design@IBM. Theo’s point about context of a company being important is so relevant when trying to change the culture of such a large company. He introduced a new card game that you can use to help teach people what it’s like to be a designer working within the constraints of a real software project. I heard a fair amount of interest from non-IBMers who were keen for a copy of the cards to be made available outside IBM.

Phil Gilbert’s Wild Ducks card game

On the UX theme, I loved Leisa Reichelt‘s talk about introducing user research to the development teams at GDS. While all areas of UX can struggle to get taken seriously, user research (eg interviewing participants and usability testing) is often overlooked because it doesn’t produce visual designs or code. Leisa’s talk was wonderfully practical in how she related her experiences at GDS of proving the worth of user research to the extent that the number of user researchers has greatly increased.

And lastly I must mention Project Andiamo, which was born at Monkigras 2013 after watching a talk about laser scanning and 3D printing old railway trains. The project aims to produce medical orthotics, like splints and braces, by laser scanning the patient’s body and then 3D printing the part. This not only makes the whole process much quicker and more comfortable, it is at a fraction of the cost of the way that orthotics are currently made.

Samiya Parvez & Naveed Parvez of Project Andiamo

If you can help in any way, take a look at their website and get in touch with them. Samiya and Naveed’s talk was an amazing example of how a well-constructed story can get a powerful message across to its listeners:

"This is supposed to be a compliment, but your talk made me cry" – @monkigras

— Charlotte Spencer (@Charlotteis) January 31, 2014

After Monkigras 2014, I’m now really looking forward to Monkigras 2015.

My 11yr old just said that #monkigras could be translated as "fat monkey" … not sure what to make of that @monkchips

— Paul Johnston (@PaulDJohnston) February 12, 2014


The post Monkigras 2014: Sharing craft appeared first on

Categories: LUG Community Blogs

Dick Turpin: If its four it must be less?

Planet WolvesLUG - Fri, 14/02/2014 - 15:03
Customer: "I can't send this email?"
Me: "That's because you have a 50mb attachment! You can't send attachments that size you'll need to split that zip file into four separate ones."

A little later.

Customer: "I still cannot send this email!"
Me: "What the...... You've attached the four zip files to the same email! That's still 50mb."

Categories: LUG Community Blogs
Syndicate content