探し出せないページ

私の現在の勤め先は、コードレビューを行う、そこそこマトモな開発体制なので、私も他人の書いたコードをレビューする事が有る。先日レビューしたコードに「コレクションクラスのオブジェクトをコレクションしたコレクションクラスのオブジェクト」が含まれていたので、それは拙いと指摘した。ここでいう「コレクションクラスのオブジェクトをコレクションしたコレクションクラスのオブジェクト」が何を指しているかと言うと、例えばList<List<String>>だとかList<Map<String, String>>だとか、その手の型のオブジェクトの事である。これが適切なケースも在るが、大抵はそうではない。より内側のコレクションクラスは、それを表現する独自のクラスを定義出来る事が大半だし、そうした方が読み書きしやすくなる。

これは、過去に私自身が実際に痛い目を見た事でも在るが、別のプログラマーが体験した事でもある。何故そう言えるかと言うと、そのプログラマーが教訓として文章化した物を読んだ事が有るからだ。レビューの指摘事項の根拠の補強として提示しようと思ったのだが、困った事に、それが誰が何処に書いた文章なのかサッパリ思い出せない。適当なキーワードを推測してググってみても見つからない。一言一句、正確に憶えているならばフレーズ検索で探し出せるのかも知れないが、それは無理な注文というものだ。

こういったページを探し出す上手い手段というのは何か無いのだろうか……

コミットログは現在形?過去形?それとも?

コミットログに過去形の英語があるとスゴイ違和感を感じるけど、GitHubとかをみている限りでは間違ってる英語の作法でもなさそうなんだよな。おれんなかではコミットログは世界の真理に相当しなければならないものなので、過去形使うのはおかしいと思ってるんだと思う。

— TAKANO Mitsuhiro (@takano32) June 22, 2012

という@takano32のtweetが気になった。

自分自身は英語の現在形で書いている。特に深い考えが有っての事ではない。以前何処かで「過去形は使わない方が良い」という話を読んでそれに倣っているだけだ。が、考えてみたら何やら妙だ。

「コミットログに過去形使うな」って、そういえばなんでなんだろう。修正を行った後でcommitする訳だから、その修正内容を過去形で書かれてても文法的におかしくない……というよりむしろ過去形じゃないとおかしいような……

— 天井冴太 (実際親指) (@AmaiSaeta) June 22, 2012

「コミットログに過去形使うな」って事は、「○○を修正した」じゃなくて「○○を修正する」という内容になる訳で、「いや『する』じゃねーよしろよしてからcommitしろよ」って話になるよな。冷静に考えたら。

— 天井冴太 (実際親指) (@AmaiSaeta) June 22, 2012

文法的に変な気がしてきた……

どうにも気になるのでGoogle先生にお伺いを立ててみる。"コミットログ 過去形"で検索し、検索結果5頁分からそれっぽい物をばーっと開いてみる。

• Mercurial MQ について - daily dayflower

  パッチにメッセージをつける

  ((略))

  $ hg qrefresh -m "カクテルとワインを追加した"

• うーむ。チュートリアルでコミットログは過去形 "Added", "Removed"... - Kosei Kitahara - FriendFeed

  うーむ。チュートリアルでコミットログは過去形 "Added", "Removed" で書かれてるけど、俺は現在進行形 "Adding", "Removing" で書く派。

• Twitter / eller86: コミットログは現?

  コミットログは現在形で書くべきか過去形で書くべきか。現在形が多いの？

• Twitter / SubaruG: そういえば、コミ?

  そういえば、コミットログの英語って現在形で書くべきなのか過去形で書くべきなのか。 個人で開発してる時は趣味で過去形で書いてるけど、会社のコードだとみんな現在形で書いているっぽいんだよねー。

• Twitter / mrkn: 僕はコミットの理?

  僕はコミットの理由を書くように努力するので、場合によっては完了形とかも出てくる。 RT @kei_s: コミットログは過去形じゃなくて現在形でやってる http://repo.or.cz/w/git.git ?#coffeerb?

うーん、人に依りけり。同じように悩んでる人(ログ)も。

イマイチはっきりしないので、人力検索はてなにアンケートを立ててみた。はてなのアカウント持ってる人は是非回答を寄せて欲しい。

貴方のコミットログの書き方について - 人力検索はてな

BOOST_PP_SEQ_FOR_EACHは、第1引数に指定したマクロの中でBOOST_PP_SEQ_FOR_EACHが使えない?

#include <iostream>
using namespace std;
 
#include <boost/preprocessor.hpp>
 
#define M2(r, data, elem) elem
#define M1(r, data, elem) BOOST_PP_SEQ_FOR_EACH(M2, data, elem)
 
int main()
{
        // M1のBOOST_PP_SEQ_FOR_EACHが解釈されない
        cout << BOOST_PP_STRINGIZE(BOOST_PP_SEQ_FOR_EACH(M1, data, ((1)(2)(3))((4)(5)(6)))) << endl;
 
        // M1を直接呼ぶと、～SEQ_FOR_EACHは解釈されている
        cout << BOOST_PP_STRINGIZE(M1(_, data, (10)(11)(12))) << endl;
        
        // BOOST_PP_SEQ_FOR_EACHで呼び出したマクロ中で、BOOST_PP_SEQ_FOR_EACHは使えないのか?
}

とすると、

BOOST_PP_SEQ_FOR_EACH(M2, data, (1)(2)(3)) BOOST_PP_SEQ_FOR_EACH(M2, data, (4)(5)(6))
10 11 12

これこの通り。

上のコードはテストの為に単純化してて、これくらいならBOOST_PP_SEQ_FOR_EACH_PRODUCT使えばいけるんじゃないかなぁと思うけど、
内側のsequencesの特定の要素だけ別の処理を行いたい、といった場合は駄目だろうし。

うーん…………何でだろう?

nullptrに対する素朴な疑問

数日前Twitterでもtweetしたけど。

nullptrってなんぞ?って話は、まぁ、C++0x - nullptr - Faith and Brave - C++で遊ぼうあたり参照。

『ヌルポインタを表すキーワード』の必要性は分かる。でもそれのために、わざわざnullptrなんて新キーワードを作る必要性があったんだろうか。既に在るNULLをキーワードにするんじゃ駄目なんだろうか。

標準ライブラリ内で定義されている#defineマクロをキーワードに昇格(?)させるんじゃ駄目なのかなぁ。C言語ではただのtypedefだったwchar_tをC++ではキーワードにしたみたいに。

そりゃ、マクロっぽい名前でキモイ、という欠点はあるけど。

既存のソースコードとの衝突を忌避したとしても、標準ライブラリで用意されている物と同じ名前の物を定義しているプログラムなんて在るのかなぁ。仮に在ったとしても、『ヌルポインタ』以外の意味で定義しているプログラムとか存在するのか?

……という、素朴な疑問。
多分、何らかの理由が有っての事だろうけど、その理由が分からない。誰か知ってる人教えて。

グローバルIPってどうやって取得すれば良いんだろう?

ちょっとメモ代わりに。

現在とあるプログラムを作っているが、グローバルIPアドレスをどうやって取得すべきか悩んでいる。

使っている言語はJavaなのだが、java.net.InetAddress.getLocalHost().getHostAddress().toString()だと、192.168.1.xxxといった感じのローカルのアドレスしか取得出来ない。

こことかここを見た感じでは、
外部サイトで出力→その結果を取得しアドレス部分以外(もしあれば)を除外する
という流れになるようだが、外部サイトが落ちる可能性を考えるとあまり使いたくない。自分だけが使うプログラムだというなら兎も角、配布を考えているものだしなぁ……

なんとか外部の力を借りずに取得する方法って無いモノかなぁ……

祝日の処理メンドイ

会社でカレンダ的なものを作っている。んで、『休日は背景色を変える』という部分を実装しようとして困った。
どうやって祝日かどうかを判定しよう?

プログラムの中に祝日の情報を持たせるよりは、外部にデータとして切り分けた方がスマートだろうとは思うが。そうなるとハッピーマンデー制度が激しく邪魔なんだよなぁ。かといってプログラム中に判定処理持ち込んだら法改正された時とか面倒な事になるし。

とか考えながらwebをウロウロしていたら、ハッピーマンデー制度の奴はまだマシだった。

春分の日は、3月20日から3月21日ごろ。祝日法の上では「春分日」としている。その前年の2月1日に、国立天文台が作成する『暦象年表』という小冊子に基づいて閣議で決定され、官報で発表される。よって、2年後以降の春分の日の日付は確定していないことになるが、これまでに、天文計算によって求められた春分の日付以外の日が春分の日とされたことはない。なお、天文計算上2025年までは閏年とその翌年が3月20日になり、その他の年は3月21日となる。

wikipediaによると、春分の日はエラい人達が決定しているらしい。秋分の日も然り。

って、ちょ、えぇ!?どうしようもないじゃん。

もしも祝日の一覧がXMLだったらで『XMLで祝日情報を発信してよ政治家なエラい人!!』という主張をされているが、全く持って同意。いやもうXMLじゃなくてもいいや。YAMLでもJSONでもなんならCSVでも。有名な形式でパーサが簡単に見つけられそうなヤツか、パーサを簡単に実装出来るヤツならなんだって。

いや本当に何とかしてください。エラい人。

どうしようもない

一応簡易計算式はあるけど、必ずその通りになるとは限らないので……

WSHでMSXMLのSAXが使えない件

いや、タイトルのマンマの内容なんだけど。かなり悩んだのでメモ。

XMLを処理するプログラムを書く必要が出来た。Perlで書こうかとも思ったが、家のPCだけでなく、某専門学校でも使える必要があったので、とりあえず、まず間違いなく現在動作しているWindows環境なら何処でも動くであろうWSHとMSXMLをチョイス。

続きを読む

デフォルトスタイルシートうざい

いや、もう、ホントに。何でこの世にデフォルトスタイルシートなんてものがあるんだろうとか思う。勿論CSSが指定されてないページだとか、under HTML 4.0なページの為なんだろうけど。

いっそCSS指定されている要素はデフォルトスタイルシート無視するようになればいいのに。もしくはそういうCSSプロパティ用意するとか。

各UA(ブラウザー)は、それぞれ微妙に違ったデフォルトスタイルシートを持っている為、この差異が原因で「こっちは揃っているけど、あっちのブラウザーでは、なんかずれてる」なんて事がよく起こります。

なので、まず最初にUAのデフォルトスタイルシートの各エレメントの見栄えを制作者のスタイルシートで再定義して上書きし、各UAの表示のデコボコを出来るだけ埋めてからCSSデザインし始めるというやり方が楽チンだ。

僕はいつも、「デコボコ埋め+自分好みの大まかなスタイル」を定義して纏めたdefault.cssを用意して、必ず最初にそれを読み込ませてからレイアウトなどを組み、デザインに合わせてdefault.cssの各エレメントのスタイルを調整しながら作っている。

次善の策として上に引用したデフォルトスタイルの差異をなるべく無くすCSSみたいな方法があるが……でもこれって正確にデフォルトのスタイルを殺すには全プロパティを指定しないといけないんじゃなかろうか。CSSのプロパティって何種類有るんだろう?正直数えようって気が起きない。

CSS を作成している際に、当然の如くブラウザによって描画結果に違いが出てくるわけで、ムキーとか言いながらその差異を埋めていく作業が一番面倒っちゃあ面倒。んで、ボックスモデルやその他ブラウザごとのバグ以外で、極力そう言った差異を少なくするためには、一番最初に全称セレクタを使ってブラウザのデフォルトスタイルを消してしまうのが手っ取り早い。

全称セレクタってのは意外と盲点だった。そうかそんなものが在ったね。