現在位置: ホーム 日々のメモ書き

日々のメモ書き

Debian Developerが綴るメモ

Debian・プログラミング・宇宙開発・自転車・登山などを中心に書いていきます。

U-23 シリア戦

Posted by TANIGUCHI Takaki | | filed under:

あきれるほどひどい試合だった。なんであんなに縦ポンクソサッカーになっているんだろう?ボールもったら放り込むの繰り返しになっていて呆れるばかりである。

山村とは何だったのか。扇原に最初からしておけばよかったのではないのだろうか?交代した瞬間前線へのボール供給ができるようになったのは呆れた。あと相変わらず比嘉もクソプレーの連発だった。この二人は良いときを見たことがない。闇の勢力からの圧力でもあるのかというぐらいである。

権田は最初から怪しいプレーの連発だったと思う。キャッチングも目測が怪しいしフィードは腐ってるし。2失点とも何じゃこりゃという失点である。

残り2試合がドキドキである。よかったな。まったく。こんなサッカーしかできないのでは先がない。いい選手が全然いないというのは言い訳にならない。

2012年02月05日 23時15分

geditのエンコーディング自動認識

Posted by TANIGUCHI Takaki | | filed under:

geditがEUC-JP・ISO-2022-JPを自動認識しないんでうっとうしいわけなんですがこれの修正。

dconf-editorを起動させてorg/gnome/gedit/preferences/encodingからauto-detectを編集。EUC-JPなどを追加して終了。面倒だな。

2012年02月03日 17時30分

御在所雪山訓練

今年もまた御在所で雪山訓練。基本的には下りの練習。コースは山上公園から奥又あたり→三ルンゼ→ヤグラ沢→前壁→裏道。

頂上までロープウェーで移動。駅を出たところでアイゼン等を装備する。そこそこ風がつめたい。手袋なしで作業していると冷える。

さて、中道のほうをうろうろしながら降下点を探す。適当に降りるかということでほんとに適当に降りだす。ちなみにヤグラ沢出会いまで現在点を理解していないまま必死に進む。足元ばかり見過ぎで全体の風景を見る余裕がまったくなかった。

最初は足元が雪に沈む感じで灌木も多く足を滑らしても雪に埋もれる程度ですむところが続くので気は楽。ここで気になるのはトラバース時の3点支持のリズムができない。ピッケル刺して1・2で足を出すというのはわかっているのだが自然にできない。結局きれいな移動はできないままだった。何がダメなのかよくわからないが、リズムを刻めない感覚。

やがて足元が凍りだす。アイゼンの歯がしっかり刺さるようになったがその分怖さは増す。今度は足をすべらすと氷の斜面を一気に下降するところとなる。へっぴり腰の移動でさらにおかしなことになる。もう少しきちんとした姿勢で歩くべき…とは思うものの一歩外したら大変なことになるという意識もあって難しい。しばらく降りたあと懸垂で降りることとなる。設置してある確保点を利用して40m下降。楽だね。

しばらくは比較的楽なとろが続く。雪も深い。ふと気がつくとヤグラ沢に来ていた。ここからヤグラ沢を登る。ここから先頭交代してひたすらラッセルを続ける。どこか違うのか去年よりずっと登りやすい。去年断念したポイントまで15分ぐらいであっという間に登る。だんだんと傾斜がきつくなってくるのでその勢いのままで上まで登るということはさすがにできなかったが。ピッケルで雪をかき落として、突き刺して両手で支えて、足を上げるということを繰り返す。一箇所だけ下がアイスになっていた場所があって、そこはピッケルを突き刺して、前爪をひっかけて登る、という、らしいというか真似事みたいなことをした。ほんのちょっとだけ。一回登ろうとしたら足がずり落ちてしまった。傾斜は本当にきつい。このあたりだけは必死だったので汗でサングラスが曇ってしまう。去年は途中で引き返したが、今年はここを登ることになったので妥協なく登り続ける。

そのまま登りきって前尾根に立つ。そのまま乗り越えて下降。アンザイレンをしながらやぐらの下あたりを通過した。そして20Mの3回の懸垂下降を繰り返して下まで降りる。懸垂下降するポイントは普通に降りれなくなる手前のポイントのせいか、準備作業も不安定な姿勢が多く、作業に苦労する。自分のハーネスの構造上、カラビナの取り回しが少しやり辛く、グローブのせいもあってさらに時間を取られる。ある程度下まで降りきったらあとは適当に雪の中をかきわけ下り北谷に出る。そこを乗り越え裏道に合流。振り返って今降りてきたところを見るが一体どこをどうやって降りてきたものだかさっぱりわからない。あんなところよく降りられたな。

そのままとは裏道を下っていき下山。踏み固められた道はアイゼンが効きすぎて足がちょっと疲れる。それにしても藤内沢で誰にも会わなかったな。不思議なことに。みんなどこに行ったのだろう?

2年前のあやしげな状態よりはましになってはいると思いたいのだが、基本的には歩けていない。トラバースや下りがまだ水準に達しているとは思えないまま。落ちても死なないところなら平気なのかもしれないが滑落のプレッシャーのあるところではまだ難しい。

2012年01月29日 23時00分

面白オープンソース

DeNAの騒ぎは結局MITにしたのでどうでもよくなったが、全然違う話をするとあるソフト会社が自社のソフトを個人にはMITで法人には商用ライセンスのデュアルという形式で配布していて何かの制限をしたつもりなんだろうか個人からトンネルさせられるんじゃないかと思うような話があったなあとライセンスって難しいねという思い出話。

2012年01月25日 20時50分

EXIFデータの修正

デジカメで撮った写真の日付設定が狂っていたのでまとめて修正を試みる。exiv2というソフトウェアを使用

$ exiv2 -Y -1 ad *.JPG

これで日付を全部1年前にずらすことができる。

他にもいろいろEXIFデータの修正ができるようだがこれだけできれば今日は満足。

2012年01月25日 11時56分

btrfs ベンチマーク

Posted by TANIGUCHI Takaki | | filed under:

Linux-3.2でbtrfsのパフォーマンスの改善があったというから測ってみた。

Linux-3.1.8

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
vanaheim     15504M   525  97 67789  13 31521  12   175   4 74101  21 120.3  10
Latency             25736us    2302ms    8545ms     190ms     292ms    1685ms
Version  1.96       ------Sequential Create------ --------Random Create--------
vanaheim            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   254   1 +++++ +++   613   4  2415   6 +++++ +++  2193  12
Latency             16002ms    1820us     230ms   14289us     212us     270ms
1.96,1.96,vanaheim,1,1327026245,15504M,,525,97,67789,13,31521,12,175,4,74101,21,120.3,10,16,,,,,254,1,+++++,+++,613,4,2415,6,+++++,+++,2193,12,25736us,2302ms,8545ms,190ms,292ms,1685ms,16002ms,1820us,230ms,14289us,212us,270ms

Linux-3.2.1

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
vanaheim     15504M   414  97 78161  13 31734  12  2266  61 76775  17 156.1   9
Latency             96929us     602ms    1036ms   69046us     424ms    1679ms
Version  1.96       ------Sequential Create------ --------Random Create--------
vanaheim            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1830   5 +++++ +++  2435   6  5194  13 +++++ +++  5207  23
Latency             35425us    1868us     778us   16338us      69us    2341us
1.96,1.96,vanaheim,1,1327026998,15504M,,414,97,78161,13,31734,12,2266,61,76775,17,156.1,9,16,,,,,1830,5,+++++,+++,2435,6,5194,13,+++++,+++,5207,23,96929us,602ms,1036ms,69046us,424ms,1679ms,35425us,1868us,778us,16338us,69us,2341us

Sequential outputのPer Chrが若干下がったぐらいで他は概ね改善されていると見ていいか。ファイル操作はかなりの向上を見せているように見える。体感でもなんとなく反応が良くなった気がする。

2012年01月20日 11時24分

Facebook の Open Graph に変更?

このサイトは Facebook の Open Graphを使っているが気がついたら対応するFacebookページに入れなくなっていた。なんかの仕様変更でしょうか。そんな話は聞いてないぞ。もはや対応するのもめんどくさい…。

追記(01/22): 勝手に直っていた。Facebookのバグか。深く考えるのはやめよう。

2012年01月17日 23時38分

bitcasa β版

月10$で容量無制限のクラウドストレージ、そういう謳い文句のbitcasaがβテスターを募集しているという記事を読み…テスターの登録をした。そして、もうあれから4ヶ月にもなるのか、テスターになったと連絡が来た。ということで使用してみた感想を…。

指示通りクライアントソフトのダウンロード。Linux版はまだないと。しょうがないのでWindows版をダウンロード。ただしα版。インストールして…bitcasaを起動。初回はアカウントを登録する。さてアップロードしてみるぞと…あれ? 全然何も起こらない。DnDでもダメだしメニューからアップロードするフォルダを指定してもダメ。なんじゃこりゃ。

ということでそもそもアップロードもできずなんじゃこりゃと終わったのであった。MacOSX版だと多少はうごくんかね?

追記: 最初に用意されている Sample Videos のフォルダ内にエクスプローラからコピーしたらアップロードされていた。少なくとも動いてはいるようだ。しかし新しいフォルダの追加方法がわからん…。

さらに追記(01.19): マイドキュメントにあるフォルダをドラッグアンドドロップで持ってきたら新規にフォルダが作成されてアップロードされた。デスクトップはいくらやってもアップロードされなかったのに。どういう仕様だこれ…。

2012年01月15日 11時50分

第一回電王戦

将棋はさっぱりな強さなので指す手を感心して見てるだけだったんだがすごいもんだ。互角の勝負なんか後手が若干いいかという解説の話をふーんと見ていたのが先手が角を移動させたところから一瞬で決まってしまうとはすごいなあと。

記者会見を見たら急遽来年5組の一斉対局に変更されたようでそれも楽しみである。会見時の会長は怖すぎ。

2012年01月14日 18時20分

CmdArgsの実験

Posted by TANIGUCHI Takaki | | filed under:

HaskellのコマンドラインパーザのCmdArgsをテストしてみる。さて、テストと言ってもなにをやるのかと思ったのでPythonのargparseのサンプルを移植するということにしてみた。

15.4. argparse — Parser for command-line options, arguments and sub-commands — Python v2.7.2 documentation

このプログラムは引数として一つ以上の数字を受け取り--sum フラグがあれば合計を、なければ最大値を返す。次のような具合。

~/src/python$ python argssum.py 
usage: argssum.py [-h] [--sum] N [N ...]
argssum.py: error: too few arguments
~/src/python$ python argssum.py  3 4 1 2
4
~/src/python$ python argssum.py  3 4 1 2 --sum
10

さてこれをHaskellのCmdArgsを使って書き直すと…。

{-# LANGUAGE DeriveDataTypeable #-}

import System.Console.CmdArgs

data Sample = Sample {
  sum::Bool,
  numargs::[Int]
  } deriving (Show, Data, Typeable)

sample = Sample
               {
                 Main.sum= def &= help "true=sum, false=max",
                 numargs = def &= args &= typ "NUMS"
               } &= summary "Sum or Max v1"

main =  do 
  arguments <- cmdArgs sample 
  print ((if (Main.sum arguments) then
           Prelude.sum
         else
           maximum) (Main.numargs arguments))
           

このようなプログラムとなり実行すると

~/src/haskell$ runghc args.hs 
args.hs: Prelude.maximum: empty list
~/src/haskell$ runghc args.hs  3 4 1 2
4
~/src/haskell$ runghc args.hs  3 4 1 2 --sum
10

となる。

2012年01月08日 13時14分
Facebook Like!
Google Ad
Google Ad
Copyright © 1996-2012 TANIGUCHI Takaki