エンターテイメント!!

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

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

先週は、書くネタが思いつかなかった。。。

業務こなしての問題

gradleのプロキシ設定

androidで社外で開発されたプロジェクトを開いた際、プロキシを設定する必要があることを忘れていて、半日潰してしまった。。。
リポジトリに存在していることや、ping打ってみたりして、ネットワークの設定がおかしいのは気付いたのだが、プロキシまで考えが及ばなかった。。。
気づかなかった要因は、gradle.propertyだったかが存在してないから、プロキシの設定のことを失念していた。
まぁ、言い訳ですけど。。。

手順書の適時

手順書で、「適時」って書くの、マジでヤメろ!
何が必要なのか、さっぱり分からない。
書いたやつは、クレーム入れて欲しいマゾヒストなのか?
手順書なのだから、判断を読み手に与えるように書いちゃダメでしょう。

クレームの入れ先が社外になるので、安易に入れられないのが腹立たしかった。 もう、適時って書いてあったら、次は発狂するかもしれない。

書いてて思ったが、もしかして、俺ってヒステリック??
普通のことだと思いたい。

CSSで存在しないURLへアクセス

backgraound-imageで、urlにタイポで存在しないURLを打った。
実行時にエラーがでないから、なんでロードされないのか、かなり悩んだ。
キャッシュのせい?とか思っていろいろ調べたが、最終的にタイポだって気付いた。。。
まず最初に、タイポを疑うべきだったな。
というか、エラー吐かれないから、タイポの可能性を排除してしまった。

実行時にcssで不正があったらエラー吐くようにする機構はないものだろうか?

ヒヤリハット

別ブランチへコミット

gitで修正を入れて、submoduleの参照先を別コミットIDにした時、完了したらコミット前にお花を摘みに行った。
戻ってきたら、コミット&プッシュを実行したが、「gerritにレビューが上がってない?なんで?」って思って、コンソールを徐々に上に辿って行ってかなり焦った。
submodule内のプロジェクトに移動してコミット&プッシュしていた。。。
全然関係ないプロジェクトにプッシュしてしまったという事実をしったときの怖さは、半端ない。
gerritに上がっただけなので、取り消しができたのでよかったが、gerritない環境でやっていたら、いろんな人に頭を下げなければいけないところだった。。。
謝ることに抵抗があるので、次からは、マジで気をつける。

雑記

アイディア

twitterの俳句バージョンあればワンチャンいける?

ノートとボールペンでイライラ

ノートにボールペンを使って書いていると、インク出なかったりしてイライラする。
調べてみたが、ボールペンの構造と書く環境に問題がありそう。
ボールペンの先は、ボールが回転することでインクが出ている。
そのため、柔らかい場所に書く際、ボールが回転せずにインクがでないことがあるらしい。
そういえば、メモ帳をテーブルのうえで書く時、かすれたことはないな。
ということは、下敷きをすれば、万事解決になるのだろうか?
なんか、小学生っぽい気はするが。。。

家に下敷きあるんだけど、だいたいアニメのキャラが書かれてるんだよね。。。
無地のやつを100均で買うしかないかな?

もしくは、万年筆に移行か。。。
試しに万年筆を使ったのだが、インクが滲む。。。
あれって、俺の筆圧が強すぎるせい??

部下との面談

こう見えても、チームの長なもので。。。
メンバーのスキル評価を実施した。
話を聞いていると、漠然と作業をしているなって感じる。
話を聞いていると、かなり抽象的で、知見が溜まってないんだろうなって感じる。
おそらく、会社がワーカー(作業者)として働くことを評価してしまっているせいだろうなって思った。

作業者として優秀かもしれないが、エンジニアとしては良くない傾向だと思う。
そもそも、IT業界って、ワーカーみたいなのが多い気がする。
たぶん、下請け構造がワーカーには住みやすいのだろうと思う。
とりあえず、当面の目標は、このワーカー体質を脱却させて、ちゃんとエンジニアとして働くように意識を変えてやる必要があると思いました。
workerからenginerへのジョブチェンジを促すしかない。
少なくとも、何か作業をしたら、知識だけではなく、何か知見・知恵となるように考えを巡らせる方向に持っていきたい。
だから、評価時に具体的な考えが見えてくるまで、質問を深掘りするしかないなと思いました。

会社もワーカーを評価する体質から脱却させないと、いつかはダメになる気がする。
提案?提言?みたいなことをするべきだろうか?
俺は、あんまり自社が好きじゃないんだけど、どうすべきかな?

論文みたいなのを書いて提出してみようか?

パイロットのフリクション

もう、嫌。
いろんなところでストレスを感じる。
まず、ペンが持ちにくい。使ってると、ものすごい手が痛い。
インク切れが早いのもストレスを感じる。インク売るために、ワザと減りを早くしてない?とすら感じる。
消せるボールペンって売れこみで愛用してきたが、最近、使うことにかなり疑問を感じるようになった。
よくよく考えたら、俺って文字を消すケースがほとんどないじゃんって最近気付いた。
消えないボールペンで問題ない気がしているんだよね。

Java12リリース前の予習

きっかけ

そろそろリリースだなと思い、リリース前に予習したくなったから

事前学習

リリース内容

JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)

JEP 230: Microbenchmark Suite

JEP 325: Switch Expressions (Preview)

JEP 334: JVM Constants API

JEP 340: One AArch64 Port, Not Two

JEP 341: Default CDS Archives

JEP 344: Abortable Mixed Collections for G1

JEP 346: Promptly Return Unused Committed Memory from G1

リリース内容の要約

google翻訳かけてサマっただけですが。。。

  • JEP 189
    ShenandoahというGCアルゴリズムを追加。Java実行中にコンパクションを実行するらしい。Javaが停止する時間がスキャンのみになって、ヒープが増えても一時停止時間が同じというのがメリット。
  • JEP 230
    マイクロベンチマークツールをJDKに入れるよ
  • JEP 325
    switch文のcaseに、ラムダ式かけるようになったよ
  • JEP 334 知識不足過ぎて、何なのかよく分からんかったった。。。
  • JEP 340
    ARM64bit用のPortがarm64/aarch64とあったので、arm64を削除してaarch64に統一するよ
  • JEP 341
    知識不足過ぎて、何なのかよく分からんかったった。。。
  • JEP 344
    G1のmixedの一時停止が長期間になる場合、中止を可能にする
  • JEP 346
    Javaのヒープ使用量を鑑みて、必要に応じて未使用のヒープ領域をOSに返すよ

開発者として影響がありそうなのは、JEP 325かな?
switch文死ねマンからすると、あまり気にならないが。。。

実験

環境

Docker使って試しました。
Kitematic使って、Java12環境を構築した。手っ取り早くやれるので、かなり便利

Docker

docker version
Client:
 Version:       18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24302
 Built: Fri Mar 23 08:31:36 2018
 OS/Arch:       windows/amd64
 Experimental:  false
 Orchestrator:  swarm

つかったコンテナは、alpine-java12 ってやつ。

https://hub.docker.com/r/pwittchen/alpine-java12

Java

# java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+29)
OpenJDK 64-Bit Server VM (build 12-ea+29, mixed mode, sharing)

JEP 325: Switch Expressions を試す。

とりあえず、公式にあるやつをパクって試す。

import java.util.Calendar;
import static java.util.Calendar.*;

public class JEP325 {

  public static void main(String[] args) {

    int day = Calendar.getInstance().get(Calendar.DAY_OF_WEEK);

    switch (day) {
      case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
      case TUESDAY                -> System.out.println(7);
      case THURSDAY, SATURDAY     -> System.out.println(8);
      case WEDNESDAY              -> System.out.println(9);
    }
  }
}

曜日の定数を作るのが面倒だったので、Calendarクラスをstaticインポートした。

実行は、下記の手順で実施

$ java --enable-preview --release 12  JEP325.java
$ java --enable-preview JEP325
6

実行したのが、日曜なので、ちゃんと動いているっぽい。
肝は、break要らないってところだな。
breakで泣かされたことがある身としては、進歩したなとは感じるが、やっぱり、利用する気にはなれない。

JEP 325: Switch Expressions を試す。(値を返す)

公式サイトを読み進めると、「値も返せるぜ!」的なサンプルあったので、ついでに試す。

import java.util.Calendar;
import static java.util.Calendar.*;

public class JEP325_2 {

  public static void main(String[] args) {


    Integer day = Calendar.getInstance().get(Calendar.DAY_OF_WEEK);

    int j = switch (day) {
      case MONDAY  -> 0;
      case TUESDAY -> 1;
      default      -> {
        int k = day.toString().length();
        int result = f(k);
        break result;
      }
    };

    System.out.println("switch result. j:" + j);

  }

  private static int f(int k) {
    return k + 100;
  }
}
$ java --enable-preview --release 12  JEP325_2.java
$ java --enable-preview JEP325_2
switch result. j:101

普通に動作する。
当然の動き。

考察

Java12のリリースでは、特に注目している機能はないが、リリースは予定通り行われそう。
直近のリリースで、switch文の改修がかなり入ってくるのは、switch文に熱心な人がコミッターにいるのかな?
switch文押しが強いことに驚く。
GC周りの知識不足が否めない。。。
どうやって学習したら良いのだろうか?

試してみて、Docker&Kitematecが便利だったってのが印象に残りました。
あと、久しぶりにstaticインポート使ったなって思った。

参考リンク

JDK 12

Java12新機能まとめ - Qiita

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

業務こなしての問題

Android で webviewによるアプリ開発

webアプリで開発した資産を、Androidへ簡易的に移植するためwebviewを使っている。
いい案かも知れないと思ったが、パフォーマンス計測していると、省メモリがかなりネックだというのが分かってきた。。。
併用はできるが、メモリの制約が問題になってくる。
実は、簡単そうに見えて、あとあとコストが高く付きそうな気がする。。。

Android webviewのリモートデバッグ

chromeでPerformanceのタイムラインを取っていたのだが、1時間位でアプリがよくクラッシュする。
どうも、メモリを結構逼迫させるみたい。
なので、短時間の計測に使うが良さそう。

長時間稼働させて計測するのなら、スナップショットをチマチマ取るしかない。
ただ、chromeのスナップショットって、どこに問題があるのか、分かりづらいんだよね。。。

雑記

開発環境

開発環境で使ってるサーバーが落ちて、2~3時間、開発がストップした。。。
本当は、開発環境も冗長化する必要があるのだろうか?

ipad落としたのが

ipadを最近落として、画面に盛大にひび割れが入ってしまった。。。
電子書籍見るのをスマホにしたのだが、かなり見づらい。
やっぱり、タブレット電子書籍読むのに適していると感じた。
デスクトップだと、場所を選ぶから、やっぱり、タブレットがいい。

近々、新型のipadが公開されるみたいな話があるから、買うのは、それまで待とうかな?

あと、ゲームするのも、タブレットがいい。
スマホだと小さすぎる。
デュエルリンクスやってると、カード操作を間違うのが痛い。

【小ネタ】JavaScriptでJsonファイルを読み込む

きっかけ

簡単にできるだろうと思ってたことで、結構つまづいたので、晒す。
普段、仕事でJavaScript使ってるけど、どっちかというとネットワーク関連のことばっかりやっている。
プロキシ食わしたり、リトライ処理やったり、Oauth認証したり。。。
ファイル入出力は苦手なんだなって、今になって気づいた。

実装

使ってるとこだけ抜粋

const fs = require('fs');

// 省略

    fs.readFile(path, "UTF-8", (err, data) => {

      if (err) {
        console.log("read err.", err);
        return;
      }

      console.log(data)
    })

調べるとたいしたことはなかったんですけどね。。。
一番ハマったのは、文字コード指定してなくて、予期しない文字が出てきてビックリしたことくらい。
require使って読み込むことも考えたけど、以前にキャッシュされるような話を聞いて、今回のケースだとキャッシュ使わせたくなかったから、fs使った。

想定外のことがおこると、やっぱりビックリしちゃうのは、初心者のころも今も変わらないな。

参考リンク

node.jsで常にキャッシュなしでjsonファイルを読み込む方法 - まーぽんって誰がつけたの?

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

業務こなしての問題

Androidのwebviewでのパフォーマンス

いろいろ計測しているのだが、なぜかmajor gcが起こらない。
おそらく、メモリの割当が、ブラウザで見るのと違っているのだろうと思われる。
たぶん、Java側が割り当てたメモリを使ってるんじゃないかな?
Javaのメモリ使用量見ても、全然増えてなかったし。
メモリの割当が小さすぎて、newの領域がすぐ満杯になり、mainor gc が頻発して、major gcが起こりにくいと勝手に妄想してる。
API見る限り、とくにメモリの設定はないな。
もう、どうしたらいいんじゃ。。。

はぁ。。。
今週も成果ゼロですわ。。。

雑記

大豆腐ってる

どこかで、「大豆腐ってる」って文章を見たとき、「おおどうふってる」って読んでしまった。
正解は、「だいずくさってる」だって気づくのに、かなり時間を要した。
句読点って大事だろう。
句読点をちゃんと打っていれば、読み間違えずに済んだはずなんだ。

文章もろくに書けないやつの文章を読むのは、苦労する。

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カーブの交差点がない。別の指標で見る必要があり、一定の品質まで達すると、既存の技術の駆逐が始まる。すなわち、既存の実績ある企業が駆逐される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

破壊的技術の原則

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