エンターテイメント!!

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

2018/09/10週 気づきと振り返り

やったこと

  • サーバーとの疎通確認

気づき

superagent

withCreadentials() → Cookie送ってくれるやつ。
Access-Controll-Allow-Originが * のときは機能しない。

tsconfig

es5 → es2018
targetだけじゃなく、libも変える必要がある。

chromeのSet-Cookie

アクセスしているサーバーと別ドメインのサーバーからSet-Cookieが来た場合、ChromeのDevToolのNetworkタブでは見えない。

ただ、実際には設定されている。

見る方法はない。

振り返り

ChromeのSet-Cookie

疎通確認でマジ困った。
あるはずのSet-Cookieがなんでないの?って2日くらい悩んだ。
結局、Cookieは正しく設定されていて、その他がおかしかっただけだった。

Chromeで開発する場合は、Set-Cookieは最後に疑う。
そうじゃないと無駄な時間を過ごす。

もしくは、他ブラウザで試してみる。

その他雑記

ChromeのSet-Cookieで悩んだ1週間だった。。。

年を1つ取ったが、このままでいいのかにも悩んでる。

メンタルが殺られそう。
今は、購買欲で誤魔化した。
あそびあそばせ」って漫画の電子書籍買ったけど、無茶苦茶面白い。
久々に笑った気がする。
俺が最後に笑ったの、いつだっただろうか?

今は、27日の無双OROCHI3が楽しみ。
もう、それくらいしか楽しみがない。

javaコマンドでjava.dllが見つからないって言われる

現象

Error: could not find java.dll
Error: could not find Java SE Runtime ENvironment.

原因

システム環境変数に、オラクルのインストーラーで入れたときのパスが入っていて、自分で入れたやつと競合してたから。

最初は、参考サイトのSystem32の設定を見に行ってたからかな?って思ったけど、違って迷宮入りするところだった。。。
ラクルのJavaパスは、インストーラーで入れるのをすっかり忘れてた。
たしかに、前に入れたっきりなにもしてなかった気がする。
今もまだ有効なのかな?
インストーラーで勝手にパス設定するのは、そろそろ辞めたほうがいいと思いました。

参考サイト

javaコマンドでjava.dllがどうこうってエラーが出た

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

やったこと

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

気づき

jestでカバレッジ

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

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

カバレッジとテスト

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

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

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

振り返り

テストデータとロジック

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

その他雑記

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

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

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

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

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

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

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

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

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

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

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

【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モジュール作る時に注意したほうがいい事メモ

きっかけ

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

指摘事項

型を排除する

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

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

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

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