プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
僕が1週間でWebサービスを公開するまで - ぐだぐだ言ってないでコードを書けよ、ハゲ。
先日、FeedlyGraph を1週間で公開した。 photo credit: surfzone™ via photopin cc 公開までを振り返ってみる。 0日目 アイデア出し 僕は普段からこんなサービスが欲しいな〜というアイデアをメモに残すことにしている。 iCloud 便利。 今回はそこから規模感が合うものをチョイス。 1日目 アイデアの検証 問題を解決するサービスが世の中にあるかどうかを確認した。 今回は「Feedly の購読者数の推移を確認したい」が問題。 既にあった解決策に近いものは以下のとおり。 Feedly Insight Feedly Subscribers Checker 2 FeedlyやlivedoorReaderの購読者数をGrowthForecastにポストするRubyスクリプト作った 上から順に WordPress でないと使えない 今の購読者数しかわからな
iOS開発者にためになる大ヒットアプリ開発社のインタビュー記事6選 - showrtpath - iOSブラウザ開発日記
2013-12-24 iOS開発者にためになる大ヒットアプリ開発社のインタビュー記事6選 iOSの大ヒットアプリは開発者のアイデアや思想、テクニックなどで成り立っています。今回まとめたのは、その一部分が感じられる開発者のインタビューです。これらのインタビューから大ヒットアプリのヒントをつかめるかもしれません。 Pocketの注目新機能「ハイライト」秘話：アイデア誕生からローンチまで2年を要した理由とは？ : ライフハッカー［日本版］ 『Mailbox』のつくりかた：最強のGmailアプリを生んだ、試行錯誤の舞台裏 : ライフハッカー［日本版］ 『CARROT』のつくりかた：作家志望の私は如何にしてプログラミングを覚えてアプリを生み出したか : ライフハッカー［日本版］ ユニクロ「スマホアプリも世界展開」でシステム再構築、その全容がすごい【ファーストリテイリング×ゆめみ座談会】 - エンジニ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
