Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? シェルスクリプトは、Unix 系環境で仕事をするエンジニアなら誰もが一度は書くであろうにもかかわらず、書き方や特性を熟知している人が少ない言語です。この記事は、シェルスクリプトを書くときに罠を踏まないようにするために最低限あなたが気を付けるべき tips 集です。「たかがシェルスクリプト」とは思わないでください。生半可に書かれたシェルスクリプトはあなたの (チームの) 生産性をかえって低下させます。 Shebang に bash を明示しろ Bash でしか使えない機能のことを俗に Bashism と言います。Bashism はもちろん
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければなら
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParame
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど
POSIX 2013 より前の POSIX 規格では、シグナルハンドラ内で出来ることはかなり制限されてゐました。出来ることはせいぜい volatile な sig_atomic_t 型の静的記憶域期間変数に値を代入することによってフラグを立てる程度でした。 POSIX 2013 ではシグナルハンドラの制約が緩和され、単一スレッドプログラムでは以下の様な場面で「シグナルハンドラ内で何をしても良い」ことになりました。 sigprocmask 関数でシグナルをブロックしておく。また sigaction 関数等でシグナルハンドラを設定しておく。 スレッドにシグナルが送信される (が、ブロックされてゐるのでシグナルハンドラはまだ呼ばれない)。 sigprocmask 関数 (または pselect や sigsuspend 等) でシグナルのブロックを解除する。この時 sigprocmask 関数等
Is git pull the least problematic way of updating a git repository? と云ふ Stack Overflow の Q&A を見掛けたんだが、 git pull は考へ無しにローカルブランチとリモートブランチをマージするから良くないんだと。う～ん、どうですかねえ。 ブランチをマージしたら動かなくなったと言ふのは可能性としてはありうるけれども、コンフリクトが発生しない様な簡単なマージでさういふことが起こることはかなり稀なので、いちいちマージして良いかどうかをマージ前に検討するのは割と無駄骨である様な気がする。 もっとも、俺は普段 git remote update --prune を使ふことが多いので git pull の有害性に関しては特に考へたことは無かったのだが。 そもそも「変更は常に master 以外の開発用ブランチを作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
