yk5656のブックマーク - はてなブックマーク

Re: 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - @kyanny's blog

技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？）「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト

yk5656 2022/12/23

開発

リンク

私のソースコードの書き方 - @kyanny's blog

note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述）土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりするこの方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため）道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ

yk5656 2016/07/19

プログラミング

リンク

インフラ系トレンド私的まとめ - @kyanny's blog

社内勉強会でいろいろ教えてもらったのでメモ。トレンドと呼ぶには一、二年遅い。なお自分の考えを整理するために書いているものなので正確さは保証しませんしツッコミも不要です。前提: 仮想マシンと仮想マシンイメージ VirtualBox とか、 AWS なら AMI とか。ホストマシン上で動作しているものが仮想マシンで、仮想マシンイメージは仮想マシンのスナップショットだったり、それをもとに新しい仮想マシンを作れる雛形だったり、くらいに理解しておけばよい。 Vagrant と Packer 仮想マシンと仮想マシンイメージの技術があるおかげで、作業環境（Mac とか Windows とか）上でプロダクション環境により近い環境を手軽に用意できるようになた。しかし仮想マシンの管理（起動したり、設定を変えたり）は手作業でやる必要があった（VirtualBox なら GUI でぽちぽちやったりとか） Vag

yk5656 2015/04/25

サーバ

リンク

JavaScript で if 文を書くとき必ず波括弧を書くべきと主張しているスタイルガイド - @kyanny's blog

新人さんの JavaScript のコードレビューをしていて、 if 文の本体部分を波括弧で囲っていないコードを見つけた。おれは本体が一行しかなくても必ず波括弧で囲うようにしており（そのほうがわかりやすいと思っているから）、できればそうして欲しいけど個人の好みを押し付けるのはよくないので、広く支持されているコーディングスタイルガイドの類いで同様の主張をしているものが無いか探した。 Google とか Mozilla とか GitHub あたりのドキュメントを眺めてみたが if 文の波括弧についてはっきり言及している箇所を見つけられずにいたら、該当するドキュメントをいくつか教えてもらった。 http://contribute.jquery.org/style-guide/js/#spacing if/else/for/while/try always have braces and alw

yk5656 2014/06/03

コーディング

リンク

Single Page Application ではない場合 JavaScript コードのエントリポイントはどこにあるべきか？ - @kyanny's blog

仕事で中規模程度の Rails アプリケーションのコードベースをいじっている。このアプリはもともと app/assets/javascripts 以下に必要に応じて JavaScript ファイルを置き、適当なテンプレートファイルから直接 JavaScript の関数を呼び出したりしていた。ごく普通の Rails アプリである。このアプリは CMS で、いわゆる「ブログの管理画面」みたいな用途で使われている。一部の機能はそれなりに込み入った UI 操作を必要としページ遷移なしに操作できる必要があるが、旧来のやり方では JavaScript コードの管理が間に合わなくなってきたので部分的に Backbone.js を導入し始めている。最近悩んでいるのが、 Backbone.js なコードのエントリポイントをどのように呼び出すべきなのか？ということ。そもそも自分が Backbone.js

yk5656 2014/03/31

javascript

リンク

「Webエンジニアのためのデータベース技術[実践]入門」を読んだ - @kyanny's blog

モバゲー本ではてブやツイッターがひとしきり盛り上がった本日ですが空気を読まずに元モバゲーの人が書いた本の書評を書きます。著者の松信さんはたぶん説明不要ですが MySQL のスペシャリストで先日 Facebook に転職された凄腕エンジニアです。その人が書いたデータベースの本なのでたいへん充実した内容、ではあったけど、率直に言って僕はLinux-DB システム構築/運用入門のほうが「濃い」と感じました。「Webエンジニアのための〜」はデータベースを中心とした大規模ウェブアプリケーション運用の話が中心で、一方「Linux-DB システム構築/運用入門」はデータベースの話題に特化しているから、というのが一つ。それから、「Webエンジニアのための〜」は同じような話が繰り返されている箇所がけっこう目について、「もう読んだのに・・・」と若干内容の薄さを感じてしまったのが一つ。雑誌連載記事がもとにな

yk5656 2012/06/14

リンク

第1回Ruby開発環境勉強会 - @kyanny's blog

第1回Ruby開発環境勉強会 - delirious thoughts http://kentaro.hatena blog.com/entry/2012/05/29/230254 という勉強会があったので、「見よう見まねでカスタマイズしてもどうせ使いこなせないからギリギリまでやらなくてよし」などという意識の低い感じの話をしました。スライドには書いてないこともけっこう喋ったので捕捉: リファレンスマニュアルについて Emacs (anything) から perldoc とかるりまとか引けるようにしたこともあるけど、コマンド名やキーバインドを覚えられず定着しませんでした。あと、用例も見たいので結局ほかのページもぐぐることになり、もうブラウザでいいや、というのが今のところの結論です。わざわざキーワードを当てたのは、「赤い背景」のページばかり上位に出てくるのが嫌だったからで、単にキーボードから

yk5656 2012/06/12

開発環境

リンク

「あとで捨てることになるコードのテスト」について - @kyanny's blog

同僚とこんな話をした。例えば「キャンペーンサイトとプレゼント応募フォーム」のような、一時的にしか使わないことがわかっているコードに対するテストをどの程度書けば良いのか？納期は迫っていて、他にもっと優先度の高い仕事もあるとする。最低限 200 が返ってくることだけをテストすれば良いのか、 POST したらどのようなリソースが作られるかまで厳密にテストすべきなのか。そのとき述べた僕の意見を書いてみる。追記同僚の名誉のために補足すると、その時は「不安な部分をテストすべき」という当たり前な結論に落ち着いたのだけど、そもそも詳しく聞いてみたら「僕ならここは不安だから書くと思う」と考える部分については、彼はすでに書き終えていて、その上でさらに厳密にテストを追加すべきだろうか？という問題意識を持っていた、という。なので、以下に意識高そうなことをつらつら書いているけど、同僚氏のほうが僕よりよっぽど