「ディスクリプタ」を含む日記 RSS

はてなキーワード: ディスクリプタとは

2018-09-12

内定率76%の私が考える面接の必勝パターン追記アリ】

プログラマとして働く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を終えた直後に、「今回、この様なチャンスを頂けたのは、私のどのような点に興味をお持ちいただけたからでしょうか?」と言っておけば、自身の専門領域に関して興味を持ったというような回答が出ますから、やりやすいペースが作れます。「そこに関して自分がどの様な問題解決能力を持っていれば、御社で働くに値するか?をご判断いただける場にしたいです。お願いします。」といったような感じですね。自己PRいか大事ものか?わかっていただけると思います

企業は何か必要があって採用活動をしているのですからベストマッチってものがあります自分ベストマッチであれば互いに幸せになれますが、そうでなければ不幸でしかありませんので、ベストマッチであるかどうかを見極める「お見合い」が面接と考えましょう。

「どういったポジション採用したいのか?」

「欠けていると考えてる技術領域人材とは?」

「社内にはどのような技術が得意な人材が多いのか?」

業務のサイクルはどのようなものか?」

というような事は最低でも抑えておきたいところです。そこに「自分が得意な仕事」「やりたいと考えている事」がマッチするようであれば、お互いにとって幸せな結果になります。私の場合は、明らかに相手企業には合わないと判断した場合内定頂けたりして困惑したりしますが。

技術面接について

特に要求されるかに関わらず、私は自身が発表した論文や所有する特許技術を添付して教えておきますし、必要ならコードgithub)も添えます。 そして、それを見てくれた上での質問を求めます。そこで質問が出ないような企業では働く価値はありません。私の場合は、回答は求められる以前にホワイトボードノートPCを用いて説明をしていきます

既存技術問題点を列挙しつつ、それを(過去に)どの様に解決たか、あるいは、(今後に)したいと考えているか、出来ると考えているか、を説明していくことで、アサイン後の可能性も提示できますし、議論の中で先方の能力も分かってきます

エージェントに関して

まりお勧めしません。エージェント能力が低すぎて技術理解できない場合自分が何をアピールしたいか?を企業に伝えられない恐れが出ます。なので、私はかなり詳細にレクチャーした上で書類をチェックして作りこんでもらいました。いい案件をもっているのは確かなので、そこは魅力なんですが、いかんせん手間がおおきい。自分でやる方が話が早いですよ。

最後

近年、自分面接官を務めるようになって、面接が下手な求職者が多いなと思いました。面接お見合いの場ですから自分企業を見極めて判断しているという視点を持ってない求職者記憶に残らないし、一緒に仕事できるイメージがもてないものです。互いに一緒に仕事をしたいと考えて終えられるように、訴えるべきこと、知りたいことを整理してから臨んでください。

上手くアピールできたなという手ごたえがある場合には、社長さんなどから「この場で内定受諾してくれる条件は幾らですか?」と聞かれたりします。私は、条件面では下限と上限を設定して提示しますが、時に上限を超えるオファーもあります。このような場合は、お断りするか上限値に収めて頂く事にしています。それ以上の価値を出せる自信がない、という事は素直に伝えたい所です。自分市場価値をある程度は見極めておくことも大事かなと考えます

追記理系文系の差

文系の方には参考にならないとのコメントがありました。すみません。確かに、この記事プログラマ就職活動によっていますが、思うに、文理関係ない所もあるかと思います。私が業務を多少なりとも知っている文系仕事技術営業があります

技術営業職であれば

これまでに自分が売ってきた製品から得た知識技術的な情報の、今後扱う事になる製品との間の互換

これまでに関わってきた顧客との関係性や新たな販路可能

と言ったことは、伺っておきたい点だと思います自分アピール出来る強みが、対象となる企業のどこに符号していて、自分の今後の展開をどう捉えているか論理的説明できているかどうかは、文系でも重要な内容ではないかと考えます経験の深さやアピールポイントの寡多も関係なく、自身武器対象理解重要と言う事です。あまり参考にならず、恐縮ですが、この点考えて頂けると面接の場が有効に活かせると思います

追記2:経験値や引き出しのなさを埋めたい

面接技術というよりは、ちゃんアピールできる引き出しの数が多いからだよ。今面接で困ってる人はこんだけ持ってるものがないから困ってる

http://canisterism.hatenablog.com/entry/2018/09/11/201006

リンク記事対象に、古株エンジニアの私ならどうしたか?を考えます

私の学生時代は当然ですが業務経験などありません。ブログの筆者さんと変わりはないでしょう。そしてある業界仕事をしたいと考えていたのも共通をしています。私は、その業界の中のどんな製品技術仕事に興味があるかを分析しました。その上で、その業務を実行するうえで必要となる基礎技術勉強して、なおかつ、業界内で今後の可能性がどの様なものになるかを考えたという感じですね。Web系のエンジニアではありませんので、その辺り具体例は出せませんが、流行技術について学んで、今後の発展性について考えると同時に、研究勉強評価できるアウトプットを出すという事です。何かの言語勉強した、という程度では、継続的勉強できる努力しか示せていません。自分が何がしたいから、どのような必要性があって、どのような技術を学んだのか?習得したのか?を説明出来た方が良かっただろうという事です。


例を出すと、この増田を書くにも日本語変換に失敗する事があります第一候補が悪い。これを改善する様な仕事をしたいと考えた時に、個々人の語彙に応じた変換を実現したいと思えたとしましょう。それを実現する一つの方法として、深層学習勉強して、そういう研究なりアウトプットを出して、今までは未知だった新しいプログラム言語や、コード管理ツールも使ってみたという様なアピールが出来ればいいのです。その人が普段読んでいるWeb上のテキストや書いている文章学習すれば~という様な目的があって勉強するはずです、Web系の企業に入りたいか言語を学んだというのは弱いです。具体的な社名を使わせて頂くと、ZOZOなんかで個人マッチする服を提案したい、それが今後のスタートアップトゥデイスタートトゥデイの間違いでした。すみません。)の可能性になるのでは?と考えたので機械学習勉強してきた、という様なアピールはあると思います。(ZOZOさんで服を買わせていただいていますので、ご容赦を)実際に、ZOZO研究所では、その様な方向に進もうとしている様ですし、伝わるものがあるでしょう。私の専門領域について例を出したくなかったので、薄い知識しか持ってない機械学習を例に出しましたが、分析→出力の過程があれば、経験の少なさは問題にならない事は多少なりとも伝わっているかと。

この場合学生には実績はありません。自分自身の夢や目標対象となる企業への分析があり、それにそった努力が出来ているという事です。似た様なアピールで十分以上に伝わるはずです。

余談ですがスタートトゥデイ研究所のカッコいいを分析するミッションというのは面白いでしょうね。イケメン分析の結果、中間顔が最もイケてるという様な研究結果はありますが、ある人にとってカッコいい服をどう捉えるかというのは難しい課題です。何を学習して何を出力するか、というテーマもそうですし、個々人の体形に応じた似合う似合わないという問題もあります機械学習だけでなく、画像認識やら、形状解析など多岐にわたる知識技術必要になるでしょう。そんな風にある人にとってのカッコいい服を表現できるディスクリプタ―なんて聞いたこともないですから、良い論文になるでしょうね。ZOZOさんには期待しています。私は畑違いですが、専門領域が被ってる人は話を聞いてみてもいいんじゃないでしょうか。

2015-01-29

初めてじゃなかったCの思い出

今やプログラミングといえば、Webなどで使われるような高水スクリプト言語中心のアプリケーションプログラミングが主流だ。

そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である

そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。


今も昔も、基本的に難しい仕事無茶振りから始まるものだ。

少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。

大学で初めて触ったC言語しかポインタからないで止まっているような奴に、電文の再配信プログラムを任せたのだから


客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。

そうなるとC/C++くらいしか事実上選択肢がない。

このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。

勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。

あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。

その時点で相当ヤバいである


コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなもの絶対必要である

その時のルールは「gccオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。

というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様コンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しか言語仕様以外の環境依存要素が山積していると来たもんだ。

そんな言語システムコールだらけのコードかつ複数ファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかマルチプロセスシグナルもあるよ!とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。

仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。

後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。

そこまで凄い良書なのになんで絶版になったんだか。


いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。

シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか!と途方に暮れたこともあった。

そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。

結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分仕事ぶりには全く満足していない。

無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッドmalloc()、可変長引数は遂に習得できなかった。

こういうプログラムって、どうやったら正しく動かせるんだろ。


このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が

Cはとても高効率ですし、マシンリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルリソース管理(たとえばメモリ管理)を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります今日マシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシン時間を少し非効率に使っても、あなた時間をずっと効率的に使う言語を使うほうが賢明でしょう。

本物のプログラマアプリケーションプログラムなど書かず、まっさら金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。

と言っていたことは正真正銘の事実であると痛感した。

あと、あれほど苦手だったポインタについても、「ポインタ理解できないと永久にC初心者」というのを嫌でも理解した。

あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ


・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。

それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分

配列ポインタ構造しか使わないで済むなんて、なんて楽な仕事なんだ!」と左うちわのんびり過ごし、しかも高評価をいただいて帰ってこれた。

実は今までの案件で一番幸福感が最高だったのは内緒である

2013-01-18

素人が完全自作SNSを二週間運営してみてわかったこと(後始末編、技術編、モチベーション編)


素人が完全自作SNSを作ってみてわかったこと。

http://anond.hatelabo.jp/20130104184115

元増田です。

ひっそりと公開したはずのtag-chat.net(http://tag-chat.net)ですが、

まさか、こんなに反響を頂けるとは思っていなかったので、びっくりしました。

素人のフリをしているとか、出版社ステマだとか色々言われましたが、嘘は一切書いてないです。

ステマというか、ウェブサービス公開後の状況を知っている方からするとマイナスステマしかなっていないような気がします…。

公開してから、色々と発見というか気づきがあったので、それを共有できれば幸いです。あと、tag-chat.netの中身についてなど。



増田記事を公開してから今までの経過~

・意気揚々と自作SNSを公開したものの、アクセスが全くこなくて途方にくれる。

             ⇓

・以前、完全に一致を作った増田の方が、増田記事を書いてからアクセスが急に来たと書いてあったので真似して書いてみる。

             ⇓

・翌日ごろからアクセスが集中。ビビる。「うちの会社で働きませんか?」と言ったお誘いのメールをたくさん頂く。

いきなりの出来事にパニックになっている間にも増田記事が拡散していき、アクセスが急増する。

             

             ⇓

アクセスが爆発する。1時間あたり二万アクセスというアクセスを捌ききれずにサーバーが落ちる。サイトのウリであるが、メモリ使用量

が最も高いマッチングチャットを一時使用停止にする。

             

             ⇓

・その後、サーバーを増強。エラー情報や、寄せて頂いた情報をもとに各種エラー情報や、使い勝手などを改善

             

             ⇓

現在、安定稼働中。おかげさまで、ユーザー数もゆるやかに増加していて、基本的な機能も正常動作していますユーザー数はもうすぐ

1000人に届きそうでありがたいばかりです。


と、いうわけでなんとかようやく落ち着き、ウリのマッチングチャットも正常に作動しているようなので、後記事を書きます





~後始末編(Webサービスを実際に運用してみて)~

ウェブサービスの公開前に注意すべきだったこと。

①・セキュリティについては書かないほうが良い。色々といじられる。

前回の増田記事で、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 グーグルアナリティクスでどれくらいの人が毎日来ているかをウォッチしているのですが、なぜか月曜日と週末にかけてア

クセスが増えます

謎です。週末はわかるけれど、どうして月曜日に……?



②・やっぱり非リアの気持ちは非リアじゃないとわからない。

前回の増田記事に対するコメントネットの反応などで、

「どうして普通にはてブに書かないのか。なんで増田なのか」とか「非リアを装って」

とかコメントしてる人たちがいたのですが、その人たちは非リアについてなんもわかってないアホだと思いました。


もともと自分名前なり、アカウントを明かした上ではてブ投稿できるくらいの度胸があれば非リアになんかなってないです。それは自

分でもわかってます

自己顕示欲人一倍強いくせに、人に名指しで批判されるのが怖いか増田投稿したのです。



フェイスブック実名ウェブサービス作ったことを投稿できるような度胸があればそうしてますし、はてブに書けるなら書いてます

そうするだけの度胸もなくて、でも誰かに認めては貰いたいか増田に書いたということをわかっていない。


③・ネットのみなさんが優しい。

 今までネットの人たちは2ちゃんねるとかで炎上したり、なんか面白そうなものを見つけてお祭り騒ぎする、ちょっと怖い人たちという

イメージだったのですが、それが今回のことでガラリと変わりました。

 本当に優しい人が多くて、どこの馬の骨ともわからない奴の作ったウェブサービスを使ってくれるだけでなく、感想や励ましのメール

どをたくさん頂きました。

 遥か雲の上の存在だと思っていた会社の方からメールなどを頂きました。本当に感謝してもしきれません。

 





技術編~

Tagchatの技術的なこと。

①・nodejsを使って外部にサービス公開するなら、認証必須。主に不正な負荷を減らすために。


さっき書いた、「セキュリティについてはあまり書くな」という話と矛盾するのですが。

nodejsでのセキュリティの話です。

nodejs、すごくアクセスさばけて、なおかつ軽いということで便利なんですが、サーバーなので、基本的にリクエストを受けたら非常に素

直に返事します。

例えば、nodejsとsocket.ioを使って、単純にメッセージサーバーに送るとして、クライアント側で

socket.emit('hoge','hoge');

のようにすると、サーバーはどこから来たアクセスなのか、とか悪意のあるアクセスなのか? とか一切気にすることなく、素直に'hoge'

というメッセージを受けます

これはつまり、第三者が悪意を持って大量にメッセージを送りつけるとそれを素直に受け取ってしまうということです。

なので、例えば大量に不正データを送りつけられたりするとレスポンスが悪くなります

なので、悪意のあるアクセスはsocketにそもそも接続させない、という対策がサーバー側で必要になると思います

socket.ioではコールバックを使って、簡単に認証させるかさせないか、という実装ができます。具体的には以下のURLなどを参考に実装す

ればいいかと思います

http://d.hatena.ne.jp/Jxck/20110809/1312847290



②・nodejsの最大接続数は、ファイルディスクリプタ依存する

ということにしばらく気づかずに、最大接続数が400ほどしか出ず悩んでいた時に以下の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

nodeのプロセスデーモン化してくれる便利ツール。

様々な使い方があるようですが、stop,list,startの3つぐらいしか使いませんでした。まだ、研究中です。

参考URL(基本的な使いかたが非常にわかやすく書かれています

http://nantekottai.com/2011/08/15/node-js-based-service-with-forever/


・mongoose

nodejsからmongoDBを扱うのに最適。

ドキュメントは色々ググったのですが、結局公式のドキュメントが1番わかりやすかったです。

http://mongoosejs.com/







モチベーション編~

■一人でウェブサービスを作る上で、心の支えになった記事。

はまちちゃんさんの、「セキュリティ過敏症の話」。

http://d.hatena.ne.jp/Hamachiya2/20080131/security

とにかく楽しんで、作ってみることが大事だよ、というお話です。すごい勇気づけられます


小飼弾さんの産声の話。

http://blog.livedoor.jp/dankogai/archives/51837985.html

弾さんは、お金持ちで、腕は一流で、PHPこき下ろすし、なんかすごく怖い職人イメージだったのですが、このエントリーを読んで、クソ

まみれでも産声を上げてみようと思えました。

実は優しい人なのかもしれません。私の高校時代担任先生にどことなく似ています

 





■お詫びと訂正

前回の増田記事で、OpenPNEについて間違った記載をしてしまいました。ソースコード公開に関する記述の部分です。

OpenPNEではそのソースコードを改変したら、そのソースコードを公開しなくてはならないと書いたのですが、これは間違いです。

OpenPNE方々には大変ご迷惑をお掛けしました。申し訳ありませんでした。




あと入家さんに謝りたいです。

勘違いサブカル野郎とか言ってすいませんでした。

フェイスブックにもとりあげて頂いたそうで、ありがとうございます

怖いのでどんな投稿なのかはまだ観ていませんが、本当にありがたいです。







最後に。

ウェブサービスをコツコツと作り続けて公開したところ、増田記事のおかげもありたくさんの反響を頂きました。


ただ、別にウェブサービスを公開したからと言って、実際のところ何かが劇的に変わったわけでもないです。


グーグルアドセンスは支払い規定の一万円を超えていないので、手元には一銭も入ってきませんし、実名出して行動できなかったので現実

ではほとんど反響はなかったです。

あいかわらず休日地元ゲームセンターレトロゲーをやって時間をつぶしていますし、学校から帰ってきたらももクロライブを観て

Chai Maxxを踊ってから寝るだけの毎日です。それでも結構楽しいのですが。

ただ、ネット上で様々な先輩エンジニアの方々や、同年代で同じようにフェイスブックが嫌いな方から励ましのメールをもらいましたし、

本当に、びっくりするような充実した二週間でした。

はてブで人気のエントリーにあがった時のスナップショットは未だに大事にとってあります

tag-chat.nethttp://tag-chat.net)を作って本当に良かったと思っています

2010-07-26

linuxプロセスファイルディスクリプタを送る方法

linuxではファイルディスクリプタを使い、例えばソケットやファイルの操作などを行います。その際、あるディスクリプタを他のプロセスに送りたいことがあるかもしれません。ここではその方法を解説します。

方法

  1. ディスクリプタ送受信用のソケットを、それぞれのプロセス作成
  2. ソケットの補助データ(後述)を送るための、msghdr構造体を用意
  3. 実際に送信し、別プロセス側で受信する
1, ディスクリプタ送受信用のソケットを、それぞれのプロセス作成

ディスクリプタを別プロセスに送信するためには、送受信用のソケットを作成する必要があります。この場合は特に、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;
}
 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん