エンターテイメント！！

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

JJUGナイトセミナー Java API訴訟問題を考える 参加報告

論争 プログラミング

概要

イベント趣旨

2012年、OracleはGoogleが「Android OSにおいてOracleの著作権や特許を侵害している」として訴訟をおこしました。
その後、Googleによる著作権侵害が認めらえたあるとされたものの、2016年5月には「フェアユースの範囲である」とされました。
この件について考える勉強会を行いたいと思います。

内容

初のMS開催！

日本マイクロソフトで初開催。
久々に行ったけど、場所は案外覚えていて、方向音痴だけど迷わず行けた。
品川の人混みは、ちょっと吐き気を催す。

そこには。

寺田さんが元気に会場整備。
あまりに違和感がなく、最初は気づかなかった。
心なしか、元気そうであった。

Oracleが訴えるまでの経緯について～SunとOSSとIBMとAndroid～

www.slideshare.net

Javaのエコシステム

  • 標準仕様と各社別の実装
    • ベンダーはJava標準APIを実装した製品を販売
    • 仕様標準によるロックイン回避
      ただし、ベンダーの差別化による追加実装はあった
  • 仕様の策定がオープン
    • 仕様はJCPを通じて作成
    • 標準認定にはSunによるテストが必須＆お布施が必要

今のOpenJDKやOracle提供のJDKしか知らなかったが、昔はベンダー各社で提供がされていたのか。
アンチMSの考えが発端にあるのは、なんとなく理解できる。

OSSのエコシステム

Apache Software Foundation

1999年設立されたオープンソースを支援する任意団体
Apache Software Foundationの元、色々なOSSが開発された。
Struts, Tomcat...etc
また、基本的にAL2.0で商用利用可・非公開OKが魅力的だった。

IBMとASF

OSSを戦略的に活用して、IBMが飛躍
OSSで実装を共有し、標準化
実装ベースでの標準化に成功

コミュニティベースのイノベーションが起こり始める

JavaとOSS

  • 2005年5月 Project Harmony提案
    • 目的は、AL2.0でJava5の実装提供
    • 賛同する企業が多数出現(BEM, IBM, Intel...etc) → 反MSの流れ？
  • 2006年10月 ApacheHarmony爆誕
  • 2006年11月 Sunが反抗してJ2SEをOSS化
    • のちのOpenJDK
    • ただしGPLv2(コード公開義務あり)　→　ベンダーの不満が溜まる
  • 2006年 Sum vs Harmony
    • Harmony：制限外せ！！
    • Sun：やだ！！　→　お布施が欲しい？企業の財政的に厳しかった裏がある？
  • 2007年8月 SunがTCK*1を公開
    • テスト対象がGPLv2である必要があり、実質OpenJDK専用
    • Apacheが抗議活動をし、JCPでのJSR承認に全て反対 →　似たような行動を日本のどこかの政党で見たことがある気が。。。

意外と子どもっぽい言い争いな気がしてきた。
牛歩戦術って単語が出てくるのでは？と期待してしまった。

AndroidとJava

2005年頃からGoogleがAndroid戦略として動き出す。

目的

  • 打倒MS
  • OSSによるキャリアとメーカーへの価値提供
  • ユーザの囲い込み

Androidの普及

  • 無料で使えるOSにベンダーが乗っかる
  • ソフトウェアの対価よりユーザ数が欲しいGoogle

両者の思惑が一致したために、普及した。

Android以後

Sun の OSS 戦略は失敗

  • 2009年4月20日に Oracle に買収
  • 2010年8月、Oracle が Google を提訴
  • 2010年10月、IBM が OpenJDK に参加
  • 2011年11月に Harmony は活動停止

個人的な考え

GoogleによるJavaの分断は、SunがJavaを完全OSS化しなかったための流れ。
本来はプラットフォームで分断化されるリスクは最小化すべきだと思いました。
※分断の意味があっているか、若干不安。。。

この流れを知ったうえで、裁判を起こしたOracleを見ると、
Androidへの嫉妬な気がしてならない。
(JavaMEより成功しているのが気に食わないのかな？？？)

AndroidをJavaMEにしちゃて、取り込んじゃえば？って思わなくもない。
そもそも趣向が違うので、無理な話かも知れんが。。。

歴史的な背景は、これにて終了！

Oracle vs Google訴訟の全貌と概要 ～APIは著作権で保護されるべきか～

www.slideshare.net

Oracle vs Google 裁判の論点

  1. 特許権侵害　→　解決済み
  2. Javaライブラリ実装コード本体の無断複製　→　解決済み
  3. JavaAPIの著作権侵害　→　論争中(本日のお題！)

APIの利用はフェアユース*2かどうかが論点。

法律議論の注意点

  • 解釈論
    法をどう捉えるか
  • 立法論
    どういう制度であるべきか

法律を語るには、両者を区別する必要がある。
今回は、解釈論について。

著作権とは

著作物の利用について、一定期間の独占権を認めることが、著作権の目的。

法律では、保護と利用のバランスを取ることが大切。

著作権の大原則

  • 申請しなくても創作したら自動的に生じる
  • 表現を保護するものであって、アイデアを保護するものではない

超そもそも論(立法論)

なぜプログラムは著作権で保護されるのか

本来は、芸術のための法律で、技術分野とは縁が薄かった。
1980年代にソフトウェア発展とともに、保護が急務になった。
なので、やっつけで芸術と一緒にされてしまった！！
日本は、別アプローチで法の保護をしようとしたが、米国のご威光で同じく一色単に！

日本と米国の裁判の違い(Break Time!!)

日本

法律を重視。　→　解釈論を優先する
裁判結果は予測しやすいが、技術変化への対応が遅い。

徳川200年の歴史を持つからなのか？
法を守ることに重きをおく。
法を作る人間が優秀で迅速に行動できる人である必要があるな～と、今更なが思う。

米国

公正さ(フェアユース)を重視　→　技術変化への対応が早いが、裁判はやってみないと分からない

さすが、自由の国！
自由競争が重視されたからこその考えかもしれん。
国民性がでるなと感じた。

米国のフェアユースの考え

社会にメリットがあると判断されればフェアユースとなる

例

同人誌を訴えたが、同人誌のおかげで売れるようになった　→　フェアユースが認められる
ベータマックス裁判でのタイムシフト録画　→　市場に害があるとみなされないためフェアユース
※日本だと法律に書いてあるので、合法

ベータマックスが、ベイゴマックスに聞こえてしょうがない！(余談)

米国は、裁判の結果が法律化するので、技術変化への対応が早くなる仕組み。

フェアユースの両者の言い分

Oracle

  • Javaを使って金儲けしすぎじゃ！(俺に分前をよこせ！)
  • フェアユースは報道、教育、研究に適用されるもの
  • スマホでの出遅れを卍解するためにJavaの資産を使った

Google

  • API の再利用はイノベーションの源泉
  • Javaは、みんなが使えるオープンなもの(空気のような存在？)
  • Oracleはライセンス料が欲しい小銭稼ぎ

訴訟戦略

陪審員が技術系のトーシローなので、感情に訴えて勝つのが、戦略としてあるらしい。
ここは、日本の水戸黄門のライターの出番な気がしてならない。

Googleは、そういう点だと、非常に有利かな～と思った。
Google検索は便利だし、利便性の良いサービスをフリーで提供してくれるし。
FinTechでますます世間の印象がいい。
Oracleがかなり不利な気がする。
ただし、日本では感情論に訴えても意味が無い。法が絶対だから。

Q&Aであった面白い考えや意見

今後のスケジュールは？早くて何年に終わる？

早ければ2、3年で決着
それまでの間、Javaが停滞しないか、ちょっと心配。

コミュニティから裁判するなという働きかけはなかったのか？

Oracle の人気がなさすぎて『何やってるの Oracle』という考えが主流だった

APIの著作権を認めることでAPIヤクザがでるのでは？

何がいいたいかというと、APIを広めて、広まったタイミングで訴訟を起こす。

さそがにそれは止められるだろうという考えだった。

個人の考え

Googleがかなり有利だし、勝って欲しい。
感情論かもしれないが。
Javaをプラットフォームとして普及されるなら、もっと普及させる努力をOracleにはして欲しい思いが強い。
できれば早期解決を願う。

*1:Java認定のためのテストキット

*2:公正な利用であれば、その利用行為は著作権の侵害にあたらないという考え

【書評】SOFT SKILLS

プログラミング チーム 生産性 書評 マーケティング

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

Soft Skills: The Software Developer's Life Manual

Soft Skills: The Software Developer's Life Manual

きっかけ

プログラマ向けに書かれた「Soft Skills」という本がすごいという話 - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blog

↑の記事を読んで、前から読みたいと思っていたが、手が出せていなかった。
日本語訳が出たのをきっかけに、日本語訳版を購入して読んだ。

内容

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

キャリアを築こう

スタートから派手に行こう！：誰もがするようなことはするな

事業者のマインドセット

ソフトウェア開発者のキャリア　→　ビジネスとして扱う
スキルは、個人の資産で、大切なもの。
事業主として考えて、資産を増やす必要がある。
事業主のマインドを持つと、スキルの棚卸しと必要なスキルの判断をするようになり、プラスに働くから。
(俺は、クリアマインドが欲しいッ！！)

どのようにして自分を事業と考えるか

事業として売るもの　＝　ソフトウェア開発スキル
多くいる開発者の中で独自製品(特殊スキル)を持ち、差別化を図る必要がある。
そして、スキルは持っているだけでは意味が無いので、価値を伝える必要がある。

未来について考える：あなたの目標は何？

事業として考えぬいたら、次はビジネス目標を考える番。
何に力を注ぐべきか十分に考える必要がある。
特に、人間は何に力を注ぐべきか考えずに行動することがある。
何も考えずにポストに飛びつき、来るか来ないか分からないチャンスを待つ。
(「果報は寝て待て」を都合よく考えるやつが多いのもそれかと思う。寝て待つのはやることをやって、準備万端になってから。それをせずに寝たら、ただの時間の浪費だろうと思う。)

早く目標を決めて動く。
そうしないと、時代や周囲の人間に流されて無駄足を踏む人生を歩むことになる。

目標の設定方法

  1. 大きな目標を決める
    細かく決めなくていい。近づいたら細かく目標を立てる。
    重要なので時間をかけて考える。
  2. 途中にある小さな目標を決める
    大きな目標から現状に至るマイルストーンを考えてみる。
    そこから小さな目標を持つことで小さな達成感を得て、目標へ向けての動きを加速させる。

社交術：考えている以上のものが必要だ

放っといてくれ、私はただコードが書きたいだけなんだ！

優れたソフトウェア開発者　＝　人と接するのが上手い
仕事の大部分は、人相手。コードを書くのが仕事であるとの考えは、間違え。
人と接することが大前提。

「大切にされている」と誰もが感じたい

人は、大切にされたいと根底で思っている。
(同意。大切にされたい。誰かもっと俺を甘やかしてぇ～！！！)

人と接するときは、基本的欲求を意識して、自分の行動がどう影響するか考えるべき。
(今のメディアはできていないことが多い気がする。)

何らかの形で存在を貶める　→　限度を超えると凶暴な反応を見せる。
さらに、その反応をからかうのはNG。
余計エスカレートしていく。
(残虐な事件は、大部分がコレな気がしてならない。周囲の人間が無自覚でからかってえいる可能性もある。)

人に自分を認めて欲しいのなら、まずは自分から他人に礼を尽くす。
プライドを傷つけては、人心は絶対に掴めない。
(劉備もそうしただろう！三顧の礼は社交術の基本)

批判　→　行動意欲を削ぐ。
罰するよりも褒めることが重要。
人への批判は絶対にやめるべきだが、コードへの批判は積極的にする。
ただし、コードへの批判が、人への批判の隠れ蓑にならないようにする。
例えば、「だれこのウンコード書いたの？この開発者クソじゃね？」って言うとか。
(この例は、知り合いの知り合いの話だから！)

他人が望んでいることを考える

相手が望んでいることを考える。
そうすることで、人への批判が減り、好意と尊敬の眼差しを得られる。
会話も自然と相手中心で敬うものにハズ！

議論は避ける

人は、感情的な生き物。
必ず理解してもらえるわけではない。
大人は感情をコントロールできるようになっただけで、中身は子ども。
(大人がケンカしているところを見ると、子どもだということがよく分かる)

話が平行線になる場合は、自分の意見を諦める機会を待つ。
本当に大切な事を見極めて、許容できるのであれば、許容する。
貸しになり、次に自分が意見を通しやすくなる。

面接をハッキングするコツ

面接で合格するための手っ取り早い方法

気に入られるのが一番早い。
※最低限の技術力があればの話。

常識に囚われずに親密な関係を築く

採用　→　個人推薦があると有利
推薦してくれた人の社会的信用を借りることができるため、スタートから高く評価してもらえる。
(これを代理証明してくれるのは、ビジネスになるのではなかろうか？)

面接に必要なもの
  • 常識に囚われない考え
  • 社内の接点となるべき人との関係構築
    →何かのユーザグループに参加して発表すれば、ある程度コネが作れる。

本物の面接ではどうすればいいのか？

技術的に優れているのは、当然。
次に、求められていることを理解し、実行できることが求められる。

雇用者にとって、雇うのは投資。
仕事を頼まなくても終わらせる人が優遇される。
何事も進んでやる積極性が重要。

今すぐできることは何か？

  1. 技術スキルを磨く
  2. 人脈作り
  3. 面接練習

雇用形態：３つの選択肢を理解する

会社の従業員

メリット
  • 安定性
  • 責任範囲の限定
デメリット
  • 時間の大半を雇用主に捧げる必要がある(つまり、奴隷である)
  • 仕事が選べない
  • 収入の頭打ち

独立系コンサルタント

メリット
  • 自分で自由に時間を使える
  • 収入が増える可能性がある
デメリット
  • 仕事探しは自分で。
  • 負荷が大きい
  • 上司が増えるだけで、会社員と変わらないかも

アントレプレナー

ギャンブルに近い。時間と将来の可能性を利益と交換している。

メリット
  • 完全な自由
  • 大儲けができるかも
  • やりたいことができる
  • 上司がいない
デメリット
  • 完全自己責任
  • ソフトウェア開発以外のスキルが必要

あなたはどのタイプのソフトウェア開発者か

専門性はとても大事

専門分野を持つ　＝　多くのチャンスが得られる。
枠が小さくなる可能性もあるが、欲しい人から見ると魅力的に見える。
※プログラミング言語は専門性とは言えない。ただ使う道具がそれですというだけ。

ソフトウェア開発者の専門分野

何を作るかはっきりさせておく必要がある。
特定分野に特化する　→　高時給が得られる

専門分野の選択方法

どこまでやるか、できるだけ限定する。
そうすることで、限定的な市場での価値が高くなる。

多言語プログラマーはどうか

複数のスキル持ち　→　貴重な存在だが、スキルが浅いと売り込みにいく。
多言語を極める前に、一つの言語を極める。
多才になるのは、その後。

どの会社も同じではない

小さな会社とスタートアップ

一人一人の会社への貢献度が大きい。
安定性に劣るものの、求められるスキルは広い。
早いペースで何かを作りたい・成長したい人が選ぶべき

中規模の会社

安定している。もしかしたら、大企業よりも安定しているかもしれない。
小企業よりリスクが負えず、変化のペースが遅い。
最先端テクノロジーが支持されるわけではない。

大企業

深い企業文化が存在している。
多数の手続きがあり、形式的で、確立されたやり方で仕事をする必要がある。
与えられるチャンスが多いが、成功しても貢献度が低い。
政治操作の餌食になる可能性がある。

ソフトウェア開発会社かソフトウェア開発者がいる会社か

アジャイルプロセスが適用されているかで見極める。
開発者主導で仕事ができることが、重要

出世階段の昇り方

責任を引き受ける

地位を引き上げることとは、責任を引き受けることである。
責任を求められたら引き受けるべき。
責任を負わせてもらえない場合、外に出て誰も関与しない場所を探す。
不毛な沼地を肥沃な大地に変える　→　一番評価されて、真価が発揮できる
(なぜかMTGを思い浮かべた)

間接的に責任を引き受ける

チームメンバーの指導者、助言者になる。
他人の問題を解決することで、多くを学べる。

責任の重い仕事が回ってくるためにできること

  • チームメンバーの支援
  • プロセスのドキュメント作成・メンテ
  • 作業の自動化

(自動化は同意。楽なことをしてくれる人は、重宝されるし、アレコレ依頼される)

自分の存在を主張する

達成したことを誰も知らない　→　何をしても意味は無い。

主張するためにできること
  • 仕事内容を記録して、要約した内容を報告する
  • 発表や講師
  • 声を上げる
  • 定期ミーティングへ必ず出席

勉強する

スキルと知識を磨く　→　昇進昇格に有利
キャリア向上への真剣度を見せることができる。
ソフトウェア開発以外の知識を習得しておくこと。
視野が広がり、将来的に必要になる。

学習している事を知ってもらう　→　自分の価値を高く見せる

プロであること

プロとは何か

責任を取り、キャリアを真剣に考え、あえて茨の道を選択する人。
重要なのは、首尾一貫とした考えを持ち、高品質を当たり前に考えて、基準を持っている人。

プロとアマチュアの違い

プロ
  • 原則に従う
  • 仕事を正しく終わらせる
  • 間違いと無知を認める
  • 責任を取る
  • 首尾一貫。言動がブレない。
    (リーダーで言葉と行動がブレブレの奴を最近見た気がする。ハゲとは言わないけど)
アマチュア
  • 仕事を終らせることに集中
  • 間違い・無知を認めない
  • 責任は取らない
  • 言動が変わる。

いい習慣を身につけてプロになる

プロ　→　習慣から始まる
習慣は、安定性を築き、信頼性を養う。
継続的な自己研鑽は、高い品質と技術を得られる。

自由を得る：仕事の辞め方

上手な辞め方

上司に伝えるのは、賢いやり方ではない。
貯金があったとしても、すぐに火の車になる。
やめる前に現実的なプランニングが必要。
副業を初めて、生活を支えるレベルのことができるようになってから、そちらにシフトする。
考え無しで辞職　＝　生活が苦しくなるだけ

独立して働くための準備

新しいことを始めるために辞職　→　辞めた方がいい。
なぜなら、必要な仕事を把握しておらず、辞めた時には遅い。
始める前に、ある程度成功させる必要がある。

新事業　＝　必ず失敗する 成功させるために多くの失敗が必要になる。

フリーランサー：外に出て独立する

クライアントを獲得するための最良の方法

ブログを始めること。
コンテンツから自身の判断をしてもらう。 料金は、適当に決め手はならない。
生活に支障がない額を掲示する必要がある。
そのためには、競争力を持っていることが前提

初めての製品開発

クライアントの候補を見つける

顧客が見える製品を作る。
顧客なしの状態では、成功せず、売り込めない。
有名人は、名声を使って製品を売り込む。
できない人は、ブログで買い手を作らなければならない。

市場をテストする

買ってくれる人が少ない　＝　問題の定義がおかしい
前進しても大丈夫か判断したら進むと、上手くいけば顧客グループができるはず。

小さく始める

ものごとの最初　→　必ず失敗する
最初から大きく賭けても、失敗の可能性が大きいので、最初は小さくしてリスクを小さくする。

スタートアップを起業したい場合

スタートアップの基礎

規模の拡大と利益増大を狙う

大きく潰れるか

スタートアップの目標　→　大企業になること
リスクが大きいことをしなければいけないので、失敗の可能性が大きい。
(日本でスタートアップ企業がないのは、リスクを犯せない人間性から)

典型的なスタートアップ

知的財産を基礎にしている場合が多い。
一般的な方法　→　既に大企業が実践済み
大規模な潜在的価値の獲得が必須になる。

アクセラレータ

企業を成長させる人(ラノベに出てくる反射させる人ではない)
狂想は過酷だが、採用できればメリットが多い。

遠隔勤務サバイバル戦略

隠遁の課題

在宅勤務　＝　課題が多い

  1. 時間管理
    誘惑が多く、計画立てないと時間だけが過ぎる可能性大
  2. 内発的やる気
  3. 孤独感

うまくやり遂げるまでは、できたふりをしよう

取り掛かる前からやり遂げたかのように行動する。
嘘をついて行動しろと言うことではない。
行動することが前提で、自身がないことで行動を制限しなさんなという意味。
難しい問題に挑み、やり方を覚えることが重要。
(少し、ポジティブ思考が強い気が。。。考えなしにやり始めては行けないと思うが。)

ダメな履歴書を良くする方法

プロのライターを雇う。
ただ、プロのライターなら誰でもいいわけではない。
慎重に選ぶ必要がある。

必要な情報は、きちんと揃えてプロに渡す。
ゴミを渡してもゴミしか生まれないので、注意！
(残飯にキャビアぶっかけても、残飯なのが変わらないのと一緒！！)

プロを雇わない場合、ユーモアと仕事の結果を書くしかない。

テクノロジーに対して頑なな態度を取る。

テクノロジーに対して宗教的になっている

自分がやっていること　＝　熱狂的になってしまう。
知っているというだけでテクノロジーを崇めるのは危険！
数あるテクノロジーの中から、最良なものを取捨選択できることが必須。
最新のテクノロジー以外が、劣っているという考えは持たないようにする。

すべてがいいもの

テクノロジー　→　歴史のある時点では「いいもの」だった。
時間とともに状況が変わり、求められるものが変わっただけ。
存在を認めて、広く受け入れる必要がある。

選択肢を制限するな

自分が選んだテクノロジーが最高だと思ってはいけない。
他のテクノロジーの過小評価　＝　最終的には自分を傷つける。

自分を売り込め

コードモンキーのためのマーケティング基礎構造

自分のマーケティングとは？

無意識にしていることが多い。
自分のメッセージと届く範囲がコントロールできるようになれば、売り込み方を調整できる。
積極的に自分の意見を言うように心がける。

自分のマーケティングの大切さ

エキスパートになっても、他社との競争に負けては意味が無い。
自分を売り込む手法を知ることで、相手よりも優位に立てるようにする。

自分のマーケティングはどのようにすべきか？

個人ブランドの設立から始める。
ブランドを作ることで、どう進めて行くかを考えて、首尾一貫した行動できるようになる。
一番簡単なブランドの作り方は、ブログを作ること

自分だと気づいてもらえるブランドを確立しよう

ブランド

製品・サービスについて思い浮かぶ期待感。
視覚を通して予想を起こす。

ブランドを構成するもの

  • メッセージ
  • ビジュアル
  • 一貫性
  • 反復的な接触

独自ブランドを作る

  1. メッセージを決める
  2. 市場を選ぶ
  3. キャッチフレーズを決める
  4. エレベーターピッチ
  5. ビジュアルを作る

作って満足せずに、拡散まで行う！

成功するブログの作り方

ブログの重要性

  • 技術分析による宝物庫(ゲート・オブ・バビロンの作成！！)
  • 力量の向上
  • チャンスがくる可能性の向上
  • 考えの言語化
  • 専門知識の最新化

成功のためのポイント

たくさん書くこと。
投稿の頻度が重要。
最低でも週一がいい。記事が多ければ多いほど、トラフィックが増える。
(同意。ブログ分割したら、アクセス数が激減した。。。orz)

質の高いコンテンツを作ることを忘れてはならない。
質の高いコンテンツは、読む人が増え、成功の可能性が増える。
そして、リンクが貼られるようになれば、アクセス数が増える。

ちなみに、最初から高すぎるモノを求めてはいけない。
いいコンテンツを作るには努力が必要。
イメージを中心に作る。

ブログ継続のためには、アイディアのストックと質の高さを意識しないようにする。

アクセス数を増やすには

他人のブログにコメントを残す。
ただし、スパム的メールはNG

最大の目標：他人のために価値を生み出せ！

人が欲しがっているものを作れ

人が欲しているものを知ることは、難しい。
なぜなら、人は嘘を言う可能性が高いから。
※意図して嘘を言っているわけではない。

兆候を掴み、ものごとを見極めることが重要。

自分がしていることの９０％は、無料化

ハードワークの対価を得ることは、間違いではないが、大成しない。
なぜなら、シェアしにくいため評判が広まらない。
将来への投資が必要。評価は値段が付けられない。

講演、プレゼンテーション、講師

ライブで話す力は必須

講演を始める

人前で話す　→　上達するまで時間が掛かる。

職場でのプレゼンテーションが最適。

社員が発表することは歓迎されることが多い。
仕事に直結していれば、なおさら。

チームで役立ちそうなことの講習会をやる。

エキスパートである必要がなく、プレゼンの必要もない。
学んだことをシェアすること、人の役立つ情報が大切。

ユーザグループでの講演

新たに発表してくれる人を求めている。
小規模で前提条件が厳しくなく、マーケティングにもなる。

フォロワーを惹きつけるような本・記事を執筆する

本や記事が重要な理由

本を書く　＝　一定の信用が生まれる
専門家として見られたいなら必須。
(大学の教授とかよくやる。中身があるかは別だか。)

書籍・雑誌は利益にならない

本から多額の収入を得るのは、奇跡に近い。
(同人出版したことがある人は分かるはず！俺は分からない！)

収入が得られないだけで、メリットがないわけではない。
広く流通すれば、得られる信頼の量が違う。

惹きつける記事を書くなら

Amazonとかで、ベストセラーを見るようにする。
そうすることで、興味があるトレンドや問題が分かるようになる。

バカにされるのを恐れるな

あらゆることは、最初が気まずい

最初は、誰でも居心地が悪い。
時間を掛けないと、居心地の悪さは消えない。

バカに見えても構わない

他人にどう思われようが気にしないこと。
プレゼンで失敗しても、死ぬわけではないし、肉体的被害はない。
失敗したプレゼンは、頭に残っていないもの。

プライドを捨てて外に出ることが重要
(サイヤ人の王子には無理だろうけど！)

ベストを尽くしつづけ、結果が出るのを待つ。
何かをやり続ける　＝　上手くならないと行けないから続ける

小さなステップを踏む

成長する方法
  • 自身を追い込む(獅子の子落とし？？外国にそういった諺はないのだろうか？)
  • ゆっくりステップを踏む

学ぶことを学ぼう

学び方の方法を学ぶ

学習のプロセスを解剖する

興味を持ったこと　→　無意識に学ぶ
学んだことを実践する　→　覚える可能性が高い
学んだことを他人に教える　→　学習効果が高い

学習スタイルは、人である以上、同じになる。
人毎に違うのは、間違え。

人生の大きな目的は、知識ではなく行動である。
ハーバード・スペンサー

本を買って読むだけでは学んだとは言えない。
実践までやる。
(バカの壁で言いたかったことに近い気がする。)

独学の方法

何かを学ぶ　→　出来る限り早く試せるポイントに到達し、行動を起こす。
遊べるだけの知識がつけば、好奇心という強力な武器を手に入れられる。
好奇心を武器に、能動的に学習が可能になる。
(作者はMTGを例に出していた。俺は遊戯王だ！！！)

メンターを探す：あなたのヨーダを探す

(外人のヨーダ信仰は異常)
(師匠といえば、日本人なら東方不敗やろうがッ！)

メンターの資質

メンターには様々な種類がいる。
もっとも優れたメンターになるには、もっとも落し穴にハマった人であることが多い。

メンターをどこで探すか

ベストは、個人のネットワーク内から探す。
個人のネットワークが狭い場合、近くのイベントに出て探すことがいい。

仮想メンター

メンターが見つからない場合、本を仮想のメンターにする。
※なるべく本物のメンターがいい
(自分は、だいたい本がメンターになることが多い)

メンターを見つけたとしても、そのメンターが積極的だとは限らない。
その人になりきって、仮想メンターを想像するのもあり。

積極的ではないメンターに教えてもらうには、熱意と無償の労働が必須。
(師弟関係で、弟子が雑務をやるのは無償労働な気がする。。。)
(ハウツーを読んでもできないことがある。それを知らないで大声上げる奴は、バカの壁を超えられない)

弟子をとる：ヨーダになる

メンターになること

開発者は、自分がメンターになれるとは思っていない。
しかし、教える人は、１歩先に進んでいるだけで、メンターの資格がある。

メンターになることは、正しいこと知っていることではない。
他人の問題を客観的に見て解決方法を示すことが、メンターの役割。
知恵や経験を教えてはならない。他人の成功には部外者の視点だけでいい。
(この考えはちょっと懐疑的。知恵の継承は必要だと思うのだが。。。)

メンタリングのメリット

「なぜ」の問にさらされ続けるので、深い知識と考え方が得られる。
成長を助けることで、立場逆転しても助けになってくれるかも知れない。
(恩をきせなかった場合、仇討的な倍返しを食らうだろう！)

教える：学びたいなら教えろ

(「えろ」で終わると、くださいを付けたくなる。)

自分は教師ではない

教えることは、誰にでもできる。
しかし、できないと思っている人が多い。
それは、能力の問題ではなく、自身に影響されるから。

完璧にマスターした　→　教えられる 朧気なから覚えた　→　恐ろしさを感じる

教えることは、知識をシェアすること。
教師になることは、エキスパートである必要はない。
教わる人より一歩先にいることが重要。
(今の教師は学位にこだわりすぎているからダメな気がする。)
(人生学も含めて、人間として一歩先に行く必要があると思う。)
(そして、先生と呼ばせるのではなく、呼ばれる存在になる必要がある。)

教えると何が起こるのか

深く理解できていない事実に直面することができる。
問題にぶち当たる事によって、情報の断片が再構築されて概念を手に入れる。
(理解、分解、再構築？？錬金術の流れがここに出てくるのかッ)

始める

教える場合、謙虚な視点で権威的なトーンで話す。
知識のひけらかしではなく、自身を持ってしっかり話すことが重要。
自信なさげに話すと、信頼は得られない。
教える方も、教わる方もバカにされたくないと思うので注意する。
お互いにリスペクトできるような教え方をする。

正しく教えるには、練習あるのみ（Go！プリンセスプリキュアのシャット風）
自分の優位性の証明や、承認欲求を満たすことをしてはいけない。
(今の人には、かなり厳しい気が。。。)

今まであった中で、最も優れている先生を思い浮かべて、アプローチを真似る。
(残念なことに、学校の教師で尊敬する人にほとんどあったことはない。やっぱり職場で一緒に働いた人になる。) (一番印象に残るのは、話が面白い人ですね。)
(あとは、仕事への取り組み方が、真似できないくらい厳格な人とか)

学位は必要か、なしで済ませられるか

成功するために学位は必要か

成功には不要。
しかし、学位がないと求人と昇進に影響する。

大企業ほど学位を気にする。
理由は、教育レベルで求人をフィルタリングかけるため。
(果たして、それは適切なのだろうか？結局、学位だけでは優秀な人を逃す気がするのだが。)
(働く事に重きを置いた人は、学位がないのに優秀であることが多いと思うが。) (自分が学位ない(大学出てない)ので、懐疑的になる)
(優秀な人を取りたいのであれば、きちんと人を見るべきだと思う。人事の怠慢では？)

能力を証明できれば、教育済みの証明は不要。
つまり、ベンダー系の資格があることが重要。

学位がなければどうすればいいか

経験と能力の証明が必要。
学位は、能力の証明。
学位がない場合、能力の証明をする必要がある。

証明するためには、自分の作品集を持つ必要がある。
GitHubでOSSに貢献することが、一番の近道。

知識のなかの隙間を見つける

(そこにサンタナがいるはずだ！！)

なぜ隙間が残るのか

知識の隙間は、放置されやすい。
隙間があることで、何が問題なるのか理解できなかったり、理解できないことの気持ち悪さの回避に走る。

隙間の見つけ方

知識の隙間　→　見つけるのが難しく、無視されやすい(まるで俺みたい！)
単純な見つけ方は、作業する上で時間が掛ているところ。
知らないことがあるせいで、無駄な事をしている可能性が高い。

分からないことや調べれなければいけないことは、リスト化して知識の隙間があることを理解する。

隙間の埋め方

隙間を認識すること。
認識できていれば、解決に向けて動けるので、隙間を埋めることができる。

生産性を高める

全ては集中から始まる

集中

意識が１点に集まること。
現実世界では注意を逸らすものが多く、日常生活で集中状態は出現しない。

集中している時間を増やす

集中状態にコツ
  • 一つの作業に専念する
  • 最初の苦痛に耐える

上記をこなすと、知らない内にゾーン*1に入る。 入るには、無理矢理、自分がそのことだけを考えるように仕向ける。

自分自身に対して責任を取る

責任の大切さ

会社に出社するのは、雇用主に対する責任のため。
責任の自覚が薄い環境　→　怠ける。人間の性なのでしょうがない。

監視している人がいない時に生産性を向上させるには、自分に対する責任感を育てることが重要。
つまり、品位・高潔さが必要になる。
(騎士であれってこと？？)

品位と高潔さを持たない場合、外的要因に左右されることになる。
責任感がある人間とは、自制心を持っている。

燃え尽き症候群の治し方

燃え尽き症候群に陥る仕組み

新しいもの　→　最初は熱狂するが、時間とともに冷める
(一時プリキュア熱が強かったけど、時間とともに冷めて閉まったのと同じかッ？)

冷めるのは自然のサイクル
一生懸命にやればやるほど、燃え尽きるペースが早くなる。
(密閉空間の焔と同じ。強く激しく燃えれば、自身が出した二酸化炭素で早く消える。)

生産性が高くなる　→　生産性の向上が鈍化するので、生産的ではないように感じる。

実際には単に壁にぶつかっているだけ

燃え尽きる　≠　終わり
本当は壁にあたっているだけ。
それを超えると大きな成果になる。

その壁の向こう側

壁を超える　→　人が少なく、競争がゆるい。
だから、燃え尽きても無視してやり続けることが重要。
(なぜだろう、アイマスを思い浮かべてしまう。)

壁を推して通り抜ける

壁は、押し続ければ抜けられる。
忍耐と同じことをやり続ける地味さが必要。
(押し通る！邪魔するな！アシタカ風)

時間浪費のメカニズム

もっとも大きな時間の浪費

テレビを見ること。
何も得られなければ、無駄である。
(無駄無駄無駄無駄！！)

テレビの問題点

  • 時間の浪費
  • お金の浪費
  • マインドコントロール

テレビ以外の浪費

  • SNS
  • ニュースサイト
  • 会議
  • 料理
  • ゲーム

全部無駄とは言わないが、浪費していると感じたら、見直したほうがいい。

習慣を持つこと

習慣が人を作る

目標のための習慣　→　目標達成しやすくなる
無意識に何かすることが習慣になれば、その道のプロになれる。

習慣の作り方

目標を決めて時間を捻出し、毎日続ける。
それだけ。

習慣にこだわりすぎない

習慣は、守れないこともある。
守れない時は無理にするのではなく、代償行為等で冷静に対処する。
そうしないと、やっかいな人間になるか、人間性が壊れる。

悪い習慣に気づいて変える

悪い習慣を見つけたら、発動条件と達成の褒美が何かを考える。
代価の習慣を考えて切替を行っていく。

ハードワーク

ハードワークがクソなワケ

ハードワークには、苦になる作業とならない作業がある。
仕事　→　辛い
遊び　→　楽しい

ハードワークを楽しむ輩がたまにいるが、やりたいとは思わないハズ。
何かメリットがあるからやる。
利益のない仕事は、簡単。

さぁ、賢く働こう

賢い仕事はハードワークよりもいい結果が得られるわけではない。
成功するためには、一定の頑張りと忍耐が必要になる。

ハードワークは退屈だ

ハードワークから逃げるのは、退屈で人権が認められないから。
ハードワーク　＝　難しい作業　＝　誰もやらない
やり遂げる人　→　楽な方に逃げる人よりは優秀
(そうだと信じたい！)

現実：簡単なものなどない

本物の成功を手に入れたいなら、ハードワークをするしかない。
ハードワークで得た仕事の仕方という種は、ゆっくり育ち、ある時期に収穫することができる。
蒔いてもいない種は、育ちもしないし、収穫もできない。
※ずっと楽できない意味ではない。成功ができないという意味。

成功は、次の成功の呼び水になる。
ただ、最初に成功する道のりが険しいだけ。
凡人は、回り道をして成功しようとするが、そんな道はどこにもないので、そのまま終わる。

どんなことでも、しないよりした方がマシ

なぜ行動することを拒否するのか

行動しないためにチャンスが消えることはよくある。
多くの人が行動しないのは、怖いから。
間違うこと、壊してしまうこと、合否を突き付けられることの全てが怖い。
(日本人は、嫌われることの恐怖がハンパない気がする。村八分とかあるし)

恐怖に縛られないでいることが、チャンスを掴むためには重要
最良の行動でなくても、何もしないがデフォルト選択にならないようにしなければいけない。

起き得る最悪のことは何か

正しい行動　→　何度か間違えたからこそできる
行動を起こすのが遅いと、正しい道を見つけるまで時間が掛かる。

選ばないことを選び、行動を先延ばしすると最悪の結果が出る。
(俺は誰も選ばない・特別扱いしなかったがゆえに独身なのだ)

動く車のハンドルは切りやすい

行動しない　＝　止まっている車
方向が間違っても、ハンドルは重くて切れない。

行動する　＝　動いている車
方向が間違っていても、ハンドルは切りやすい。

方向の間違いは、進んでみないと分からない。
間違うコストが低いなら、何かすることを選んだほうがいい。

お金に強くなろう

給料はどのように運用するか

目先のことだけを考えるな

目の前の金でやれることを考える　→　稼げば稼ぐほど使う。
財力通りか、それ以上の事をしてしまうので、高給取りでも貧困になる。

資産と負債

資産　→　維持費　＜　利用価値
負債　→　維持費　＞　利用価値

給料だけでは

収入が増えることは金持ちではない。
億万長者になるためには、お金を生み出す資産へ投資する必要がある。
貯金しても、貯金したお金の働かせ方を知らなければ、金銭面で成功はできない。 (百万長者という言葉が書いてあった。)
(mirrioearの日本語直訳だろうか？)
(最初見た時は意味が分からなかった。理由を考えたら納得とニヤケ笑いが。。。)
(金に強いかどうか判断するための罠だろうか？)

給与交渉の方法

交渉は、応募する前から始まっている。

給与交渉は、評判に影響される。
ソフトウェア開発者としての名声は、ブランド力と積極的なマーケティングにかかっている。
(たまにブランド力だけの奴がいるのが腹立たしい。１回地獄に落ちてほしいね)

どのようにしてポストを獲得するか

役職に付く　＝　給与に影響する
交渉は、必要性が高いほうが不利になる。
職が欲しいから求人票を見て応募　→　不利な状況から交渉スタート
会社側が欲している　→　交渉は有利に進められる。この状況になるには自己マーケティングするしかない。

数字を先に言ったほうが負け

先に数字を言う　→　交渉では不利になる。
会社側が自分が思っているより低い額を掲示しそうな場合だけ、釘を打つために下限値を先に言う。
先に言ってくれと頼まれても、絶対に答えてはならない。
会社が先に答えられないのは、何か理由があるハズ。
どうしてもいう場合は、広い範囲を言う。
ただし、下限値は許容最低額より高めに設定する。

掲示を受けたとき

必ず数字を見ること。
最終的な掲示で数字がない場合、許諾してはならない。

借金の危険性

借金は悪いことである

借金を抱える　＝　利子分余計に払う
借金より大きな収益を上げるためでなければ、しないほうがいい。
借金は、時間とともに積み上がっていき、負担は重く、金に苦労しない生活から遠ざかる。

金をめぐるバカげたこと

不要な借金　→　してはいけない
(むしろ、するやつなんているのか？)
借金をした場合、高い金利から返済すること。
購入はローンを組まずに購入したほうが得。
なぜなら、利子を払わなくてもいいから。

すべての借金が悪いわけではない

借金　＜　収益　→　借金しても問題はない
利益が見込めない借金が一番不味い。

やっぱり体が大事

なぜ健康でいる必要があるのか

自身

自身があるように見える　＝　才能以上の成功を呼ぶ
健康と自信　→　健康的だと外見がよくなり、自信があるように見える

恐怖心の除去

不健康だと、病気になるリスクを抱える事になる。
手遅れになってからでは遅い。
健康的になり、次世代に繋ぎ、次の世界を長く見守らなければならない。
(死を求めていたが、考え方が少し変わった気がする)
(誰のために生きるか考えていたが、嫁もなくこどももいないためどうすればいいか悩んでいた)
(次の世代に繋ぐことや何かを残すという考えがあるのか)

負けない心を鍛えよう

心と体のつながり

心とは、体にはない部分のこと。
体と心は等価であり、優劣はない。

人生を操作したい場合、心の力・思考方法を使ってコントロールする必要がある。
(キングになりたいと思わなければ、キングにはなれないのだ！)

恋愛と人間関係

ゲームの性質を理解する

恋愛　＝　ゲーム
戦略的に挑む必要がある。
追うだけでは、相手は逃げてしまう。

自信を持つことが必要。
３秒ルールを適用して、３秒以内に行動する。
３秒以上の思考停止は、自信がないように見えて、ものごとが上手くいかない。

恋愛は数のゲーム

一人の人に固執する　＝　チャンスが少なくなる
世の中は広いので、受け入れてくれる人は必ずいる。
失敗を恐れず、拒否される事を恐れないことが大切。

失敗に正面からぶつかれ

なぜ失敗を恐れるのか

失敗　＝　本能的に嫌う。先天的なもの
失敗の恐怖　＝　壊れやすい心を保つためには必要

失敗することは、孤島に送られるイメージに近い。
助けてもらえる希望が無く、抑圧される感覚が失敗することに近い。

失敗は敗北ではない

失敗　→　一時的なもの
敗北　→　ずっと続く
(敗北したキングは、元キングとずっと言われる！)
(敗北を取り戻すためには、もとの位置まで這い上がる必要があり、最初の通った道より険しい)

成功するためには、何回か失敗する必要があることを覚えておく。
失敗を恐すぎると、成功がやってこない。

読み終えて

感想

たまに違和感を感じることが章があったが、それは文化的な違いだろうか？
文化的な違いを意識して読む必要がある。
あと、きちんと腹に落とし込んでやるまで、読み返したほうがいいと感じた。
いろいろな考えに触れたが、結構納得行くことが多い。
欧米や北欧のソフトウェア開発は進んでいる気がするが、そうでもないかとも感じた。

読むのに結構時間がかかった。
読書スピードが落ちたのだろうか？
読み返すことも結構あったのが、気にかかった。
ブログや自己マーケティングの方法は、結構参考になった。
自分が最近やり始めたことだからかも知れないが。

社内でプレゼンは良くするので、学習方法については概ね同意できた。
やはり、そとへのアピールは必須だと感じた。
いずれ、ユーザグループには公演したいものだ。

参考資料と合わせて読みたい本

人を動かす

人を動かす 文庫版

人を動かす 文庫版

まだ未読。
持ってはいるけど、まだ読んでない。
リーダー的立ち位置になったので、早めに読んで人心掌握の術を掴みたい

CODE COMPLETE 上下

Code Complete 第2版 上　完全なプログラミングを目指して

Code Complete 第2版 上　完全なプログラミングを目指して

Code Complete 第2版 下　完全なプログラミングを目指して

Code Complete 第2版 下　完全なプログラミングを目指して

読了済み。
古い本だが、やり方は今でも通じる。
若干読みづらく、腹に落としにくいが、効果的な手法が多く載っているので、時間を欠けて読み解くのをオススメする。

Clean Coder

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

未読。
プログラミングに関する書籍は結構読んだので、もういいかと思う気持ちが強い。

Head First デザインパターン

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

読了済み。
一番最初に買ったデザインパターン本。
読むだけだと理解しづらい。必ずコーディングして試すことが必須。

金持ち父さん貧乏父さん

金持ち父さん貧乏父さん

金持ち父さん貧乏父さん

未読。
金の考え方はソフトウェア開発者にとって大事だと思ったので、なるべく早めに読みたい。

バカの壁

バカの壁 (新潮新書)

バカの壁 (新潮新書)

読了済み。
学習方法や考え方の発展的な内容がこの本に書いてあった。
SOFT SKILLSを読み終えた人は、この本を読んで欲しい。
たぶん、考え方や学習に対する考え方が大きく変わるハズ！

*1:余計な思考感情が全てなくなりプレイに没頭する。ただの集中を超えた極限の集中状態。選手の持っている力を最大限引出す事ができる反面、トップアスリートでも偶発的にしか経験できない稀有な減少である。練習に練習を重ねたものだけが、その扉の前に立つことを許され、それでもおな、気まぐれにしか開くことはない。それは選ばれたモノしか入れない究極の領域 By 黒子のバスケ

管理職にコードの問題点を伝えても伝わっていない件

チーム プログラミング

背景

新規プロジェクト開発に携わることになった。
何回かフェーズが別れており、段階的に開発する流れになっていた。
自分は第二フェーズから参加。
第一フェーズのコードを見たが、いろいろ不味いスパゲッティを作っており、指摘をした。
その結果、伝わっていなかったことが周囲の人から聴いて知った。

詳細

管理職との関係

ほとんど面識がない。
管理職は顧客に近いとこにいるため、作業場所が違っている。
顔は何度か合わせたことがあるけど、ほとんど覚えていない。
そのため、指摘は対面ではなく、メールベースでの指摘となってしまった。

知った経緯

歓迎会があり、管理職の近くにいる開発者から状況を教えてもらった。
一部の開発者からは絶賛されたけど、管理職に近い開発者からは全然理解を得られていなかった。

なぜなのか

簡単に言うと技術力の差。
理解ができていない管理職付近にいる開発者に話を聴いたが、どこがどう問題になるのか理解できていなかったらしい。
※管理職も含めて

自分は、文章で理論的に話したが、それが不味いという指摘を得た。
実際にどうなるのか想像ができていないため、指摘したことをやり続けることで、物理的にどういう問題になるのか分からないらしい。
つまり、内部的な構造は目に入っておらず、最終的なアウトプットが正しければ、内部構造はどうでもいいとういうことだ。

それは、不味い

内部構造を理解してないのは、非常に不味い。
カオスの予兆が分からないということだから。。。
その人の経歴を聴いたが、どうやら管理専門で教育を受けて今の立場にいるらしい。

管理職だからでは済まされない

「管理職だから内部構造を理解しなくてもいい」という理由にはならないと、自分は思うのです。
管理職でも、一定の開発スキルは必要だと思います。
なぜなら、改善はコードに対してするため、コーディングに対する知識がないと、改善が行えないから。
そして、今のコードの状況がわからないため、開発者に対して高負荷を意図せずにかける事態になる気がします。
そして、プロジェクトは炎上し、なぜなぜ分析をするのだが、そもそも自分に原因がない前提で分析するので、分析にならないことがある。
真因が求められない結果、開発者にしわ寄せが行って、「ダメだなコイツは」って考えになる。
そういった事を数度受けたことがあるので、どこの現場でもよくあることな気がしてならない。

開発者あがりの管理職が一番

管理職といえど、やっぱり開発スキルは最低限必要だと思いました。
説明能力がない自分にも問題あると思いましたが、自分が全て悪い気がしません！

最低でも原理・原則の基礎知識が欲しいと思いました。
実践はできずとも、理解はあることが重要だと思います。

そういう点では、開発者あがりの管理職は、結構強みがあるのではないかと感じました。
コーディングに理解があり、開発者との意思疎通ができて、それを顧客に説明できるので、強みだと思いました。

頼むから勉強してくれ

管理職も大変でしょうが、プログラミング理論・原理について一定の理解・勉強はして欲しいと感じました。
あと、開発者だけに勉強を強いている管理職をよく見ますが、それってどうなのと思います。
他人に強いる前に、自分がどうあるべきがちゃんと示してこそ、言葉に重みが出ると思うのです。

思うこと

自分が管理職ではないので、アンチ的な立ち位置で批判してしまいましたが、管理職が大きなプレッシャーと戦っている点は理解しているつもりです。
最終的に責任を取らなければいけない立場ですし、責任の重さは計り知れないと思います。
ですが、少し開発者の立場によって欲しいという思いがあります。
どうも、「お客様は神様です」思考が強すぎで、開発者軽視になっている気がしてならない。
開発者も悪いものを作ろうとしてやっているわけではないので、一定の理解が欲しいのです。

寄り添う努力を、もうちょっとしてくれてもいいのではないかと思う今日このごろです。。。

ブログ分けました

テクニカルとサブカル

テクニカル系のブログとサブカル系のブログに分けました。
このブログは、本来やりたかったテクニカル系のブログにします。
サブカル系の記事がみたいよ～って人は下記リンクのブログを見るようにしてもらえればと

エンターテイメント！！／サブカル

分けた理由

さっき書いたように、本来やりたかったテクニカル系のブログに専念するため。
ただし、息抜きも必要なので、サブカル系のブログに分ける。

あと、サブカル系の記事はPVがもの凄くて、調子乗っていっぱい書いちゃったから、本来やりたかったことのノイズになるので分けた。
ブログ見返す時に結構ノイズになったりするってのが大きな理由ですかね。

ブログの使い方は、ノートに近い事をしている。
現場で、ふとド忘れしたこととかを調べたいときに、即効でアクセスできるので、時短にもなるから助かっている。
エンジニアの人は、なるべくブログ書いたほうがいいと思います。

JJUGナイトセミナー Javaフレームワーク特集 感想

FW プログラミング

参加背景

Spring Boot以外はよく知らないので、知識領域を広げるために参加。

概要

【東京】JJUGナイトセミナー Javaフレームワーク特集 - WildFly Swarm / Play Framework / Spring Boot - 日本Javaユーザーグループ | Doorkeeper

日時

2016/06/27 19:00-21:00

場所

日本オラクル株式会社 本社 13階

内容

WildFly Swarm - Rightsize Your Java EE Apps

www.slideshare.net

WildFly

  • Java EE7に準拠したAPサーバ
  • モジュールクラスローダー採用

WildFly Swarm

WildFlyをSpring Bootっぽく利用できる。
SpringBootとの差異は、依存性の解決、設定、起動、デプロイをすべてmain()でできるようにしているところ

Arquillian

テストのためのライブラリ。
Mockを使わず、すべて本番相当の状態でテストできる。

The High Velocity Web Framework For Java and Scala

Play Frameworkの紹介。
Playは、WEBフレームワークで、Javaのフレームワークではない。

Frameworkは登場の背景とかを知ってないと間違ったところに適応されることがある

↑の言葉で、FWの歴史を知る重要性に気づけた気がする。

Play1

Java停滞期に作成された。
Javaの非合理な慣習や機能不足をなんとかしたかったから作成された。
Javaに対するアンチテーゼがことの発端。
そのため、Javaに拘らない独特な実装が多い。

  • groovy テンプレート
  • 起動高速化のために、コンソールはPythonを使用
  • 思い切ったクラス名(Java,java、F.java)
  • 例外を継承した戻り値

Play2

FWの世代交代(Strutsからの脱却期)に作成される。
Scalaで全面的に書き直しされた。

特徴

  • Servlet非依存
  • ホットリロード
  • Akkaを統合し、リアクティブプログラミング可能に

こんご、積極的にAkkaに置き換わっていくかも。

From Zero to Hero with REST and OAuth2

www.slideshare.net

SpringBootによるOAuth2のライブコーディング？(ほとんどコピペだった気が・・・)
SpringBoogの詳しい紹介は基本なし。
サラッと説明してライブコーディングに移った。

感想

SpringBootは知っていたので、特に不満はない。
FWは、紹介されてもメリットが分かりづらいから、実際に使ってフィードバックを得る行動をすべきだと感じた。
あとは、なぜこのFWが出来たのか、歴史背景を知ることがFWの理解を速めることだと思いました。

雑記

7/11のナイトセミナーが即効で埋まったのが悔やまれる。。。
かなり聞きたい。
キャンセル待ち行列に並んだけど、聞ける気がしない。
今回はライブ配信していたらしいので、7/11もライブ配信してくれると嬉しいな☆ミ

【書評】プリンシプル・オブ・プログラミング

書評

プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

読むに至った背景

パラパラ捲って見たが、既知の内容を幅広く集約しているようだった。
既に読了済みの本の内容を多くまとめている感じがしていて、買うか迷ったが、複数の本と合わせて読むことが一冊である程度できるので購入。
目的としては、いろいろ読んだ本の知識を、個の本を読むことで繋いで知識を体系化したい。

内容と考察

内容＋個人の考えを載せている。
この記事＝本の内容ではないので、注意

前提

プログラミング・ソフトウェア開発には、変わらない真実がある。 真実を見たい場合、真実の扉の先に行かなければならない。
扉の向こうに行くには、通行料として、長時間の苦痛・苦悩が必要になる。

真理を by ハラグロハイイロクマ on pixiv

プログラミングに銀の弾丸はない

プログラミングに特効薬はない。
これを使えば、どんな問題も解決できるものはない。
なぜなら、ソフトウェアは本質的に複雑であるため。(人間関係と一緒)
問題にぶち当たったら、歴史から戦う術を探してみる。

コードは設計書である

ソフトウェアにおける設計＝基本設計・要件定義～デバッグ
プログラミングは設計。
エンジニアが作ったコードは、ハードウェアの設計図に該当する。
(今の日本じゃ、プログラマ軽視だから、こういった考えは出ない気がする。)

改善の対称となるのは、コード。
改善を加えるのは、設計ではなくコードで、コードを直す必要がある。
そのためには、優秀な設計者(プログラマ)が必要。
プログラミングとは、仕様のコード化ではない。仕様を改善する作業を含んでいる。
(前者の考えは、ただのワーカー。プログラマ軽視はここから来ている気がしてならない。)

コードは必ず変更される

コードは修正されるもの。
一度書いて終わりということは、ほぼない。 なので、変更されることを想定してプログラミングする必要がある。

コード = 書いているより、読むことのほうが長く時間を使う。
書くのに時間をかけても、読みやすいモノを作るほうがいい。
長い期間で見ると十分に元が取れる。

原則

プログラミングのガイドライン

シンプルにしておけ、このバカ野郎！！

コーディングで大事なもの = シンプルさ
追求しないと、無秩序→複雑→カオスのコンボが炸裂する！
複雑なコードは、修正しにくくバグを量産し、コードを腐らせる。(「コイツ、腐ってやがる！」ってクロトワ以外からも言われる)
常にシンプルな状態を保つ事を心がける。
シンプルに保つためには、以下の事に注意する。

  1. 新しく覚えた技術を使いたい！
  2. 将来の必要に備えたい
  3. 勝手に要件を加える

欲望を捨てて、プログラミングすることが重要。 「大きいことは、よいことだ」って言っているCMがあったらしいが、あれは大間違いだ、バカヤロー(たけし風)

DRY ~ 繰り返すな

コードのコピペ厳禁！
コードの改善が困難かする可能性大

コードの抽象化を行い、重複の削除をなくす。
抽象化は、長い目で見ると有利だが、デグレードのリスクを梱包することになるので注意

DRYのプログラミングスタイル

やり方だけに注目せず、目的を意識すること！

やむをえないDRY違反

抽象化スタイルの違いから来るもの。
抽象化が違うものを一緒にする → 変更箇所の修正で思わぬ影響が出る

YAGNI ~ それは、きっと必要ない

コードは必要最低限

ソフトウェアの変化予測 = 不可能
必要なコードだけを書くようにする

コードの予測は外れる

汎用的なコード　→　利用されないことが多い 無制限な汎用性の追求　→　不毛 使われない機能　→　なぜ使われないかの存在理由不明で、消そうにも消せない

コードは今必要なものだけ

汎用性 < 利便性・単純性
使えること、シンプルであることが重要
過度の汎用性は、修正し難くなる

PIE ~ 意図を表現してプログラミングせよ

コード　→　人が読むもの
コンパイラが読むものではない。

文芸的プログラミングを行い、コードをドキュメントのように書く。
(たまに、区分名で命名する奴がいるが、頭のイカれた理数系な気がしてならない？)

コメントは書く

コメントは、ないのが理想だが、現実問題として難しい。
コメントには、Why(なぜ)の部分を書くように心がける。
なるべく、コメントを書かなくてもよい実装を行い、足りない部分をコメントで書く。

文芸的プログラミングのメリット

  • ドキュメントを別途書かなくていい。コードに語らせる。
  • コードと説明が近くなるので、修正しやすくなる
  • コメントの質が上がる

SLAP ~ 抽象化レベルの統一

コードのレベルを合わせる

抽象レベルが揃う　＝　コードの質が上がる。
閲覧性が格段に上がる。

コードに閲覧性と要約性をもたらす

抽象度によって処理をまとめる　→　要約された処理ができる。
抽象度が合わない　→　読み手に負荷がかかる。

OCP ~ オープンクローズドの原則

コードの変更を波及させない

拡張に対して開いている　→　振る舞いを増やせる 修正に対して閉じている　→　拡張した内容が他に影響しない

コードの柔軟化

OCPを実現することで、変化に強いソフトウェアが作れる。
ソフトウェアは、変更されやすいものなので。。。

ただし、過度な適用はやめるべき。
やり過ぎると複雑化する。
変化を予測して適用させる。

名前重要

以下の記事でも言及したので、興味ある人は見てみて！

suzaku-tec.hatenadiary.jp

コードで命名は最重要課題

  • 命名
    要素が正しく理解された。
    ふさわしくない名前　→　設計がおかしい。
  • 名前
    プログラマ同士が会話する上で必須。円滑な開発には、名前に配慮すべき。

コードを読む人への配慮

名前は、コードを読む人へのUI
適切な命名は、意図が明確に伝わる。

わかりやすい名前のメリット

  • 処理内容が把握しやすい
  • 名前に導かれて実装できる
  • 実装が説明的になる(文芸的プログラミング)

わかりにくい名前のデメリット

  • 処理内容を知るために、細部に目を配る必要がある。
    →　読むことを強いられているんだ！！
  • コーディング時、使用していい関数か判断に迷う
  • 実装が支離滅裂で分かりにくくなる。

コーディングは名前から

常に使う側、読む側の視点に立つ。 命名で注意すべきこと

  • 名前に情報を詰める
  • 誤解されない名前にする
  • 名前に効果と目的を持たせる
  • 発音できるものにする
  • 検索可能なものにする(英字１字とかは辞める)

(キラキラネームは、意味を込めてないから、辞めるべきだと思うんですよね～)

メンタルマッピング回避

メンタルマッピング = 記憶とイメージの変換
多くなると読み手の負荷が大きくなる。
一般的なモノを使い、特殊な用途の言葉をなるべく避ける。

ループバックチェック

名前を付けたら、名前を元に説明が行えるか確認する。
名前を元に説明できる　＝　正しく命名できている。

思想

プログラミングセオリー

変更に強くシンプルなコードを書くことに価値観を置く。
価値観は原則を通じてコードに適用する。
やることの価値がわからないと無意味

コミュニケーション

コード　＝　コミュニケーションの場
コードとは、ドキュメントである。
コードにおいて、読んだ人が内容を理解し修正することができる　＝　コミュニケーション良好
常にコードを読む側の視点に立つことが重要。

シンプル

コードの複雑は排除する。
目的達成のための複雑性は、仕方ないので許容する。

コードの複雑性

今後の開発の禍根になる
余分な複雑さ　→　価値はない

コードの玉石を仕分ける

コードをシンプルに保つ　＝　玉石を選別する
シンプル過ぎると情報が少なすぎて分かりにくくなる。

柔軟性

コードの変更が容易であること コードは必ず変更される。
コードの拡張性を上げておく必要がある。
柔軟性のための複雑さは、許容してはならない。
柔軟性　＜　シンプル
トップダウンでの柔軟性　→　見当違いが多い
ボトムアップでの柔軟性　→　細部からのフィードバックであるため、的確

マイクロサービスの由縁はここからかな？
計画ばかり先行するとダメになるのは、柔軟性の重視から発展したマイクロサービスにも同様の習性がある。
トップダウンではなく、TDD駆動・DDD駆動で開発して、ボトムアップで問題上げて解決すると、マイクロサービスになる気がしました。

結果の局所化

変更の影響を抑えること。
そうすることで修正と確認を容易化できる。
結果が局所化されていない　→　変更がいろんなところに発生する
結果が局所化されている　→　影響範囲が狭く、修正が楽

実行するには、関係が濃密なコードをまとめておくといい。
お互いの呼出し回数が多い　＝　本来まとまっているべき処理が分散されている可能性がある。

繰り返しの最小化

重複は削除する。
そうすることで、修正の影響を局所化できる。
繰り返しは、結果の局所化を侵害する。
コピペによる同一コード生成　＝　ロジック変更があった場合に他の箇所は必要か判断しなければならない。
つまり、「一括置換でOK！」とは言えない。
コードを分割して管理することで、重複を排除しやすくなる。

対称性

コードに一貫性を持たせる。
そうすることで、類推できるようになり、抽象度の均等化、重複の排除が行い易くなる。
同じことをする場合、なるべく同じ表現を使うようにするのがミソ

宣言型の表現

宣言型プログラミングをして、コードの意図を伝える。
命令形　→　問題の解法
宣言型　→　問題の定義　＝　問題の性質・制約が伝わる

フローがないので、読みやすくなる。

変更頻度

変更理由でグルーピングする。
そうすることで、変更範囲が狭まり、修正しやすくなる。
変更箇所が複数ある　→　関連の強いコードが分散している
変更箇所が少ない　→　関連性の高いコードが集約している。堅牢なコード。

アーキテクチャ根底技法

良いコードには「型（流派）」がある。(俺は、流派：東方不敗！！)

抽象化

概念的線引をすること。
捨象と一般化の観点をもとにまとめる。 捨象　→　性質から本質的要素を選別すること。本質を見つけやすくなる。
一般化　→　具体的対象から共通の性質を抜き出す。共通項のグルーピングをする。

カプセル化

データとロジックのグルーピング

情報隠蔽

必要ないものは見せない。
使用者が不正な操作をしないように、公開範囲は最小にする。
そうすることで、関連がシンプル化する。

カプセル化と情報隠蔽の違い

カプセル化　→　関連する要素を集めてモジュール化すること
情報隠蔽　→　内部へのアクセスを遮断する

パッケージ化

モジュールのグルーピング。
意味のある単位にまとめる。または、分割すること。
そうすることで、モジュール郡の複雑度を下げる。

関心の分離

関心事毎に、機能や目的を分離する。　→　独立したモジュールになる。
また、関心事毎に変更はやってくるので、影響範囲が狭く、修正が行い易くなる。

インタフェースと実装の分離

  • インタフェース
    モジュールの機能を定義して、モジュールの使用方法を決めるのが役割
  • 実装
    モジュールの機能を実現する。ロジックとデータを持つ。

参照の一点性

定義は一度だけ行う。　＝　初期化は一回だけ。
そうすることで、副作用のないプログラミング(不動のプログラミング)ができる！
副作用を抑えることで、状況依存の生涯が減り、コードの見通しが良くなる。

分割統治

大きな問題を小さく割る。
そうすることで、大きなままでは制御不能な問題を取り扱い易くする。

つまり、小さくして各個撃破！
兵法三十六計：混戦計：仮道伐虢

アーキテクチャの機能要件

「機能以外の機能」の観点
ソフトウェアの付加価値について高めることがアーキテクチャの仕事
なぜなら、非機能要件はリリース後の影響が大きいから。

セキュリティ非機能要件

書いてあることは、それほどでもない。
過去にまとめた情報セキュリティ試験の最初の方のことが書いてあった程度。

suzaku-tec.hatenadiary.jp

変更容易性

コードの変更を容易にする能力。
ソフトウェアは、どれだけ容易に改善できるかが超重要。
なぜなら、ソフトウェアの寿命は長く、最初のリリースで終わることはほぼない。
そのため、絶え間なく変化にさらされるので、変化に強くしなければいけない。

相互運用性

他のソフトウェアと会話する能力。
なぜ必要となるかというと、ソフトウェアは連携してシステムを構成することが多いから。
連携がしやすい　＝　資産を活かせる

効率性

リソースを上手く使う能力。
なぜ必要かというと、リソースは限られており、いかに上手く使うかがソフトウェアの価値であるため。

信頼性

機能を維持する能力。
信頼性を上げるやり方はいくつかある。

テスト容易性

効率的にテストする能力。
早く、安くテストできる　＝　質が高いテスト（牛丼と似ている！！）
テストの品質　＝　本体の品質
テストをしやすくすることで、ソフトウェアの品質を高めることができる。

再利用性

再利用する／される能力
重視される理由は、できるだけ「作らない」ことで開発効率を上げたいから。
ただし、再利用可能なモジュールは、一般的なモジュール開発の３倍難しい。　→　一般的な問題も想定する必要があるので、複雑度が増しやすい。

７つの設計原理

  1. 単純原理
  2. 同型原理
  3. 対称原理
  4. 階層原理
  5. 透明原理
  6. 明証原理
  7. 安全原理
  8. 線形原理

レビューする場合、上記内容に気をつける。

単純原理

シンプルにこだわる。
なぜなら、複雑なところにバグはでるから。
なるべく、自然なコードにこだわる。

同型原理

形にこだわる。同じものは同じ表現を使う。
そうしないと、異物は目立たないため、レビューでバグが見つけづらくなる。
一貫性あるコードを書く。

対象原理

形の対称性にこだわる。 そうすることで、読むときに予測を立てることができる。

階層原理

階層にこだわる。
なぜなら、階層構造は読めやすいから。

線形原理

処理の流れは、線形にこだわる。
一直線の原理は読み易く、バグを解消しやすい。
なるべく分岐の少ないコードを書くように心がける。

明証原理

ロジックの証明にこだわる。
見ただけで正しさが分かるようにする。
そうすることで、不確実性を取り除き、明瞭なコードを書く。

安全原理

安全性にこだわる。
つまり、曖昧な箇所は、ありえない条件を考慮して、安全に働くようにする。
そうすることで、大事故への発展を防ぐ。

UNIX思想

UNIXの停留にある暗黙知を利用する。
なぜなら、UNIX設計は実践から得た「技」の集合体であり、覚えることで設計の正しさを覚えられる。

モジュール化の原理

控えめなモジュールを作る。
ソフトウェアは、複雑であるため、なるべくシンプルに作ることを心がける。
そうすることで、モジュールの関係が簡素になる。

  • シンプルなモジュール：他モジュールへの依存が少ない
  • 複雑さを減らす　＝　プログラミングの真髄

メリットが多いので、モジュールの入り口を狭める事を心がけるようにする

明確性の原理

巧妙な作りはやめて、コードを明確にする。
そうすることで、障害が発生し難くなり、改修しやすくなる。

組み立て部品の原理

フィルタとして作り、ソフトウェア同士を組み合わせることができるようにする。
そうすることで、相互接続で相乗効果で価値の創出ができるようになる。

分離の原則

メカニズムからポリシーを話す。

  • ポリシー：ソフトウェアの前提に依存する部分
  • メカニズム：前提に依存しない独立した部分

メカニズムは安定しており、ポリシーは不安定している。
ポリシーの変更はやりにくく、ポリシーの変更はメカニズムの変更になるため。
ポリシーを分離して改善を行い易くする。

単純性の原理

コードはシンプルにする。
なぜなら、コードは自然発生的に複雑になるため。
シンプルさをチームの価値観の絶対文化にするように心がける。

倹約の原則

大きなコードは書かない。
なぜなら、大きなコードは制御不能であるため。
コードの継ぎ足しは、避けるようにする。

透明性の原理

ソフトウェア動作は見える化する。
そうすることで、デバッグに貢献する。

  • 透明性：一見見て内容を理解する
  • 開示性：内部の状態を監視・表現できるようにする。(カイジ性ではない。ギャンブル性は排除する)

安全性の原則

ソフトウェアを安定させる。
予想外の条件下でも、適切に動作させることで、堅牢にさせる。
考慮し過ぎると複雑になるので、なるべくシンプルにする。
ソフトウェアは堅牢な作りを心がける。

表現性の原理

情報はデータに寄せて表現する。
なぜなら、データはロジックより制御しやすいから。

驚きの最小原則

予想通りのインタフェースを作る。
そうすることで、学習コストが低くなる。
ユーザの既知を利用することが、学習コストを下げる。

沈黙の原則

ソフトウェアは寡黙にする。
エラーでいちいち指摘してくるソフトウェア　＝　使いにくい。
寡黙に作ることで、大事なことが伝わりやすくなる。
出力が多いと、情報過多で見逃しやすくなる。
ユーザの注意力・集中力は大事なリソースなので、情報の出力は多用すべきではない。 なので、重要な情報のみ出力する。

修復の原則

修復失敗時は、処理を停止する。
なぜなら、エラー時の継続続行は被害が拡大するから。
後手に回ると、被害は雪だるま式に大きくなる。
エラー通知は、「けたたましく」

経済性の原則

プログラマの時間は大切にする。
プログラマの時間の浪費が、目先の経費より高く付くことが多い。

時間浪費の原因

  • ハードウェアが貧弱
  • ソフトウェアに対する制限
  • 環境へのルール・制限

生成の原則

「コードを書く」コードを書く。
手作業はなるべく避けて、無理に全てを対象としない。
そうすることで、安価で高品質なコードを生成することがでできる。

最適化の原則

早いコードより正しいコードを作る。
なぜなら、早い段階での「速いコード」は、設計を破綻させる。
最適化にこだわると、いくつか問題点が出てくる。

  • 透明性や単純性の損失
  • 部分的最適化≠全体の最適化

正しくしてから早くすることを心がける。

多様性の原理

選択の多様性を受容することで、よりよいやり方を模索する。
多様性を失くす　→　思考停止に繋がり、危険！
人一人のの想像力には限界があるので、多様性は積極的に受け入れる。

拡張性の原理

拡張できるように設計しておく。
なぜなら、ソフトウェアは成長しなければいけないから。

小は美なり

小さいソフトウェアは美しい。
なぜなら、小さいソフトウェアは扱いやすから。

  • 理解が簡単
  • 保守が容易
  • マシンリソースが節約できる

１つ１仕事

1つのソフトウェアは、１つの仕事をする。
そうすることで、ソフトウェアが純粋になり、再利用しやすくなる。

即効プロトタイプ

できるだけ早くプロトタイプを入手する。
なぜなら、試行錯誤なしではよいものは作れないため。

効率性より移植性

効率性よりも移植性を重視することで、ソフトウェアの価値を持続させる。
ハードウェアによったソフトウェアは、移植性が低く、ハードウェアの優位性に依存する。
移植性を高く作ることで、ハードの優劣が致命傷にならないようになり、価値を持続させやすい。

データはテキスト

バイナリファイルよりテキストファイルを優先する。
なぜなら、テキストファイルは万能で、移植性が高く、人が見やすい。
ツールやコマンドで処理することも容易である。

レバレッジ・ソフトウェア

ソフトウェアの梃子で力を増幅させる。

  • 力点：ソフトウェア
  • 支点：ユーザ
  • 作用点：操作結果

ソフトウェアを複数・ユーザの近くで動作させることで、結果が多くなる。
少ない労力で巨大な成果を得ることが重要。　→　手作業を自動化させる。

シェルスクリプト活用

シェルスクリプトで接着する。
そうすることで、梃子の効果が増幅する。
普段使っている言語を使ってのスクリプト　→　移植性が悪い
特別な理由がなければ、コマンドラインで事足りる。

対話インタフェース回避

拘束的ユーザインタフェースは避ける。(SMプレイはらめぇぇぇ！！)

対話型の問題点

  • ソフトウェア固有の使い方を覚える必要がある
  • 連携がしにくい
  • 待ち時間の増加
  • 字句解析による入力チェックによるコード量の肥大化
  • ソフトウェアの機能過多

フィルタ化

ソフトウェアは、フィルタとして設計する。
なぜなら、ソフトウェアは入出力であるため。

UNIX哲学

ただの格言集

環境カスタマイズ

使いやすいようにアレンジする。

小文字使用

識別しやすく読みやすい。

森林保護

紙は編集できないので使いにくい。
(日本の企業って紙で資料欲しがるけど、なぜなのだろう？
エコエコうるせぇのに、こういったところで矛盾を感じる。)

沈黙は金

表示は極力控える。
無意味なデータは見せないほうが見やすいから。

日本はあまりできてないことが多い。
繁華街を見て育ったせいか、ごちゃごちゃしているところに風情を感じる特徴がある気がする。
ただ、それは現実世界であって、ディスプレイで見るとすごく汚い。 付け加えると、会議では発言するほうがいいが、余計なことは言わない方がいい。
あとで背中からナイフで刺される。

並列思考

小さく分割して同時に実行できるようにする。

部品コラボレーション

小さい部品の集合　＞　単体ソフトウェア

90%解

100%上手くやることは困難。
費用対効果を考えて仕事しようね！

劣るが優る

高品質で高価　＜　効率的

階層指向

階層構造は、優れたアプローチ。
単純であるがゆえに強力である。

視点

凝縮度

モジュールは「純粋」に作る。
なぜなら、雑じりっけのあるモジュールは、脆い＆硬いため、変化に対応出来ない。
鉄と一緒。純度の低いものは硬いが、かけやすい。 硬さより柔軟性が、ソフトウェアでは大事。

結合度

モジュール間は「疎遠」にする。
結合が密だと、互いに影響を与えて再利用しにくくなる。

直交性

コードは独立させる。
なぜなら、直行コードは堅牢になるから。
堅牢に作ることで、変化が局所化され生産性が上がり、リスクが軽減できて問題部分の隔離ができるから。

可逆性

戻す・やり直しができることが可能な選択をする。
なぜなら、ソフトウェアに最終決定の権利はないため。
最終決定を下すのは利用者。ソフトウェアは、物事に対応できるようにしておくのが仕事。
ただし、やり過ぎには注意

コードの臭い

コードの凶兆・問題点は見逃さない。
リファクタリングを継続的にすることは、ソフトウェアでは必須。
臭い臭いの傾向を知っておくと良い。

  • よく見る
  • 長過ぎる
  • 大きすぎる
  • 多すぎる
  • 名前が不当

技術的負債

問題コードは「借金」である。
すぐに返済できるなら問題ないが、返済が長引くと利子が付いて返済不可になり、自己破産する。
なるべく、早めに返済を行い、問題コードと上手く付き合う方法を知る。
技術的負債　→　悪循環を生む。
「手抜き」が必要になることもある。
その場合は、借金をコントロールする必要がある。

借金は悪だと考える思考が強すぎるが、逆に考えるんだ。
借金しちゃってもコントロールしていれば問題ないさと。
できればないほうがいいけど、意図せずにしてしまうこともあるので気をつける。

問題コード発生の誘因

  • 経験不足
  • 〆切のプレッシャー
  • 読みにくいコードの存在
  • 特殊化
  • 複雑性
  • 悪い設計

チーム文化による問題コードの誘因

習慣

プログラマの３大美徳

プログラマは「怠慢」「短気」「傲慢」であれ！
ただし、TPOは考える必要があるけどね。

理由

  • 怠慢：労力を減らす手間を惜しまない
  • 短気：効率的に作業してないことに怒りを感じること
  • 傲慢：過剰な自尊心を持つことで、己を強く保つ努力をする

もっと傲慢な日本人は増えて欲しいところ。
※ほんとうに傲慢ならムカつくが。。。
場の空気を読める傲慢な奴は、職人であることが多い気がする。
なんとなしに作業している奴は、なるべく消えて欲しい。

ボーイスカウトの原則

コードは掃除して帰る。
つまり、改善する努力を続けること。そして改善は人任せにしないこと。
そうすることで、コードの腐敗は防止される。
コードは生物で、時間の経過とともに腐敗して品質が下がる。
前よりも少し綺麗な状態にすることで、品質が保たれるようになる。

コードは改良してからコミット

完璧を目指さなくてもいい。
少しの改善をすることが重要。

プログラミングは急がば回れ

最短で時間とコストを稼ぐ　＝　腐敗したコードができる
回り道のほうが、品質が上がる。(相対性理論？？)

パフォーマンスの箴言

「速い」より「よい」コードを作る。
早過ぎる最適化　＝　諸悪の根源（つまり、ドレッド・ルートである！）
速いコードは、「割に合わない」ことが多く、大切な何かを失う。
※速さは何かとのトレードオフで成り立つ

最適化で失うもの

  • 可読性
  • 品質
  • 複雑性
  • 保守の阻害

なるべく正しさを追求した後に最適化を行い、失うものを最小化する。

エゴレス・プログラミング

エゴを捨ててプログラミングしなさい。
自尊心を捨てて「よりよいものを作る」に価値観を置く。
つまり、コードの私物化をやめて、アドバイスを謙虚に受ける姿勢を保つ。

エゴっぽい事をいう人がいたら、「エゴだよ、それは！(アムロ風)」に言ってみると面白いかも。。。

エゴレス・プログラミングの十戎

  1. 自分自身が間違いを犯すことを理解して受け入れる
  2. 書いたコードは専有しない
  3. 上には上がいる
  4. 相談なしにリファクタリングしない
  5. スキルが劣る人にも、尊敬・敬意・忍耐をもって接する
  6. 絶対変わらないものはない事を意識する
  7. 信じるもののために戦い、負けは受け入れる(これを出来ない奴が戦争を続けるのだ！(ガンダム風))
  8. ひきこもらない
  9. 人の批判より、コードの批判

１歩ずつ少しずつ

ステップ・バイ・ステップで物事を進め、複数の事象を相手にしないようにする。
なぜなら、手堅い歩みは効率敵だから。(イソップ童話のウサギとカメ？？)

小さいけど確実な一歩　＝　結果的に品質が上がり、効率的になる。
複数のことを一度にすると、作業が混線して失敗しやすくなる。

TMTOWTDI ~ やり方は、ひとつではない

ツールの多様性は、善。
達成する手段が多い　＝　使う側がシンプルに使える。
使われる方がやり方を複数用意することで、使う側がシンプルに使えるように選択することができる。

手法

曳光弾*1

常に現状を理解して、即時フィードバックできる仕組みを持つ。
そうすることで、暗闇の中でも道筋を照らせる。
つまり、ソフトウェアの意思決定を迅速にできる。
目標と現在の差分を知る手段をもつことが重要。

曳光弾のメリット

  • フィードバックが得られる
  • プログラマが活躍できる舞台が、早めにできる
  • デバックやテストが正確にできる
  • デモ可能なソフトウェアの確保
  • 進捗の明確化

最初に動作する土台を作る

プロトタイプの作成を優先する。

プロトタイプと曳光弾の違い

  • プロトタイプ
    理解を検証する手法
  • 曳光弾
    連携方法の正しさを証明する手法

アプローチは似ているが、目的が違う。

契約による設計

呼出し側と呼び出される側の取り決めを行う。

  • 呼出し側
    事前条件を満たすようにする。
  • 呼び出される側
    事後条件を満たすようにする。

取り決めを決めることで、思い違いを早期に発見する。

防御的プログラミング

「かもしれない」プログラミングを心がけ、不足の事態に備える。
自分の身は、自分で守る事を忘れない。
そうすることで、開発と運用が安全運転できるようになる。

バリケード戦略

バリケードを作り、問題の拡散と侵入を防ぐ。
インタフェースを安全地帯への境界にするとよい。 バリケードの内外で、エラー処理内容を分ける。

ドッグフーディング

ソフトウェアの味見をする。(命名は犬に味見をさせて、死なないか見るため？？動物保護団体から苦情きそうな名前。。。)
開発途中のソフトウェアは、洗練されておらず、マズイ可能性大。
率先して味見して、塩梅を確認することが重要になる。

ラダーダッキング

「説明する」というデバック手法のこと。
説明する行いが、問題解決方法に気づける可能性が高い。
比較的安価でデバックできる。

自己解決を促す

説明する　＝　問題の暗黙的過程を明確にする行い。
間違いに気づき、解決の糸口を見つけられる。

無機物に説明

人に話す前に、人形に対して説明してみる。(ちょっとメンヘラみたい。。。)
そこそこ効果があることが証明されているらしい。
ベストは、現場にいる同僚のエンジニア。
(自分、居ても話しかけられないのですが。。。)

コンテキスト

文脈会話、文脈思考をする。
そうすることで、会話や思考の迷子になることを防ぐ。
文脈ベースの説明は、状況や背景がわかり、利用価値が高い。
そして、思考するツールとして利用できるので、問題解決の作業が良くなる。

コンテキストの伝導力

最初にヒントが有る状態でコードを読むことができるので、可読性が飛躍的に上昇する。
脳は、最初のヒントで処理能力が向上するため、その恩恵が得られる。

チームはハイコンテキスト思考*2で

空気が読める・阿吽の呼吸ができることは、チームとしての最大の強み。

日本人は、それに比重をおくので、チームとして良い状態になることがある。
ただし、重視しすぎたり、リーダーが無能だと足の引っ張り合いが加速する気がする。。。

ハイコンテキストチームの特徴
  • オーバーヘッドが短い
  • 意思疎通が楽で、コストが少ない
  • 新規加入しづらい
    コンテキストが共有されてないので、摩擦が生じやすい。
    ローコンテキストで対応する必要がある。

（日本で村八分という考えがあるのは、ハイコンテキストだからではなかろうか。。。？）

コード共通化はコンテキスト指向で

コード共通化は良いことだが、依存性を内包することになるので、コンテキストを意識して作る。
コンテキストを意識することで、役割を明確化しておく。

プログラマのコンテキストスイッチ*3

プログラマの理想　→　フロー状態(ゾーン)に入ること これは、スポーツ選手だろうが変わらない。

フロー状態は、入りにくく維持しづらい。
割り込みが入ると、簡単に切れる。

マネージャには理解されないもの。
なぜなら、割り込み対応がマネージャーの仕事だから。

プログラマの理想を実現するためには、職場の意識改革や文化改革が必須。
プログラマの時間の重要性を理解することが重要

法則

ブルックスの法則

要因追加は「火に油」。
遅れを取り戻すための要因追加は、遅延の拡大になることが多い。
なぜなら、「人」と「月」は交換不能だから。
たとえば、６人月の作業を６人１ヶ月でやるのと、２人３ヶ月でやるのでは、仕事の効率が違う。

依存関係によるオーバーヘッドが発生するため、単純な後からの増員は、遅れに繋がる。 無条件の増員は避ける。
やる場合は、ユーザと調整して、機能に優先度を付け、リリースを行う。

アジャイルが出来た由縁はここにある気がする。
人月神話については、過去に読んだことがあって、人月に対する考え方が変わった。
一旦どこかでまとめたい。

コンウェイの法則

アーキテクチャは組織に従う。
なぜなら、アーキテクチャは、情報伝達構造に従うため。
組織構造　→　情報伝達構造　→　アーキテクチャ

格式ばった組織は、やたらと設定ファイル好むのは、このせいなのかな？？？

アーキテクチャ設計後に組織編成せよ

組織の都合でできたアーキテクチャ　＝　最適ではない
完成品に悪影響が出ることがある。
早期に作成されたアーキテクチャも、近似解であって正解ではないので、早期の組織編成は止める。
十分に検証した後に組織編成を行う。

それまでの間の組織編成は、変化に強い組織編成を行うことがいい気がする。(個人の感想)

組織とプロセス

相互依存の関係にある。
境界となる箇所を探して、単独の良し悪しで決めることは控える。

以前読んだ、組織パターンに書いてあることが多く引用されていた印象がある。
過去に読んだ内容をまとめた記事があるので、そちらも見ることをススメる。

suzaku-tec.hatenadiary.jp

割れた窓の法則

悪いコードは「蟻の一穴」(ユートォォ！！)

以下、ユートのセリフ引用。

巨大な建物も蟻の一穴から崩れるという。 君には融合という壁に我々が最初にうがつ小さな亀裂になってもらう

つまり、ちょっとした綻びが、全体を崩壊されるものになる。
それは、ソフトウェアも同じである。

悪いコードは邪心を引出す

悪いコードがある　→　適当に作業する心理にさせる

人の反応は、長く弱いストレスに敏感に反応する。
短期の強いストレス　＜　長期の弱いストレス

悪いコードの存在が、さらなる悪いコードの呼び水になり、負の連鎖を誘発する。
（悪いコードは儀式魔法で、負の連鎖は儀式モンスター！！）
結束の硬い組織が、少しの疑念で総崩れすることはよくあること。
歴史がそれを語っている。

コードは清潔に保つ

悪いコード　＝　発見次第、修正する 良いコード　＝　悪いコードが入らないように細心の注意を行う。
そうすることで、邪心の入るスキを失くす。

人は人を真似る

行動を真似る　＝　人の特性
悪いコードの存在は、人の特性を利用して連鎖を起こす。

エントロピーの法則

エントロピーとは、物理学用語で、無秩序の度合いのこと。(まどマギ用語ではないのか！?)
ソフトウェア開発は、エントロピー増大の法則に強く縛られている。
何がいいたいのかと言うと、コードは自然と腐っていくものである。
何もしないと、限界を超えるまで無秩序は増大する。
コード腐敗の兆候を掴み、アジャイル的な対応で腐敗を許さないようにする。
アジャイル的な対応を撮るのには理由がある。
なぜなら、腐敗は流動的なものであるため、目的を固定化して改善しても、対応が終わる頃には状況が変わっていることがある。
イテレーションを回して、継続的に改善することが必要。

80-10-10の法則

プログラミングに万能薬はない。

ユーザの要求
80%は実現可能。残りの20%が問題。
10%は、相当な努力が必要。のこりの10%は、完全に実現が無理。
そのため、プログラミングの問題領域を決めておく必要がある。

ジョシュアツリーの法則

名前がないものは、見ることすら出来ない。
まどか神が見えないのは、全員名前を忘れたから。

名前を付けることで存在を知る

物や概念　→　名前があることが前提
名前があることで認知され、再利用される。
この仕組を利用したのが、デザインパターン。
設計ノウハウに名前を付けることで、再利用できるようにしている。

「コミュニケーション」って言葉も、元来日本には存在しないハズだが、海外の考え方に触発されて普及した感じがする。
普及したはいいが、そもそも日本の風土にないため、個々で定義が変わっていて、意思疎通の邪魔ばっかりする。
言う方は楽でいいかもしれないが、聴いてるほうは翻訳のストレスに悩まされる。そして認識齟齬を生む。
それが問題化すると、コミュニケーションうんたらを言い始めるから始末におえない。まったく、いやな世の中になったものだ。
日本のリーダー層やトップの人間が、コミュニケーションって言い始めたら、だいだい怪しいと思うのが、最近の心情である。

セカンドシステム症候群

２回めのリリースは危険だ！
なぜなら、慣れからくる自身が、失敗を招きやすいから。
慎重な判断をすることを常に心がける。

車輪の再発明

既にあるものを作ること。
時間の無駄であることが多く、既にあるものが品質が優れていることが多い。

f:id:suzaku0914:20160627064818j:plain

ロードローラー使ったのも、車輪の再発明を揶揄してなのかぁー！！！

車輪の再発明をしてしまうことは、「車輪の知らない」「車輪を作りたい」という背景が存在している。

車輪以外に注力する

本来やるべき作業に注力する。
その状態を作るために、チームミーティングを行い、情報収集を行う。
また、エゴの少ないプログラミングを徹底する。
作りたいから作る　→　プログラマのエゴ
日々、使えそうなものは調査・把握する努力を怠らない。

車輪の再発明をすべき時

  • ビジネス目的
    再利用する　＝　差別化を止める
    ビジネスコアな部分は再発明をやめて差別化を図ることが重要。
    そのためにも、ビジネス目的は明確にしておく必要がある。

  • 学習目的
    存在するコードを使うのと、ゼロからソフトウェアを作るのとでは、得られる経験値が違う。
    車輪の再発明は、学び技術力を高める上で必須になる。

ヤクの毛刈り

本当の問題に辿りつくことは難しい。
なぜなら、トラブルは芋づる式。
問題を解決しようとしたら、別の問題が出てきて、最終的に何を解決したかったのか忘れることがある。

そのような状況に陥った場合、早々に切り上げる方がいい。
問題が起こったら、何が目的だったのか考えるクセを付ける。
目的と違う・コストと見合わないと感じたら、作業をやめて別の道を模索する。
そうなった経緯は、参考になることが多いので、メモしてメンバーに共有すると、組織が強くなる。

トラブルが、「ＴｏＬＯＶＥる」って誤変換ばかりされて、困った。
あんまり打たないハズなのだが、Google日本語入力は、俺をそうゆう人間だと判断したらしい。
もしくは、そういうことをGoogle検索する奴が多いってことだな。

感想

結構いろんな本の言いたいことを、体系的にまとめていた気がする。
内容が濃ゆいので、読んで自分の腹に落とし込むのに結構時間がかかった。
基本的には、自分の考えと間逆なことは書いてなかった。
初心者に理解させるには、難しい内容な気がする。
自分は、過去の経験から記述内容を腹に落とせるけど、初級者はそれがないので辛いのでは？と思いました。
とはいえ、幅広く知識を得るには優れた本なので、１冊持っているのがいい気がします。
気になったことは、より専門的な本を買って読めばいいので。
ヒントになることは、いくつかあったが、より深く探るには適さない。
幅広い知識体系と考えを持ちたい人にオススメの本でした。

全体的に読んでみて、シンプルって言葉がよく出てきた。
やはり、ものごとの本質は、シンプル性を好むのだと強く確信できた。

次は、SOFT SKILLSの日本語訳でも読もうかな？

*1:発行する弾丸のこと、飛んだ奇跡がわかり、即時フィードバックができる

*2:背景・価値観に共通認識が多い状態

*3:状態の切替

Javaのインタフェースの使い方と有名企業の技術力

チーム プログラミング

インタフェースの使い方

そもそもインタフェースの役割

仕様と実装を分けること。
使われ方と内部の処理を分けると言ったほうが伝わるかな？
例えるなら電卓。
数値と演算子を打ち込めば計算できるけど、内部でどう演算しているかは知らなくていい。
※電子制御レベルの話での演算

過去に酷い現場で見たインタフェースの使われ方が。。。

どう使われているかと言うと、特定のクラスからしか呼び出されないクラスに対してインタフェースで分離している。
まぁ、それだけなら許せるんですけど、質が悪いのは、クラス名で縛っているから、100%未来永劫他のクラスで使われない。
例えると、B001ってクラスがあるのだが、B001IFのインタフェースがあって、B001IFImplって実装クラスがある。
B001IFImplは、絶対B001しか使わない。
話通じているだろうか？若干不安だ。。。

これってインタフェースで分離する意味あるのだろうか？？
変化が起こる未来が想像できないだけで、実は存在している？
詳しく説明して貰いたいものだ。
看破される気がしねぇ！

DIしているんですけど、絶対どっかからパクってそのまま流用しているとしか思えない。

さらに悪化の連鎖が。。。

まぁ、インタフェース程度ならまだ我慢できなくもない。
※結構、怒りの臨界点に近いけど。

インタフェースの定義を見て絶望した。。。
select01()、select02()、select03()・・・・ お前、なめとんのかー！！！ヽ(`Д´)ﾉﾌﾟﾝﾌﾟﾝ

流石にこれは許容できなかった。
こんなとこあるのか。。。
下記記事でクラス名でDisったところだが、ここまでダメな子なの。

suzaku-tec.hatenadiary.jp

メソッドで何をしたいのかさっぱり分からない。
こんなのを保守していくのか。。。

日本の技術力は大丈夫なのでしょうか？

東証に出てくる企業名がCopyrightに書いてあるのだが。。。
本当に大丈夫なのか、不安になった。

営業が強いだけで、技術力が足りてない、もしくは軽視している気がしてならない。
ITエンジニアは道具じゃない！！
営業も人事も総務も、みんな大切な仕事で楽な仕事など無いと思っているが、少し軽視の対象になっている気がしてならない！

仕様を満たしてはいるかもしれんが、保守は出来ないのではなかろうか？
作って終わりではなく、作って運用していくことを考えて欲しいと、強く思いました。

日本の将来のためにも技術系の記事を多く書いたり、議論の対象になるような記事を書かなければいけないと感じさせる現場だ。
このブログは、サブカルを結構多く取り上げてしまっているのが恥ずかしくなった。
※まぁ、サブカル系の記事投稿は辞めないけど。

大丈夫だと信じたい！

前の現場も東証に上場している現場だったけど、命名はしっかりしていた。
インタフェースも変更がある箇所や多様性を求める箇所に使用していたので、そこまでストレスは感じなかった。
ここの現場が特別そうだと思いたい。
適切にやっている現場も見ているので、全部がダメだとは思っていない。

ただ、結構な割合でこういう現場は見る。
最近見なかったので、沸点が低かったのかもしれん。

感想

Bad Smell

臭い臭いが。。。
書いて思ったが、「くさいにおい」とも「においくさい」とも読めるな。おもしろーい。

嫌な予感しかしない。
契約上、長期間のため、終わる頃には心が死んでいるかもしれない。

上長の説得

はやくこのヤバさを上の人に伝えたいのだが、説得できない可能性が高い気がする。。。
なぜなら既にお金が発生しているから。
諭されて終わりな気がしてならない。

長期的にデメリットが多く出て、ロスが大量に発生する旨を伝えればイケるだろうか？
話し下手な自分が恨めしい。

話が下手だから、最後に苦労する＆女も付かないのだろうなと感じました。。。。