日本語のネット空間においては、けっこう自信満々でそう言っているひとを多く見かける現象がありますが、いったいなぜなのでしょう？
Is Gmail on Android Push or Pull?
ここでもはっきりプッシュだと言いきっています。「擬似プッシュ」とか「プッシュを厳密な意味で使うひとにとってはプッシュではない」などではありません。
ひょっとすると、Androidでも機種やキャリアによっては（特に日本のキャリア帝国主義空間にあっては）擬似プッシュだったりする状況がある（orあった）のでしょうか？
謎です。
……なんでこんなこと突然調べてみたかというと、IRCをAndroidへプッシュしたいと思ったのです。
当然、まずは、プッシュ通知のIRCクライアントを探しましたが、そのものズバリは存在しません。
プッシュ通知に対応したAndroid用IRCクライアント『TapChat』
という記事がありますが、おそらくこれは作者の書いた文をまともに読まずに書かれています。このクライアントを使用するには、自前でTapChatサーバを立てておかなければなりません。そのことに言及がなければなりません。
TapChatサーバはWindows版はないので、僕の選択肢からは外れます（甘え）。
ズバリIRCクライアントではないけれど、
IRCのキーワード通知をスマートフォンへPushする個人的最適解
という記事が見つかりました。Pushover（有料）を利用するというものです。しかしこの方法は、外部の会社が1個多く絡むことでセキュリティ懸念が増します（パラノイア）。
同様に、ZNC用のPushモジュールを使うという手があるとおもいますが、Windows版をビルドしておいてくれていないので、僕には使えません（甘え）。
Push notifications on ZNC?! Really?!
によれば、入れればちゃんとAndoirdへもiOSへもプッシュ通知できるようです。開発元にも「さらなる開発中だが、実用にはすでにたえる」と書いてあります。
電子メールゲートウェイを介してSMSを送るという手があるのではないかとおもいましたが、この線は半年ぐらい前にも別件で一度あたってみたことがあるのですが、今日探してみてもあいかわらずMobitelが電子メールゲートウェイに対応している情報が見つからなかったので諦めました。
で、結局、呼ばれたらGmailへ通知させるのがいちばん簡単そうかなぁと。
ZNCのshellモジュールとかがこれに使えるのでしょうか？ あるいはIRCbot Consoleを使うと実現できそうです。
2014年9月5日金曜日
あらゆる学校は、親がまともかDQNかという軸と、親がリッチかプアかという軸により形成される4つの象限のいずれかに属する
のだと思う。
図解すると下図のようになる。
私の行った東京大学は、少なくとも私の交友の感じでは、第II象限という印象であった。もちろん全員がとは言いませんが。
下の動画は、タイの学校崩壊の様子。
これなどは第IV象限であろう。
成金層のバカ親のお子様たちとおもわれる。
先日、うちの子供2人を転校させたことを書いた。
現在子供を行かせている学校は、もう明確に第II象限である。
かなり第I象限寄りではあるが、少なくともIIIやIVではないということが何より大切なことだ。
学校の質とは、親のまともさ90％、カリキュラム5％、先生5％だと言ってもよい。
第I象限というのがもちろん理想だけれど…。
<親馬鹿>
余談ですが、長男(8)はさっそくSpelling Bee Competitionで3位を取りました。
gymnasticsのsを会場の雑音で聞き取れずに言わなかったので運悪く3位になってしまったが、それがなければ実力的に確実に1位だろうと思えた。
いやいや、わかっていますよ、運も実力のうち。
図解すると下図のようになる。
私の行った東京大学は、少なくとも私の交友の感じでは、第II象限という印象であった。もちろん全員がとは言いませんが。
下の動画は、タイの学校崩壊の様子。
これなどは第IV象限であろう。
成金層のバカ親のお子様たちとおもわれる。
先日、うちの子供2人を転校させたことを書いた。
現在子供を行かせている学校は、もう明確に第II象限である。
かなり第I象限寄りではあるが、少なくともIIIやIVではないということが何より大切なことだ。
学校の質とは、親のまともさ90％、カリキュラム5％、先生5％だと言ってもよい。
第I象限というのがもちろん理想だけれど…。
<親馬鹿>
余談ですが、長男(8)はさっそくSpelling Bee Competitionで3位を取りました。
gymnasticsのsを会場の雑音で聞き取れずに言わなかったので運悪く3位になってしまったが、それがなければ実力的に確実に1位だろうと思えた。
いやいや、わかっていますよ、運も実力のうち。
</親馬鹿>
UnrealIRCdでユーザー名によるban
IRCチラ裏シリーズ第5弾ぐらい。
ChanServでアクセス登録済かつNickServで認証済のニックのみがチャンネルへの参加を許可されるようにするだけでは、そもそもサーバにまるで知らん他人が入ってきて勝手にチャンネル作ったりすることを防げません。
僕は了見が狭いので、自分のサーバのリソースを知らん他人に食われたくありません。
まるで、IRCが夢見た「世界は友達」的な世界観をことごとく否定したいかのようです。
もちろんFW等でLAN内オンリーとすれば根本解決なんでしょう。
が、自分が外から入ったり、将来お客さんとかの参加を考えて、LAN外からのアクセスは残しておきたいところです。
そんな、きわめてセルフィッシュな僕です。
ですので、知らん他人がIRCサーバにアクセスしてもすぐに切断されるように設定しました。
性格悪いですね！
以下その方法です：
UnrealIRCdの.confで
ban user {
mask *@*;
reason "Unknown user";
};
except ban {
mask *miuchi@*;
};
とした。
LimeChatの「ユーザー名」欄を全社員「miuchi」とする。
そうしていない他人がサーバにアクセスしようとすると
22:05 *Error(465) *** You are not welcome on this server (Unknown user) Email admin@miuchi.net for more information.
22:05 *ERROR Closing Link: hirota[192.168.1.3] (You are banned)
と表示されて切断される。
社員外の参加を認める段階になったら、
except ban {
mask *okyaku@*;
};
などを増やす。
要は、IRCのユーザー名をIRCサーバパスワード的に運用しようということです。
ですので下線部はもちろん実際とは変えてあります。
社員ごとに異なるユーザー名を与えてもちろん構わないとおもいます。そのほうが、辞める社員などのことを考えたときに、よりセキュリティは高まると思われます。この場合、ニックが世間的にいうアカウント名に相当する役回りとなり、ユーザー名が世間的にいうパスワードに相当する役回りとなります。試してませんが、その場合、except banを社員の数だけ作ることになる手間が生じるでしょう。
ChanServでアクセス登録済かつNickServで認証済のニックのみがチャンネルへの参加を許可されるようにするだけでは、そもそもサーバにまるで知らん他人が入ってきて勝手にチャンネル作ったりすることを防げません。
僕は了見が狭いので、自分のサーバのリソースを知らん他人に食われたくありません。
まるで、IRCが夢見た「世界は友達」的な世界観をことごとく否定したいかのようです。
もちろんFW等でLAN内オンリーとすれば根本解決なんでしょう。
が、自分が外から入ったり、将来お客さんとかの参加を考えて、LAN外からのアクセスは残しておきたいところです。
そんな、きわめてセルフィッシュな僕です。
ですので、知らん他人がIRCサーバにアクセスしてもすぐに切断されるように設定しました。
性格悪いですね！
以下その方法です：
UnrealIRCdの.confで
ban user {
mask *@*;
reason "Unknown user";
};
except ban {
mask *miuchi@*;
};
とした。
LimeChatの「ユーザー名」欄を全社員「miuchi」とする。
そうしていない他人がサーバにアクセスしようとすると
22:05 *Error(465) *** You are not welcome on this server (Unknown user) Email admin@miuchi.net for more information.
22:05 *ERROR Closing Link: hirota[192.168.1.3] (You are banned)
と表示されて切断される。
社員外の参加を認める段階になったら、
except ban {
mask *okyaku@*;
};
などを増やす。
要は、IRCのユーザー名をIRCサーバパスワード的に運用しようということです。
ですので下線部はもちろん実際とは変えてあります。
社員ごとに異なるユーザー名を与えてもちろん構わないとおもいます。そのほうが、辞める社員などのことを考えたときに、よりセキュリティは高まると思われます。この場合、ニックが世間的にいうアカウント名に相当する役回りとなり、ユーザー名が世間的にいうパスワードに相当する役回りとなります。試してませんが、その場合、except banを社員の数だけ作ることになる手間が生じるでしょう。
クメール語の修飾語順規則と、何事にも例外はあるという話と、例外とは高次規則の徴証であるという話
クメール語を勉強するひとのための教科書には、複数の連体修飾語が付くときには、人称所有詞が最末尾に来ると書かれている。
だが実際にはクメール人の発話において僕らはときに
ムペア クニョム スレイ （女の俺の友人）
というよう「規則破り」を耳にする。
これは、先生が示した規則に対する例外なのだろうか。
あるいはこの「例外」は、最も強調したい性質を最も最後に言う、という、より一般化された理論によって包括できるものであり、冒頭の規則はその特殊理論にすぎないと言えるのだろうか。
もうひとつ、日本語においても本多勝一が指摘しており、多くの言語においておそらく通用する構文技法として
「親和性の高い語どうしについては、誤解を招く危険があるときには、あえてそれらを互いに離す」というものがある。
上の例でいえば
ムペア スレイ クニョム （俺のガールフレンド）
は恋人のような意味に誤解されるおそれがある。だからあえて語順を入れ替えるのだ、ということだ。
いずれにせよ自動翻訳の開発は、単純に人間が考えるアルゴリズムでは難しそうだ。
アインシュタインの言葉ではないが、人間が考えだした言語という問題を真に読み解くには、おなじ頭脳では不可能だということかもしれない。
それがいま急速に進歩と実装が進みつつある機械学習というもので解決されることを大いに期待している。
上記のような悩みが、単に衒学的なディレッタントのみの物になる日の遠からんことを。
だが実際にはクメール人の発話において僕らはときに
ムペア クニョム スレイ （女の俺の友人）
というよう「規則破り」を耳にする。
これは、先生が示した規則に対する例外なのだろうか。
あるいはこの「例外」は、最も強調したい性質を最も最後に言う、という、より一般化された理論によって包括できるものであり、冒頭の規則はその特殊理論にすぎないと言えるのだろうか。
もうひとつ、日本語においても本多勝一が指摘しており、多くの言語においておそらく通用する構文技法として
「親和性の高い語どうしについては、誤解を招く危険があるときには、あえてそれらを互いに離す」というものがある。
上の例でいえば
ムペア スレイ クニョム （俺のガールフレンド）
は恋人のような意味に誤解されるおそれがある。だからあえて語順を入れ替えるのだ、ということだ。
いずれにせよ自動翻訳の開発は、単純に人間が考えるアルゴリズムでは難しそうだ。
アインシュタインの言葉ではないが、人間が考えだした言語という問題を真に読み解くには、おなじ頭脳では不可能だということかもしれない。
それがいま急速に進歩と実装が進みつつある機械学習というもので解決されることを大いに期待している。
上記のような悩みが、単に衒学的なディレッタントのみの物になる日の遠からんことを。
なぜ私はデング熱にかかったか または東南アジアでリゾート気分で半袖半ズボンで歩き回る人々
代々木公園の蚊で紗綾たむがデング熱にかかったりして日本ではにわかにデング熱ヤバイヤバイブームが起きているようです。
僕は2004年にカンボジアでデング熱にかかりました。
治療法もないので、1週間、ベッドでウンウンうなっているだけでした。
苦しみながら寝ている一人暮らしの部屋へ、当時のカンボジア人社員の女の子がそのお母さんと一緒に来て、まずいきなり部屋に殺虫剤をまかれました。
「勘弁して～！」
と思いましたが、よく考えれば、僕から蚊を経て感染するおそれがありますので、理にかなった行動といえます。
関係ないですが、ちなみにその女の子は、今は僕の妻ですが、そんなことは本題に関係ないのでとばします。
なぜデングにかかってしまったかというと、当時プノンペンの都心から割と近い郊外（スタン=ミアンチェイという地区）にゴミ集積場があり、そこへ仕事で、ゴミ運搬トラックごとゴミ重量を計測する装置のパソコンを直しに行ったとき、白昼、蚊に食われたことが、明らかに原因とおもっています。
通常、デング熱を媒介する蚊は、昼間活動します。
夜に活動する蚊は、通常、デング熱を媒介しません。
したがって、昼に蚊に食われないことが最大の予防策となるのは言うまでもありません。
夜も食われないほうが無難でしょう。
蚊に食われないためにもっとも有効な方法とは何でしょうか。
蚊取り線香は、その周辺に自分がいるときにしか効きません。歩きまわっているときにベープを持ち歩くわけにはいきません。
虫除けスプレーなどの皮膚につける薬は、すぐに揮発していまい、はっきりいって大した効き目ないというのが僕の実感です。
したがって、
肌を露出しないこと。
これに尽きます。
カンボジアはじめ東南アジアへいらっしゃる方や、住んでいる外国人（日本人を含む）のなかには、半袖シャツとか半ズボンで、肌を思いっきり露出してる方がけっこういますが、自殺行為であるといわざるをえません。
僕はほとんどつねに長袖長ズボンです。
グループチャットと言って僕らが普通思い浮かべるようなものをIRCで作る方法
IRCのユーザー認証について勉強していると、まるで自分が、J. P. ホーガン先生の小説によく出てくるような、体制側の脳筋マンになったような気分がしてくる。『創世記機械』でミサイル基地に飛ばされちゃったあのひととかね。（ネタバレにつき黒塗り）
なにしろ、素のIRCにはそもそも「ユーザー認証」という概念がないのである！
なんとまぁあけっぴろげで、あっ軽い、理系学生的な、ホーガン的な思想であろうか。
が、1990年代前半の大学キャンパスの空気を吸った僕にはよくわかる雰囲気でもある。
ここに僕は、僕らの世代が上下の世代と根本的なところではわかりあえない最大の要因となっているサブカル的ノリの源流をも見出すのだが、それはまたアナザーストーリーである。
会社経営者 兼 IT部長 兼 その他 のロープレをリアルに目下おこなっている僕としては、ざっとネットで調べた結果、2014年の現在においてもいまだに社内チャットサーバの立ちあげにはIRCが拡張性など勘案して最適解であるように見える以上、IRCでユーザー認証を実現する方法があるのかを知りたかった。
で、AnopeのChanServのリファレンスなどを参照してみた。
方法は、あるようだ。
おおざっぱにいって、NickServがユーザー認証をつかさどり、ChanServがチャットグループ（IRC界ではチャンネルという）へのメンバー登録（メンバー以外は閲覧できない）をつかさどるということのようだ。
NickServで社員をREGISTERしておく。
社員は、IRCに参加する都度、NickServにIDENTIFYでパスワードを入力することにより本人認証を行わねばならないようにする。
NickServのパスワードは、LimeChat2というIRCクライアントでは、記憶させておくこともできるが（他のクライアントではどうなのか知りません）、それはセキュリティ的によろしくない気がするので、かつウチはけっこうデスクトップパソコン群に対してフリーアドレス制に近い状態になってたりするので、記憶はさせておかず、毎回パスワードを入力しなければならないことにする。
NickServでまた驚かされるのは、デフォルトでは、他人であっても、パスワードを打たなくてもいったんあなたとしてログインできてしまうという仕様だ。
ただ単に「このひとは認証ずみですにょ」というマークが付かないだけであり、自由にチャット内容の閲覧どころか、あまつさえ発言などできてしまうのである。
嗚呼古き善きヒッピー達よ。
したがって、そうならないよう設定を変えておかないといけない。
SET KILL QUICK
とかでよいのであろうか。
あるいは.confでグローバルに変えれるのかも（未学習です）。
あるいは.confでグローバルに変えれるのかも（未学習です）。
一方、ChanServの設定は次のとおり：
SET #channel RESTRICTED ON = アクセスリストに登録されている人のみそのチャンネルに入れる。
SET #channel SECURE ON = NickServで認証済の人のみそのチャンネルに入れる。SET #channel MLOCK +rでもたぶん効果は同じと思われる。
アクセスリストには、廣田以外全員、レベル3（auto +v = 発言できる）として登録しておけばよいだろう。
加えて、以下のような設定も可能である：
SET #channel PRIVATE ON = チャンネルリストに表示されなくなる。
SET #channel MLOCK +i = 招待者のみ参加可能とする。Skypeチャットグループのメンバー追加操作に近い。
カンボジアで最も自然と触れあえるホテルの写真
が投稿されていました。ライブドアニュースで知りました。
「火事で避難したら…その後は？」
「こんにちワニ」
「プールつきホテル」
「パンフのキャッチコピーは『自然とのふれあい』」
などのコメントが心暖まります。
「火事で避難したら…その後は？」
「こんにちワニ」
「プールつきホテル」
「パンフのキャッチコピーは『自然とのふれあい』」
などのコメントが心暖まります。
登録:
投稿 (Atom)