Rider Clearances

To account for different height riders while still keeping the rider’s eyeline above the height of the bulkhead, the seat back reclines, pivoting near the hip joint. All of the swept area must be clear of any other objects. Below the body swept area is space usable for luggage, except where the chain passes through.

To cycle, there has to be room for the rider’s legs to move as they pedal, so the swept area of the rider’s thighs has to be kept clear; the rider’s legs mustn’t hit the bulkhead, nor the steering wheel. Position of the steering column is not affected though, as the rider’s legs will pass either side of it.

Having a steering wheel in the cockpit with the rider in such a reclined position presents a trickier packaging requirement then underseat steering. Not only must the wheel be clear in the straight ahead position, it must also not interfere whilst turning, including the protruding brake levers.

As the body area pivots close to the hip position to accommodate different height riders and the wheel has no variation of position, the best position for the wheel is directly above the rider’s hips. Height of the steering column must be set so the wheel doesn’t impact the rider at the bottom and doesn’t hit the screen (with clearance for the rider’s hand) at the top. A lack of steering wheel adjustment means that there will be a variation in hand position depending upon rider height.

The low height of the cockpit area also means that full steering lock (>±90⁰) may bring the bottom of the wheel (and brake lever) close to the rider and the top of the wheel will obscure some of the rider’s forward vision. Though this isn’t too much of a problem, as full steering lock will only be useful at very low speeds (e.g. for parking or turning round) when the speed of reaction for braking is less critical. All normal riding should need much lower steering wheel angles.

Once it was clear what happened during a merge, it was much easier to see how to go about undoing the change.

Commit Merge

Commit Merge

When development has taken place on both branches before the merge operation, git has to create a new commit that mixes the changes.

Git will automatically try to make a commit, but using git merge -n (branch_name) or having merge conflicts will leave you to make a manual commit.

Fast-Forward Merge

Fast-Forward Merge

If there’s only development in one branch, then when you make the merge, git will just update the head position for the receiving branch. The merging branch is then a sub-set of the history if the recipient branch.

No Fast-Forward Merge

-no-ff Merge

A special form of a commit merge; git commit -no-ff (branch_name) will force a commit merge, even if it is possible to make a fast-forward merge.

Undoing Merges

If the merge hasn’t been pushed remotely yet, then it’s fairly straight forward to undo, if the merge has already been published remotely, then it’s best to issue a revert: a new commit that reverts a previous one, so as not to upset the history of any other pulled clones.

For a commit merge that hasn’t been committed yet,

git reset HEAD

will clear the Staging Area of any changes (Warning: git reset --hard HEAD will also clear the Working Directory of any changes compared to the HEAD commit).

If the merge commit has already been made, you can move the tip of the receiving branch back to it’s previous position. For the example above:

git checkout master
git reset B

will set the tip of the master branch back to commit “B” and the merge commit “F” will be ignored and eventually thrown away (use the sha of actual commit as appropriate).

For the Fast-Forward Merge, the process is the same:

git checkout master
git reset B

will move the tip of the master branch back to its original position.

Sources:

ProGit > Undoing Merges

Git Community Book > Basic Branching and Merging

Nvie > A Successful Git Branching Model

ProGit > Reset Demysified

StackOverflow > Revert a merge that was already pushed

Schacon > Git How-To > Revert a faulty Merge (for more complex situations)

Except this one. Which isn’t one.

Back next week.

As in: The Treachery of Images

But, if you’re going to the trouble of learning a new skill, then you’ll want a way to use it in practice. Online, there’s the Dotsies reader and the bookmarklet; but as there are no books published in Dotsies yet, changing the font on some ebooks might be a good start. After all, Dotsies is designed for maximising screen estate.

These instructions are for a Sony PRS-505, though it should work for most Sony Readers, I’m changing fonts book-by-book, so there’s nothing scary like firmware flashing. These instructions use Calibre for the conversions, so you’ll need DRM-free ebooks; I’ve used the file from “A Princess of Mars” that I’ve used previously.

Dotsies on an ebook Reader

If you don’t mind breaching some TOCs, stripping DRM from ebooks is a solved problem (that means a search engine is your friend).

First, you’ll need the fonts. A regular and bold are available for download (there’s no italic font as the italic shape for Dotsies hasn’t been decided on yet).

Then place those two fonts into a fonts directory in the internal memory of the Reader (this folder doesn’t normally exist).

Then it’s time to convert the ebook in Calibre. I already had this book in my Library, so I imported a new copy and changed the title in Calibre so it would be a new book, and so I’d know from the title that it was the Dotsied version.

Select the book in Calibre, right click, and select Convert Books » Convert Individually. Then, in Look & Feel paste the following CSS into the Extra CSS box. This will tell the ebook reader to use the Dotsies fonts that were copied across before for the book text.

@font-face {

    font-family: "Dotsies";
    font-weight: normal;
    font-style: normal;
    src: url(res:///Data/fonts/Dotsies.ttf); 

}

@font-face {

    font-family: "Dotsies";
    font-weight: bold;
    font-style: normal;
    src: url(res:///Data/fonts/Dotsies Wide.ttf); 

}

body, div, p {

    font-family: "Dotsies", serif;
    widows: 0;
    orphans: 0; 

}

If should also display using Dotsies in the Calibre reader if those fonts are installed on your computer.

Finally, copy the new book across to your reader. I didn’t notice any change in page turn time.

See also:
code.google.com » prs-plus wiki » InstallGuide
The ebook Reader » Sony Font Hack How to Change Fonts on a Sony Reader
mobileread forums » *VERY* detailed guide on changing default Reader fonts

[…]using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of reg​ex parsers for HTML will ins​tantly transport a programmer’s consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection wil​l devour your HT​ML parser, application and existence for all time like Visual Basic only worse[…]

The whole StackOverflow answer makes a very sane and reasonable argument for not using regexes to try and parse HTML, so I’d recommend taking a look. However, if you’re not totally convinced, perhaps you’d prefer Bring Me Your Regexes! I Will Create HTML To Break Them!. That did convince me.

PHP does have a DOM extension, so it’s possible to use that to operate on XML elements, but it all looked to complex and involved for me to find a way in, but S.C. Chen’s PHP Simple HTML DOM Parser made the whole thing fairly straight forward.

The whole, commented, revised code is up at Github, but while I have a few regular expression match calls, they’re all operating now on the returned HTML attributes from the DOM parser, instead of trying to pull put the details from raw HTML.

After including the Simple HTML DOM library, the script:

• Finds any link wrapped images.
• Checks that the link points to an image file and doesn’t have a “lightbox” relation proterty applied. (as a side effect, any link with rel=”nolightbox” will also be overlooked)
• Adds the popup caption from the database if it’s a single hosted image, or part of a gallery.
• And finally, adds “lightbox[post-(post_id)]” to the rel attribute of the link

This should be more robust than version 0.3, although I haven’t seen any problems with that version in practice. However it does also make the code much easier to extend or expand in the future.

While I’ve been meaning to do this for a while, I’ve only just got round to coding it up. Everything in the “DOMcontrolled” branch looks good in the initial testing, so the version is currently set at 0.4.RC1, which I’ll roll out after it’s survived more prodding.

See also: Coding Horror > Parsing HTML the Cthulhu Way

Functionally identical to the “K-Drive” of the Kingsbury Kingcycle, the mechanism is first described in 1890, so it might be more correct to call it a “Vietor Elliptical Drive”, it’s best known as the “Kingsbury K-Drive” from Kingcycle’s successful use of it the early 1990s.

The chainring is connected to the primary crank spider as is normal, except that additional clearance is required between the crank and chainring for a secondary chain line.

Primary Crank, Stator and Chainring

The K-drive additionally has a secondary, shorter, crank that is connected to it’s own sprocket. The secondary crank sprocket is linked by a fixed length chain back to a stationary sprocket (stator) around the axis of the bottom bracket.

Secondary Crank

Because the secondary crank’s sprocket is half the size of the stator sprocket, the secondary crank will make two rotations for every one that the primary crank makes, and in the opposite direction. This means that the pedal — at the end of the secondary crank — will follow an elliptical path around the chainring axis. If the primary and secondary cranks are the same length, then the path of the pedals will be linear.

Pedal Paths

While there may be some power benefits from linear or near-linear drive, it does have one clear benefit for fired vehicles. By reducing the vertical movement of the rider’s feet, the vertical clearance required for the rider is greatly reduced. This gives greater freedom of design for the nose shell.

Vertical Clearance

Where a normal crank requires clearance for the rider’s foot an addition to the diameter of the crank’s rotation, the K-Drive only requires foot clearance plus the maximum vertical travel of the pedals ellipse. Assuming a total of 30cm foot clearance, a normal drive would need 64cm for clear motion, but with a 5cm high ellipse, an equivalent K-Drive would need only 35cm. That’s a 45% reduction in height!

Other that a few concepts and and some racing bikes, this drive system doesn’t seem to have been used much, despite it’s engineering elegance. I particularly like LucaBike‘s use of toothed belts instead of chains.

Has anyone ever manufactured this type of drive commercially?

How does it fare in use? Is it reliable?

Makerslide took the idea of a standard aluminium extrusion frame system, used for building custom frame structures, and added a v-profile to make it usable as an accurate linear bearing system. And created the necessary combining hardware, v-pulley wheels, mounting plates, eccentric adjusters for the pulleys and belt drive attachments to create a linear bearing system that can easily be used for motor control.

Makerslide is intended to be a standardised solution to linear drive systems for the home builder. Aluminium extrusions need a certain amount of capital to produce, and since Makerslide successfully raised five times it’s goal, is now manufacturing and shipping rails and the other associated parts.

Then, a month after Makerslide’s Kickstarter success, the Project Shapeoko’s $300 CNC machine was funded. And a low-cost CNC machine that is now available as a kit. It uses the Makerslide system as it’s major structral components to keep costs low, while allowing good accuracy; and this means that it’s now possible to own a desktop CNC machine for as low as $338 (as of time of writing).

So with aluminium extrusions extended to create linear bearings; in turn extended to a complete CNC platform; run with open source motor controllers, built upon the open source Arduino board and powered by open source CNC controller software: the cost of a CNC machine is falling steadily into the realm of the hobbyist.

So I’ve moved the project to git, set up a remote repository for synchronisation and backup and started making commits. Then I realised that my symlinked makefile was only included as a link in the git repository. This is different to Dropbox, which would synchronise the contents of the linked file.

Instead of just having a symbolic link to a file that might not exist on another computer, I needed another way of including the file properly. I could just drop the file into the git repository, but then it won’t update if I make any changes to the main project files. If I make use a hard link then git will include the file contents, but then it’s possible to make tracked changes in the \(\LaTeX\) project repository by changing the file in its original repository — and that is just a recipe for confusion.

Instead, it’s probably better to include the makefile repository as a git submodule and then symlink into the sub-repository’s makefile. That way, the exact commit information is included in the parent-repo, but the sub-repo can be updated, changed and branched as needed.

To do this:

cd ~/LaTeX/project/folder
git submodule add git://github.com/DefProc/LaTeX-SVG-to-PDF.git
rm makefile # if you already have a makefile in the directory
ln -s LaTeX-SVG-to-PDF/makefile makefile
git add .
git commit -m "added LaTeX-SVG-to-PDF as submodule and linked to makefile"

There are a couple of complications to this method:

If you clone a new local repository of the parent project then you also have to initiate and update the submodules to add their contents.

git clone my@server:git/project.git
cd project
git submodule update --init

And you also need to be careful of including changes to the sub-repos. If you git add . && git commit to the parent-repo with uncommitted changes to the sub-repo, then you’ll be telling the parent-repo to use that dirty head on every clone — not good.

If you’ve made changes to the sub-repo, make sure that these are committed (and pushed) before commiting on the parent-repo.

LaTeX-SVG-to-PDF makefile project source and download.

So when it appeared again, as I was looking at buying Peter Cline’s book “Ex-Heroes” and reading the authors “ranty blog” that became enough repetition for me to bite. And as I was already buying one book on Amazon, I took a look at what dead tree versions were available for “A Princess of Mars”.

A few, it turns out. There’s a Disney Books edition with all the nice typesetting, a Simon and Schuster published collection which makes very clear that it’s not endorsed by the Edgar Rice Burrows estate, an edition with a Frank Frazzetta cover and more.

And then I realised that the book was written long enough ago that is fallen into the public domain. And that I already had an ebook version from the Gutenberg Project that I hadn’t read. This means I didn’t even have to wait for delivery, as I already had paper, ink and a printer sitting right next to my desk…

So after converting from ePuB to HTMLZ with Calibre and running the resulting index.html file through pandoc; I ended up with a remarkably clean \(\LaTeX\) file ready for formatting.

Even better, by the power of public domain and a competition based market place, I can offer the resulting, print ready, pdf for you to download and print off at home in a variety of page formats, free of charge.

Or just buy a pre-printed copy from a bookstore.

Or get a copy of the free ebook.

For single sided printing on A4 or letter paper:

A Princess of Mars (A4 Single Sided)

A Princess of Mars (letter, single sided)

Or double sided if you have a fancier printer:

A Princess of Mars (A4 Double Sided)

A Princess of Mars (letter, double sided)

It’s a big print, ≈165 pages (85 sheets double sided) so I’ve bound my copy with binder clips with the levers removed to make a book-like document.

It might be worth reiterating that the copyright on “A Princess of Mars” has now expired, and the work is in the public domain. This means you, I, and Disney can copy, transform and combine to our heart’s content.

And they’re called “dotfiles” because any filename that begins with a full stop (period) is a hidden file in Unix, Linux, etc.

Since I started using vim for text editing and made some tweaks to my .vimrc file and added some plugins (pathogen, vim-fugitive and vim-latex), I quickly realised that I’d like to be able to take these settings with me, so I started looking at keeping the configuration files in version control.

Now there are any number of dotfile repositories on github and many, many guides on setting up your dotfiles with git, but I noticed that there were two main arrangements, but the pros and cons of each arrangement seemed to be spread out around the web.

1. Put your whole home directory into revision control and track only a few files.
2. Add a dotfiles subfolder in your home directory that is under version control, move in the files that you want to track and symlink them back to the original location.

Which one to choose? I tried both, but I like the second best.

Why? See below:

Home Directory

Just creating a git repository of your home directory looks like the simplest solution, but you soon realise that you have to exclude a lot of files from being tracked, or you’ll be seeing lots of files listed every time you do git status. This isn’t too difficult though, just ignore every file (/*), except dotfiles (!.*), except the dotfiles that you don’t want to track (e.g. .bash_history). Now any new dotfiles will be automatically added by a git add . unless you choose to ignore them.

Except it’s not that simple. Adding a file listing to .gitignore will propagate to any other git repositories in you entire home directory. Ah. It’s not too bad though, you can just use the .git/info/exclude file for repo specific exclusions. Except that the .git/info/exclude doesn’t propagate to other repositories, so you’ll have to add the exclusions again for each clone.

Using the home directory gets worse though. If you run a git clean on this repository, you’ll remove any files in the directory that are untracked by git, e.g. every other file. This isn’t too likely in normal practice, and you’ll probably have to add -f and either -x or -X to really mess things up, but I don’t like the idea that a normal cleanup command for a repository now holds the keys to clear out all the contents of my home directory!

dotfiles Subfolder and Symlinks

Adding your dotfiles to a subfolder and then symlinking them back to the original location looks like it’ll be more complicated, but it does keep all of those files nicely separate. All you have to do is add each file to the repository once, and then any other file remains completely unaffected. You can nuke and re-create the directory without going anywhere near you other files.

The main effects of using a subfolder are that: you have to manually select which dotfiles you want to include (where as with a home directory you have to manually exclude them), but this tends to lead to more of a curated repository; and you have to add the symlinks manually for any new clone or new file on every clone.

Symlink control is probably best left to a script though, maybe even in a post-receive hook if you really trust the code. There are examples in make, ruby, and this interesting “dot files management” (dfm) program in perl. I think I’ll have to spend smae time with the dfm documentation