railsのレールにどれだけ乗れてるかだけで判断するな - komagataのブログ
長いことrailsばっかりやってると他人のコードを「Railsのレール（流儀）にどれだけ乗れてるか、どれだけ流行りの書き方してるか」だけで判断しがち。 見慣れない書き方だったり、他の言語っぽい書き方だったりするとボロカスに評価しているのを見かける。 Railsに浸かり過ぎて、Railsっぽくないもの＝悪。レールから外れている＝ゴミ。そういった判断は楽だしRailsプロジェクトにおいては大抵あってる（Railsを理解するのを面倒臭がっているゴミコード）んだけど、対象のコードが持つ価値（どんなことをどういう方法で解決してるのか）を判断する力が衰える気がする。 Railsのレールや最近の流行りの書き方とは違うけど、一貫性のあるコードだったり、不具合が出づらく変更に強いコードってのはある。 特にRails経験は浅いけど他の言語・フレームワークに習熟してる人のコードにそういうものが多い。 手癖でやっ
レガシーPHP改善日記 シーズン1 エピソード2 - komagataのブログ
hrysd心を折られるチンカスプログラマーことhrysdがバイトで来てくれることになったので一緒に大門に出社。 初出社前に既にバグを一個潰してコミットしているという荒業を見せたhrysdだが、3000行を超えるcontrollerに早くも心を折られる。 俺「actionのメソッドが5行を超えたら危険印、なんていうrailsのぬるま湯に使ってたんだよ！これがサバンナだ。」 Github Organization契約出社後早速、社長にGithub Organization Bronzeプランを契約してもらう。技術的なことはわからないというが、リスクを背負って立てなおそうという気持ちが伝わって来ました。 9月30日の直近の締め切りに間に合わないのでsvn + redmineからの移行は10月にお預けだ。 svnがよくわかってないまずはsvnでもトップにぶち撒けられてるというのは辛いのでtrunk
偽のシンプル、正しいシンプル - komagataのブログ
組織論でもプログラムでもデザインでも「シンプルにしよう」とよく言いますが意味がフワッとしてるので自分的まとめを。 Rich Hickeyのシンプルの定義 シンプルさの必要性 | eed3si9n 上記の俺的まとめ。 simpleの対義語はcomplex。simpleを語源・対義語から考えると、多数のものを組み合わせてない・一つのものという意味になる。それに対してeasyを語源から考えると、近くのものという意味になる。 complexこそが悪。 easyだけどcomplexなもの = 甘え hardだけどsimpleなものを恐れない。simpleなものはしばしばeasyでない。 命名 上記を使いやすくするために、easyでcomplexなもののことを偽のシンプル、hardでsimpleなもののことを正しいシンプルと名付ける。 simpleでeazyが最良でcomplexでhardが最悪だが、
rubocopの警告から該当のルール名を知る - komagataのブログ
rubocopデフォには「おい、それはちょっと口うるさすぎるでしょう？」という項目が結構あって、"複数行ブロックの場合は->じゃなくてlambda使え"というのもその一つ。 % rubocop app/models/comment.rb Inspecting 1 file C Offenses: app/models/comment.rb:11:26: C: Use the lambda method for multi-line lambdas. scope :except_blocked, -> { ^^ でもどのルールをオフにしたらこれが許されるのかわからなかったが、-Dをつければルール名も表示してくれるらしい。 % rubocop -D app/models/comment.rb Inspecting 1 file C Offenses: app/models/comment.rb
俺の被害妄想でrailsが死ぬ時 - komagataのブログ
昨日EdTech Hackathonに行って久しぶりに色々なWeb関係の方の空気に触れて思った事。 俺はrails好きで強力だし楽しいなーと思うんだけど、 「GoogleからJSのシングルページでもSEO的にペナルティが全く無くなったらサーバーサイド要らねんじゃね？mBaaSで良くね？」 とか 「ちょっとしたサーバーサイドの処理はPHPで良くね？エンジニア多いし、安いし、技術的負債とかセキュリティ・ホールとか経営者からしたらたいして気にならないし、実際の所よくわからないし、来年どうなってるかわからんし。」 とか 「railsエンジニアとか単価高い割に何やってるのかわからないし。テストを書いてます？もっとこうガーッと派手に動く機能追加してくれねえかなあ？」 とか 「長期的なプラットフォームとかはガッツリ作ってくれて構わないけど、もっと雑でいいから短命のモバイル・アプリ量産してくれねえかな？」
アジャイルネイティブの為の受託開発から離れた理由 - komagataのブログ
受託開発から離れた理由というエントリーを書きましたが、 「新卒の時からウォーターフォール開発じゃあ既になかった。」 というアジャイルネイティブ（コンチクショウ！）な方には少し分かり辛いかなと思い少し補足を。 受託開発から離れた理由 - komagata （僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。） 「開発会社とクライアント（開発を依頼した会社）の利害が必ずしも一致してない」というのは極端に言えば下記のようなことがあるということです。 下記は全てフィクションです 開発会社が論文検索システムを4人月（1人月＝100万円）と見積り受注した。全文検索にはクライアントも知っている名のある商用パッケージを使う前提で見積もったが、土日で試してみたApache Solrを使えば半分の工数（というか土日で仕様
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
