投稿者「the-takeo」のアーカイブ

自分語りPart1 大学留年危機

この記事はプログラミング一切関係ないです。

大学卒業したとき、Facebookか何かに載せようと、大学生活のことを振り返る文章を書いた。
だけど、いざ載せようと思うと、文章の稚拙さや、何より構ってちゃんな感じがして公開しないでいた。
けど、書いてから1年以上経ったし、ブログならそこまで構ってちゃんに思われないだろうというよくわからない心理で載せてみる。

久々に何か長文を書こうかなと思う。
と言っても何か気の利いた話なんて書けないし、折角学生生活を一旦は終えた訳なので、自分のそれを振り返ってみようかなと思う。
今までもmixiとかで日記とか書いていたけど、それでも流石に都合のいいことしか書いてないだろうし、隠してないことの方が少ない。
だけど、もうそんな必要もあまりないと思うし、出来るだけ赤裸々に、つまらなくもグダグダと書きなぐってみよう。
まずは1番記憶の残っている大学生活後期、3年後半～4年までを。
多分、メンヘラっぽくなるけどそこは許して欲しい。

1）留年危機～進級、形だけの就活
大学3年の冬あたりから僕のアイデンティティは揺らいだ。
発端は留年危機。あまりに情けない話だが、今までのらりくらりと何だかんだと言って躓かない人生を送ってきて、またこれからもそうなるという漠然とした想像をしていた。
しかし、その未来妄想図はあっさりと崩れた。
そう、単位を取らなくては卒業できないという逃避できない事実に気付いたのだ。
大学3年生となり、数学が全く、本当に全く理解できなくなっていた。
なのに、試験ができなくては単位は取れない。このままでは、いや、この後どうしようともど
うにもならないとしか思えず、発狂した。
「理解できないなら勉強すればいいじゃないか」と思うかも知れない。いや、事実そうなのだ。だけど、これは後から自己分析(笑)とか諸々を行い薄っすら気付いたことなのだけど、僕は所謂「学び方」というのを全く知らなかったのだと思う。というより、今も分からない。この歳でそうなのだから、多分これからも分かることは無いんだろう。
昔から興味あることしか知ろうとしなかったのだ。それがたまたま数学になった時期があっただけだった。

まぁ、このことは大学の話とはあまり関係ないし、また違う機会に書くことにする。

閑話休題。留年を意識しながらも、結局大学3年後期は数学を見るのも嫌で、学校に行かない日々が続いていた。
多分、週に1、2度ぐらいしか行っていない。授業はほぼ毎日あるにもかかわらずだ。
病んでるという言葉を軽々しく使うようだし、甘え以外何物でも無いんだけど、自分がただひたすらダメな人間だとギャグでなくとうとう本当に自覚してしまい、どこかおかしくなったのかも知れない。事実、今もその意識はある。

何でみんなそんなに堂々と生きていられるのか、そしてそれが羨ましくなる。
道を平然と歩き、当たり前に学び、当然のように人と繋がるのか。段々分からなくなる。

またまた閑話休題。さて、そんな風に現実逃避の生活を続けていたが、いよいよ期末試験が近づき、どうしようもなくなった。
恥も外聞も捨て、丁度同じく留年危機にあった友人からの聞いた「学年主任の先生に相談するといい」という情報を信じ、試験2週間前、I先生に相談に行った。
今思うと「何だこいつ」という感じだ。俺が先生なら「いや勉強しろよ」と押し返すと思う。

だが、先生は予想外にあっさり相談を受け入れ、真摯に単位を集め、進級する為のアドバイスをしてくれた。後で聞いた話だが、数学科は東工大随一の留年率を誇り、その為毎年のように俺みたいな輩が出てくるらしい。先生達も手慣れたもんだ。
アドバイスの中には重要な情報もあった。進級の為には「準必修」と呼ばれる科目の単位を規定数以上取らなくてはいけないのだが、これを律儀に守ると留年者が大変な数になってしまうので、「規定より4単位少ない程度までなら、会議で進級を認めることがある」のが現状だったのだ。
それはつまりそもそもの規定が厳しすぎるか、講義に問題があるのでは・・・とも思うのだが。

とにかく、幸か不幸か俺にはまだ進級の可能性が残っていることが分かった。しかし、勉強はやっぱり出来ない。せめてもと演習の授業は出席し、課題も出していたが、講義科目はてんでダメ。
所詮数学を理解していないのだ。努力を怠らなかったといえば嘘になるが、学問に「耐える」資源が足りなかったというのもまた事実なのだ。
嫌なことから逃げて逃げて逃げ続けて生きていたのだ（野菜すら嫌い続けている）。
そしてとうとう逃げきれなくなっていた。

まぁ、そんな感じで、2月。期末試験を終えた後は途方にくれていた。絶望していたし、虚無感
もあるし、変な気持ちだ。自分の進路をまともに考え出したのがこれぐらいだったか。
大学院に進学。
これが予定だったし、当然の道だったけど、果たして留年しそうな自分にその資格があるのか。大体行けたとして、行きたいのか。お前がしたいのは「大学院生」であって「数学の研究」ではないんじゃないか。本分を見失ってはいやしないか。
じゃあ大学院に進まないとして、どうする？就職？俺が？まさか。働くのに1番向いていない性格をしている。
でも、結局はこの二者択一しかない。ニートとか、再入学とか、起業とか、正直今の自分には現実離れしている。でも・・・
そんな自問自答と現実逃避を繰り返していた。

全文載せるとアホみたいに長いからここまで。
しっかしあのとき病んでたのは、言い換えれば選択肢としての希望があったからなんだよな。
今はあそこまで芳醇な選択肢は無いし、心の何処かで破滅願望があるような気がする。

それでも絶望しているって訳じゃないから、人生よくわからないんだよね。

C#で素因数分解(工夫なし)

案の定というか、更新停止していた。

ネタは書きためているのだけど、書き溜めるだけじゃ何もできん。
プログラミングを学んで一番最初に自分で1から作成したのは素因数分解を行うプログラムの作成だった。
ついさっき、そのコードを見つけたのだけど、これが酷すぎる。
見ていられない。
というわけで、ついさっき書きなおしてみたら5分でできた。それも以前のものより段違いにシンプルで速い。
こんなサンプルに意味はないのだけど、なんとなく載せてみる。

全然関係ないけど、最近、SmartWatchのPebbleのアプリ”Simply.js”でjavascriptだけで色々とできることが分かったので、Twitter投稿アプリを作成しようと目論んでる。
・・・javascript単体だと難しそうなのでサーバーにexe置いてjavascriptで叩いて起動、というフローを想定しているんだけど、できるのかなこんなこと。
どうも、プログラム初心者です。

Gitでコンフリクトを起こしたくなくて

Gitは分散型バージョン管理システムなので、
ソースコードの同じような箇所を複数の人が修正したら当然コンフリクトが発生する。

コンフリクトを回避するにはマージツールなどを使えばいいんだけど、正直やりたくないのが本音だ。
他人のソースを理解し、そのように採用するか、その作業は思ったより負担になることが多い。
俺の技術不足?それはその通りだ。
でも、それを嘆いてもソースが読めるようになるわけではない。
そこで、コンフリクトを極力起こさないように、ある方法を用いている。

それは非常に単純で、「新規追加機能やクラスは極力別ファイルにする」というものだ。
ファイルが違えば、コンフリクトなど起き得ない。
それに、クラスを別ファイルにすることで、ソース全体への視認性も向上する。

勿論、ソースを見て、ファイルを分けるべきでないなら、分けてはならない。
あくまでTipsなので、それで全体が振り回されるのはいけない。

あ、言うまでもないけど、こんなことしなくてもコンフリクトの原因をすぐに理解し、その修正をすぐに行える人はこんなことすべきでないと思います。
初戦は自分の未熟さをカバーするための回避策です。

なんだこの内容の無さ。

GitHubとBitbucket

世の中ソーシャルコーディングの時代なのか、Gitレポジトリのホスティングサービスが主流になっている。

有名なのはご存知GitHubだが、もう一つ代表的なのにBitbucketがある。
両者ともGitを扱い、PullRequestがあったりと基本的な機能は同じだが、絶対的に違う点がいくつかある。
1)プライベートレポジトリの作成
GitHubは無料プランである限り、プライベートレポジトリは作成できず、常に全世界公開状態ですが、Bitbucketは対照的で、無料プランでもプライベートレポジトリが作成可能です。
ただし、レポジトリにアクセスできるユーザーは最大で5人までという条件があります。
つまり、Bitbucketは大人数での開発には向きません。
個人や少人数で、かつあまり見られたくない開発作業にはドンピシャリです。
2)日本語化
GitHubは完全に英語ですが、Bitbucketは日本語にも対応しています。
多少怪しい日本語ではありますが、誤解が生じないレベルで理解できるので、我らが英語の出来ない日本人には安心感があります。
ただ、一部の日本語が文字化けします。例えばコミットメッセージでよく「実装」という言葉を使っているのですが、これが「実�」と化けます。
まぁ正直、違いは1)に集約される。
SNS的側面を併せ持つGitHubと、あくまでレポジトリのホスティングサービスに徹するBitbucketといったところか。
で、これの使い分けだけど、僕は基本的にはGitHubを使い、見られては行けないコードが含まれているもの(何かのAPIのキーをベタ書きしているコードとか)はBitbucketを使うようにしている。
一時期は全部Bitbucketでやってたんだけど、「人に見られることがない」と思うと平気で汚くてその場しのぎのコードだらけになるんだよね。
GitHubに置いても誰かが見に来ることなんて無いんだけど、「見られる可能性がある」という事実だけで、良いコードを書こうとする意識が働く。
そういうところにこそ、GitHubを使う本当の意味があったりするのかな、と最近思う。
(大体、個人で使うならバージョン管理だけをすればいいから、Gitだけで十分のはずだ)
後、「GitHubを使うとなんかカッコイイ」「GitHubを使っていると、今時のプログラマって感じがする」、という、ミーハーな理由もある。
プログラマでこの先もやっていくとは思えないけどね。
早く帰国して公務員になりたい。

全角半角を区別せずに文字列を比較する。

Dictionary<string,object>のキーについて、ある文字列と全角半角を無視して比較を行おうとしていた。
最初は
Dictionary<string,object> dic=new Dictionary<string,object>(StringComparer.CurrentCultureIgnoreCase);
と設定すればいけるだろうと考えていたが、これでは全角半角は区別してしまうみたいだ。
他のCultureでも同様だ。

仕方ないので、以下のようにやった。

もっと良いやり方があるような気がするのだけど。

結婚式を祝うために

中学時代の友人Tが結婚することになった。

同世代が結婚という大人のステップを進んでいくのに何だか違和感を感じてしまう。
自分の精神年齢が子供のときから変わっていないせいなんだろう。
さて、Tの門出を祝福したいのだが、如何せん海外在住の身。結婚式にも参加できず、とりあえずフェイスブックで式当日にメッセージでも送ればいいか、と考えていた。
しかし先週、突然連絡が来た。それはTの友人で僕の友人でもあるYからだった。
「結婚式で流すメッセージビデオ撮って送ってくれない?」
無茶である。
しかも期限は来週までと来た。
とりあえず、マーライオンの近くで何かを話そうかな、と。
もちろんふざけたことを話して、最後はなんかいい話風に締めくくり茶を濁すつもりだ。
しかし、具体的な内容は思い浮かばない。
そして動画を撮影する道具もiPhoneぐらいしかない。
更にいうと一人で野外動画撮影、そして撮影被写体として喋るのはキツイものがある。
会社の人に頼むのは絶対に嫌だし、（会社では殆ど喋らないキャラです）
でも残念ながらシンガポールで頼める友達もいない。
あと動画編集もやったことないし。
誰か一人でも協力者がいれば、ずいぶんと違うんだけど。

DataTableの特定の行を別のDataTableに格納する。

「DataTableのある特定の行を抽出し、その結果を格納したDataTableを作る」という操作が必要になった。

何も悩む所は無いと思ったのだが、意外と何回も失敗し、最終的にカンニングをしたので、備忘録として書き記す。

つまり、DataRowはDataTableに所属するオブジェクトなので、
違うDataTableに追加するには全く新しい行を作成して追加しなくてはいけないということ。

もっとスマートにできないのかな。
わざわざSelectしたものをさらにDataTableにするというのがそもそもスマートじゃないのかもしれない。

git rebaseでコミット履歴を修正する

前回メモしたIssueからPullRequestを作成するをワークフローに入れるとある問題が生じる。

それは、空のコミットを作成しているせいで、そのPullRequestをMasterブランチにマージした場合、masterブランチに余計な空コミットが作成されてしまうという点だ。

正直言って、僕は「それでもいいじゃん、変更が追いにくくなるわけでもないし」という考えをしてしまうのだが、会社では可能な限りコミットは綺麗にする方針なので、コミットを修正する方針をとっている。
この変更なのだが、vimが使えないと辛い。
ネットで調べても「vim?使えて当然だろ」と言わんばかりの資料ばかり。
知らないのが悪い、自分で解決しろ、というプログラマのこういうところが嫌だ。
（自分の向上心のなさを棚に上げる）

とりあえず、仕事で使っている最低限のコミット修正、rebaseの使い方を書いていく。

1)commitを行い、pushできる状態にしておく

2)ログを確認し、どのコミットを修正したいか確認する

ex)今回は3番目のfixというコミットを、2番目のwriteというコミットに統合させることを目的とします

3)rebaseコマンドを打ち込む

  • git rebase -i HEAD~(戻る分のコミット数)
  • ex)git rebase -i HEAD~2

4)採用する修正(=最新の修正)のpickをfixupに書き換える

rebaseコマンドを行った途端こんな画面に。
入力する前にキーボードでiを押して入力モードにする。
今回はfixというコミットを採用するので、fixの行をpickからfixupに変更する。
入力したらescキーを押し、コマンドモードに戻る。

5)編集を完了させる

  • コマンドモードで”:wq“と打ち、Enterを押す

6)成功したかgit logで確認

成功。コミットが2つになっている。
“create”コミットの内容は編集前の”create”と”fix”を合わせたものになっている。
リネームが必要な場合は後述参照。

7)成功してれば、pushする。ただし、コミットの書き換えで競合が起こるので、強制pushする

  • git push origin +”ブランチ名”

僕のワークフローでは6)の後、もう一回rebaseでコミット名の修正をしています。
コミット名の修正は”pick”を”reword”として編集完了すればリネーム画面が開かれます。

vim触ったことなかったんだけどメリットが分からない。
どうも、PC初心者です。

第二回電王戦第四局

プログラミングの備忘録ばかり書いていて他のこと書いてなかった。

将棋のこと、でまず最初に思い浮かんだのが、今話題の電王戦。
コンピュータ対プロ棋士というパンドラの箱を開ける戦いで、現在までで3回開催された。
特に印象に残っているのが、第二回電王戦第四局、Ponanza対塚田九段戦。
賛否両論ある戦いなのだが、ドラマという意味ではこれを超す対局は歴史上でもあまりないと思う。
ちょっと説明。
塚田泰明九段はタイトル獲得歴もあり、「塚田スペシャル」という自分の名前を冠した戦法で一時期一世を風靡した強豪棋士です。
塚田スペシャルもそうなのですが、攻めっ気の多い棋風です。
とはいえ、既に50歳近くで全盛期をとうに過ぎ、酷い言い方をすれば「ロートル」という部類になるかもしれません。
（分かりやすく説明するためにあえて失礼な言い方をしています。念のため）
そんな塚田九段がコンピュータと戦う。
「正直言って八割型コンピュータの勝ちだ」と大半の将棋ファンは思っていたと思います。
事実、対局は序盤からじわりじわりとコンピュータが優勢を拡大する展開になりました。
そこで、塚田九段は決意します。コンピュータにただひとつ存在する明確な欠点を突くことを。
そう、入玉狙いです。
入玉狙いの手順が賛否両論を巻き起こしました。
プロ棋士が「正々堂々」でなくコンピュータの欠点を突くということは、既に負けを認めたも同然じゃないか、という話です。
（まず、「正々堂々」の定義が考えるほど分からなくなります。「普通の人間同士の対局と同じように」という意味かと思いますが）
しかし、塚田九段はひたすらに逃走劇を繰り広げます。大駒を全て渡し、それでもただひたすらに相手陣に向かいます。
入玉しても勝ちになるわけではありません。
両者入玉になった場合、駒で決まる点数で勝負が決まります。
塚田九段は既にあまりに多くの駒を渡し過ぎていました。
入玉を果たしてもコンピュータに入玉をされたら点数勝負になり、負けになります。
しかし、先程述べたように、入玉が絡む局面はコンピュータの苦手とするところなのです。
塚田九段はここでコンピュータは入玉をしてこないと読んでいたようです。
しかし、塚田九段が入玉を果たした直後、非情にもコンピュータの玉は塚田陣に向かい始めました。
コンピュータの入玉、それはすなわち点数勝負になり、このままでは負けることを意味します。
敗北を回避するにはただひとつ、相手の駒を取り、引き分けに持ち込めるだけの点数をかき集めるしかありません。
予め断っておくと、人間同士の戦いならこれはまず不可能です。そういった局面でした。
しかし、相手はコンピュータ、インデックスの境界範囲外になればまだ何が起こるかわかりません。
ただ、ひたすらに塚田九段は指し続けました。
それは不毛にも思える時間でした。
実際、このときの控室ではもう対局を中止させようという話が持ち上がっていたそうです。
このままではプロ棋士の権威が無くなる、塚田九段がただ傷付くだけだと。
それを制止したのが塚田九段と同期、この対極の立会人を務めていた神谷七段（現八段）でした。
規定では250手までは指すルールなので、当然の行動ですが、そこには同期棋士としての、信頼があったような、そんなふうに考えてしまいます（後述）。
両者入玉。点数はコンピュータが勝利条件を満たしている。
このまま行けば塚田九段の敗北です。
もはやどれだけ続いたか分からない不毛な指し手の連続に、ニコニコ生放送の解説は段々と茶化したような笑い混じりになってきました。
しかし、ここでとうとうコンピュータに波乱が起きます。
入玉勝負では悪手とした思えない指し手が続いたのです。
とうとうコンピュータは相入玉のこの局面を理解できなくなってきたのです。
惨めな時間がいよいよ報われました。塚田九段は大駒を一枚取り返し、小駒をかき集めます。
そしてとうとう、引き分けに持ち込める局面になったのです。
そこからの様子は下記動画でご覧になれます。

冒頭の木村八段の解説様子からわかるように、終局間際とは思えない笑い混じりの状況です。
見ていた当時は何も違和感はありませんでしたが、今振り返ると異常ですね。
00:20–塚田九段が駒を指さして点数カウント。通常の対局ではまず見られない光景です。
03:00-グダグダした確認の後、対局終了。謎の空気。
ここから終始、立会の神谷七段は笑顔です。
この異常な状況に対する単純な笑い、同士のひたむきな指し手が報われた喜び、コンピュータ相手に敗北しなかった安堵、そして対局を止めようとした者達への「見たか」という思いとか、とにかくまぁきっと色々な思いがあったのだと思います。
しかし、その神谷七段も、この異常な状況に酔っていたのかもしれません。
07:15-「投了しようと思ったか」という質問に対し、塚田九段が突然涙する。
そしてその涙を見た瞬間、神谷七段の顔から笑顔が消えます。
神谷七段は同期の塚田九段がここまで戦ってくれて嬉しかった。それは事実だと思います。
ただ、先ほど書いたように、この異常状況で、あることが思考から抜け落ちていたのだと思います。
戦っているのは塚田九段だけだということ。
プライドを捨て、惨めな手を指し続け、その姿を全世界に晒しているのは、塚田九段本人だけだということを。
その計り知れないものの重さを、神谷七段だけじゃない、多分塚田九段を除いた全世界の人が、気付けてなかったのかも知れない。
これほどにまで印象的なシーンは貴重だと思う。
電王戦はこの後も続いているが、ここまでに異常な対局は未だ現れていない。
この対局の話はネット上に溢れてるし、何番煎じかわからない。
でも、将棋と聞いてまず最初に思いついたのがこれなので、素直に書いてみた。
以上、稚拙な文章で失礼しました。

IssueからPullRequestを作成する

hubコマンドで僕が一番使うのがIssueをPullRequestに変更するコマンド。

（っていうかこれしか使わない。極力複雑なことは便利であってもしたくないのです）

理由は仕事でのワークフローがIssueごとにPullRequestを作成して、
レビューを貰ってマージするという方式だから。
正直Issueいらないんじゃないかなって思ってる。
このコマンド、将来的には無くなるらしい。
けど今は使っているので、使い方をメモしておく。
1)PullRequest用のブランチを作成する
  • git checkout -b "ブランチ名"
2)PullRequest作成のためにコミットが必要なので、空のコミットを行う
  • git commit --allow-empty -m "コミットのメッセージ"
3)リモートレポジトリ(ってかGitHub)上にpushする
  • git push origin "ブランチ名"
4)hubコマンドでissueを現ブランチから作成されたPullRequestに変更する
  • hub pull-request -i "Issue番号" -b "ベースにするブランチ名"
以上。
4)の”-b”をずっと”branch”だと勘違いしていた。
“base”の意味だそうです。
2)が必要だったり、このワークフローあまりよくない気がするな。

手元に資料がない状態で書いてるので間違ってるところがあるかも。
資料見て間違ってたら修正します。

追記20140515
2)のコマンドが間違っていたので修正。

追記20140517
言うまでもありませんが、既に変更が加わっている場合はわざわざ2)をする必要はありません。
普通にコミットしてください。
自分のワークフローでは「作業前にプルリクエストを作成する」というルールがあるので、
作業前に空コミットを作成してプルリクエスト作成可能状態にしているのです。