  |
はてなキーワード: ディスクリプタとは
先日の三上悠亜がCA4LAとコラボしたことで炎上した件をはじめとして、性的表現に関わるものについて「ゾーニング」をしろという意見がよく見られるのだけど、どういうゾーニングをするべきか、というのがさっぱりわからない。
ゾーニングというのは、ゾーニング対象が消滅しても成立するし、逆にゾーニングにより守られるべき受け手が消滅しても成立する。
エロ本が存在しなければエロ本は完璧にゾーニングされているし、18歳以上の人しか存在しないなら18禁のゾーニングは無条件に成立する。
みんなは、どこにラインを引くべきか、あるいは引かないべきか、どう考える？
| 番号 | ライン | 具体例 |
|---|---|---|
| 1 | ゾーニング対象の抹殺 | エロ本を焚書する、AV女優を殺害するなど |
| 2 | ゾーニング対象を封鎖する | 離島に隔離する、市街地に塀と検問所を設けて隔離する、刑務所的な施設を整備する |
| 3 | ゾーニング対象を厳しく隔離する | 売り手と買い手は政府による免許を必要とし、免許を確認の上立ち入り可能な施設に隔離する |
| 4 | ゾーニング対象を隔離する | 政府による許可を得た店舗に隔離する、学校や福祉施設等と隔離し住専には設置不可にする、学校や福祉施設等と隔離し住専には設置不可にする |
| 5 | ゾーニング対象を厳しく区分陳列する | 店舗内で、什器や壁により隔離されたスペースで販売する |
| 6 | ゾーニング対象を区分陳列する | 店舗内で、棚を分ける等する |
| 7 | 広告を禁止する | 一切の広告を禁止する |
| 8A | 屋外・公共交通機関・区分されていない店頭での広告を禁止する | ポスター、ポップなどを使った広告は区分陳列と同じ場所に制限する |
| 8B | TVCM、一般雑誌、新聞等での広告を禁止する | 専門雑誌やWeb以外でのメディアを使った広告を禁止する |
| 9A | レーティング表示、コンテンツディスクリプタの義務化 | 18禁などの表示や、レーティングの理由が暴力か性表現かなどの説明を記載する |
| 9B | シール止めやシュリンクラップ | シール止めやシュリンクラップで内容を見られないようにする |
| 9C | 表紙やパッケージの内容の制限 | 使用できる写真、文言などを明示的に制限する |
| 10 | PNや芸名の強制変更 | アダルトコンテンツの作者や俳優、女優は、一般向け作品や全年齢向けの媒体に移るときは名前の変更を強制する |
| 11 | フィルタリングソフトの義務化、使用されない場合の免責 | meta name="rating" content="adult"などのメタタグを用いればゾーニングはできているとされ免責される、子供にはフィルタリングを義務化する |
| 12 | 店内商品のレーティング表示による免責 | 店の入り口に商品のレーティング、コンテンツディスクリプタを掲示した場合免責する |
| 13 | 放送のフィルタリング機能の義務化 | テレビ等の放送機器にフィルタリング機能を実装し、EPGでレーティングやコンテンツディスクリプタを配信しその範囲で免責する |
| 14 | 外出の制限 | コンテンツ等が目に入ってしまった場合に責任を問わないことを事前に約束しない場合は外出を禁止する |
| 15 | 瞼の利用 | 閲覧者が自己責任において瞼を活用し、使用しなかった場合の結果について責任を負う |
| 16 | 感覚機能の制限 | 視覚聴覚等の感覚機能を除去し、または器具等により機能を制約する |
| 17 | 認識機能の制限 | 薬剤または外科手術等により感じる機能を停止させる |
| 18 | 閲覧者の抹殺 | 閲覧による結果について責任を負えない閲覧者を抹殺する |
あと、このようなラインを引いたことによって生じた損害（逸失利益、ゾーニングのためにかかるコスト、心身のダメージ等の精神的被害など）を補償すべきかどうか、どう考える？
たとえば、製造販売に制約を設けたとき、それが無ければ得られたであろう利益を補償するのか？ 店の売り場を分けるなら、その什器の費用やスペース効率の悪化を補償するのか？ スティグマ化で負った精神的被害を補償するのか？ 視覚を奪ったときの逸失利益や慰謝料は？ みたいな話。
プログラマとして働く15年のキャリアの中で5回ほど就職活動をしています。5回の内訳はといいますと、1回目は普通に就活、2回目はエージェントを利用した転職＋自分での就活、3回目はコネ、4回目はスカウト、5回目は自分で就活といった流れになります。これまでに合計で34社との間で面接に臨ませていただいていますが、26社から内定を頂いています。【追記】初めての転職は待遇の問題で、2回目は企業の事業からの撤退に伴っての会社事情での退職で、その時の上司のコネで共に転職。3度目は、その上司の転職後にオファーを頂いて行く事に決め、最後にやりたい事が出来て4度目という流れになります。自分ではジョブホッパーとは思わないですが、コメント頂いたように多いかもしれませんね。
就職活動の際は、10/16 でした。初めての転職では、8/10 でした。2度目、3度目の転職は、1/1 です。直近の転職では、6/6 でした。
スコアとしては悪くはないでしょう。正直なところを言うと、断るのが面倒ではあるので、あまり数を受けたくはないんですが、コネやハントされて就職するのでもなければ、どの様な会社かを自分で見て判断せねばなりませんから、この様な結果になってしまっています。
もちろん私の持つニッチな専門知識と技術力の訴求力があってのことではあるのですが、私の中では面接そのものに対する絶対的な自信があります。
面接というのは、企業が自分を見る場というだけではなく。我々求職者が、企業を見極める場でもあります。自分を見てほしいという視点は捨てて、自分が幸せに働ける企業だろうか？という視点を持つべきでしょう。そういう視点があって初めて、企業に対して聞きたいことが出てくるはずです。
私が業務経歴書を書く際に意識することは、この書類を用いて面接者が何を自分に聞いてほしいか？を明確にイメージすることです。この段階で、私は面接官の意識を誘導して自分の能力をアピールできる方向に持っていきます。例えば、学生だと、自身の修士などでの研究についてアピールしたい項目がある場合は、実際に業務で利用されている同様の技術の課題や問題点を指摘しつつ自分が何を解決したかを、「大雑把に」一言添えておくなどの工夫をします。論文要旨から実際の問題に落とし込む手間を相手に払わせない事です。だいたい理解出来ていると思うけど、少し突っ込みたい事がある場合には絶対に近い確率で聞いてきます。そういった点を複数盛り込んでおけば、面接全体を自分のペースで支配できるでしょう。
というような順序で話を構成していくべきです。
どんな技術を修めて来たか、その技術を用いてどんな仕事をしたいと考えているか、その仕事が対象企業のどんな業務内容とマッチすると考えているのか、その業務に着けた場合、どの様な達成目標が考えられるか。
ここまで話せておけば問題ないでしょう。辞めた動機は悪口にならなければ、構わないと思います。
私自身は、そこはごまかさない様にしています。例えば、ある業務を提案したけど許可がおりなかったし実現の可能性がない、御社では既に同様の業務があり可能性があると考えたというような感じですね。自己PRは、実際とても大事で、その後の面接の方向性を決定する事になります。ですから、最初の時間はうまく使ってください。
技術的な質問は既に誘導を仕込んでいるレジュメに従って出てくるはずです。それに関して、アピールしたい内容を答えると同時に、相手の知識を問うような質問を発しましょう。これから働く可能性がある同僚のレベルをしりたいのは当たり前のことですから、ガンガン逆質問を入れつつ議論を深める方向にもっていくべきでしょう。例えば、今話題となっている演算処理について何か致命的な問題があると仮定しましょう（誤差、処理時間など）、それに関してどの様なアプローチで解決してきましたか？というような質問は適宜しておきたいところです。
また、仮に自分が職場にアサインされた場合、どの様な業務が想定されているのか？自分のレジュメの何に興味を感じて呼んだのか？というような質問は、最後の質問時間ではなく、この段階で議論を深めておくべきだろうと思います。
例えば、自己PRを終えた直後に、「今回、この様なチャンスを頂けたのは、私のどのような点に興味をお持ちいただけたからでしょうか？」と言っておけば、自身の専門領域に関して興味を持ったというような回答が出ますから、やりやすいペースが作れます。「そこに関して自分がどの様な問題の解決能力を持っていれば、御社で働くに値するか？をご判断いただける場にしたいです。お願いします。」といったような感じですね。自己PRがいかに大事なものか？わかっていただけると思います。
企業は何か必要があって採用活動をしているのですから、ベストマッチってものがあります。自分がベストマッチであれば互いに幸せになれますが、そうでなければ不幸でしかありませんので、ベストマッチであるかどうかを見極める「お見合い」が面接と考えましょう。
というような事は最低でも抑えておきたいところです。そこに「自分が得意な仕事」「やりたいと考えている事」がマッチするようであれば、お互いにとって幸せな結果になります。私の場合は、明らかに相手企業には合わないと判断した場合も内定頂けたりして困惑したりしますが。
特に要求されるかに関わらず、私は自身が発表した論文や所有する特許技術を添付して教えておきますし、必要ならコード（github）も添えます。 そして、それを見てくれた上での質問を求めます。そこで質問が出ないような企業では働く価値はありません。私の場合は、回答は求められる以前にホワイトボードやノートPCを用いて説明をしていきます。
既存の技術の問題点を列挙しつつ、それを（過去に）どの様に解決したか、あるいは、（今後に）したいと考えているか、出来ると考えているか、を説明していくことで、アサイン後の可能性も提示できますし、議論の中で先方の能力も分かってきます。
あまりお勧めしません。エージェントの能力が低すぎて技術を理解できない場合、自分が何をアピールしたいか？を企業に伝えられない恐れが出ます。なので、私はかなり詳細にレクチャーした上で書類をチェックして作りこんでもらいました。いい案件をもっているのは確かなので、そこは魅力なんですが、いかんせん手間がおおきい。自分でやる方が話が早いですよ。
近年、自分が面接官を務めるようになって、面接が下手な求職者が多いなと思いました。面接はお見合いの場ですから、自分が企業を見極めて判断しているという視点を持ってない求職者は記憶に残らないし、一緒に仕事できるイメージがもてないものです。互いに一緒に仕事をしたいと考えて終えられるように、訴えるべきこと、知りたいことを整理してから臨んでください。
上手くアピールできたなという手ごたえがある場合には、社長さんなどから「この場で内定受諾してくれる条件は幾らですか？」と聞かれたりします。私は、条件面では下限と上限を設定して提示しますが、時に上限を超えるオファーもあります。このような場合は、お断りするか上限値に収めて頂く事にしています。それ以上の価値を出せる自信がない、という事は素直に伝えたい所です。自分の市場価値をある程度は見極めておくことも大事かなと考えます。
文系の方には参考にならないとのコメントがありました。すみません。確かに、この記事はプログラマの就職活動によっていますが、思うに、文理関係ない所もあるかと思います。私が業務を多少なりとも知っている文系の仕事は技術営業があります。
これまでに自分が売ってきた製品から得た知識、技術的な情報の、今後扱う事になる製品との間の互換性
と言ったことは、伺っておきたい点だと思います。自分がアピール出来る強みが、対象となる企業のどこに符号していて、自分の今後の展開をどう捉えているかを論理的に説明できているかどうかは、文系でも重要な内容ではないかと考えます。経験の深さやアピールポイントの寡多も関係なく、自身の武器と対象の理解が重要と言う事です。あまり参考にならず、恐縮ですが、この点考えて頂けると面接の場が有効に活かせると思います。
面接の技術というよりは、ちゃんとアピールできる引き出しの数が多いからだよ。今面接で困ってる人はこんだけ持ってるものがないから困ってる
http://canisterism.hatenablog.com/entry/2018/09/11/201006
リンクの記事を対象に、古株エンジニアの私ならどうしたか？を考えます。
私の学生時代は当然ですが業務経験などありません。ブログの筆者さんと変わりはないでしょう。そしてある業界で仕事をしたいと考えていたのも共通をしています。私は、その業界の中のどんな製品・技術・仕事に興味があるかを分析しました。その上で、その業務を実行するうえで必要となる基礎技術を勉強して、なおかつ、業界内で今後の可能性がどの様なものになるかを考えたという感じですね。Web系のエンジニアではありませんので、その辺り具体例は出せませんが、流行の技術について学んで、今後の発展性について考えると同時に、研究や勉強で評価できるアウトプットを出すという事です。何かの言語を勉強した、という程度では、継続的に勉強できる努力しか示せていません。自分が何がしたいから、どのような必要性があって、どのような技術を学んだのか？習得したのか？を説明出来た方が良かっただろうという事です。
例を出すと、この増田を書くにも日本語変換に失敗する事があります。第一候補が悪い。これを改善する様な仕事をしたいと考えた時に、個々人の語彙に応じた変換を実現したいと思えたとしましょう。それを実現する一つの方法として、深層学習を勉強して、そういう研究なりアウトプットを出して、今までは未知だった新しいプログラム言語や、コード管理のツールも使ってみたという様なアピールが出来ればいいのです。その人が普段読んでいるWeb上のテキストや書いている文章を学習すれば～という様な目的があって勉強するはずです、Web系の企業に入りたいから言語を学んだというのは弱いです。具体的な社名を使わせて頂くと、ZOZOなんかで個人にマッチする服を提案したい、それが今後のスタートアップトゥデイ（スタートトゥデイの間違いでした。すみません。）の可能性になるのでは？と考えたので機械学習を勉強してきた、という様なアピールはあると思います。（ZOZOさんで服を買わせていただいていますので、ご容赦を）実際に、ZOZOの研究所では、その様な方向に進もうとしている様ですし、伝わるものがあるでしょう。私の専門領域について例を出したくなかったので、薄い知識しか持ってない機械学習を例に出しましたが、分析→出力の過程があれば、経験の少なさは問題にならない事は多少なりとも伝わっているかと。
この場合、学生には実績はありません。自分自身の夢や目標と対象となる企業への分析があり、それにそった努力が出来ているという事です。似た様なアピールで十分以上に伝わるはずです。
余談ですがスタートトゥデイ研究所のカッコいいを分析するミッションというのは面白いでしょうね。イケメン分析の結果、中間顔が最もイケてるという様な研究結果はありますが、ある人にとってカッコいい服をどう捉えるかというのは難しい課題です。何を学習して何を出力するか、というテーマもそうですし、個々人の体形に応じた似合う似合わないという問題もあります。機械学習だけでなく、画像認識やら、形状解析など多岐にわたる知識と技術が必要になるでしょう。そんな風にある人にとってのカッコいい服を表現できるディスクリプタ―なんて聞いたこともないですから、良い論文になるでしょうね。ZOZOさんには期待しています。私は畑違いですが、専門領域が被ってる人は話を聞いてみてもいいんじゃないでしょうか。
今やプログラミングといえば、Webなどで使われるような高水準スクリプト系言語中心のアプリケーションプログラミングが主流だ。
そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である。
そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。
少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。
大学で初めて触ったC言語しかもポインタ分からないで止まっているような奴に、電文の再配信プログラムを任せたのだから。
客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。
このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。
勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。
あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。
コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなものは絶対に必要である。
その時のルールは「gccのオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。
というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様はコンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しかも言語仕様以外の環境依存要素が山積していると来たもんだ。
そんな言語でシステムコールだらけのコードかつ複数のファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかもマルチプロセスでシグナルもあるよ！とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。
仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。
後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。
そこまで凄い良書なのになんで絶版になったんだか。
いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。
シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか！と途方に暮れたこともあった。
そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。
結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分の仕事ぶりには全く満足していない。
無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッド、malloc()、可変長引数は遂に習得できなかった。
こういうプログラムって、どうやったら正しく動かせるんだろ。
このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が
Cはとても高効率ですし、マシンのリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルのリソース管理（たとえばメモリ管理）を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります。今日のマシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシンの時間を少し非効率に使っても、あなたの時間をずっと効率的に使う言語を使うほうが賢明でしょう。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
あと、あれほど苦手だったポインタについても、「ポインタが理解できないと永久にC初心者」というのを嫌でも理解した。
あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ。
・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。
それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件に助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分は
「配列とポインタと構造体しか使わないで済むなんて、なんて楽な仕事なんだ！」と左うちわでのんびり過ごし、しかも高評価をいただいて帰ってこれた。
http://anond.hatelabo.jp/20130104184115
の元増田です。
ひっそりと公開したはずのtag-chat.net(http://tag-chat.net)ですが、
まさか、こんなに反響を頂けるとは思っていなかったので、びっくりしました。
素人のフリをしているとか、出版社のステマだとか色々言われましたが、嘘は一切書いてないです。
ステマというか、ウェブサービス公開後の状況を知っている方からするとマイナスのステマにしかなっていないような気がします…。
公開してから、色々と発見というか気づきがあったので、それを共有できれば幸いです。あと、tag-chat.netの中身についてなど。
・意気揚々と自作SNSを公開したものの、アクセスが全くこなくて途方にくれる。
⇓
・以前、完全に一致を作った増田の方が、増田記事を書いてからアクセスが急に来たと書いてあったので真似して書いてみる。
⇓
・翌日ごろから、アクセスが集中。ビビる。「うちの会社で働きませんか？」と言ったお誘いのメールをたくさん頂く。
いきなりの出来事にパニックになっている間にも増田記事が拡散していき、アクセスが急増する。
⇓
アクセスが爆発する。１時間あたり二万アクセスというアクセスを捌ききれずにサーバーが落ちる。サイトのウリであるが、メモリ使用量
⇓
・その後、サーバーを増強。エラー情報や、寄せて頂いた情報をもとに各種エラー情報や、使い勝手などを改善。
⇓
・現在、安定稼働中。おかげさまで、ユーザー数もゆるやかに増加していて、基本的な機能も正常動作しています。ユーザー数はもうすぐ
１０００人に届きそうでありがたいばかりです。
と、いうわけでなんとかようやく落ち着き、ウリのマッチングチャットも正常に作動しているようなので、後記事を書きます。
■ウェブサービスの公開前に注意すべきだったこと。
①・セキュリティについては書かないほうが良い。色々といじられる。
前回の増田記事で、DoS攻撃の対策などについて語ったのですが、それを確かめるためなのかサイト公開してしばらくしてから、定期的に
Dos攻撃をくらいました。
おかげ様で、ちゃんと一時的にそのIPからのアクセスを遮断することはできたのですが、セキュリティについてあまり大々的しゃべると攻
撃対象となるので、あまり具体的なセキュリティ対策などについてはしゃべらないほうが良いのかな、と感じました。
また、DoS攻撃だけでなくCSRF試したり、色々といたずら（もしくは善意のテスト？）をして下さる方がとても多かったのには驚きました。
はてな民の技術レベルの高さを知りました……。いたずらされている間は本当に怖かったです。
とりあえず、今のところ攻撃は防げているようです。
はじめ、私は調子に乗ってサイト内に英語を多用していたのですが、それがユーザー様にとって混乱のもとになっていたようです。
例えば、他のユーザーから自分の書いた日記などにコメントがついた時に、それを知らせるページがあります。
普通に考えれば「友達からの反応一覧」とか「友人からの反応」とかにすれば良いのですが、何を血迷ったのか「Reaction」と中二病丸出
しで書いてしまったので、ユーザー様がものすごく混乱したようです。
結局、「使いにくい」、「サイト内迷子になる」との声を受けて日本語メニューに変更しました。
③・使い方のページはくどいくらい書いても良かった。
フリーチャットや、マッチングチャットでは、基本的に相手が見つかるまでは「待ち」の状態になります。
相手がすでにこちらを「待っている」状態だとすぐにチャットが始まるのですが、そのことに対する説明が足りなかったようで、チャット
ルームを出たり入ったりしている人が多かったようです。
また、チャットが終了した時にチャット相手にお礼をこめてメッセージを送る機能があるのですが、これも説明不足で上手く使われなかっ
たようです。
とにかく、くどいくらい説明しても良かったと思います。
■ウェブサービスをリリースする前にやっておいて良かったこと。
①・Twitterのアカウントを作りそこから最新情報を流せるようにする。
これは本当に大きかったです。
とつぜんの増田砲で一時間あたり二万アクセス近くのアクセスをさばけずに、サーバーがビジー状態になってしまった時も、Twitterを通
じて現在の状況などを流せたことは非常に大きかったです。
②・エラー情報を送ってもらえるようにメールアドレスを作っておく。
本当にありがたいことに、実際に使ってみた使用感や、こんなエラーが出ていると言った情報を送って下さる方がいます。
一人でテストしていた時には気づかなかったエラーや、不便な点などをわざわざ時間をとってメールで教えてくれるのです。
どこの馬の骨ともわからん怪しい奴が作ったものに登録してくれ、使ってみてくれただけではなく、エラー情報や励ましの言葉を送って下
さるのです。
本当にありがたいことです。
③・それでもわからないエラー情報に対して対処できるようにしておく。
優しいユーザーの方がエラー情報などを教えて下さるのは大変ありがたく、また開発の励みにもなるのですが、それに頼ってばかりいて
はダメです。
サーバーの吐き出すエラー情報を調べて、おかしな挙動にいち早く気づく必要があります。
本当はhttpdのエラーログとか見れば良いんですけど、はっきり言って物凄く見づらいので、ツールを使って毎日「こんなエラーがでました
」と教えてもらうようにしておきました。
色々なツールがあるみたいですが、私はlogwatchを使いました。
・参考URL
http://www.atmarkit.co.jp/flinux/rensai/root04/root04c.html
これでエラーの出ているところだけでも、修正するということをやっていました。
■ ウェブサービスを運営してみてわかったこと。
①・SNSの人の流れにはなんだかよくわからない規則性がある。
tag-chat.net グーグルアナリティクスでどれくらいの人が毎日来ているかをウォッチしているのですが、なぜか月曜日と週末にかけてア
クセスが増えます。
謎です。週末はわかるけれど、どうして月曜日に……？
②・やっぱり非リアの気持ちは非リアじゃないとわからない。
「どうして普通にはてブに書かないのか。なんで増田なのか」とか「非リアを装って」
とかコメントしてる人たちがいたのですが、その人たちは非リアについてなんもわかってないアホだと思いました。
もともと自分で名前なり、アカウントを明かした上ではてブに投稿できるくらいの度胸があれば非リアになんかなってないです。それは自
分でもわかってます。
自己顕示欲が人一倍強いくせに、人に名指しで批判されるのが怖いから増田に投稿したのです。
フェイスブックに実名でウェブサービス作ったことを投稿できるような度胸があればそうしてますし、はてブに書けるなら書いてます。
そうするだけの度胸もなくて、でも誰かに認めては貰いたいから増田に書いたということをわかっていない。
③・ネットのみなさんが優しい。
今までネットの人たちは２ちゃんねるとかで炎上したり、なんか面白そうなものを見つけてお祭り騒ぎする、ちょっと怖い人たちという
イメージだったのですが、それが今回のことでガラリと変わりました。
本当に優しい人が多くて、どこの馬の骨ともわからない奴の作ったウェブサービスを使ってくれるだけでなく、感想や励ましのメールな
どをたくさん頂きました。
遥か雲の上の存在だと思っていた会社の方からもメールなどを頂きました。本当に感謝してもしきれません。
～技術編～
①・nodejsを使って外部にサービス公開するなら、認証は必須。主に不正な負荷を減らすために。
さっき書いた、「セキュリティについてはあまり書くな」という話と矛盾するのですが。
nodejs、すごくアクセスさばけて、なおかつ軽いということで便利なんですが、サーバーなので、基本的にリクエストを受けたら非常に素
直に返事します。
例えば、nodejsとsocket.ioを使って、単純にメッセージをサーバーに送るとして、クライアント側で
のようにすると、サーバーはどこから来たアクセスなのか、とか悪意のあるアクセスなのか？ とか一切気にすることなく、素直に'hoge'
これはつまり、第三者が悪意を持って大量にメッセージを送りつけるとそれを素直に受け取ってしまうということです。
なので、例えば大量に不正なデータを送りつけられたりするとレスポンスが悪くなります。
なので、悪意のあるアクセスはsocketにそもそも接続させない、という対策がサーバー側で必要になると思います。
socket.ioではコールバックを使って、簡単に認証させるかさせないか、という実装ができます。具体的には以下のURLなどを参考に実装す
http://d.hatena.ne.jp/Jxck/20110809/1312847290
②・nodejsの最大接続数は、ファイルディスクリプタに依存する
ということにしばらく気づかずに、最大接続数が４００ほどしか出ず悩んでいた時に以下のURLを参照して、なぞが解けました。
http://blog.livedoor.jp/mokepon/archives/182178.html
またsocket.ioのテストの書き方ですが、
http://d.hatena.ne.jp/toritori0318/20120902/1346591831
という素晴らしいエントリーがあったので参考にさせて頂きました。
■楽できるところは楽するためのツールなど。
nodejsの開発で、面倒くさいところはできるだけ楽しました。以下、便利だったものまとめ。
・node-dev
コンソールにデバッグ情報を吐き出してくれ、サーバー側のコードをいじくった時に自動的に再起動してくれる。
いちいちコマンドプロンプトからnodejsを実行する必要がないため、作業の手間がはぶける。
nodejsを触り始めた時はエラーを吐いてばかりなので非常に役に立ちました。
参考URL
http://d.hatena.ne.jp/replication/20110224/1298474534
・forever
様々な使い方があるようですが、stop,list,startの３つぐらいしか使いませんでした。まだ、研究中です。
参考URL（基本的な使いかたが非常にわかりやすく書かれています）
http://nantekottai.com/2011/08/15/node-js-based-service-with-forever/
・mongoose
ドキュメントは色々ググったのですが、結局公式のドキュメントが１番わかりやすかったです。
～モチベーション編～
■一人でウェブサービスを作る上で、心の支えになった記事。
http://d.hatena.ne.jp/Hamachiya2/20080131/security
とにかく楽しんで、作ってみることが大事だよ、というお話です。すごい勇気づけられます。
・小飼弾さんの産声の話。
http://blog.livedoor.jp/dankogai/archives/51837985.html
弾さんは、お金持ちで、腕は一流で、PHPこき下ろすし、なんかすごく怖い職人のイメージだったのですが、このエントリーを読んで、クソ
まみれでも産声を上げてみようと思えました。
実は優しい人なのかもしれません。私の高校時代の担任の先生にどことなく似ています。
■お詫びと訂正
前回の増田記事で、OpenPNEについて間違った記載をしてしまいました。ソースコード公開に関する記述の部分です。
OpenPNEではそのソースコードを改変したら、そのソースコードを公開しなくてはならないと書いたのですが、これは間違いです。
OpenPNE方々には大変ご迷惑をお掛けしました。申し訳ありませんでした。
あと入家さんに謝りたいです。
フェイスブックにもとりあげて頂いたそうで、ありがとうございます。
怖いのでどんな投稿なのかはまだ観ていませんが、本当にありがたいです。
■最後に。
ウェブサービスをコツコツと作り続けて公開したところ、増田記事のおかげもありたくさんの反響を頂きました。
ただ、別にウェブサービスを公開したからと言って、実際のところ何かが劇的に変わったわけでもないです。
グーグルアドセンスは支払い規定の一万円を超えていないので、手元には一銭も入ってきませんし、実名出して行動できなかったので現実
あいかわらず休日は地元のゲームセンターでレトロゲーをやって時間をつぶしていますし、学校から帰ってきたらももクロのライブを観て
、Chai Maxxを踊ってから寝るだけの毎日です。それでも結構楽しいのですが。
ただ、ネット上で様々な先輩エンジニアの方々や、同年代で同じようにフェイスブックが嫌いな方から励ましのメールをもらいましたし、
本当に、びっくりするような充実した二週間でした。
はてブで人気のエントリーにあがった時のスナップショットは未だに大事にとってあります。
tag-chat.net（http://tag-chat.net)を作って本当に良かったと思っています。
linuxではファイルディスクリプタを使い、例えばソケットやファイルの操作などを行います。その際、あるディスクリプタを他のプロセスに送りたいことがあるかもしれません。ここではその方法を解説します。
ディスクリプタを別プロセスに送信するためには、送受信用のソケットを作成する必要があります。この場合は特に、unix domainのUDPソケットを作成する必要があります。
unix socketとはネットワークを介さずに使えるソケットインターフェースです。接続アドレスはファイル名で指定されます。このためソケットを作った後はそのファイルが作成されます。ただし、送受信データはそのファイルではなくカーネル内のメモリに保存されます。
ソケットはsocketシステムコールにより作成します。その際、第一引数にAF_LOCALを、第二引数にSOCK_DGRAMを指定することで所望のソケットを得ることができます。なお、受信側ソケットの場合は、bindにより受信アドレスを設定する必要があります。
#define UNIX_SOCKET_PATH "/tmp/socket2010" int make_socket(int is_receiver) { // create the unix domain udp socket. int sock = socket(AF_LOCAL, SOCK_DGRAM, 0); if (is_receiver) { struct sockaddr_un addr; // include sys/un.h unlink(UNIX_SOCKET_PATH); memset(&addr, 0, sizeof(addr)); addr.sun_family = AF_LOCAL; strcpy(addr.sun_path, UNIX_SOCKET_PATH); bind(sock, (struct sockaddr *)&addr, sizeof(addr)); } return sock; }
