技術関連メモ

技術関連の短いメモです。その他 Etc. 配下のコンテンツですが、タメになったメモもご参考にドウゾ。

目次

• 有用なリンク
• みんなのナレッジベース
• 用語
• 雑多
• ドキュメンテーション
• マインド
• 半分ネタ

有用なリンク

• BugbearR's Wiki - システム開発
• BugbearR's Wiki - 開発規約
  • BugbearR's Wiki - 開発規約/11 開発に必要と思われる文書の一覧
  • BugbearR's Wiki - 開発規約/12 品質とは何か
• 玄系 プロジェクト管理者の道具箱 - システム開発
• reverse-interview/JAPANESE.md at master · viraptor/reverse-interview

みんなのナレッジベース

• 八寿のナレッジベース
• yutkat/katapedia: この書は常に未完成である。内容の正誤に保証はない。 ITエンジニアとして役になったTips、よく忘れることを記す。 ブログに記載してもよかったが、水平方向の情報を見つけやすい本の形式をとることにした

用語

• ダチョウ・アルゴリズム
  • 発生することが極めて稀な問題を無視する、という戦略。レアケースを考慮するためのコストを天秤にかけて、対策として用いることがある
• ドイッチュ限界
  • ビジュアルプログラミングは、画面上に一度に50を超える要素を表示できない、という警句
• ヨーヨー問題
  • 継承関係が深すぎたり複雑過ぎたりするプログラムを読む時に、多くのクラスを行ったり来たりしないと読めない状況のこと
  • 過剰なオブジェクト指向プログラミングなどで発生しやすく、複数の情報源を頭に入れておかないといけないシステムは作りが良くない
• PIE : Program Intently and Expressively 意図を表現してプログラミングせよ
• SLAP : Single Level of Abstraction Principle 抽象化レベルの統一
• Remove は「取り除く」。Unix の rm はディレクトリからエントリを取り除き、参照カウントが0になった時に実体が回収される。名前の通りの動作。

雑多

• カナかな団の躁鬱_CSS とか HTML
• Database Answers | We provide advice on Best Practice in Data Modelling and over 1,000 free Databases.

• アジャイル開発はコミットメント(約束)を大切にしてないよ。指標と実績を計測可能にして科学的にそのずれを最小にすることで見積もり精度を高めるアプローチだよ。見積もりの話なのに、真逆の説明しないでー

• コンテクストメニューの役割 (agenda)
  • コンテクストメニューは、ポイントされているオブジェクト、または位置に関する操作を行う為のメニューに絞るべき
  • 「何故コンテクストメニューなのか」を全く考えないまま、直感的に便利だからという理由でコンテクストメニューに機能を詰め込んでいると思われるアドオンが多すぎ。「ポイントしなくても良い操作なら、コンテクストメニューにしてはならない」くらいの制約をまず課して考えてほしい
• 要件定義～システム設計ができる人材になれる記事 - Qiita
• 多い日も安心設計 - Qiita
• 【若手向け】上司にウケる会社の目標設定例 - Qiita
• プログラミングの素人と玄人を見分ける方法

  • 一つの関数内に、コードを数百行も書くのは素人。多くても数十行で済ませるのは玄人。何千行でも平気で書くのはギーク。
  • オブジェクト指向をまだ理解していないのは素人。何かとオブジェクト指向と言うのは玄人。オブジェクト指向という言葉を一言も発さないのはギーク。
  • 一つのプログラミング言語しか使えないのは素人。数十種類のプログラミング言語を使いこなせるのは玄人。プログラミング言語を作るのはギーク。
  • 設計を始める前にコードを書き始めるのは素人。設計を行ってからコードを書くのは玄人。設計なんて必要なくて、初っ端からコードを書くのはギーク。
  • プログラミング中、頻繁にマウスに手を伸ばすのは素人。殆どマウスに手を伸ばさないのは玄人。全くマウスを使わないので、なんでだろうと思ったら ThinkPad。
  • 普通の携帯電話を持っていたら素人。スマートフォンを持っていたら玄人。スマートフォンでプログラミングしていたらギーク。
  • 一つのディスプレイでプログラミングしてたら素人。マルチディスプレイでプログラミングしていたら玄人。目を瞑り、瞼の裏にコードが表示されたら重症。
  • お気に入りのエディタがないのは素人。お気に入りのエディタを持っているのは玄人。vi と Emacs 以外はカスだと思っていたらギーク。
  • 分からない事をインターネットだけで調べようとするのは素人。本でも調べるのは玄人。何も調べないで、trial & error を繰り返すのはギーク。

• ファイル書き込みをするプログラムで気をつけた方がよいこと | IIJ Engineers Blog
• ブログ: 業界6年目で考えが変わったソフトウェア開発のトピック
  • 様々な経験レベルを持つ人がいるチームで仕事をする場合は、型付き言語の方が適している
  • Javaはそれほどひどい言語ではない
  • ソフトウェア・アーキテクチャは、おそらく他の何よりも重要である。優れた抽象化のクソみたいな実装は、コードベースに正味の害を与えません。悪い抽象化や欠落したレイヤーは、すべてのものを腐らせる
  • 巧みなコードは通常、良いコードではない。明瞭さは、他のすべての懸念事項に勝る
  • 必要ないのにスケーラブルなシステムを設計すると、困ったエンジニアになる
  • DRYは特定の問題を回避するためのものであり、それ自体が最終目的ではない
  • YAGNI、SOLID、DRY。その順番で
  • 鉛筆と紙は最高のプログラミング・ツールであり、あまり使われていない
  • テクノロジーを追加することはめったに正しい判断ではない
  • 「スケーラブル」という言葉は、ソフトウェア・エンジニアの心に神秘的で呆れるほどの力を持っている。その言葉を口にしただけで、彼らを堕落した狂乱に巻き込む可能性があります。この言葉を使った容赦のない行動は正当化される
  • コード網羅率はコード品質とはまったく関係ない
  • モノリスは大抵の状況でかなり優秀
  • TDD(テスト駆動開発)純粋主義者は最悪である。彼らの心の弱さは、様々なワークフローの存在を処理することはできない
• Sebastian AaltonenさんはTwitterを使っています 「A good practice is to copy-paste code three times, and then refactor (extract) if all three instances are still doing the same thing. Before this, you don’t want to add unit tests, because your code has no dependencies. Code without dependencies is the best code. Safe to modify.」 / Twitter
  • コードの共通化は3回同じコード片が登場してから
  • Sebastian Aaltonen氏のプログラミング観 - Qiita
• コードを書く際の指針として見返すサイトまとめ - Qiita
• JavaScriptの非同期処理をキャッシュする場合の注意点 - Qiita … セマフォ
• 型変換用メソッドは受け取り側クラスに作る | まくまくいろいろノート
• 大手Webサービスがクライアント側で発生したJavaScriptのエラーをどう収集しているのか まとめ - Qiita
• 文字列変数の引用符の展開ルール | まくまくSassノート
• 単位を明確にする | まくまくいろいろノート … コメントではなくてシンボル名から単位を読み取れるのが理想
• 肯定形で表現する | まくまくいろいろノート
• 時制や単数形・複数形を考慮して命名する | まくまくいろいろノート
• UT、ITa、ITb、ST、UAT の違い
• わかりやすいシステム構成図の書き方 - Qiita
  • 製品名ではなく役割を書く
  • データと処理を書き分ける : 処理は四角で囲み、DB・テーブル・ファイル・キューなどは図形を描き分ける
  • データの流れと制御の流れを書き分ける : データの流れは「処理」を起点にする、制御の流れは「処理」と「処理」を繋ぐ、それぞれの矢印線は実線と点線などで描き分ける
• API越しでタイムスタンプをやりとりする時のフォーマットをどうするべきか - その手の平は尻もつかめるさ
  • 文字列型で RFC 3339 (ISO 8601) のみ扱えるようにすると、バリデータの作り込みが問題になる
  • Unix Time を使えば UTC であることが担保できる。時間の単位を _sec や _ms といったフィールド名で示せば良い
  • double 型 (小数) のフィールドなら単位は sec (秒) で、細かい精度を小数で示せば良い、と表明できるかも (JS 界隈では浮動小数点の誤差が出るのであまり扱いたくないが…)
• アジャイルとは 〜5つの解釈〜 | Agile Studio
  1. プロダクト開発の手法としてのアジャイル (継続的リリース・「アジャイルソフトウェア開発宣言」に最も忠実な解釈)
  2. プロジェクトマネジメントの手法としてのアジャイル (情報共有による透明性・不完全なコミュニケーションをマネジメントする手法)
  3. 改善活動としてのアジャイル (仕事・課題の可視化)
  4. 組織構造としてのアジャイル (機能別の階層型組織からネットワーク型組織への変化・組織の意思決定スピードの向上・Team of Teams・O&I)
  5. 働き方としてのアジャイル (組織の学習能力・生産性の向上)
• ポートフォリオや個人開発で使えそうなアイデア - Qiita

• No is temporary, Yes is forever.
  • 機能要求を断るのは一時的なことだが、一度 Yes と言ってしまうと開発から保守までのコストをかけることになる
  • なんでもかんでも機能を追加するだけでは価値は出ない、本当に必要な機能を見極め、そこから外れた要求に対しては No と返し続けないといけない
  • No is temporary, Yes is forever - kidooom's Scrapbox
• 品質の観点
  • 機能性
    • 目的性 : 目的に合っている
  • 信頼性
    • 障害許容性 : 障害影響が少ない
    • 回復性 : すぐ復旧できる
  • 使用性
    • 理解性 : 分かりやすい
    • 習得性 : すぐ覚えられる
    • 運用性 : 使いやすい
  • 効率性
    • 時間効率性 : 速い
    • 資源効率性 : 省資源
  • 保守性
    • 解析性 : 中身が分かりやすい
    • 変更性 : 簡単に変更できる
    • 安定性 : 障害が発生しにくい
    • 試験性 : テストしやすい
    • 移植性 : 移植しやすい
    • 設置性 : インストールが容易
    • 置換性 : 他のシステムに置き換えやすい
  • アクセス制御性
  • アクセス監査性
  • 堅固性 : 誤った操作をしてもデータが破壊されない
  • 整合性 : 異常が発生してもデータが破壊されない
  • モジュール性 : 局所的な変更で済む
  • 自己包含性 : 他のモノに依存しない
• 0.1秒 : ユーザは、自分がシステムを「直接」操作していると感じる。
  1秒 : ユーザの思考を止めない限界。反応に時間がかかっていることに気づき、システムの存在を意識する。
  10秒 : ユーザが操作に集中できる限界。待っている間に何らかの形で処理の途中であることを伝えないと、容易に他のことに興味が移る（離脱する）。
  つまり、Webサイトの反応速度（ページの表示速度）は、理想は0.1秒、可能な限り1秒以内に収めるべきで、それ以上ユーザを待たせると離脱が増えるばかり、ということが言えるでしょう
• Excelのサポートを10年間やってきた経験から最も頻出の助言は「データベースファーストの原則」であり、この原則には「1セル1データの原則」「1列1データ型の原則」「セル結合禁止の原則」の3つが含まれる
• 似て非なる文字の扱い方、名寄せについて考慮すべきこと … 入力チェック、自動統一変換をどの程度行うか
  • 似て非なる「ハイフン」文字をどう扱うか
    • 参考 : ハイフンに似ている横棒を全て統一するᅳㅡ˗𐆑–᭸‒-─−▬𐄐—━‐‑ー﹣―ｰ﹘－⁃➖⁻！ - Qiita
  • 似て非なる「スペース」文字の扱い方。プログラミング (実装工程) でも注意が必要
    • 参考 : Unicode のスペースは色々あるし、半角スペースと &nbsp は同じでもない - A Memorandum
• コマンド打つのは誰でもできるんですが、打ったコマンドに責任持って最悪元に戻せるスキルと経験にお金を払うのがIT業界における作業費の意味なんです
• テストでは品質は上がらないですよ。テストはあくまでも品質をあげるきっかけ。品質をあげるのはプログラミングです
• いいですか、タスクの名前は、やる活動の要約ではなくて、タスクが完了した状態の要約にするんですよ。進捗がやばくて、誰かに手伝って欲しいとき、前者だと助けにくいんですよ
• カップ焼きそばを作るには、ただ熱湯を注ぐだけでなく「買ってくる」、「ソースを入れる」など前後に様々な工程があり、パッケージには「熱湯3分」とだけ書いてあっても実際の納品までは10分弱かかる計算なのです。これが、エンジニアが納期を想定の倍以上見積もったほうがいい理由です
• 現在IT業界とよばれるところは80万人の雇用があるが、専門教育を受けたちゃんとした人材だけで仕事すれば8万人で済むとのこと。それぐらい、今のIT業界は専門教育を受けていない人材が含まれている、すなわち、それでちゃんと回るような社内教育システム、開発体制、長時間労働体制が構築されている

ドキュメンテーション

• 「誰でもわかるようなドキュメントを書け」ってのは「ググっても出てこないような暗黙知を無くすようにする」ことであって「未経験者にもわかるように」ってことじゃないんだからね！
• オブジェクト指向でも関数型言語でも同じだけど、抽象化の方法は1つじゃないので、設計者が何を思って何をどう抽象化したのかという点がわからない。ドキュメントはこの点のみ必要だと思う。設計者の意図
• 「ソースコードがドキュメント」は一理あると思ってるけど、経験上ドキュメントが存在しないシステムのソースコードがきれいだった試しがない。人にぐちゃぐちゃなものを読ませて「ソースコードがドキュメント」とか言うのは本当にやめてほしい

マインド

• Negative Capability ネガティブ・ケイパビリティ
  • 積極的な問題解決能力 (Positive Capability ポジティブ・ケイパビリティ) の逆で、分からないこと、不確実なモノを受け入れ、その状況下に留まれる能力のこと。解決を諦めているワケではないが、「答えは一つではない」「すぐに解決するモノではない」ということを認識して余裕を持った姿勢でいることを表す
  • マネージャーとNegative Capability - scrapbox - hotchemi
  • ネガティブ・ケイパビリティ - Wikipedia
• ちゃぶだい返しをされたときのモチベーションコントロール方法について - Qiita
• 不具合修正に対する向き合い方 | まくまくいろいろノート

半分ネタ

• フルスタックになった人間は信頼できる同僚を持てなかった寂しい人間
• Web application はプログラミングスキルがあまり要らないんだよね。誰かが作った API やライブラリ、何とかスクリプト、SWFなどを使えば目に見えるサービスができる。皆がスゲーと言ってくれる。アルゴリズムとか計算量とかそういう、いわゆる正規の計算機工学の勉強はほとんど必要ない。むしろ DB とかの経験やデザインのセンスが重要だ。入口は広いですよ。皆が入ってもまだ余地はある。ところで、ネズミ講でうまくやる秘訣は知ってるよね？(Inemuri nezumi diary 2008-01-03)
• おっさんプログラマのダメなとこはなんか楽にできる方法あるんじゃねえの？って探して力技しかない結論に達しても楽にしたい欲を捨てられずそこで手が止まることです
• 部屋とお姉さんとソースコードはきれいな方がいいと思います
• プログラミングの進展をコードの行数で測るのは、飛行機建造の進展を重量で測るようなものだ - ビル・ゲイツ
• 今日のプログラミングは、馬鹿でも使える、より重大かつ高度なプログラムを構築する努力をしているソフトウェアエンジニアと、より重大かつ高度な馬鹿を生み出そうとする宇宙との間の競争である。今のところ、宇宙が勝っている - Rich Cook
• あなたのコードをメンテナンスすることになる人が、あなたの住所を知る強烈なサイコパスになりうるのを常に想定してコーディングしなさい - Rick Osborne
• 一つの問題に直面するとき、「そうだ。正規表現を使おう。」と考える人たちは、二つの問題に直面する - Jamie Zawinski
• そもそも、デバッギングはコーディングよりも2倍難しい。従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない - ブライアン・カーニハン
• 上品で美しい設計ができる人、たいてい最前線の激務に耐えられないし、そういう理由で社会を支えるシステムはテストや設計が壊滅していたりして脳筋な世界が完成する
• 考えてみると、「クラウドコンピューティング」って言葉は、MSがOfficeにあの雲のオートシェイプを仕込んでたからこそ生まれた言葉じゃねぇの？
• システムエラー出たとき、何種類かのネコのgif画像をエラー内容に合わせて表示するようにしたんだけど、
  問い合わせが基本「猫ちゃんが出てきた」になったし
  猫ちゃん見てるからクレームの温度感も温くなったし
  こっちもとりあえず「画面にどんな猫ちゃん出てますか？」って聞けばいいし楽
• あなたはプロジェクトを下のように行うことができる。
  ・時間通りに
  ・予算内に
  ・適切に
  二つを選べ
• クソコードってまさしく「そういうものを同僚にお出ししていいと思っている」という人格の問題なので、コードレビューは人格否定と不可分なので、戦争の方法を学ぶしかない
• かつて、ソフトウェア科学に「そんな難しいことを現場のプログラマにどうやって教えるんだ？」との言葉が投げつけられていました。すでに答は出ています。「理解した人が現場に入れば良いだけ」

• 関連ブログ記事 : 2018-10-08 「目 grep」が異様に遅いヤツら
• 関連ブログ記事 : 2019-10-05 契約による設計・契約プログラミングが少しワカッタ
• 関連ブログ記事 : 2021-10-19 自分が避けてきたバッドノウハウをあえて使う