日々

link permalink

N クイーン問題

少しだけ link N クイーン問題 JavaScript 版のソルバを更新しました。右上の角にある場合(1列目)は、N - 1 の大きさの盤の問題を解くこととほぼ同じ、と見なすことで、1割ほど速くなりました。

他の言語でもやってみようと思い、試しに Java 版に同じ実装をしてみましたが、全く速くなりません。うーん、なんでだろう……?

以下、各言語版の N クイーン問題のソルバへのリンクです。

[編集者: すずき]
[更新: 2014年 12月 5日 02:19]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

C++11 に突っ込み過ぎた

C++11 を訳も分からず使っていたら、華麗に爆死しました。

Debian 7.7 wheezy の g++(※)は C++11 の std::regex が使えません。警告もエラーも出ず、中途半端に動くため混乱します。例えば、

  • 合っている正規表現に regex_error をスロー
  • 絶対パターンマッチする regex_search でもマッチしない

など、性質の悪い動きをします。

参照サイト(Qiita - 2013-10-03 以前の GNU libstdc++ では C++11 の正規表現は使えません)のおっしゃる通り、std::regex を使うのは諦めて、boost::regex を使います。

しばらくは libstdc++ のバージョンは要チェックかな……。

おかしな動きをする例

std::regex r("abc"); //OK, but not work fine...
std::regex r("[ ]"); //NG, std::regex_error

(※)g++ (Debian 4.7.2-5) 4.7.2

メモ: 技術系の話は Facebook から転記しておくことにした。

[編集者: すずき]
[更新: 2015年 11月 29日 05:42]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

おー人事、おー人事

最近、職場から人が去っていくことが多く寂しい限りです。

人が去るとき、残った人にコードを引き継ぎますが、大抵の場合、さほど詳しくない人がコードを引き継ぐことになります。

詳しくない人が、引き継いだコードを使おう、変えよう、とするのは非常に大変です。自身の経験でも、周りの人を見ていても、そう思います。

さほど詳しくないコードを引き継ぐときに、この情報があれば良かった…と思うことが 2つあったので、自分が何か作るときの戒めとして書いておきます。

あったら良かった 2つのこと

  • 1つ目は初心者のための「使い方」
  • 2つ目は熟練者のための「なぜその方法を取ったか」

「使い方」は、初めての人でも数分〜 1時間で使い方がわかると嬉しいですね。

引き継いだのに初心者ってことは無いだろう?と思われるかもしれませんが、残念ながら、実際のところ初心者のことが多いです。断片的な設計資料があればマシな方ですが、初心者には全く役に立たない場合が多いです。

「なぜその方法を取ったか」は、コードを読んでも見えてこない設計の「Why」が書いてあると嬉しいですね。

文章の 5W1H と同じように、コードにも「When」「Where」「Who」「What」「How」が書かれています。余程クソみたいなコードじゃない限り、仮に設計資料が全く無かったとしても、コードを読んだり、動かしながら解析すれば 5W1H までは何とかなりますが、「Why」は絶対にわかりません。

例えば、問題 Q があって、方式 A と方式 B という解決方法があったとします。コードを読んだり解析すれば、Q を解決しようとしていること、A を採用していること、まではわかります。しかし、なぜ A を採用したか?は、いくらコードを見てもわからないのです。

設計の「Why」にこだわる理由は、設計を変更する(例えば方式 A を方式 B に変える)時に、非常に重要な情報となるからです。

単に方式 A しか知らなかっただけなら、方式 B への置き換えは検討に値するでしょう。でも B は地雷で別の問題を誘発するなら、B は地雷だと書いておけば後継者が無駄な検討をせずに済むはずです。

情報を残す場所

自身の経験から言って、コードのなるべく近くに「使い方」と「なぜその方法を取ったか」があると嬉しいです。情報を残す手段として良く見かけるのは 4つです。

1つ目、Wiki や Trac などの Web システムです。

  • まとめて書ける、読みやすいのが利点
  • コードとの対応が取りづらいのが欠点

特に「使い方」を書くとき、多人数に公開する情報を書くときに向いていると思います。コードと一緒にはできないので、コードとの対応を書いておくと良いと思います。

2つ目、PowerPoint のスライドです。会社では一番多く見かけます。

  • 図が書きやすいのが利点
  • 差分が追いづらい、コードとの対応が取りづらいのが欠点

コードとバラバラに管理すると散逸しやすいので PowerPoint で情報を残したいなら、コードと一緒にコミットすると良いと思います。

3つ目、README のようなテキストです。

  • 差分が追いやすく、まとめて書けるのが利点
  • 長くなると読みづらく、コードとの対応が取りづらいのが欠点

コードのトップディレクトリに置いておくと目立つので「使い方」を書くときに向いていると思います。コードと一緒にコミットするのが普通でしょう。

4つ目、コードのコメントです。

  • 差分が追いやすく、コードとの対応が取りやすいのが利点
  • まとまりがなくなるのが欠点

必ずコードの近くに書けるので「なぜその方法を取ったか」を書くときに向いていると思います。コードと一緒にコミットされる(そうせざるを得ない)のも良いですね。

[編集者: すずき]
[更新: 2014年 12月 27日 15:59]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

残念なコメント

コードのコメントは有った方が嬉しいですが、有ればいいってもんでもないです。

たとえば…、下記のような「見たら分かるわ!このおバカ!」というレベルのコメントは、いくら有っても嬉しくありません

残念なコメントの例

//hogeの合計を出す
for (i = 0; i < hoge_length; i++) {
    sum += hoge[i];
}

こんなコメントより、合計を何に使うのか?どうして今計算するのか?のコメントの方が嬉しいですよね。

しかし会社のコードでは、ひどいレベルのコメントを良く見かけるので、残念極まりないです。仮にもソフト開発部門なのに、こんな体たらくで良いのか……?

メモ: 技術系の話は Facebook から転記しておくことにした。

[編集者: すずき]
[更新: 2015年 11月 29日 05:36]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

継承と委譲

今日、初めて 〜Java 7 の単一継承でつまづきました。

Java なら継承じゃなくて、委譲だろ?という天の声が聞こえますが、委譲先と同じ名前の関数が増えてうっとおしいです。継承の方がスマートだと思うんだけどなあ…。

このまま委譲で作るか、思い切って Java 8 の Mix-in 機能に変えるか、悩ましい。

メモ: 技術系の話は Facebook から転記しておくことにした。

[編集者: すずき]
[更新: 2015年 11月 29日 05:33]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

電線に掛かる電圧

切れた電線に絶対に近寄るな(参考: 東京電力のサイト)、という注意文を初めて見たのは、確か小学生だったと思うのですが、当時は電線の電圧が 100ボルトだと勘違いしていたので、切れた電線が何故そんなに危険なのかよく分かって居ませんでした。

しかし高校か大学だったか、実は、その辺の電信柱を通っている電線の電圧は 6600ボルトだと知って戦慄を覚えました…。

メモ: 技術系の話は Facebook から転記しておくことにした。

[編集者: すずき]
[更新: 2015年 11月 29日 05:31]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報