Rubyを書いていると、サーバを書きたくなることがあります。皆さんもそうだと思います。 ということで今日はRubyでスッとサーバを書くためのgem、serverengineの簡単な使い方メモ。 github.com Rubyでサーバを書きたくなった時 そもそも的に、Rubyでただサーバを書くのは非常に簡単である。具体的には Kernel#loop などを回してその中でリクエストを待ったり、何かしら処理を行えば終わり。特別なgemは必要ないし、TCPを扱うクラスなども組み込みで用意されている。 以下のような9行のスクリプトを起動すれば、サーバを書いたと言える。ところで TCPServer#accept_nonblockでないと、acceptでブロックしてしまって終了処理が遅れたりするのでノンブロッキングの方のAPIを好んで使うのがいいだろう。 require 'socket' server

www.digitalfukuoka.jp 去年より開発している、mrubyでコントロールできるLinuxコンテナランタイム Haconiwa で、第9回フクオカRuby大賞・県知事賞をいただきました。 写真は受賞決定直後の様子です。 今日の福岡Ruby大賞で @udzura さんが大賞で100万円とったという速報とともに送られてきた写真見て「うづらさん怒られてるの？」ってslackに書いた自分の書き込みがツボって仕事にならなかった。おめでとうございます！ #udzura_sushi pic.twitter.com/7zGKUyvj5K— 松本 亮介 / まつもとりー (@matsumotory) 2017年3月1日 Haconiwaの開発にあたって 去年の振り返り で書いた気もするんですが、そもそもの大きなきっかけとして福岡開催された 第9回 コンテナ型仮想化の情報交換会＠福岡 の存在が

読みきった。一周目の所感を書く。 Linuxプログラミングインタフェース 作者: Michael Kerrisk,千住治郎出版社/メーカー: オライリージャパン発売日: 2012/12/01メディア: 大型本 クリック: 14回この商品を含むブログ (7件) を見る モチベーション ぼくは、小さい会社でWebサービスの開発もしつつLinuxのサバ管も少ししつつ、という人間だったので、Linuxに開眼して真髄を会得したい、という欲求が長らくあった。例えば青木さんの本であったり、なるほどUnixであったり。 ふつうのLinuxプログラミング Linuxの仕組みから学べるgccプログラミングの王道 作者: 青木峰郎出版社/メーカー: ソフトバンククリエイティブ発売日: 2005/07/27メディア: 単行本購入: 35人 クリック: 450回この商品を含むブログ (150件) を見る tatsu

RubyWorld Conference 2015 話しました。 Ruby way-openstack.keynote from Uchio Kondo www.slideshare.net 111枚、なんとか収まりましたと言いつつ後半は早口... 書いてある通り、OpenStack Ruby Wrapper "YAO" と、その周りのツールたちとで、まずはペパボ周りの人たちのためのOpenStackエコシステムをOSSで作ってるみたいな話です。 github.com バージョンも地道に 0.2.1 となり、対応APIも増えてきました。ロゴも、5人いるカレー四天王の一人 id:Horaotoko によるものを採用し、何だか勢いが出てきた感じします。 horaotoko.hatenablog.jp この分野でセカンドシーズンをやり始めている経緯はスライドに書いてある通りです。ぜひご利用くださ

個人的には三つの基準があるという話。 そのソフトウェアが十分に古く、十分長い間保守されていないか そのソフトウェアを触れる人間が組織内に少なく、増やす手だても困難であるか そのソフトウェアで実現できることが、他の新しいソフトウェアでより容易に実現できるかどうか 1. についてはそうだろう、という感じだと思う。というかリプレイスの前提になると思う。バージョンが古いソフトウェアを使い続けると、脆弱性も出てくるし、一般的には開発の速度も低下する。 ただ、ここで重要なのは、2.や3.との兼ね合いかなと思っている。 例えば2.が1.より優先される場面というのもあるだろう。Hoge言語で作ったミドルウェアの保守について以下のような状況にあるとする。 開発者が退職してしまった Hoge言語に関するドキュメントが全然なくて学習が困難 という感じであればリプレースは検討に入れていいかもしれない。 しかし、こ

http://ppworks.hatenablog.jp/entry/2015/02/19/223552 ほぼほぼ同意なのですが、フームと思って（ppworksさんプロダクトだから、ということでもないが）ポエムをしたためた。 でもなんかこれをあえてポエムにとどめないで書いたらどういう反応があるかな〜と思ったのでブログにも転載してみよう。 規約縛りの哲学 これは文句なくその通りだと思っていて、Rails以外のフレームワークではこれらの実現が非常に中途半端であると言う印象を持っている。 サービス作りにおいて技術選定やら何やらからの議論をしていてはリリースは当然遅くなるし、あまりしたくないということである。議論するならもっとユーザに近い、正体のよく分からない不安点（このアプリほんとにユーザに受けるの？ とか）に関してすべき。 議論は一般的に良いことのように思われているが凄い体力を使うし、本当に必

当該の件夜中に色々考えたら ロードマップ指向とエコシステム指向 - アンカテ という話である程度説明できるんかな〜と思った。で、求めてるものが違うんで議論にならないのも仕方ないな〜と言う。 なんかまあ、まず普通に 結局ちゃんと知識を持っている人がいるフレームワークを選んで保守して行くという話で、Railsな人がいればRails、Springな人がいればSpringでいいのでは。どっちかと言うと自分で選んでコミュニティに貢献して寿命延ばすみたいなほうが前向きでいいと思う— Uchio KONDO (@udzura) 2014, 8月 26 と思っていて、 その上で、Ruby on Railsは代表的なエコシステム型FLOSSなので、フレームワークとかに求めているのがただ便利とか、ただ堅牢とかだとそもそもずれが生じるよなあって思う。一時的ならともかくずっと付き合って行く前提ならなおさら。 Ra

雇用流動情報の季節ですが、いかがお過ごしでしょうか。雇用流動と間接的に関係のある記事を書きます。 標記の通り、研修をしていたのでその内容をまとめたり振り返ったりする。 思ったより長くなったぞ... 背景とか がっつりとしたWeb開発の経験は無いが、情熱があり、コミュニケーション能力など基本的な能力が高そうな、年齢の若い方が応募されたので、いわゆる「第二新卒」と言う扱いで研修を前提に採用した。で、その研修のカリキュラムを主にぼくが考えて実施していた。 といっても、今までに積み上げてきた新卒向け研修のカリキュラムやノウハウを眺めてエッセンスを抜き出すみたいな感じだった。 ペパボ新卒デザイナーとエンジニアの研修ブログ ペパボ新卒エンジニアの研修を開始している - HsbtDiary(2013-05-22) ペパボ新卒エンジニア研修 前編 | blog: takahiro okumura ペパボ新

エクスキューズとか 正直な話をすると、Webフレームワーク自体に関する興味は以前に比べて失われてきているので、最新のSinatraの細かいコミットまでは追っていない。 だが、2年強ほど Sinatra/Padrino 界隈を追いかけてきて得た知見と言うか考えについてまとめるのは一定の価値がある、少なくとも自分に取っての価値は非常に大きいと思うのでここに書いていきたい。 副次的には、ミスコンセプトによってSinatraを利用して、結果必要の無いイメージの悪化を招く事態を一件でも減らせればと思う。 Sinatraはmicroframework、あるいは「フレームワークではない」 公式の説明にある通りである。 具体的にどういうことかと言うと、Sinatra単体ではウェブサービスに必要な要件を満たさないかもしれないと言う話である。Sinatraが持っていないものについては、Sinatra以外の場所

休みの日はあまり真剣なインターネットをしない（そういう意味では今回の週末は反省した方が良い）のだけれど、流れてくる情報はキャッチしときたい。 試みに気になるリンクをPocketに突っ込んで、平日に確認すると言う運用を取ったら、結果的に20くらいになったので、そこそこ捗る感じがする。 はてブでも良いけど、内容を見て微妙なものをはてブしてしまうのも微妙（シテオク）だし、Pocketで一枚噛ませた方が良さそう。 これで休日のインターネッティングにも役割が生まれた訳だけど、あまりやりすぎないようにしよ... それにしても、こういうリンクとかを外部サービスに飛ばしたい時はIntentと言う仕組みは便利っぽい。一部iOSにも取り込まれてるようだけど（Twitterアプリとの連携はある）、facebookのリンクをPocketに飛ばす時が若干だるいのでいつかなんとかなると良いな~ 追記 http://t

「家とその設計図」とか、「タイ焼きとその型」とかってやっぱり誤解のあるたとえだと思っていて、 辞書に載っているような「猫」の概念が猫クラス 実際に街中にいる、生きて動いている猫たちが猫インスタンス だと思っているんだけれど（シニフィアンとシニフィエみたいな）、オブジェットシコウの本をちゃんと読んでいないのでパーマリンク付きのポエムとしてここに書くに止めます...。 クラスはクラス、インスタンスはインスタンスと言うことだと思うので、なんか学習者の皆さんは頑張ってほしい。頑張れちょう頑張れ！

標題の通り本が出て、それに関わっています。 まずは、共著者諸氏の記事その他をご参照ください。 パーフェクトなRailsの本を書きました - joker1007の日記 パーフェクト Ruby on Rails という本を書きました - willnet.in Twitter / Search - #sugamasao_sushi 本の売りとか willnetさんとjokerさんのエントリの通りなんですが、Rails 4.1に滑り込みで対応したことはあります。あと何より、敢えて内容に「現場っぽい、仕事でずっと使っていたエンジニアの観点っぽい」バイアスを掛けているところだと思います。 個人的には、今まで書籍という形では取りこぼしていたようなRailsのフィーチャーの説明とか、中盤、ある程度きっちりしたアプリの設計、コーディング、テスト、サーバのプロビジョニング、デプロイ、監視設定までを一気通貫でや

「プロジェクト全体のMLにエラー通知メール飛ばすのうざい」、「〜についてはみんながいるチャンネルで相談すべきことではない」みたいな指摘がある。 個人的には情報は可能な限り広いスコープで公開してほしいし、自分でもそうしようとしている。まだ未熟なので霊力に負けることもあります...。 というのも、「情報が届いていない」ことによる不利は仕事上非常に大きいし、場合によって致命的になるので、むしろ冗長化して届けられているべきなのである。 あと、情報が多ければ多いほど普通は判断が適切になると思うので、情報が広く共有されていると言うことは、チームメンバー一人一人が自分で判断できる材料を持ちやすくなると言うことにもつながる。スクラムとか色々言われているけど「一人一人が自分で判断できる」ということはどういう開発スタイルでも大事だと思う。 なのでむしろみんながいる場で議論していたり、細かい情報をどんどん流して

闇 Advent Calendar 2013では、青臭い話もネガティブな話もして良いそうなので、これから小説を書きたいと思います。 ぼくはプログラマなのだが、ぼくの仕事の考えの真ん中にあるのは、実は技術的なエッジに触れているとか、あるいは給与がいいだとか、そういうことは結構どうでも良くて、たとえば孤独なチームメイトを作らないとか、業務知識を一人で抱え込むのを辞めさせるとか、一人一人に当事者意識を持ってもらうとか、そんな青臭いけど単純なことである。 ただのスクラムの影響、言われればそれまでだが、その根底にあるのは「過去の自分を救いたい」と言う感情だと思っているし、この考えの根底が作られた当時はスクラムの本なんかろくに読んでいなかった。 過去、とある会社に所属していたとき、辞めるまでの後半の1年ほどは本当に辛くて、入社して2年ほどしかたっていないぼくが、2000年代の初めだかに誕生したレガシー

B社時代 たまにひとに言ってるんだけどぼくは元々新卒の頃マスコミばかり受けていて、最初のキャリアは新聞社で始まった。ただし社内SE。 当時のジョーシ氏は技術畑の人では無かった（むろんLinux、RDBの知識などは当時のぼくが敵わないレベルには勉強していた）のだけれど、今でも割と影響を受けていて、なんか「人にフォーカスする」みたいなことを盗んだような気がしている。今でもチームや他部署の人を観察するのとか、人間関係も基本的にP2Pでつくる癖があるんだけどこの辺の動きが影響を受けている。 「人にフォーカスする」はぼくのプログラマとしての働き方の根底にある気がする。ルビーコミュニティーの影響もあると思うけど多分当時のジョーシの影響の方が強い気がするな、と最近久しぶりに呑んで思った。 F社時代 自分の未熟さ故に自分の思ったモノ作りはできていなかったかもしれない。学んだこととしては主に3つあった。 ひ

と言うことで paperboy&co. に入社しています。 技術基盤グループのエンジニアとして働いていますが、今後はロースおじさんの中の人ポジションを狙ってがんばろうと思います。 それから、11月下旬より福岡支社勤務となります予定です。つまり生活の基盤を福岡市近辺に移します。特に福岡周辺のエンジニアやWeb系の方々、よろしくお願いいたします。仲良くしてください。 ではまた！ （TODO: ナイスな画像を探す）

10月18日付で株式会社Aimingを退社しました。 お世話になりました。およそ1年半ほどでしたが、すごく楽しかったです！ 今後のことなど詳しくはまたいずれ！

俺聞け6 in Tokyo と言うイヴェントに行ってきたのでシェアします。発表もしてきて、なんだかんだAimingで最近やってるような感じの内容を紹介しました。 クラスタがかぶらない気がしていたのですが、結局けっこう知り合いがいたのでボッチは回避できました...。 皆さん発表が上手だったのでぼくは壇上でビールを飲む他なかったです。先駆者のsendさんありがとうございました。 実はこういうテクニカルじゃない会合に行くことがほとんどなかったので、新鮮で楽しかったです。機会をくださったmsngさんに感謝。 GitHub とデザイナーさん、プランナーさんについて 社内でこの内容を再演したところ「この発表ではまだデザイナーやプランナーがGitHubを使うメリットが分かりにくい」と言われたりもしたのでもう少し具体的にフローを説明すると、 プランナさんがマスタデータをいじる→プログラマが足りないところを

今後役立つ日も来るかもしれないのでメモしておく。Rubyist寄り。 CSに全く興味がない人はきつい 計算機に関する学科を出ていなければ門戸を開かないと言うのは、人不足の現実から言っても厳しいだろうが、我々の用いる道具に関する最低限の足腰は欲しい。 エラストテネスの篩を説明できるとか クイックソートの計算量のオーダは何で、それはなぜか説明できるとか サブネットマスクとは何かを説明できるとか 簡単な帳票を見せて、それをすらすら正規化できるとか 別に「たまたま知らない」とかはあり得るんだが、ポロポロ欠けていると、それまでの勉強の仕方を疑わざるを得ない感じがする。 とはいえ、Rubyistならウェッブ系と言うかサーバ寄りだろうからRDBやネットワークの知識はある場合が多い気もする（経験上身に付きやすいですよね）。でも、ぼくも割とアルゴリズムを勉強してるとかは大事だと思う。単純にいろいろな技術的ド