runaround’s diary

なんとなく、つれづれ

ベタで何が悪い

こないだ悩んでたDBアクセスまわりのクラスのjar化はうまくいきました。

jar化するプロジェクトの方にJerseyのライブラリ入れてしまっていて、

Tomcat立ち上げの時にJerseyが暴走しちゃってた・・・

 

jar化する方のプロジェクトを見直したらJersey使ってるとこあったけど、

そのメソッド自体使われてないやーんっorz

このクソメソッドめ(こら

いや、読んだらホントにクソメソッドやった・・・

 

メソッド消してライブラリも消してビルド、画面側に取り込んで

デプロイしたら\(^o^)/

Jenkins側にもjar取り込みの手続き書いたから自動化でけたー

いやー、色々環境設定頑張ってくれてる相棒のおかげでサクサク。

ホントありがたい。

 

最近は次にリリース予定サービスの結合テストが始まったわけですが。

久々にイケてない実装が混入しちゃって読んでヘコんだ。

ログ出力ロジックぐらいベタで書こうよー

何でメソッド化してパラメータ文字を連結するんだよー。

後でエラー発生時にソースgrepする時にヒットしにくいじゃんかよー。

何年前のコーディングなんだよ・・・

なんでもメソッド化すりゃええってもんではない。

 

今読んでる本に、

コンパイラにわかりやすいコードは誰にでも書けるが、人間にわかりやすいコードを書くのは大変」

みたいなことが書いてあった。

クソコードは簡単に混ぜ込めるんだよな。(もちろん自分にも言っている) 

 

案外ベタでもわかりやすいコードは存在すると確信している今日この頃。

どったんばったん

毎日ぼやーっと仕事している感じですが、これでも色々考えてます。

あれこれ考えることが盛り沢山なのと、タチの悪い喉風邪引いちゃって体調がぼろぼろ。

今日のTOEICも散々だったなぁ・・・。

来月はちゃんと頑張らねば。

 

今、TOEIC対策として週一でNOVAレッスンで専用テキストで頑張っているのだけど、もっと問題を解かないとねぇ。

本はもう問題覚えちゃうぐらいになってしまったので新しいのを買うか・・・

でも場所とっちゃうしなぁ・・・。

 

うちのシステムのDBアクセスまわりはDomaを使っているのだけど、

共通化(ライブラリ化ってやつ?)したくてプロジェクト分けたのはいいけれど、

jarにしてから他プロジェクトに取り込んでデプロイしたら・・・

画面がうまく起動してくんない・・・

ちっきしょーーー!!!

明日local環境でグリグリして何とかしてやるぅ!(出来るかはわからないw)

 

やりたいことは沢山あるけれど、時間は有限だし他にもやるべきことはあるし。

取りあえず広く浅くアンテナは張り巡らせておいて、気に入ったことは深堀りすべし。

 

来週は勉強会が続くのでちょっとハードですな。

リリースや運用からシステム開発を考えるとチームが幸せになる話

昨日の社内勉強会のスライドです。

speakerdeck.com

 

まぁ、色んな分野や様々な経歴の参会者ということもあって、

かなりざっくり目に書いていますが。

今の現場で実際に実現出来ていることです。

 

もっとスライド作成の腕、磨かなきゃなぁ。

 

あ、あとこれ買いました!今日到着!!

books.rakuten.co.jp

じっくり読もうー。

コードレビューって慣れるまで大変だにゃぁ

咳がなかなか治らない。

明日の社内勉強会で喋るより咳が多い可能性高い(こら

 

先月は所属チームから他のチームにちょっとお手伝いに行ってました。

1ヶ月ほど。

開発環境をオラオラ作って、サンプルコードをオラオラ書いて。

振り返りとかも参加して小うるさい意見などオラオラ言ってました。

 

んで、所属チームに戻ってきてからは改善チケット対応でちょっこし実装したりもしますが、基本的にはひたすらコードレビューのレビュアーになっとります。

 

こんなにがっつりとコードレビューするのは久々?あれ?初めて?どっちだ?

 

元々今の現場に参画した時は本当にきったないコードしか書けなくて。

当時チームにいた一番古株の方にびしばしレビューしてもらってました。

今、私が気づけてることの大半はその人の受け売りです。はい。

凄く的確な指摘をいっぱい貰って凄く納得できることばっかりでしたから。

今その方は別のチームでバリバリ頑張っておられますが。

あとは自分が実装して得たことや失敗して反省したこともあるかなぁ。

 

コードのリファクタリングにしてもそうだけど、コードレビューのルールとかって実際の状況に寄るところが大半ですよね。

一概に「これだ!」みたいなのがあんまり言えない・・・。

そんな中でもリファクタリングで本も出てたり、コードレビューについてもネットに情報を挙げてくださっている方がいてとてもありがたいっす。

いくつか探して、私的にはこれが一番わかりやすくて読みやすくまとまってたと思います。

 

qiita.com

 

レビューイとレビュアー両方について書かれています。

チームにどんどん人が増えていることもあるし、新人ちゃんもいるから職場でシェアしようかなぁ。

自分戦略

あ、そういえばやっとMacBook Proの設定も終わってひと安心。

Chrome入れたんだけどパスワードマネージャーが動かなくてちょっと不便です。

早く直して欲しいなぁ。Safariって使い慣れていないから。

 

来週の社内勉強会の発表資料もMacで作ってみました。

Keynoteは割と使いやすい。

ずっとMicrosoft製品に毒されてきたけれど・・・

発表が終わったらここにでも貼るかなぁ、支障なければ。

 

そして今日はDevLove関西さんの勉強会に参加してきました。

devlove-kansai.doorkeeper.jp

話し手のお二人の経歴が凄すぎて・・・お話も大変興味深かったです。

偶然?どちらの方も誘われてCTOになった経歴をお持ちで、

オフレコな部分があって詳しくは書けませんが共感するポイントも多々ありました。

 

社外勉強会には積極的に参加すべし。

今自分が関わっている技術以外の勉強会にも参加をしてみるべし。

年齢に関係なく新しいことを学ぶ努力は怠らないこと。

勉強会で発表すべし。

 

ざっくりしてますが、アンテナを広げておくといいことが多いんだ、と。

視野を広く持つことも怠らずに。

日々勉強、勉強。

 

そういや今週うちのチームはスプリントの振り返りがありまして。

いつもKPTパターンでやることが多いのですが、

偶然見つけたYWTパターンっていうのでやってみて割と好評でした。

 

hisa-magazine.net

 

Y(やったこと)

W(わかったこと)

T(つぎやること)

日本語かーいっw

 

ここしばらく、うちのチームは隣のチームから2人ほど期間限定で移籍してきていたのでその感想も色々引き出してみたかったんです。

KPTだとP(Problem)が入っちゃう。問題って凄く言いやすいし盛り上がっちゃうんですけど、ネガティブな空気が充満しちゃうし改善策ってその場でパッと出るわけじゃないから好きじゃない。

っていうか問題があるんだったら振り返りまで熟成して置いとくんじゃなくて、その場で何とかする癖をつけた方がいいと思うんですよね。

で、YWTパターンは隣のチームとの違いや元のチームに戻ったらどうしたいかなど聞けてうちのチームにもシェアできて良かったです。

週報にこのYWTパターンの話を書いたらボスから週報フォーマットに取り込んで欲しい!と熱烈な依頼が来たのでw、来週からこのYWTで書くことになりそうです。

とりあえず

ずっと書いていたblogは閉鎖して、こちらでリスタートすることにしました。

といっても古いblogもほとんど更新していなかったんですけどねw

最近はついったやFBやインスタの更新ばっかりだったので。

古い記事はアーカイブしてローカル保存しておかなきゃ。

 

近頃は書けないことが多いのでなかなか書くネタが・・・。

あ、一つあった。

 

人生初MacMacbook Pro)です。

(って言いながらこの文章はレッツノートで書いていますがw)

もー、Win生活が長すぎて、Macはちょっと触るのにいちいちアイポンでググってますが・・・

 

とりあえず次回はMacからblog更新してみて、徐々に慣れてから開発環境構築すっかな。