steps to phantasien t(2007-02-18) 最近読んだ本: The Apache Module Book
現実逃避で少し Apache のソースを読んでいた. その資料探しにぐぐっていて発見. なかなかよく書けていた. 満足. (表紙のぞく.) 500 ページくらいあって身構えるけど, なぜか巻末に HTTPの RFC やら ASF ライセンスやらが付いていて 150 ページくらい水増しされていた. 実際は 350 ページくらい. コードも多く, 手軽に読める. まず Apache のアーキテクチャを概観し, APR, モジュール基本, コンテンツ生成, ヘッダ書き換え, 認証, フィルタ, 設定, デバッグ技法...とつづく. 新しい本だけあって Apache 2.2 の話題もある. けっこう網羅的な気がする. (気のせいかも知れない. 網羅されてない話があってもわからないし...) 実のところモジュール用にどんな API があるかはソースを持ってきて ヘッダや実際のモジュールを眺めればだい
steps to phantasien t(2007-01-03) いつもの派閥争いの話
去年の未読 feed を消化していたら, XML vs JSON という話がぞろぞろ出てきた. 火事と喧嘩は XML の華. 最近ちょっとおとなしかったけれど, たまにはこういうのがないと寂しいよね. 火元は JSON の親玉である Douglas Crockford が XML2007 で行った講演 "JSON, The Fat-Free Alternative to XML" らしい (スライドの ppt) . XML 愛好家の集りで XML でないフォーマットの話をするとは豪胆だ. しかも暗に "おまいらおでぶちゃんとは違うんだぜ" と煽っているわけだから, XML ファンが刺激されるのも仕方ない. まとめ記事によると, 反撃の狼煙を上げたのは Scripting News らしい. でも読んでみるとあんまし JSON をわかってない節がある. 本人も自覚があるのか, 議論をうながし
ソーシャルブックマークの未来は受動型？ 自動型？ － ＠IT
2007/08/22 お気に入りのWebページを複数ユーザー間で共有、コメントするソーシャルブックマークが次の段階に移ろうとしている。はてなやライブドアなど既存のソーシャルブックマークは、それぞれのポータルサイトなど特定のページにアクセスして、人気ブックマークを閲覧し、興味を持ったWebサイトにアクセスする使い方が一般的。ソーシャルブックマークの登録も含めて、ユーザーの能動的な行動が欠かせなかった。しかし、「知の共有」というソーシャルブックマークのメリットを受動的に得られるサービスが登場した。 「能動的なメディアではなく、ページが上から降ってくるような受動的なメディアを作りたかった」。Firefoxのサイドバー上でソーシャルブックマークを利用できるようにするプラグイン「swimmie」を発表したCurioの取締役兼CTO 大澤昇平氏は、swimmieをこう説明する。swimmieはWebブ
HTML勉強会で何を教えるべき? (2007-08-08)
ということで今週は勉強会週間ということで、前々からネタとして上がっていた「HTMLと私」を話すことになった。さすがにそれはきついので、とりあえず普通のHTML勉強会を開いた。 さて、HTML勉強会では何から教えるべきなのだろうか。すみけんさんの本みたいに「ももたろう」のマークアップをしながら必要な要素について解説していくのがよいだろうか。それともHTMLの要素群を<html>から順番に解説していくのがよいだろうか。そもそも教えるべきはHTML3.2なのかHTML4.01なのかXHTML1.0なのかXHTML1.1なのか、はたまたISO-HTMLなのか。HTML4.01やXHTML1.0だとしたらTransitionalな要素や属性に触れるべきか―― みんなに何が知りたいか訊いて、あと後輩が書いたHTMLを見て思ったこともあったので、とりあえず文法から話すことにした。件のHTMLはliがbo
マークアップエンジニアが次に取り組むべき5つのテーマ。 | Junnama Online
マークアップエンジニアが次に取り組むべき5つのテーマ。 公開日 : 2007-08-09 16:32:32 性懲りも無くまた書くとする。このエントリーは「マークアップエンジニア」に向けて書く。 * 前回何故あんな書き方をしたかというと、やっぱり書き方が見下してるというか、嫌〜な匂いがしたからだ。で、案の定そのノリで反応来るしなぁ。ちなみに僕はマークアップエンジニアではなく最近はPerlばっかり触っているスーツです。 次にやるべきは何か。結局はあなたが何者になりたいか次第だけど、あなたの周りにも左右されるだろう。それは決して (このブログも含めて) ブロゴスフィアの世論? ではなくて例えばあなたの (今の、そしてこれからの) 属している業界とか会社とかあなたの仕事仲間とかのことね。 だからこれは僕の会社や僕が属している業界の場合の話と予めお断りしておく。 また表現者になりたいのか、ビジネスと
fladdict.net blog: FlexとかFlashとかの話
nytoyonさんと、secondlifeさんのエントリ見て雑感。 Flexは「現在は」広告とかプロモーションで戦力外ですが、まったくできないかというと、そんなこともないと思うのです。 モデルやコントローラー等のややこしい部分はFlexフレームワークを使ってViewだけFlashで乗っ取れないか、的な実験もちょっとやってみたことあります。例えば、VOO-DOO-DOLLSのスクリーンセーバーなんかはMXMLプロジェクトでもろFlexコンポーネント上で作られていますし。 問題はインタラクティブなコンテンツを扱う人間にとって、FlexフレームワークとAS3は学習コスト高すぎる。という点ことなんですよね。きっと。 プロモサイト的なモノならば、FlexなんかよりもFlashで何倍も素敵なもの作れますし。 逆にアプリ系ならやっぱりFlex2がいいと思いますよ。得にユーザーの管理画面や、投稿画面。 投
Re: んー （スーツの国の Flex その2） - てっく煮ブログ
Re: んー （スーツの国の Flex その2） flex 昨日のエントリ に g:subtech:id:secondlife さんに つっこんでもらった のでお返事。 社内うんちゃらのツールを作るなら Ajax でいいんじゃね？ できる人が社内にいて、全部内製でやっちゃうような会社だと、ノウハウも溜まってて、フレームワークも選り取りみどりな Ajax の方が早いでしょうね。 けど、間に SIer が挟まって、下請け孫受けなんかの仕事だと、Ajax とか Perl のような揺らぎがでる言語よりも、Java とか PHP のようながっつりしたもののほうが好まれる。そこに Flex がはまりそうだなぁ、と思ってるわけです。 スタープレーヤーが勢いで作ってメンテナンスし続けていく場合と、納期があって仕様書があって複数人で作っていく場合で、ずいぶん手法も変わってくるんじゃないかと。まさにギークとス
スーツの国の Flex - てっく煮ブログ
flexFlex についてみんな誤解してるんじゃないだろうか、と思ったので考えをまとめてみた。Flex というのは ActionScript 用のフレームワークで、MXML という XML で見た目を記述したり、ActionScript だけでは実現が大変な DataGrid などの便利なコンポーネントが利用できたりする。デザイナーが Flash 8 などで作っていた SWF だけども、Flex を使えば RIA な SWF を簡単に開発できるようになる。Flex は裏世界で使われるその Flex について、不満のような意見が聞こえてきている。 Flex が天下を取って Flex の GUI を使いこなせれば引く手あまた、なんて状況はみじんも感じられなくて、(中略)軽く表面上のレイアウトだけ使うこともでき、プロトタイプ作りには良いけど、ねぇ。AS3/Flex2 を使い始めて約半年 - 8時
Ruby2.0からオレ様言語まで、軽量言語のお祭りが開催 － ＠IT
2007/08/07 日本初のハッカーとされる和田氏の講演（レポートその1）で幕を開けた軽量プログラミング言語の恒例イベント、「Lightweight Language Spirit」（LL魂）。レポート第2弾以降は各セッションからハイライトをお伝えする。すでに前編に書いたように、軽量プログラミング言語の最新情報や実用情報が目白押し、というイベントではなく、ギークなネタやジョークが満載の、いかに会場を沸かせるかを競うかのようなイベントだった。 Io、Clean、R言語、Luaのマイナー言語関連の発表 最初のセッションは、Perl、Io、Clean、PHP、R言語、Python、Lua、Rubyの各言語の最新情報をまとめて報告する「Language Update」。Io、Clean、R言語、Luaなどマイナーな言語に関しては、近況報告というよりも、言語の概要と特徴を紹介するという感じだ。 I
「なぜ作ったのか？」、オレ様言語作った人々 ― ＠IT
2007/08/07 軽量プログラミング言語の恒例イベント、「Lightweight Language Spirit」（LL魂）。レポート第3弾は、自らプログラミング言語を開発している人々によるセッション「オレ様言語の作り方」の模様をお伝えする。日本語で書けるプログラミング言語を開発した人、高校で教師生活を送る傍ら独自言語開発を楽しむ人など、それぞれの立場で「オレ様言語」に対する熱い思いを語った。 日本語でプログラムできる言語「なでしこ」 「その当時好きだった女の子にひとこと、プログラミング言語を作ると言ったことが原因で作ることになった」。独自プログラミング言語「なでしこ」を作り始めたきっかけを冗談交じりにそう語るのは、酒徳峰章（クジラ飛行机）氏だ。事務処理の自動化を目的に、日本語によるプログラミングを可能にしたなでしこは、きわめてユニークな存在だ。文法はシンプルで難しい概念も出てこないが
Flash|Ajaxベストサイトセレクション20 -つくるぶ 特集
2007年8月20日 動画再生や音声再生がもともと得意で、インタラクティブなWebサイトを作ることができるFlashと、非同期通信を利用してWebサイトのユーザビリティを一躍向上させたAjax。Flash、Ajaxで一長一短はありますが、それぞれの特徴、良さを改めて理解するためにFlash、Ajaxならではというサイトをたくさん並べて見ることにしました。サイトのセレクションは、Flashを得意とする木村さん、寺井さん、Ajaxを得意とする竹村さん、川崎さんにお願いしました。
マークアップエンジニアのキャリアパス
マークアップエンジニアはどこへ向かうべきかを読んで。 僕らがやってる多くの仕事って、「生産技術」の範疇だったりするんですよね。 で、とりあえず気になったところ、and 感想。 ・技術がわかるかわからないかというより、如何に早く、正確にできるかできないかってのは職能として重要。 ・仕様書の理解が難しいということを除けば、仕様が決まってることに対しての仕事なんだよね。 ・でも、そういうのって野球も同じだったりして。野球もルールという制約の中で、如何にパフォーマンスを発揮するか？という仕事ですよね。 ・ただ野球と同じで、後発の人が追いつくのは割と簡単だというのなら、長くはできない仕事なのかもしれない。（同じ仕事ができて、しかも体力勝負なら若い方が重宝される。） とりあえず間違ってると思うこと。 ・マークアップエンジニアのキャリアパスはプログラマーでもビジュアルデザイナーでもない、と思う。 （必然
なぜ、日本人のプレゼン資料が海外に伝わらないのか？：永井経営塾：オルタナティブ・ブログ
加藤さんのきょこコーリングのエントリー「アメリカ人に通じるプレゼンを作るために」で書かれていた 「アメリカにいる上司を説得しなければならないときに、「英語力を上げよう」として英会話に通ったり、ビジネス英文の書き方の本を読むのではなく、MBA関連の本を読むとのこと。」 という箇所を読み、非常に納得できましたので、ちょっと考えてみました。 日本人が作るプレゼン資料が、なかなか海外の人に伝わらないということは、海外とコミュニケーションをなさっている方であれば、経験なさっていることと思います。 欧米社会だけでなく、アジア社会でも結構起こっているように思います。 欧米型のプレゼン資料（又は製品資料やお客様事例等)というと、こんな感じではないでしょうか？ 文章をズラズラ書く。絵はない 我々からすると、当たり障りのない文章。当たり前の結論 でも、何故かこれでちゃんと意思が伝わるし、相手も動く 一方で、日
マークアップエンジニアはどこへ向かうべきか（を考えてたらカッとなって LL の資料公開） - IT戦記
はじめに このエントリはマークアップエンジニアに対する批判ではありません。不快な想いをした方がいましたら、申し訳ありません。 きっかけ ライブドア & サイボウズラボの数人でお昼ご飯を食べにいって、いろいろ話しながら考えたことを昼食後に Twitter に書き込みました。 濃い昼飯だた、(X)HTML+CSS しか出来ない人は真剣に第二の何かを探したほうがいいと思た。(X)HTML+CSS ではもうこれ以上すごいと呼ばれる人なんて増えないと思う。 http://twitter.com/amachang/statuses/191256222 「CSS 道」は道が短すぎるんだ。マーケティングの為に長く見せてるけど、実際覚えることは少ない。「デザイン」か「JavaScript」を職業に出来るくらいにしとかないとヤバいと思う。 http://twitter.com/amachang/statuse
デスクトップアプリケーションは死んだ - Kentaro Kuribayashi's blog
"Ev's Rants: Desktop Applications are Dead"が面白かったので、翻訳してみた。というか、「超訳」だが。 原著者: Eugueny Kontsevoy 超訳者: kentaro a.k.a. id:antipop 原文のURL: http://kontsevoy.blogspot.com/2007/08/desktop-applications-are-dead.html いまさらその話かよ、って？そんなこといっても、「デスクトップアプリケーションは死んだ！」とか、いまもみんなそこらを叫んで回ってんじゃん。 その連中の多くは、いわゆる「ウェブアプリケーション」の開発者どもだ。誰があんな連中のいうことを聞くんだ？やつらは本物の開発者なんかじゃない。だよね？全然ものがわかってないし。あいつらときたら、malloc()やfree()すらまともに使えないんだか
OOエンジニアの輪！ ～ 第 38 回 笹田 耕一さんの巻 ～ | オブジェクトの広場
現在のお仕事について ---最初に、今どういうお仕事をやっておられるか、お話していただけますか？ 東京大学大学院の情報理工学系研究科創造情報学専攻で特任助教をしています。ここ、情報理工学系研究科秋葉原拠点は、創造情報学という最近できた専攻のラボになっているんですが、主にここに常駐しています。 そこで具体的に何をしているかといいますと、文科省の「先導的 IT スペシャリスト育成推進プログラム」というプロジェクトに従事しています。産業界から「きちんとわかる IT 技術者が少ないので大学もなんとかしてくれ」という要請があったらしく、文科省の公募により、数拠点が選ばれました。 で、東大と東工大と NII（国立情報学研究所）の 3 つの研究機関が協力してそのうちのひとつ「情報理工実践プログラム」を行っているんですが、私はそこに雇われている、というわけです。 この拠点では、実際にソフトウェアを作ること
ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人生は時間（時間を何倍にも増やす５２チップス） - EC studio 社長ブログ
http://stack-style.org/2007-08-16-03.html
IBM 軽量 Web サーバー - Japan
