エンターテイメント！！

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

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

パフォーマンス 分析 恥晒し 愚痴 認証 ネットワーク Java

業務こなしての問題

SafariでOauthのImplicitフロー

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

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

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

Google Oauth Implicitフロー

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

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

愚痴

ゼロ～

今週も成果物ゼロだぜ！

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

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

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

嫌な季節

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

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

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

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

抱えてる問題

文章解析

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

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

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

情報収集 愚痴 日記 体調管理

業務こなしての問題

ビルドシェルと変数

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

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

ハッピーマンデー反対

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

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

体調不良

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

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

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

SpringBootCLI + Groovy で "Hello Saga!"

Java FW ネットワーク プログラミング 学習 情報収集

きっかけ

安かったので買ってみた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

実装

作るのは１クラスだけ。

@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対応モダンプログラミング

HTML/CSS JavaScript エンターテイメント 恥晒し 学習

まとメモ

JavaScript解説

ECMAScript

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

Node.js

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

JavaScriptの使われ方とその問題

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

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

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

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

JavaScriptの始め方

Node.jsのインストール

windows:Nodist
mac:anyenv+ndenv

トランスパイラ

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

  • babel
  • webpack loader

バンドラ

複数ファイルを１ファイルにする。
モジュール開発しつつ、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は、新陳代謝が早い。
今主流でも、２・３年後には、非主流になっていることもある。
スタープログラマでも、技術選定でミスをする。
JavaScriptでうまくやっていくには、技術に対するアンテナ感度を上げておくことが必要。
基礎*1をしっかり作ることが大切。
マルチパラダイム言語であるため、他言語の知見を知っておくことは、技術選定ミスを犯しにくくさせる。

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

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

名前をつける力

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

ウェブ

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

感想

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

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

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

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

Android JavaScript ログ プログラミング メンタル 恥晒し 愚痴 日記

業務こなしての問題

Androidのprogaurd

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

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

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

package.jsonのdependenciyの削除

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

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

Androidのログ

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

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

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

getter/setterの価値

俺は必要ないと思う派。

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

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

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

無力感

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

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

個人的に思いついた名言

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

【書評】読んだら忘れない読書術

書評

読んだら忘れない読書術

読んだら忘れない読書術

まとメモ

基本原則

  • 記憶に残す
  • スキマ時間の利用
  • 速読より深読

読書術

ホームラン読書術

たくさん読むのではなく、読みたい本を選んで、自己成長に繋がるものを選ぶ。

守破離読書術

本を読む時、どのステージにいるのかを意識する。

守：基礎を学ぶ基本
破：他人の方法を学べる応用
離：自分のスタイルを学ぶブレイクスルー

自分のレベルにあってないものを読むのは、理解を困難にする。
自己満足を得るだけで、成長は得られない。

入門読書術

入門書で基礎知識と全体像を把握する。
深い学びを得るには必要なこと。

お勧め読書術

推薦されている本は、比較的ハズレを引きにくい。
誰が勧めているのかが重要。

自分軸読書術

売れているかどうかにかかわらず、自分が読みたい本か見極める。

専門書読書術

専門書は、大型書店で。

ネット書店読書術

  • 他者評価を知ることができる。
  • 他者評価は鵜呑みにしてはいけない。
  • レコメンドを使って本を紹介してもらう。

セレンディピティ読書術

自分の興味・関心を理解し、情報フィルターを準備しておく。
必要な本を発見できる確率を上げられる。

直感読書術

本を読むことで、本を見分けるデータが貯まる。
その結果、選球眼が養われる。

数珠つなぎ読書術

参考文献から次に読む本を選定する。
固め読みしたほうが、記憶に残りやすい

失敗しない基準

  • バランス良く読む
  • 長所を伸ばし、短所を克服させる
  • 情報と知識の偏りをなくす
  • ポートフォリオを作る

感想

ちょっと独善的すぎかなって気もする。

2018/12/17週24週 気づきと振り返り

恥晒し 学習 チーム ネットワーク

業務こなしての問題

Oauth認証のImplictフロー

認証周りをImplictフロー利用してやるような実装に変えるタスクにチャレンジ中。
おそらく、refreshトークン使って再認証する処理を入れ込むと、ロジックが複雑になって、難読化するからだと思われる。

実装しているのだが、iframeを利用するのがうまくできない。。。
裏でアクセスさせるのが、途中でコケてしまうのよね。
年末で解決できなかったけど、たぶん、年始の俺が頑張って解決してくれるはず。

submoduleの移動

git mvで移動できる。
設定ファイルをイジって、git submodule sync したりするよりも、手間が少なく安全にできる。
設定ファイルをいじってやる場合、１日無駄に過ごす覚悟が必要。

gerritでhook忘れ

毎回忘れるのだが、新しくリポジトリをクローンしてきた際に、hookの設定をし忘れて、コミット＆プッシュした時に、changeidが付与されず、あとあとコミットメッセージを入れ込む作業をしてしまう。
gerritのクローンコマンドに何か入れられないものなのだろうか？
クローンしてきたら、hookの設定を勝手にしてくれるのが一番嬉しいのだが。。。

logcatの切替

Androidで、logcatを環境ごとに出力するレベルを切り替えたいのだが、どうすればいいか？
build.gradleだったかをイジったが、その設定はダメっていうビルドエラーが出てきて萎えた。

個人的に思いついた名言

  • 明日の俺が頑張ってくれるはず。