はてなブックマーク

はてブで単一責任の原則（Single responsibility principle）について、もう一度考えるといふ記事を見掛けて、なんとなく懐かしい気持ちになった。久し振りにこの言葉を見たなって。 「一つのモノに一つの責任 (役割) を」といふモットーは、初めて聞いた時にはすごくもっともらしく聞こえるんだけど、いろいろ考へてくと結局「責任が一つであるとはどういふことなのか?」「といふか、責任って一つとか二つとか数へられるものなのか?」といふ疑念を抱くよね。俺も昔さう思ひました。 で、この菅野さんの記事では「責任が一つであるとは、一人の利用者 (アクター) に対してだけ責務を果たすこと」といふ話をしてゐる。その理解はたぶんそんなに間違ってはゐないと思ふ。ブコメに「作者の人そこまで考えてないと思うよ」とかいふコメントもあったけれども、菅野さんの記事が信用できないと思ふんならボブ本人による記

POSIX シェルの小ネタ集。随時更新。 POSIX の範囲外の機能に依存するところには 【non-POSIX】 と書いておいた。 ファイル操作 空のファイルを作る touch でもいいがリダイレクトした方が速い。 >> filename # 既存ファイルは上書きしない (ファイルの更新日時も変へない) >| filename # 既存ファイルは空にする > filename # -C が有効なら既存ファイルがあるとエラーになる フィルタ ソートして重複行を消す sort | uniq でもいいが sort -u だと一コマンドで済む。 ソートせずに重複行を消す awk '!x[$0]++' 1 行番号を付加する awk '{print ++i,$0}' 【non-POSIX】 cat -n 一行目だけを消す tail -n +2 sed 1d 最後の行だけを消す head -n -1 s

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 はもちろん

うまくクラス名を付けるための参考情報といふ記事を見掛けて、「動詞+er」のパターンがちょっと多くていまいちだなーとか思って書いた記事です。 以前クラスの命名のアンチパターンといふ記事を書きましたが、これを読んで「Animation と Animator とではどっちがええんやろ?」と思った人への回答でもあります。 昔の Java では可変文字列クラスは StringBuffer と呼ばれてゐました。C# や最近の Java では可変文字列クラスは StringBuilder と呼ばれます。Objective-C では MutableString です1。 私はこの中では MutableString が最も良いと思ってゐます。次点は StringBuffer です。 StringBuilder はダメです。 MutableString が良い理由は、完全にその名が体を表してゐるからです。直訳

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? OS X Server に含まれてる Xcode Server を使って iOS アプリの自動ビルド環境を作ってみた。 概要 環境 MacBook Pro Mid 2014 OS X 10.11.1 OS X Server 5.0.15 Xcode 7.1.1 ビルド対象は、うちの会社で作ってる某 iOS 向けアプリ できたこと: GitHub に誰かがコミットをプッシュしたら、自動的にコミットをプルし、アプリをビルドし、アナライズし、インストール済の全てのシミュレーターでそれぞれユニットテストを実行し、アーカイブし、結果 (エラーや警

シェルスクリプトで、あるファイルパスに別の相対ファイルパスを連結して新しいファイルパスを得るには次のようにします。 前提 ベースとなるパス base は空文字列ではない 連結するパス rel は空文字列ではなく、かつスラッシュで始まらない コード 解説 結果が単語分割されるを避けるため、全体を二重引用符で囲みます。 ${base%/} で、 base の末尾にスラッシュがある場合にはそれを(一つ)消します。これにより base がスラッシュのみからなるパスである場合でもスラッシュの数が変わることを防ぎます。例えば base が / で rel が home ならば結果は /home になります。 ここでもし "${base}/${rel}" を使ったとしたら、結果は //home になります。Cygwin などの環境ではスラッシュ二つが特別な意味を持つため、これは正しい結果ではありません。

並行プログラミングの設計に関する本に関して適当にググると 「並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミング」とか「マルチコアCPUのための並列プログラミング」とかいったものが出てくる。これらの本の主題は、ソートや探索などの比較的大きな計算問題をどのように並列化して解くか、そしてアルゴリズムを問題の大きさやスレッドの数に対してどうスケールさせるかといふことだ。 しかし、一般的な GUI アプリ開発では、GUI を操作するためのスレッドと他のスレッドとの通信や同期の仕方が問題になる。これがうまく出来てゐないアプリでは、例えば 処理を行ってゐる間、アプリが操作を受け付けなくなる 処理を開始するボタンを素速く二回クリックしたら、二つの操作の結果が混ざって出力されたり片方の結果しか出力されなかったりする などといった問題が発生したりする。 この類の問題を起こさないために必

ソフトウェア原則[1] - OCP(Open-Close Principle) と云ふ記事に「(引用者註: プログラムをオブジェクト指向で書き直すことによって) 修正の論理を、追加の論理に変換している」と書いてあったのですがそれは公平なものの見方ではないと思ったのでここに記しておきます。 開かれてゐると云ふことの真実 元記事にある C++ で書かれた例では、 Shape 親クラスに Circle 子クラスを追加しても既存の Point 子クラスや Line 子クラスの実装を修正する必要はないことが示されてゐます。つまり、Shape クラスは新たな図形の種類を表す子クラスの追加に対して開かれてゐるといふことですね。 しかしこの C++ の例は、図形に対する操作の追加に対しては開かれてゐません。例へば、既にある draw (描画する) といふ操作に加へて translate (平行移動する)

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Working Effectively with Legacy Code を読んで重要さうな点や気になったことなどをメモっていきます。(随時更新) お断り: 英語の原著を読んでゐます。和訳版 (『レガシーコード改善ガイド』) とは訳語が異なることがあります。 The Mechanics of Change 1. Changing Software 変に弄って壊れたら嫌なので、必要最低限のコード変更しかしない → 設計の崩壊 → コードが理解できなくなってくる → 始めに戻る＼(^o^)／ 2. Working with Feedback

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

理系だからって日本語を間違って使っていいってことにはなりませんよ 適用は「一般的な規則や定理を具体的な事例に当てはめること」。他動詞。 例: HTML 文書にスタイルシートを適用する 関数を値に適用する 「関数に値を適用する」ではない クイックソートアルゴリズムを乱数列に適用する 修正パッチをプログラムに適用する 経営に失敗した企業に会社更生法を適用する 適応は「状況に合せて自分自身を変化させること」または「対象と相性がよく効果を発揮すること」。自動詞。 例: 最初の意味 企業が市場の変化に適応するために事業戦略を変更する 海から陸に上がった生物が地上の環境に適応する 二つ目の意味 挿入ソートアルゴリズムは予めある程度ソートされたデータに適応する 花粉症に適応する薬

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 は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど

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 の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければなら

適当にググると「とにかく何でも .bash_profile に書いとけばおk」みたいな嘘を書いたブログ記事がわんさか出てくるのでここに正解を書いておきます。 .bash_profile .bash_profile はログイン時にのみ実行されます。具体的な用途は: 環境変数を設定する (export する変数) 環境変数はプロセス間で勝手に受け継がれるのでログイン時のみ設定すれば十分です。 .bashrc .bashrc は対話モードの bash を起動する時に毎回実行されます。具体的な用途は: 環境変数でない変数を設定する (export しない変数) エイリアスを定義する シェル関数を定義する コマンドライン補完の設定をする これらは bash を起動する度に毎回設定する必要があるものです。 その他 .bash_profile ? .bashrc ? いろいろあるけどこいつらなにもの？

特殊組み込みコマンド 特殊組み込みコマンドは、以下の特性を持つ 対応する外部コマンドがなくても必ず実行される 同名の関数で動作を上書きできない シェルが対話モードでないとき (≒ シェルスクリプトを実行中のとき)、以下のエラーが発生するとシェルは直ちに終了する コマンドの構文誤り リダイレクト失敗 変数代入失敗 特殊組み込みコマンドに対して行った変数代入は特殊組み込みコマンド実行終了後も残る 特殊組み込みコマンド: . : break continue eval exec exit export readonly return set shift times trap unset 準特殊組み込みコマンド POSIX には「準特殊」なる用語は出てこないが、ここでは便宜上その様に呼んでおく。 準特殊組み込みコマンドは、対応する外部コマンドがなくても必ず実行される。(他の点は普通の組み込みコマン