エンターテイメント!!

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

JJUG CCC 2019 Spring 参加報告

公式サイト

JJUG CCC 2019 Spring - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

参加セッション

  • Oracle Keynote Valhalla, updates and future
  • Catch up Java 12 and Java 13
  • ドメイン管理サービスにおけるJava活用のご紹介
  • 入門: 末尾呼び出し最適化
  • ソフトウェア設計の教育工学的な分析と育成へのアイデア
  • Project Loom - 限定継続と軽量スレッド
  • Functional Spring Cookbook

感想・まとメモ

Oracle Keynote Valhalla, updates and future

  • 内部クラス -> JVM上では別クラス
  • JEPの名前は、変わることもある
  • 二仕様物語は、笑うところ
    • たぶん、笑わないのは元ネタが分からないから。二都物語とかけているらしいが、読みが似ているだけで、内容が揶揄しているのか、よく分からなかった。。。
  • Java11より前は、内部クラスから外部クラスを呼ぶときにBridgeMethodを経由して呼ばれる
    • 開発者は作ってないが、スタック上に出力されてしまう。。。
    • やろうと思えば、外部からBridgeMethodにアクセス可能
    • Java11でなくなった
  • ValueTypes
    • Minimal Value Types プロジェクト(MVT)
      • タイプの種類
        • LQRU
          • なんか、エヴァのタイトルに出てきそうな英字だな。。。

BridgeMethodは、一回、試してみたい。
確かに、Java8使っているときに、見覚えのないメソッドがスタックトレースに出てきた経験がある。

Catch up Java 12 and Java 13

www.slideshare.net

Java12

lts のあとなので、大きな変更はない。
とはいえ、ツールとか入ってきた。

JEP 189

  • GCが7種類に
  • Shenandoahは、一回の GC は一定だが、頻度が変わる。

ShenandoahのJEPのサマリを見たときは、「そんな、バカな!」と思ったけど、やっと意味が分かった。
最初見たときは、一回のGCで全部回収して、実行時間も一定みたいな意味合いに見えてしまったが、違うのね。
参照の切り替えで済むから一定で、頻度は違うかもってわけか。。。
思ったんだけど、これの発生タイミングが重複してしまったら、どうなるんだろう?

JEP346

  • Java がメモリを返すようになった
  • これが可能になることで、常駐プロセスが作りやすくなったはず。
  • GC 改善は続いている。

JEP325

  • switch -> preview
    • 即使うのは待った

イマイチ、これは、便利になったのか?って疑問符が湧く。
switch文が嫌いなのだが、JDKのコミッターにswitch文好きがいるのかな?
それとも、デカい回収のための何かなのだろうか?

JEP341

  • 起動時間の短縮

JEP334

  • 定数の遅延処理

String#transform

  • ラムダ式でアクセスの逆順で書けるようになる。

かなり便利そう。
これは、Stringだけなのかな?
他のオブジェクトでも使いたいケースがありそうな予感。
内部の仕組みを確認しておきたい。

java13

  • socket 一新される
  • Loomは桜庭さんのセッション参照

かなり駆け足だった。
45分で振り返るのは、無理があったのだろうな。。。
興味持ったところだけしか、メモは取れなかったが、コンパイラの話は、かなりスッキリした。
あとは、String#transformが、かなり気になる。

ドメイン管理サービスにおけるJava活用のご紹介

  • TLD -> top level domain
  • ドメインはオークションで落札する必要がある。そこから色んな会社を経由して利用者に渡る
  • ドメインの最高落札額は、150億円くらい

ICANNと聞いて、最初にICANを連想してしまった。。。
ICANNって、ビジネス的にウハウハなんじゃないかな?って思ってしまった。

入門: 末尾呼び出し最適化

speakerdeck.com

末尾呼び出し最適化ってのは、後続の処理がないことに目を付けているわけね。
処理をスタックトレースに積まないことで、メモリ消費を抑えていると。
後々、疑問に思ったが、問題が発生したときにトレースできなくなるのでは?と思ったが、どうなんだろう?
同じ処理の繰り返しだから、スタックトレースは不要という考えなのかな?
分岐があったら死にそう。。。

あと、スタックってのは、遊戯王で言うところのチェーンを積んだ状態と一緒だなって思った。

ソフトウェア設計の教育工学的な分析と育成へのアイデア

speakerdeck.com

やっぱり、現場に出てない講師もいるんだ。。。
なんか、セミナーとかは、現場に出てないやつが出ているのではないかという疑惑が心の中にあったが、やっぱり、ものによっては、現場から追い出されたやつが講師しているケースもあるのね。。。

分からない箇所が本人の説明と違う箇所にあるってのは、よくある話。
俺も、新人の頃は、分からない箇所を教えてもらっても、しっくりこないことがよくあった。
それを理解して接してあげないと、精神攻撃になってしまうから、教える側は注意が必要かもね。

Project Loom - 限定継続と軽量スレッド

t.co

  • safe habor statement -> 信じるなの意
  • 並列/並行処理=難しい
  • 並列処理がスケールしない= CPU が遊んでる

待ちを譲るって聞くと、js の Promise だな。
JavaでjsのPromiseをやるには、スレッドを上手く使うしかないと思う。
wait-notifyAllでも実現はできるのか。。。

どうも、スレッド周りの話は、難しい。
ExecutorServiceが理解できてないせいかもしれない。
時間を見つけて、本腰入れて勉強する必要があるかも。
できれば、Fiberが来る前にやっておきたい。

Functional Spring Cookbook

docs.google.com

Spring Fu???
eclipse cheにインスパイアされてそうな命名に感じる。
ただ、FuはFunctionであることは、なんとなく予想できる。

Springにも関数型の概念が入ってきているのか。
Spring webfluxを早めにキャッチアップしておきたい。

全体通して

やっぱり、人が多い。女性の割合がかなり増えた印象がある。
あと、初参加者は、毎回、一定数いるんだなって感じた。

主流はmacだが、サーフェス使いも増えてきた気がする。

String#transform が、かなり気になった。
最初にやりたいことが、一番最後に記述するはめになるのを、どうにかならないものかと考えていたので、とても画期的に思えた。
応用が効くのか、試したい。

タスク・課題

  • String#transformの確認
  • BridgeMethod
  • ExecutorServiceを調査する
  • Spring webflux

Vue.jsをvue-cliで試してみる

きっかけ

UI周りの実装が楽にならないか探して、vue.jsを知ったので試してみる。
react.jsも試したことはあるんだけど、覚えることが多くて辞めた。

環境

バージョン: 1.33.1 (system setup)
コミット: 51b0b28134d51361cf996d2f0a1c698247aeabd8
日付: 2019-04-11T08:27:14.102Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

詳細

nodeはインストールした前提で始める。

Vue cliのインストール

とりあえず、公式にあるとおりにインストール。

npm install -g @vue/cli

グローバルに入れるのは、プロジェクト作成のツールであるため。
vue create my-project とすると、my-projectの中にnpmのプロジェクトができるので、自分で作ってローカルにインストールすると、二重にできてしまうから。

プロジェクト用意

先に書いてしまったが、下記のコマンドで用意

vue create my-project

結構、長い。。。
気長に待つ、

とりあえず実行

インストールが終わると、npm run serve で起動できるらしいので、作られたmy-project配下に移動して、コマンドを叩く。

 $ cd my-project
 $ npm run serve

serveって、serverのことかな?

http://localhost:8080/で起動したよ的なメッセージが出てきたので、ブラウザでアクセスしてみる。
そうすると、vueのサンプルページが見えるはず。

バインディング

App.vue と HelloWorld.vueの連携はわかったんだけど、index.htmlとApp.vueの連携がよく分からなかったので調べた。

紐付をしているのは、main.jsの下記の実装

new Vue({
  render: h => h(App),
}).$mount('#app')

appにApp.vueを設定している。

下記の記述と同価

new Vue({
  el: "#app",
  render: h => h(App),
})

render関数は、業が深そうなので、こうすると描画されるんだ程度で辞めとく。

感想

vueファイルとあるが、内部は、css/html/jsだから、素直に読めるのがいいと思った。
イベントハンドリングや文字列の埋め込みは、別の機会に。

Visual Studio Code で WSL

きっかけ

windows10で、dockerとかvirtual box入れなくてもlinux動かせるようになったが、visual studio上でやりたいと思ったので情報探したので、メモ書き

詳細

VisualStudioCode insidersを入れる

ちょっとタイトル詐欺があります。。。
現時点(2018/05/11)では、visual studio code(以下、vscode)では、ターミナルにWSLを指定できません。
visual studio code insiders(以下、vsinsiders) をインストールしてやる必要があります。
vsinsiders は、 vscodeの実験的な意味合いでビルドされたもので、普通に使う分には、vscodeと大差はないと思う。(たぶん。。。)

Download Visual Studio Code Insiders

自分の実行環境は、下記の通りだった。

バージョン: 1.34.20-insider (user setup)
コミット: 57b550c559b945eb9d871dbf2b2e4cb9e31e2551
日付: 2019-05-10T17:36:45.765Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

WSL有効化

自分は、これする前にしてしまったので、下記のサイトを参考に設定を変えてください。

Windows10でWSLとVSCodeを使ってC++環境を整える - Qiita

忘れずに、update/upgradeをやってね。

拡張機能

Remote WSL ってやつを入れる。

設定の変更

公式にあった設定を、そのまま適用

Integrated Terminal in Visual Studio Code

{
    "terminal.integrated.shell.windows": "C:\\Windows\\System32\\bash.exe"
}

ここまでできたらターミナルを開くと、wslに接続されるはず。

感想

まだ使い込んでいないので、なんとも言えないが、linuxの学習環境構築としては、とてもいい気がする。
vscodeは、markdown補助の拡張機能もあるし、メモ取りながらコマンドをバシバシ打っていけるがいいと思う。
linuxのコマンドやviとかをwindows上で使える恩恵が、ものすごいと思う。
試しにvi操作でwidnwso上のファイルを編集したけど、widows上で他のエディタで見ても編集できてる。
これからは、linuxの恩恵がwindows上で得られるのは、画期的に感じる。
ちょっと前までは、cygwinとかがそうだったけど、ちょっとクセがあるから使いづらい印象。

雑記

最近、ジョジョの奇妙な冒険 黄金の風のOPの裏切りのレクイエムを、食い入るように聞いてる。
今回も、準備しながら聞いてた。
なんか、中毒性が高い。

参考サイト

VSCodeのInsiderの拡張、Remote WSLを使ってみたよ - 味噌汁を飲みます

Windows10でWSLとVSCodeを使ってC++環境を整える - Qiita

【読書ノート】ドラッカーさんに教わったIT技術者のための50の考える力

きっかけ

セール品の中で、たまたま目に止まった。
最近、思うんだけど、平時から技術者としてどうあるべきか考えを持ってないと、優秀には成れないと思い始めてきた。

まとめも

基礎的な考え方を身につける

成長のための考え方

  • 時間管理
  • 貢献の仕方を考える
  • 強みを伸ばす
  • 重要なことを集中的に行う
  • 効果的な意思決定

上記の全ては、実践の中で磨かれる。磨かなければならない。

メモ:つまり、奴隷的な考えはアカンよってことかな?考えて作業してないと、成長はありえないってことだろう。

知識労働者であることを自覚する

ITエンジニア=知識労働
幅広い知識を利用し、考えて作業を行うべき存在。
仕事を単純労働にするのは、己自信。考えて働くことを辞めたら、それは知識労働者ではない。

考えることを辞める阻害要因
  • 手順書・マニュアルが整備されてしまっている
  • ネット上の情報を安易にコピペ

メモ:でもさ、とりあえずやることって重要じゃない?そこから考えるネタが見えてくることもあると思う。やってみて、考えとは違う結果に成れば、それはそれで、いいことだと思うんだよね。闇雲にとりあえずやるはダメだとは思うけど。。。考えても埒が明かないとか、考えられることは考えたなら、とりあえずやるは、有効だと思う。

考えることが仕事

考えることは、強制されることは少ない。
だからこそ、考える力を伸ばさなければならない。

考えて仕事しているかのチェックリスト
  1. 手順を追うだけの仕事をしてないか?
  2. 工夫することはないか考えているか?
  3. 単純コピペしてないか?
  4. 誰かの奴隷になってないか?

メモ:俺風の言葉に直した。特に、「奴隷になってないか?」は、自分でも自画自賛したいくらい秀逸な文言だと思う。

成長の責任を負う

研修制度がある≠成長できる
成長の責任は、自分で負うべき。

メモ:素晴らしい言葉だ。だいたいの人は、成長を他責にしようと思っている感がある。配下メンバーと話すと、そう思うことが多い。なぜ自分の責任で学習しようとしないのか、ものすごく疑問に感じる。逃げの一手であるような気がしてならない。かと言って、叱責したところで状況は変わらないと思うんだよね。だから、話すたびに相手に考えさせることをしないと思う。

能力向上の2つの方法
  • 改善
  • やり方を変える

メモ:日本は、改善が得意だけど、やり方を変えるは下手。両立ってできないものなの?

改善とイノベーションの両立

改善は常に行う。その先に、イノベーションがある。
上手くいっているときに、新たな取り組みを行うことが必要。

自分の成長に責任を持ったら、いまの自分が上手くいっているのが見つめ、改善と新たな取り組みの2つの目標を立てる。

自分の軸を考える

改善とイノベーション = 外なる成長 誇りと自身をつける = 内なる成長

よりよく行うことを目指す

コントロール不可な現実
  • 時間が他人に取られる
    • 抵抗するのは不可能
    • 時間の使い方が大切になる
  • 定常業務に追われる
    • 重要なことができなくなる
    • いたずらに知識と能力を浪費してしまう
  • 組織にいる
    • 自分一人が頑張っても成果にならないことがある
    • チームで成果を出すつもりでないと、己の成果もあげられない
    • 外部に与える影響が見えない場合、成果が上がっているのかも分かりづらい。

上記の阻害要因があるので、意識して努力しない限り、成果をあげられない。
流されて仕事をすることをやめ、一流を目指して仕事をしなければならない。

学び方を工夫する

学び方は、千差万別。学校や塾で教わった学び方が、自分にあっていない場合もある。
自分が得意な学び方で学ぶことを心がける。

時間をマネジメントする

新しいことを学ぶ前にすべきこと
  1. 時間配分を知る
  2. 効率が悪いものを見つける
  3. 時間をまとめて、大きな自由時間を作る
時間を記録する

成果をあげるためには、まず時間配分を記録することが必須。
後々、どこで時間を使っていたのか、分からなくなる。

記録した時間をもとに、辞めるものを検討する。
もしくは、時短の方法を考える。

フィードバック分析

フィードバック分析を行うことで、下記の効果が得られる。

  1. 強みの強化
  2. 傲慢を正せる
  3. 成果の妨げが何か知ることができる
  4. 人への接し方の改善
  5. できないことをしない
  6. 無駄な努力の削減

その日の目標を作る

客観的に分析するには、何かに対して、できたこと/できなかったことを知る必要がある。
目標があることで、分析が容易化する。
どう改善していくかときめること=フィードバック分析

上手くできたことは覚えていない

失敗は覚えているが、上手くできたことは覚えにくい。
上手くできたことに対して、喜びが感じられていないためかもしれない。
フィードバック分析の一番の目的は、強みを見つけて活かすこと。
失敗を覚えることも重要だが、同じくらい、上手くいったことを覚えることも重要。

目標があると分析がしやすい

目標を決める=それに向けて行動する=成功率が上がる。
成果として見えるので、上手くいったことを忘れずに済む。

原因を3つ考える

振り返り=必ず記憶を取る。
記憶があることで、学習効果が高まる。

振り返りのポイント

なるべく3つ原因と要因を考える。
1つだけだと、短絡的思考になり、次に繋がらない。

深く考える

成果があがる/あがらないの差は、才能ではなく、習慣的な取り組む姿勢と基礎的な方法を身につけているかどうか。
取り組み方は、人によって千差万別。

メモ:トヨタのなぜなぜ分析は、使い方を間違えやすいとは、長年思ってた。方向性を見失っていると、意味ない方向に飛ぶから、ある程度、議論の方向性が見える人が必要だとは思う。

ロジカル問題解決のフレームワーク

Where/Why/Howの観点で、振り返りをする。

感情を区別する

記憶=感情も残る。
フィードバック分析を行うためには、論理的に行う必要があり、事実の記憶が必要。

感情と理論

感情的に考えるのは、人間の特性。
論理的に考えるには、感情的に考えることを受け入れること。
感情を持つことは、人として当たり前なので、それ込みで分析する。

感情ではなく行動に注目する

重要なのは、その感情になった結果、何をしたのか?
それを振り返ることで、次回から対策を考えられるようになる。

判断力を高める

意思決定をする = 知的労働者にとって成果をあげるために必要な能力

判断のプロセス

  1. 問題の種類を知る
  2. 条件の明確化
  3. 是非
  4. 行動

問題の種類

  • 経験則で解決可能な問題
  • 一般的問題
  • 新種の問題
  • 例外的で特殊な問題

いつもと同じでいいかを考える

  • 同じように行えるようことは、手順化・ツール化して省力化
  • いつもと違うところをみつけ、それの解決に集中する

人のやり方を真似る

分かった気になる=失敗に繋がりやすい。
判断を下す前に、十分な情報を入手して、実際に試してみてから判断したほうが良い。

意識して判断する

調査しながら判断=目的がすり替わる可能性が高い。
推測のまま進めなければならない箇所が出てくるため。
それが積み重なった結果、大問題になる。

ミッションを元に判断する

自分のミスを疑う

本当に例外的な問題は、稀。
実は、操作ミスなど、多角的に見ると、たいしたことない問題であることもある。
例外的な問題と判断する前に、よく調べてから問い直す。

メモ:作ったのを動確してると、だいたいは、己のミスであることが多い。

コミュニケーションを工夫する

メモ:コミュニケーションって言葉、もう辞めませんか?何いってもコミュニケーションで済ませるから、このワードを見ると腹が立ってしょうがないんだよね。

聞くことからスタートする

信頼関係を作る

人→聞くより話す方が好き。
話しやすい環境を作ることが、信頼構築の第一歩

期待を知る

相手の期待を知る=有利に物事を進めることができる

用意してからアウトプットする

インプットからスタートしない

アウトプットが想像できない場合、インプットした情報・知識から作り始めるため、体系的な説明ができにくい。
アウトプットを決めていると、何をすべきかが明確になるため、必要な情報を集中して集めることができる。

短い文で伝える

受け手の言葉を使う

受け手が分からない専門用語を使う=野卑
相手が理解できるような言葉を使って会話する必要がある。

メモ:でもさ、相手が分かるかどうかって、相手からの反応がないと分からなくない?逆に、受け手が分からない前提で離したら、愚弄されてると受け手が感じることもあると思う。

短い文で伝える

メモ:短すぎるのも問題と思うが。箇条書きの羅列で前後関係が破綻すると最悪。意味のまとまった単位で最小の文を作るが、正解だと思う。

結論から伝える

話が長い=受け手にストレスがかかる

言いにくいことでも、端的に述べる。
言いにくいことは、何かしらの背景がある。
それを明確にしたほうがいい。

感情を伝える

仕事=感情抜きでもできる。信頼に対して敬意があれば、仕事は成立する。信頼関係構築のために、相互理解を計るべき。
感情を無くせというわけではない。
感情が存在するのは、人である証拠。
抑え込もうとするのは、逆効果で、受け入れる方が、楽になる。

周囲の評価は、感情では決まらない。
行動に対して、評価が決まる。

感情と事実と考えを分ける

事実と考えは違う。
妄想が報告された結果、最終的に大事になる。
伝えるときは、それが事実なのか、考えなのか、感情なのか、受け手にとってわかりやすいように話す。

上司をマネジメントする

上司=成約ではなく利用できるもの
部下の役割は、上司に成果を出させてあげること。

部下・上司、お互いをよく知ることで、仕事は成功しやすくなる。

成果を上げる思考力

判断しているかを見つめる

先延ばししてしまった場合、その判断理由が何かを明確にする。
反射的にやっている場合、先延ばしがなくなることはない。
理性的に判断する習性をつける。

感情を記録し、受け入れる

今さら自分は変えられない。
それを受け入れ、解消するための行動を起こす必要がある。

何も決定しない選択は、選択としてはあり。
ただし、行動を起こさない結果、自体が悪化するのなら、行動しなければならない。

やらないことを決める

先延ばしは、重要ではないことに時間を使っていることが大半。
だから、やらないことを決める。
必要なことで辞めることができない場合は、作業を他人へ移譲することも考える。

やりたい気持ちを大きくする

仕事に意味を加え、貢献方法を明確にする。
最終的に後回しを回避することにつながる。

仕事の種類を知る

  • 成果が質を意味する仕事
  • 質と量の療法を成果とする仕事
  • 質が前提で、成果の殆どが量で定義される仕事

やる種類によって、注意すべきポイントは変わる。
どの種別の仕事をやっているのか意識し、仕事をやることで成果を上げることができる。

リスクを考える

リスクがない仕事はない。
リスクを予め想定して段取りをするべき。

リスクを発見したら、できるだけ早い時期に最小化するための対策を行う。

仕事が終わったあとでも、リスクの検討について振り返りをする。
どのようなリスクがあるのか考えることは、次に活かせる。

ネガティブになっていることに気づく

ネガティブな状態になったときに行う考え方

  • 無視する/否定する
  • 「自分の仕事ではない」と考える
  • 責任の押し付けあい
  • 混乱/判断を仰ぎ、責任転嫁
  • 言い逃れ
  • 様子見

メモ:漫画で出てくる敵役がやりそうなことだな。。。

被害者意識に陥ると、なりやすい。
さらに、被害者意識は悪循環を呼び、抜け出せなくなる。

メモ:でもさ、原因分析って、大抵の場合、悪者探しになるじゃん。

貢献と目標を意識する

貢献を意識すると、主語が組織やチームになる。

メモ:貢献は、ようするに圧倒的な当事者意識がありますか?ってことだろう。言霊主義の日本では、有効かもね。

目標を意識すると、チャレンジの考えが芽生える。
ただし、高すぎても、低すぎてもダメ。

メモ:俺は、会社の目標には従わない。自分の中で目標はすでにあるので、会社には、聞こえがいいように自分の目標を伝えて、経営方針のことをいかにも考えているような感じで伝える。

ルールを変える

ネガティブになるきっかけ

  • 誰かの感情に引っ張られた
  • 叱責/非難
  • 正義感に引っかかる

ネガティブな感情は、伝染する。
社会的な機能として備わっている。

メモ:他人の幸福を見ると、壊したくなるんだが、これも、人の社会的な機能ですかね? メモ:おかしいな。俺は負の権化なはずなんだが、職場がネガティブになってくれない。

普段から、不平不満を撒き散らしている人やグループといると、感情も引っ張られる。
グループがそうなりそうな場合は、距離をとるなどを考えてみる。

メモ:な、なるほど。不平不満を言う相手がいないから、職場がネガティブにならないのか。。。

ルールを変える

ネガティブな反応はなくせないので、反応を制御する。
ネガティブな反応がでそうなときは、意識の切り替えを考える。

信念を見直す

信念は、誰でも持っている。
ただ、信念が元になってネガティブな感情になることもある。
その場合は、信念を少し変えてみる。

自分を伸ばす思考力

自分の強みを発見する

強みを知る方法=フィードバック分析しかない

強みが活きる行動をリストアップする

強み=成果を生み出すもの
強みを活かせるところを見つけることで、より評価が高くなる。

強みを活かせる関係を築く

人的ネットワーク=強みを活かせる場を提供してもらえる機会がある。
知的傲慢は、人的ネットワークで得られたチャンスを失う可能性があるので、言動には注意が必要。

自分の持っている知識、自分の行動を見つめる

人に教える=知識や技術をより明確に理解している必要がある。

人に教えることができるようになるためには、下記を行う必要がある。

  • 知識の整理
  • 知識の不足点を補う
  • 知識の体系立て
  • 自己の行動が、どのような根拠や目的に即してやっているか明確にする

知識を伝える

伝えるには、価値観、欲求、目的に合致していると理解が進む。

メモ:講義を聞いたりするけど、ダメな講義は欲求が満たされない気がする。講義は選んで受けるので、目的や価値観には大幅なズレはないかな?

知識を伝えるのは、限界がある。
何かの知識と複合して自分の知識になるケースもある。
だから、伝えるべきは、効率的に学べるように伝える。

行動を教える

知識だけ、手順だけを教えていては、理解は深まらない。
技術は、知識と能力を複合することで発揮される。
伝える際は、具体的な行動と判断基準もセットで教える。

補助輪付きで走らせる

最初から、教えたことが実践できるとは限らない。
成果を出せるように働きかける必要がある。

教えたことを効率的に身につけるためには、フィードバック分析を支援してあげる必要がある。

補助輪を外す

いつまでも補助輪をつけるのは、成長に繋がらない。
どこかの時点で、責任を持たせる。

自分で判断する

自ら判断しない=責任を持たず、できるかどうかを深く考えていない。失敗しても他責にしようとする。
自ら判断=責任を持って、成功するためにどうしたらいいかを考える

目標達成のプロセスを考える

理想の状態と評価基準を考える。
プロセスを考えるためには、必要。

自己目標管理のために、以下の基準に気をつける

  • 具体性
  • 測定可能
  • 達成可能
  • 重要性
  • 達成期間

具体的な計画に落とし込む

目標を設定したら、まず、現状とのギャップを分析する。
その後、ギャップを埋めるための行動を決める。
行動を定期的に測定し、チェックする。

コーチングの進め方

  1. 話をする環境を作る
  2. 目標を決める
  3. 行動を決める
  4. 目標達成の基準を明確にする
  5. 定期的に測定する

感想

さすがに、50は、最後まで読むのがダルくなる。。。

ドラッカーさんの言うことには、概ね同意何だが、現場が複雑化しすぎて適用できない気がするんだよね。。。
適用するにしても、人が人間的に優れていないとダメなんじゃないかとも思う。
ITの現場って、ゴミみたいな人間が多いから。。。

読んでて思ったけど、たまにツイッターで流れてくるいい話的なやつって、ドラッカーさんの言うことを親子を例にして説明しているだけな気がしてきた。

Mahoutでレコメンドを試し実装

きっかけ

Spartの動きがなんとなく分かったので、次の機械学習へ。

環境

IntelliJ IDEA 2019.1 (Community Edition)
Build #IC-191.6183.87, built on March 27, 2019
JRE: 11.0.2+9-b159.30 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

intellijって、開発環境を簡単に出せるのか。。。
知らなかった。
メニューバーの HelpAbout で表示できる。

いっつも、コマンド打って転記してたけど、今度からこれでやったほうが早いな。

実験

build.graldeと実行ソース、データセットを晒しておけば十分かな?

build.gradle

plugins {
    id 'java'
}

group 'rssCollector'
version '1.0-SNAPSHOT'

sourceCompatibility = 11

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
    // https://mvnrepository.com/artifact/org.apache.mahout/mahout-core
    compile group: 'org.apache.mahout', name: 'mahout-core', version: '0.9'

}

data.csv

1,1243,3.3
1,1240,0.3
1,1242,1.2
2,1242,1.3
2,1243,1.9
2,1241,2.8
2,1245,4.3
3,1240,0.6
3,1242,1.0
3,1241,2.3
3,1245,3.0

sample

本当は、先頭大文字にすべきだけど、多めにみて。。。

import org.apache.mahout.cf.taste.common.TasteException;
import org.apache.mahout.cf.taste.impl.model.file.FileDataModel;
import org.apache.mahout.cf.taste.impl.neighborhood.NearestNUserNeighborhood;
import org.apache.mahout.cf.taste.impl.recommender.GenericUserBasedRecommender;
import org.apache.mahout.cf.taste.impl.similarity.PearsonCorrelationSimilarity;
import org.apache.mahout.cf.taste.model.DataModel;
import org.apache.mahout.cf.taste.neighborhood.UserNeighborhood;
import org.apache.mahout.cf.taste.recommender.RecommendedItem;
import org.apache.mahout.cf.taste.recommender.Recommender;
import org.apache.mahout.cf.taste.similarity.UserSimilarity;

import java.io.File;
import java.io.IOException;
import java.net.URISyntaxException;
import java.net.URL;
import java.util.List;

public class sample {
    public static void main(String[] args) throws IOException, TasteException, URISyntaxException {


        URL url = ClassLoader.getSystemResource("data.csv");
        DataModel model = new FileDataModel(new File(url.toURI()));

        UserSimilarity similarity = new PearsonCorrelationSimilarity(model);

        UserNeighborhood neighborhood = new NearestNUserNeighborhood(2, similarity, model);
        Recommender recommender = new GenericUserBasedRecommender(model, neighborhood, similarity);

        // ユーザID:1の人に3件レコメンド
        List<RecommendedItem> recommendations = recommender.recommend(1, 3);

        recommendations.forEach(System.out::println);
    }
}

実行

実行すると、下記みたいなのがでるはず。

RecommendedItem[item:1245, value:3.65]
RecommendedItem[item:1241, value:2.55]

3件指定したけど、2件しか出てこないのは、データが少なすぎるせいらしい。

感想

sparkなくても、レコメンドとかできるのか。。。。
すごく楽にレコメンドとか実装できてしまって、hadoopの実行環境作るのに悩んでいたのは何だったんだと思いたくなる。

他のサイト見ていたけど、 UserSimilarity similarity = new PearsonCorrelationSimilarity(model); のところで、 PearsonCorrelationSimilarity 以外のアルゴリズムを適用させて、いろいろ分析方法を返るみたい。
当然、後続で利用するクラスも変わるわけだが。。。
利用するアルゴリズムは、統計学の知識がないと、よく分からなかった。
体系的に統計学を学ばないと、ググって調べた程度の知識量では、汎用的に使うのが難しそう。。。

あと、調べてると、やたらとscalaが出てくる。
時期的に見ると、Java8リリース前だから、JVM言語が出始めてきた頃だな。
Java8リリース前は、JVM言語の方が盛り上がってた印象がある。
Scalaは、なんとなく読めるけど、やっぱり、違和感はある。

そういえば、機械学習とかするときって、前処理が大変とよく聞くが、アルゴリズムを適用させるために、決まったデータフォーマットにするために大変ってことだろうか?

課題

参考サイト

Mahoutでレコメンドを作ってみよう! | Atlas Developers Blog

mahout をとりあえず動かしてレコメンドしてみる(動作確認程度) - Qiita

低スペックな頭の僕がJavaの機械学習ライブラリmahoutを動かしてみる。 - regtan’s TechNote

Spark試し実装

きっかけ

本当は、hadoop使ってビックデータ処理がどんなものか探る予定だったけど、環境構築で挫折。。。
あまりにも面倒だったので、sparkでアプローチしてみようと思い、記事を書くに至る。

環境準備

macで実験。
Homebrewをインストールした前提で話をする。

OS

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.4
BuildVersion:   18E226

Homebrew

$ brew -v
Homebrew 2.1.1
Homebrew/homebrew-core (git revision 858af; last commit 2019-05-01)
Homebrew/homebrew-cask (git revision 606f3; last commit 2019-04-30)

インストール

$ brew install apache-spark
$ brew install scala
$ brew install sbt

Sparkの設定

export Spark_HOME=Spark_HOME-/usr/local/Celler/apache-spark/x.y.z

x.y.zはインストールしたバージョンを指定。
自分は、2.12.8だった。

$scala -version
Scala code runner version 2.12.8 -- Copyright 2002-2018, LAMP/EPFL and Lightbend, Inc.

実験

参考サイトを参考に、環境を生成。
ディレクトリ構造を間違えて、かなり迷った。。。

ディレクトリ構成

WordCount/
  build.sbt(ビルド方法を定義するsbtファイル)
  input.txt(ワードカウントする対象の入力ファイル)
  project/ (sbtの追加設定を入れるファイル)
    assembly.sbt
  src/
    main/
      scala/
        jp/
          excite/
            news/
              WordCountApp.scala

build.sbt

name := "WordCountApp"
version := "1.0.0"
scalaVersion := "2.11.8"
resolvers += "Atilika Open Source repository" at "http://www.atilika.org/nexus/content/repositories/atilika"
libraryDependencies += "org.apache.spark" %% "spark-core" % "2.1.0"
libraryDependencies += "org.atilika.kuromoji" % "kuromoji" % "0.7.7"
assemblyMergeStrategy in assembly := {
  case PathList("javax", "servlet", xs @ _*)         => MergeStrategy.first
  case PathList(ps @ _*) if ps.last endsWith ".properties" => MergeStrategy.first
  case PathList(ps @ _*) if ps.last endsWith ".xml" => MergeStrategy.first
  case PathList(ps @ _*) if ps.last endsWith ".types" => MergeStrategy.first
  case PathList(ps @ _*) if ps.last endsWith ".class" => MergeStrategy.first
  case "application.conf"                            => MergeStrategy.concat
  case "unwanted.txt"                                => MergeStrategy.discard
  case x =>
    val oldStrategy = (assemblyMergeStrategy in assembly).value
    oldStrategy(x)
}
mainClass in assembly := Some("WordCountApp")

assembly.sbt

resolvers += Resolver.url("artifactory", url("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases"))(Resolver.ivyStylePatterns)

addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.6")

WordCountApp.scala

package jp.excite.news

import java.util.regex.{Matcher, Pattern}
import scala.collection.convert.WrapAsScala._
import org.apache.spark.SparkConf
import org.apache.spark.SparkContext._
import org.apache.spark.SparkContext
import org.atilika.kuromoji.Tokenizer
import org.atilika.kuromoji.Token
 
object WordCountApp{
def main(args: Array[String]) {
    //スパークの環境設定
    val sparkConf = new SparkConf().setMaster("local[4]").setAppName("WordCount App")
    val sc = new SparkContext(sparkConf)
    //kuromojiのトークナイザ
    val tokenizer = Tokenizer.builder.mode(Tokenizer.Mode.NORMAL).build()
    //テキストファイルから1行ずつ読み込み。名詞を配列に分解する。
    //テキストファイルからRDDオブジェクトを取得する。
        val input = sc.textFile("input.txt").flatMap(line => {
        val tokens : java.util.List[Token] = Tokenizer.builder().build().tokenize(line)
        val output : scala.collection.mutable.ArrayBuffer[String] = new collection.mutable.ArrayBuffer[String]()
        tokens.foreach(token => {
            if(token.getAllFeatures().indexOf("名詞") != -1) {
            output += token.getSurfaceForm()
        }})
        output// return
    })
    //ワードカウントを行う。数える名詞をキーにし、キーを元に加算処理を行う。
    val wordCounts = input.map(x => (x, 1L)).reduceByKey((x, y)=> x + y)
    val output = wordCounts.map( x => (x._2, x._1)).sortByKey(false).saveAsTextFile("output")
    }
}

参考サイトだと、wordCountsが重複して定義してあったので、削除したのを上記にのっけた。

実行方法

sbt run

実行すると、WordCount/output に出力される。
part-0000xに出力される。

感想

hadoopでいろいろやろうとしたが、環境準備でダメだった。。。
その点、sparkは簡単に試せた。

scalaの構文は全然知らなかったけど、kuromojiは、知っていた。
何となくでも読めた。
ただ、sbtのscalaのビルドがどうなっているのかで、ちょっとハマったけど。
問題は、spark使うメリットが良くわからなかったことかな。。。
もうちょい、深く使ってみないと、わからないかもしれない。
もしかして、StreamAPIが入ったことで、並列処理がStreamAPIでもできるから、Javaでメリット薄いように感じるのだろうか?

ハマったこと

ディレクトリ構造を読みまちがて、java.lang.RuntimeException: No main class detected が出てしまったこと。
最初、WordCountApp.scalaを、src/jp/excite/news/WordCountApp.scala に配置してしまって、scalaのソースとして参照されていなかった。
src/scala/jp/excite/news/WordCountApp.scala が正解。パッケージ名にscalaなんて入ってこないから、相当悩んだ。。。
scalaディレクトリ構造は、srcの下にscalaがあるのが正解だって気づくまで、かなり悩んでしまった。
これは、Javascalaを共存させるために、こうなっているのだろうか?

これからの課題

  • SparkとStreamAPIを比較してみる
  • Scalaを学んでみる
  • sbtを調べてみる

参考サイト

「Apache Spark」×「Scala」で分散処理入門 : エキサイト公式 エンジニアブログ

【読書ノート】the four GAFA 四騎士が創り変えた世界

まとめも

GAFA - 世界を作り変えた四騎士

GoogleAppleFacebook、Amazom以外のテック企業は、存在感を失いつつある。
育っても、四騎士に買収されるのが関の山。
四騎士に対抗できるのは、四騎士だけという状態。

メモ:国レベルで保護されないと、対抗企業は作れないだろうな。中国が可能性としてあるけど、同等にはなっても、上位の企業は出せないと思う。なぜなら、パクるしか能がないから。

アマゾン - 1兆ドルに最も近い巨人

アマゾンの特徴は、より多くのものを楽に集めようとする狩猟本能への訴えかけ。
資本を食う店舗を持たないため、倉庫の自動化に投資し、パートナーを増やしていった。
売店がアマゾンの脅威に気づく頃には、アマゾンが巨大になっていた。

アマゾンが勝者になり、それ以外はすべて敗者の状態。
資金が大量にあるため、多少、投資に失敗しても、株価が下落しない。
また、投資戦略がはっきりしている。投資が無駄と分かったときは、きっぱり辞めることができることが成長を加速させている。
リスクアプローチの違いがはっきりしているのが特徴。
ビジネスの過ちは、リスクを負わなかったことで発生することが多い。
おとなしいことには、代償が伴っていることを理解する必要がある。

メモ:おとなしいことへの代償を一番理解してないのは、日本だな。。。とくに行政。規制を大量に作って、現状維持を望んだ結果、海外に駆逐されるって未来が見える。

売店だったはずのアマゾンが、いつの間にかクラウド企業、運送会社になりつつある。

グーグルにも勝る可能性が、アマゾンにある。
商品の検索をアマゾンでする傾向が強まれば、検索能力の向上につながる。
資金も集まってくるので、アマゾン優位ができる可能性がある。

アップル

ジョブズトークが注目されがちだが、最大の功績は、アップルをリスクを追うことを優先する大企業にしたこと。

アップルは、テクノロジー企業から高級ブランド企業に変わった。
そのため、テック企業から競争対象として外れることになった。

アップルの成功は、製造ロボを重視し、世界的サプライチェーンを確立させ、サポートとIT専門家の力を背景に、存在感を確率したこと。

企業は、敵の侵入を防ぐため、参入障壁を作ろうとする。
しかし、現実的には、どこかしらにヒビが入り、いずれ崩れる。

メモ:蟻の一穴理論だな。

テック企業では、それが顕著に現れる。
テック業界に切り込むには、敵の弱みをつくのに使った武器を無力化する力を持つことが大切。

メモ:核兵器を持つなら、Nジャマーも作らないと、報復合戦で勝てないってことか?

アップルは、他の四騎士に比べて、ブランド力で追随を許さない。
競合することが少ないので、長期間存続する可能性が高い。

フェイスブック

すべての情報を関連付けしてしまうため、プライバシーの問題が残る。
顧客情報が明確になっているため、得られるデータの精度が高いため、市場価値が高い。
ツイッターは、偽名である可能性があり、ボットである可能性が排除できない。

フェイスブックの力の根源は、ユーザーにある。
ユーザーがそっぽを向くような策だと分かった時点で、すばやく手を引く。

平均への回帰。正しいことをたくさんしたのなら、いずれ大きな間違いを起こす。
メモ: 平均への回帰って、かなり正しい観測かもしれない。

フェイスブックにとっては、情報が金につながる。
ゆえに、ヘイトスピーチであっても、記事の削除で金が減るのは嫌という状況になっている。

グーグル

情報へのアクセス精度が高い。求めているものを回答してくれ、誰に対しても公平であることで、影響力が一番高い企業になった。

グーグルは、検索アルゴリズムを出し抜こうとする輩を許さない。
いかさまによる検索上位表示をしたものに対しては、対策をきっちり行われ、検索結果の下位になるようにされる。

グーグルの能力は、昔の神であるメディアを殺しにかかっている。
メディアが編集室で発揮しているスキルよりも、高いスキルを発揮している。

グーグルは、神の力である全知を手に入れつつある。

メモ:日本だと、もう動詞として使われつつあるからな。空気と同じような存在に近づいているのだろう。

グーグルは、情報検索による情報収集を行い成長していった。
そのため、他社は気づくのが遅れ、圧倒的な差がついたころに気づいてしまった。
よって、他社の参入が困難な状況になり、今後もこの状況が続く可能性が高い。

四騎士は「ペテン師」から成り上がった

偉大なるペテン師とは、相手が騙されたことに気づかないようにする。
新聞社は、未だに何が起こっているのか知らない。グーグルに完膚なきまでに押しつぶされているとも知らずに。

メモ:無料で情報にアクセスしてくることを制限しないと、収益化はグーグルに握られたままだな。プラットフォームが強すぎて、新聞社じゃ太刀打ちできないだろうし、立場が逆転することは、数十年かかるだろう。というか、グーグルが許さないだろうな。

四騎士は、多かれ少なかれ、犠牲者の目を欺いている。

Uverは、多くの市場で、法律違反を犯しているが、契約する運転者や乗客は、増え続けている。
サービスが優れているため、廃れない。甘やかされてほぼされたタクシーのビジネスモデルを容易に淘汰してくる。

規則が完全でなければ、消費者は使い勝手のいいサービスを使う。
Uverは、それを行っているに過ぎない。

脳・心・性器を標的にする四騎士

成功するビジネス=脳・心・性器に訴えるもの

四騎士が共有する「覇権の8遺伝子」

  • 商品の差別化
    • 差別化は形あるものに限った話ではない。消費者が見つける場所/買い方/配達方法などもあてはまる
    • 消費者の面倒を減らす
  • ビジョンへの投資
    • 大胆なビジョン→安い資本を集める力
    • 目に見える形で結果を残す必要がある
  • 世界展開
    • 第5の騎士になるために必要
  • 好感度
    • 敵を作りにくい
    • 外からどう見えるかで現実が変わる
  • 垂直統合
  • AI
    • データへのアクセス
    • データの活用能力
    • 数量的最適化=予測の向上&将来の顧客のためになる
  • キャリアの箔付け
    • トップクラスのエンジニアを集めるために必要
  • 地の利
    • 優秀な大学とのパイプ=優秀なエンジニアの人材確保につながる

メモ:日本だと、難しい考えだな。特に地の利。大学とのパイプよりも、自社で育てるって概念があるから、そこまで重要視されない気がする。

NEXT GAFA

メモ:アリババは、無理だろう。。。中国という印象最悪なバックがいるのに、国際社会で通用するとは思えない。データに対する価値観も、違うんじゃないかな?金のために、顧客の資産情報を売買する可能性が高いと思う。

メモ:テスラか。。。日本の自動車産業の状態が一切書かれていないのだが、そんなに差があるものなのか?

メモ:uverは、代価企業が出てきたら、廃れそうだな。。。好感度がかなり重要だと事例でわかる。

メモ:ウォールマートは、アマゾンとの差別化が問題かもね。デジタル分野が弱いのが、致命的だな。。。

メモ:マイクロソフトは、どっちかというと復帰できるかどうかな気がする。

GAFA「以後」の世界で生きるための武器

現在:超優秀な人にとっては、最高の時代。なぜなら、勝者総取りの経済が存在しているため。
さらに、国際化による市場の拡大が拍車をかけている。

心理的成熟が、重要になっている。
競争と製品化のサイクルが短くなり、仕事の結果がすぐ出るようになっている。
どのような状況下でも感情のまま反応せず、組織の中が流動的になっても、うまくやっていける人が必要になる?

メモ:これって、もしかして、僕のことですか?

好奇心を持つことも、重要。
テクノロジーの進歩は、年々早くなっている。
次の変化について、積極的になれる人。

メモ:日本人は、現状維持が大好きだからな。経営層が変化に敏感じゃないと、外資に喰われそう。

当事者意識をもち、問題解決にあたる。
当事者意識を持つことで、問題を最小化できる。

感想

なんか、最後は日本企業的な価値観に回帰しそうな気がする。
読めば読むほど、データの扱いが重要だと思った。
やっぱり、ビックデータの知識や統計の知識を早めに習熟しておいた方がいいと思ってしまった。