エンターテイメント!!

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

2019/02/04週 気づきと振り返り

業務こなしての問題

git submoduleの変更をしてないのに、コミット時に怒られた

.git/configの参照パスが壊れてたみたい。
パスを直したらコミットできるようになった。

具体的な対応内容は、忘れちゃった。。。
たしか、下記のstackoverflow見てた気がする。

git submodules - How to "resolve fatal: Not a git repository"? - Stack Overflow

なぜ起きたのか考えたが、多分、submoduleを別ブランチで動かしたりしたときに壊れた気がする。

レビューでの理由を述べない指摘

レビューしてもらう機会があったのだが、ただどうすればいいかだけ指摘するの、やめてもらえませんかね?
それ、指摘じゃなくて指示だから。
もしくは、独り言か小言。

指摘をするなら、なぜこれがダメなのか述べないと、ダメだと思うんですよね。
あきらかなイージーミスとか、理由が推測できるのならいいんですけど、指摘理由が分らないのは、奴隷扱いされているようでムカつく。
そういう指摘があったら、理由を述べよって返すようにしてる。

JavaでprivateメソッドのJavaDoc

俺は、何にでもJavaDoc書く派なのだが、書いたら消せと言われた。
それって正しいのだろうか?

そこまで書いちゃダメなものなのだろうか?
前提条件ありのメソッドだったので、前提条件を書いたのだが、それ書かなくていいの?って思ったわ。

JavaDocって、書くほうを推奨すべきだと思うんだよね。
JavaDocを極力書いて、インラインコメントは極力書かないってポリシーでいる。

Android Studioでbuildエラーの詳細を見る

Toggle Viewを押せば、エラーの詳細内容を見れる。
デフォルトビューで、エラー起きた時に、「詳細を見ろ」的なことを言われたが、「どこに詳細があるねん!」って思ってた。

もうちょい早く気づいてたら、エラー対応は早くできただろうな。。。

最近の近況

DL4J

DL4Jの使い方を学ぼうと思ったが、難易度のレベルが違いすぎて、時間がかかり過ぎると判断。
まずは、Mahotから習得する。

学習の道筋は、Hadoop→Mahot→DL4J

まわり道になってしまうが、しょうがない。

【読書ノート】イノベーションのジレンマ

イノベーションのジレンマ 増補改訂版 (Harvard Business School Press)

イノベーションのジレンマ 増補改訂版 (Harvard Business School Press)

まとめも

優良企業が失敗する理由

大手企業がイノベーションを起こす努力を怠っていたわけではない。
企業がつまづくのは、既存の蓄積した技術とは異なる知識を必要とされるとき、つまづきやすくなる。

メモ:応用問題だされて答えられないパターンだろうか?今まで培ってきたものが役に立たないって、結構、絶望的よね。

過去に築いてきた能力の価値が、技術革新によって破壊された時に失敗し、新技術によって能力を高められれば成功する。
大手企業は、顧客が製品改良を求めた場合、開発と採用に必要な資源と手段を集めてきた。
顧客が必要としなければ、技術的には簡単でも、商品化不可と判断する。

メモ:大手企業になればなるほど、顧客に縛られる。つまるところ、日本でイノベーションが起きにくいのは、現状維持を重視する国民性とも言えそう?

戦略的技術マネジメント=Sカーブ曲線の見極め。後継技術の乗り換え時期である古いSカーブと新しいSカーブの交差を見極めるのが課題。カーブの交差を見極めに失敗する=企業の優位性を失う。

破壊的イノベーションは、Sカーブの交差点がない。別の指標で見る必要があり、一定の品質まで達すると、既存の技術の駆逐が始まる。すなわち、既存の実績ある企業が駆逐される。

メモ:駆逐してやる!一匹残らずってのは、技術界隈でもありえることなんだな。

破壊的イノベーションへの対応

顧客=破壊的イノベーションより持続的イノベーションを求める。
顧客の声を聞きすぎるのは、破壊的イノベーションのリーダーシップを失わせ、誤った方向に導くこともある。

メモ:たしかに、いまあるものにどうしても目が行ってしまうからな。。。それを打破するのは、アニメとかで出てくる近未来的なガジェットだろうなって気はする。

破壊的イノベーションに企業が直面した場合、検討事項が実績ある/なしで違う。
実績ある企業は、顧客を指標から外すことができず、顧客の声を重視してしまう。
また、複数の技術構造を同時に持つことは、コストが余分にかかるえでに収益モデルを平穏に共存させる必要があるため、極めて難しい。

破壊的イノベーションに取り組む場合、持続的技術以上にリーダーシップが重要になってくる。
また、短期的な成長と利益を満たせないリスクがあることも忘れてはならない。

イノベーションのマネジメントは、先駆者有利とは限らない。
追随者の方が、いい場合もある。
重要なのは、先駆者・追随者を判断すること。

メモ:後追いを選べるのは、社内の技術力を把握してないと難しいかも。後追いでも十分追いつける技術力を持ってないと、判断しにくいかもね。

持続的技術→先駆者に優位をもたらした事実は、ほとんどない。
破壊的イノベーションに対しては、リーダーシップが極めて重要。
開拓された市場に遅れて参入しても、市場の拡大は難しい。

破壊的技術の市場は、企業と顧客が市場の価値を見出す必要がある。
破壊的イノベーションに直面したとき、マネージャが打ち出す戦略・計画は、学習・発見のための計画であるべき。
市場の将来性を理解していると思っているマネージャと、発展途上の市場の不透明性を理解しているマネージャとでは、計画と投資のしかたが異なってくる。
実績ある企業では、ほとんどのマネージャが持続的技術の環境のなかでイノベーションを学ぶが、破壊的技術の前では、その知識が役に立たないケースが多い。

メモ:自分を客観視できないと、今の自分の考えを捨てるってのは、難しいかもね。

破壊的技術は、不透明な環境の中にある。そのため、予測ができない。
破壊的技術の中で信頼できる事実は、専門家の予測は必ず外れることだけ。
破壊的技術で重要なのは、実験室等で活動することではなく、発見志向で市場を探索すること。
新しい顧客と新しい用途に関する知識を身につけ、それを分析することが必要。

メモ:暗中模索が破壊的技術のデフォルトってことかな?闇を支配する力を得る必要があるという厨ニ的なワードしか思いつかない。

組織の能力は、資源・プロセス・価値基準によって決まる。
資源=資産とも言える。質の高い資源が豊富にあれば、変化に対応できる可能性も高くなる。
資源だけ高めても、組織の能力が高くなるとは限らない。価値の高いアウトプットを作るには、プロセスや価値基準が必要になってくる。
プロセスは、付加価値を高める作業。明文化されたものもあれば、暗黙的なプロセスもある。
プロセスは、ほとんどの場合、柔軟性に欠け、変化に対応しづらい側面を持つ。
価値基準は、組織の仕事の優先順位を決める基準。倫理的意味合いが強い。
組織の価値基準は、従業員が決定する。組織が複雑になればなるほど、従業員の一貫性のある明確な価値基準が浸透しているかが重要になる。

メモ:資源は、要求されるプロセス・価値基準を再現するために必要になってくる。

破壊的イノベーションに既存のプロセスは通用しない。
破壊的技術の前では、プロセス・価値基準が崩れるため、既存のやり方を流用するだめでは無力。
適切な資源を問題に配分するだけでなく、資源が働く組織に、プロセスや価値基準が問題解決にふさわしいかどうかも調べる必要がある。

組織の設立直後は、資源である人材に依存する。時間が経つと、それが徐々にプロセスや価値基準へと移り変わる。
この移り変わりに失敗すると、先駆者の優位性を確保しても衰退する。
企業文化は、従業員が一貫した行動を自主的にとるようになるので、マネジメントをするうえで強力な手段になる。
しかし、文化ができるということは、同時にできないことも明らかになるため、企業が直面する問題が変化した時に、無能ができる原因にもなる。
変化に対応する能力を持つことも必要。

  • 現状のプロセスや価値基準が適してないと判断したときにとれる選択肢
    • 適したプロセスや価値基準を持った別組織を買収
    • 現状のプロセスや価値基準を変える
    • 独立した別組織をつくり、その中で新しいプロセスや価値基準を育てる。

買収による能力獲得には、買収した企業のプロセスや価値基準が成功の根源であるかを見極める必要がある。
成功の根源である場合、統合は辞めるべき。なぜなら、プロセスや価値基準が変わってしまうから。
しかし、買収の目的が、資源の獲得であった場合、プロセスや価値基準は共有すべきなので、統合を図るべき。
プロセスを帰る場合、既存の組織構造の変更、経営陣の意識改革が必要になり、非常に難しい。

  • 破壊的技術の一貫した性質
    • 市場が変わると、弱みが強みになる
    • 既存の確率された技術より、低価格・高信頼性・便利

まとめ

  • 市場が求めるものからは、破壊的技術は生まれにくい
    • 顧客の意見は、持続的イノベーションに取り組む際の指標としては使える
    • 現状分析し、会社が直面している問題が破壊的なのか持続的なのか判断する。そのためには、軌跡フラグが有効
  • イノベーションマネジメントは、資源配分の結果が反映される
    • 資源を投入しなければ、成功しない
    • イノベーションマネジメントの難しさの一部は、資源配分が複雑であること
    • 判断を下すには、膨大な知識と経験を身につけたスタッフが必要になる
    • 破壊的技術に資源を集中するのは、難しい。
  • 市場と技術の組み合わせ
    • 成功している企業は、持続的技術の改良・提供する能力に炊けるが、破壊的技術だと目的に合致しない
    • 破壊的技術を既存の市場やニーズにあわせようとすると失敗する
    • 破壊的技術の特性を評価し、市場を開拓することが必須
  • 組織の能力は、経営者が考えるよりも専門家されており、特定の状況のみに対応できる
    • 特定の新技術を特定の市場に持ち込む能力はあるが、別のやり方で市場に持ち込むのは困難
  • 破壊的技術に直面したとき、判断するための情報はない
    • 何が正解かわからないので、固執した考えを持つのは危険
    • 試行錯誤する努力と、失敗に寛容になる必要がある
  • 一面的な技術戦略は適切ではない
    • 破壊的/持続的技術を見極め、先駆者・追随者になるかを判断する
    • 破壊的技術は、圧倒的に先駆者有利
  • 障壁の定義
    • 経済学者は、資産や資源を重視したがる。しかし、資産や資源のある大企業が、必ずしも破壊的イノベーションに成功していない
    • 実績ある企業が障壁を乗り越えるには、問題の内容を理解し、支援する環境を作り出す必要がある。

破壊的技術の原則

  • 企業は、顧客と投資家に資源を依存しているため、破壊的技術に十分な投資ができない
  • 小規模な市場では、大企業の成長ニーズに答えら得ない。破壊的技術は小規模な市場からはじまる。ゆえに、破壊的技術への投資がやりにくい
  • 破壊的技術は、まだ存在市場にたいするもので、存在してない市場は分析できない
  • 組織の能力は、状況が変わると無能力になることもある
  • 技術の供給は、市場の需要と等しいとは限らない。

2019/01/28週 気づきと振り返り

業務こなしての問題

SafariでOauthのImplicitフロー

認証回りの実装をしているのだが、SafariでImplicitフローの動作確認で引っかかった。

最初のGoogle認証画面に飛ばすのはいい。
問題は、再認証のためにhidden iframeを使ったとき。
サイト超えトラッキングがデフォルトで無効にされているため、アクセス時にエラーになった。。。
設定変えればなんとかなるんだけど、それに気づくまでにかなりの時間を割いてしまった。。。

おかげで、今週の成果物がまたゼロだぜ。。。

Google Oauth Implicitフロー

Implicitフローを実装しているのだが、id_token_hintが必要なことに気づくのに時間がかかった。
ドキュメントを何度も読んでやっと分かったレベル。
id_token_hintは、ユーザを特定するのに必要だって、最初から書いてくれねぇかな?って思う。
ヒントだから、あってもなくても、問題は解けるんだろう?って思ってしまった。

思うんだけど、Oauthの認証って、何がどういう役割なのか、使ってみないと分からないのが、分かりにくさを後押ししてると思うんだよね。
抽象的な概念の説明を結構見るんだけど、いざやってみると全然分からないってのが、Oauth認証の辛いところだと思う。
バカの壁を乗り越えるのに、かなり苦労する。

愚痴

ゼロ~

今週も成果物ゼロだぜ!

今年に入って、まともな成果物って何も作ってない気がする。。。

やるのは、週次リリースの物件を固めたり、障害調査したり、パフォーマンス調査したり。。。
機能を作るって作業がまったくない。
障害対応も、最新バージョンで対応済みですって内容だったから、ただ疲れただけだった気がする。

周辺の人が、いろいろ成果物作ってるのを目の当たりにすると、かなり焦るのだが、同じ気持ちの人はいるのかな?
週次リリースのときの対応内容確認も、俺に対する嫌がらせ?って思っちゃうよね。
他の人は、こんだけ成果上げてますよって、見せつけられてる気分。
惨めな気分になるのを堪えるので精一杯です。

嫌な季節

もう、2月に突入か。。。
2月ってさ、ヴァレンタインというクソイベントがあるから嫌い。

チョコ渡されたら、舌打ちしてやる。

何というかさ、すげぇ見下されてる感じがハンパないんだよね、ヴァレンタインって。
このクソ文化考えた人って、そうとうな差別主義者だと思うわ。
このイベント、人間関係を壊し、負の感情をバラ撒いていると思うんだよね。
この負の連鎖を、断ち切らなければいけないと思うんですよ。

日本人は、チョコなんて食わず、節分の豆食ってりゃいいと思うわ。

抱えてる問題

文章解析

最近、文章のベクトル化ってのに興味をもっていろいろ調査しているのだが、Java機械学習って面倒臭くない?
DeepLearning4Jを使おうと考えているのだが、何をすればいいのか全然分からない。
そもそもパラメータの意味が分からないから、どうしていいのか分からない。
本読んだりもしてるけど、基礎的な知識不足なのか、書いてあることが全然分からん。。。
抽象化された知識はあると思うのだが、それを使えるレベルまで深く理解しているかは、別問題だなってのを実感している。

もう、Pythonに逃げようかな。。。

2019/01/14週 気づきと振り返り

業務こなしての問題

ビルドシェルと変数

ビルドシェル書くのはいいんだけど、ファイルを跨いで同じ変数を使うの、辞めてくれませんかね?
同じ変数を使うのなら、1ファイルにまとめとけよって言いたい。

定数じゃないのを安易に複数ファイルに跨がせるのは、混乱の元。
実際、俺は混乱した。

ハッピーマンデー反対

各週リリースが火曜なのだが、1日のバッファである月曜がなくなるのはキツイ。
あと、月曜って、週初めのところが多いから、勤怠が合わないと結局無駄時間が生まれて、意味がない。
調整しろって思うやつがいるかも知れないが、調整にも時間がかかるんだよ?

ハッピーマンデーの導入を考えたやつは、頭がお花畑か、まともに仕事してないかのどっちかだろう。

体調不良

熱は出てない。
鼻詰まりと喉を痛めて、呼吸がやりづらく、頭痛がひどかった。。。

鼻の通りは、マジで生命線。

あと、寝込んだときは手洗いうがいを習慣にしようと思うのだが、健康になるとなんにも思わなくなる。
昔は、手洗いうがいは習慣になっていたんだが、今じゃ、やろうとも思わないな。

SpringBootCLI + Groovy で "Hello Saga!"

きっかけ

安かったので買ってみたSpringBootの本に、Groovyで動かしている内容を見て、興味が湧いたので真似てみた。

実験

環境

OS

$sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.2
BuildVersion:   18C54

Spring Boot CLI

$spring --version
Spring CLI v2.1.2.RELEASE

homebrewで入れようとしたんだが、xcodeのバージョンが古いからダメですと言われて、かなり萎えた。。。
xcodeって、サイズが大きいから、アップデートするのシンドいんだよね。。。

ちなみに、homebrewでの入れ方は、下記。

$ brew tap pivotal/tap
$ brew install springboot

Groovy

Groovy Version: 2.5.5 JVM: 11.0.1 Vendor: Oracle Corporation OS: Mac OS X

実装

作るのは1クラスだけ。

@RestController
class App {
  @RequestMapping("/")
  def saga() {
    "Hello Saga!"
  }
}

Groovyだと、直後にメソッドから抜けることが確定してる式は、returnを省略できるので、"Hello Saga!"だけでいい。

実行は、spring run app.groovyでOK
しばらくすると、お馴染みのSpringBoot起動のコンソールが流れるはず。

俺の環境では、実行までにかなり時間がかかった。
こんなに遅かったか?と思って、Javaで書いたのを実行したら、ものすごい速かった。
groovyファイルをコンパイルするにしては長かった。
メッセージの内容をみていると、依存関係の解決が長かったので、groovyのコンパイルにひきづられて、何かの依存関係の解決もやり直しになってるんだろうなって推測。
詳しく調べるとハゲそうなので、とりあえず保留。

実行して、ブラウザでアクセスすると、Hello Saga!って出るはず。

ちなみにJavaで書いた時の記述

App.java 
@RestController
class App {
  @RequestMapping("/")
  public String saga() {
    return "Hello Saga!"
  }
}

groovyは、java特有の宣言記述が省略されてるのがよくわかる。

参考サイト

Spring Boot CLI と Groovy 7行で Hello, world! してみる - Qiita

【書評】最新JavaScript開発〜ES2017対応モダンプログラミング

まとメモ

JavaScript解説

ECMAScript

JavaScriptから言語仕様を抽出した規格。
ブラウザ操作のAPIであるDOM等を除いたものが定義されている。

Node.js

Node.jsの登場でJavaScriptCLIとして動くようになった。

JavaScriptの使われ方とその問題

複雑化に対応するために高速に進化した反面、クロスドメインで使われることが多くなった。
他言語エンジニアが片手間で書いたコードは、メンテが難しく進化に対応できていないことが多い。

APIサーバーとJSの分離による解決

APIサーバーとウェブクライアントが分離されることで、言語が入り混じることが少なくなった。
しかし、まだドメイン知識が重複してしまっているところがある。

今は、Node.jsの登場で、APIサーバーも構築できるようになっている。

JavaScriptの始め方

Node.jsのインストール

windows:Nodist
mac:anyenv+ndenv

トランスパイラ

コンパイラのようなもの。
JavaScriptを吐き出すのが仕事。

  • babel
  • webpack loader

バンドラ

複数ファイルを1ファイルにする。
モジュール開発しつつ、Webブラウザ上でうごくものを開発できる。

  • browserify
  • webpack
  • rollup

クセがどれも強い。

型の恩恵を受ける

Flow

静的な型チェックを行う。
プロジェクトの一部分に導入できることもできる。

型の概念は、TypeScriptに似ている。
mixed・合成型って型があるのが特徴的。

ユニットテストをしよう

  • AVA
    • テストの並列実行可能
    • 並列で処理するため高速

TDD

  • チケット駆動開発
  • 設計・開発のための技法
  • 雑な作りから、より洗練されたコードを作って行くのに向いている。

黄金サイクル

Red→Green→RefactorのサイクルがTDDの基本。

Red:テストだけ書く Green:テストを通る最小限のコードを書く Refactor:リファクタリングしてコードを洗練させる。

最初は、コンパイルエラーが出ず、テストに失敗する状態を作る。
テストも偶然通るような実装にはしないほうがいい。正しい実装に変化したことがわかりづらくなるため。
テストが通るようになったら、リファクタリングを行う。
この際に、挙動を変えないように注意する。
挙動が変わったかどうかは、テストの実行で確認する。

十分に仕様を設計・実装できていると確信できるものに対しては、サイクルを回す意味は薄い。

ウェブブラウザ向けの開発におけるテスト

E2Eテストは、書かなくて済むのなら、書かないほうがいい。
やる場合、テスト実行時間が長いこと、非効率であることに留意する必要がある。

E2Eテストの選択肢

  • Selenium WebDriver
  • Pantom.js
  • SlimerJS
  • Nightmare

Appendix JavaScriptの歩き方

できる限り公式ドキュメントを読む

日本語の情報は、古くなってる可能性が高い。
JavaScriptは開発が活発であるため、翻訳が追いつかないことが多い。

英語が苦手な人は、Google翻訳でOK

公式以外

  • stack overflow
  • Qiita
  • jser.info

技術選定には注意する

JavaScriptは、新陳代謝が早い。
今主流でも、2・3年後には、非主流になっていることもある。
スタープログラマでも、技術選定でミスをする。
JavaScriptでうまくやっていくには、技術に対するアンテナ感度を上げておくことが必要。
基礎*1をしっかり作ることが大切。
マルチパラダイム言語であるため、他言語の知見を知っておくことは、技術選定ミスを犯しにくくさせる。

  • Google検索する場合は、1年以内のデータに絞る。
  • Githubのスター数

エンジニアが身につけるべき基礎力

名前をつける力

  • 名前を正しくつけることは、責務の抽象化能力
  • 名前から責務の範囲を考える
  • 名前にお約束を設ける

ウェブ

  • HTML5.1の仕様
  • CSSの仕様
  • React + Redux
    • シンプル
    • パワフル
    • 学習コストが高くない

感想

読んでて、俺は基礎ができているのか?って不安になる。
不安になるってことはできてないんだろうな。

HTML5/CSSの仕様は、読んだことがない。
利用するときに探すだけってことが多い。
一回くらいは、目を通したほうがいいかも知れない。

*1:個別の細かいやり方ではなく、汎用的な手法や本質的な知識

2019/01/07週 気づきと振り返り

業務こなしての問題

Androidのprogaurd

年を跨いで対応していたが、いろいろひどい目にあった。

いじっていたが、何がダメなのか、袋小路に入って、ひたすら悩んでいた。
progaurdが無効のまま、progaurd.proに修正入れても反映されないでいろいろ悩んでいたりした。

もう、今となっては些細な問題だと思う。
仕組みをなんとなく覚えられたので、もう同じ轍を踏むことはないと信じたい。

package.jsonのdependenciyの削除

uninstallで消しましょう。
記述を削除すると、インストール済みのものが残ったままになり、間違って使ってしまって、他人がビルドしたとき、もしくは、CIかかったときに慌てるハメになる。

前にも書いた気がするな。。。

Androidのログ

タグは、パッケージ名を参考にしたほうがいいのではないかと思いました。
なぜなら、フィルタリングが楽になると思うから。

現場のタグ名が、クラス名になっているのだが、実装したクラスのログすべてをフィルタリングしたいってときに、どうすればいいのかかなり迷った。
結局、いい方法が思いつかなかったので、全出力で皿目で見るという作業になってしまった。

マジでタグ名をどうするかは、真剣に考えたほうがいい。

getter/setterの価値

俺は必要ないと思う派。

それなら、ただのpublicフィールドでいいじゃんって感じる。

カプセル化って言う人をたまに見るが、「ロジックが必要ない箇所に適用して、何か意味があるの?」って思う。
ロジックがないなら、普通にそのフィールドにアクセスしているのとなんら変わらないじゃんって思うんですよ。

JavaだとLombokが一時期話題になっていたが、そもそも単純getter/setterは必要ないと思っていたので、熱は早めに冷めた。

無力感

1ヶ月くらい、成果物を作ってない気がするのだが。。。
調査した結果、対応を見送る、難易度高すぎて諦めたタスクがいっぱいある。。。

存在意義とか、自分の能力を疑いたくなっちゃうよね。。。
他の人はタスクこなしているのに、俺だけ取れ高ゼロだもんな。。。

個人的に思いついた名言

  • 俺は組織の爆弾になる。潤滑油になどなるものか!
  • やればできる子なんだ。今はやらないだけなんだ。