Home > Tags > ネットワーク

ネットワーク

魔術師オーフェンのWikiが凄い

Orphenpediaというのを発見したが、情報量が凄い。どうやら、私が読んだのは背約者のあたりまでなので、その後倍くらい続いているようだ。何で止めたかというと…出版間隔か、展開に飽いたのかどっちだっけ。

システムはWikipediaと同じMediawikiベース。2008年9月開始でおよそ3年半近く運営。項目数が1200強ページある割に、「議論」(ノート)の活用があまり無いことから、少人数で各個に編集していると推察される。凄いなあ。

と、思いつつ夏用にログホラのデータを収集する昨今であった。

そういえば、今でこそWikipediaのおかげでWikiとの略称があったが、当初は”Wiki-Wiki”から取ったオリジナルにそって、一部ではWikiWikiWebとよんでいた気がする。現在はOEDにも”Wiki”の名前で登録されたようだし、すっかりオリジナルからも離れたし、Wikiで良いのだろう。

Androidは面倒だ

最近、興味が出てAndroidのpermissionまわりに手を出しているのだけれど、どの関数がどの権限を要求しているのかがさっぱりわからない。

公式サイトからは辿れなかったのだけれども、どこかにまとまった表は無いものだろうか。

情報のクリッピングを整頓してみる

Readabilityは確かに良いのだけれど、何故か会社の環境だとChromeのプラグインで2ステップになってしまって、非常に使い勝手が悪い。ifttt.comを経由してのDeliciousへの登録も、一々Favoriteをつけないと取り込んでくれない。

しかし、Reederとの連携が良いのでInstapaperには戻りたくない。

そこで、Instapaperで記録→DeliciousとReadabilityに反映、と流れを整理した。

Instapaper→Deliciousはタイトルをとりこぼすことが多いのが難点だが、まあReadability連携のほうで普段すればなんとかなる。

なお、事ここに至り、タグは完全に捨ててます。

Reababilityの運用が固まってきた

ブラウザなり、Googleリーダーで読んだ場合は、基本的にbookmarkletかプラグイン経由でReadabilityに保存。Reederなりで読んだ場合も、連携機能経由で保存。

ifttt.comは次のように設定してある。

  1. Instapaper(RSS)が更新されたら、DeliciousReadabilityに登録。これはTweetAtokなどInstapaperしか対応していないクライアントがあるため。
  2. Readabilityでfavoriteがついたら、Deliciousに登録。本当は全部放りこみたいのだけれど、現状fav以外に選択肢無し。
  3. Deliciousに登録されたら、Evernoteの専用ノートブックに放りこむ。

TwitterのFavもDeliciousに流れるようにしてあるので、これでどこに集めようが基本的にDelicious経由でEvernoteにURLが集まる仕組み。Readabilityがimportもサポートしていてくれるなら、Deliciousの流れを逆にしてReadabilityに集めるところなんだけど。難しい。

なお、Readabilityのfavは、家のMac版のReederで毎日夜にちまちまと処理している。

b-mobileをU300からFairに変更

b-mobile U300は帯域がいまいち狭い。Twitterならまだなんとかなるが、そこからリンクがあると地下鉄ではどうしようもなくなる。

というわけで、b-mobile U300の期限がきたので、購入しておいたb-mobile Fairに変更。SIMを差し替えて開通の電話をかけて、設定のアカウント部分を変更するだけと楽なもの。

速度は流石の快適さ。後は、どれ位持つか。4ヶ月上限とはいわないけど、2ヶ月くらいもってくれれば上々。

iftttを使ってみる

iftttはソーシャルサービスの間を繋ぐのりのようなサービス。

基本は「〜」したら「〜」する、といった「タスク」。

「Deliciousでブックマーク」したら「Evernoteに投稿」する、「Instagramで写真を投稿」したら「Wordpress.comで投稿を作成し公開」するなどといったことが可能。

下手な連携ツールやRSS経由でするよりも細かな調整がきくので有り難い。認証もOpenIDやAPI経由で使えるものは、できるだけそっちで認証してくれているようだ。

といいつつ、Evernoteが不整合になって、バックアップとってなおしていたら容量オーバーしたので、しばらく利用停止。

EVERNOTEの体制を整えてみた

まだ今一使い勝手が悪いのだけれど、ニュース資料を放りこんでおいて検索用に使えそうなので周辺環境で色々といじってみた。

まず入力口としては4つ。デスクトップからはブラウザ拡張とInstapaper。iPod touchからはFastEverとReeder。ブラウザ拡張は適当に見ているページを放りこむ用で、Instapaperはメモしておいて後から☆をつけることで、選別をかけている。FastEverはその場でのメモ入力用で、ReederはRSSを読んでいて何かあればメモ、程度の連携。

FastEver App
カテゴリ: 仕事効率化
価格: ¥170

Reeder App
カテゴリ: ニュース
価格: ¥250

入力は全部Inboxにあつめて、デスクトップで定期的に整理。

まだ出力が甘いけれども、ひとまずはこんなところで。

課題としては、ソーシャルブックマーク系が丸々外れてしまっているので何とかしたいところ。Deliciousとの連携はなんだか面倒そうなので、どうしたものか。

サブのウェブサーバを構築

ドメインをとったので、そのためにウェブサーバをjailで構築。入口はpoundを使い、ホスト名で分岐している。

まずは、パッケージをバイナリでインストール。久しぶりなのでports以外でパッケージをいれるためにはどうすればいいか、Handbookを探してしまった。

# pkg_add -r lighttpd
# pkg_add -r php5

/usr/local/etc/lightttpd を編集。

modules.confでfastcgiを有効に。ついでに、ロードバランサとしてpound経由にしたので、extforwardモジュールを使いロードバランサを指定してログに元のIPアドレスが出るようにしておく。


##
## FastCGI (mod_fastcgi)
##
include "conf.d/fastcgi.conf"
include "conf.d/extforward.conf"

server.modules += ( "mod_extforward" )
extforward.forwarder = (
    "192.168.xxx.xxx" => "trust"
)

fastcgi.server = ( ".php" =>
                   ( "php-local" =>
                     (
                       "socket" => socket_dir + "/php-fastcgi-1.socket",
                       "bin-path" => "/usr/local/bin/php-cgi",
                       "broken-scriptfilename" => "enable",
                        "min-procs" => 2,
                        "max-procs" => 5,
                        "bin-environment" => (
                                "PHP_FCGI_CHILDREN"     => "1",
                                "PHP_FCGI_MAX_REQUESTS" => "5",
                        )
                     )
                   )
)

lighttpdの起動でエラーが出たので、IPv6を無効化。

# service lighttpd start
Starting lighttpd.
2011-11-27 10:19:00: (network.c.203) socket failed: Protocol not supported
/usr/local/etc/rc.d/lighttpd: WARNING: failed to start lighttpd

server.use-ipv6 = "disable"

favicon.icoが表示できないので、conf.d/mime.confに指定を追加


  ".ico"          =>      "image/x-icon",

コンテンツは以前実験したPukiwikiをコピーして、無事稼動。

久しぶりにドメイン購入

ネタ用に1ドメイン購入。

3年間ほど確保したけど、具体的にはどう使ってやるかな。

久しぶりにGANDIにアクセスしたので、個人情報の更新やwhois情報の修正もすませておく。

iCloudの罠

iCloud経由でカレンダーを同期すると、せいぜい2ヶ月程度しか同期してくれないようだ。これは仕事上非常に困る。

そこで、まずは母艦と直接同期させようとしてMac側のiCloudを切ると、ローカルのiCalデータが全部消えた。マスターそっちなのか…orz

仕方が無いので再度iCloudと同期して、iCalの「書き出し」でバックアップ。

iPod touch側のiCloudを切ると、データを残すかどうかの選択肢が出た。残してみたら、Mac側のと重複して、全部データがダブった。

解消方法。全部Mac側のカレンダーを削除して、iPhoneも消して同期。それから再度バックアップからMacに登録しなおして同期。ふう。

どうしても重複した場合は、一応iCal Dupe Deleterというツールや、AppleScriptでの対処もあるらしい。

最初にまっ白いカレンダーを見た時は、嫌な汗が出てしまった。

正式にやりたい時は、(多分)次のようにしましょう。

  1. iCloudと同期したまま、iCalでデータをバックアップする。丸ごとだと設定もろとも残るので、個別カレンダーごとに保存。
  2. MacとiCloudとの同期を外す。
  3. iPod touchとiCloudとの同期を外す。データは削除。
  4. バックアップからMacに再登録。
  5. iPod touchを同期して反映。

何故かiCalはバックアップから復活するごとにiCloudをONにするらしい。非常に嫌な挙動だ。

最近のDeliciousが使いにくい1個の理由

Yahoo!に買われ、そして売られと瞑想しているDelisious。以前と比べてどう使いにくいのかを分析してみた。

1. ブラウザプラグインの出来が悪い

はっきりいってこれがほとんど全て。どう出来が悪いのかを見ていくと

1-1. Firefoxでは登録後に小ウィンドウが消えない。一々C-wで消す必要があり面倒。

1-2. タグの補完が無い。出るとしても妙な候補しかでなくなった。

1-3. 推奨タグがほとんど出ない。他人のタグもわからない

1-4. スペース入りのタグがつけられるようになって、「,」で区切ればマルチタグになるよう変更されたが、日本語に非対応。一々フォーカスを外して確定を待つか、スペース二つ挟んで選択画面から”Separate”を選ばないと1つのタグにされてしまう

1-5. タグの確定が遅い。待ってから登録しないとタグ無しとされてしまう。大分ハマりました。

1-7. 登録キャンセルしようとしても登録されていることがある。タグの通信が原因? よって無駄な登録が増える。

1-8. ブラウザプラグインのボタンで自分のhomeにとぶと、ブックマークの一覧ではなく全体のスタック一覧に飛ばされるようになった。一々メニューを出してリンクを辿らねばならず面倒。

かと言って今更他を試すのも面倒なわけで(Diigoはあまり良くなかった)。はてさてどうするか。

自宅サーバからクラウドへの流れになるか

はてなの脱「自作サーバー」宣言から「さくらのクラウド」の未来まで はてな×さくら座談会2011夏 – はてなブックマークニュース

自作サーバの自主運用で有名だったはてなが、さくらのクラウドでの業務委託に切り替えたとの事。安価に入手できる、用途にあわせつつ適応で組める、といった自作のメリットがクラウドで享受できるようになってきたからなのだろう。サーバ機器のおもりをするにしても、昨今は節電もあれば人件費も相対的に高くなるし、結局のところ運用費用がかかるということだ。

個人ではどうかと言うと、私は以下の点をクリアできれば自宅サーバをクラウドに移しても良いと考えている。なお、価格優位性とか保守体制とか会社の信頼度とか安定度とか、あたりまえの話は省略。

まずは可用性ということで「データが引き揚げられること」。データをベンダロックインされるのではなく、適当な単位で手元にバックアップしておきたい。Amazonなど世界各国で分散すれば1箇所落ちても大丈夫、などというのもあるが、古い人間なのでデータは手元に届くようにしておきたいし、手元が壊れてもリモートがあるという状態にしておきたい。

つぎにいささか職業病的だが「機密性が約款で担保されていること」。元々通信事業者には縛りがかかっているが、クラウドサービスの場合どこまで適用されるのかがいまいちわかりにくい。そのため、オペレータが中身を覗けません、安いからといってマーケティングに利用されません、という保証が欲しい。その分、いざとなったら約款の壁でデータが取りだせませんよとなってもOK。そのための可用性条項だ。

最後に、できれば身元確認を取るサービスであること。クラウドによるサービスの利点は支払いさえあればすぐに取れるような利便性にあることは承知しているが、住所を同定する必要があるISPサービスとの連携、あるいはクレジットカードでも良いので身元や信用の確認を行った上で利用可能なサービスである方が、Pinboardのように◯◯な方々避けとしては望ましい。

実際に移すとしたら、まずはウェブとDNSまわりで様子見して、最後にやっとメールサーバという事になるだろう。IPv6が自宅までなかなかきちんと届かないので、クラウドで試せるならば色々やってはみたい。Vyatta等も気になる。

そして、ここまで書いてやっと気がついたが、どっちみち家庭内でファイルサーバとか動かすと大して消費電力がかわないのではないだろうか。せいぜいISPを移動しやすくなる程度? …まあ気にしない気にしない。

IPv6の現状についての所感

なんとなくIPv6について考えてみる。

IPv4が枯渇した今、IPv4を極力延命しつつも嫌でも徐々にIPv6を使わなければならない時期にきている…はずである。というのも一般のレベルでは当然そうあってしかるべきだが、枯渇も延命も移行も実感が無いからだ。

通信網の対応状況としては、通信におけるラスト1マイルの問題のように、ISPと家庭内機器(CPE)の対応がまだまだ取れていない。NTT-NGNでは徐々に対応していくのだろうけれど、フレッツ・ネクスト(NGN利用)のみでフレッツISDN/フレッツ光はまた別。ソフトバンクは6rd方式を推進している一方で、事前に大量のIPv4を確保し、最近はiPhoneにもプライベートIPを割り振り、やりくりしようとしている様子が噂レベルで聴こえてくる。ISPによる差こそあれ、一応進んでいると見ていいだろう。

目を機材やソフトウェアに向けると、おおよそ対応していることに「なっている」が、もちろん旧来の機器では対応していないものも多いし、「IPv6対応は上位グレードだけ」という機器がある時期もあった。小規模のソフトウェアでは、よほど意図していない限りIPv4に依存しているものも多いだろう。だが、このあたりは徐々に必要であれば改善されていくと考えている。

一方、専門家の間でもまだIPv6について実用にならないという勢力があり、そういうのを見ているとUnicodeの状況を思い出す。かつては実装の品質差も激しかったし、規格自体も色々と言われていた(そして今も言われている)。けれども、最終的には規格は不具合を補われ、ソフトウェアはOSが担保して標準的な手法を使えばそれなりに対応するようになり、ユーザがそれほど不自由無い形で使えている。L10N(地域化)ではなく、I18N(国際化)が主となった。

きっと、IPv6もそうやって、実用してはじめてわかる不便なところを修正しつつ、進んでいくのだろう。技術者として、せめてその様子の概観くらいは目を向け続けておきたいものだ。

IPv6で遊んだ組織たち

てくろぐ » World IPv6 Dayはどうでした?

余談に注目。昔から空き領域を半ば実用的な意味を込めて、0xdeadbeef等の意味があるっぽく読める文字列で埋められるような事はあった。

IPv6でもそれは同じで、16進数が数ケタあれば十分綴れる。ましてそれが組織名の略称ならば。

というわけで、A10 NetworkがA10::A10とか、ciscoがC15C0:D06:F00Dとか、FaceBookがFACE:B00Cとかしはじめるわけですね。今は違うのもあるようですが。

IとかOが苦しいですが、1と0でまあ良いのかと。Gを6と読ませるよりは余程自然です。

[物欲] GbE

ESXi用に手頃な値段のGbEが欲しく、注文していたのが到着。秋葉原で探してはみたのだけれども、中古・ジャンク系の店はどんどん撤退し、あったとしてもPCI-Xの時代のものばかり。というわけで、やっとこれで色々とできる。

Home > Tags > ネットワーク

Return to page top

123...Last »