トップ «前の日(11-17) 最新 次の日(11-19)» 追記

2002-11-18

_ コンパクトサーバとか

数ヶ月前から自分用サーバがほしくて仕方ないのですが、候補として挙がっているのが

  • ベアボーンキットでかっちょよくて速いサーバ
  • PowerBook2400 でコンパクトでかっちょよくてディスプレイの心配の要らないサーバ
  • ウルトラマンPC110 でコンパクトで酔狂なサーバ

くらい。他にもいいのあったら教えてください。現実的なことを言っちゃうと安い中古ノートが候補なんですけどね。でも可能な限りかっちょよさにはこだわりたいです。

Tags: Net 日々 Tool

2003-11-18

_ ViewCVS も制覇

ちょっと設定の意味の分からなかった ViewCVS も動いた。これでまた内職環境が一つ整ったわけだ(こら)

Tags: 日々 Web Tool

_ キーボードがほしい

ので調べてみるか。

Tags: 日々 Tool

2005-11-18

_ samba と netatalk

ここ数日 samba3 & netatalk2 の実験中。(FreeBSD 6 はこの絡みで動かしている。)なぜって、NAS がある理由でまともに使えないから。どうせなら自分で起こせた方が今後も融通が利いていいかもしんない*1と思い、実験を開始。

netatalk って基本はシステムべったりなんだ。システムアカウントと、Unix 系の伝統的な permission で運用できる*2ってことは、実は自分みたいな古い頭の人間にはこの方が楽かもしんない。*3

samba は高機能なのとシステム自体にあまり依存しないようにできているので、ユーザーの情報を別に管理しなくちゃならないし、考え方がメンドイ。開発チームやユーザー数の規模が違うのでツールやドキュメントは圧倒的に samba の方が充実してるけど。

というか、インストール記事よりも本当にほしい実際のユーザー管理や権限管理のノウハウとかそういう話って、Web 上にはないもんだなぁ。保存しておいた雑誌記事にもない。みんな何の苦労もなく使えているんだろうか。あるいはここが本当にお金になる部分だから表に出てこないとか。

Tags: Net Tool

*1 もちろん善し悪しなんだけど

*2 できそうってだけで実は間違ってるかも。

*3 ユーザー情報を汎用なものにするためには PAM 経由で切り離す。

_ 半日以内…

textfile.org 経由で 半日以内に仕上げないといけない仕事があるとします。

にも書いたんだけど、

  1. 〆切りが延ばせるかどうか確認。延ばせないなら無理をする覚悟を決める
  2. 無理をすると必ず反動がくるんで、〆切り後のスケジュールを確認
  3. 本当に眠くてだめな瞬間を見計らって小一時間仮眠
  4. 起きたらモカなどのカフェインを入れる
    • ちゃんと事前に薬局などで入手しておく。医薬部外品はほとんど効かないので注意。

ですかね。数日くらいなら連続運用は可能。なはず。最近やってないから自信ないけど。

目覚ましなどで必ず起きることができるという保証が必要ですが、この辺は人によりけりでしょう。

あ、そもそも頑張って半日以内に終わるものなのかどうかって確認が必要ですな。頑張っても無理そうならまったく別な方法を考えるしかないでしょう。

Tags: Web
本日のツッコミ(全2件) [ツッコミを入れる]

_ otsune [>というか、インストール記事よりも本当にほしい実際のユーザー管理や権限管理のノウハウとかそういう話って、Web 上に..]

_ wtnabe [これ書いたあとにやっぱり『Samba のすべて』を Amazon でポチっとしました。ぼやくばっかじゃしょうがないで..]


2006-11-18

_ 東京タワー

金も定職もないっつーのは本当につらくて情けなくて不必要に自分を蔑んで反動で無意味に遊びほうけてしまったりして、とてもつらいよね。

と、まったく勘違いした共感を覚えていたりするのであった。

全体的には、宣伝はすごかったけど話はイマイチ。時間軸をいじりすぎた演出もちょっとどうかと。半分くらいの時間はついていけてなかった。田中裕子はあの手の芝居は良い悪いを別にしてちょっと板につきすぎてる感じ。蟹江敬三と BEGIN の歌がとてもよかった。

と、冷静に見れているようなフリはしているが、最近はすっかりお涙頂戴物には弱くなっちまった。

Tags: 日々 TV

2007-11-18

_ nadoka をいじり始めてこれからの irc の活用を妄想

Nadoka: IRC Client Server Program - nadokaさんとあそぼう

IRC に twitter を載せたのに気を良くして軽く nadoka なぞ。

  • nadoka は bot だと思い込んでいたけど実は proxy + bot だった
  • 設定ファイルがでかい*1
  • 閉じた irc サーバなので別に proxy の機能は要らない(bot の存在が明示されても問題ない)
    • proxy の機能を殺す方法が見当たらない
    • 適当な port に振って acl で deny all する
  • proxy として利用しないと control command が投げられない
    • とりあえず nadoka そのものを front で動かしてしょっちゅう ^C して起動し直すことに
  • googlebot を試そうと思ったら SOAP API の license key が必要だったが、うかつにも取得しておらず、使えないことが判明(今は新規登録できない)
    • 後継が Ajax API になってるけど、、、Ruby じゃできないよなぁ
    • 別に Google 検索なんかできなくてもいいや ← 今ここ

bot の書き方が分かると便利そうだなという感触。というのも最近 twitter をやってみて、

ログを irc で垂れ流すのはなかなか便利

という感触を得ていたため。というか以前からモバイルファクトリー方式であれこれ irc に流せたら便利だろうなーと思いつつここまできてしまっていたんだけど、なんとかできそうな気がしたため。

それとは別に今 Y! Widgets を、仕組みを眺めたりするだけでなくちょっと動かしてみてるんだけど、例えば Yahoo! トピックスなんかを出しっぱなしにしておくのはそれなりに便利だなという気になっている。そんなの feed reader で読めばいいじゃんとこれまでは思っていたんだけど、feed reader で読むことにしていると、すべての見出しが目に入ってしまってともするとうんざりしちゃう。でもウィジェットや irc の画面はどうせ流れて行ってしまうので諦めがつく。

言ってみれば feed reader でのニュースチェックは新聞と同じで、そこにあるすべての情報に対して人間が取捨選択を行う形であり、ウィジェットや irc でのニュースチェックはテレビやラジオのニュースと同じで、流しっぱなしにしておいて気が向いたときに見ればいい形なんじゃないかと。

で、自分としては一般的なニュースは垂れ流し方式の方が気楽でいいなと思うわけです。目立つニュースはどうせ誰かが話題にしてるし、別に先頭切って追っかけなくたっていいじゃんていう。

ただ現状出回っているウィジェットは多くの場合で特定の feed 専用になってしまっていて、そんなもん使えっかボケな状態なので、feed をかき集めて irc に垂れ流す bot を特定の channel に置いとけば便利かなーという感じ*2。アレならジャンルごとに channel 分けてもいいかも*3。もちろんその場合は全文を流すとうざいのでそれは無理だけど、まぁニュースはほとんどの場合で見出しのみなのでそれでイケるかな。

あ、あとログを検索できたらもしかしたら便利かも。

Tags: Ruby IRC

*1 というかコメントが多すぎるのかな。昔の CGI の設定ファイルってたいがいこんな感じだったからなとは思うんだけど、なんか改めて見るとちょっとなぁと感じる。例えばデフォルトの設定と server や channel ごとの設定を別ファイルに分離できたらいいのかも。

*2 極めて個人的な要望だけど自前 irc サーバなので何でもアリなのだ。

*3 今の RSS_CheckBot は単体ではそういうことはできなさそうだけど。継承して bot 増やせばいいのかな? デフォルトの設定だと cache がバッティングするからそこは気をつけないとダメだな。いや、バッティングしちゃってもいいのかな? ← ok ですた。問題は feed の管理方法が分離しちゃうことか。


2008-11-18

_ All Rights Reserved と Creative Commons License

今まであんまり興味なかったけど調べてみました。

結論から言うと自分の理解では All Rights Reserved の表記と CC ライセンスの併用は問題ないと思います。

例によって間違っていたら突っ込んでください。

そもそもの由来と表記の無意味さ

http://eng.alc.co.jp/newsbiz/hinata/2005/09/c.html

この言葉が使われるようになった背景はこうです。米大陸諸国が1910年に締結したブエノスアイレス条約が著作権の保護を受けるためには、There shall appear in the work a statement that indicates the reservation of the property right.(所有権を留保する旨の記載が著作物上表示されていること)としたので、締約国内で発行される物にAll rights reserved.またはスペイン語でこれに相当するTodos derechos reservados.のいずれかの表示が付されるようになったのです。

(snip

一方、このブエノスアイレス条約の締約国は最終的に上で説明したベルヌ条約か万国著作権条約のいずれかに加盟するに至っていますから、後法は前法を廃する (A later law prevails over an earlier law.)というルールにより著作権保護の条件として特別な表記を要求するブエノスアイレス条約は効力を失っています。

  • ベルヌ条約
  • 万国著作権条約

は知っていましたが、ブエノスアイレス条約は知りませんでした。

ということはブエノスアイレス条約にだけ批准している国では今でもこの表記が法的な意味を持ちますが、ほとんどの国においてこの表記は法的には意味を持ちません。書かなくても著作権は保護されます。(ベルヌ条約のみに批准している国では C マークが必要。)

それでもあえて All Rights Reserved

すべての権利を留保している、言い換えると放棄していないという意味です。「すべての著作物は自分の著作物だ」という意味にはならないはずです。その場合は All works belong to me/us. ですよね? 少なくとも rights 以外の単語がないと表現しようがないと思うのですが…。

「無断転載禁止」を訳に当てる通例がありますが、これも著作権法上当然のことを言っているだけで、そんなに必死に訳について考える必要もないでしょう。

「ライセンス」素材の利用と All Rights Reserved

原則矛盾しないはずです。ライセンスが著作権法と矛盾している場合は別ですが、少なくとも CC などは著作権法と矛盾していません。例えば上の日本語に当てはめてみると、一見、許可を取らずに転載できるので "All Rights Reserved" と矛盾しているように読めます。しかし実際にはライセンスによってすでに転載の許可が明示されているのであって、許可なく転載しているわけではありません。従って、例えば CC ライセンスの素材を利用してサイトを作っているからと言ってそのサイトの著作権表示を All Rights Reserved にしてはいけないとは言えないと判断していいと思います。

また極端な例として public domain のものを考えると、public domain のものを利用しても「オリジナル」に対して自分には権利がないし、二次著作物には二次著作物としての権利を有していますので、やはりこの表記とは矛盾していないはずです。権利のないものに対して権利を主張しているわけではないので。

しかし矛盾してそうな例

CC の場合は "Some Rights Reserved" というバナーや No Rights Reserved が掲げられている場合があり、これが混乱のもとではないかと思います。*1

http://www.creativecommons.jp/learn/policies/post_4/

例えば自分のサイトで

  • Some Rights Reserved
  • All Rightes Reserved

が併記されていると読めるような表示はおかしいでしょう。

しかしこの Some Rights Reserved はなんかこう、悩ましいですね。何を言いたいのか不明瞭だし、この表現は使わない方がいいんじゃないかなぁ。ライセンスに徹した方がいいんじゃないかと思うんですが、どうでしょう。

ちなみに、なんでそこまで All Rights Reserved にこだわるかというと、単にこの表記がなんとなくかっこいいからですね。それ以上の意味はないです。

*1 というか CC 自体 All Rights Reserved と No Rights Reserved の間を埋めるということを言っているのでややこしい。


2018-11-18

_ 怠惰なRubyistがNginxをできるだけ楽に使うことを考えたメモ

Nginx 使うには使うけど細かい設定はしていない*1 Rubyist が Nginx だけで何かをする場合の設定をどうしたかのメモ。予め断っておくと、本当に今さらで内容も全然ない話。

単に開発環境でWebサーバが欲しい場合はLLでよい

はい。最初にものすごく身も蓋もないことを書くけど、Nginx を使う必要はない。むしろ準備に手間が掛かる。Python の SimpleHTTPServer とか Node.js の http-server とか、そんなんでいい。

動的にサーバサイドを書く? Rackでいいでしょ。言語もWebサーバも選べない? なるほど、頑張ろう。

Nginxはreverse proxyのために入れる

単純な Web アプリのためにはそんなに proxy 必要ないけど、一つ一つのアプリをシンプルに保とうとするほど、proxy は便利に使える。ということで Nginx を使うときにはほぼ proxy 必須という縛りでよいと思う。

必要な時だけ動くコマンドとして使いたい

Nginxはコマンドライン引数だけで動かすもんじゃないので設定ファイルを書く。こんな感じ。もちろん daemon off だ

daemon off;

events {
}

http {
  include  mime.types;
  sendfile on;

  server {
    listen 3000;

    location / {
      ..
    }
  }
}

events section がないと怒られるけど、別に中身は要らない。mime.types は残念ながら必要で、これがないとブラウザが CSS とか無視してしまう。自分で作ってもいいし、適当に github から落としてきてもよい。

で、ここで大事なことの一つは log をファイルに紐付けないことで、

http {
  access_log /dev/stdout;
  error_log  /dev/stderr debug;
}

※ error_log の debug 指定はお好みで。

しといてあげないと起動した Nginx のログはどこかに設定されているデフォルトのファイルに吐き出されていて terminal 上で全然確認できない。daemon off とこの設定はセットと思ってよい。

面倒なのは絶対パス

で、実際に設定をするわけだけど、やっかいなのは Document Root で、本当は起動時に相対パスで指定できるのがいちばんお手軽なんだけど、残念ながらそういう機能は Nginx にはないっぽい。まぁ daemon として動作する場合には間違いなくフルパスが必要なので、仕方ないっちゃ仕方ない。

こういうやつね。

http {
  server {
    location / {
      root /path/to/root
    }
  }
}

で、じゃあどうするかというと、erb でワンクッション置いて埋め込むとよい。これは Heroku の Buildpack を参考にしていて、

#! /bin/sh

#
# Usage: start-nginx -c <config>
#

erb $2.erb > $2
nginx $@

という sh script を用意して、例えば

./start-nginx -c `pwd`/config/nginx.conf

のように動かす。

その nginx.conf.erb の中では

location / {
  root <%= File.absolute_path(File.dirname(__FILE__) + '/../<root>) %>;
}

みたいなことを書いておけばおっけー。

要は

相対パス → 絶対パス変換を nginx に渡す前のどこかでやる

ってだけ。sh script の中で erb に渡す前に変換してやれば変換のコードは減るけど、 $@ で丸ごと引数渡してる部分を書き換えてやらないといけないのが面倒でとりあえずこんな感じにしてある。

まとめ

登場人物は以下の通り

  • Nginx
  • ERB
  • erb を叩いたのち nginx を起動する sh script
  • nginx.conf.erb

で、全然お手軽じゃない。

でも portable にしておかないと他人と共有できない*2し、自分の手元でもうっかりプロジェクトの場所を動かしたら簡単に nginx.conf は壊れるものなので、この程度なら許容範囲かな?という辺りの面倒くささにしてある。

Tags: Ruby Web

*1 Apache 時代で直接サーバ管理するのをやめた

*2 「自分の環境しか考えてない」とか「各自がそれぞれ書き換えるのが当たり前でしょ?」と言わんばかりのベタ打ちのコードも稀によく見る