親戚にビールを注ぐ 酒の力を借りて社会性のある行動に出てみた。バラエティも飽きてきたのでNHKのニュース風にしてみよう。 音声は、 「安易な回答に、実現されないと林氏の『あいつはいつも口だけ』という批判が高まりそうです。」 だろうか。昼のニュースの地元放送局に切り替わってからのローカルニュースのように見える。 ちなみにこのようすは海外メディアではこのように取り上げられている。
それぞれのエントリをブックマークするときに、以下のようなボタンが現れる。 ボタンを押すと、それぞれのブックマーカーの押したボタンの綜合値が「エントリ温度計」に表示される。 こんな感じ。 数値はusers数(図では15users)。 つまり「15人が受けたこのエントリの印象」がグラフィックとして表示されている状態。 表示される場所はそれぞれのエントリでもいいし、ブックマークエントリ画面でもいいし。 以下、「エントリ温度」の説明。 で、それぞれの色の意味は? こんな感じ。 三色ボタンがそれぞれに対応するわけですが、ブックマーカーがブックマークするときに 「××だ。ブックマークしよう」 という××にあてはまる「印象」をポチっとするわけです。 ブログ温度計とエントリ温度計 そのサイトのエントリがどの色に分布するか、はこんな具合に表示されるといいかもしれない。 サイトの上のあたりとかに。 最初のを「
参考:会計ソフトからGoogleのサービスを使う | スラド IT Googleは勢いとマニア精神を擽って、ぐんぐん勢力を大きくしているが、全てGoogleに完結させる時代が来るのはもう少し先になりそう。ていうか来ないかも。 Plaggerが便利で、ブログを読むのもスケジュールを読むのも、UIは全てメーラになって、あれがしたいと思えばまずPlaggerで出来るかなあと考えるまでになってきた。もしかして全てPlaggerで完結させる事も不可能では無いのでは(信者)。 単純なプラグインを書いて他のプラグインと組み合わせるだけで、RSSだろうとHTMLだろうと同じ様に読み書きが出来る。ドキュメントは豊富とは言えないものの、サンプルが多いので悩む事は少ない。Perlならではの強みとしてCPAN様を活用出来る事も利点だ。 院の事務通知はサイボウズに掲載されるので、Plaggerに読ませよう。 Pyt
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
_ 対応方法が思いつかないspam そのページに書かれている文章から抜き取ったテキストの最後に1行(宣伝)URLを追加したツッコミspamがさっき来たんだけど、これって機械的な識別がえらく難しそうだな。日本語利用チェックとか、URL文字列割合チェックとか、その手の対応はすべて無効で、ほぼURL・ドメインベースのblacklistで対応するしか手はないんじゃなかろうか。 _ タグ入力支援機能の改善 リニューアル版1470.netのタグ入力支援機能を、使いにくいまま放置している。この辺は結局Ajaxを使わなければならず*1、Ajaxを使う場合はちゃんと設計してから作らないとぐだぐだになりがち*2なんで、隙間でちょっと機能追加するといった感じで作れない。 ひとまずタグ入力支援機能として、どういう機能があれば使いやすいのか自分の中でまとめ切れてないんで、具体的にどういう支援機能があればうれしいみた
そうそう、インタフェースの話でいつも思うのがロールプレイングゲームのユーザーインタフェースなんですよね。あまり意識することはないかもしれませんが、良くできたロールプレイングは大概のものが入力のインタフェースがよくできてる。(DS のタッチインタフェースがいいとかっていう話とはまた別で。) で、ドラクエとかファイナルファンタジーみたいなゲームのインタフェースは、昔のものをシリーズで追っていくと面白くて、徐々に徐々に改善されていってるのが分かって楽しいですよね。例えばファイナルファンタジーIIでは全体魔法を使うと、魔法エフェクトが各敵ごとに逐次で発生して完了するのに待たされるんですが、III では一度にエフェクトが起こるようになって待ち時間が無くなったとか。 ファイナルファンタジーI はドラクエの後発なのでおそらくドラクエのインタフェースを若干参考にしていると思われるものの、ドラクエとは異なり
さて、Googleがオンラインスプレッドシートを出したのだけど、まあ機能の充実度はさておき、実際に企業内で使うとして、重要なデータをGoogle様に預けてよいものかどうかという話がある。たとえば個人情報が関わるようなデータも預けてしまっていいのか。きっとちゃんとしたエンタープライズ環境に適応するには、データ流出/漏洩が怖すぎて使えない。 まあそもそもGoogle Spreadsheetがそんな使い方を想定していない/推奨していないのでは?といわれればそれまでなんだけど、Webでスプレッドシートを共有したいという欲求はそもそもファイアーウォールの内側にこそ多い欲求だったように思う。そこで「○○のデータに関しては使えないよー」となってしまうと、ちょっともったいない。 これはSalesforce.comのようなSaaS (Software as a Service)形式のオンラインサービスにも共
米Google、Ajax開発ツール「Google Web Toolkit」のベータ版を公開 (MYCOMジャーナル) Ajaxアプリケーション開発キット「Google Web Toolkit(GWT) ベータ版」の提供開始と、その概要について説明した。GWTの利用により、Google MapやGmailなどで実現されているようなリッチなユーザーインタフェースをもったアプリケーション開発が容易になる。 GoogleからもAjax開発キット。 これまで出たものもまとめてみると次のような感じ。 米Oracle,Ajax対応UIコンポーネントを公開 AdobeのAjaxフレームワーク Spry Yahoo! UI Library 各社、この分野で競い合ってる感じですね。
« ApplicationDomain | Main | Electrical Fantasista 2006 » March 09, 2006 Flex & Ajax アップデート 先日 Adobe Labs にて、Ajax 関連の発表が2件行われました。 一つ目は、FABridge (Flex Ajax Bridge) と呼ばれる Flex2 アプリケーションと Ajax アプリケーションを連携させるためのライブラリです。これを使うと、Ajax 側から Flex コンポーネントのメソッドを呼び出したり、あるいは逆に Flex 側から Ajax の関数を呼び出したりが簡単にできます。つまり、Ajax アプリケーションに Flex アプリケーションを埋め込むといったことが気軽にできるようになるわけです。現在はまだアルファ前の段階ということで、これからまだ変更などは多々ありそうですが、興味の
Adobe から Spry という名前の Ajax フレームワークが公開されました。(Adobe Labs/spry) Spry は BSD ライセンスの下でフリーで使用できます。 こちらのページでデモが見られます。(Spry Demos) ダウンロードはこちらから。(Spry Download) Spry の特徴は Web 制作者を主ターゲットにしていることで、CSS を使った HTML ページ作成の知識があれば、特に JavaScript に詳しくなくても使えるよう設計されています。このようにすることで、従来の Web デザインの延長として Ajax を使えるようにしたいというのが目標です。今までの Ajax はどちらかというとプログラマの視点から語られることが多かったですよね。 既に公開されている Flex-Ajax Bridge (FABridge) と組み合わせれば Spry と
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 s.h.さんの素晴らしいトラックバック「HIIにHCIのアプローチを取り入れる:『アンビエント・ファインダビリティ』を読んで思ったこと」を機にしたエントリー「HCIとHIIの階層構造、生命情報/社会情報/機械情報の階層構造」に対して、またしても、s.h.さんがとっても素敵な返信をくれました。 これはなかなかいいHHI(Hito Hito Interface)ができている w このエントリで、ユビキタスコンピューティングのアーキテクチャはフラクタルなMVCフレームワークになるという事を書こうと思う。 コンピュータシステムはデータの「入力」「処理」「出力」をするものなので、このフラクタルなMVCフレームワークはちょっと考えてみれば自明な事だと思う。 確かにコンピュータシステムは
こんなおいしそうな議論をしていたとは、さっき飯食ってたときはぜんぜん知らなかったな(苦笑)。アンテナが下がってる。 naoyaさんの文章を読んでいてふと疑問に感じたのが、APIというときのIと「インタフェース」と書いたときとで、それぞれ異なる意味で言葉を使っているように読めるってこと。miyagawaさんのエントリのタイトルが「API, UI as Commons」と2つのIを並列して書いているのと並べて読むと、そこんとこを深読みしちゃうなぁ。 Catalyst の View::JSON とかは渡したデータ構造が勝手に JSON になって Web API になりますよ、というものだけども、これだけだとまだ開発者は「どういう API を持たせて、どういうデータ構造を返して」というのを自分で考えないといけない。なのでインタフェースに制約が欲しい。 APIというのはアプリケーションに対してサービ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く