ソースコード20万行の大規模サイトのPHPを5.1から5.4に上げるためにやったことまとめ · DQNEO日記
所要期間 着手しはじめたのが2010年12月ごろ、完了したのが2013年9月だったので何と３年近くかかったことになります。 長引いた原因は、日々の機能追加や運用をしながら孤独に片手間で細々とやってたからです。(単純に人手不足とも言う) また、PHPバージョンアップと同時にCentOSサーバを5から6にあげることにしたのでサーバ再構築のための工数も含まれています。 後半は仕事仲間が増えてその人が専業でバージョンアップ作業をやってくれたのでだいぶ楽できました。 それと専任のテスターさんたちにも参加していただいたので本番で大きなトラブルなく完了することができました。 感謝感謝です。 サーバ入れ替え作業が終わってPHP5.1の入った古いサーバを削除したときの、まさに「技術的負債」を返済し終わった瞬間の、あのスッキリ感、もう言葉にはできません。 終わってみてこの件に関するRedmineのチケットを数
いい加減、<script src="http://.. と書くのはやめましょう - DQNEO起業日記
外部サイトのJSファイルを読み込むときに、こういう書き方するのはやめましょう。 <script src="http://example.com/js/jquery.js"></script> 理由 あなたのサイトが、いつの日かSSLに対応することになったとき、そのscriptタグがバグの原因になります。 ご覧のとおり、HTTPSページの中でHTTP要素を読み込もうとすると、ブラウザによっては安全装置が働いて読み込んでくれないのです。 上の例ではjQueryの読み込みに失敗していますが、エラーメッセージ「Uncaught ReferenceError: jQuery is not defined 」を見てもHTTPS/HTTPのプロトコルが原因だとはすぐ気づかないので、わかりにくいバグになってしまいます。 結論 JSファイル(とかCSSとか画像とか)を読み込むときは、"http:"の部分を省
Git pullを使うべきでない３つの理由 · DQNEO日記
git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「
必殺！Github導入に向けて上司を説得する時に使える資料まとめ · DQNEO日記
Subversion vs Github 青い線と赤い線。 あなたの会社は、どちらと運命をともにしたいでしょうか？ 業界誌でも大きく特集されている 「Githubは世界標準の開発環境である（ｷﾘｯ」by @HIROCASTER さん Githubを導入している先進企業たち 公開されている情報をもとにリストアップしてみました。 ご要望があれば追加します！ (Piece of Cakeさんを追加しました。） (サイボウズさんを追加しました。） これらの事例の中から資料をキリハリして、上司の説得に使いましょう。 ＼（サイボウズ）／ ＼（ペイパーボーイ）／ 技術的なアプローチを強化しようと、エンジニアのトップであるmizzyに 直属になってもらい、全社的に取り組むべき課題とチャレンジしたいことの洗い出しや 技術のアウトプットを高めるための取り組みを始めました。 [中略] そのような取組の結果、エン
else句を使わないのが良いコードなの？いや、そんなはずは・・・ · DQNEO日記
if (条件) { return 20; } else { return 30; } ↓ if (条件) return 20; return 30; こうすれば確かにネストは浅くなりますが、いつも毎回こう書く方がよいのでしょうか？ elseを書いた方がよいケースもあるのではないか 条件の部分が特殊・例外的な場合は、確かにこの方がわかりやすいと思います。 例えば、スーパーマリオで、マリオの状態が「無敵・チビ・大きい」の３種類しかないとします。 敵に触れたときの挙動を関数として書きます。 (オブジェクト指向っぽくないかもしれませんが、本記事の主眼はif-elseの書き方です。) function () { if (マリオ.is無敵モード) { 敵.死ぬ(); return ; } //以下、通常モードの場合のコードを書く } 無敵モードは特殊な状態だから、これはよいと思います。 しかし、マリオ
JavaScriptで、もう連想配列の最後のカンマに悩まない！(※追記あり) · DQNEO日記
末尾に要素を増やしたい、または減らしたいときに問題が起こります 例えば" c : 3 "の行を単純に削除するとバグるので削除したいときに、" b: 2,"のカンマを削除する必要があります。 また、" d : 4 "を追加したいときに、" c : 3 "の後にカンマを入れる必要があります。 これは面倒くさいですね。 (エンバグについてはjslintなどのツールで防げばよいという指摘があったので修正しました。） より良いやりかた var x = { a : 1, b : 2, c : 3, dummy : null } このように最後に "dummy : null" というダミーの要素を書いておきます。 こうすれば、プロパティa, b, cはどれもカンマ付きで平等になります。 ぜひ一度試してみてください。 (もしかして常識だったらすみません。あとこの手法は for in で走査したいときはよく
MongoDBをext3で使ったら死んだ · DQNEO日記
Linux File Systems MongoDB uses large files for storing data, and preallocates these. These filesystems seem to work well: ext4 ( kernel version >= 2.6.23 ) xfs ( kernel version >= 2.6.25 ) In addition to the file systems above you might also want to (explicitly) disable file/directory modification times by using these mount options: noatime (also enables nodiratime) We have found ext3 to be very
メソッドの命名が適切かどうかを自分で判定するたった一つの方法 · DQNEO日記
私の好きな記事に、こういうのがあります。 ふとActiveRecordで使えるpreviousメソッドってどこからきてるんだろう？と思ってgemsをgrepしてみるも見当たらず。 よし、場所を探り当ててやる！ [中略] 自分で普通にmodelに定義してた。 因みに複数人開発で他人が実装したとかではなく、紛れも無く俺が実装したメソッドである。おまけにテストも書いてある。 何故このような自体が発生したのか。 メソッド名が自然過ぎたか。 メソッドの定義されている場所を探す - komagata Ruby on Railsの中で"previous"メソッドがどこで定義されているのかを探してみたら、それはRailsにはなくて、自分が普通に子クラスで定義したメソッドだった、というオチ。 yugui コレクションがあってシャッフルしたいと思ったら、shuffleと書いて、それで動かなきゃいけないんですよ
Ethna開発者が知るべき１０のこと · DQNEO日記
１．AppID（プロジェクト名)は短くしましょう 最初にプロジェクトを作る時のAppIDを長くしてしまうと、後で後悔することになります。 短い方がよいです。 アルファベット２文字～３文字程度にしておきましょう。 例えばプロジェクトの名前を"Pocketmonster"にしたいと思って"add-project Pocketmonster"などとしたとします。 すると、プロジェクト内のあちこちの場所で"Pocketmonster"という長い名前を使うハメになります。 こうなると開発時に何かとめんどくさいし、後から変更するのも大変です。 "Pocketmonster"の代わりに"Pm"などにするのがよいでしょう。 ２．省略できるものは省略しましょう 空っぽのアクションフォームクラスとか、空っぽのアクションクラスファイルとか、空っぽのビュークラスファイルを作ったりしていませんか？ アクションフォー
PerlとPHPにおける「リスト」概念の違い · DQNEO日記
naoyaさんのPHP版 List_RubyLikeを見ていて面白いことに気づきました。 $list->push('foo'); $list->push('bar','buz'); 一瞬、「なんて美しい！」と思いました。 と同時に、「なんてPerl的な！」とも思いました。 「これじゃまるでPerlじゃないか」と。 私ならこういうインターフェイスにすると思います。 $list->push('foo'); $list->push(array('foo','bar')); 少し冗長ですが、こっちの方がPHPとしてしっくりきます（私にとっては）。 実際にはpush(array('foo','bar'))などとリテラルを渡すことはあまりなくて、push($hoge)とかpush($this->hoge())などと書くことになるでしょう。 この違いを突き詰めていくと、「PerlとPHPにおけるリストの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DQNEO起業日記