雑記
前回から一年以上更新しておらず
お久しぶりです。
最近はお仕事も忙しく、家に帰っても
ゲームかテレビか酒飲んでるくらいな状態
近況を適当に書きなぐっておきます。
最近は、蒸留酒をよく飲むようになりました。
特にブランデーは、ここ最近に初めて買いましたがあれは良いですね。
飲みやすくてぐいぐいいけちゃいます。
いきすぎて日曜とかにやるとちょっと困ったことに
なってしまいますが。。。
そうそう、前回記事にしたC#だとAttribute自作できて
使えば似たようなことができますね。
Javaの場合、ライブラリが豊富で使用するライブラリで
それぞれきちんとアノテーション用意してくれており、
ほとんど自作する必要がないくらいでした。
ただ、使用するライブラリの選定とかめんどいなので
やっぱり私はC#のが好きだなって思いました。
C#を触って感動したこと
最近はC#を仕事で触ってるけどAttributeクラスが結構便利
XmlElementとかXmlAttributeって使うけど似たようなものを
自作できるというのをここ数カ月で知った
好んで使用しているのは設定ファイルを読むとき！！
設定ファイルを読むのにnullチェックだの型チェックだのはつきものだけど
Attributeで設定を入れると最初に定義さえ作っとけば読み込む際にチェックのメソッド呼び出せば設定値の形式がいくら変わっても簡単に作れて再利用性も抜群だった
設定ファイルなんてそんなに読んだあとのチェックに差異はないから一度作ってしまえば別のプロジェクトでもいくらでも流用できるのは嬉しい
あと設定値の入れ物をプロパティで作るだけでPropertyInfoでプロパティを取得も設定もコード上で自由にできる。
クラス内のプロパティをループでぶん回せば、設定ファイルを読み込むロジックを共通化できて超便利
先ほどの属性も定義しとけば入れ物を定義しただけで勝手に設定ファイルの読み込みと値チェックできるのが強い
dryに役立つテクニックということでそのうち記事に起こすかも
2016年
書こうと思ってたけど2016年も終わったし昨年の振り返りを
2016年は初の転職があり、個人的には激動の一年でした。
1月
出荷前で稼働は高かったけど結構楽しかった。
LANの施設とかハードウェアの構築、COTSセットアップの仕事をしていて
ソフトウェア屋よりもネットワーク屋の道もありなのかと
見出した良い経験になる月だった。
2月
初めてエンドユーザーのとこに着いて仕事をした月
お客さんも協力的だし、適度な忙しさで毎日定時で帰れて幸せだった。
その傍ら、退職面談という名の説得をひたすら受けてイライラしてた。
3月
上旬はかなり暇してた思い出
あまりに暇で一日中資格試験の勉強して、
たまに問い合わせ対応したりで精神的安定してた。
下旬は無計画な社内雑務が膨大なのとあまりに同期、先輩が使えなくて
本社の頭と要領の悪さに地獄を見た。
改めて前の会社が糞だったと認識し、脱出できて本当に良かった。
4月
ニートもとい求職者
グラブルにはまって一日中やってたけど遊んで暮らす生活にも10日程度で飽きて
すぐ就職活動を始めた。
前の会社からは「仕事辞めてから簡単に新しいとこに入れると思うな」みたいな
脅しを受けてたけど2社受けて第一志望に受かったのでギャップに驚いた。
改めてブラック企業はすぐ辞めろと若手に言いたい。
5月
下旬に入社が決まってたからひたすら遊んでた。
少し実家に帰って転職の顛末を話しに行って久しぶりの実家で
リラックスできた。
6月
実務しながらお勉強
前の会社と比べて技術力の高さに四苦八苦してた。
PGとして弱小企業で第一線で働けても
大きい会社だと自分はパンピーなんだと気づかされた月
7月
既存プロジェクトの改修を任されて、しかもやり方も自由にやって良いという
最高の環境で仕事ができて楽しかった。
この頃は適度に働いて帰ってはドラマばっか観てた。
最高にエンジョイしてた。
8月
やることがなくなってツール作ってた。
今の設計書を作りたくない病はこの頃の影響なのかも
9月
上司が変わった。
前の上司はほとんど話すことなかったのを少し後悔した。
新しい上司はできる人っぽい印象で少し恐いところがあった。
（今ではフレンドリーで大好きな人）
10月
大炎上プロジェクトにアサインされて休みもなく、
帰りもほぼ終電の毎日だった。
自分の時間が取れなくて辛い反面、
大人数のプロジェクトが楽しかった。
11月
引き続き大炎上プロジェクト
10月の給料がとんでもないことになっててにやにやしてた。
後半は一人プロジェクトにアサインされて平穏を手に入れた。
12月
別部署のお手伝いとして一人で開発みたいなことしてたけど正直地獄だった。
PMがマネジメントしかできない人な上に完全にお客様だった。
あれこれ言うけど自分では何もやらないで一人だけさっさと帰るのにイライラ
とりあえず仕様変更を何でも受けるなっていうのと何でも俺のせいにするなよと。。。
この影響で月末は胃炎に＞＜
終わりよければすべてよしという言葉があるけど
年末結構大変でした。
2016年冬の近況
暫く更新してなかったのではてなさんから
記事を更新するようにとのメールがきたので近況を
激辛フェス
この前友達に誘われて激辛グルメフェス行きました。
激辛の有名店が揃ってるだけあってどれも狂ってるくらい辛かったです。
舌が痺れすぎて辛くないもの食べると甘く感じるくらいでした。
特に美味しかったのはこちらの麻婆豆腐
中華料理美味しいですね。
そのへんの中華屋で軽く飲みながらつまむのが最高です。
ピクルス
昨年に引き続きピクルス熱再燃中です。
冬になるとピクルス漬けたくなるのでしょうか？
お店で出されるものより美味しく作れる自信があります。
色々漬けたけどオーソドックスな胡瓜、トマト、パプリカあたりが一番美味しくできますね。
山芋、にんにくあたりも漬けると美味しいです。
特ににんにくは、ピクルス液全体の風味付けにもなるし一石二鳥となります。
ただし、りんごは冒険しすぎて後悔しました。
映画
今更だけど君の名はと聲の形観ました。
最近は面白そうなアニメ映画が多いですね。
どちらも面白いけど聲の形はいじめを取り上げていてかなり胸糞悪い展開なので
人を選ぶ作品だったと思います。
JAGMOの講演行ってきた話
兄に誘われてJAGMOというゲームのオーケストラ講演を聴いてきました。
JAGMO「伝説の交響組曲 - THE LEGENDARY SYPHONIC SUITE -」
昔からFF好きだったし他のゲームも有名どころが多く、
曲目に、やったことあるゲームが多かったので楽しく聴くことができました。
今までは、オーケストラに行ったことなくてライブみたいなのを
イメージしてましたが、雰囲気が全然違って新鮮でした。
一番安い席で、位置が奏者の後ろで楽器が向いている方向が逆だったので
少し不安でしたが、大迫力を感じられました。
一個残念だったのが、楽しみにしてたFF4,FF5の楽曲がメドレーで一瞬しか
なかったことです。
曲目にない楽曲や、やたらFF10の楽曲にばかり時間をかけていたので
それならと曲目にある楽曲をしっかりやって欲しかったですね。
それを入れても凄い迫力と原曲に沿った演奏なのでゲーム好きなら
絶対楽しめる講演でした。
私も機会があったら、また友達を誘って行ってみようと思います。
DISTINCTにはまった話
postgresqlでDISTINCTを使っていてはまってしまったので
ブログにまとめてみます。
SQLを使用していて重複項目を取り出したくないときは、
DISTINCTを使用します。
SELECT DISTINCT 列1, 列2 FROM 表;
重複を削除するとき事前にソートしたものから取り出したかったので
次のように書いてみました。
SELECT DISTINCT T.列1, T.列2 FROM (
SELECT 表1.列1,表1.列2,表2.列3, 表2.列4
FROM 表1, 表2
WHERE 表1.列1=表2.列3
ORDER BY 表2.列4
) T;
二番目のSELECTで取得した表から列1と列2の重複データを削除してソートした
通りの順番で取り出したかったのですが、結果は順番が狂って取り出されました。
調べてみたらDISTINCTは内部でソートしてから重複を削除するという
処理が働くために起こる現象のようです。
ORDER BYを評価した後にDISTINCTが評価されて意図しないソートが発生してしまうわけです。
対策としては、二番目のSELECT内でDISTINCTし、ORDER BYを一番目のSELECTに対して行う。
これでDISTINCTの評価をORDER BYより先にさせることができます。
ただし、ソートする条件が取得したいカラム以外に指定する必要がある場合はさらに副問い合わせを行う必要があります。
SELECT T1.列1, T1.列2 FROM
(SELECT T2.列1, T2.列2, T2.列3, T2.列4
FROM(
SELECT DISTINCT 表1.列1,表1.列2,表2.列3, 表2.列4
FROM 表1, 表2
WHERE 表1.列1=表2.列3
) T2
ORDER BY T2.列4
)T1;
また、SQLから離れますが、SELECT結果取得後に一意項目を削除する処理をコード上で行う方法もあります。
ちなみに同じ重複を削除する処理として表結合時に重複を削除するUNIONもあります。
こちらも重複削除時は、ソートが走り、意図しない順番になる可能性があるので、
基本的にUNION ALLを使用した方が安全と言えます。
(UNION ALLのが早いしね)
例に挙げた通り、条件が複雑になるとSQLが複雑になり、コードからは追いづらくなります。
