エンターテイメント!!

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

【書評】知的戦闘力を高める独学の技法

知的戦闘力を高める 独学の技法

知的戦闘力を高める 独学の技法

読書開始日

2018/01/29

きっかけ

大量に山積みされているのと、普段は独学ばかりやっているので、興味をそそられたから

まとめノート

太字は、感じた感想

知的戦闘力をどうあげるか?

独学のメカニズム

  1. 戦略
  2. インプット
  3. 抽象化・構造化
  4. ストック

大別すると、戦略を決めて、それを実行する方法が何かを書いてるわけね

高める知識を決め、情報収集する。集まってきた情報から自分なりの考えを導き出し、それを整理・保存することが独学で大切である。
独学は知識の詰め込みではない。

武器を集めるつもりで学ぶ

どこで戦うのかを明確にして、必要な武器/必要な息吹を見極める。

水中ならビーム兵器より実弾がいいってこと

現在は、情報量が多いので、いらない情報を捨てて、いる情報をあつめる情報密度を高めることが必要になる。
一番大事なのは、多くの人が知ってない情報。
人との違いを明確化して、差別化することが強さになる。

差別化するのはいいけど、見当違いなことを重視することではない。
理にかなっていて、かつ、的を得ている必要がある。

「戦略」は粗い方向性だけでいい

知識は、偶然の連鎖で広がる場合がある。決め付けすぎは、大きな発見に繋がらないことがある。

茂木健一郎の名が出てくると、すごく胡散臭く感じるのは、僕だけですかね?
あぁ、決めつけは良くないね(笑

広範囲のソースから自分の五感で行う知的生産

情報収集で大切なのは、複数のメディアを使って集めることだ大切。
誰も持たない情報を得ることが一番重要。
それを達成するためには、自分の五感を使い、体験する。
なぜなら、五感は自分しかもたないので、貴重な情報になる。

バカの壁」と似たような考えだな。結局は、自分がどれだけ真摯に考えていて、自らを追体験させることをしないと、学びは得られないというわけね

洞察につなが「問い」と「組み合わせ」

情報をそのまま貯めると、オーバーフローする。
情報をコンパクトにするには、情報密度を濃くする必要がある。
そのためには、仮設を立てて検証し、知識として有効になってからストックする。

オーバーフローするとメタルクウラみたいになってしまうからな。先を見据えて情報を知識に昇格せなアカン。

戦う武器をどう集めるか

独学とは、何を学ばないか決めること。
思いつきで時間を浪費することは、戦力の逐次分散投入と同じ。

日本企業を見れば分かる。集中投資をしなかったために、足元をすくわれてる事が多い。特に特許分野は。

知識の一点特化は、難しい。 ゲームじゃないしね。。。
持っているものを組み合わせて、特異性を出して、特定領域で優位になることが大切。

生産性の高いインプットの技法

読書の目的

  • 仕事に必要な知識を得る
  • 専門領域を深める
  • 強要を深める
  • 娯楽

長期目線の教養の読書は、失敗の可能性が大きい。
なぜなら、キャリアの予測が難しいので、役に絶たない可能性がある。
刹那的な選考の方がいい。

本書だと、あとで役立つ知識もあると書いてあるけど、結局、読書はどういう考えでいるん?

共感できるインプット

共感できるインプットは、バカになる。
なぜなら、知識が極端になり、独善的になり、同質化を起こす。

激しく同意。自己啓発がその最たるもの。
サンモニのコメンテーターたちが、なぜああなったのか分かった気がした。
おそらく、朝日新聞だけで育ったのだろうな。。。

意見の対立がなければ、高いクオリティの意思決定はできない。
対立と批判は、混同して、「差別ガー」と言っていると、大局を見据えた意思決定はできない。

知的水準が高くても、同じ人が集まれば、意思決定の質は低くなる。
頭のいいやつが集まるとバカになる原則とも言う
他人の意見を認める広い心が必要なのだ。

肯定と否定は、強い次元では同じもの。
真の意味での反対は、無関心と同じ。
ツンデレが恋愛として成立すると、フロイトは見抜いていたんだな!!
無関心が一番マズいということは、既に神のみぞ知るセカイで学んだぜ! 重要なことは、意外と漫画から学んだのかもしれない。ただ、書いている人が優秀な知識人である必要があるけど。

自分を知るには、好きなものより嫌いなものを分析する方が簡単。
怒りを感じるのは、大切なものを否定されているから。それが大事なものであることを理解する。
ネガティブな感情は大事。そこから、知ることもできる。「何が嫌いかより~」は、自己分析する上では間違いである。

独学するのはいいことだが、収集した情報がゴミだと、出力する情報もゴミになる。
うんこで作った料理は、結局、うんこでしかない。

ゴミの選別をする必要がある。
ただ、それは難しいので、なるべく名著や古典を読んだほうがいい。
なぜなら、評価が確立しており、ハズレ(ゴミ)を引く可能性が低いから。
読む時は、深く鋭く読む。 つまり、考えながら読みなさいってことですかね?
多読は、読むに値するか見極められる人がするべきこと。
そこに至ってないのにすることは、時間の浪費に近い。
内容をよく吟味せず、周囲に吹聴するのは意識高い系のお仕事。お仕事をとってはいけない。

仕事ができないから、コンプレックスを埋めるための読書はナンセンス。
結果としてできあがるのは、偏屈で扱いにくく、知っていることをひけらかして悦に浸る人になる。
某県の米○知事とか、小西○之議員とかみたいなやつを見れば、分かる気がする。

読書で得なければいけないのは、知ることではなく、人生を豊かにすること。

情報

情報には種類がある。

  • インフォメーション:情報
  • インテリジェンス:洞察や意思決定のできる情報

エンタメ系は、インフォメーションが主。生活に影響はない。
今後、重要になってくるのは、インテリジェンス。

人とは、もっとも優れた情報を提供してくる。
フィルタリングや文脈理解が高度で、重要な情報を効率的に教えてもらえる。
人と会って話を聞くことは、特異な情報を得る近道になる。

効率的な学びは、問を持つことが必須。
問を持つことで、思考が生まれ、高度な情報を導き出せる。
問を溜める習慣を付ける。
意識してやらないと、白昼夢のようにすぐ消える。

知識を使える武器に変える

情報を知識にするには、情報を汎化して使いやすい状態にする必要がある。
特殊な状況下でしか使えない武器は、対して役に立たない。

抽象化が下手な人は、専門バカである可能性が高い。
一定の局面にしか使えないため、本当の知性は得られていない。

知識をストックする際に考慮するポイント

  • 得られたもの
  • 特徴
  • 応用方法

創造性を高める知的生産システム

ストックした情報を活用するには、記憶に頼らないストックが必要。
キーワード、コンセプトだけ覚えて、詳細は外部記憶に保存して検索可にする。

知的ストックのメリット

  1. 現実問題を考える助けになる
  2. 常識を崩せる
  3. 創造力が上がる

創造は、組み合わせを変えることで生まれる。
つまり、四十八手は、増える可能性があるという認識でよろしいのでしょうか?

読書から知恵を得る方法

主張したいことを見極め、それが真実か検証し、重要だったらストックする。
結局のところ、考えることが重要である

なぜ教養が「知の武器」になるのか?

世の中は変わりやすいため、適応するための土台が必要だから。

歴史

学ぶことで、起こすべき行動の指針が得られる。
既に行動を起こして、結果が出ているのだから、そこから学べる

歴史を学ぶということは、表面的な事実だけではなく、内部のメカニズムを考えることが重要。
そこから得たものが、現実にいきてくる。
また、そこから得ることで、未来予測できる力が上がる。

経済学

市場のルールや価値の本質を見抜けるようになる。
その結果、市場を有利にして、利益を得ることができる。

哲学

疑い方を学び、否定と肯定を使い分ける力が身につく

考えると悩むことは違うことに注意

心理学

人間は合理的ではない。不条理を追求することが心理学。
経済学とは対極にいる存在だな。。。

音楽

全体を直感的に把握する力が身につく?
モーツアルトとベートーベンの話が面白かった モーツアルトは、トイレに入っている最中に楽曲ができた。
つまり、ウンコと一緒にメロディが出てきたわけか それに対して、ベートーベンは嫉妬に似た感情を覚えたわけね。

脳科学

人間が起こすエラーパターンを学ぶことが目的。
心理学に近い

文学

理解力の向上、人間性を高められる。
仮想体験することで、人生観の追体験ができる。その結果、人間性が上がる。

表現力の強化。つまり、比喩表現の強化。
悪用すれば、人身を惑わせる。対策のためにも知る必要がある。
この能力が高いのが、小池百合子な気がする。

宗教

思考・行動様式を理解できる。
人は不条理だが、宗教によって傾向が分かれる。
心理学に近い 日本人は、宗教もてるよね?だって、どういう行動を取りやすいのか、分析できるってことは、つまるところ、宗教をもっているのだろう
ただ、キリスト教ヒンドゥー教みたいに、名詞がついてないだけな気がする

感想

読み進めていると、矛盾しているところがある。
だが、大筋で学ぶ方法については同意。
結局のところ、考えて自分のものにすることが大切。

古典については、考えを改めないといけない。
新しいものばかりに飛びつくのは、土台がしっかりしてないとダメだな。
弱いところは補強しないと。

【書評】ダークサイド・スキル

ダークサイド・スキル 本当に戦えるリーダーになる7つの裏技

ダークサイド・スキル 本当に戦えるリーダーになる7つの裏技

きっかけ

ダークサイドって言われると、魅力を感じる世代なのです。
ダークって単語を聞くと、ハートキャッチプリキュアのクモジャキーを思い出す。
もう、ダークって聞くと、その後の単語は、「な心に支配されるぜよ!」って脳内再生される。

まとめノート

7つのダークサイド・スキル

太字は、俺の考え。

U字型コミュニケーション

コミュニケーションって単語が気に入らんぜよ!

日本は、会議では互いの愚痴は言わないけど、会議の後に言う傾向が強い。
そして、それは部下に広まり、風の噂で流れて、ボトムアップで相手に伝わる。
こうした風土がある結果、相互不可侵な組織が形成される。

組織の中で重要なのは、中間管理職。
トップがすべて見切れるわけではないので、中間管理職の情報を信じるしかなく、組織を操作しようと思えばできてしまう。
トップよりも長く会社にいる可能性が高いので、先を見据えておく必要がある。

弱音を吐くこと≠実情を伝えること
勝ち抜くためには、冷静な判断とタイミングを知る。

上司への報告に必要なものは、調査・段取り・根回し。
実施するタイミングに気をつける。言い訳に聞こえるタイミングでの利用は、最悪の状態を招く。

評価は、成果をあげることだけではない。
失態を抑えることも評価するべき。
失敗から学んでいる人の方が、強く育ち、リスク勘定ができる。

結局、隠しても相手に情報は伝わる。愚痴をこぼす時は要注意

KYなやつを優先しろ

あうんの呼吸は、同質化を招く。
同質化した結果、すり合わせはしやすいが、異質なものを排除する傾向が強くなる。
そのため、新しい考えが出てこない。

同質化は、放っておくと、勝手に同質化する。
人は、フェストゥムのような性質を持っている。
多様性を維持するためには、同質化しないためのコストがかかる。

部下への直接指示は避ける。
なぜなら、バイアスがかかり、考えるのを放棄する危険がある。
相手に考えることを促すこと、考えた結果をいえる環境を作ることが大事。

ちなみに、KY発言がすべていいわけではない。
何も考えてないと、それはただの自己中。
ひんしゅくを買うことはさけ、適切なタイミングでする必要がある。

使える奴をてなづけろ

劇的なスキルアップは、難しい。
全知全能の神になるのは、無理がある。
結果を残そうと思うのなら、他人の能力を借りる必要がある。
他人を認めることから始めないと、人は集まらない。

知らないことは受け入れる。
知らない分野が何かをしり、そこに詳しい人を集めることが、強い組織を作るのに必要なこと。
弱いところを知って補強する

組織で重要なことは、手駒の数。
多くあったほうが、柔軟に対応できる。
将棋と同じで、持っている駒は多い方がいい。
ただ、駒だけ持っていてもしょうがない。打つタイミングを気にする必要がある

堂々と嫌われろ

意思決定することは、悪い決断もすることである。
悪い決断をしたくないから先送りにすることは、民主党政権みたいなものである。

意思決定とは、不十分な状況下でするもの。
十分に情報があり、迷う必要がないものは、決断と言わない。流されているという。

評価を気にすると、敵を作らないように動いてしまう。
結果として、悪い決断がやれなくなり、勝負時に勝負できなくなる。

煩悩に溺れず、欲に溺れろ

煩悩は、なくせない。
悪い方向に働かないように、自制心を持って制御する。

エロは命を救う
スティーブン・キングの短編集の解剖室みたいなことがあるかもしれない
エロは命を育むものでもある。なくてはならないものなのです。

踏み絵から逃げるな

リーダーの価値は、有事に決断できるかどうかで決まる。
リスクを取らずに失敗を避けることは、負けはしないが、勝ちもしない。

部下に使われて、使いこなせ

部下を使いこなすとは、意見を引き出させること。
そのためには、質問の仕方を工夫する必要がある。

リーダーシップとは、経験から強みと弱みを認識し、罠を避け、部下を思いやれば、自然と発揮される。

ダークサイド・スキルを磨くポイント

いつでも叩ける態勢を整える

自由な意見は、リスクがあるのでいいにくい。
そのため、保身に走ってしまう。

空気を読みすぎて、存在が空気にならないようにする。
意識的に思い切った発言をする必要がある。

黒子テツヤが存在感を示すために、強い意志と言葉と行動をしめしたように、空気にならないための努力もいるのだ!

決断の先送りは、何もやらないのと一緒であることを覚えておく。

人を操る3つの力

コミュニケーション力(意思疎通力)

人を動かすためには、ロジカルな説明が必須。
そのためには、財務表を読めることが大事。

上記3つを読めることで、事業のメカニズムが分かるようになる。
事件の気配を掴んだり、施策の有効さを紐付けることができる。
話すためのネタを見るける力にもなる。

先見の明を知るためだったり、振り返りをするためにも必要そう

硬軟織り交ぜて人を動かす「人間力

仲良くなってもいいが、緊張感は維持する。
関係を良好に保つには、配下メンバーを見る。
配下メンバーのキャリアを潰す選択は、極力回避する。

ナメられるのは、一番気に食わない!
特に、某となりの国にナメられるのは、腹が立つ!

リーダーとしての高い使命感

情報はすぐに拡散されることを理解する。
一定以上のポジションと影響力を持ったら、けじめをしっかり付ける。

自分の強さ・権威・背後にはる力が何かを理解する。
理解しないと、王様の耳はロバの耳や、虎の威を借る狐の虎と同じ愚行を犯してしまう。

【書評】ベタープログラマ

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

読書開始日

2017.01.14

読もうと思ったきっかけ

なんとなく目に入って、目次を見た感じ、良さそうだったから買った。

本書の目次

  • 1章 コードを気にかける
  • 2章 見かけのよい状態を維持する
  • 3章 少ないコードを書く
  • 4章 取り除くことでコードを改善する
  • 5章 コードベースの過去の幽霊
  • 6章 航路を航行する
  • 7章 汚物の中で転げ回る
  • 8章 そのエラーを無視するな!
  • 9章 予期せぬことを予期する
  • 10章 バグ狩り
  • 11章 テストの時代
  • 12章 複雑さに対処する
  • 13章 二つのシステムの物語
  • 14章 ソフトウェア開発とは
  • 15章 規則に従って競技する
  • 16章 単純に保つ
  • 17章 頭を使いなさい
  • 18章 変わらないものはない
  • 19章 コードを再利用するケース
  • 20章 効果的なバージョンコントロール
  • 21章 ゴールポストを抜ける
  • 22章 凍結されたコードの数奇な人生
  • 23章 プリーズ・リリース・ミー
  • 24章 学びを愛して生きる
  • 25章 試験に基づく開発者
  • 26章 チャレンジを楽しむ
  • 27章 停滞を避ける
  • 28章 倫理的なプログラマ
  • 29章 言語への愛
  • 30章 プログラマの姿勢
  • 31章 一生懸命ではなく、賢く
  • 32章 完了したときが完了
  • 33章 今度こそ分かった……
  • 34章 人々の力
  • 35章 原因は思考
  • 36章 遠慮なく話す
  • 37章 多くのマニフェスト
  • 38章 コードへの叙情歌

まとめノート

you write (code)

見かけの良い状態を維持する

レイアウト論争は不毛。
プロジェクトで統一することが大事。
制定する場合、根拠を付ける。

少ないコードを書く

ソフトウェアの機能は、コード量に依存しない。
だから、なるべく書かないほうがいい。
ただし、読んで分からなくなるレベルに少なくコードを書くのは良くない。

少ないコードのデメリット

  • 保守範囲がデカい
  • 保守コストが高い
  • 可読性が悪い
  • 修正量が多い
  • バグの隠れる場所が多い
  • 複製するとバグも複製されやすい

取り除くことで改善する

システムの改善は、コードの削減でもできる。
死んでいるコードは邪魔なだけ。
プロジェクトが大きくなるほど、死んだコードも大きくなる。
放置するのは、失敗の兆候になり得る。

コードベースの過去の幽霊

古いコードは、宝の山でもある。
そこから学べることもある。それは、いい面・悪い面も含む。
過去を知ることで、スキルを知ることができる。

航路を旅行する

コードを知るには、プロジェクトを知っている人に導いてもらうのが、一番早い。
助けを求めることを恐れてはいけない。

システムの理想は、いくつか存在しているが、忠実に再現するのは難しい。
ちゃんと現実を見据えて行動を起こさなければならない。

汚物の中で転げ回る

コードは、知らないうちにひどくなる。
ひどいコードに対策できる準備を、常日頃からやっておく必要がある。

あえて酷いコードの中に入ることで、改善方法を学ぶこともあり。
できの悪いコードは、意図してできているわけではない。

そのエラーを無視するな

エラーは、何か原因があって出る。
無視・先延ばしは、問題の解決になってない。
あとでしっぺ返しが発生する可能性がある。

予期せぬことを予期する

コードを書く際は、可能性のある全てのルートを考慮する。
例外的なルートも、なるべく適切に対処する。

バグ狩り

その場しのぎのコードは、メンテナンスコストが高くつく。

テストの時代

改善するには、問題に気づく必要がある。
フィードバックは、早く頻繁に行われるほうがいい。

開発する場合は、テスト可能な状態にすることを心がける。

複雑さに対処する

複雑さを作り出すのは、人間であることを忘れてはならない。
複雑さには、必要なものと不必要なものもある。
必要な複雑さの見極めと管理方法を学ぶことが大切。

2つのシステムの物語

誤った設計は、誤った設計を更に呼ぶ、呼び水になる。
人によって起きる問題で、政治的な背景があることが多い。

アーキテクチャがシステムに与える影響は大きい。
呼び水にならないように、変更できるように単純に保っておく。
現状を嘆かず、どうすればいいのかを考えるのがエンジニア。

練習することで完璧になる

ソフトウェア開発とは

プログラミングには、美的感覚が必要なこともある。
しかし、思いつきのコーディングはダメ。常に自問自答して、答えを探る。

単純に保つ

単純な説明のメリット

  • 説明の簡略化
  • 理解・図解しやすい
  • 誤用対策になる

バグの改修

早まった最適化は、不必要な複雑さを呼ぶ。
暗黙の想定を作らない。
適度な改修ではなく、必要十分な対処で満足する。

頭を使いなさい

単純なこと≠考えなくていい

応急処置をせず、責任を持って対処する。

変わらないものはない

変更は必ずあるもの。
変化に対応して、最適化する。ありもしない変化は、考えない。
変化に対応するためには、自動テストを開発に入れる。

コードを再利用するケース

コピペは、悪魔の所業。
やる場合は、正しさを理解してからやる。

再利用のための設計は、推測でやってはいけない。
推測で作ると、複雑さを内包したものができあがる。
必要になってから、再利用を考える。
それは、ライブラリ化、リファクタリングも同じ。

購入や車輪の再発明は、コストを考慮する。
排他的になることは、コストが高いことを考慮する。

効果的なバージョンコントロール

VSCなしの状態は、支柱のない家と同じ。
間違いが起こっても戻せないことは、致命的。
VSCは、セーフティーネット的な役割を提供してくれる。

効果的に使うポイント

  • リリースバージョンを明確にする
  • 管理するファイル構成はシンプルにする
  • 必要なものだけ管理
  • 小さな意味のあるまとまりを頻繁にコミット
  • コミットメッセージは、単純・明瞭・完結を心がける

ゴールポストを抜ける

腐敗した開発環境は、下水道と一緒。
リリース前に待ち構えるQAチームに、汚水を流してはいけない。
品質は、全員で作ることを忘れてはいけない。

凍結されたコードの数奇な人生

コードの凍結は、変更しないリリース前の期間であって、永久に変更されないわけではない。

凍結中に、技術的負債を見つけて、凍結解除されたら改善に移れる準備をする。

プリーズ・リリース・ミー

規律と計画を作り、リリースサイクルを確立する。
早めに作って、頻繁に実行することが大切。

個人的なこと

学びを愛して生きる

何もしなければ、衰退するだけ。

学ぶことはいいことだが、集中しすぎると、視野が狭くなる。
多くの情報源を持ち、広い視野でいることは大切。

学んだことは、書き出す。
持っている知識を明確化する。積極的に使って、知識を定着させる。

試験に基づく開発者

有能になっても満足してはならない。
潜在的な危険は、いつも存在していることを自覚して、考えて開発を行う。

チャレンジを楽しむ

楽しみのために開発を行ってはならない。
どうしてもやりたいことがあるならば、計画を立ててやる。

停滞を避ける

安全地帯は、有害である。
さらに良くなることはない。
なぜなら、安全だから。

変化には、リスクが常につきまとう。
意図して投資しないと、成長はできない。

倫理的なプログラマ

やってはいけないこと

  • 可読性の悪いコードを書く
  • ライセンス違反
  • 中傷不正行為
  • 不正行為を見逃す
  • 働きすぎ

言語への愛

成長は、複数の言語を学ぶことで得られる。
複数の考え方・解法をしることで、多くの問題に対処できるようになる。

愛に必要なもの

  • 尊敬
  • 信念
  • 会話
  • 忍耐

プログラマの姿勢

同じことばかり考えない。
同じことばかり考えていると、解法がでないうえに、心も狭くなる。

一生懸命ではなく、賢く

生産的なプログラマは、賢く働いている。

賢く働くための戦術

  • 賢く利用(車輪の再発明をしない)
  • 他人の解答を見る
    優秀な人の解答をパクる
  • やらなければならないことだけやる
  • 一時的な解決策を試してみる
  • タスクに優先順位をつける
  • 本質を理解する
  • シングルタスク
  • 小さく実行
  • 先延ばししない
  • 自動化
  • 会話
  • 燃え尽きない

完了したときが完了

完了は、もしかしたら、完了したと思いこんでいるだけかもしれない。
タスクをこなすときは、完了を明確に定義する。
必要以上の完了を目指さないほうがいい。

今度こそ分かった・・・

ソフトウェア開発の問題は、人間の問題であることが多い。
多面的な見方で、解決方法を探る努力をする。

人々の営み

人々の力

優秀なプログラマになるには、環境が大事。
環境を変えるには、仕事を変えるか、イベントに出るしかない。
専門家の考え方を知るのが、優秀になる近道

原因は思考

明や理由付けしたり、批判を受け入れることを習慣化する。

遠慮なく話す

開発には、コンピュータとだけではなく、人と話す必要もある。
言葉選びにも注意する。

多くのマニフェスト

マニフェストは、原則の概要にすぎない。
常に正しいとは限らないので、過信せず、状況を見て判断する。

コードへの叙情歌

コーディングの問題には、人間の問題も含まれている。
健全な状態に戻すのは、急にできない。
考え方を少しずつ変えさせるしかない。

関東の雪での社員のあるべき姿

記録

とりあえず、積雪の記録

www.sankei.com

日本列島は22日、南岸を東進する低気圧の影響で太平洋側を中心に広い範囲で雪になった。関東甲信では平野部でも積雪を記録、東京都心でも雪が積もり、帰宅時間帯の交通に大きな影響が出た。関東甲信の雪は23日にはやむが、気温が低い状態が続くため、凍結した路面などに注意が必要だ。 気象庁によると、低気圧に伴う雨雲が22日未明には九州にかかり、徐々に東に進んだ。西日本は雨の地域が多く、中国や近畿の山沿いでは雪になった。昼ごろには、東京都内や神奈川、埼玉両県などの平野部でも雪が降り始め、夕方には積雪を記録した。 関東甲信を中心に、列車の運休や高速道路の通行止めが相次いだ。 低気圧は22日夜に関東の南の海上を通過。23日以降、三陸沖を急速に発達しながら北上し、冬型の気圧配置が強まる見通しだ。

思うこと

僕の行っている現場は、早期帰宅命令が出たので、すぐに帰りました。
翌日は、普通に出社してしまいました。。。

出社がおかしいと思いつつも、雇われているので、そんなこと言えないんですよね。。。
嬉々として出社しているような記事をみるけど、だれも嬉々として出社してないと思うのですよ。
しかも、残念なことに、翌日は、電車が動いていたんですよね。。。
あの京葉線が動いていたんだから、ほとんど運行していたと思う。
思うんだけど、関東は雪対策なんてないから、少しの積雪で、経済が止まるんですね。。。
実家が新潟なので、雪はなんとも思ってなかったけど、自然の脅威を知りました。

こういう時は、リモートワークだったりがある企業が羨ましいと思いますわ。

あるべき姿

  • 出社する
  • スケジュールを守る

本当は、「安全に待機」があるべき姿だとは思いますが。。。
他の人はどうだったんだろう?

『絶対にエンジニアが転職してはいけない会社の募集要項』の個人的まとめ

絶対にエンジニアが転職してはいけない会社の募集要項 | Findy Engineer Lab

きっかけ

転職を考え始めたから。
失敗しないためにも、まとめて、頭の中を整理する。

まとめ

やばい求人の特徴

  • エンジニア職種の分解がされていない
  • 開発言語のスペル間違い、または、大文字小文字が間違っている
  • ブラック企業ワードがいっぱい
  • 営業マンが大好きそうな単語(意識高い単語)がいっぱい
  • 事業戦略に言及なし
  • 募集要項の中身が薄い

エンジニア職種の分解がされていない

ありあらゆることがお願いされる可能性が高い。
理解が低く、過度な期待をしていることがある。

分業の概念を持っていないため、ブラックの傾向があるかもしれない。

開発言語のスペル間違い、または、大文字小文字が間違っている

人事部のみで書いた可能性が高く、組織的な風通しが悪い可能性がある。

ビジネス要件をまとめたりするのに、営業を通したりもするので、環境面について注意する。

ブラック企業ワードがいっぱい

個人的に思うブラック企業のワード

  • 根性
  • あきらめない
  • アットホーム
  • 未経験者歓迎
  • 熱意
  • やる気
  • やりがい
  • 充実
  • 残業なし
  • ノルマなし

やりがい搾取、精神論による労働、「なし」という甘いワードに隠されたサービスの強要。。。
僕が感じるのは、こんな感じですかね。

これは、アルバイトにも通じるし、就活生も注意しておいたほうがいい。

営業マンが大好きそうな単語(意識高い単語)がいっぱい

とりあえず、営業マンが好きそうな意識高い単語 ※自分で思いついたやつ

ここらへんの単語が出てきたら、よく話を聞いて、ツッコミを入れたほうがいい。
事実と矛盾している箇所がある可能性が高い。
意識高い系は、矛盾を日本人がよく知らなそうな単語で誤魔化している傾向が高い気がする。

事業戦略に言及なし

なにも考えないで仕事をしている可能性が高く、どこかの下請けの可能性が高い。

募集要項の中身が薄い

やる仕事の内容が薄いと、意図してないことまでやらされる可能性が高い。

感想

とりあえず、これを印刷して面談する時に、手元に置いておこう。。。

Java10 JEP296 翻訳(たぶんあってると思うよ?)

JEP 296: Consolidate the JDK Forest into a Single Repository

要約

原文

Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development.

翻訳

多数の林立しているJDKリポジトリを一つにまとめて、開発を合理化します。

動機

原文

For many years, the full code base of the JDK has been broken into numerous Mercurial repositories. In JDK 9 there are eight repos: root, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashorn.

While this model of multiple repos offers some advantages, it also has many downsides and does a poor job of supporting various desirable source-code management operations. In particular, it is not possible to perform an atomic commit across repositories of inter-dependent changesets. For example, if the code for a single bug fix or RFE spans both the jdk and hotspot repos today, the change to both repositories cannot be done atomically in the forest hosting those two distinct repos. Changes spanning multiple repos are a common occurrence; over 1,100 bug ids have been reused across repositories in the JDK forest. The 1,100+ repo-crossing bugs is only a lower bound on the number of logically repo-crossing bugs, since some engineers use separate bug ids to push to different repos.

This mismatch between the divisions of the Mercurial repos and unity of the engineering dilutes one of the main benefits of modern source-code management: tracking changes to sets of files rather than just individual files. As a corollary, this mismatch between SCM transactions and logical transactions complicates use of tools such as Mercurial bisect.

The individual repos don't have a development cycle separate from the JDK as a whole; all the repos advance in lockstep with the JDK promotion cycle. The multiplicity of repos presents a larger than necessary barrier to entry to new developers and has lead to workarounds such as the "get source" script.

翻訳(意訳:間違ってるかも)

長年の間、全てのJDKのコードベースは、多数のMercurialリポジトリに分断されていた。
JDK9の中には、root, corba, hotspot, jaxp, jaxws, jdk, langtools, nashorn の8つのリポジトリが存在している。

この構成は、多少のメリットがあると同時に、それぞれのソースコードを管理する上では貧弱であるデメリットがあります。
特に、相互に依存する変更箇所をコミットすることはできません。
例を挙げると、単一のバグ修正や機能拡張のエンハンス対応が、現在のJDKと改修中のリポジトリの両方に変更が必要な場合は、競合がおこってしまいます。複数のリポジトリにまたがる変更は、一般的に存在するものです。
1,100以上のバグが、JDKリポジトリで同一バグとして修正されています。
1,100以上のリポジトリをまたがったバグは、論理的には下限値ではありません。なぜなら、一部のエンジニアが、同一バグを別のバグIDを使用してリポジトリに反映させているからです。

Mercurialリポジトリの分割と統一されたエンジニアリングの両方を成立させるという相反する考えは、ソースコード管理の主なメリット(変更したファイル群の変更追跡)を弱くする。
その結果、ソースコード管理と論理的課題の間に起こる不一致は、Mercurial bisectなどのツールの利用を複雑化する。

リポジトリは、JDK全体の開発サイクルから独立しているわけではありません。
全てのリポジトリは、JDKの進捗状況と足並みを揃える必要があります。
多くのリポジトリが存在することは、新規開発者の参入に大きな弊害をもたらしたて、ソースコード入手方法が複数存在する状態になっています。

詳細

疲れたからパス

【WEB+DB PRESS】Vol.102 はじめてのペアプロ/モブプロ

目次

  1. ペアプロ/モブプロとは何か
  2. ペアプログラミングの基本
  3. ペアプログラミングの実践ノウハウ
  4. モブプログラミングの基本
  5. モブプログラミングの実践ノウハウ

まとめメモ

ペアプログラミングとは

2人でプログラミング(および分析、設計、テスト)とプログラムの改良を同時に行うやりとりのこと

モブプログラミングとは

ペア(2人)ではなく、モブ(チーム全体)でプログラミングを行う。

思うのだが、タイピングする人は、いろんな人からあれこれ支持されて、ストレスたまらないのかな?

役割

ドライバー

キーボードの前にいて、コードを書き進めていく人

ナビゲーター

ドライバーの隣に座り、ドライバーと会話しながら導く人

ペアプログラミングの歴史

XPを最も強く体現したプラクティスがペアプログラミングだった。
モブプログラミングは、XPのプラクティスをベースとして開発された発展的な手法。

ペアプロ/モブプロの効果

作業への集中と質の向上

  • リアルタイムでコードレビューしてコードに反映
  • 相互監視されることで、目標がブレを防止
  • 会話による思考整理
  • 集合知の結集
  • ケアレスミスの減少

知識と学びの共有

  • 技術力の底上げと高い教育
  • 過程(プログラミング)から学ぶ
  • 属人性の減少
  • 暗黙知の共有

ペアプログラミングの進め方

  • コードを書く前に方向付けを行う
  • コードを書きながら会話し、考えを共有する
  • ロールを交代する

組み合わせ

ベテランと新人の関係は、相互補完の関係にあり、理想形。
ベテラン同士は、揉めたりする可能性もある。
いわゆる音楽性の違いみたいなのが発生する。
新人同士は、学習の機会が少なく、あまり成果が得られない可能性が高い。

ペアプログラミングの実践ノウハウ

なるべく開発環境は、統一する。
しかし、現実的な解決策ではないので、エディタやIDEの依存度を下げるリアルタイム共同編集機能を備えた環境を作る。

ペアプロの強制はしてはいけない。
どうしても受け入れられない人もいるので、そのことは認めなくてはいけない。

知識はペア内にしか残らないので、ペアのローテーションをする。
その際、意図を残すプログラミングを心がける。
※それは普通のことな気もするが。。。

モブプログラミングの基本

モブプログラミングの始め方

  • 大画面のディスプレイを用意する
  • 解決する課題を絞る
  • ドライバーが積極的に助けを求める
  • ナビゲーターは手分けして調査

日本だとデカいディスプレイは高いので、プロジェクターにしたほうがいい気がする。

モブプログラミングを支える文化

スウォーミング

課題を複数のタスクに分散して作業すること。
変化に対する対応能力を高く保てる。

高度な意思決定

情報が常に集まってくるので、感覚の同期や意思決定の作業が迅速に行える。

高速な意思決定に必要なことは、迅速なフィードバック、ふりかえり、技術負債の認識。
実施する上で、上記のことを認識してやる。

外部との信頼関係

生産性に疑問を持つ人は多い。
近年のプログラミングは、定型文のコピペではないので、そのことを理解してもらう必要がある。

モブプログラミングの実践ノウハウ

モブプログラミングを支える技術

メインブランチでの開発

全員で開発するのでレビュー時に戻りが発生する可能性を下げる。
マージ作業がいらなくなるので、苦痛が減る。

変更したらすぐにデプロイ

モブプログラミングにかぎらずではあるが。。。

技術的負債の解消

集合知を活かして、どこで問題解決するかを選定する。
リスクを減らして対応できる可能性が高い。

感想

集合してやるのは、良さそうな感じはするが、誰かに頼り切っている奴らが多いと、破綻しそうな気がする。
構成するメンバーの価値観が、似通ってないとキツそう。
読んでて思ったのは、個を高めることに貪欲な人でないと、正の循環が生まれず、やってもメリット薄いような気がした。