発表資料 - クックパッド開発者ブログクックパッドスタッフによる開発者向け発表資料は下記 URL に移動しました。 https://static.cookpad.com/techlife/presentations.html
Web開発でよく使う、特に使えるChromeデベロッパー・ツールの機能
Webアプリのデバッグやチューニングに役立つ、Chrome Developer Toolsの主要機能を、スクリーンキャプチャ中心で簡潔に紹介。2014年10月に最新情報に改訂。 モダンブラウザーの中でGoogle Chromeは最後発ながら、その機能の潤沢さ、便利さ、高速さからシェアを大きく伸ばしている。そして、今やほとんどのブラウザーではWindowsの場合F12キーを押すことで（Macの場合はCommand＋Option＋Iキーで）手軽に各ブラウザー搭載のデベロッパーツールを利用できるが、特にChromeのデベロッパーツールは、非常に機能が豊富なため、利用している人もかなり多い。 本稿では筆者がよく使う機能や、使うと便利な機能を中心に、Chromeのデベロッパーツールについて紹介していく。なお、本書は執筆時点で、最新のChrome 38を使用している。 機能ふかん 残念ながら、Chro
さくらVPSを使って便利な開発環境を構築する - UNIX的なアレ
開発環境は難しい 最適な開発環境をつくるのっていつも難しいなーと思います。サーバ側に入って開発する人もいれば、クライアント側のIDEあげてる人もいるわけで人それぞれです。 その人に特化した開発環境をつくるだけであればそこまで難しい話ではありませんが、チームでの開発となるとそのあたりをうまく解消するのがだんだん難しくなってきます。また、新しくサブドメインが増えたりなど開発環境も常にアップデートし続ける必要があります。 このあたりを、サーバエンジニアが手動でやってると死にます。悪しきDev/Opsの対立関係がうまれてしまうので、なんとかしないといけない。 というわけで、オフィス移転をきっかけに開発環境を作りなおしてみました。以下の3点からさくらVPSを選びました。 コストを抑えたい 最近さくらVPSに東京リージョンができた ローカルネットワーク接続できるようになった 新規開発環境をつくる上での
スレッドセーフという幻想と現実 - yohhoyの日記（別館）
この記事はC++ Advent Calendar 2013の15日目にエントリしています。 内容はC++標準ライブラリとスレッドセーフに関する解説になります。 flickr / rennasverden もくじ What's スレッドセーフ？ スレッドセーフという幻想 基本型とデータ競合 C++標準ライブラリとデータ競合 C++標準ライブラリ：シーケンスコンテナ編 C++標準ライブラリ：連想コンテナ編 スレッドセーフ RELOADED 基本的なスレッドセーフ保証 std::shared_ptr<T> std::rand() std::cout （本文のみ約9000字） はじめに マルチスレッド対応の点では他言語に遅れを取っていたプログラミング言語C++ですが、C++11ではようやく標準ライブラリにスレッドサポートが追加されました。C++11スレッドサポートではスレッドクラスstd::thr
グロースハックチームを作って1ヶ月運用してわかったこと | ランサーズ社長日記
いいね！ 360 ツイート B! はてブ 125 Pocket 372 昨年から今年にかけて、僕の周りでも非常に話題になったグロースハック。 数ヶ月前からランサーズでもグロースハック的なことを色々とやっていましたが、2013年10月からは、思い切って、既存のチームから明確に分離して、「グロースハックチーム」なるものを立ち上げてみました。 1ヶ月半くらいグロースハックチームを運営して、色々と気づいたことや成果をまとめてみました。 グロスハックチーム誕生秘話 ・小さい機能改善の優先度が下がりがち サービスの改善や機能追加などをするためには、開発リソースが必要です。開発リソースは「優先度」という魔法の言葉によって開発の順番が決められて行きます。順番が決められるので、小さな機能改善、やっても良くなるかどうかわからないもの、効果測定しにくい開発は、どうしても優先度が下げられ、リリースされない、という
発表資料 | 株式会社えにしテック
ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell
ペーパープロトタイピング入門 – 第2回 ペーパープロトタイピングに使う道具 | fladdict
ペーパープロトタイピング講座シリーズ。第2回は準備編。前回はこちら。プロトタイピングを始めるにあたって必要なものを列挙する。 必須ツール 紙 まず紙は大量に必要。A4コピー紙や大型のポストイットが一般的。スマホアプリの場合は、弊社が専用に開発したペーパープロトタイプ用ノートが便利。実寸で検証できるように心がけよう。 シャーペン 下書き用ペン。消しやすい芯がよい。個人的にはステッドラーを愛用。 サインペン 清書用のペン。チーム共有やテスト時に読みやすくするために使う。細い、普通、太いの3種類のペンがあるとよい。個人的には0.05mm、0.3mm、1.0mmの3本を使っている。オススメはピグマかコピックマルチライナー。 マーカー 清書用ツール。タップエリアや、注目させたいコンポーネントを面で見せる為に使う。最低限２色。薄いグレーと濃いグレーがあるとよい。可能ならばアプリとタップ色や警告色なども
ペーパープロトタイピング入門 – 第1回 どうして紙でプロトを作るのか | fladdict
ペーパープロトタイピング講座シリーズ。第1回は導入編。 第1回はの導入編。ペーパー・プロトタイピングとは何なのか、何故必要なのか。そして導入することで、どんな利点があるのかを説明する。 ペーパー・プロトタイピングって何？ ペーパー・プロトタイピングとは、紙で実際にアプリやサイトを「実装する」ことである。 通常の開発においてコンテンツが使いやすいかどうかは、開発が終盤になるまでわからない。このため「作ってはみたが使いにくい」や「いまさら後戻りできない」という問題が発生する。UIや手触りが重要なモバイル系のアプリにおいて、これは致命的な問題になる。ペーパープロトタイピングはこの問題を低コストで解決する。 紙とペンで動作モックを作成することで、本実装を行う前に、素早く手戻なく検証を行うことができる。これにより、仕様書策定や実装前にPDCAのサイクルを実現できる。作業負荷の高い本実装を行う前に軽く
Facebookの継続的デプロイメント - ワザノバ | wazanova
https://www.facebook.com/publications/514128035341603/ 1日500件、3,000ファイルに及ぶ本番アップ フロントエンドのコードは1050万行、内850万行がPHP 開発エンジニア1,000名とリリースエンジニア3名 QAやテスターは存在しない 自分でプロジェクトを選ぶ & 自己責任のカルチャーが強い。 1/3のファイルが一人のエンジニア、1/4が二人のエンジニアでメンテされている。 フロントエンドの本番コードベースは一つのものを共有 日常業務ではローカルのgitを利用。本番アップ可能になれば、中央のレポジトリにマージして、それからSubversion（過去の経緯で使っている。）にコミットする 同じエンジニアがコードをコミットする間隔は中央値で10時間 本番にプッシュする前に、担当エンジニア自身でのユニットテストを終え、同僚によるコード
High Performance Web Frontend
★追記： https://speakerdeck.com/ahomu/high-performance-web-frontend-2013-qiu のほうがブラッシュアップ版です WCAN 2013 Summer (7/6) で行われた、"High Performance Web Frontend…
「最強」のチームを「造る」技術基盤
「最強」のチームを「造る」技術基盤 Presentation Transcript 「最強」のチームを 「造る」技術基盤 Nov/09/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/ Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2 アジャイルコーチとして、 開発現場を日々サポートさせていただいています。 3 造る ＝ 栽培する・耕す 4 CI/CD TDD ATDD この３つを軸にした チーム造りについてお話します。 5 Agenda 1. チーム造りの背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD for Android 4. 3rd Stage : ATDD
Firefoxの開発ツール
2. この資料について • JavaScript での開発を助けるツールの紹介 • 想定する読者 • これまで Firebug を利用して来た方 • JavaScript で開発をされて来た方 • デバッガを利用したことがある方 2
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
カジュアルに鯖を監視するNewRelic をAmazon Linux に導入 - aws memo
今っぽい感じのSaaS型監視サービス NewRelicを Amazon Linuxに入れてみる。( Newvem とか Server DensityとかPingdomとかもある） New Relic は、エージェントを監視対象ノードに入れておく点は Zabbix等と変わらないが、監視サーバを構築しないですぐに(無料で)始められる、という点がメリット。 監視対象サーバが少ないシステムだと、監視サーバのコスト・運用負荷がデメリットになるので、CloudWatchを補助する目的で、CloudWatchで取れない Load Average, free memory, Disk UsageといったOS内部の情報をカジュアルに一元管理するのに向いている。 特徴を説明したページはこちら。 Server Monitoring Application Monitoring Real User Monitor
これからWeb系のベンチャーで起業しようと思っている人へ考慮しなければいけないリストを作成した ~技術編~ - nigoblog
Web系に限らずですがとにかくいろんなことを考えなければいけません。 業界で3年以上やっていたエンジニアならいざしれず、非エンジニアやフロントエンドしか触ったことのないエンジニア。 そして学生等々、Web系ベンチャーをやるには案外考えることが多いんだぜってことを伝えたいと思います。 開発編 運用編 まとめ という流れで説明します。 開発編 主にサービスローンチまでのプロセス。 最近でいうとMVP (Minimum Viable Product)だったりアジャイルだったりが流行っていますが、 とりあえずMVPを構築するまでに考えなければいけないことをリストを書いていきます。 1. 言語は何を使うか 一番ベーシックな概念にして、一番重要かもしれません。 とりあえずフロントエンドはさておき、バックエンドをどうするか。 ここで選択肢を上げておきます。 PHP Perl Ruby Python Sc
Cumiki - エンジニアのための、ちょっといい感じのドキュメント作成ツール
ベータ版を始めるにあたって、ベータユーザー募集中です。 お気軽にご連絡ください。どうぞよろしくお願いします。 http://cumiki.comRead less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
About COOKPAD (2013-11)
3年前の僕へ
時雨堂を支える技術
時雨道場