2018/08/27週 気づきと振り返り

やったこと

• jest環境構築
• 使用言語：typescript
• jest使ったユニットテスト作成
• superagent-mockをテスト環境に入れ込む

気づき

jestでカバレッジ

jest --coverage で見ることができる。

レポートは予想以上にキレイに出てくる。
テストがきちんと動いていることを対外的に示すのにも有効。

カバレッジとテスト

１００％を目指すよりは、足りてないテストが何なのかを見極めるために、カバレッジを使ったほうがいい。

１００％を目指した場合、リファクタリングを阻害する可能性があるのと、機能追加が難しくなる。

という、結論を現場で出した。
足りてないケースを見極めて、そこにコストかけるのかを判断したほうが、１００％目指すよりは安上がりだと思う。
かけるコストとパフォーマンスを考慮することを考えれば、あえて１００％を目指さないほうが、判断の基準ができる気がした。
１００％だと、コスト度外視して盲目的にＯＫにしがちな気もする。
もうちょい、考慮の余地はありそう。

振り返り

テストデータとロジック

テストデータにロジックを含めてはならない。
特に、モックを使う時は注意が必要。
知らぬ間にロジックを含めてしまい、テストのためのテストを書いてしまうことがある。
テストの理解も困難化する。
ロジックがあることを明確化して、共通処理として抜き出すなどを考慮したほうが良い。

その他雑記

日頃の楽しみが、ランチくらいしかないことに気づいた。
現場の社食が、女子大生考案のレシピだから、喜んで食べてる。
女子大生を身近に感じるって素晴らしいことだな。

遊戯王デュエルリンクス初めたけど、ジェム貯まりづらい。。。

ネットワークスペシャリストの資格試験を受けるのだが、受かる気がしない。。。
受かればそれなりのリターンがあるけど、ダルい。。。
もっとやる気を出す方法はないものか？

もしかして、闇落ちしてる？

最近、生きる意味をよく考えるようになった。
もう、三十路を超え、たいしたスキルがないのに、このままでいいのかということをよく考える。
仕事も常に同じことの繰り返し。定時退社できているけど、スキルが付く／能力が上がったという実感はない。
その結果、生きることに意味を見出だせないのだが、他の人はどう思っているのだろうか？

特に夜がヤバイ。
いろんな不安が、寝る前に一気に押し寄せてくる。
たまに眠れない夜がある。
社会から隔離されているような感覚が、たまにある。

不安に打ち勝つには、考えないようにするしかないって最近分かった。
だけど、それって何の解決にもなってないんだよね。。。

これが、俗に言う闇落ちか。。。
昔は、そんなこと考えもしなかったのにな。。。

何がそうさせているのか？
年齢が大きなウエイトを占めている気もするが、周囲の環境も一因としてあるかもしれない。
解決の糸口が全く思いつかない。
解決するには、逃げるしかない気がする。
「逃げちゃダメだ」なんてアホなセリフ吐いたキャラがいるらしいが、「逃げちゃダメ」ってことはないと思う。

解決の糸口が見つかるまで、もう、考えないようにする。

なんか、すごく女々しいことを書いた気がする。。。
何か趣味を初めたほうがいいのかもね。。。
思いつくのは、ゲームかイラスト書くくらい。
ローグライク系のゲームでもしようかな？

【Software-Design-2018年9月号】書いて覚える S w i f t 入門 新しいフォーマット「SION」の紹介 メモ・感想

設定ファイルの形式

JSON形式の設定ファイルは、関与しているプロジェクトで見たことないけど、本当に流行っているのかな？
俺が古い環境に慣れすぎているかもしれないが。。。
YAMLはたまに見たことがある。大多数がXMLだった。。。
そろそろ、俺の記憶も上書きする時期かもしれない。

YAML

• 直感的
• 人の読み書きも楽

XML

• 一時期は流行った
• デシリアライズが、あまりに重い
• かさばり過ぎ

JSON

• ECMAScript準拠
• プログラマが書きおろすフォーマットがもとになっている
• データ交換にも可視化にも向いている
• コメントが使えない。
• DateやDataがサポートされていない
• objectのキーとして文字列（string）しか使えない

SION

JSONの欠点を保管したデータフォーマット。

サンプルを見たが、JSONに準拠しつつコメントがかけるので、フォーマットしらなくてもプログラマなら理解しやすそう。

感想

SIONの導入で終わってしまった。。。
JSONの問題点からのSIONの利点が分かりやすかった。
Swift使う機会が少ないので、触る機会があれば試してみたい。

【Software-Design-2018年9月号】ITエンジニアのための統計学入門 メモ・感想

データサイエンティストを目指すには

• 必要なエンジニアリング・スキルを「手を動かして」鍛える
• 社内外にアウトプットを出す／フィードバックをもらう
• 一次情報を仕入れる・理解する

「一次情報を仕入れる・理解する」というのが、できてない気がする。
また、最近、妙に気分が落ち込むことがおおく、「手を動かして」鍛える機会も減ってる気がするな。。。

必要なエンジニアリング・スキルを「手を動かして」鍛える

データサイエンスの仕事に従事して役立った経験・スキル

• データ・ログの取得。
• 取得したデータの整形・掃除。
• 分析した結果の可視化。
• データ取得→整形→可視化までの連携処理。
• 実際に運用するためのクラウド・インフラに関する知識と経験

データサイエンスだから、分析や解析の能力が重視されるかと思いきや、インフラの知識のほうが多く問われている。
インフラの知識は、エンジニアとして長くやっていくために必須知識だと思われる。

問題解決能力が必要不可欠とされるのは、どの職種も同じか。。。
読む力、考える力の重要性を認識してないとダメだね。

社内外にアウトプットを出す・フィードバックをもらう

アウトプットするメリット

• フィードバック・意見をもらえる
• 自分の言葉で話す・書くことにより、良かった点や改善すべき点が見えてくる
• 回数を重ねるにつれ、アウトプットの質と信頼が高まる

一次情報を仕入れる・理解する

百聞は一見にしかず的な内容だった。
つまり、データ分析のヒントは現場にある的な内容だったと思う。

そこから価値を見つけて、ユーザに提供しているんだと感じた。

感想

データサイエンティストって、分析・解析が主業務かと思ったが、インフラ構築込でやることが多いのね。
なんとなくだが、インフラ構築が容易化したことで、いろんな分野でインフラ知識が求められている気がしてきた。

あと、やっぱり、「百聞は一見にしかず」なんだね。
聞いたから分かっていると、見て得たことは、知識の定着も違うし、発想の内容も変わってくる気がする。

typescriptでnpmモジュール作る時に注意したほうがいい事メモ

きっかけ

ＩｏＴ向けのコードをtypescriptで書いているのだが、公開する流れになったので、そのときに受けた指摘をまとめる。

指摘事項

型を排除する

typescript使っているからかも知れないが、npmモジュールは、javascriptでも使う。
だから、型情報をできるだけ利用しない形で実装する。

継承よりイベントドリブン

前述した内容に被るが、継承はなるべく使わない。
使う側としては、継承させるより、イベントをハンドリングさせてもらうほうが楽。

Javaでもそうだな。。。
継承を否定するわけではないが、使いにくくなるのは確かにある。

dependency-cruiser を使って依存関係分離をしたメモ

きっかけ

ＩｏＴ機器に載せるソフトウェア開発しているのだが、複数端末で資産流用できるようにしたいらしく、そのためにマイクロサービス化する必要があり、依存分断して構成変えられるように実施した。

その際、依存分断するのにかなり手間取ったから、依存分断するために使った方法をさらす。

準備

環境

OS

Microsoft Windows [Version 10.0.17134.165]

Node

v7.2.1

typescript

2.5.3

dependency-cruiser

4.3.1

dependency-cruiser - npm

インストール方法

• npm install --save-dev dependency-cruiser
• npm install --global dependency-cruiser

どっちかでインストール。

graphviz

2.38

https://www.graphviz.org/download/

binフォルダを環境変数のPathに入れる。
※windowsの話

\graphviz-2.38\release\bin

↑フルパスを入れればＯＫ。

実行

本来はJS用のものなので、typescriptをjsに変換する。 自分は面倒くさいので、前回のbrowsifyのヤツを使ってみる。

suzaku-tec.hatenadiary.jp

実行したコマンドは、下記の通り。
実行場所は、プロジェクトディレクトリ直下。

depcruise --exclude "^node_modules" --output-type dot src/ts/app.js | dot -T svg > dependencygraph.svg

そうすると、dependencygraph.svg が出来上がる。

コマンド実行して、dotが見つからない的なことを言われたら、VSCodeでやっている場合は再起動してみるといいかも。
システム環境変数が反映されてないみたいなので、自分も最初迷ったが、再起動したら問題なく動いた。

app.js から依存しているものが見えるようになる。

使って見て

助かったのは、循環参照とか、かなり深い参照していた箇所。
最初は目で追っていたけど、無理だった。。。

あと、svgで出力すると、dom操作でフォーカス当てたクラスから派生するのに色つけたりできるので、いろいろ便利。
クラス数多いと、色つけると見やすい。

とりあえず、長年、どうやって依存を発見しようか悩んでいたが、これで少しは楽になった。

正規表現の備忘録

ログ調査でよく使うのでメモ。
随時追加予定。

ある文字列を含まない行を抽出

^(?!.(AAA|BBB)).$