サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
zerobase.hateblo.jp
非モテ系エンジニアがデザインとかUI/UXについて勉強してみた - IDEA and Players この記事を読んだとき、自分は単純に「へー、そういう発想もあるのかー」と感心したくらいなんですが、安藤先生はUXの本来の意味を見失っている、と指摘されたんですよね。 「歩く距離を増やしたら、苦情が減った? だからUXが向上した? じゃあ、お年寄りに長い距離を歩かせるのが良いユーザ体験なの? 馬鹿なの?」 と、まあ本当はもっとご丁寧な口調だったんですが、昨今の言葉だけで中身が空の「UI/UX」には憤懣やるかたないご様子で。 このお叱りの言葉は、かなり胸に突き刺さりましたね。もっとユーザについて想像しろよ、数字なんかじゃなくてさ、と言われたみたいで。 そうなんだよねえ。 「良い体験が何かということを想像できない人間が、他人の良質なユーザ体験を計画できるはずがない」 だよねえ。 さらに、UXDに携
Facebook上の「シェアさせて頂きました」の意味がわからない。以下、いくつかの意味解釈を検討していく。 パーミッション? 「させて頂く」の意味がわからない。許可や承認が必要だとは思えないからだ。 そもそも投稿者がシェアされたくない場合は、シェア可能(公開 public)なパーミッションで投稿しないはずだ。例えば「友人のみ」(friends only)な設定にするだろう。 シェア可能な設定で投稿されているということが、すでにシェアの許可を意味している。「シェアしてもよい」ないしは「シェアしてほしい」といった意図があるからこそ、シェア可能な投稿にしているはずだ。 だから、わざわざ「させて頂く」という意味が分からない。敬語が過剰で、誤用だと感じる。「シェアしました」でいいだろう。 感謝の表明? あるいは「シェアしました、ありがとうございます」ならわかる。しかし、感謝の言葉なしに「シェアさせて
いっときPR配信サイトのフィードを購読して、ウェブ業界のあらゆるニュースリリースをウォッチしていた気持ち悪い人は私です。 10年くらい前の話です。 いろんな学びがありましたけど、端的に言えば昨今「グロースハック」と呼ばれてるような手法の重要性に気づきました。 人はウェブページを開いて1秒以内に「自分には関係ない」「理解できない」という意思決定をして去るよなあ、という当時ヤコブ・ニールセン博士が言ってたことを実感したんです。あらゆるニュースリリースを大量に読みまして。 さて、昨今「グロースハック」が流行っております。たいへん結構なのですが、問題は「10年前にウェブ業界がとっくに通り過ぎてきたノウハウ」を、またやりなおしてる感があるんですね。 まずは歴史に学んだ上で、その上に構築していったほうがいいのにね。残念です。 大橋ぜんたろう氏が開発したプロパテンション指数とか、知らんでしょ、最近のグロ
「日本人はハイコンテキストだから、言葉で説明しなくても、互いに理解しあえる(だからロジカルシンキングが発達しない)」という議論に、ぼくは懐疑的です。日本人は互いに理解しあえていない。理解しあっているような幻想があるだけ。 それは日本人に限らない。人間は「互いに理解しあっている」という幻想を持っているだけ。「相互理解は結局のところ幻想にすぎない」という理解のうえに、それでもなんとか回る社会にしていくことが大事。 それに対して、日本人の問題は、「日本人はハイコンテキストだから、言葉で説明しなくても、互いに理解しあえるというメタ幻想を持っていること。それによって「相互理解できている」という幻想を強化していること。 「日本人は言語を尽くしたコミュニケーションをしなくても、理解し合える」は誤り。 「日本人は言語を通じた相互理解を早々に放棄し、曖昧な理解のままに物事を進める」というのがぼくの認識。 そ
「やぁ、ビル・ゲイツだけど何か質問ある?」ということで本人が降臨して次々と回答した全問答まとめ - GIGAZINE 原文:Hello Reddit – I’m Bill Gates, co-chair of the Bill & Melinda Gates Foundation and Microsoft founder. Ask me anything. : IAmA 09:スティーブ・ジョブズはアシュトン・カッチャーが演じました。ビル・ゲイツは誰に演じてもらいたいですか? サミュエル・L・ジャクソン というやりとりを見て、「黒人俳優の名前をあげるなんて、ビル・ゲイツさんはシャレがきついなあ」と面白がっていたのだが、原文で裏を取ろうとしたら、GIGAZINEに騙されていたことが分かった。 誤訳というかなんというか DepartmentOfWorks: Steve Jobs had As
ネイティブとHTML、その決定要因としてのプッシュ通知 現状、「単にスマホに情報提供したい」だけでもネイティブ・アプリを作りがちですが、その主要な理由の一つがプッシュ通知。 iOSもAndroidも、端末にプッシュ通知したければネイティブ・アプリを作らなければならない。 サードパーティ「通知センターアプリ」 そこに目をつける人は当然いるわけで、この問題を解決するスタートアップがあります: Boxcar Pushover これらを「通知センターアプリ」と呼ぶことにします。この仕組みによって、ネイティブ・アプリを作らなくても、ウェブサイトから端末にプッシュ通知を送信できるようになります。 発想としては「端末へのプッシュ通知のためにはネイティブ・アプリが必要」「でも、たかがウェブサイトが、いちいちネイティブ・アプリなんか作るのは…」「そうだ、ぜんぶまとめて一つのアプリにすればいいじゃん!」という
同じ「部品」の意味で、英語には “component” と “module” がある。その違いを考えた。なお、オブジェクト指向、ドメイン駆動設計の観点である。 (以下の定義や解説は個人的な見解に過ぎないのであって、「言葉の意味の押し付け」と誤解されないよう願いたい) 定義 component は object の部分集合である (object ⊇ component) module は component の部分集合である (component ⊇ module) module は「元の context を離れて再利用できる component」である(実際に再利用したかどうかではなく、可能性の問題である) 解説 ドメイン駆動設計における「ドメイン」の特徴は固有性にある。汎用性ではない。 “module” には standard (標準)や dettach(取り外し)の意味が含まれる。 ゆ
最近、ScalaとSmalltalkを触っていて思ったこと。 一見すると、関数型は「データ」より「処理」を重視しているように見える。 関数型プログラミングパラダイムそのものは「副作用のない関数」の合成による演算の恩恵を最大限に享受するパラダイムだ。副作用がないので並列演算の高速化に向いている。 昨今のマルチコア化やクラスタ化のメリットを最大に活かすには関数型プログラミングパラダイムの導入が鍵だろう。プロセッサ単体での性能向上が頭打ちになってきたのだから、並列演算に対応したプログラミング方式へのシフトは不可避だろう(ただし高性能が要求されない分野は除く)。 関数型プログラミングパラダイムは、データよりも処理を重視したパラダイムのように見える。 一見すると、オブジェクト指向は「処理」より「データ」を重視しているように見える。 オブジェクト指向プログラミングパライダムは、(Smalltalk的に
(結構駄文であることをあらかじめお断りしておきます) 募集要項によると、政府CIO補佐官の報酬は「日額 40,460円~59,280円」とのこと。うん、安いね。ありえない。「週3日以内」「1年契約」のパートタイム・ジョブで、これは。 専門性の高い人を短時間雇うのは、一般的に高い時間単価になります。弁護士5万円/時とか。 日額5万円で8時間勤務だと6,250円/時ですよ。なにそれ。 これ、応募する人、「日額5万円」に目がくらんじゃった層の人か、「お国のために滅私奉公」でけっこういろいろ捨てられる人の、どっちかじゃん。 たとえばフルタイムのサラリーマンだったら、「いまの仕事は辞めるの?」って話だし。よっぽどいい会社なら「週2契約」とかにして継続雇用契約になるかもしれないけどね。 いわゆる「回転ドア」っていう言葉があって、行政と民間企業の間をグルグル人が行き来できるっていう意味なんだけど、この場
404 Blog Not Found:プログラミングとアプリ開発の違い プログラミングしたい人々は、物が出来るまでの過程を楽しみたい人である。だから、「DBにクエリーをかけてHTMLにぶちまけるだけの簡単なお仕事」が退屈で仕方がない。しかし、アプリ開発したい人々にとって、物ができるのは出発点にすぎない。彼らが楽しむ過程というのは、それを公開し、それを人々が使ってみるところにある。それがただのハッシュなのか人工知能なのかというのは、はっきり言っておもちゃの材質程度の意味しかない。 「DBにクエリーをかけてHTMLにぶちまけるだけの簡単なお仕事」と「コンピューター・サイエンス全開のハイソなプログラミング」の二択ではなくて、第三の道があります。 それは「モデルの持つ概念の力を活かしてビジネスをモデリングするアプリケーション・エンジニアリング」です。 『エリック・エヴァンスのドメイン駆動設計 ソフ
最近ようやくウェブ・スタートアップ界隈にもペーパープロトタイピングが普及してきた。 今後は「プロトと実装の差」が理解されていくといいな。 みなさんプロトタイピングを「設計フェーズ」でやってると思うけど、「設計フェーズ」「実装フェーズ」って分かれてるのがおかしい、という話。でも、これが変わるには十年かかるだろうな。 プロトタイピングに慣れてきた人は、プロトで設計を完璧に詰めようとする。でも実装して触ってみるとぜんぜん違うわけだ。 そりゃ、「動かないプロトから想像した触り心地」と、「実際の触り心地」が一致するわけないじゃん。 みなさんも経験あるでしょ? 例えば、iPhoneアプリ作ってて、実装後のテスト段階でのUI仕様変更。リリース直前に手戻り。デスマ。お疲れ様です。(←嫌味じゃない。俺も経験あるから言ってんのよ。 そうなるのは当たり前。実機で実装を触らずに、事前の予想だけで完璧なデザインがで
プロフェッショナル・サービスの収益性の方程式を紹介します: 粗利益 = 勤務時間 × 稼働率 × 時間単価 × (1 - 原価率) 稼働率:勤務時間中の売上になる(顧客に請求できる)作業時間の比率 時間単価:時間当たり請求額(売上) 原価率:売上に占める売上原価の比率。売上原価は外注費など。販管費は含まず。 うちの場合は、個人独立採算制なので、自身の粗利益から本部費を会社に支払った残りが、自身の受け取る報酬になります。 →自立したプロフェッショナルのための自由な企業の制度 - Zerobase Journal 最重要指標は「時間単価」 「時間単価」という KPI が最重要です。 この場合は、その本人が生み出した付加価値=粗利益ベースで考えてるので、正確には「時間あたり粗利益=時間単価×(1−原価率)」ということになります。 時間単価が上がると、プロフェッショナルとしての自信につながります。
「法的に難しい」ものに対して「法律を変えよう」という方向に起業家精神が発揮されないのよね、日本。 数年前の法改正でPayPalによる個人間送金ができなくなって「日本ダメだ」と思いました。Winny、まねきTV、医薬品ネット販売規制、ダウンロード違法化など、いろいろあって、ほんの一部の例にすぎない。ダメなことがたくさんありすぎる。 我々の業界団体が政治的に未熟。新経連かどうかはともかく、そういう勢力が必要だと思います。 日本のネット業界は政治的・立法的な振る舞い方が下手すぎて、「ルールブレイカー」たりえてない。「ルールのなかでなんとかしようとする」ような頭しか働いてない。 ルールを壊しにいきましょうよ。もちろんスタートアップには無理だけど、大手ネット企業ならそういうこと考えましょうよ。ネット医薬品販売規制などが典型だけど、これまで防戦一方だよね。攻めようよ。 民間のことだけ考えて「世界を変え
以後 http://ishibashi.tumblr.com/ を購読ください。 (UIデザインにおけるメンタルモデルを考える上で、ちょうどよい練習問題) Android 4.4 KitKatのバッテリー残量インジケーターは、この画面表示で「残り50%」を示しています。そうは見えませんよね?(そう見える人もいるかもしれませんが) 私には、とても50%もあるようには見えません。もっと少なく見えます。なぜでしょうか。ここには「メンタルモデル」と「UI実装モデル」のギャップがあります。 なお、ここでいう「メンタルモデル」は、クリッペンドルフの『意味論的転回』では「ユーザー概念モデル」(UCM: user conceptual model) と呼ばれています。以後そう呼びます。 この練習問題について、自分で考えてみたい人は、一旦ここで読むのをやめて、回答を出してから、続きを読んでください。 ・ ・
オブジェクト指向も、MVC (Model-View-Controller) も、アジャイル開発 (XP: Extreme Programming) も、テスト駆動開発も、Smalltalkから生まれた、っていうことについて、徐々に体得的に実感できつつある。 現代のエンジニアリングの潮流がSmalltalkに由来するということは、そこに何か非常に重要な本質が潜んでいる可能性がある。 また何か書きたい。 とりあえず現時点でほとんど確信しているのは、現代のエンジニアは教養としてSmalltalkをやっとくといい、ということだ。仕事でSmalltalkを書くかどうかは関係なく。 関連情報 Smalltalk入門 (全16回) - プログラミングならドットインストール オブジェクト指向9つの簡単なルール 読解いやな法則: にわかな奴ほど語りたがる PharoCasts: Display Picasa
【これはとてもひねくれた文章なので、「実用的な情報を速やかに収拾したい忙しいビジネス・パーソン」は読まないほうがいい。警告はした】 【役立つ部分をさくっと読みたい方はシンプル版を用意しました】 fladdict氏の『スマホUI考(番外編) 顧客やユーザーの要望に全て対応すると、アプリは99%破綻する』は素晴らしい記事だ。 その記事のコメント欄でのやりとりが気になった。 【某氏】 先生! 設定画面で全てのUI機能要素を ON/OFFしたり、configファイルの編集でボタンのレイアウトを変更できれば良いと思います! 【fladdict氏】 その思想をつきつめると、設定オンオフで音楽プレイヤーからFacebook閲覧までユーザーが自在に切り替えられる万能アプリへの道に進むのです・・・ 【某氏】 やりたいことが何でもできる万能アプリの複雑性と、デフォルト設定のシンプルさは両立しますからね。初めて
第1回SEMATカーネル勉強会に参加しました。 SEMATカーネルとは、SEMATというプロジェクトの核(kernel) SEMATとは、ソフトウェア工学(software engineering)を「再建」しようとする試み 詳細は省略しますので、平鍋氏の『SEMAT.org にて「ソフトウェア工学再建」運動が開始:An Agile Way』という記事や、SEMATの詳細をご覧下さい。 ※ちなみに"SEMAT"の発音は「シーマット」(sea-mat)でいいようです。SEMAT創始者Ivar Jacobsonのスピーチによると。 品質・テストの重視は日本の独自性 さて、第1回SEMATカーネル勉強会の内容については、最後の課題共有ワークショップが面白かった。参加者から提出された課題のなかで、一番多かったのが「個人のスキル」で、二番目が「品質・テスト」でした。 たしか『ソフトウェア企業の競争戦
意外とこういう話を聞かないので、ぼくの理解が間違っているかもしれないという前提で、書いてみますが。 概要 ふつう「CEO」という肩書きは米国型のコーポレート・ガバナンス(企業統治)を示唆します。それと異なる統治形態の企業が「CEO」という肩書きを使うと、受け手に誤解させる可能性があります。 本文 中小企業の社長が「CEO」って名乗ることが増えましたよね。これがいわゆるオーナー企業でワンマン企業だったりすると、けっこう違和感あるんですよ。本来「CEO」は「社長」の英訳ではありませんね。「CEO」という言葉の背後には、コーポレート・ガバナンス上のいろいろなものが示唆されます。 具体的に言うと、外部資本、社長以外の取締役、社外取締役、取締役会の開催などのいずれもが欠けているような会社で、"Chief Executive Officer" って、ちょっと意味が分からないんですよね。 コーポレート・
保存アイコン=フロッピーディスクの時代は終わった…? | MEMOPATCH を見て「保存ボタンとか無くしていこうぜ!」って書こうと思ったらすでに長谷川恭久さんが言及してた: 保存アイコンでみえてくるアイコンデザインの勘違い : could 別の議論で、そもそも「保存」という機能はいらないという意見もあります。私が愛用している Byword も保存という概念がなく、いつの間にか iCloud 経由で同期されているのが好きな点ではあります。しかし、すべての「保存」がこうした自動化がふさわしいのかというそうではありません。バージョン管理のようなコミットというアクションも含めた保存は自動化は適切ではないですし、保存というアクションがあることで利用者が自分で操作をコントロールしているという安心感もあります。 うん、「コミット」の意味論は、人の明示的な操作を要するよね。そういうのは単純な「保存」とは
DCIとDDD DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticismを読んだり、DCI meetup w/ @jcoplien for Rubyistsに参加したりして、DCIアーキテクチャについて考えてきた。 DCIはメッセージパッシング指向だ。そのSmalltalk的なオブジェクト指向の原理はいいけど、実装が嫌だ。 そもそも、DCIアーキテクチャ提唱の目的は、メンタルモデルのセマンティクス・ギャップを埋めることだ。DDDの「ユビキタス言語」も、メンタルモデルのセマンティクス・ギャップを埋めるための要素であり手法だ。だから、ふつうにDDD(ドメイン駆動設計)をやればいいと思った。 DCIへの疑問 DCIでは、「オブジェクトのアイデンティティ」にこだわりすぎていることで、アーキテクチャが複雑になって
一般的に使われる "ID" は "identifier" (識別子)の意味であって、 "identity" (同一性)の意味ではない。ぜんぜん違う。 Conflict システムの実装上、 ID が衝突 (conflict) することはありえる。複数の別々のものに同じ ID を振ってしまう問題を、 ID の「衝突」という。 「本来異なるもの」を「同一である」と誤認することが起こりうる。それは「 ID が衝突した」という事態に気付かずにシステムを運用した場合に生じうる。 (それ以外にも、同定 (identification) のプロセスにおけるミスやバグなどといった理由も考えられるが、本題ではない) Equivalency ID の衝突は、存在 (existence) の「重複」などという意味ではない。そもそも存在は「重複」しない。「同じものが二つ存在する」ということはない。 二つ以上存在して
『社内LAN撲滅運動 - ISO27001(ISMS)認証を取得しました』という素晴らしい報告がありました。 私たちは、社内LANとインターネットとを区別するのではなく、クラウドを利用してネット上に仮想のワークスペースを作り、それを場所を問わず使えるようにするという方針でセキュリティと業務の両立を図りました。 テレワーク化を推進するために、こういう事例を参考にしています。 現時点での懸念は、「IPアドレス制限」という認証方法が使えなくなることです。 補足しますと、ウェブサービス開発をする場合には、 開発環境へのSSH, HTTP(S)アクセス 本番環境の管理画面へのHTTPSアクセス などを固定IPアドレスベースで制限することがあります。例えば「事務所のIPアドレス」で制限することにより、「従業員によるアクセス」であるという認証になっているわけです。 しかし、「事務所のLAN」がなくなると
How to Get Startup Ideas by Paul Graham Y Combinatorのポール・グレアムが素晴らしいエッセイを書きました。そのエッセイを読んだときのメモです。(そういえば起業家っぽい記事は久しぶりかも) Important The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself. The very best startup ideas tend to have three things in common: they're something the founders themselves want, that they themselves c
これから述べる分散オブジェクト・アーキテクチャに近いフレームワークやアプリケーションの実装がすでにあれば教えて頂けると助かります。 背景:ゼロベースの管理会計システムを開発するよ。 (凡例:追記と削除) 目的 ドメイン駆動設計(DDD)を原理的に突き詰めたアーキテクチャによって、オブジェクト指向プログラミングの作業から、インフラストラクチャ層に関する配慮がほとんど不要になる。SQLもデータスキーマ設計も不要になる。 といっても、Ruby on RailsのActiveRecord的な話ではないので、誤解なきよう。むしろ正反対。リレーショナル・データベースを使わない。 ドメインのオブジェクトをシンプルに書けばシステムが実現するようになる。一言で言えば、「GOOS/DDD原理主義者のためのフレームワークが欲しい」という話。 ウェブ・アプリケーションの三層アーキテクチャ再考 ウェブ・アプリケーシ
『分散オブジェクト・アーキテクチャ/ドメイン指向アーキテクチャ』について考えるなかで、「永続化」への理解が深まった。というか、このアイデアについて人と話してもかみ合わない理由が分かった。とどのつまり、ぼくが独特な感覚を持つマイノリティだったのだ。 たぶん、ふつうのプログラマから見れば、おそろしくどうでもいいことにこだわっている、ように見えるだろう。 信仰告白 ぼくは現在主流の「データベースを使った永続化」が大嫌いだったんだ。ORMとか一体何なんだ。知らんわな。なんでプログラムを書くのにSQLを書かなきゃならんのだ。(※個人的な感じ方の問題です) 「RDBからSQLでデータをとってきてHTMLで整形して出力するPHPプログラミング」なんて二度とごめんだ。データベースのために働いてるみたいじゃないか。(※個人的な感じ方の問題です) 「データベースを使った永続化」が行き過ぎると「データベース中心
今年はプログラミングに再入門してます。 もはや若くないので、自分の「頭の悪さ」を受け入れて、それでも読み書きできるコードを模索してます。 ここでいう「頭の悪さ」とは、「大きなクラスや長いメソッドを理解できない」という脳のスペック的な意味です。 ぼくは二十代の頃と比べて頭が悪くなってしまったので、DDD(ドメイン駆動設計)、TDD(テスト駆動開発)、DCI(データ・コンテキスト・インタラクション)といったソフトウェア工学の成果に興味を持ってます。 抽象度の高いドメインモデリングとかプログラミングって、一見頭がよさそうに見えるかもしれませんが、むしろ(上記の意味で)「頭が悪い」人にこそ必要なんです。 頭が良かったら、もっとCPUに寄り添った高速なコードをすらすら書けるわけです。 頭が悪かったら、人間のメンタルモデルに寄り添った読みやすいコードを書くしかないわけです。 だから、一見高度で抽象的で
このページを最初にブックマークしてみませんか?
『石橋秀仁(zerobase)書き散らす』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く