サイトパフォーマンスのインパクト - ワザノバ | wazanova
http://programming.oreilly.com/2014/01/web-performance-is-user-experience.html 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約3時間前 サイトパフォーマンスがプロダクトにどのような影響を与えるかは色々な資料で見たのですが、数字をまとめて把握してなかったので、EtsyのLara Swansonがこちらのブログで事例をまとめてくれていて助かります。 ページの読込みに3秒かかれば、40%のユーザが離脱する。 Amazonによると、ページの読込み時間が100 ms増えると、売上が1%落ちる。 Googleは、検索結果の表示数を増やして、ページの読込み時間が0.5秒増加すると、売上とトラフィックが20%低下した。 Akamaiによると、75%
データプロダクトをつくるときに気をつけること - ワザノバ | wazanova
http://blog.relateiq.com/the-data-revolution/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 LinkedIn / Greylockを経て、CRMツールのRelatelIQのVP of ProductをしているDJ Patilの "Building Great Data Products"をまとめたものです。データの絡むプロダクトづくりをするときにハイレベルで気をつけるべきことが挙げられてます。 1. あまり凝りすぎないこと。 シンプルで素直なかたちの方が、凝ったアプローチよりも、10回のうち9回は正しい。 2. シンプルなものからはじめて、必要あらば、複雑にしていけばよい。 複雑なものからはじめて、それからシンプルしようなんて思わないこと。 3. データ
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
JavaScriptフロントエンド開発の昨今
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Herokuの中の人が書いたWebアプリケーション構築の方法論「The Twelve-Factor App」の日本語訳 - orangain flavor
2016-01-14追記: 日本語版は随分前に本家にマージされたので、記事中のURLも変更しました。 The Twelve-Factor App はHerokuの中の人 Adam Wiggins氏によって書かれた、モダンでスケーラブルかつ継続的デプロイ可能なWebアプリケーションを構築するための方法論です。 2011年に書かれた記事ですが、とても有用な内容だったので勉強を兼ねて日本語に訳してみました。 The Twelve-Factor App（日本語訳） 目次は以下のとおりです。 コードベース バージョン管理されている1つのコードベースと複数のデプロイ 依存関係 依存関係を明示的に宣言し分離する 設定 設定を環境変数に格納する バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する プロ
Gengo | オンラインで２４時間発注できる翻訳サービス
プロによる 翻訳サービスを 安く・早く お届けします顧客満足度 97.6% お客様件数 6万5,000件超 総翻訳語数 10億語
第3回 ブランチvs.フラグ | gihyo.jp
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
Railsによるワイルドなソフトウェア開発
CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…Drecom Co., Ltd.
Adobe Shadow の設定方法と注意点 - akihiro kamijo
先週の記事で紹介した Adobe Shadow の設定方法と使用時の注意点について、改めてご紹介します。 まず、必要な環境です。 Mac OS X v10.6, 10.7 または Windows 7 の搭載された PC iOS または Andoroid の搭載されたデバイス WiFi デスクトップ環境には、Shadow と、Chrome と、Chrome 用 Shadow プラグインをインストールします。デバイスには Shadow クライアント （iOS, Android） をインストールします。 Windows 7 のみ、Shadow と一緒にインストールされる BonjourPSSetup.exe を使って Bonjour の設定も行います。 ここまでできたら、PC とデバイスを接続します。以下はその具体的な手順です。 デスクトップ側 デスクトップ上で Shadow を起動 ウインドウ
若手エンジニアたった1人のメーカー経営（前編）
ビーサイズ（Bsize）は、神奈川県小田原市にある家電メーカーだ。同社が開発・販売する製品が、LEDデスクライト「STROKE（ストローク）」（2011年12月27日に発売）。既に、独「red dot design award 2012」「2011年度 グッドデザイン賞（GOOD DESIGN AWARD）」も受賞した。 STROKEのキャッチコピーは、「最高の光、最小の構造」。その筐体は、細いパイプ1本。作業者の視界を遮らず、あまり主張しないデザインとしている。光源はLEDなので省電力で、かつ6万時間持つ。演色性のクラスは1A（平均演色評価数Raで90以上）で、自然光を忠実に再現可能だ。 ライトが照らす範囲は広角になっている（以下の写真）。周囲を広く均等に照らせるため、従来のスタンドのように、「角度を変える」「高さを変える」あるいは「置く場所を変える」といったことを考えなくてもよい。また
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
TiDD初心者によく聞かれる質問part1～チケットが放置されがちです #tidd - プログラマの思索
チケット駆動開発についての質問のうち、「チケットが放置されがちだがどうすればいいか？」「チケットの粒度はどれくらいがいいのか？」の二つはいつも聞かれる。 最初の質問について、自分なりに考えたことをメモ。 【元ネタ】 チケット駆動開発を導入しても変わらないこと - Basic まずは箇条書きより始めよ - Basic デベロッパーズサミットまとめ【チケット管理システム編】 ? prototype002 【1】「チケットが放置されがちだがどうすればいいか？」という質問の背景を類推すると、チケットを起票する運用はできているものの、チケット管理ができてないことを意味する。 チケット一覧画面で、一生懸命チケットをフィルタリングしながら、どのチケットが遅れているのか、どう対処すればいいのか、必死になって考えている間にも、どんどんチケットが増えていってしまっているのだろう。 チケットが放置されがちな状況
見積りとコミットメントは分けよう
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 多くの組織における根本的かつ共通の問題は、見積りとコミットメント（約束）が同一のものとして扱われていることである。 ある開発チーム（アジャイルか否かに関係なく）は、顧客が望むもの一式を納品するのに、利用可能なリソースを踏まえて7か月かかるだろうと見積もった。 チームメンバーはこの見積りをマネージャに提出したが、マネージャは見積りを部長に、部長は顧客に知らせてしまった。 そして、いくつかのケースにおいては、その見積りが、チームの「伸縮可能なゴール」を奪ってしまうことになる。 ここでの問題は、チームの7か月という見積りが合っているか間違っているか、ではない。 問題は見積りがコミットメント（約束）に変化してしまったことだ。 「我々
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
github を用いた開発フローテンプレート
ソースコードの品質向上のための効果的で効率的なコードレビュー
子供のスマホ知恵袋
ストーリーポイントは複雑さや時間と関係があるか？
IDEA * IDEA
