谷川岳登山 #kabepy

Hython 部の方から来ました。こんにちは。今回は Python ボルダリング部 (通称 #kabepy) のアドベントカレンダーにお邪魔させて頂きます。もともと Hython 部は Pythonista が廃村に行くとかいうノリで始まったんですが、廃村が山奥にあることが多く、いつの間にかワンダーフォーゲル部になってしまいました。昔の日本は林業大国だったんですね。
今年 (2012年) の登山成果は、
  • 谷川岳 - 一ノ倉 - 茂倉岳縦走
  • 富士登山
  • 槍ヶ岳縦走
  • 浅間山縦走
  • 丹沢縦走
です。#kabepy のアドベントカレンダーなので "ロッククライミングのメッカ" と言われている谷川岳について書かせて頂きます。

谷川岳について

谷川岳 - Wikipedia に詳しく書かれていますが、
  • 剣岳、穂高岳と共に日本三大岩場のひとつ
  • 日本三大急登 (高低差) がある
  • 遭難による死者数が世界一 (ギネス認定
なんとも物騒な感じですが、コースによります。私が登ったコースは、とても登りがいがあり、稜線が素敵なコースでした。まだ登山歴 2 年目ですが、また登りたいと思った山は谷川岳だけ。@rokujyouhitoma 先生の故御父様も谷川岳をこよなく愛されていたそうです。

コース

直線距離: 約15km / 高低差: 1.5km / 全 7.5 時間 ぐらいですかね。小雨。
  • 07:30 - 土合駅
  • 08:00 - 天神平
    晴れてる時は富士さんが見えるらしい。残念ながら ガスで10m 先も見えない。
  • 10:00 - 谷川岳トマの耳 (1,963m)
    鎖場あり。岩場あり。登りごたえのある登山コースです。が！写真撮れません。ガスがひどくてシャッター下りません。立派なプレートだけ。
  • 11:00 - 谷川岳オキの耳 (1977m)
    景色？なにそれ。立派なプレート。
    稜線の所だけガスが晴れた瞬間。ここから人とすれ違わなくなります。高山植物がいたるところに生えていて、ハエが大量にいます。が！写真撮れませんでした。
  • 12:00 - 一ノ倉岳 (1974.2m)
    立派な・・・
    手前に万年雪があります。ガスもあってただ一面白いだけ。ここもオートフォーカスが効かないという。
  • 13:00 - 茂倉岳 (1977.9m)
    茂倉の稜線は美しい！ここを走るのは快感です！茂倉だけでもまた行きたい。(晴れてる時の稜線)。登るだけではなく、滑走できるのも登山の魅力。トレイルランニングには最適なコースです。
  • 15:00 - 土樽駅
せっかくなので、岩場とか鎖場とかの写真を何枚か。これは @hidecheck 先生に撮っていただいた奴。こんな岩場 #kabepy の方たちは朝飯前ですよね！
岩場。
鎖場。
谷川岳の魅力が少しでも伝われば良いのですが、少々不安です。。自分が超絶雨男なのが残念です。今年は浅間山以外全部悪天候でした orz
是非壁な方も外山にも登りに行きませう！

最期に日本最高峰剣ヶ峰から見える雲海と御来光。

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM...
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...
続きを読む