Blog

Mt. Fuji climbing

It has been a long time since I posted anything about a trip here, but now it's time I do so. Last weekend, the 22nd and 23rd of August, I along with six friends climbed Mt. Fuji.

We set off on Saturday, leaving Tokyo at 12:40 by bus from Shinjuku, and we arrived at the fifth station of the Kawaguchiko trail (at an altitude of 2305 meters) around 17:00. After spending some time getting used to the thinner air, we started climbing around 18:00. Our schedule had us on the summit some time around 2:00 in the morning, but that was hopelessly optimistic. The climb was very exhausting, and I'm not exactly in the best shape, so it took us somewhat longer. The large number of people caused the occasional "traffic jam" which also caused a lot of delay. It's really unbelievable how crowded that mountain is. It's worse than Shinjuku station.

Our goal was of course to reach the summit before sunrise at 5:00 in the morning, but unfortunately we fell short of that goal by about 300 meters (distance, not altitude). Probably a good thing, in retrospect, since it appeared to be much more cloudy on the actual summit so we probably got a better view from where we were. After sunrise, we continued to the summit. Unfortunately, because many people had paused to watch the sunrise, an enormous queue had formed leading up, so eventually we were at the summit around 6:30. Once there, we took some rest, ate some food (despite the high prices I did buy some noodles, just to have something hot to eat, as it was very cold on the summit). Although thoroughly exhausted, we were all glad we made it.

Here's where things started to go wrong, though. For one thing, we hadn't all made it to the summit at the same time, so we were already separated. I was with only two others when we started our descent, and unfortunately we took the wrong trail back down (the trail down was not supposed to be the same one we took up, but we still took the wrong one). Despite the fact that there's signs every twenty meters or so, none of us noticed it was the wrong trail until we were all the way at the bottom. While we did arrive at a fifth station, it was the wrong fifth station. Of course, the others who went down separately did take the right trail so we couldn't meet with them. And because everybody managed to have dead cell phone batteries at the same time, we couldn't even contact each other to try and sort things out. So we could only go back to Tokyo on our own and hope the others did the same (which of course they did). It all worked out in the end, but it was a pretty stupid feeling when we realised we were at the wrong location after climbing all that way down.

But no matter how grueling the journey (especially the wind and the dust on the way down were very bad), and no matter the mistake with the descent, I'm still glad we did it, and I'm very happy I made it, of course. In fact, I still have trouble believing it. It's the longest single climb I've ever done, and the highest I've ever been (3776 meters at the summit, prior to this the highest I'd been was 3400m in the Sierra Nevada in Spain). The beautiful sunrise (the pictures don't do it justice, really), and the sheer satisfaction of reaching the goal, make it worth it.

Enjoy the pictures!

Show images (47)

Categories: Personal, Japan
Posted on: 2009-08-30 09:11 UTC. Show comments (2)

Let's Play: Riven

You may have heard of something called a Let's Play video. These are videos on the Internet (typically YouTube) where someone plays through a game from start to finish, often providing commentary along the way.

I quite enjoy watching these videos. When done well, they can provide some nice added value to the game, and provide an opportunity to catch up on classic games that you never had the chance to play.

For quite some time now, I have harboured the plan to make a Let's Play of my own. Now, I have finally done so. The game I have chosen to play is Riven: The Sequel to Myst. This is my favourite game of the Myst series, and perhaps my favourite game of all time. Its level of depth and immersion is unparalleled by anything else I've seen, and because I know a great deal about the world of the Myst games it presented an ideal target for a Let's Play.

The first video of the series is embedded below:

Today, I have finally uploaded the final video of the 32-part series. The whole thing was recorded in a single weekend, and uploaded one by one over the period of two weeks.

All of the videos are available in this playlist.

Enjoy!

Categories: Personal, General computing, Random stuff
Posted on: 2009-07-26 15:44 UTC. Show comments (4)

Windows 7 ISO Verifier

Windows 7 is about to hit RTM, and many of you might want to verify that the ISO image you downloaded hasn't been tampered with or was damaged as the result of some error in the download process. Of course you can use existing checksum tools and compare the result to published values, but it can be a bit of a hassle.

At the request of Long Zheng I created a small application that makes this process easier. Simply drag and drop your ISO file onto the application (or start the application and browse to the ISO file) and it will verify the EXE and tell you which build you have from a list of known builds. It downloads this list from the web automatically, so you don't need to re-download the application after Windows 7 RTM is released.

The Windows 7 ISO Verifier can be downloaded from Long's website.

Categories: Software, General computing
Posted on: 2009-07-06 08:50 UTC. Show comments (4)

Priority Queue for .Net

A priority queue is a queue data structure where the element with the lowest (or highest) value is always at the front. A common analogy is to think of a queue of people ordered by some criteria such as age or height. Many programming languages include a priority queue in their standard library, including C++ and Java. However, the Microsoft .Net Framework does not include a priority queue, which is why I provide one here.

You might wonder why you can’t just use a sorted list to get the same effect as a priority queue. And the answer is, you can. A sorted list is a perfectly valid way to implement a priority queue. However, with a priority queue we are only interest in the smallest element at any time, and not any of the other elements, which means it is not necessary to maintain a total order of all the elements. Because of this, we can use an implementation that maintains only a partial order, which can provide better performance.

The most common such implementation is one that uses a binary heap. A binary heap is a binary tree with the property that any element in the tree is always smaller than both of its children. This guarantees that the smallest element is always on top, although the binary heap does not maintain a total order like a binary search tree. Efficient operations exist to maintain this heap property when inserting and deleting elements, making the binary heap perform better for priority queues than a sorted list. My PriorityQueue class for .Net uses a binary heap implementation.

The PriorityQueue<T> generic class that I provide here is written to conform to the conventions used by .Net’s built-in collection classes in the System.Collections.Generic namespace, particularly the Queue<T> class. The PriorityQueue<T> class implements IEnumerable<T> and ICollection.

The three main operations provided are Enqueue, which adds an item to the queue; Dequeue, which removes and returns the first element of the queue; and Peek, which returns the first element without removing it. In this implementation, these operations are O(log n), O(log n) and O(1) respectively. A special operation, AdjustFirstItem, allows you to change the value of the first item and re-evaluate its position in the queue, in less time than it would’ve taken to remove the element and add a new one (note that this is only possible with reference types that are not immutable).

The PriorityQueue<T> class provides several constructors, including one that allows you to create a priority queue from an existing list of elements with O(n) time complexity, faster than individually adding each element to the list with Enqueue.

You can put any type of element in the priority queue as long as it implements IComparable<T>, or you provide a custom IComparer<T> for the type. Note that the PriorityQueue<T> class will always put the smallest element at the front. If you want to have the largest element at the front, you can use the included InvertedComparer<T> class.

A short example of how to use the PriorityQueue<T> class is provided below.

PriorityQueue<int> queue = new PriorityQueue<int>(new[] { 4, 7, 3, 9, 12 }); // create a priority queue with the specified elements.
int n = queue.Dequeue(); // returns and removes 3; the front element is now 4.
queue.Enqueue(5); // the front element is still 4.
queue.Enqueue(2); // the front element is now 2.
n = queue.Peek(); // returns 2, but does not remove it.

Download the PriorityQueue<T> class for .Net (class library, sample application, and source code provided).

Read the documentation for the PriorityQueue<T> class.

Categories: Programming
Posted on: 2009-04-29 06:17 UTC. Show comments (5)

New download: Ookii.Dialogs

I have made available a new download: Ookii.Dialogs.

Ookii.Dialogs is a class library that provides a number of common dialogs for use in .Net applications. The dialogs provided are the task dialog, progress dialog, credential dialog, input dialog and Vista-style common file dialogs.

The download contains two class libraries, one for Windows Forms and one for Windows Presentation Foundation (WPF). The contents are nearly identical; only the input dialog is not available for WPF. Some utility classes are provided for Windows Forms; these are not available for WPF either.

Most of these dialogs are wrappers around Windows API functionality. The TaskDialog class wraps the task dialog API provided in Windows Vista and later. The ProgressDialog class wraps the IProgressDialog API available since Windows 2000. The CredentialDialog class wraps the CredUI API introduced in Windows XP, and the VistaOpenFileDialog, VistaSaveFileDialog and VistaFolderBrowserDialog classes wrap the IFileDialog API introduced in Windows Vista. Only the InputDialog is not a wrapper; this is a custom dialog that performs the same functionality as the old Visual Basic InputBox function. Visit the link above for more details on each dialog.

Each class has been designed to be not merely a wrapper around their respective native API, but to provide a programming interface that is natural to .Net developers, with full support for the component designer. The complete source code of the class libraries, as well as documentation and a sample application are provided.

The classes aim to give the best experience possible on each OS, where applicable. In the case of the CredentialDialog class, this means that the new Vista-style dialog is automatically used on operating systems that support it (Vista and newer). The Vista-style file dialog classes will automatically fall back to the old style dialogs when using Windows XP. This is also true of the VistaFolderBrowserDialog class for WPF, even though WPF itself doesn't provide a folder browser dialog; the VistaFolderBrowserDialog class is a full folder browser dialog implementation for WPF supporting XP and newer.

This library replaces the Ookii.VistaDialogs library, which contained only the Vista-style file dialogs and didn't offer any support for WPF.

This library is a collection of classes that I have developed for personal use over the years. Because of the difference in age of some of the code, and the many modifications made over time, there may be some inconsistencies.

Let me know what you think of it, if you use it.

Categories: Software, General computing, Programming
Posted on: 2009-01-28 11:54 UTC. Show comments (38)

Latest posts

Categories

Archive

Syndication

RSS Subscribe

;