  |
はてなキーワード: xmlとは
Google Baseってどんなんだっけと思って検索して見たけど情報少ないなぁ。
前に名前くらいは聞いた気がしたけどその時もよく分からなかったし、現時点でもベータだったり日本語対応してなさそうな雰囲気だったり。
実際に触ってみてもGoogleが検索用に使うDBって感じで、何か別のDBを構築するのには向いてるのかどうか、そういう機能があるのかもしれないけどそこまで確認して無いです、すまん。
もしかしたら使えるような機能があるのかもしれないんで、また調べて良さそうだったら使うかも、情報サンクス。
Googleサービス内で他にカレンダーとかも使いようによっては可能かな。
局別にカレンダー作って(ひとつにしても大丈夫かも)番組と各スポンサーを載せていくとか、wikiみたいに書き込み無制限には出来ないけど編集権限も追加していけるし。
だけどアカウント持ってない人とか見れなかったりするだろうし、Ajaxって気持ち重くてちょっと敬遠してしまってるんだよなぁ、物凄く主観な意見だけども。
自前でDB用意しないと不安な性分なのでなんだかなぁというのが本音だったり、XMLか何かで吐いてくれるなら外部から使いようもあるんだけど。
なければwikiか自前でそれっぽいCMS用意するなりで、その前に使えそうなサービスあるかどうかもうちょっとちゃんと調べてみる必要ありそうですね。
LiveDoor認証がでたらしいので、とりあえず寝際にちゃちゃっと書こうとしたのだけどなんかうまくいかない。
「ログインURLの有効期限が切れています」とかでちゃうんだ。
なにか間違ってるかな？
<?php // LiveDoor認証に必要なリンクの生成 // 定数がクラス内に切ってあるので環境にあわせ変更してください include_once('authlivedoor.class.php'); // Livedoor認証用クラス $obj_auth = new AuthLiveDoor(LIVEDOOR_APIKEY, LIVEDOOR_SECRET); $livedoorloginurl = $obj_auth->getLoginUrl(); ?> <div style="border:solid 1px #666666;"> <a href="<?= $livedoorloginurl ?>">ライブドア認証を利用してログインする<br /> <img src="http://auth.livedoor.com/img/cmn/head_livedoor.gif" border="0"> <img src="http://auth.livedoor.com/img/cmn/head_logo.gif" border="0"> </a><br />
<?php // this code is writen by utf-8 & lf //http://auth.livedoor.com/login/?app_key=<app_key>&perms=<perms>&t=<time>&v=1.0&userdata=<userdata>&sig=<sig> // LiveDoor外部認証APIを利用する // キーは各開発者ごとに取得が必要です。 http://auth.livedoor.com/ ここより取得できます。 // コールバックURLには authlivedoor.php を指定してください // --- 下記宣言を環境に合わせて変更してください。 --- define("LIVEDOOR_APIKEY" ,""); // アプリケーションキー define("LIVEDOOR_SECRET" ,""); // LiveDoor認証秘密キー // --- ここまで --- class AuthLiveDoor { const LIVEDOOR_AUTH_PORT = 80; // ポート const LIVEDOOR_AUTH_TIMEOUT = 10; // タイムアウト const LIVEDOOR_AUTH_VERSION = '1.0'; // 認証APIのプロトコルバージョン const LIVEDOOR_AUTH_PERMS = 'id'; // 認証APIのアクセス権 const LIVEDOOR_AUTH_FORMAT = 'xml'; // 認証APIの取得フォーマット const LIVEDOOR_AUTHURL = "auth.livedoor.com"; // LiveDoor認証URL private $login_state = false; private $login_id = ""; private $err_msg = ""; private $apikey = ""; private $secret = ""; public function __construct($apikey, $secret) { $this->apikey = $apikey; $this->secret = $secret; } // // $cert = $_GET['token']; public function getAuth($token) { if ($token == "" ) { return; } $api_time = date('U'); // エポック秒で $param_ary = array($this->apikey ,AuthLiveDoor::LIVEDOOR_AUTH_FORMAT ,$token ,api_time ,AuthLiveDoor::LIVEDOOR_AUTH_VERSION ); sort($param_ary); $api_sig = hash_hmac('sha1',implode('',$param_ary),$this->secret); $param = "app_key=".$this->apikey ."&format=".AuthLiveDoor::LIVEDOOR_AUTH_FORMAT ."&token=".$token ."&t=".$api_time ."&v=".AuthLiveDoor::LIVEDOOR_AUTH_VERSION ."&sig=".$api_sig; $fp = fsockopen(AuthLiveDoor::LIVEDOOR_AUTHURL , AuthLiveDoor::LIVEDOOR_AUTH_PORT , $errno , $errstr , AuthLiveDoor::LIVEDOOR_AUTH_TIMEOUT); if (!$fp) { $this->err_msg = "$errstr ($errno)<br />\n"; } else { $out = "POST /rpc/auth?$param HTTP/1.1\r\n"; $out .= "Host: auth.livedoor.com\r\n"; $out .= "Connection: Close\r\n\r\n"; fwrite($fp, $out); $ret = ""; while (!feof($fp)) { $ret .= fgets($fp, 2048); } fclose($fp); } // LiveDoorの認証XMLのパターン $pattern = '/(\s*<livedoor_id>)(.*)(<\/livedoor_id>)/'; preg_match_all($pattern,$ret,$getAry); $livedooruserid = $getAry[2][0]; // ユーザーIDを取得できた場合 if ($livedooruserid != "") { // ログイン成功 $this->login_state = true; $this->login_id = $livedooruserid; return ture; } } public function getLoginState(){ return $this->login_state; } public function getLoginId(){ return $this->login_id; } public function getLoginUrl() { # http://auth.livedoor.com/guide/ # http://auth.livedoor.com/login/?app_key=<app_key>&perms=<perms>&t=<time>&v=1.0&userdata=<userdata>&sig=<sig> # app_key 必須 登録時に発行されたアプリケーションキー # perms 必須 要求するアクセス権、現状userhashとidの2種類がある # t 必須 URLが生成された時間をエポック秒で表したもの # v 必須 プロトコルバージョン、現在は1.0で固定 # userdata 任意 コールバックURLに引き継ぎたい値を255バイトまで自由に設定できる # sig 必須 このURLの正当性を確認するためのシグネチャ // ログインURLの有効期限が切れています // ヾ（。ｏ、゜)ノ ここらへんがわからん！！ // $api_time = time()+32400; // エポック秒で $api_time = date('U')+32400; // エポック秒で // $api_time = date('U'); // エポック秒？？もしかして、それはポエティック病ではありませんか？ $param_ary = array($this->apikey ,AuthLiveDoor::LIVEDOOR_AUTH_PERMS ,api_time ,AuthLiveDoor::LIVEDOOR_AUTH_VERSION // ,data ); sort($param_ary); $api_sig = hash_hmac('sha1',implode('',$param_ary),$this->secret); $loginurl = "http://auth.livedoor.com/login/" ."?app_key=".$this->apikey ."&perms=".AuthLiveDoor::LIVEDOOR_AUTH_PERMS ."&t=".$api_time ."&v=".AuthLiveDoor::LIVEDOOR_AUTH_VERSION // ."&userdata=" ."&sig=".$api_sig; return $loginurl; } }
もう疲れたので寝る。ライブドアなんてーーーー！！！
訂正。
秘密キーとか、そのままのっけちゃった (ーωー|||)
そしてなかなか訂正できなくてあせった。。
http://anond.hatelabo.jp/20070411180408の人へ
Javascriptの言語仕様を読めば、語句があって構文があって構造化やらオブジェクトやら関数やらなんやらの作り方がわかる。
私もそれについては何の問題もなかった。少々、特徴はあるけれど、さほど困惑するほどのものではなかった。
ただ、それから先で、はたと困惑するんだよね。やりたいことをどう作っていけば良いのかわからない。それ、よくわかる。
Javascript(正確にはちょっと違うのだけれど)の特異な点は、こちらがJavascriptの枠組みで何か設計する前に、すでに互いに関連しあったインスタンスがある、または他の枠組み(HTMLやらXMLやら)でインスタンスを生成したあと、Javascriptで操作する、って所なんだ。
他の言語は、I/OやI/Fを設計して、それをその言語で作って操作して、という手順になるんだよね。プログラミングはそのI/OやI/Fを作ることから始まることが多い。
しかし、Javascriptはその部分のほとんどをインスタンスとしてブラウザが作った後に動く。すでに形になっているインスタンス群がある状態で動く。そして、プロトタイプ言語だから、インスタンスを作る際に他のインスタンスを使用する事が多い。
つまり、すでに出来ているインスタンス群の状態を知る、つまりDOMを知って、実際にどんなインスタンスが出来ているのか、どんなインスタンスを作ればよいのか、を知る必要がありました。
以上、prototype.jsも満足に使えないへぼい奴からの言葉です。
いや、仕様は大体本読めば分かるんだよ。
全部がオブジェクトで実は中身はハッシュだとか、プロトタイプベースのオブジェクト指向だとかそう言うのは。
ただ、具体的にプロダクトにこう言う機能を実現させたい！って時に何をやればいいのかさっぱりイメージが浮かんでこない。
例えば、ちょっとテーブルで表を作ってどこかのカラムをクリックしたら入力フォームになってデータ入力出来る様にしたい、とかでも何から手をつけていいやら。
結局色んなライブラリを探してその説明通りちょこちょこ流用できる時以外は、あうあうあうああーーで全然ナニやれば良いのか頭が働かない。
DOMの操作が分からないってだけなのかなぁ？
phpとかでXML文書をパースして色んな処理、とかは特に躓かなかったんだけど。
AJAXとかprototype.jsとかMochiKitとか色んな技術を使おうとワケワカメになってるのもあるのかも。
昔から地道にwindowオブジェクトをチョコチョコ弄って、とかのjavascriptを書いてきた経験が無いから。
anond:20070404150650の人ではないけれど。
に対して
と言ったわけだ。
つまり、「HTML+CSSを扱えるのがWebブラウザに限定されるように、RSSを扱えるのはXMLパーサに限定されてる、どっちも同じようなもの」ってことでしょ。
で、ここからは私の意見なのだけれど、RSSに見た目を求める人ってのは、なんでRSSを使うのだろう。
上の「HTML+CSSとRSSは似た様なもの」ってのは、ある意味正しいのだけれど、でも、現状では「似たような物」ではない。ちゃんと用途別に使われている。
RSSが出てきたのは、この「用途」の違いじゃないの？
HTML+CSSはブラウザがレンダリングして人が見るために豊かな表現力を持つ。それと引き換えに、ブラウザの消費する(開発とかも含む)リソースは多い。
そういうのじゃなく、もっと軽やかな仕組みのために、表現力を落として意味付けに重点を置いたのがRSSでしょ。RSSにHTML+CSSのような表現を求めてもしょうがないと思うけどなぁ。というか、そこまでするなら、UAみて振り分ければよいのに。
横槍だけど、無理かと。
まずHTMLの意味的役割を無視したサイトが多すぎる。hn要素系が無いだとか、親要素がdivだけで意味づけが不明だとかはよくあることで、非道いのだとtitleが無いだとか、altの無いimg要素だとか、そんなサイトが溢れ返ってる。
更に、ある程度strictな構文であっても思想的な違いがあるから、文書構造が想定不可能で、CSSだけだと意図した見栄えにならない可能性が非常に高いかと。
所詮、HTML+CSSでの可能範囲なんて、ユーザCSSでちょっと文字サイズとか変えたり、pdfリンクの場合に注意文入れたりするくらいで、あとは制作者側が用意したCSSに任せきりにするか、やるにしても思いっきり殺伐としたスタイルを適用するくらいが限界なんじゃないのかな。
もちろん、元記事で書かれてるのはRSSっていうよりXMLの利点だし、XHTML+XSLTまで含めればかなり柔軟性は増すんだろうけど、xhtml+xmlで提供してくれてるところなんてあまり無いし。
エクセルってgroup by とか使うレベルのSQLって書けるの？
なんか職業別分類とか個人的に興味があったので一覧でみてみたいなと思ったんだけど、縦に記述されてるのでエクセルのソートだと厳しい。
ちゃんと計算して値をだしたいんだけどエクセルってどこまでやってくれるのだろうか？
そこまでやるんだったらマクロで集計→別シートに起こす→ソートのほうがいいのかな？
官報も２．０になってAPIかなんかで基礎情報返してくれればいいのに。
誰か、国勢調査の値をDBに落とし込んで外からのリクエストに応じてxml返すみたいなのつくってちょ。
結構需要はあると思う。たぶんプログラム的なところを言えば学生レベルでできるだろうし、システムもレンタル鯖いっこで充分。
誰かやってみないか？
そういう使い方ができるかどうか電話してみよう。。
めも。。
POST /news/newsarticle/34435/TrackBack/ HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 239
Accept: */*
url=http://anond.hatelabo.jp/20070111050543&title=%E8%8B%A5%E8%80%85%E3%81%AE%E3%83%A2%E3%83%A9%E3%83%AB%E3%81%8C%E4%BD%8E%E4%B8%8B%E3%81%97%E3%81%A6%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E6%9B%B8%E3%81%84%E3%81%A6%E3%81%84%E3%82%8B%E3%81%8C
応答：
HTTP/1.1 500 Internal Server Error
(もっとつづく)
trackbackの仕様上、エラーはXMLフォーマットで返ってくるべきなのに、500って恥ずかしいよね。
（北京，12月22日 ロイター） 中国のメディアが金曜に伝えたところによると、3つの一流大学から集まった10人の博士課程の学生が、地域のクリスマスのお祝いを酷評するための、ネット上の請願書を投稿し、人々に「西洋文化の侵略に抵抗する」ことを呼びかけた。
中国日報が伝えたところによると、北京大学、清華大学、中国人民大学という一流大学の学生は、「アメリカとヨーロッパの文化」が「その科学技術的、経済的な支配」をともなって、中国全土に広がっていると罵った。
「西洋の文化は、穏やかなシャワーというよりむしろ嵐のように、この国を掃き尽してしまっている」と新聞は請願を引用して伝えた。その請願の日付は、中国の伝統的な旧暦で書かれていた。
それは「部分的には、経済発展を促進する一方で中国の伝統を維持できなかった政府の失敗である」
著者の学生たちは、祝祭を商売のために使っていると言って小売業者を非難し、その行事の起源も知らずに浮かれ騒いでいると言って中国の人々を非難した。
「クリスマスイブには、北京や他の中国の都市において、殆ど全てのレストランで席を待たなくてはならない」と著者たちは悲しんだ。
近年、クリスマスやバレンタインデーのような西洋の祝祭が、中国の若者の間でポピュラーになった。しかし、伝統的な中国文化が、まっしぐらな経済の急発展の中で押し流されてしまっていると危惧する人々もいる。
中国のコミュニストの政府は、公式にはたった一つの伝統的祭日だけを承認している――中国の旧正月である。その他の、ドラゴンボートフェスティバルのような祭日は、いまもって香港と台湾でのみ正式に認められている。
厚生労働省の課長以上には、管理職手当という手当が支給される代わりに残業代が一切支給されない（公務員は労働基準法適用除外、ということで一応合法らしい）。ということで、「絶対に『わかった』とは言わない」どころか、すでにやっているわけですな。
この人はホワイトカラーエグゼンプションについては理解しているようだが、官僚制度の知識はウトイようだ。
国家公務員の課長職は、職級でいうと９級以上の上級幹部職員。国家公務員の職級順位は係員(1-2級)＜係長(3-4級)＜課長補佐(5-6級)＜室長(7-8級)＜課長(9-10級)という順位となっており、人数的には官僚ピラミッドの上から0.8％ぐらいまでが課長級以上。
霞ヶ関の本省には国家公務員が約１７万人いるが、9級の課長は全省庁で1400人、10級の課長は66人しかいない。地方公務員でたとえると局長など、知事が出席する会議に出るような立場が国家公務員の課長だ。民間企業なら営業部長や工場長や支社長クラス。
国家公務員幹部に超過勤務が支払われていないのは事実だ。しかし、政府が提案しているホワイトカラー・エグゼンプションは、国家公務員の課長クラスを対象としているのではなく、国家公務員でいえば3級の係長とか棒級の高い2級のベテランの係員の残業までサービス残業を合法化してしまえという提案だ。
だから国家公務員の9級の課長以上が超過勤務手当てが無いことをもって、政府が提案しているホワイトカラーエグゼンプションを国家公務員が「すでにやっている」とはいえない。
もし国家公務員の9級の課長以上が超過勤務手当てが無いことを基準とするなら、ホワイトカラーエグゼンプションは年収2000万円以上の役職者だけに限定すべきということになり、それは現在政府が提案している内容とはまるで異なる。
国家公務員の課長をホワイトカラーエグゼンプション適用の基準とするならなおさら、政府提案のホワイトカラーエグゼンプションはひどすぎると考えるべきだろう。
国家公務員はの平の係員にはサービス残業が蔓延しており、残業しても超過勤務手当てが支払われないケースがかなりある。
超過勤務手当てが全額支給されている職員は全体の10.4％程度。実際に支払われている超過勤務手当ては、本来支給すべき超過勤務手当てのおおよそ５割程度だ。
なぜ国家公務員の残業の多くがサービス残業になっているのかというと、組織で使える残業の上限があらかじめ決められていることがひとつの理由。組織としての残業代の上限をいっぱいまで使い切ってしまったら、のこりの残業は、突発的な災害でも起こらない限り、原則としてサービス残業になる。
それがいやなら残業せずにすむよう仕事を効率化して早く帰れ、というのが人事院の言い分だ。が、多くの組織はどこも絶対的に人手不足なので、そんなことはできるはずもない。
たしかに、ヒマな組織も一部あり、そういう組織では、残業代の上限を使い切らないと残業予算が削られるのでしなくてもいい残業をしていることがある。だからそういうムダのないよう不要な残業予算を削ることは必要だ。
だが、人事院や財務省は必要／不用の判断を実態を調べて判断せずに機械的に残業予算を割り当てている。その結果、本当に残業が必要な組織ではサービス残業が蔓延し、ヒマな組織では上限いっぱいまで残業することが固定化されてしまうことになる。これでは悪循環だ。
仕事を効率化させるのはあたりまえとしても、それと賃金不払いは別問題。現実の残業労働に対しルールどおりの賃金が支払われないという現状は、労働法違反であり違法である。
だからサービス残業をやめさせろと組合は再三主張しているし、「国家公務員の残業改善に関する請願」も国会に提出している。誰もサービス残業という現状に納得して好き好んでサービス残業しているわけではない。
多くの組織では人手が足りない。足りないにもかかわらず公務員改革の名のもとで定数を極限まできりつめる。だからますます人手不足となり、残業が増える。残業が増えても公務員改革の名のもとで残業の予算をつけないから、サービス残業となる。結果、過労による労働効率は低下し、不満は高まり、職場の士気は落ち、労働効率は逆に悪化する。
行政サービスが人的問題によって劣化して困るのは、結局は国民だ。
http://www.shugiin.go.jp/itdb_seigan.nsf/html/seigan/1541351.htm
国公労の調査によれば、年360時間以上の残業者は全体の６割占めており慢性的な長時間労働となっていることが明らかになっている。過重労働による公務災害の認定要件とされる「残業時間月80時間以上」と回答している職員は、ほぼ２割（18.9％）に達している。調査対象となった職員の7.2％(364名)が過労死の危険を「現在感じている」と回答を寄せている事実も明らかになった。
こんな現状だから、厚労省は自分の職員に対してホワイトカラー・エグゼンプションを導入する気などさらさらない。もし導入すれば「違法なサービス残業の固定化だ」という批判が組織内部から一斉におこる。そしてその主張はまったく正しい。だから霞ヶ関は自分の職員に対してホワイトカラー・エグゼンプションを導入したくてもできない。するつもりもない。
つまり、自分ではできもしないルールを、国民に対してだけ、厚労省は求めようとしているということだ。
http://www.sannichi.co.jp/kyodo/news.php?genre=National&id=2006122101000602.xml
労働時間規制を一部撤廃するホワイトカラー・エグゼンプション（適用除外）を議論する厚生労働省の審議会は２１日、労働者側の合意が得られないまま導入に向けて結論を出す見通しが強まった。これに対し、働き過ぎで死にかかった体験を持つ元管理職らから「長時間労働を拡大する過労死促進法だ」との批判の声が広がっている。
夫や息子の過労死、自殺の悲劇を体験した遺族らは、厚労省に導入撤回を申し入れたのを皮切りに、東京都内のオフィス街で反対を訴えたり、審議会のメンバー全員に手紙を送るなど要請行動を展開している。
大手ゼネコンの元技術者秋山光夫さん（５６）は「自律的な働き方なんてない。ノルマや成果主義に強制される働き方だ。厚労省は法改悪ではなく、労働時間を守らせ、長時間労働や過労死を減らす対策を強めるべきではないか」と訴える。
http://www.sannichi.co.jp/kyodo/news.php?genre=National&id=2006122101000602.xml
労働者側の合意が得られないまま導入に向け結論って、じゃあなんのために労働者側を入れて議論していたんだ、と。
ホワイトカラー・エグゼンプションなんてとんでもないルールを国民に押し付ける前に、厚労省の課長以上の官僚や自衛官の佐官以上の全員の給与を、全部ホワイトカラー・エグゼンプションにすべきではないかな。
教師に「愛国心教育」を強制しているのだから、政府の官僚もホワイトカラー・エグゼンプションに参加して愛国心を示してもらおうじゃないか。そうすればかなりの節税になって国民の理解も得られるだろう。
などと提案しても、連中は絶対に「わかった」とは言わないだろう。
自分でできもしないルールを国民にだけおしつけようという厚労省の魂胆が気にいらない。
どうしても、ホワイトカラー・エグゼンプションを導入したいのならば、日本株式会社の総本山である、公務員への導入から初めて頂きたい。多くのサラリーマンの根本を揺るがすホワイトカラー・エグゼンプションは、「隗より始めよ」である。
（前回：『はてな』がイノベーターに成り得ない５つの理由 - はてな匿名ダイアリー）
20:02:05 - 2006/12/09(土)
18:15:30 - 2006/12/10(日)
