quattro_4's diary

また同じ過ちを繰り返すと気付かんのか!?

レガシーコード改善ガイド 感想

レガシーコード改善ガイド

レガシーコード改善ガイド

メモ

  • レガシーコードとは、単にテストのないコードです
  • eXtreme Programming:エクストリームプログラミング
  • テストの最大の障害となるのが依存関係
  • 一貫して小さな改善を続ければ、数ヶ月の間にシステムは見違えるような状態になる
  • スプラウトメソッドとラップメソッド
  • Null を渡す (nilを渡すのは便利な手法)
  • 一度にあまりにたくさんの変更をしようとしているのかも
    • 「そのメソッドを壊したら、この場所で変更を検出できるか?」と、問いかけてみることです
  • 仕様化テスト(characterization test)
    • コードの実際の振る舞いを明らかにするテスト
  • 試行リファクタリング(scratch refactoring)
  • 「どうしてもprivateメソッドをテストしたいのなら、そのメソッドはprivateにすべきではない」ということ

感想

  • 長かった
    • 以前少し読み始めていたが序盤で断念してた
    • Javaのコードだったのもあって、コードがある部分は結構飛ばし読み
  • 本が10冊以上くらい紹介されていた
  • この辺りは個人的に結構身につけられていると思うので、斬新な発見はあまりなかった
  • スプラウトメソッドとかよくわからないところもあった
  • テストを壊したり、リファクタリングしたり参考になる手法がいくつかあった

レガシーコードはだんだんそうなるんじゃなくて、書く人や状況によっては最初からレガシーコードなんじゃないかって思った。
ただ、それらを後からレガシーコードじゃなくすることは可能だとわかったし、個人的にテストを重視することを続けてきて良かったと思えた。
自分のコードでさえ、それが1ヵ月以上後の自分にとってわかりにくいコードならそれもレガシーコード。
最近コードを見る時、頭を空っぽにする(前提知識のない人を想像する)ことや、視界を狭めたり(エディタで見える範囲で変数名などの妥当性を考える)広げたりするのをよく意識している。

レガシーソフトウェアについてはレガシーだったり、そうじゃないコードの集大成なので、だんだんレガシーになるもので合ってると思う。

せめて自分の触る部分は、レガシーを生み出さない、レガシーを治すようにしたい。


最近テストが落ちるような変更をしてコードを改善していく手法を、自分で発明したかのように思っていたのだけど、
(→ テストをわざと壊して効率的に開発する - quattro_4's diary
色々試して場合によっては破棄するという点で「試行リファクタリング」とほぼ同じなんじゃないかと気づいた。
昔からあったものだった。

それと、過去の自分まあまあ良いこと書いてあった
新装版 リファクタリング―既存のコードを安全に改善する 感想 - quattro_4's diary



10+h
Speed 3/5
★★★★★
10-FEET - nil?

個人的に最近新しく聴いてる音楽

以前も聴いてる音楽を振り返ったことあったけどまたやってみる

特にYATSUI FESきっかけでいくつか聴くようになったのもある
SATANIC CARNIVALまた抽選落ちたし、PUNK SPRING FINALだったし、パンク離れするのかもしれない


岡崎体育 - 感情のピクセル

YATSUI FESで見たけど良かった
MCとかネタとか全体通してコントみたいな雰囲気で完成度高いし楽しい
ネタ系の楽曲ばかりが目立っているけど、アルバムの後半にある真面目な曲もかなり良い
打ち込みすごい

岡崎体育 - スペツナズ



sumika - ソーダ

今年発見して一番のお気に入りはこれかな
テンポにしてもメロディーにしても自分好み
最近量産されている速い4つ打ちバンドとは一味違う感じもして良い
一曲の長さでsumikaが分かる動画 - YouTube


never young beach - 明るい未来

21世紀のバンドでこんなトロピカルなの聴いたことない

兄は高橋一生


yahyel - Once

YATSUI FESで教えてもらって見た
使っている機材とかの関係か、クラブ系に分類されたりもするらしく、コメント欄とかでアンチに変に批評されてて不思議
実際ライブで聴いた感じは、むしろ爆音(ラウド)系に思えたのと、曲と連動する映像にこだわっている部分もよくわかった
個人的にはFACTに通じるものを感じた(作品では素顔を見せない。海外志向っぽいこだわり)
たまにラウド系を含みつつ、映像面含めてSigur Rós的な神秘的な路線を目指せば面白いんじゃないかとは思っている
スペル、名前(ヤイエル)が覚えられない


ラブリーサマーちゃん - 青い瞬きの途中で

YATSUI FESに誘ってきた友達にすすめられなければ見つけることすらなさそう
すごい洋楽も聴いてて詳しい感じ
打ち込みもいろんな楽器もできて、自分で作るし演奏もする
SoundCloud



全体まとめると、作ることにこだわるいかにもクリエイターみたいなアーティストばかりで、岡崎体育とかラブサマとかここに挙げていないがtofubeatsとか、一人で宅録してたりするしすごくて応援したくなる
自分の仕事的な部分と重ねて良く思えるのかもしれない

あなたのセキュリティ対応間違っています 感想

あなたのセキュリティ対応間違っています

あなたのセキュリティ対応間違っています

以前やってたが、久しぶりに読んだ本のログ取ることにしてみた

けっこうすぐ読める感じだし、どんな立場の人でも軽く一読するのは良いと思う

メモ

  • 守れないルールによる運用は、大変危険な脆弱性
  • 必ず1次情報の内容を自らの目で確認
    • 自分が信頼できそうなセキュリティ専門家を見つけて、Twitterでその人をフォローするなど、SNSを活用して、専門家の見解を取り込みます
    • 必ず複数の専門家の意見を参考にする
  • アノニマス派閥
    • DoSなどのサイバー攻撃を行う武闘派の「アノンオプス(AnonOps)」
    • 合法的に抗議する穏健派の「アノンネット(AnonNet)」
  • 手帳にパスワードをメモ
    • 万が一紛失したときのことを考慮して、書き方を一工夫
    • パスワードの一部を省略してメモしておき、落として誰かに知られても、ログインできないようにしておきます
  • piyolog
  • (n) – life is penetration. geeks cheer. geeks be ambitious.

ITリテラシーが低い人など相手によって、手帳にパスワードをメモを取ることを勧めているあたり、著者は現実的で実現可能な考えを提示してくれるし情報が信頼できそう
セキュリティなんかは特に堅い立場の人や組織ほど、間違いでもないが実用的でない対策を提示するものだと思う



4+ hours
Speed 3/5
★★★★☆
MAN WITH A MISSION - database feat.TAKUMA(10-FEET)

自分専用のCIを使ってRailsの開発効率を上げる

テストをわざと壊して効率的に開発する - quattro_4's diary
の記事に書いた内容に関連して、最近自分専用のCI的なものを欲しいと思っていた

幾つかの手軽な方法として思い浮かんだのは

  • Travis CIを使う
  • 自分専用のCIをMac miniなど別のマシンで構築

Travis CIについては、会社で有料プランの2 Concurrent jobsで動いていて、現状運用としては十分なレベル
一つレガシーなプロジェクトが1時間くらいかかるものがあって、それが更新されると2つのjobsを占有して待ちが生じて多少効率悪いことがある
3 Concurrent jobsのプランがあればぜひ利用したいが、次のプランは5 Concurrent jobsでそこまでは必要ない

プランを上げても起こるデメリットとしては、テストを壊す目的で使うブランチがTravis CI上やgitレポジトリ上で他の人にとってノイズになる
Concurrencyが増えても、レガシープロジェクトにブロックされる可能性は残るなどがある

自分専用のCIをMac miniなど別のマシンで構築について
自分だけテスト専用のMac miniを置いておくというようなのは正直他の人から見たら少し変。
オフィス内で利用できるテスト専用端末を会社で導入というのも考えられる。
他の人も使ったらどうかという話になる。その端末のメンテも結局は必要。とか結局いろいろ面倒になりそう。
マシンの初期費用がかかるし、ベストとは言い切れない


最終的に落ち着いた方法は、自宅のiMacを利用する方法
最初はwemuxなどを使ってできないかと思ったが、リモートネットワーク経由で何かしないですむならその方が良いと思った
結果的にはかなりシンプルな方法になった

使うものは

Dropbox上に対象のプロジェクトを置く(コピーまたは、新規にチェックアウト)
pushを許可

cd ~/Dropbox/path/to/my_project
git config --add receive.denyCurrentBranch ignore

作業プロジェクト上からそのDropbox上のものへ参照

git remote add share ~/Dropbox/path/to/my_project

iMac上でjenkinsを動かして、ローカルのDropbox上のレポジトリをポーリングする
通常使う失敗時のEmailと合わせて、毎回失敗した内容を確認したいので「拡張Email通知」で「Always」を設定し、常時通知するようにする

あとは作業したブランチをDropbox上にpushするだけ

結果として、MacBook上で全テスト走らせるより多少早いフィードバックが得られるようになった(iMacは16Gのメモリがある)
後場合によってはjenkins上で早く結果の出るspecごと細分化・パイプラインまたは並列化してみる方法も考えられる
(models -> controllers -> features他)


一つつまづいた点としてはgitの"--bare --shared"などのオプションでレポジトリを使おうとしたけど、参照する側でなんかうまくいかなかったので諦めた
結果、なんらかのリスクがありそうな"receive.denyCurrentBranch"を使わざるを得なかった

SMTPで使っているGMailアカウントはメインのとは別の無くなってもそれほど困らないアカウント


今回のような方法に行き着いた流れとしては、別でMacBookの調子が悪かったのがあった
Macがkernel panicで予期せず再起動していたのを直した話 - quattro_4's diary

調子が悪くなったことで、最悪自宅のiMac上で開発できる状態に持っていくこと、wemuxなど試したことがヒントになった

テストをわざと壊して効率的に開発する

最近効率の良い開発の進め方について良く考えている

一番これ良いなと思える方法は、Breaking Driven Development
個人的な造語段階だが、破壊駆動
手法としては、変更を加えようとしている部分をわざとテストが落ちるように変えてすべてのテストを走らせて、その落ち方から次の方針を導き出す

これをやると

  • 影響範囲の把握が最速でわかる
  • デザインが洗練される
  • 無駄なテストが減る
    • 足りないテストがわかる
    • 足りない制約(validation, authorizationなど)がわかる
    • JSのコード内のリスクの発見

(破壊するための)変更の具体的なパターンは次のようなものが思い浮かぶ

  • factory/validation/relation/filterのオン・オフ
  • 一時的なraiseを追加
  • わざとtypoを混入

ただ一つ大きな欠点がある

全テストを走らすのに時間がかかる

全テストを走らすのに5分〜数十分かかっているものを数分に押さえるのが今一番に考えている課題


テストのFailuresの結果を見れば、その場その場で次どうしたら良いかはわかるのだけど、そのルール・パターンを明示的にまとめることはできていない
今後余裕があれば、具体的なコードと一緒にパターンを追求していきたい

Macがkernel panicで予期せず再起動していたのを直した話

使用しているマシーンはMacBook Pro (Retina, 13-inch、Early 2015)

症状としては

  • ある日から突然、1日に2〜3回予期せず再起動するようになった
  • 画面が一瞬(数秒)止まる、トラックパッドが反応しなくなる
  • 放置していても起きていることがある
    • 負荷が高いと起きるとは限らない
  • 落ちる時のアプリケーションに規則性はない
  • OS X El Capitan 10.11.6
    • 過去2週間で大きなアップデート、インストールは無し

直した方法の結論から言うと「NVRAM/PRAMのリセットを行う」⌘⌥+P+R
参考にしたのは検索上位で見つかった次の記事
Macがカーネルパニックを起こした時に試したい8つの対処法 | gori.me(ゴリミー)

今回の問題について、いろいろ検索で調べて書かれている症状と比較して、自分の症状で特徴的だったのが、
(1) カーネルパニックが起きる時のタイミング、アプリケーション、ログの内容などに規則性が無かった

(2) 起動音を消すスクリプトを使用していて、これが電源を落とした時などに動作している
El CapitanやSierraでMacの起動音を確実に消す方法

直ってみれば、起動音消すのを試した時に、別の方法でnvramを変更する方法もあったので、このスクリプトが影響して壊れる可能性も十分ありうるなと思った


今回学んだことは、Appleのフォーラムなど読みにくい情報も多いが、複数の情報から理論的に考えていけば、正確な情報は見つけられると思った
買い替えやApple Store持ち込みをする前にできることはだいぶある

"PRAMクリア Appleの電話サポートでも、対策の一つとして一番初めににこれを勧められました。簡単にできる"
(再起動時の画像を検索したついでで見つけた記事)
Macのカーネルパニックが未だに頻発。解決の為に自分で試した6つ事! | [毎朝8時更新]Re:birthDesign Blog

他に見つけた正しく書いていそうなサイト(SMCはPRAMとは別物)
2017年2月からMacBookタイプのSMCリセットが変わった!? - Apple In

OSインストールはPRAMをリセットしない
"A fresh OS install won't reset the hardware, SMC or PRAM."
macos - Does clean install reset everything, including SMC? - Ask Different

規則性がないカーネルパニック(occasionally resulting in a kernel panic, random kernel panics)
Bad NVRAM NVRAM consists of a small amount of memory dedicated to storing important settings for the way Mac OS X interacts with hardware components. For instance, one NVRAM variable tells the system how much primary RAM to recognize.
These settings can sometimes become correct or otherwise problematic, occasionally resulting in a kernel panic. As such, clearing NVRAM can prove a quick fix when the cause of random kernel panics or particularly kernel panics at startup proves elusive. (see "Kernel panics at startup or shutdown" section below).
Tutorial: Avoiding and eliminating Kernel panics - CNET


やったこと、今回効果無かった

解決した方法

  • NVRAM/PRAMのリセット

なぜか「NVRAM/PRAM」は違うと予想してスキップしてしまい、無駄な作業も多かったがクリーンインストール復元とか、買い替えを余儀なくされた時の良い予行練習になった
DropboxGitHubに必要なものを全部上げておくことが重要と認識した

Rubyでスクレイピングする話をしました “Web Scraping with Capybara”

trbmeetup.doorkeeper.jp

Kindleの情報集めるやつ kindle_manager
Amazonの注文履歴を集めるやつ amazon_order
を作ったので興味ある人は試してほしい

特にamazon_orderは誰でも使えると思う
自分の過去のAmazonでの注文履歴10年以上を合計したら300万超えてて反省の余地ありそう

次のような感じで簡単に集計出せる

f:id:quattro_4:20170708220254p:plain

あとKindleも次の感じで概算できて、全然読まないくせに無料のコミック1巻を買いまくっているのをやめられないでいる
反省すると無料本や安売りセールの本は出費は問題ないが、
無駄に買うことで本来読むべき本が埋もれてしまっているのが大きな問題

f:id:quattro_4:20170708220333p:plain