nilog: RFC 3092 Etymology of "Foo" 「Foo」の語源。ん？ "1 April 2001" って書いてある。もしかして。。。 (2016-06-01)

← 前の日	2016-06-01	次の日 →
← 一年前		一年後 →

Twitter (2016-06-01)
RFC 3092 Etymology of "Foo" 「Foo」の語源。ん？ "1 April 2001" って書いてある。もしかして。。。 https://www.ietf.org/rfc/rfc3092.txt https://www.ietf.org/rfc/rfc3092.txt [t] 2016-06-01 21:11:58

関連するかも情報
【話題急上昇中ワード】 1. 伽椰子 2. 新しい判断 3. 佐野ひなこ 4. 清霜 5. 笑ってこらえて 6. 渡辺麻友 7. 安倍首相会見 8. オキシトシン 9. 新宿ピカデリー http://searchranking.yahoo.co.jp/realtime_buzz/ #buzzbot [t] 2016-06-01 21:10:05
RFC 3092 Etymology of "Foo" 「Foo」の語源。ん？ "1 April 2001" って書いてある。もしかして。。。 https://www.ietf.org/rfc/rfc3092.txt https://www.ietf.org/rfc/rfc3092.txt [t] 2016-06-01 21:11:58
「1989(平成元)年から2005(平成17)年まで連続17年間、エイプリルフールに公開されていたが、2006(平成18)年には発行されず、連続記録は途絶えた」ジョークRFC ‐ 通信用語の基礎知識 http://www.wdic.org/w/WDIC/%E3%82%B8%E3%83%A7%E3%83%BC%E3%82%AFRFC [t] 2016-06-01 21:12:57
Chrome でページ内をひらがなの「あ」で検索したらカタカナの「ア」がヒットした。そういうもんなの。。。 [t] 2016-06-01 21:33:41
「型のチェックには、この関数ではなく is_* 関数を使います」 PHP: gettype - Manual http://php.net/manual/ja/function.gettype.php [t] 2016-06-01 21:46:48
PHP で試してみる。 [ヅ] PHP の $_GET で取得した値を見る (2016-06-01) http://www.nilab.info/z3/20160601_01_php_get.html [t] 2016-06-01 21:59:57
【話題急上昇中ワード】 1. 伽椰子 2. 新しい判断 3. 新宿ピカデリー 4. 100位 5. 笑ってこらえて 6. オキシトシン 7. 完封負け 8. 米山 9. イラン http://searchranking.yahoo.co.jp/realtime_buzz/ #buzzbot [t] 2016-06-01 22:10:05
RT @manabuueno: 「うちのシステムも iPhone のようにマニュアル読まなくても簡単に使えるようにしたい。」と要望される。iPhone と業務システムでは用途が違うしそもそも OS とアプリケーションだし比べるのもおかしいが、どうやら iPhone はマニュアルがなくても使えるという認識らしい。 [t] 2016-06-01 22:45:49
RT @manabuueno: 実際 iPhone でもある程度の前提知識がないとそれほどうまくは使えないということを私は知っているが、学習効率がよいので人はそのことを忘れてしまうのだろう。 [t] 2016-06-01 22:45:52
RT @manabuueno: マニュアルを読まなくても使えるようにしろと言う人の多くが意味するのは、手順を覚えやすくしろということだ。タスクが単純であれば丁寧なガイダンスがついたウィザードをつくればよい。しかし多くの場合、タスクはそれほど単純ではない。 [t] 2016-06-01 22:45:58
RT @manabuueno: iPhone の学習効率が高いのはひとえに直接操作感を重視したイディオム設計にあるということも私は知っている。つまりモードレスであることが大きなファクターになる。 [t] 2016-06-01 22:46:02
RT @manabuueno: iPhone に対してユーザーが「マニュアルを読まなくても使える」と感じるのなら、その使いやすさとは、手順が覚えやすいのではなく、そもそも決まった手順が無いということなのだ。 [t] 2016-06-01 22:46:08
RT @manabuueno: 手順が決まっていない。ユーザーは好きな方法で目的に向かっていける。これが GUI の根本であるモードレスネスだ。しかしこのコンセプトはシステムの企画者や設計者の間でほとんど理解されていない。 [t] 2016-06-01 22:46:12
RT @manabuueno: これまでコンサルで様々なシステムを見てきた。世の業務アプリの8割はタスクベースのUIストラクチャになっていて、それをオブジェクトベースに変えるだけで劇的に改善できる。これは銀の弾丸と言っていいほど汎用的で強力なノウハウだ。 [t] 2016-06-01 22:46:31
RT @manabuueno: ここでいう改善とは、操作効率、学習効率、業務効率、UI拡張性などの向上。画面数の削減（5〜10分の1に）による開発工数の低減など。それなのにほとんどのユーザー部門、情シス部門、SIer はまずこのUIストラクチャを発想することができない。 [t] 2016-06-01 22:46:40
RT @manabuueno: なぜならほとんどの開発メソッドでは上流工程で業務分析やワークフロー分析を十分行うことを重要視しており、その結果タスクの羅列こそがUIストラクチャであると短絡的に捉えられてきたからだ。システムに対してユーザーは何かを明確に要求しているという前提で、開発者はそれを特定しようとした。 [t] 2016-06-01 22:46:48
RT @manabuueno: デザイナーがUCDだなんだと言い出すずっと前からシステム開発の上流ではユーザーコンテクストの特定に躍起になっていたわけで、観察やインタビューといったものはすでによく行われていた。ユーザーに最初に着目したのは開発者であり、数々のアンチパターンが厳しいクリティシズムを発生させていた。 [t] 2016-06-01 22:46:54
RT @manabuueno: ビジネスアプリの設計においてタスクが偏重されてきたのは、それが、電話や紙を用いて行われていた業務をスクリーンにそのまま置き換えるという初期動機によるものだ。しかし世の常として、道具はまず仕事に合わせて作られるが、やがて進化した道具によって今度は仕事が変化するのだ。 [t] 2016-06-01 22:46:57
RT @manabuueno: オブジェクトベースのUIストラクチャでは、ユーザーはタスクを選ぶのではなくエンティティ選ぶ。エンティティはインスタンスのマスター＆ディテールを持ち、それらは目的に合わせた表示形式とアクションを持つ。ユーザーは業務という概念ではなく情報オブジェクトに直接向き合うことになる。 [t] 2016-06-01 22:47:03
RT @manabuueno: 事業体において、エンティティ（主要な概念単位）は変化しにくいが、業務（タスク）は変化しやすい。だからタスクベースのUIストラクチャは複雑化しやすく破綻する。オブジェクトベースならきれいに拡張できる。ビューとそこに付随するアクションを増やすだけでよいから。 [t] 2016-06-01 22:47:05

2016年06年01日のnilogをすべて表示する