タグ

2016年4月24日のブックマーク (13件)

  • カスタマージャーニーマップ、失敗のすゝめ | DevTab - 成長しつづけるデベロッパーのための情報タブロイド

    カスタマージャーニーマップとは、ウェブサイトやサービスを利用する顧客がどのようなプロセスで、どのようなタッチポイントをもって、どのような感情と思考をもってどのような体験をするのかを1枚絵のように視覚化したものです。その名の通り、「顧客(カスタマー)の旅(ジャーニー)をしるした地図(マップ)」です。 メジャーな手法ですので、ここで詳細な説明は行いませんが、ユーザーの感情や行動が全体像として図解されていることや、図解ゆえに関係者が集まって議論しやすいなどの利点があるため、サービス企画やウェブサイト制作時によく使われる手法です。 私たちギルドワークスでもユーザーの動きを見立てる方法として、カスタマージャーニーマップを利用しています。 ユーザーストーリーマッピング、サービスブループリントなども利用していますが、カスタマージャーニーマップはユーザーの感情や思考やモチベーションも関連させられるところが

    カスタマージャーニーマップ、失敗のすゝめ | DevTab - 成長しつづけるデベロッパーのための情報タブロイド
    ama-ch
    ama-ch 2016/04/24
  • InfoQ: かんばんとスクラム - 共に最大限に活用する

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

  • react-storybookを用いたReactコンポーネント開発 - Hatena Developer Blog

    こんにちは!Webアプリケーションエンジニアの id:amagitakayosi です。 今日はReactコンポーネントを手軽に開発するためのツールを紹介します。 前回のあらすじ react-storybookとは 導入してみる 初期設定 storyを作成する 起動 イベントを監視する Hot Module Reloadingの仕組み メリットとデメリット リアルタイム確認できる 導入が簡単 ストーリー駆動開発できる デメリット: Webpackの機能で動いてる まとめ 前回のあらすじ developer.hatenastaff.com 前回の記事では、Reactコンポーネントをnpmパッケージとして開発する方法を紹介しました。 対象としたのはこちらの無限スクロール用のReactコンポーネント。 http://www.npmjs.org/package/@fand/react-infini

    react-storybookを用いたReactコンポーネント開発 - Hatena Developer Blog
  • kintone開発プロセス

    Facebook's 10-year plan, Buzzfeed misses forecast, and more news

    kintone開発プロセス
  • カンバン仕事術が活かせそうな点満載だった

    会社でホワイトボードに書き出してはいるものの上手くいってなかったので、いっときAmazonでも在庫切れになったりとい人気っぽいカンバン仕事術を読んでみた。 総論 ってきり、はじめはスクラムとかXPとかアジャイルの手法ゴリゴリかな?と思っていたのだが、むしろ逆で、かなりピュアなカンバンのだった。 スクラムとかXPとかのアジャイルを現場に持ち込むのはそれなりにパワーいるが、こののようなカンバンだけなら簡単に導入できる部分がありそう。 カンバンでの見える化からはじめて、いきなりやるには、作法がわからないとか、その作法の裏にあることを理解できてなくて諦めがちなアジャイルの手法にも段々ともっていくというようなこともできるのではないだろうか。 カンバン仕事術だけでは具体的案イメージがつかなかった点も多いのだが、アジャイルコーチの道具箱 – 見える化実例集を合わせて読んだらよりイメージがわいたのでセ

    カンバン仕事術が活かせそうな点満載だった
  • Promise Error Handling

    Promise Error Handling 約束されたエラー Promiseとエラーの基 Promise内で起きた例外は自動でキャッチされる エラー処理は.catch(fn)で行う var promise = new Promise(function(){ throw new Error("例外"); }); promise.catch(function(error){ // 例外をキャッチできる }); よくある問題 .catch(fn) をしないとエラーログも出せない .catch(fn) をしわすれてエラーの握りつぶしが起きる = unhandled rejection (.catchをしてないpromise) 4.6. Promise.prototype.done とは何か? 現状のunhandled rejectionへの対応 unhandled rejectionが発生した

    ama-ch
    ama-ch 2016/04/24
    unhandled rejection
  • アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー!) | DevelopersIO

    アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー!) はじめに 2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。エントリーは、その時の様子を文章化したものです。 アジャイル・クラウド・DevOps は実際のところどんなものなのか? 上手くいく/上手くいかない取り組みの違いはどこなのか? そもそもそれは当にやるべきか? 組織とエンジニアの関係、評価はどのようにすれば良いのか? といった幅広いテーマについて語っていただきました。 このインタビュー記事は、 アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方 手を付けたけど、なんだか上手くいっていないことにお悩みの方 もしく

    アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー!) | DevelopersIO
  • もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita

    はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo

    もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
  • Squash your commits | The GitHub Blog

    ProductSquash your commitsGit’s flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the… Git’s flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the merge button on GitHub only created merge com

    Squash your commits | The GitHub Blog
    ama-ch
    ama-ch 2016/04/24
  • JavaScriptの文化とleftpadの話とpadStartについて - from scratch

    無駄にラノベみたいに長いタイトル書いちゃったんですが、まぁやっぱり一言くらいは残しておくかと思ったので書きます。長いのでまとめだけでも見てもらえると良いかもしれません。 leftpadの話はかなり大事になっていて、Node.js界隈を中心としてその他のOSSをやっている全体的に話が波及しています。幾つかの記事を読みました。今回はJSの文化歴史についてちょっとずつ書いていこうかなと思います。 の虫: npmからkikとその他諸々が消されたまとめ 江添さんの話はすごくよくまとまっていて、ネタも含めた上で一番面白い話になっていました、ここで言われている下記の疑問に答えていこうと思います。 もっと憂うべきパッケージがある。isArrayだ。このパッケージは一日88万回もダウンロードされていて、2016年2月だけの一ヶ月間に1800万回もダウンロードされていて、72個ものNPMパッケージが依存し

    JavaScriptの文化とleftpadの話とpadStartについて - from scratch
    ama-ch
    ama-ch 2016/04/24
  • 社内共用カメラのすゝめ - クックパッド開発者ブログ

    舘野 (id:secondlife / @hotchpotch) です。 クックパッドでは会社の中心にキッチンがあり、社員同士でランチやお菓子を作ったり、イベントを開いたりと社内のコミュニケーション用途で広く使われています。そんなキッチンで作られている様々な料理や、楽しそうなコミニュケーションをその場に居ない人にも伝えたいなー、どうにか伝える方法は無いのかな〜と思っていました。 そんな中、より良い組織を作るために の中でも触れられているコミニュケーション改善の話をしている最中、社内に共用のカメラが置いてあって、撮った写真が何もせずとも自動で社員が見れる場にアップロードするだけの仕組みを提供するだけでうまく行くかも、と思ったので2014年末に作ってみました。 サービスのコンセプト 作るときに盛り込んだコンセプトは以下の二点です。 運用コストがゼロ アップロードコストがゼロ 運用コストがゼロ

    社内共用カメラのすゝめ - クックパッド開発者ブログ
  • JSDocをランタイムassertに変換するBabelプラグインを書いた

    JSDocをassertに変換するライブラリとそれを使ったBabelプラグインを書きました。 azu/babel-plugin-jsdoc-to-assert: Babel plugin for jsdoc-to-assert. azu/jsdoc-to-assert: JSDoc to assert ライブラリのjsdoc-to-assertの方は、JavaScript ASTのコメントからassertの文字列を作り出すだけのシンプルなものです。 実際に使う場合は、Babelのプラグインとしてbabel-plugin-jsdoc-to-assertを使い、コードを変換してランタイムassertを追加させます。 やっていることとしては、FlowTypeをランタイムチェックするbabel-plugin-typecheckのJSDoc版とも言えます。 babel-plugin-typechec

    JSDocをランタイムassertに変換するBabelプラグインを書いた
  • npmからkikとその他諸々が消されたまとめ

    npmとは、node.jsにおけるパッケージシステムのことだ。npmを使えば、他人の書いたnode.jsベースのプログラムとライブラリの入手と利用がとても簡単になる。 そのnpm界隈が混乱している。発端は以下のURLだ。 I’ve Just Liberated My Modules — Medium Azer Koçuluはkikという名前のnpmパッケージを公開していた。このkikというソフトウェアの中身についてはここでは関係がない。 さて、それとは別に、kik.comというスマフォ用のチャットアプリを出しているKik Interactive社がいて、kikという名前のパッケージをnpmで出したいので、名前を明け渡すように要求した。 Azerはこの要求を拒否した。すると、Kik Interactive社はnpmの管理者に片っ端からメールを投げまくり、そのうちの一人が反応して、Azerの意

    ama-ch
    ama-ch 2016/04/24