リードタイムアウトや接続タイムアウト(コネクションタイムアウト)の試験方法メモ
リードタイムアウトや接続タイムアウト(コネクションタイムアウト)の試験方法を間が開くたびに忘れてしまうので備忘のために書きます。
※環境によってはダメなこともあるとは思いますがご容赦を。
リードタイムアウト
リクエストするサーバー側でsleepなどを仕込んで、リードタイムアウトの時間までにレスポンスを返さなければ発生させることができる。
モックのサーバーとかを使ってる場合、レスポンスを返すまでの遅延時間を設定できることも。（wiremockというものでは可能）
接続タイムアウト（コネクションタイムアウト）
ホストのところで、例えば、10.255.255.1といった自分の環境にて繋がらないIPアドレスを指定することで発生させることができる。。
適当なホスト（xxxxx.com）だとunknow host exceptionだったり、接続先のアプリを落としていたりしてもAPサーバがいれば500がかえってきたりすることもあるので注意。（環境でいろいろかわると思いますが。）
以上
RestTemplateのHttpServerErrorExceptionやHttpClientErrorExceptionをthrowする
RestTemplateのHttpServerErrorExceptionやHttpClientErrorExceptionをthrowする方法を備忘も兼ねて書きます。
発端としては、JUnitにて、ExceptionHandlerで上記が発生したときのテストコードを書こうとしたときに、newしてthrowしてもハンドリング処理が動かなかったためです。
対応策
HttpServerErrorExceptionクラスを眺めていたのですが、ネストされたクラスとして、HttpServerErrorException.InternalServerError などがあるようでした。
これらのネストされたクラスの例外を作成して、throwすることで無事ハンドリング処理が動きました。
作成方法ですが、以下のcreateメソッドをコールして作成します。
HttpServerErrorException.create(...)
とりあえずのJUnitなので引数の値は適当な値を入れましたが、無事期待通りにthrowできました。HttpClientErrorExceptionも同様にcreateメソッドがあるのでそちらで作成できました。
以上
ヒメタニシが体調が悪そう（ひっくり返る、殻にこもる）場合の対処について
ヒメタニシが体調が悪そう（ひっくり返る、殻にこもる）場合の対処について書いてみます。（旅に出たりできないので、アクアリウムも趣味となりつつあります。）
自分は小さめの水槽で、環境もひとそれぞれ違うと思うので参考までに。
事象
メダカなどを飼っている水槽に、ヒメタニシを入れると、最初のころは動き回ってくれてるのですが、2,3日後には殻にこもって固まってりしてしまうことが続いてました。
水取り換えしたり、別の環境（適当な瓶）とかに入れると復活してくれたりしていました。特に後者の別の環境では、顕著に復活していました。
対処
ネットで調べてみて怪しそうと思ったのが水質でした。水取り換えは3日に1度くらいの頻度で行っていたので、水が汚れていってそれを放置で水質悪化というわけではないと思い、環境面で考えるとソイルと流木あたりが怪しいと思いました。
ネット情報だと、これらが水質を酸性に傾けてそう。そこで水槽にカキガラを投入してみました。すると効果てきめんで、2,3日経ってもいままでのように固まったり、殻にずっとこもらなくなり、しっかり動き回ってくれるようになりました！
カキガラを入れてから、今まで見かけてなかった謎のスネイルも現れ。。。別の課題は出そうですが、ひとまずタニシは元気に活動してくれそうです。
追記
その後、やはりタニシが殻にこもってしまうことがあり、どうやら決定的な対応方法というわけではなさそうです。今は、ソイルが入ってない入れ物に移し替えていますが、そちらだと大体活動しているのですが、やはりちょくちょく殻にこもります。
個体差とかが結構あるのだろうか・・・？
以上
IEで開発者ツール（F12）を表示しているとログインのセッションが維持されない
IEで開発者ツール（F12）を表示しているとログインのセッションが維持されない件。
ログイン機能を持つアプリ作成時に発生しました。
事象的には、ログイン→リダイレクト→メニュー画面と遷移した際に、メニュー画面から他画面への操作を行うと再度ログイン画面を飛ばされてしまう感じ。
原因
原因としては、bootstrapのmin.jsをローカルに落として使っていたのですが、この中に書かれているsourcemapのmin.js.mapのファイルがなかったのが原因だった模様。
対応
min.jsをいじってsourcemapの行を削除したところ、ログイン状態が維持されるようにないりました。
以上
客先常駐が多い会社をやめ、客先常駐をメインとした会社に移る
今回は、「客先常駐が多い会社をやめ、客先常駐をメインとした会社に移る」話です。
やめた話
前の会社は数年前に入社しました。客先常駐がメインという会社ではなかったのですが所属となった部署が、客先常駐の割合が多い部署でした。で自分も例外ではなく自社を離れ客先常駐（SES契約などで）をする流れとなりました。
そうなるとよくある話の帰属意識の低下が起きます。で、経営陣とは分かり合えないところなのでしょうが、会社の人々は帰属意識を高めようと以下のようイベント事を企画します。
- 月一の帰社
- 部署の飲み会
- 社内イベントの参加
個人的には、ほぼ自社にいない人間からすると上記のようなものは面倒ごとでしかなかったんですよね。。。一緒に仕事をした同僚がいたりするとちょっとは変わるのでしょうが、入社後すぐに客先常駐となったうえで上記のようなものはアウェーな場所に行く感じになるのです。帰属意識を高めさせたいのであるなら、自社で仕事をさせるのがまず先じゃないの？と思います。
また、以下の点も気になっていました。
- 毎週の作業・進捗報告を細かくもとめられる。多分燃えても手伝ってもらえないけど。
- 評価面談などの場があるが、上司と仕事をしておらずどうやって評価してるのか謎
このあたりも面倒に感じてしまうところですが（会社に所属してる以上しょうがないんだろうけど）、面談する上司が一度も仕事したことないし、年間10分も話してないんじゃないかとなるとどんな感じで評価されるのか非常に謎なところです。
そして沸点を超える出来事がありやめるに至りました。ずっと客先常駐だったので引き止められても引き取まる要素もなく、固い意志で退職しました。
SESなどをメインとした会社に移った話
上記で客先常駐で文句を書いている感じですが、SESなどをメインとした会社に入社しました。個人的には客先常駐は全然いやではないのです。以下の点で客先常駐はいいなと思っています。（現場によるのかもだけど）
- 新しい技術に触れれる可能性がある
- 客先のリーダーの仕事から色々盗める
ある程度スキルがマッチすれば自社ではやらないような新しめのことをしている現場にアサインされる可能性があると思います。自分はJavaが強味として現場に行ったけど、pythonやらAWSやらNo SQLにも触れることができたので。
また、一部上場の会社とかに行くと若いけどすごい仕事ができるリーダーがいたりしてとても刺激になります。自分ももっと頑張らないと！と感じたりしてました。
そして、新しい会社では帰社や評価の問題も改善されるのかなと思っています。
- 簡単な作業報告書を月に1回出す感じ。（現場によるんだろうけど）
- 自社のやりとりも営業さんが自分のところにきて簡単に会話するだけ
- 給与が自分の作業単価ベースとなる（単価の7割以上）
まだ、始まったばかりですが自社向けの作業も楽になり（がっつり干渉されない）、給与も明確で、自分が頑張りお客さんから評価され単価が上がれば自分の給与に帰ってくる、といった感じで特に不満はない状態。（社員を客先常駐させてる会社は、単価も評価基準にしたらいいのにと思うんすけどね。）
もちろん勤怠が悪かったり、単価が下がればそれも給与に直結しますが、それは自己責任ですからそれはそれで納得できますからね。
上記のように、客先常駐という形ですが所属する会社は移ってみました。期待と不安はありますが頑張ろうと思います。
以上
埼玉から会津若松へのお気に入りの電車のルート
タイトルの通り、埼玉（大宮）から会津若松へのお気に入りの電車のルートについて書きます。
実家が会津なので年に何回か帰省するのですが、何度か電車で帰省しているうちに好きなルートができました。
なぜ電車なのか
自分は田舎の方に行くとなると、車窓から綺麗な景色を見たかったり、気になる駅があれば降りて散策してみたくなる派です。遠い距離の移動となると新幹線もありですが、電車と比べ道中の景色が楽しめないというところはあると思います。
なので、自分はほとんど電車を利用して帰省しています。
埼玉(大宮)から会津若松へのお気に入りのルート
電車で移動するとなると以下のルートになると思います。
※どちらも4時間以上は掛かる。
で、個人的に好きなのは1の方のルートです。こちらのルートだと、日光の山の中を走り、道中、川を横目に移動する場面も多々あり非常に旅してる感があります。また、鬼怒川より先だと車内も空いており、普通列車ではボックス席でゆったりもできるかと思います。
電車の移動だと乗り換えが大変そうと思いますが、快速のマウントエクスプレスという列車があり、これを利用すると下今市駅から会津若松駅まで乗り換えなしで行くことができます。※本数は少なめなのでちゃんと時間確認が必要ですが。
また、マウントエクスプレスはクロスシートなので景色をゆったり見ることができます。左右どちらの窓側でも景色は結構違うと思うので大事かもですね。
自分は実際に以下のルートを利用しました。
寄り道
野岩鉄道や会津鉄道などは電車の感覚が１時間以上あったりするのですが、散策したいところがあれば、快速＋鈍行の組み合わせで途中で立ち寄るのことも全然可能かと思います。
鬼怒川温泉、龍王峡、各温泉駅、塔のへつりなど自然系の観光スポットは多々あると思います。
お得な切符
東武鉄道には埼玉から会津若松までのフリー切符があるようです。これを利用すると1,000円以上は割安で行けそうです。
また、JRでのルートになりますが青春18切符のシーズンであればそれを利用すると安いですね。
以上
DynamoDBのDynamoDBMapper(高レベルインターフェース)でmap型(json型)を利用する
技術ネタです。DynamoDBのDynamoDBMapper(高レベルインターフェース)でmap型(json型)を利用するです。（java）
DynamoDBの項目の属性をmap(json)にした際に、モデルクラスの当該プロパティをMap
以下のように書くと例外が発生。
private Map<String, Object> data;
ちなにみ以下のように書くと例外は出ませんでしたが、Mapの中身に"S"や"N"といった型の内容まで入っていました。
private Map<String, AttributeValue> data;
いろいろぐぐってみたところ変換用クラスを作り、それを利用するように指定することで対処できました。
以下のようなクラスを作成。（javaDocは割愛）
public static class MapConverter implements DynamoDBTypeConverter <Map<String, AttributeValue>, Object> { // 保存時の変換 // @param object 変換元(Map<String, Object>など) // @return Map<String, AttributeValue>に変換された値 @Override public Map<String, AttributeValue> convert(Object object) { // ItemUtilsはawsのsdkに含まれてるクラス return ItemUtils.fromSimpleMap((Map) object); } // 読み込み時の変換 // @param 変換元のMap<String, AttributeValue> // @return Map<String, Object> @Override public Object unconvert(Map<String, AttributeValue> map) { List<Map<String, AttributeValue>> mapList = new ArrayList<>(); mapList.add(map); // ItemUtilsはawsのsdkに含まれてるクラス return ItemUtils.toItemList(mapList).get(0).asMap(); } }
モデルのプロパティに以下のようにアノテーションを書く。
@DynamoDBTypeConverted(converter = MapConverter.class) private Object data;
これだと、Mapの中身に"S"や"N"が入らず期待した通りに動きました。
ちなみに、保存時にこの属性をnullとして保存すると当該属性は登録されず、この属性がnullの項目を読み込むと上記例だとdataはnullが設定されてました。
以上
