01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
http://yohei-y.blogspot.com/2005/04/rest_23.html
REST と Ajax、JavaScript は仲が悪いのかも?、
と思ったこともあったけど、意外とそうじゃない気もしている。
REST はあくまでネットワークアーキテクチャで、
UI じゃないんだよね。
再利用性を高めるためには、やっぱり REST という
デファクトスタンダードは考慮する必要があると思うですよ。
過去の日記)
REST なんてどうでも良いかも、と思った日記 --> [2005-09-16-1]
REST についてのまとめ --> [2005-09-14-7]
http://dkiroku.com/2005-11-10-14.html
たしかに無駄にすげーぜ。
途中で読むの飽きちゃったよ。弱い。
http://takekuma.cocolog-nifty.com/blog/2005/11/post_8c84.html
プロとアマチュアの一番の違いは技術じゃなくて
- お金を取るための販路(流通経路)を持っているか
ということだったりする。
お金を取るに値するだけの何かを持っているかは
必要条件だけど十分条件じゃない。
ちゃんとした流通経路を持ってる、というのが
プロのプロたる特権だったと思う。
でもインターネットの出現により販路が簡単に構築できるように
なってきたわけで、これからどんどん面白くなるよなあ、
というのが正直な実感。
プロとしては、アマチュアの流通への参入がどんどん進むのは、
脅威だと思うけど、実はマーケットが増える、
というメリットのほうが大きいんだよね。
プロがアマチュアを育てる、その上で、プロの高い技術を見せる、
というのは芸事なんかの世界ではあたり前なわけで、
そういう、客を育てる、という視点は、今後どの領域でも
重要になってくるんだろうな。
参入障壁を高くしたり、既得権益を守る、というやり方は、
時代の空気的には流行らないと思うしね。
まあプロにとってはキツい世の中になっていくのかもしれないけど、
プロが大変、というのは多分健全ではある。
まあそういう話はともかく、「惑星大怪獣ネガドン」見たいねえ。
惑星大怪獣ネガドン
http://ameblo.jp/ki6ra/entry-10005963914.html
女性は Yahoo、男性は Google らしい。
http://seki.webmasters.gr.jp/tdiary/20051110.html#p01
はさみ将棋は双方が最善を尽くすと引き分けになっちゃう。
でもなにか1つルールを加えてやるとそれなりに面白いゲームに
なるんじゃないか、という気がする。
はさみ将棋 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%81%AF%E3%81%95%E3%81%BF%E5%B0%86%E6%A3%8B
たとえば Mak-yek みたいに相手の駒の間に割り込むと、
両側の2枚を取れる、とか。
はさみ将棋と Mek-yek
http://seki.webmasters.gr.jp/tdiary/20051024.html#p01
拡張ルールをちょっと考えてみた。
頭の体操体操。
- 駒の間に割りこむと両側の2枚を取れる
- 1回だけ相手の駒を自由に除去できる
- 3回まで一度に2回動かせる権利がある
- 盤面の端と端が繋がっているとみなす
- 膠着状態になったときは面積勝負にする
- サイコロを振った数だけ駒を動かすことができる
面白いかどうかはやってみないとわかんない。
http://www.atmarkit.co.jp/farc/rensai2/proto01/proto01a.html
上流工程っていうのは
- 要件定義
- 基本設計
なんかを指すのが普通。まあ一般的には。
その上流工程の前段階には、
- なんのためにシステムを入れるか
ということに関する議論は必須。
これをちゃんと議論しないでシステムを作っちゃう、
というのはありがちな悲劇の元。
要はユーザの気持ちを理解しなきゃ駄目よ、と。
その議論のためには、システムを導入したいユーザの商売、
つまり
- どういう業務を
- 誰が
- どんなふうにやっていて、
- お金をどう使って
- お金をどう回収してるか
というようなことを、予備知識として、
きちんと理解しとく必要がある。
業務知識がある SE が欲しい、と言うのは、
この辺の知識がある、ということよね。
ただ業務知識というものは、実際に業務に携わらないと、
ちゃんとは身につかないもので、
システムだけ作ってて身につくものじゃないのよ。
なのでシステムを作る方で業務知識がある人を
揃えられるか、というとなかなか難しい。
でもユーザ側は、システムを作る側に、
業務知識は当然ある、ということを要求しがち。
お金だけ出せばシステムができてハッピーになるぞ、
と思ってるわけだ。
その辺もありがちな悲劇の元。
アジャイル的なアプローチが絶対っていうわけじゃないとは思うけど、
少なくともアジャイル的なアプローチでは、
- 顧客がやりたいことを、顧客と開発者で明確化し共有できる
というメリットはあるのは確か。
アジャイルの考え方や理念は、従来型の開発にも応用ができるので、
上流工程の人こそアジャイルの勉強をして欲しいなあ、と思うね。
http://slashdot.jp/linux/article.pl?sid=05/11/10/0950212
問題提起の原文は以下。
Problems with the IETF's copying permissions
http://josefsson.org/bcp78broken/
ここで以下の問題提起がされている。
- No Rights To Adapt Parts Of Contributions
- No Rights Are Granted To Third Parties
RFC3978、RFC2026 を斜め読みした感じだと、
たしかに Rights にうるさくなってるみたいだ。
http://rfc.net/rfc3978.html
http://rfc.net/rfc2026.html
なんで Rights にうるさくなってるのか、という背景が知りたい。
やっぱりガバナンス絡みなのかなあ。
余談)
RFC を調べるには以下が便利。
http://rfc.net/
最新の STD、BCP、FYI 等をまとめて読める。
STD : standard - 標準プロトコル
BCP : Best Current Practices - プロトコルの使い方、設定方法等
FYI : For Your Information - インターネットに関する有用な情報
IETF をちゃんと追いかけていないけど、たまに RFC を見る必要がある
人にとっては、こういうまとめページはむちゃくちゃ助かる。
余談2)
こういうページにも PayPal DONATE が貼ってある。
有用なページでお金を稼ぐにはアサマシじゃなくて
寄付という選択肢もあるのう。
2021 : 01 02 03 04 05 06 07 08 09 10 11 12
2020 : 01 02 03 04 05 06 07 08 09 10 11 12
2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
最終更新時間: 2021-03-02 14:20