2020年の東京競技大会でも、国内外から大勢の観光客が集まり、大会会場周辺で大変な交通混雑となることが予想されるため、ロンドン大会の成功にならい、2017年から2020年までの毎年、開会式に相当する7月24日を「テレワーク・デイ」と位置づけて、テレワーク一斉実施の予行演習を呼び掛けて参ります。オリンピック・パラリンピックを契機として、全国的にテレワークの普及が進み、働き方改革のレガシーとなることを目指します。

だそうです。オリンピックなのに満員電車や渋滞だと困るので家から出ないでね！

的なやつですね。テレワークと言いつつ時差出勤とかもありのようです。

週末会った方は上記の影響で7:30出社だ！て言ってました。

個人的にはそうなったらへろへろになってしまう！わたしはいまは朝はゆっくりで電車も比較的空いてますが早いと…

あ、でも極端に早いと空いてるのかな。

とりあえずSEは朝に打ち合わせとかなければゆっくりでいいでしょ！と思うのでゆとりができるといいなあ。

ただ以前の職場でテレワークできるPCをもらっていましたがいつでもできる分いつでも気になってしまうので制度とかいろいろしっかり作ってもらえるとうれしいです。

2017-07-22

WEBエンジニア勉強会02に行ってきました

勉強会

WEBエンジニア勉強会02

connpass.com

ついった #WEBエンジニア勉強会02 - Twitter Search

資料とかもみんなあげているみたい。

大したこと書いてないですが聞きながらメモ的に書いていたので一応残しておきます。

1. HTML 5.1 と AMP の概要を学ぼう

OSCA先生の発表。

HTML 5.1

HTML5.1のメニュータグについて。VBのアプリとかみたい。業務APでは使っても良いような。ただユーザの意識はないので、右クリックしてね！みたいになるからなかなか広まるのが難しいかもなぁ
HTML5.1の仕様は決まったが、ブラウザの実装はまだの部分も多い。w3cのページを見れば実装可否がわかる
- 5もあるのかな。見てなかったなぁ。。。

AMP

低スペックの携帯への対応。軽量なサイトに対応。
CSSやJavaScriptの使用に制限がある
対応するとGoogleのCDNにキャッシュしてくれる

Let’s Encrypt

無料でサーバ証明書を発行できる
デモやってくれた！

ブラウザ自動テストツール Selenium

コードの説明すごくわかりやすかったです！個人的には知っている所でしたが。
WebDriverってただのSeleniumの機能だと思ってた。w3cで定義してたのそもそもしらなかった。。。。
Seleniumのメンテナンス問題はあるよなぁ。。。現場で導入したけど結局メンテナンスしないとかいろいろあった。。。。
ページオブジェクトパターンを使うときれいになる。
- 1Javaクラス１ページに切り出す。そのページで行えることをメソッドに定義する。
- フィールドに要素を入れる。Byクラスのオブジェクトをフィールドにおいてしまう。
zalenium dockerファイルを準備して録画してエビデンスの検索とかもできる

LTの方々

ごめんなさい。メモとってなかったので省略！

自分のLT

5分のLT実施。エラー画面について。

いつも通り早口になってしまった・・・つい忘れてしまう。気を付けなければ。資料は勉強として面白くないのと人のサイトのキャプチャを勝手に使っていて全体公開していいのか微妙なところなのでパスしようかと思います。ごめんなさい！まあネタ見せみたいなもので多少は笑い取れたのでいいかな！

端的にいうとこれだけ。

エラー画面を見ても怒らない
せっかくエラー画面を作るならユーザのことを考え、遊び心を！

あまり内容書いてないし、面白くなくてごめんなさい！

とりあえず若い人も多いし、個人的に良く行くJava系の勉強会と違い、自分が知らない単語も多く出てきたりして、楽しかったです！

また次回。 9月は今の案件のリリース？があるのでどうなるかわかりませんが。。。。

2017-07-20

LTやらせてもらうことになりました

雑談勉強会

WEBエンジニア勉強会 #02

https://connpass.com/event/60947/

5分のLTやらせてもらうことになりました。

エラー画面について

の予定。まだ資料ほぼ作ってないとか言えない…

急遽思い立ったので社内勉強会の焼き直しも考えましたが一応新ネタで。

がんばりますー！

予定がつく方はぜひよろしくおねがいします

2017-07-20

最近さわっているもの、書いておきたいこと

雑談新人向け

ちゃんと書き残すようにしたい！と思い、ブログに書き残したい。いつも途中であきて放置になるんだけど。

書きたいことメモ。とりあえず思いつくやつ。

DockerのJenkins初期設定

Jenkins 子ノードの設定方法

Jenkins パイプラインについて

Javaのあほなコードについて

Eclipseの初期設定、ショートカットキー

（新人向け）試験とは？

試験のエビデンスについて

（新人向け）スケジュール管理について

Java8のもろもろ

Java9のもろもろ

2017-07-17

SIerにいる若手開発者（プログラマ）が知るべき運用とは　その２

システム運用新人向け SIerに入ったら

以下の記事の続きです。

SIerにいる若手開発者（プログラマ）が知るべき運用とはその１ - のんびりプログラムのお勉強でも・・・・・・・

前回で以下を意識してコード書こう！でしめました。今回は具体的に何が必要なの？を書こうと思います。

いつ何が起こったか情報も何もなく、意味不明で何をしていいのかわからない非定型作業
いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業
非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業
手順が整備されていない定型作業
手順が整備されている定型作業
何もしない

「いつ何が起こったか情報も何もなく、意味不明で何をしていいのかわからない非定型作業」から「いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業」へ

「いつ何が起こったか情報も何もなく」→「いつ何が起こったかだけはわかる」が変わっています。ポイントは「いつ」と「何が起こった」です。今回のメインテーマ。

「いつ」がわかるようにする

簡単にいうと何か起こったらすぐ運用者がわかるようにする！です。システム側から教えてあげないと運用者は気付くことができません。つまり、先ほど書いた「監視」もしくは「人間が普段のコミュニケーションに使うツール」を使って教えてあげる必要があります。プログラムレベルでいうと以下を気を付ける必要があります。

想定外の例外などが発生した場合、必ず監視にかかるようにしておく必要があります
- e.printStackTrace()やSystem.out(“エラー発生”)とかやっていると標準出力に出力されてしまう場合があります。Javaだと多くはloggerを使用することが多いです。そのloggerが出力したログを監視して運用者に伝えます。
そのうちITが進歩すればなんでも自動化できるようになるのでしょうが、限界があります。またお金の問題もあります。ごくまれに発生する事象に残念ながら高機能を作ることができません。その場合には運用者に「あとはがんばれ！」を伝えておくことも必要になります。
- 多重障害に対する対応を自動化することは難しくこのパターンに入れておくとよいです。

5W1Hを明確にする

次は「何が起こった」です。「いつ何が起こった」を明確にするため、5W1H（When、Where、Who、What、Why、How）を運用者がわかるようにします。若干の拡大解釈しつつ、注意点を書きます。「いつ」がわかった前提のため、ログにどんな情報を出すべきかが中心になります。下記に例を書きますが、エラーのプログラムをする場合に5W1Hを意識してほしいです！

When

いつ！上で書いた「いつ」と重なりますが、ここでいうのはログの時間です。多くの場合は単純に時間を出せばいいのですが、注意点は以下。

サーバが違う場合、時刻は同期がとれているのか？
サマータイムや国が違う場合の時差は考慮されているのか？

必要に応じて、ただサーバの時刻を出すのではなく、DBサーバなどから時刻を取得してすべてのサーバで出すなど工夫すると良いです。

Where

どこで！いろいろあるのですが、ソース部分のどこで起きたよ！を教えてあげる必要があります。 Javaなら例外発生時はStackTrace出せばわかります。あとは自分でエラーにする場合。エラーログを出して終わりにしてしまったりするのをよく見ますが、IDを出したりどこでエラーを出したかを明確化するとより分かりやすくなります。

Who

誰が WEB APなどの場合、ユーザ情報を出力してあげると誰なのかわかります。BtoCの場合は難しいですが、社内システムなどの場合は、該当のユーザに連絡を取って謝ったりもできますｗ

What

何を。これが考慮されていないログが非常に多いと個人的には思っています。入力されたデータなどをわかるようにします。プログラムのバグの場合、特定のデータが来ると処理に失敗する場合があります。その際に「エラーが出た！」だけ言われても解析することができません。処理しようとしたデータがわかるような情報を出力することで原因解析が早くなります。あと、例えば文字列の処理に失敗した場合にこの文字の処理に失敗したよ！というログを出しているプログラムを見かけますが、これは「What」に答えられていない場合があります。該当の文字はそれはそれでいいのですが、処理中のレコードのpkeyだったり、その他に紐づけられないとその文字でエラーになったのはわかりますが、どこから混入したのか追えなくなるので注意が必要です。

Why

なぜ？このエラーはどんな場合出得るのかを教えてあげます。「エラーが出た！」だけでなく、このエラーが出た場合はDBとの接続に失敗しているから～を見てね、などです。

How

どうやって。何をしようとしていたのか、わかるようにしておくことで原因解析が早くなります。 5W1Hだぜ！っていったけどHowって難しいｗ

「いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業」から「非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業」へ

1個上のいつを教えて5W1Hを伝えれば、運用者は調べることはできるようになります。さらに1歩踏み込んで「何をしていいのかわからない」から「頑張ればなんとかなる」にします。これはソースの書き方というより運用者が調べられるようにすることです。

主にはドキュメント。1つは設計書をきれいに書きましょう！ってことです。さらに言うとこういうエラーの時にはこれを見てね！というのがあるとなおよいです。

意図しないエラーで発生頻度が低いものはここまで持ってくるのが限度だと思います。

「非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業」から「手順が整備されていない定型作業」へ

どんなエラーが発生するのか運用側に伝えてあげます。エラー一覧みたいなやつですね。この状態だとエラー内容が頭に入っていたりして、エラー見た瞬間にまたいつものか！みたいなやつです。

影響がないのはいいですが、オオカミ少年みたいになってしまうので、この状態で事象をとどめるのはやめてさっさと直すか次の段階までは進めてください。ただ現場行くと意外とこの状態でとどまっている事象が多いです。ずっとプロジェクトにいる仙人みたいな人が直したり、影響ないよ！って言ったりしているパターンです。

運用は人に依存するのは排除すべき！

「手順が整備されていない定型作業」から「手順が整備されている定型作業」

エラーなど運用作業に対して手順書を作成します。シェルなどを作ってあげてでなるべく手順を簡略化するとさらによいです。

よく見かけるのがメモみたいな手順書ですが、最初はそれでもいいですが、誰がやってもできる手順書を心がけるとよいです。

またエラー出なくても手作業が必要な場合はここまで落としてあげる必要があるため、 5W1Hなどを意識して運用者に情報を伝えつつ、手順書まで作成して誰でもできるようにする必要があります。

何もしない

手順書が作れるくらいだったらプログラマならそもそも自動化しろって話です。無理なのも多いですがｗ

まとめ

2回にわたってプログラマに知ってほしい運用を書いてみました。私自身も若い頃は運用ってよくわからず、とりあえずリリース後に頑張ってくれる人たちだ！ってことで、ほぼ故障みたいなやつを先延ばしして運用で頑張る！みたいにしてしまったことがあります。

実際には運用の方が期間が長くて、人も多く携わるし、お金もかかります。これ誰かが対応するんだな～だったらこうしておこう！みたいな感覚を持ってプログラミングするだけでもだいぶ違うと思います！