タグ

2010年11月11日のブックマーク (6件)

  • 編集部の厳選3本! はてな匿名ダイアリーの名作短編小説 - はてなニュース

    名前を隠して日記が書ける「はてな匿名ダイアリー」、通称「増田」。誰が書いているか一切が不明なまま、毎日ただひたすらエントリーが積み重ねられていくその光景は、もはやシュールの一言です。そんな「増田」に、どういう了見か渾身の小説作品を送り届けてくる不思議な人たちがいるようです。今回は、はてなブックマークで注目された、謎の才人たちによる傑作ショート・ショート3を送ります。 ■ 「まるで星新一の作品みたい!」との声も……『犬の餓死』 ▽ 犬の餓死 名前の通りに犬が餓死する過程を見せる現代アート、「犬の餓死」。それに憤った大衆が作品発表のたびに犬を買い取っていたところ、かえって作品がマスコミの話題になってしまう。だが、そのブームの絶頂で、突然芸術家は作品を発表するのをやめた。その理由は……? ユーザーから「まるで星新一みたい」と声も出ているのが、この『犬の餓死』という作品。確かに最後のオチに漂う「

    編集部の厳選3本! はてな匿名ダイアリーの名作短編小説 - はてなニュース
  • ユーストで楽曲を放送するにはどうすればいいか・まとめ | ポット出版

    *技術系の話じゃないです。 前回の日誌にも書きましたが、UstreamとJASRAC/イーライセンス/JRC/は包括的利用許諾契約を締結しているので、3社が著作権管理を委託している楽曲はUstreamで自由に配信できます。 各社のデータベースは以下から検索出来ます。 ・JASRAC ・イーライセンス ・JRC 注意書きなどさまざまありますが、Ustream、上記3社に事前に楽曲使用の許諾を得る必要はありません。 (3社に電話して確認しました) ● 使用したら、すみやかにUstreamの「利用した楽曲の報告について」 のページにあるメールアドレスcopyright_jp●ustream.tvに楽曲利用の報告メールを送ります。 (※以下、ポット出版の場合) ● Ustream楽曲利用窓口から、メールに添付されて「Ustream楽曲利用報告書」(エクセルファイル)が送られてきます。 記入例のシー

  • [CSS]パンくずの実装はどのようにするのがよいかの考察

    パンくずは何要素で実装していますか? ul要素? ol要素? p要素? パンくずをどのように実装するのがよいかの考察を紹介します。 Exploring Markup for Breadcrumbs [ad#ad-2] 先日紹介したCSS-Tricksの「画像を使用しないでApple風のパンくずを作成するチュートリアル」に寄せられたコメントから考察されたもので、各ポイントを意訳したものです。 パンくずのマークアップの考察のきっかけ -ul要素で同列配置 パンくずのマークアップの考察 -ul要素で親子 パンくずのマークアップの考察 -ol要素で順序づけ パンくずのマークアップの考察 -セパレーターの使用 パンくずのマークアップの考察 -Googleを参考に パンくずのマークアップの考察 -HTML5の使用 パンくずのマークアップの考察 -おわりに パンくずのマークアップの考察のきっかけ -ul

  • google appengine に関してひと言

    ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt

  • HTML5ベースのリモートデスクトップソフト「ThinVNC」v1.0が公開、正式版に

  • Git入門 ゼロから始めるGitドリル

    gitの勉強をしつつ取ったノートを記事化しました。一応これを読めばざっくりとした導入やSVNとの違いが分かってもらえるように書いたつもりです。svnを使った経験があることを前提に進めていきます。 svnの場合、一つのレポジトリに対して認証のあるユーザが変更を報告していくユースケースをとっています。gitの場合は、個々のローカルマシンにリポジトリが分散されて配置され、お互いに変更を報告しあうユースケース。これはLinuxの伝統的なバザール方式の開発を想定しています。そのため例えばカフェや電車で開発したり、マスターはgithubやgitfarm(Git Hosting参照)にしておいて時々ローカルの変更を報告することも可能です。 目次 インストール 基操作 Gitリポジトリの作成 ブランチの作成。 タグ ファイルを無視する 索引の理解 取り消し 導入 --hardと--softの違い 一個の

    Git入門 ゼロから始めるGitドリル