タグ

2013年9月6日のブックマーク (6件)

  • GitHub - uiur/seiseki.pdf

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - uiur/seiseki.pdf
    yanbe
    yanbe 2013/09/06
    どれどれ…と成績表を見たら、学生のときにお世話になった先生方の名前がいくつもあって、図らずも背筋が伸びる感じになった…
  • 入れるべき機能と排除すべき機能の分類メモ | fladdict

    クライアントプレゼン用の覚え書き。 「機能」のほとんどは以下の5種類に分類できるので、搭載するまえにどのカテゴリに属するかよく考える。 1:必須機能 メーラーの送信、CC送信、カメラの撮影、オートフォーカスなど。 ついていて当たり前、つけなければユーザーの不満が増加する機能。 必須機能が実装されていない場合、基的に勝負の土俵には立てない。 予算をかけすぎても、べつにユーザーへのアピールにはならない。 2:訴求機能 なくても不満ではないが、あればユーザーの満足を増加させる機能。 ユーザー自身も無自覚的で、初期段階では実物を見るまで需要の存在自体が見過ごされている。 女子向けのポップな一眼レフや、(1979年当時)歩きながら音楽が聞ける機械など。 メリットは高いがそもそも発見するのが大変だったりする。 差別化機能のうち需要の高いものは、業界内で徐々にパクられ必須機能にシフトしていく。 3:沼

    yanbe
    yanbe 2013/09/06
  • Google

    世界中のあらゆる情報を検索するためのツールを提供しています。さまざまな検索機能を活用して、お探しの情報を見つけてください。

    Google
    yanbe
    yanbe 2013/09/06
  • 僕がいっさい図面を見ないから、代官山 蔦屋書店ができた:日経ビジネスオンライン

    製のモノが、サービスが売れない。性能はいいのに。機能も充実しているのに。壊れないのに。親切なのに。多くの日企業が直面している、「いいモノをつくっているのに売れない」問題。 なぜ、売れない? それは、日製品の多くが、かっこよくないから。美しくないから。カワイくないから。気持ち良くないから。つまり、デザインがなっていないから。 どうして、デザインがなっていない? それは、経営者がデザインのことをわかってないから。つまり、経営者が「ダサい」から。だから、デザインをマネジメントできない。 経営者がダサいと、日企業はつぶれる。では、どうすれば、デザインをマネジメントできるのか? どうすれば、かっこいいを、美しいを、カワイイを、気持ちいいを、商品化できるのか? どうすれば、ダサい経営から、デザインできる経営に転換できるのか? ifs未来研究所所長の川島蓉子が、時代を切り開く現役経営者やデザイ

    僕がいっさい図面を見ないから、代官山 蔦屋書店ができた:日経ビジネスオンライン
  • Kibana3というのもありまして

    前回は3番煎じぐらいでしたが、今回は初記事かな?(だといいな) Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というのが存在します。 Kibana3って? Kibana2はRubyで書かれていましたが、Kibana3はHTMLJavaScriptで構成されています。 ですので、ApacheなどのWebサーバに配置することで、利用が可能となります。 ただ、HTMLJavaScriptのため、ブラウザ上で動作するためブラウザが動作するマシンからElasticSearch(通常だとhttp://マシン名orIPアドレス:9200/とか)にアクセスできなければいけないという制限があります。 この条件さえクリア出来れば、Kibana3ではKibana2よりも様々なパネルが用意されていて、色々できそうなのでお勧めです。 インストール ElasticSearchやログについて

    Kibana3というのもありまして
  • なぜリリース頻度を上げるのか

    サービスのリリースで書いたようにネットのサービスを提供している企業は新バージョンのリリースの頻度を上げるよう常に努力しています。 リリースの頻度を上げる理由は、サービス開発の方向の軌道修正を細かく行いたいからです。少しずつサービスを改良し、その改良がユーザーにどのように受け入れられたかという反応を元に将来の開発を行っていきます。このフィードバックサイクルを短くすることによりこまめな軌道修正が可能になります。 リリース頻度が低く、リリースサイクルが長いと、その期間に加えられた変更の数が多くなり それぞれのリリースでの変更量が大きくなります。変更が多い分、リリース後の不具合発生の可能性が高くなります。また、リリース後の障害発生時の問題の切り分けも難しくなります。小さなリリースを頻繁に行うことにより、一歩一歩問題がないことを確認して次の一歩を踏み出すように、よりリスクの少ないリリースが可能になり