エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

【ポエム】今はAIバブル?

みんなAIに期待しすぎ。
みんな詐欺師に騙されてるじゃなかろうかってくらい、AI信仰がある。

NHKの「AIに聞いて見た」を見たが、ありゃAIじゃなくて、機械学習した結果を出してるだけ。
データサイエンティストが理由付けしてないだけなんじゃなかろうかって思った。
そもそも機械学習がどういうものか知っていたから、なんとも思わなかったけど、知らない人が見たら無責任に見えるかもね。。。
これで分かった。
流行のものほど、周辺知識を付けとかないと、いろんなものに騙されるんではなかろうか。
悪意がなくても、騙されることはあるだろう。

いろんな番組を見るが、全部AIにやらせればいいみたいな話を見る。
本当にそう思っているのだろうか?
人間の代わりはできるようになるかも知れないが、それが正しいことなのかを判断するのは、人でなければいけないと思う。
「AIだから」は、理由にならない。
責任ある立場の人ほど、AIに責任を追わせず、自分で判断しないと。

ところで、僕が結婚できないのは何ででしょう?たぶん、AIのせいだ!

Git移行時に経験したSVNの恐怖症

Git使うようになったけど怖いこと

初期のころは、結構思うことがあった

ブランチの削除が怖い

マージが終わって本線に入ったんだけど、なぜか消すのが超怖い。

ブランチの切り替えをしたがらない

SVNやっている頃を考えると、ブランチの切り替えは、死を覚悟するレベルでやっていた。
コミットし忘れを何回かして、死にそうになることが何回かあったから、ブランチの切り替えをかなり慎重にしていた。
今は、ちゃんとスタッシュして退避してやるから、全然気にならなくなったけどね。

スタッシュってなんぞ?

スタッシュの考えが理解できなかった。
変更した内容だけ退避ってことができるわけないと思っていた。
やってることがわかれば、大したことはなかった。
というか、かなり便利。
ブランチの切り替えが超絶楽になる。

リベースの意味が分からない

今でもよくわからない。
だいたい使うのは、スタッシュとマージ、プッシュとコミットくらい。
これだけでも十分使える。

加えて、blameをよく使う。
使う理由は、だれが何の目的でこのコードを入れたのか知るため。
大抵、自分が前に入れたコードだってことを知ることになるだけになっている。
他者に余計な会話をしなくても済むようにはなった。

プッシュ

コミットしたら終わりだろう?
そう考えてる時期がありました。
最近は、コミットとプッシュがワンセットみたいになってるのに、若干の疑問を覚える。。。
あげる必要ない変更は、コミットだけしてプッシュしないような使い方が、段々と意識してできるようになってきた感じ。

覚えるには

とにかくコマンド打つか、使うしかない。
やるんなら、SourceTreeかな。
レビューとかする必要が出てくると、コマンドを本格的に覚えないといけない。
特にgit bleamは必須。

インスパイアされたサイト

SVN脳患者から見たGit - Qiita

Windowsでの効率的なログ解析

きっかけ

Syslogを見ることが多くなって、なんか効率的に検索できる方法ないか考えた結果をまとめる。

ログを見る県境

たぶん、普通のWindows環境じゃ無理。

まずは、MinGW入れる。
やっぱりログ調査となると、LinuxUNIX系の環境がないと辛い。

MinGW使えないときの対応

やるならエディタで正規表現を上手く使ってやるしかない。

該当する文字の検索は簡単なハズ。
問題は、特定文字に該当しない行を抽出する時。

正規表現では、以下の通り。

^(?!.*(XXX|WWW)).+$

上記例では、XXXかWWWを含まない行が抽出される。
大抵の場合は、検索したいワードを指定して、それ以外の行を削除するのが、いつもの使い方。

あとは、ガンバって解析しましょう。

MinGW環境が用意できる場合

使うスキルは、grep、less、正規表現
これらを使えばなんとかなる。

grep

特によく使うのは、下記のコマンド

grep -E 検索正規表現 検索したいテキストファイル

利用できる正規表現

.                    改行文字以外の任意の1文字
*                    直前の1文字の0回以上の繰り返しに一致。直前の文字は正規表現でも構わない
^                    行の先頭
$                    行の末尾
[ ]                  かっこ内の任意の1文字に一致。ハイフン(-)で範囲指定もできる
[^ ]                 かっこ内の任意の1文字に不一致。ハイフン(-)で範囲指定もできる
\+                   直前の文字の1個以上の繰り返しに一致
\?                   直前の文字の0または1文字に一致
\{n\}                直前の文字のn個の繰り返しに一致
\{n,\}               直前の文字のn個以上の繰り返しに一致
\{,m\}               直前の文字のm個以下の繰り返しに一致
\{n,m\}              直前の文字のn個以上,m個以下の繰り返しに一致
pattern1\|pattern2   pattern1またはpattern2のいずれかに一致
\(pattern\)          patternをグループ化する。マッチした内容は\numで参照できる
\                    正規表現に使われる記号を普通の文字として扱う

やってることはエディタでやってるのと一緒。
コレだけだと、やってることはエディタと一緒。
lessと組み合わせることで、ものすごく解析が捗る。
説明はlessで。

あと、ログはタイムスタンプを必ずつける。
時間の価値は偉大。
あるとないとではうんていの差が出る。
整合性確認のためにも、タイムスタンプは必須。

less

コマンドの基本的な使い方は、ITproで。

Linuxコマンド集 - 【 less 】 テキスト・ファイルの内容を閲覧する:ITpro

grepとの連携は、パイプラインで繋げる。

grep -E "XXX" | less

コイツのいいところは、表示後に色々できること。

例えば、表示後に行番号欲しいなぁ~って思ったら、-Nを入力。
一旦どこかに検索結果を保存して置きたいなぁ~って思ったら、-o ファイル名 ※表示中に一度しか使えないので注意
そもそも抽出が検討ちがいだったら、一旦終了してgrep条件考え直す。

less+grepのいいところ

エディタで調査していた頃より、余計な情報でイライラすることが少なくなった。
ある程度、関係しそうな情報を抽出できるので、原因特定がしやすい。
エディタでもできなくはないけど、新規ウィンドウかタブを立ち上げて、全部コピペ→抽出は、正直言って面倒くさい。
やれることは、MinGWない環境でも一緒だけど、手間が増えるってのがネック。

意外とちょっとした面倒なことって、続かないもんだぜ!

参考サイト

エンジニアなら知っておきたい lessコマンドtips 11選 - Qiita

Software Design 2017年8月号 エンジニアのための うけるプレゼン・ すべるプレゼン まとめ

きっかけ

プレゼンはたまにするから、目についたのでまとめる

目次

  • 意識改革編
    なぜエンジニアもプレゼンができたほうが良いのか?
  • 実践入門編
    プレゼンの「練習」をする場を作る
  • 即効技術編
    聴衆を意識してテーマを作る
  • 成功ノウハウ編
    より良い発表の仕方

感想・まとめ

個人の感想とまとめ。
要約なので、あってるかは別問題

意識改革編

プレゼンできた方がいい理由

  • 営業・企画より優位に立てる
  • 人脈が広がる
  • 転職を有利にする(プレゼンの出来が良くないとダメだが。。。)

特に、営業にデカい顔されるのが超ムカつく!
やつらは目の前にぶら下がってる餌にすぐ噛み付くくせに、料理は俺ら任せやからな。

実践入門編

プレゼンは、ハウツー本を読んだだけではダメ。
実践して場数をこなす。

一番厄介なのは、ToLOVEる発生時ですな。
場数をふんで、ToLOVEる対応と自信をつけることが、成功への近道。

リハーサルは入念にしておく。
準備せずに場数だけ踏むのは、愚かな行為。
ダメはダメなりに最善を尽くす。

慣れが一番重要。
尻込みして話してる内容が伝わらないのが、一番の問題になる。

即効技術編

話す場合、まずはテーマを決める。
プレゼン作るのは二の次。
決めないと軸がブレる。

聴衆が誰なのかも理解しておく。
じゃないと聴衆置いてけぼりのプレゼンになり、意味をなさなくなる。

受け狙いは、慎重に。
それが主体になると、だいたいダメになる。

成功ノウハウ編

プロジェクターの確認は必ずする。
プレゼンでは、プロジェクター問題が発生しやすい。

ネットワークの問題もあるので、資料はオフラインでもつかえるようにしておく。

あとは、資料見過ぎも良くない。
声量も大切。大丈夫だと思いがちだが、意外と声が出てないことが多い。
エンジニアは、だいたい草食系だから、営業の肉食系が多いところは萎縮しがちになるので、留意する。
窮鼠猫を噛む気持ちで!

プレゼン時間の超過は大問題。
時間を気にして、切り上げポイントは決めておく。

聴衆にとって意味あるプレゼンにすることが、成功への道。

【書評】プログラマが知るべき97のこと

プログラマが知るべき97のこと

プログラマが知るべき97のこと

目次

  1. 分別のある行動
  2. 関数型プログラミングを学ぶことの重要性
  3. ユーザが何をするかを観察する(あなたはユーザではない)
  4. コーディング規約を自動化する
  5. 美はシンプルさに宿る
  6. リファクタリングの際に注意すべきこと
  7. 共有は慎重に
  8. ボーイスカウト・ルール
  9. 他人よりまず自分を疑う
  10. ツールの選択は慎重に
  11. ドメインの言葉を使ったコード
  12. コードは設計である
  13. コードレイアウトの重要性
  14. コードレビュー
  15. コードの論理的検証
  16. コメントについてのコメント
  17. コードに書けないことのみをコメントにする
  18. 学び続ける姿勢
  19. 誰にとっての「利便性」か
  20. すばやくデプロイ、こまめにデプロイ
  21. 技術的例外とビジネス例外を明確に区別する
  22. 1万時間の訓練
  23. ドメイン特化言語
  24. 変更を恐れない
  25. 見られて恥ずかしいデータは使わないこと
  26. 言語だけでなく文化も学ぶ
  27. 死ぬはずのプログラムを無理に生かしておいてはいけない
  28. 「魔法」に頼りすぎてはいけない
  29. DRY原則
  30. そのコードに触れてはならない!
  31. 状態だけでなく「ふるまい」もカプセル化する
  32. 浮動小数点数は実数ではない
  33. オープンソースプロジェクトで夢を実現する
  34. API設計の黄金律
  35. 超人の神話
  36. ハードワークは報われない
  37. バグレポートの使い方
  38. 余分なコードは決して書かない
  39. 最初が肝心
  40. プロセス間通信とアプリケーションの応答時間の関係
  41. 無駄な警告を排除する
  42. コマンドラインツールを使う
  43. プログラミング言語は複数習得すべき
  44. IDEを知る
  45. 限界を知る
  46. すべきことは常に明確に
  47. 大量のデータはデータベースで
  48. いろいろな言葉を学ぶ
  49. 見積りとは何か
  50. Hello, Worldから始めよう
  51. プロジェクト自身にしゃべらせる
  52. 「その場しのぎ」が長生きしてしまう
  53. 正しい使い方を簡単に、誤った使い方を困難に
  54. 見えないものを見えるように
  55. 並行処理に有効なメッセージパッシング
  56. 未来へのメッセージ
  57. ポリモーフィズムの利用機会を見逃さない
  58. テスト担当者はプログラマの友人
  59. バイナリは常に1つ
  60. 真実を語るはコードのみ
  61. ビルドをおろそかにしない
  62. プリミティブ型よりドメイン固有の型を
  63. ユーザの操作ミスを防止する
  64. プロのプログラマとは?
  65. バージョン管理システムを有効に使う
  66. いったんコンピュータから離れてみる
  67. コードを読む
  68. 「人間」を知る
  69. 車輪の再発明の効用
  70. シングルトンパターンの誘惑に負けない
  71. パフォーマンスへの道は地雷コードで敷き詰められている
  72. シンプルさは捨てることによって得られる
  73. 単一責任原則
  74. 「イエス」から始める
  75. 面倒でも自動化できることは自動化する
  76. コード分析ツールを利用する
  77. 偶然の仕様ではなく本物の仕様のためのテストを書く
  78. テストは夜間と週末に
  79. テストのないソフトウェア開発はあり得ない
  80. 1人より2人
  81. エラーがエラーを相殺してしまう
  82. 他者への思いやりを意識したコーディング
  83. UNIXツールを友にする
  84. 正しいアルゴリズムとデータ構造を選ぶ
  85. 冗長なログは眠りを妨げる
  86. WETなシステムはボトルネックが見つかりにくい
  87. プログラマとテスターが協力してできること
  88. コードは生涯サポートするつもりで書く
  89. 関数の「サイズ」を小さくする
  90. コードを見る人のためにテストを書く
  91. 良いプログラマになるには
  92. 顧客の言葉はそのまま受け取らない
  93. エラーを無視するな
  94. リンカは魔法のプログラムではない
  95. ペアプログラミングと「フロー」
  96. テストは正確に、具体的に
  97. ステートに注目する
  98. 命を吹き込む魔法
  99. ロールプレイングゲーム
  100. ルーチンワークをフローのきっかけに
  101. プログラマが持つべき3つのスキル
  102. 快適な環境を追求する
  103. 見知らぬ人ともうまくやるには
  104. 不具合にテストを書いて立ち向かう
  105. 育ちのよいコード
  106. Noといえることの大事さ
  107. 名前重要

感想

まとめと感想。個人の主観が入ってるので、注意。

分別のある行動

技術的負債は、先送りしていると負債は大きくなる。
返済計画を立てないと、返済しきれなくなって破産する。

付け加えるなら、資産も持つべきかな?
作ったコードは、たぶん負債だらけってわけじゃないと思うんだよね。
よく作られているコードは、資産と捉えて、増やす・維持する努力もやるべきだと思う。

関数型プログラミングを学ぶことの重要性

関数型プログラミングオブジェクト指向は、相反する存在ではない。
注力しているものが違うだけ。

実際にやっていると分かるが、どうしても状態を持たなければいけないところが発生する。
使い分けができるようになっておく必要がある。
前までは、オブジェクト指向素晴らしいと言ってきて、今度は、関数型プログラミングが素晴らしいって世の流れは、かなり違和感を覚える。
結局は、使いどころを見抜く力が必要なのだよ。

ユーザが何をするかを観察する(あなたはユーザではない)

考え方や味方は、ユーザと開発者では違う。
同じだと思ってはいけない。
解決するには、観察するしかない。

コーディング規約を自動化する

規約が存在することで、コードの私物化を防止できる。
なるべく強制的・自動的に守らせる。
規約を作っても、忠実に守ってくれるとは限らない。

規約は、プロジェクトと一心同体。
プロジェクトで求められるものが変われば、規約も変わる。
見直すタイミングを考える必要がある。

だいたい規約作って終了の現場は多い。
維持するために覚えるのは、ものすごく辛い。
自社サービス作るのに100%自社社員ならいいが、協力会社が入っているなら、規約のチェックは自動化しないとやってらんない。

美はシンプルさに宿る

シンプルなコードは、責務を最小化し、関連をすくなくし、テストしやすく、長期保守ができるようになる。

リファクタリングの際に注意すべきこと

リファクタリングは、必要なときに必ずする。

むやみやたらにやっても、確認で破綻する。
ご利用は計画的に!

リファクタする際の注意点

  • 既存コードの良い点・悪い点を見定めてから実姉
  • ゼロから作り直したい衝動を抑える
  • 大幅な変更より、小さな変更をたくさんする
  • デグレ確認必須
  • エゴを入れない
  • 新技術を使いたい衝動を抑える
  • 人間はミスすることを忘れない

共有は慎重に

共有=再利用
再利用させたい場合、目的や役割を考えてライブラリ化する。

共有したら情報漏えいのリスクも上がるしな!

ボーイスカウト・ルール

来たときよりも美しくする。
少しづつ改善する努力が、ソフトウェア開発には必要。
ただし、不要な修正は禁止しなければならない。

他人よりまず自分を疑う

コンパイラ・OSは、いろんな人がチェックしているので、バグは少ない。
他者に原因がある前提で動くより、自分が作ったものにバグがある前提で探した方が、効率的。

これは、あるあるネタ
だいたい他人を疑う前に、自分に否がないように論理武装してから挑まないとダメ!
自分に否がないと分かったら、他者を徹底的に痛めつけられない!
俺って結構クズ人間?

ツールの選択は慎重に

ツールに依存する=ベンダロックイン状態になる。
ツールは必要最低限にしておき、分離可能なように設計する。

たまに、ツールのために設計している現場があるからな。。。
そう言った現場は、だいたい汎用性がなくて、顧客要求に対応できず、協力会社の教育にも時間がかかり、炎上する。

ドメインの言葉を使ったコード

データ構造は、時間の経過とともに複雑化していく。
ビジネスに合わせてコードを書かないと、変化したコードの内容は、すぐに分からなくなる。
ドメインとともに、コードも成長させる。

たまにあるのが、データ構造が永久に変更無いと思っているやつ。
そういうやつに限って、自動生成がどうこう言い出して、ドメインが成長してもコードが成長しないような環境を作り出す。
なんか、愚痴ばっかだな、俺。

コードは設計である

建築コストのゼロ化→早く設計したもの勝ちになる。
早く設計したはいいが、その妥当性は、素人に判断できない。
最終的な品質は、低下する。

ソフトウェア開発にも同じことが起きる。
優れた設計には、人間が必要。
その妥当性の確認作業は、人間にしかできない。

この考えはAIにも当てはまる気がする。
AIでなんでもできるようになったって、それが妥当かどうかは、素人には分からない。
やっぱり、専門家が必要なんだと思う。
これからは、企業が優秀なエンジニアを持ってないと、AI時代が来たときに、出遅れる気がしないでもない。
作戦立案はAIにまかせて、その妥当性を吟味して意思決定するのが人間になりそう。
やっぱり、仕事へらないじゃん!
AIだからこそ、最終的な意思決定が重要になりそうだ。

コードレイアウトの重要性

コーディング<リーディング
リーディングを効率化しないと、時間がかかる。
既存コードを読んで、発想を真似るのはよくあるからね。(コピペはダメ!絶対!)
リーディングを効率化するためにも、見ただけで何をしているか分かる状態にしておく。

コードレビュー

コードレビューは、質を上げ、欠陥を減らす。
チーム知識の共有と規約の確率も含まれている。
やる際は、建設的であるべき。
辛辣な批判は避ける。
そうしないと、レビューがボトルネックになり、プロセスが瓦解することがある。

続けるには、レビューを楽しくする事が大事。

知的な話術で場を和ませるスキルが必要なのだ。
そのためにも、漫画やアニメ、映画に小説をよんで、面白い語録を身につけることは、仕事に役立つ気がしてきた。

コードの論理的検証

コードが正しいことを証明する=事前条件・事後条件・不変条件を決めること。
ただし、難しい。

注意点

  • gotoは避ける。
  • 変更可能な変数は避け、スコープは狭くする。
  • インデントを使って読みやすくする。
  • 名前で機能が分かるようにする
  • パラメータは減らす
  • インタフェースの適用箇所は減らす。

コメントについてのコメント

コメントとは、有用なもの。
どういう目的で書いたのかを残す。
多く入れるのは、かえって分かりづらくする。

1行1コメントが許されるのは、教育目的まで。
たまに書かなすぎなやつもいる。
コードは万能ではないことを理解しておくことも必要。

コードに書けないことのみをコメントにする

書かなくても良いものを見極めることが重要。
コードに付加価値を加えないコメントは、ノイズでしかない。
書いてしまうのは、構造や宣言方法に欠陥がある。
なるべくコードに語らせて、コードに書けないことをコメント化する。

学び続ける姿勢

どこでも必要。
会社は当てにしないほうがいい。
自らの力で実施することが大切。

誰にとっての「利便性」か

作る側の利便性<使う側の利便性
APIを作る時は、使うほうが自由にできることを増やす。

開発者の利便性は糞。
最終的に使われないと意味がない。

すばやくデプロイ、こまめにデプロイ

デプロイ作業後に顧客が利用するので、デプロイがスムーズにいかないのは、不信感を持たれる。
なるべく早く使えるようにして、不確定要素を減らす。

精神衛生的にもいい!

技術的例外とビジネス例外を明確に区別する

区別しないと、問題の切り分けが難しくなる。
なるべく切り分けできるように設計して、障害対応の初動を早くする。

たまに、例外がビジネス的な例外なのか分からない時がある。
例外禁止している現場は、だいたいビジネス例外とシステム例外を見分けられていない。

1万時間の訓練

1万時間経過したら、急にエキスパートになれるわけではない。
やっていく中で、徐々に専門知識がつく。
だけど訓練は、厳しくする必要がある。
楽なものでは意味ない。

温室育ちの花が、アスファルトで生きているハズがない。
才能あれど、常に厳しい環境に身を押して無いと、生存競争に勝てない。
続けることも大切だが、それと同じくらいに、厳しい環境に身を置いて、厳しい訓練をすることも大事。
だから、山ごもりって文化があるのだろう?

ドメイン特化言語

どの分野にも専門用語はある。
一度作れば、技術的な詳細はブラックボックス化し、一般の人にも使えるようになる。

警察とかは、ドメイン用語の宝庫。
デカとか、普通伝わらんやろ。

変更を恐れない

変更を恐れるのは、病気。
システムの健康を保つためにも、変更を恐れずに日々リファクタリングすることは、必須。
健康と同じ。

見られて恥ずかしいデータは使わないこと

恥ずかしいデータの露呈は、いつ発生するか分からない。
常に公になったときのことを考えて作業する。

プリキュア名をテストデータにしたら、いつかバレるから、慎重に!
これは、俺のことじゃないからね!

言語だけでなく文化も学ぶ

複数の言語を学ぶことは、新しい発想を得たり、デザインパターンの理解が深まる。
同じ問題に対して、違った解決方法を身につけることが大事。

多様性は大事!
自分が偏ってると思ったら、反対の言語を学んで見る。

死ぬはずのプログラムを無理に生かしておいてはいけない

例外を無理矢理処理するのは、後で首を締める。
適切な場所で、適切な処理をする。

例外をそもそも導入しないのは、糞野郎。

「魔法」に頼りすぎてはいけない

プログラミングしただけで、プログラミングは語れない。
素人に見えないだけで、データ構造・概念化など、重要な部分が隠れている。
関与してない箇所は、簡単に見えてしまう。
どんなことであれ、仕事している人は尊重する。
問題が起こると、簡単に見えていたことが、実はそうでなかったと気付く。
対応する必要があるので、簡単になったからと言って、対策を怠ってはいけない。

経営、カールと一緒。
なくなってから欲しても、もう手に入らないからね!

DRY原則

重複は無駄である。
作業の重複は、自動化で防ぐ。
ロジックの重複は、抽象化で防ぐ。

そのコードに触れてはならない!

システムを治すからといって、本番に直接修正してはいけない。
決められたプロセスを、権限を持った人がやらないと事故るだけ。

決められたプロセスを無視して実行すると、プロセス通りにやっていれば問題なかった問題を踏み抜いて、余計に時間がかかることが多い。
プロセスの見直しは定期的にするべきだが、急いでいるときほど、いつもやっている手順を重視する。

状態だけでなく「ふるまい」もカプセル化する

振る舞いがカプセル化できてないと、呼び出し元でif-elseが多くなる。
カプセル化することで、保守性が格段に上がる。

浮動小数点数は実数ではない

精度には限度がある。
金融で使うべきではない。

オープンソースプロジェクトで夢を実現する

OSSの参加

  • 希望するものが作れる
  • 個人の時間を削る必要がある
  • 他人の問題解決手法を学べる

貢献方法

  • ドキュメントを書く
  • テストコードを書く
  • コーディング

API設計の黄金律

APIは、公開したら修正するのは難しい。
APIを作る時は、利用する側のテストコードも書く。
テストの難しさを設計課題として捉える。

超人の神話

超人はいない。
ただ、問題解決能力が高いだけ。
超人神話を作るより、エキスパートを育てることに注力する。

超人作るのはいいけど、その人が居なくなるリスクがでかくなるから、企業は超人を作らないほうがいい。
均一なスキル保持者を量産すべき。

ハードワークは報われない

仕事は、短い時間で終わらせる。
長時間労働は、プロ意識の欠如。
効率化と日々の反省を忘れない。

バグレポートの使い方

バグレポートには、感情を入れない。
情報の入れ過ぎは、重複が増えてわかりづらくなる。
情報を増やしたい場合、入力欄を増やすことで対応できないか、一考する。

余分なコードは決して書かない

ない方がいいが、作ってしまう。
作る際に、本当に必要なのかよく考える。

最初が肝心

最初の導入で躓く=もう使われないと思ったほうが良い。

意外と人間って、成功体験がないとすぐ諦めるんだぜ!

プロセス間通信とアプリケーションの応答時間の関係

応答が遅い場合、データ構造・アルゴリズムよりも、プロセス間の通信量に注目する。

無駄な警告を排除する

無意味な警告は、邪魔なだけでなく、必要な警告を隠す。

syslog見てみろ!
いらねぇログばっか出していると、障害解析が辛いんだよ!クソが!

コマンドラインツールを使う

IDEは、裏で何かをしている。
その何かをしることで、もっと効率的にできる。

プログラミング言語は複数習得すべき

1つしか習得してないと、問題の解法が限られる。
未知の問題に対応できないリスクがある。

IDEを知る

簡単に使えるけど、上達はしない。

限界を知る

リソースには限界がある。
どこが限界なのかをしることで、最適なやり方を知ることができる。

限界を決めるなとかいうやつがいるけど、許容限界を決めて、限界に達したら他の効率的なやり方を探したほうが、有意義だと思いますけどね。
経営もそうしているはずだろう?

すべきことは常に明確に

目標がないと、時間を浪費しがち。
やることに期限をきめるだけでも、効率的になる。

大量のデータはデータベースで

RDBMSで管理することで、大きなメリット享受できる。

いろいろな言葉を学ぶ

人との会話は大事。
チームで働くので、職人仕事より、人と協力して作業する。

見積りとは何か

見積もりとは、何かの価値・量・程度についての概算。
ある程度以上の精度は期待できない。

見積もり・目標・約束の認識が違うと炎上しやすい。

Hello, Worldから始めよう

物事をシンプルに考える。

ごめん、、、これ以上のことは読み取れなかったよ、パトラッシュ。。。

プロジェクト自身にしゃべらせる

CIを適用して、プロジェクトを自動監視する。

プロジェクトの状況を教えてくれるAIがあるといいかも。
個人的には、有名声優の声で、異常を教えてもらいたい!

「その場しのぎ」が長生きしてしまう

暫定対応は、意図せず発生してしまうが、放置しておくと後で修正が難しくなる。
修正するには、修正を暫定に加えず、新規で正当なものを作る。

正しい使い方を簡単に、誤った使い方を困難に

使いやすいインタフェースは、正しい使い方が自然とできる。
開発者の利便でUIを決めないようにする。

見えないものを見えるように

目に見えるものについては考えるが、見えないものは放置しがち。
ソフトウェア開発は、常に目に見える証拠を維持してないと、状況は把握できない。

並行処理に有効なメッセージパッシング

問題は、だいたい共有メモリ
解決するには、メッセージ交換でできないか検討してみる。

未来へのメッセージ

コードは時間が立つとわかりにくくなる。
未来の自分へのメッセージだと思ってコードを書く。

分かるぜ。3時間前の自分が回たコードを、自分で貶していると知った時の衝撃は、計り知れなかった。。。

ポリモーフィズムの利用機会を見逃さない

if-elseはバグの混入率が高い。
ポリモフィズムが適用できないか検討する。

テスト担当者はプログラマの友人

QA・QCからの指摘は、恥だと思ってはいけない。
顧客の目に触れる前に見つかったことを喜ぶべき。

顧客の目に触れてからだと、仕事もらえなくなるからな!

バイナリは常に1つ

コナン君に影響されたのか?
環境も含めてバージョン管理するようにしないと、ビルドに振り回される。

真実を語るはコードのみ

コメントを書かないとわかりにくいコードは、コードを改めるべき。
実行されるのは、コードであってコメントではない。
わかりやすくするために、なるべく依存関係は減らす。

ビルドをおろそかにしない

理解が深まれば、ビルド労力・時間の減少になる。

プリミティブ型よりドメイン固有の型を

強い型付けは、問題の発声を防げることが多い。
ビジネスロジック固有のデータ構造を定義すれば、問題の防止が容易になる。

ユーザの操作ミスを防止する

ミスする側が悪いで話を終わらせるのは簡単。
ミスがでるのは、ユーザとソフトウェアの間に誤解が生じている。
ユーザがどう考えて解釈しているか、知ることが大切。

プロのプログラマとは?

やったことへの責任感の強さ。
最善の努力を尽くす姿勢を持つ。

キャリアに責任を持つ

自分の価値は自分で高める

コードに責任を持つ

バグの原因を特定するまで安易な対応はしない。

チームプレイヤーであることの自覚

チーム全体のアウトプットに責任を持つ。
チームのミスはカバーする。

バージョン管理システムを有効に使う

プロジェクトの構成要素は、すべてバージョン管理すべき。
バージョン管理することで、意図しない自己を防げる。

いったんコンピュータから離れてみる

論理的に考えて行き詰まるのは、視点を変える必要がある。
一旦休憩を入れてみる。

コードを読む

コードを書くよりも、リーディングの方が力がつく。
読む場合、何が読みやすいのか考えながら読む。

「人間」を知る

ユーザに分類された要件を求めるのは、無理がある。
理解した上で接しないと、苦労する。

車輪の再発明の効用

車輪の再発明はコストがかかる。
しかし、知識をつけるには、価値がある。

シングルトンパターンの誘惑に負けない

シングルトンの問題

  • 暗黙的依存ができる
  • 永続化される
  • インスタンス削除のタイミングがない

シングルトンを使う際は、上記問題を考慮する必要がある。

パフォーマンスへの道は地雷コードで敷き詰められている

パフォーマンスは、複雑度と依存性の戦い。
事前にメトリクスを計測しておく必要がある。

シンプルさは捨てることによって得られる

リビジョンが上がっても、よくなることは少ない。
既存のコードの質が一定以下なら、捨てる覚悟を持つ。
捨ててシンプル化することを考える。

単一責任原則

同一の変更理由によって変わるものは、一箇所に集める。

「イエス」から始める

顧客要望は、肯定的な立場から受け止める。
そして、理由を追求する。
理由が明確になることで、ストーリーが生まれ、人を動かしやすくなる。

面倒でも自動化できることは自動化する

自動化できるものは、できるだけ自動化する。

コード分析ツールを利用する

品質向上は、テストだけではない。
コード解析を使って、テストで見つけにくいものを発見する。

偶然の仕様ではなく本物の仕様のためのテストを書く

細部に至るまでの厳密なテストは、テストコードと強結合になる。
細部に至るテストは、実装上そうなっただけで、偶然の私用に過ぎないものをテストしている可能性が高い。
やるなら、ブラックボックステストで、本来の要求をテストする。

テストは夜間と週末に

テストは、夜間と週末に実施して、リソースを効率的に使う。

テストのないソフトウェア開発はあり得ない

建築と違って、作った後にテストできる。
テストは、ソフトウェア開発固有の作業で、重要度が高い。
開発者は、責任を持ってテストを行う。

1人より2人

システム開発は、一人ではできない。
ペアプログラミングで得られる効果は大きい。
確信が持てないなら、実施してみる。

エラーがエラーを相殺してしまう

問題が相互作用で発生することがある。
問題が発生したら、曇りなき眼で、思い込みを捨てて、冷静に対応する。

他者への思いやりを意識したコーディング

ただ質の高いコードを書くだけではダメ。
他人へ影響を与えるコードを書く。

UNIXツールを友にする

拡張性が高く、効率的に使える。

正しいアルゴリズムとデータ構造を選ぶ

適切なアルゴリズムを選ぶことは、適切なデータ構造を選ぶこともセットでついてくる。
アルゴリズムを使えるシーンについて、理解を深めておかないと、失敗することがある。

冗長なログは眠りを妨げる

ログに不要なものがあると、問題が発生しているかも分からない。
必要最低限のものだけ出す。

WETなシステムはボトルネックが見つかりにくい

DRY原則に反しているもの=WETシステム
保守性だけでなく、ボトルネックの発見も困難化するので、DRY原則は守る。

プログラマとテスターが協力してできること

設計が悪いと、テスト項目が多くなり、テスターの負荷が増える。
設計を改善するためにも、テスト項目を理解しておく必要がある。
テスターとプログラマーのチームワークを良くすることが、成功の鍵。

コードは生涯サポートするつもりで書く

コードを適当に書いてはいけない。
生涯サポートするくらいの気持ちで真剣に書く。

関数の「サイズ」を小さくする

問題領域はなるべく狭くする。
扱いやすくなるだけではなく、障害調査もしやすい。

コードを見る人のためにテストを書く

テストコードをただ書いているだけではダメ。
テスト対象を補完するようなテストコードを書く。

良いプログラマになるには

一朝一夕ではなれない。
努力を続けた人だけがなれる。
善意だけではなれない。
善意が役立っているか、確認して今後に活かす。

顧客の言葉はそのまま受け取らない

言っていることが正しいとは限らない。
意図を読み取ることが大切。

エラーを無視するな

エラーを放置しない。
放置すると、コードベースが不安定になり、バグを生みやすくなる。

リンカは魔法のプログラムではない

難しいことはしてないが、簡単なことが積み重なると、難問ができあがる。

ペアプログラミングと「フロー」

相手の方が格上:気後れせずに接する。
相手の方が格下:忍耐強く接する。
ペアプログラミングのメリットは、早期問題の抽出と新人育成。

テストは正確に、具体的に

テストは正確に書くだけでは不十分。
わかりやすくテストの目的が分かるようにする。

ステートに注目する

状態が処理に与える影響は大きい。
だから、状態には注目しておく。

命を吹き込む魔法

コードネームをつけると、当事者意識がまして、震源に取り組むようになる。

ロールプレイングゲーム

理想のプログラマを演じる。
仕事と割り切れば、できること。

ルーチンワークをフローのきっかけに

ルーチンワークは、無駄になっていることがある。
自動化して、他のことに集中する。

プログラマが持つべき3つのスキル

スキルをあげるには、OSS開発か、師となるべきエンジニアを見つけるしかない。

快適な環境を追求する

環境を改善することで得られる時間は、投資した時間より多くの物が返ってくる。
コーディングで食っていくなら、環境改善は必須。

見知らぬ人ともうまくやるには

できないことは、できないまま。
できることは、できるようにしておく。
無駄な論争をせずに済む。

例えばユーザ情報の更新。
QAテストで使うユーザのIDとパスワードを全員知っているせいで、意図せず変えてしまってテストで混乱するのは、避けないといけない。
あと、環境もね。知らない人から、ディスられるから、やれないことはやれないようにして置くのは、超絶大事!
俺がディスられたわけじゃないいだからね!

不具合にテストを書いて立ち向かう

不具合修正は、不具合再現コードを書いてから行う。
遠回りのようだが、一番合理的。

育ちのよいコード

成長するに連れて、まとまりの悪さがでる。
リファクタリングと機能追加のパッチを使い分けるようにして、まとまりの悪さを回避する。

Noといえることの大事さ

ソフトウェアの公開は、機能追加要望が増える。
そうすると、いらない機能が増えて使いにくくなってしまう。
だから、Noと言えることが大切

名前重要

設計の基本は、ネーミング。
ネーミングにはこだわる。

読了感想

本当はもっと早く読むつもりだったけど、結構先延ばしになっていた。
読書スピードが落ちているってのもあるかも知れない。

Visual Studio CodeのターミナルをGit-bashに変更する方法

きっかけ

powershellとか、cmdだと、業務で覚えたLinuxの知識が活かせない。
別ウィンドウでgit-bash起動すればとも思うが、使うツールは少ないほうがいい。
職場で設定したが、やり方忘れやすいので、メモ。

設定方法

ファイル -> 基本設定 -> 設定から、setting.jsonを開く。
もしくは、Ctrl+Commaでショートカットで起動してもいい。

起動したら、terminal.integrated.shell.windowsの内容を変更する。

Git-bashを設定したい場合、Git\\bin\\bash.exeを指定する。
※指定するのはフルパス。

ここで注意したいのは、bin配下のbash.exeを指定すること。

git-bash.exeだと、VisualStudioCodeとは別ウィンドウで、git-bashのターミナルが起動するので、注意!
予期した動きと変わるので、かなり困惑した。

参考サイト

qiita.com

Typescriptと依存関係

起きた事象

クラスが相互参照になって、実行時にエラーになった。
エラーの内容が、相互参照によるエラーだとわかりにくくて、結構悩んだ。
※俺が起こしたわけではない。むしろ巻き込まれたほう。

どうやって

どうやって検出すればいいんだ。。。
型付け言語なのに、相互参照が解決できないのは痛いな。

クラスが増えれば、発生する可能性は高いし、検知する方法を持っておかないとキツイ。
どうにかして回避したいが、なんかいい方法ないのかな?

いや、まぁクラス設計ちゃんとすれば済むんだろうけど、正直難しいだろ。。。