電子書籍「エスクペリエンス ポイント」のサイトができるまで電子書籍「エクスペリエンス ポイント」の Web サイト構築のプロセスを最初から最後まで記録しました。 http://www.yasuhisa.com/book/exp/
半年ほど前に書いた「コーディング規約をまとめてみた (Ruby編)」に引き続き、Railsのコーディング規約もまとめてみました。前回と同じように、できるだけ理由を併記するよう努めました (主観的なものも含まれていますが…)。 気に入らない規約や、この記事に書かれている規約以外にも気をつけていることなどありましたら、コメントなどで教えてもらえると嬉しいです (理由も合わせて書いてくれると助かります)。 Railsのコーディング規約は以下のページを参考にまとめています。 http://guides.rubyonrails.org/contributingtorubyonrails.html#follow-the-coding-conventions https://github.com/bbatsov/rails-style-guide 前提 コード例は「コーディング規約をまとめてみた (Ru
最近買った新しい市場のつくりかたという本の感想文。 足で書いた本は面白い 今までになかった新しい商品を販売することで成功した人たちを訪ね歩いて、成功の理由、あるいは新しい商品を発送する原理のようなものを導こうとした本。いろいろ参考になった これは「足で書かれた本だ」という印象を持った。理念ではなく、具体を重ねて論に到達するような本。こうした書かれかたをした本は、読むといろんな発想が広がる。同じ具体例を作者と共有しつつ、作者とは異なった理念の衝突が楽しかったりもする 「足で書かれた本」とは逆に、理念先行、論が理念を補強する「頭で書かれた本」というものもある。頭で書かれた本で描かれる理念は整合がとれていて、読んで「ははぁ」と頷く部分も多いのだけれど、発想はそこで閉じてしまうことも多い 個人的にはたとえば、佐々淳行の危機管理に関する本は、「頭で書かれた本」であるように思う。佐々の危機管理に関する
成功企業のビジネスモデル ・クックパッドの強さの理由は? ・アップルのプラットフォームビジネスとは? ・なぜドラクエ9は大ヒットしたのか? 事業成長ストーリーの描き方 ・複数のピクト図を“時間軸”に並べて描く ・アップルコンピュータからアップルへ ・進化するアスクル 手書きのピクト図
わけあって『リーン開発の本質』を再読しています。る。日本の中でアジャイル開発を、できるだけ管理者の言葉として伝えたかった本です。この本は本当にたくさんの人に読んでほしいなぁ。ここに、そのあとがき、として書いた文章を掲載します。 最後に書いた、 多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則を作らなければならない」とか「人は交換可能である」というメンタリティから発している。もし、組織の文化や方針の中心にこのような考え方があると、もしくは多くの管理者がこのように考えているならば、「決して」リーン活動は成功しない。そうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。ここをやり間違えてはならない。 日本のソフトウエア業界が、人の持つ知恵と力を大切にしながら、高品
HCD(人間中心設計 human-centered design)と UXD(利用者体験デザイン user-experience design)の違いについて。 「これをしなければ○○ではない」という必須手順が、HCD にはあります。UXDにはない。 HCD の場合は、 ISO 13407では、まず人間中心設計の必要性の特定を求めている。次に4つのステップを一連のプロセスとして回していく。 - 使用状況の理解と明示 - ユーザーと組織の要求事項の明示 - 設計による解決策の作成 - 要求事項に基づく設計の評価 ※上記引用元『人間中心設計 - @IT情報マネジメント用語事典』 ユーザー観察、ユーザーのモデルづくり、デザイン、評価など、ひとつひとつの手法はすでに多くの方が実践していて、それぞれに関する情報も世の中に広がってきています。そうした個別の要素を上手くつなぐプロセスが人間中心設計なので
「UI」は「ユーザー・インタフェース」。 「UX」は「ユーザー・エクスペリエンス」。 「UI/UX」と混同表記する人がいるから、「UI と UX の違い」という不要な疑問も生じるんです。 「UI と UX の違い」なんて瞭然ですよ。 それを説明するために、ちょっと回り道します。 「怪我と痛みの違い」は瞭然ですよね。 「怪我」は客観的物質的存在です。 怪我した本人でも他人でも誰でも、そこに怪我が「ある」ことを観測できる。 一方、「痛み」は主観的な感覚ですね。 他人の「痛み」は観測できない。 痛がっている様子から「痛いんだろうな」と推定することはできるけど。 「UI」が「怪我」、「UX」が「痛み」に対応した比喩です。 「UI」は客観的物質的存在です。 誰が見ても iPhone にホームボタンは一つです。 誰が押してもホーム画面に遷移する、というインタラクションです。 一方、「UX」は主観的な体
In simple cases, if you use Heroku, application deployment process can be as easy as one shell command. But Heroku does not provide enough scaling and flexibility for more advanced scenarios or more serious load. If you need to test something and then be able to expand to thousands of requests per second, EC2 from Amazon Web Services is definitely the way to go. It provides you with a virtual syst
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く