Dropbox paperのチームが良いプロダクトデザインの為に大切にしている３つのこと｜Hiro Yamada（foriio founder）
12月1日にレッドブルスタジオ東京にて、Dropbox Japan主催のUnleash the World’s Creative Energyと題されたイベントがあったので行ってきました。 クリエイティブな仕事のコラボレーションをサポートするツールとなりつつある最近のDropbox。Design managerのKurt VanerさんがDropbox Paperの制作現場の様子と素晴らしいデザインの傾向というタイトルで話してくれたのでメモを残しておこうと思う。 先程言った通り、Dropboxはただのファイル共有サービスではなくなっている。（友達紹介だけで14GBくらいの容量を稼いでいたころが懐かしい…。）そもそもファイルの共有サービスというより、クラウドストレージ的な側面が最初は強かったサービスだが、今ではPaperやShowcaseというサービスなどがローンチされ、彼らが次のフェーズに
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
git commitをやり直しする＆取り消しする(「get commit --amend」と「git reset」) - hogehoge foobar Blog Style Beta
git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。 直前にしたコミットをやり直す（git commit --amend） 直前にしたコミットをやり直す場合、「git commit --amend」を使用します。 例えば、直前のコミットログが以下のような状態だったとします。 実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。 コミットログ(git commit --amend 実行前) $ git log commit cca638b48b4c8be7ad5432f7882497534b04e2b4 Author: mrgoofy <hogehoge@example.com> Date: Wed Sep 8 23:03:57 2010 +0900 2nd Commit.-> New Add File : bar.txtこ
国内におけるアジャイル開発、どのプラクティスがいちばん使われている？ IPAが調査報告書を公開
国内でアジャイル開発を普及させることを目指し、IPAはアジャイル開発の国内での活用事例をまとめた｢アジャイル型開発におけるプラクティス活用事例調査｣として、調査報告書、およびプラクティス活用のためのリファレンスガイドなどを公開しました。 IPAがこのような調査報告書を公開する背景として、「国際競争力強化のため、世界的に主流になっているソフトウェア開発手法であるアジャイル型開発に日本でも取り組む必要がある。しかし、現状、日本では「普及が遅れており、ようやく認知され始めた」段階であるとされている」と調査報告書に記述されています。 報告書では、国内の26のアジャイル開発事例についてその状況をまとめることでナレッジの集積をはかるとともに、今後の普及に向けた提言を記しています。 日次ミーティング、ふりかえり、イテレーションが国内3大プラクティス 国内でアジャイル開発の普及が阻害されている要因として、
ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi - @i2key のBlog
Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d
デザインデータのバージョン管理ができるAbstractを試してみた✌ | UXデザイン会社Standardのブログ
複数人で1つのデザインデータを編集していると、突き当たるのが「どうやってマージするか問題」です。 作業人数分のデータを複製して用意したり、「これから◯◯.sketch触ります。開かないでください????」とチャットで周知したり……そんな経験をした方も多いのではないでしょうか。 そんなデザイナーの悩みを解決してくれるのが、今回紹介するAbstractです。 Abstractとは AbstractはアメリカのElastic Projects, Inc.が提供しているサービスです。どんなサービスか一言で説明すると「デザイナー向けのGitHub」といったところでしょうか。 Gitの仕組みを利用して、デザインデータ（.sketchのみ対応。Adobe系も対応予定）に対してブランチを切ったり変更内容をコミットしたり、差分をマージする、といったことが可能です。 まだ正式リリースはされておらず、現在はPr
5分で理解するリーンな「かんばん」
Henrik Knibergさんのブログで「One day in Kanban land」という記事を見つけました。そこでは、かんばんの使い方のポイントがうまく描かれたマンガが紹介されています。各国語に訳されているので、ヘンリック氏に許可をいただき、日本語訳してみました。 赤い人がプロダクトオーナー（PO）の役割で、青い人たちが開発チーム（DEV。ここでは2名ずつ2チーム）、緑の人がテスターだと思います。テスターチームはデプロイまで担当しているみたいですね。 また、「TODO」「開発」「デプロイ」という各ステージにはWIP（Work in Progress：仕掛り作業）が制限されています。WIP制限とは、各ステージにWIPの数以上のカードを貼ることができないというルールです。
インターンシップ「サービス開発演習」の舞台裏 - クックパッド開発者ブログ
こんにちは、投稿開発部副部長の勝間(@ryo_katsuma)です。 普段はクックパッドのレシピ投稿周辺のサービス開発を行う部署のマネジメントやエンジニアリングを担当しています。 さて、クックパッドでは、8月10日から先日9月2日まで技術インターンシップを開催していました。 講義全体のまとめについては、先日公開されましたこちらの記事を参照ください。 クックパッド サマーインターンシップ2016の資料を公開します Service Development at Cookpad 2016 summer internship 今回は、私が担当した4日目の講義「サービス開発」について、どのような狙いを持って設計したか、また参加学生の皆さんがどのような反応だったかなど、舞台裏についてご紹介いたします。 昨年の振り返りと課題 技術インターンシップにおいて、サービス開発の講義は昨年度も私が担当しました。
ゲームデザイン入門＜目次＞
●ゲームデザイン入門＜第六版＞ ――1992.08.16 初版発行 ――1997.08.15 第六版第三刷発行 ――企画・編集 ざるの会 ※基本的に原文のままHTML化してあります。 はじめに オフセット版発行に当たって ミクロビデオゲーム理論 1．意義と限界 1）意義論 2）限界論 2-1）理論内の「限界」 2-2）理論自体の「限界」 2．基礎概念 1）定義 ～「ビデオゲーム」とは何か？ 2）本質 ～「面白い」とはどういう事か？ 2-1）刺激と快感 2-2）出力に由来する快感 2-3）パルスチャート 2-4）「考える」 ～意思決定の快感 3）難易度 3-1）定義 3-2）情報処理モデル 3-3）思考波モデル 3-4）設定 4）トータルデザイン 4-1）刺激の「質」と「量」と「配置」 4-2）刺激の逓減性 4-3）「モデリング」 4-4）回転力 ～何がサイクルを回すのか？ 4-5）ゲームデ
複数人でのWebサービス開発で便利だったもの - Qiita
遊びに使えるWebサービスを友人と一緒に作成中。 仕事じゃなかなか使えないようなツールやサービスを無料の範囲内で使ってみてるんですが、かなり便利。 忘れないようにまとめてみます。 なおJavaとJavaScriptを使ってるので、それに関する内容が多いかも。 なお、次のような感じで開発進めてます。 週に1回集まってミーティング兼もくもく会 集まらない日は各自のペースで作業 機能などを作ったらプルリクエスト出して承認もらって取り込む サーバー側がJavaでクライアント側がJavaScript BitBucket Gitリポジトリをホスティングしてくれるサービス。 他にも類似サービスはいろいろあったけど、非公開リポジトリを無料で作れるってのが決め手。 基本的にソースコードはここで一括管理して、各自が作った機能とかは必ずプルリクエストを出す運用で活用中。 ReadmeとかWikiも便利で、ここに
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
受託開発にアジャイルは適用できるか？
3つの大事なこと まず全ての受託開発に適用できるかというと、それは難しいと考えています。 これまでクレイに発注いただいた開発で、次のような案件に適用してきました。 Webサービス スマートフォンアプリ プロトタイプ、研究開発 要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。 次に規模ですが大きくても3，4人で半年から一年程度の小規模な開発が多かったです。 ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。 特に次の3つが進めていくために大事なことと感じています。 クライアントにプロジェクトに責任を持って参加してもらう アジャイルに適した契約にする 開発プロセスを出来るだけ透明化する クライアントにプロジェクトに責任を持って参加してもらう 「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでし
開発を効率的に進めるられるまでの道程
27. DroidKaigi 2015/04/25 @cattaka_net SharedPreferencesの差し替え プロダクションコード public class SharedPreferencesFactory { static SharedPreferencesFactory INSTANCE = new SharedPreferencesFactory(); public static SharedPreferencesFactory getInstance() { return INSTANCE; } public SharedPreferences newInstance(Context context, String name) { return context.getSharedPreferences(name, Context.MODE_PRIVATE); } }
よく言われる「施策を数字で」というやつについて - クックパッド開発者ブログ
新規広告開発部の大野です。今回は、「目標を達成するための施策を数字で考える」ということについて、普段やっていることを書きます。 施策の評価に関しては Rを使う などいろいろなノウハウがありますし、Web上の行動改善などはそれはそれで、世にノウハウがたくさんあります 。 今回は、例えば、期初に事業目標を決めた次のステップとして、全体の優先度を決めるあたりの段階の話をしましょう。 分解： 数字から取り組む施策を決める まず、どの施策をするかを決めるわけですが、必ず、最初に目標を因数分解しています。 広告なら「収益 = 単価 × 在庫 × 販売率」といういつもの式があるので、これが元です。例えば 単価がCPCなら在庫はクリック回数。つまり、imp（表示回数） × CTR 単価が表示なら、在庫は単純に imp となります。で、販売方法によって、どの項をあげるのが有効か、つまり、現実的に伸びるか、ど
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
受託開発の会社が自社サービスを1年運用してきた内容・結果と今後の課題 - ヴェルク - IT起業の記録
boardというサービスを正式リリースしてからちょうど1年が経ちました。 以前、「受託開発の会社が本格的にWebサービスを開発・運用してみてぶつかった課題（只今5ヶ月目）」という記事を書きましたが、その続きというか、現在の状況を書きたいと思います。 boardの開発の始まり boardは2年前の9月に開発を始めました。 その頃は起業して3年目の後半で、案件の管理や見積書・請求書作成などはExcelでやっており、案件数の増加とともに、Excel管理がだいぶしんどくなってきていました。 そこで、何か請求書作成系のクラウドサービスを使おうと思って探し始めたのですが、案件単位で受注するビジネスモデルにフィットするようなサービスがなく、また支払管理・売上管理・見込み管理など、自分が会社を経営する上で必要な部分まで欲しいレベルでカバーしているものがありませんでした。 ちょうど9月の連休があったので、自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cygamesを支えるPHPと、その高速化の取り組み
Trello のススメ
DeNA Engineering - DeNAエンジニアのポータルサイト
