タグ

ブックマーク / nekogata.hatenablog.com (30)

  • 日本一わかりやすい Akka の IOManager と SocketHandle(やServerHandle)、それに IO.Iteratee と IO.IterateeRef - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    ちょっとこのあたりが複雑に感じたので、一度整理しておく。まぁ全部「公式読めば書いてあるよ」で OK なんだけど、それではあまりにマッチョすぎるしわたしがあとから参照したいしみたいな感じ。 IOManager とはなにか Akka でIOを扱うときには、 IOManager を通じて行うと良い。実際の IO の煩わしいことを隠蔽してくれる。IOManager は IOManagerActor というアクターへのリファレンスであり、実際にActしてくれるのは IOManagerActor のようだ。IOManager は手動で止めたりする必要はなく、管理する IO が無くなれば勝手に止まってくれるらしい。賢い。 IOManager を通じてソケットを作るには、IOManager#connect や IOManager#listen を呼び出す。それぞれ SocketHandle や Serve

    日本一わかりやすい Akka の IOManager と SocketHandle(やServerHandle)、それに IO.Iteratee と IO.IterateeRef - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • Scala + akka で簡単なチャットサーバーを書いてみたので解説してみるよ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    !!!CAUTION!!! この記事で扱っている IO のインターフェイスは Akka 2.2 で すでに old-io 扱いとなり( http://doc.akka.io/docs/akka/2.2.0/scala/io-old.html )、Akka 2.3 からは削除されてしまっています。 今ならばこちらを参考にされたほうがいいでしょう。 I/O まわり: http://doc.akka.io/docs/akka/2.3.7/scala/io.html TCPのハンドリング:http://doc.akka.io/docs/akka/2.3.7/scala/io-tcp.html 文 akka というのは Scala で Actor モデルを実現するためのライブラリだと思えばいいっぽい。この記事を読むためには case class とパターンマッチとアクターモデルについての知識が最低

    Scala + akka で簡単なチャットサーバーを書いてみたので解説してみるよ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • process-book、ePub と pdf 出た - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    https://github.com/Shinpeim/process-book/blob/master/release/ ここです。 @moznion が Rakefile 書いてくれたからそれまるっと使ってる。@moznion ++。 pr 送ってくれて、それが merge された場合(というかリポジトリのコミットログに名前が含まれる場合)、ePub の表紙に「contributors」として名前が記載される仕組みになってるので、どんどん pull req ください。 OSSのように、こういうドキュメントの類いもオープンになってればコミュニティに貢献できる感じして良いなって思ってる。 追記 mitukiii のひとが pdf も作ってくれたからpdfも出来た、mitukiii ++

    process-book、ePub と pdf 出た - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
    kazuph1986
    kazuph1986 2013/03/27
    プロセス本が無料公開されている!
  • *nixのプロセスまわりについて書いてたやつがついに書き終わった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    プロセスさん最終回書いた。 最終回: https://gist.github.com/Shinpeim/5205353 目次: https://gist.github.com/Shinpeim/4736099 第一回を書き始めたときには、もっとさらっと書けるだろうと思ってたんだけど書いてみたらいろいろ書くべきことがあって、なんだかかなり辛い量の文章書いてしまった。最後のほうとかもう書くのがかなりしんどかったんだけど、プロセス周りの話はだいぶ網羅できたんじゃないかなって思う。 小出しに書いてる間、はげましのブクマとかはげましのスターとか付けてくれたひとがいたから書けたし、「おもしろい」って言ってくれたり「わかりやすい」って言ってくれたひとたち当にありがとうございました。あなたがいなければプロセスさんは存在しなかった。 なんか噂によると Working with Unix Processes

    *nixのプロセスまわりについて書いてたやつがついに書き終わった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • 「プロならこれくらいできてあたりまえ」のはなし - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    ビルドの時間にこれ書いてる。なんかとりとめなく書く。 プログラマーとか、デザイナーとかもそうだとおもうんだけど、技術がモノを言う系の職業をやってるひとたちって「プロとしてこれくらいはできてあたりまえ、できないやつはダメ」みたいなことを言いがちな感じするし、わたしもついつい言ってしまうことがあるんだけど、こういうのあまり良いことではないよねっていうかダサい感じがする。 というのも、「プロとしてこれくらいはできてあたりまえ、できないやつはクソ」みたいなことを言うひとたちって、けっこう「自分ができること」を「これくらいはできてあたりまえ」って言うんだけど、自分ができないことを「これくらいはできてあたりまえ」って言わないので、なんというか安全地帯からの dis みたいなことやってる感じするんですよね。「セーフ」の側に自分(あるいはその周辺のひとたち)を置いてその下をすべて「アウト」とするみたいな感

    「プロならこれくらいできてあたりまえ」のはなし - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • 後方互換性についてさいきん考えていることを書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    後方互換性を守るべきブロダクトと、そこまで気にしなくていいプロダクトがあると思っている。 後方互換性を守るべきもの これはもうシンプルで、「依存関係の下のほうにあるプロダクト」。下のレイヤーを担うことを狙っているものについては後方互換性を守って行かないとみんなが困る。多くのライブラリがすでに依存してるライブラリとか、あとはまあデータフォーマットとかも変わるとそもそも溜め込んだデータとかが使えなくなったりするので困る。 Perl5 が後方互換性を保つことに熱心なのは、そもそも Perl がシステムツールによく使われていることと無関係ではないはずだ。system perlのversion上げたらシステム動かなくなりましたみたいなことになったら困るからかなり気を使ってる。その点、Python が 2 系から 3 系に移行するときにばっさりと後方互換を捨ててしまったのは失敗だったんじゃないかなと私

    後方互換性についてさいきん考えていることを書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • 状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない?横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になりになり死

    状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
    kazuph1986
    kazuph1986 2013/02/10
    すっと頭に入って来た。わかりやすい。
  • 適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    適切に抽象化されたコードを書く、というのはまさに言うは易し行うは難しだ。 最近私が心がけていることのうちのひとつに、「未来を予測しない」というのがあって、「ここはあとから変更とか追加があるかもしれない」と思って抽象化しておくみたいなことはやめようと思ってる。ひとことで言うと、よくYAGNIとか言われるアレです。 そもそも、なんのために抽象化するのかというということを考えると、ひとつは「一塊の手続きに名前を付けて隠蔽して外から中を意識しないで済むようにする」ってことと、その副産物として「交換可能性が高まる」っていうのがある。 抽象化して実装を隠蔽することで、 コードが理解しやすくなる インターフェイスさえ合ってれば交換可能な部品として扱えるようになる という利点があるから、わたしたちは抽象化を行うわけだ(だからこそ「名前重要」なわけですね)。 この後者の利点に注目すると、ついつい「あっあとか

    適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
    kazuph1986
    kazuph1986 2013/01/29
    なんかノーフリーランチ定理を思い出した。
  • Niigata.pmが正式にpm.orgに登録されました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    これまで居酒屋LTやtech talkを行って来たNiigata.pmですが、実は今までは正式にpm.orgに登録されていませんでした。 しかし、イベントなどを繰り返すごとに参加してくださる人や認知してくださる人が増えてきて、これはそろそろ正式にpm.orgに登録するべきだな、と思ったので、ちょっと前にpm.orgに申請を出し、先日無事にその申請が通りました。 公式サイト:Niigata.pm公式サイト ML:Niigata.pm メーリングリスト IRC:#niigatapm@irc.freenode.net 今後は今まで以上に活発に飲み会や勉強会を開催していきたいと思っておりますので、みなさん、今後ともよろしくお願いします。 とりあえず5 or 6月に飲み会 or tech talkやりたいです。日程の調整は #niigatapm@irc.freenode.netにて!なるべく考慮しま

    Niigata.pmが正式にpm.orgに登録されました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • よけいなプライドは捨てたほうがいいという話について書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    雑文を書く。 ぼくはどちらかとプライドが高いほうで、単なる趣味であるところの音楽でも「下手なところは見せられない」とか、「アレを聴いてないことが恥ずかしい」みたいな気持ちを強く持ってる。なんというか、「下手なところを見せたら舐められるんじゃないか」とか「アレを聴いてないとバカにされるんじゃないか」みたいなふうに感じてしまう。 で、こういう話をしてるとよく、「プライドを捨てよ、そして楽になるがよい」みたいなことを言う人間がどこからともなく現れてOSEKKYOを始めたりするのだけれど、そういうのに対しても結構大きな違和感を持っている。こういう「舐められたくない」みたいな気持ちがないと、クオリティの低いものばかり作り出す邪悪な人間になってしまうし、プライドがあるからスキル上がって行くみたいなところはあると思う。 一方で、こういうプライドがじゃまになることもたしかにあって、馬鹿にされるのが嫌だから

    よけいなプライドは捨てたほうがいいという話について書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く