第4回ISUCON予選にチーム「ご注文はPHPですか？」で参戦して1日目暫定10位になりましたがPHP使ってません - このブログはURLが変更になりました
いい感じにパフォーマンスチューニングするコンテスト第4回ISUCONに参戦しました。まだ現時点で本戦に進めるのかわからないのですが、1日目で暫定10位になりました。 PHPでも十分に戦える！と思った方、ごめんなさい。Go言語使いました。 チーム紹介 チーム名 ご注文はPHPですか？ チーム略称 ごちぺち 予選スコア 44000〜45000ぐらい（暫定） メンバー アイコン Twitter @do_aki @matsuu @netmarkjp 職業 インフラエンジニア インフラエンジニア インフラエンジニア 得意言語 PHP Perl Python 当日の役割 右腕 左腕 ファシリテータ えぇ、ぺちぱー(PHPer)で有名なdo_aki先生がいるチームですが、Go言語を使いました。 役割分担大事。特にファシリテータ大事です。fujiwara組もたぶんfujiwaraさんがファシリテータだと思
Vagrant のプロビジョン時間を削減する vagrant-cachier プラグインが良い
インストール vagrant-cachier プラグインをインストールするには、vagrant plugin install コマンドを実行するだけです。 $ vagrant plugin install vagrant-cachier Vagrantfile への記述 vagrant-cachier プラグインを有効にするには、Vagrantfile に下記の設定を行います。config.cache.scope では、キャッシュスコープを設定します。 下記では、:boxを指定しており、これは、プロビジョンでインストールしたパッケージを Box 単位でキャシュします。同一 Box を使う Vagrantfile であれば、別の VM でもキャッシュを共有することができます。 私の用途であれば、この設定が使いやすそうです。 あとは、通常どおり、vagrant up を行うとプラグインが有効と
最低限書いておきたいPHPのDocコメント - Qiita
最低限書いておきたいというよりは、最低限書いて下さいという私の切なる願いかもしれない。 そもそも何故Docコメントを書くのだろうか？ メソッドの命名さえ正確に行えるならDocコメントという存在はほぼ必要無いという考えがあり、 それは間違いでは無いでだろう。 しかし… 型が無いためにメソッド名を冗長にしてしまう 以下のコードは税率を取得するだけの単純なものだ。 TAX::getRate()と実行することで税率を取得出来る。 これなら、主語＝TAX、述語＝getRateと読み取れるので何をしているのか一目瞭然である。 class Tax { private static $tax_rate = 0.8; public static function getRate() { return self::$tax_rate; } } しかし、これは戻ってくる値の型を予約出来る静的片付け言語であればの
石田組でISUCON参加しましたぞ！！！（二日目組です） - uzullaがブログ
参加したことありそうといわれましたが、実際の所初参加です。 メンバは私、id:moznion、id:studio3104です。 夏期講習AMIなどはやりましたが、AMIをどうやったら提出なのか？という所がよくわからなかった程度には初心者でした。 ただまあ、やることはわかっていたので、些末な所ですね。 すたじおさんがぼそっと「メガネにウンコみたいなものがついてました…」 っていってて本当に大変だなとおもった #isucon— uzulla (@uzulla) 2014年9月28日 PHPです 私は普段メールフォーム作成を主な生業としておりますから、当然（？）今回も当然PHPです。 一時は「Perlのほうがいいんじゃないですか…」ってさんざん言われたんですけど、「ならば音楽性の違いだ！！」などという浮き沈みを経由した上で、結局PHPで参加できました。 本当出題側のみなさんには頭がさがります。
YappoLogs: #isucon で、やらんかった事
書いてる人 ISUCON が始まる直前のエンジニアチューニングコンテストで、レギュレーションで「特定のディレクトリ以下のファイルを弄ったら失格。それ以外は自由」って競技があったので、特定のディレクトリ以外の htppd.conf をいじって documentroot を変更して、ぶっちぎりのスコアをたたき出したら、ぶっちぎりすぎたと言う理由で失格になってマジイラっと来た人間。 最初やった事 レギュレーションを良く読む テンプレートファイルを良く読む ベンチマーク実行する ベンチマークの User-Agent を見る 任意の Set-Cookie を返してもちゃんと処理するかどうか見る ログを awk ... | sort | unic -c |sort -r | more static file を.gz してファイル圧縮対応してる client かどうか試して無理なの確認する ベンチマー
リーダブル・コードを書く | POSTD
ここ数年間をプログラミング的な観点で見ると、私が望んでいたほどには面白みがなかったと言わざるを得ません。このことは、恐らく他のプログラマの皆さんも同意見かと思います。そこで、私はこの期間をある意味、充電期間と捉えて、自分の開発ツールの強化に取り組んできました。そして土曜日になると、Bashを使って ワークスペース 作りに精を出していたのです。 最後にシェルを使って真剣にプログラミングに取り組んだのは、かれこれ恐竜がまだ地球を支配していた頃だったでしょうか。何年も触れていなかった言語を改めて取り上げ、その昔に自分が書いたコードを見直してみると、いかに自分が成長したかということを実感できて、なかなかに面白いものです。 14年前、私は”コンパクトなコードは優れている”という考えに随分と傾倒していました。コードが少なければ、そしてDon’t Repeat Yourself（DRY）に従えば、バグも
クックパッドとマイクロサービス - クックパッド開発者ブログ
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
『健康レシピ』スマートフォンサイトのデザインプロセスについて - クックパッド開発者ブログ
ユーザーファースト推進部の坂本です。 8/4（月）に自分がデザインを担当している『健康レシピ』のスマートフォンサイトを公開しました。 今回のスマートフォンサイトのデザインプロセスに合わせてクックパッドでよく用いているツールを紹介します。デザイナーやエンジニアの方が今後スマートフォンサイトを作る際に参考にして頂くためまとめてみました。 ■健康レシピとは… クックパッドで公開されているレシピを管理栄養士監修のもとに選定し、簡単に栄養計算ができるようにしたサービスです。主に糖尿病や高血圧、脂質異常症やメタボの方向けに、健康的でおいしい食事を紹介しています。 スマートフォンサイトのデザインプロセス スマートフォンサイトのデザインプロセスは、以下の流れで行いました。 画面構成を作成し、全体の遷移を確認する 各ページのデザインを作成する Flintoで遷移に違和感や問題点がないかを確認する コーディン
GREE Tech Talk #06 ご来場ありがとうございました | GREE Engineering
こんにちは。開発企画室の佐島です。 はじめに 9月24日（水）、グリー主催の技術勉強会GREE Tech Talkが開催されました。 6回目となる今回のテーマは「Practical Go」。 言語をテーマにしたのは今回が初めてでしたが、言語そのものを学ぶというよりも実際の開発や運用で出会った問題を取り扱うという「実践的」な内容でしたので、いつものGREE Tech Talkと同じ感じだったのではないかと思います。 天候の悪い中お越し頂いたみなさま、本当にありがとうございました。 セッション概要 当日行われたセッションの模様をダイジェストでお届けします。 『Lessons Learned While Writing "peco"』牧 大輔（LINE株式会社） 最初にご登壇頂いたのはpecoの開発者であり、上位3%のアクティブGoユーザ牧大輔さん（@lestrrat）によるpeco開発で得られ
技術的負債 - Qiita
この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債という比喩で表していている。 たとえば、省略可能なプロセスを飛ばす事で開発の高速化を行う事があり、初期開発を高速に行う開発者の中には意識的・無意識的問わずこれを行っている事例が多々存在する。このようにして抱えられた技術的負債は長期的に見た場合に問題を引き起こ
bash の脆弱性 "Shell Shock" のめっちゃ細かい話 (CVE-2014-6271) - もろず blog
※(2014/10/1 追記) 脆弱性の番号を誤って CVE-2014-6721 と表記してしまっていました 正しくは "CVE-2014-6271" です 失礼致しました ※(2014/10/7 追記) 2014/10/7 14:00時点で Shell Shock への修正パッチは6個 公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください シェルに脆弱性が見つかったらしいです このコマンドを実行すると脆弱性があるバージョンかのチェックができるようです $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" 以下のように表示されたらアウトです vulnerable this is a test どうやら、このコマンドが正常に実行できるというのがこの脆弱性の正体らしく、 echo vuln
YappoLogs: #isucon 2014 に参加して暫定圏外になってきました
#isucon 2014 に参加して暫定圏外になってきました ISUCON4 の予選やってきました、最終スコアは37000位だったけど本戦足切りラインは45000くらいだと思うので残念でした。 チームメイトは、前回組んだ kamipo さんに加え新メンバー ar_tama さんと共に望みました。 役割としては kamipo: 司令塔権 middleware 以下全部担当 ar_tama: アプリ担当 yappo: アプリ担当 リポジトリはこちら https://github.com/kamipo/isucon4qualifier 開始前 大体の凡ミスはレギュレーション読まない事に起因するのが、過去の ISUCON の教訓だからひたすらレギュレーション読む。 お陰でリーダの遅刻を見逃した。 10:00-12:00 開始とともにトイレ。この間に kamipo さんが必要なインスタンスあげてログ
Composer でパッケージの削除は composer remove が良いと思ったらそうでも無かった - Qiita
Composer で複数のパッケージをインストールしていて、開発を進めるうちにそれらの一部が不要になること、あると思います。そんなとき、どうやって不要になったパッケージを削除しているでしょうか？ 幾つか方法はあると思うので、それらの動作を確認してみます。 まず、実験のために composer.json を a b c d の 4 つのディレクトリに作成します。それぞれ下記の内容です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1年で1台->100台まで増やした話
なぜプログラミング言語のように英語を習得できないのか？──カーネルハッカー・小崎資広（8） | サイボウズ式