実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
LLユーザこそ「ふつうのLinuxプログラミング」を読んだらいいという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
4年くらいまえに一度通読して「ふーん」で終わってたんだけど、最近読み返したら「これはめっちゃ良い本では？」となったので紹介します。 ふつうのLinuxプログラミング Linuxの仕組みから学べるgccプログラミングの王道 作者: 青木峰郎出版社/メーカー: ソフトバンククリエイティブ発売日: 2005/07/27メディア: 単行本購入: 35人 クリック: 450回この商品を含むブログ (146件) を見る 特に第二部、第三部がめっちゃよくて、Linuxの重要な概念を、押さえるべきところを押さえて説明してあって最高な感じでした。 サブタイトルにこそ「Linux の仕組みから学べる gcc プログラミングの王道」とありますが、むしろ普段から C 言語でシステムコールに近い部分を普通に書いているプログラマよりも、普段は Perl や Ruby などのスクリプト言語を使っているが、その言語で書か
読み取り権限がなく実行権限だけのファイルが実行できるのはなぜ？ - カーネルのソースを読む - - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
きっかけはこのツイート。 基礎的なことなんだろうけど理解できてないこと。 読み取り権限のない実行権限だけのファイルってどういう扱いになるんだろう。— ゑぬぽい改@電探が出（ん）たん？ (@NPoi) March 27, 2014 実際にやってみるとわかるけど、実行権限だけついてるファイルは実行可能です。でも、「読み込めないのに実行できる」というのは直感に反するような気もしますね。だって、実行するためにはプログラムをメモリに読み込む必要がありますから！ではなぜ実行権限だけのファイルが実行できるのか、その仕組みを解説します。 実行とはなにか、どういう仕組みなのか Linux において実行とは「forkしてexecする」です（そのへんの詳しい話は プロセスさん を読もう！）。 fork も exec もシステムコール（正確には execve がシステムコールで exec はそのフロントエンドだけ
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
PHP はいつもわたしに新鮮な驚きを与えてくれる - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ことの始まり PHP の srand 関数について調べていて、ひょんな拍子にsrandのseedに文字列（numericである必要はあるけど）を渡せることを知った。 では、ここに long を超えるものを放り込むとどうなるのか。 では結果をごらんください。 「！？！？」 なぜこうなるのか 秘密は PHP 処理系の zend_parse_arg_impl 関数にあります。 zend_parse_arg_impl はphpの関数に渡された引数をパースする部分で、longを要求する関数にstringな値が渡された時の処理はこの部分ですね。 https://github.com/php/php-src/blob/master/Zend/zend_API.c#L335 さて、読み進めていくと「ん！？！？」ってなる行があるはずです。 この行ですね https://github.com/php/php-
日本一わかりやすい 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
Git を怖くなくする 荒技 tips - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
プログラマーに対しては「四の五の言わずに覚えろ」でいいんだけど、そうじゃないひとにも使ってほしいみたいなことって仕事であると思う。だから前の記事みたいなやつ書いてるんだけど、どう考えてもコミットメッセージ 書くときにターミナルで使うエディタ使ってもらうのはかなりのつまずきポイントなので、なんか方法ないかなーって考えてた。 で、かなりの荒技なんだけど、open コマンドで mac のエディタ開いちゃうってのを思いついた。 $ git config --global core.editor 'open -t -W' で、エディタを 'open -t -W' にしてしまうという荒技。 "-t" は、「標準のテキストエディタで開く」っていうオプションで、"-W" は、テキストエディタが終了するまでブロックするってオプション。"-W" 付けないと、openしたあとすぐプロンプト戻ってきちゃって、空の
アニメーションgifを殺して静止画にしたらかっこよかったはなし - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
アニメーション gif って一枚一枚の画像を高速で切り替えてアニメにしてるわけだけど、じゃあ、何枚も画像を切り替えるんじゃなくて、一枚の画像の中で上から順に表示させたらかっこいいんじゃないかなーって思って（伝われ）やってみたら案の定かっこよかったので置いておきます(だれかがもうすでにやってそうな気もする)。 これらが こうなる。 画面全体がすごいうごくみたいなやつはグリッチっぽくなって、画面の一部が動いてるみたいなやつだとミュワンって感じになる。 活きのいいアニメーション gif をフレーム一枚一枚にバラバラ殺人して、さらに個々のフレームもバラバラ殺人して、部品を上から順に並べるみたいな感じなので、anigif_killer.rb という名前にしました。スクリプトを貼っておくので魔改造なりなんなりしてください。
*nixのプロセスまわりについて書いてたやつがついに書き終わった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
プロセスさん最終回書いた。 最終回： https://gist.github.com/Shinpeim/5205353 目次： https://gist.github.com/Shinpeim/4736099 第一回を書き始めたときには、もっとさらっと書けるだろうと思ってたんだけど書いてみたらいろいろ書くべきことがあって、なんだかかなり辛い量の文章書いてしまった。最後のほうとかもう書くのがかなりしんどかったんだけど、プロセス周りの話はだいぶ網羅できたんじゃないかなって思う。 小出しに書いてる間、はげましのブクマとかはげましのスターとか付けてくれたひとがいたから書けたし、「おもしろい」って言ってくれたり「わかりやすい」って言ってくれたひとたち本当にありがとうございました。あなたがいなければプロセスさんは存在しなかった。 なんか噂によると Working with Unix Processes
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
ActiveRecord の named_scope に by_<column_name>みたいな名前つける人間は腹を切って死ぬべき……だよね？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
最近仕事で ActiveRecord ばかり触ってるのでその話題 ActiveRecoedには named_scope という便利な機能があって、これはまあ動的にクエリを組み立てるのに便利で良いよねって話がまあよくありますね。その話をします 最初に、Railsの嫌なところの愚痴 クエリビルダー死すべきみたいな話はあると思うし一理あると思うんだけど Rails 使う以上 AR 使わないとやってられんみたいなのもあるので AR 内でのベストプラクティスでやるしかない。こういうあたり自由じゃないなーって感じがしてわたしは Perl の TIMTOWTDI な感じがやっぱり好きだなーってなるんだけど、まあその話はおいておく。 named_scope は便利って言われるけど何が便利なの 今回は別に named_scope ってのは便利だねってことに関して異を唱えるつもりはなくて、named_scop
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
