オーバーエンジニアリングしないために心がけていること - $shibayu36->blog;
オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある— Windymelt💀(めるくん)🚀❤️🔥 (@windymelt) 2024年9月12日 上のツイートを見かけたので、自分は何を心がけているか書いてみる。 結論 プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする 前提: あらゆる未来の変更に強い抽象化はない 設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが
git logの内容を検索する-Sと-Gの違い - $shibayu36->blog;
ずっとgit logの内容を検索するときに-Sオプションを使っていたが、実は近いオプションに-Gオプションもあり、探したい内容によっては使い分けないとダメということを初めて知った... 詳しくはhttps://git-scm.com/docs/git-logの-Sと-Gのドキュメントを見てほしい。簡単にまとめると -Sは指定した文字列の出現回数が変わるdiffがあるcommitを検索する -Gは指定した正規表現がマッチする文字列がdiffにあるcommitを検索する ドキュメントの事例部分が結構わかりやすくて、以下のようなdiffがあった場合 + return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0); -S frotzで検索をかけると、frontsの出現回数は変わってないのでマッチしない
スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;
会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると
Emacsで現在見ている行を変更したPRを開けるようにした - $shibayu36->blog;
このコードどうしてこうなってるのかという経緯を知りたい時、git blameなどのコマンドを利用することが多い。しかし、git blameだとその行を変更したcommitが分かるだけであり、経緯が結局分からないということがよくある。 そういう時にその行を変更したPRを開けるようにしたいなーと思って、いろいろやったところ、Emacsで現在見ている行を変更したPRを開けるようになったのでメモ。 特定のコミットが含まれるPull Requestを開くには 前段階として、特定のコミットが含まれるPull Requestを開くということをやってみる。これは既にいろいろやっている人がいて Commit Hash から、該当 Pull Request を見つける方法 - Qiita How to find pull-request by a commit sha - Pitr.ch Gitベースのコード
Carp::Replyを使って、モジュールの挙動を追いかける - $shibayu36->blog;
最近Cartonコードリーディング会をやっているのですが、そのときにCarp::Replyを使ってみたのでメモ。 例えばCartonとかの中身を追いかけるときに、この時点でこの変数はどうなっているのかとか調べたくなることがあります。そういうときにRubyのPryみたいな機能を持つ、Carp::Replyというのを使ってみました。 ひとまずやりやすいようにCartonのrepositoryをclone。 $ cd ~/development/ $ git clone https://github.com/miyagawa/carton.git ここに変更加えたのが使われるようにPERL5LIBに追加します。 $ export PERL5LIB=~/development/carton/lib あとは止めたい場所に以下の文を追加するだけです。 use Carp::Reply qw(repl);
Xslateのpre_process_handlerを使ってCSSのインライン化をする - $shibayu36->blog;
この前 XslateのテンプレートをCSSインライン化する - $shibayu36->blog;という記事をかいたのだけど、その時にgfxさんにコメントで gfx BKっぽい気もしますが他にいい方法は思いつかないし、最近 pre_process_handler という機能も足したので、まあ許容範囲じゃないすかね。 と言われた。 pre_process_handlerというものがあったことを知らなかったので、試しに利用してみた。 pre_process_handlerを使ってtemplateに対してCSSインライン化する さてやりたかったことを振り返ると メールを一通一通CSSインライン化するのではなく、先にtemplateをインライン化しておいて、それを利用してrenderしたい ということでした。 例えば以下のようなtemplateを用意します。 <html> <head> <styl
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
