エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ
RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
#yapc8oji 行ってきた - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
yapcasia8oji-2016mid.hachiojipm.org YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa という、八王子なのか品川なのかよくわからない名前（正解は「品川は八王子（哲学）」という態度です）のカンファレンスに、スタッフ、そしてスピーカーとして参加してきました。 スタッフとして 飛び入りトラック、通称Dルームを担当させていただきました。なんかのときに「今回アンカンファレンス的なことやりたいです」とわたしが発言したため、わたしが担当になったといういわゆる「言いだしっぺの法則」というやつですね。 飛び入りトラックは、事前トーク応募には応募しなかった（あるいは、したけどリジェクトされてしまった）方が「それでも俺は喋りたいんだ！」という熱い気持ちをぶつけるための枠として、当日トークを受け付けて当日話してもらう、という枠で
適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
適切に抽象化されたコードを書く、というのはまさに言うは易し行うは難しだ。 最近私が心がけていることのうちのひとつに、「未来を予測しない」というのがあって、「ここはあとから変更とか追加があるかもしれない」と思って抽象化しておくみたいなことはやめようと思ってる。ひとことで言うと、よくYAGNIとか言われるアレです。 そもそも、なんのために抽象化するのかというということを考えると、ひとつは「一塊の手続きに名前を付けて隠蔽して外から中を意識しないで済むようにする」ってことと、その副産物として「交換可能性が高まる」っていうのがある。 抽象化して実装を隠蔽することで、 コードが理解しやすくなる インターフェイスさえ合ってれば交換可能な部品として扱えるようになる という利点があるから、わたしたちは抽象化を行うわけだ(だからこそ「名前重要」なわけですね)。 この後者の利点に注目すると、ついつい「あっあとか
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
CRuby の hash.c を一部読んだ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ツイッターで「Ruby の Hash のキーにするオブジェクトに hash と eql? を定義しないといけないのなんでなんだろう」という話題が出て、「おそらく Hash の名前の通り、Hash テーブルを lookup するのにキーの hash 値を計算するのに使ってるんだろうね」という話になったのだけれど、「じゃあhash.c 読んでみようぜ」って感じになって、一部読んだ。2.0.0-p0のコードです。 (一部markdownが注釈と解釈されておかしなことになってるの防ぐためにスペースを余分に入れてある) まずは、Hash#[ ] の実装がどこにあるのか見る。 hash.c の 3448 行目見るとわかる。 rb_define_method(rb_cHash,"[ ]", rb_hash_aref, 1); Hash#[ ] の実体は rb_hash_aref というCの関数である。じ
YAPC::Asia 2014 レポート「一歩踏み出すのに遅すぎるということはない」 #yapcasia - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
YAPC::Asia 2014 に参加して来ました。自分も Scala のトークで応募していたのですが、残念ながらリジェクトとなり、サークル参加ではなく一般参加者として参加しました。 いろいろと書きたいことはあるのですがあまりに長くなってしまうので 2 点に絞って書きます。 Scala in Perl Company の話 はてなのはこべさんによる、「Perlの会社であるはてながなぜ Scala を採用したのか」という話題を中心としたトークでした。このブログの最近の投稿を読んでいただけるとわかるとおり、わたしの最近の学習と関心の中心にある言語は Scala で、実際に業務でも一部 Scala を利用しているので、とても楽しみにしていたトークでした。 動的型付けの言語のつらみの部分や、それに対するアンサーとしてなぜ Scala なのかという話や、一方で Scala も銀の弾丸ではないという冷
Scala の implicit parameter は型クラスの一種とはどういうことなのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
なんか型クラスとか言うと型の怖いひとたちが怖い話をワイワイしてるイメージがありますよね。わたしはあります。「で、それって何がうれしいのよ」とか、そういう話はあまりされていないような印象がありますね（あくまで印象です）。その上 "Scala の implicit parameter は型クラスの一種" とか言われると「暗黙的な引数がなんで型クラスの一種なんや！！！意味がわからん！！！！」となります。わたしはなりました。 というわけでそのへんについて勉強したので書きます。 そもそも型クラスってなんや Haskellとかにあるやつですね。アドホック多相を実現するもの、らしいです。すごい、いきなり意味がわからない。 というわけで、まずは「アドホック多相ってなんなの」という話からして行きます。 さて、まずは「多相」から行きましょう。この文脈で言う多相とは、簡単に言えば「引数にいろんな型を取れる」とい
読み取り権限がなく実行権限だけのファイルが実行できるのはなぜ？ - カーネルのソースを読む - - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
きっかけはこのツイート。 基礎的なことなんだろうけど理解できてないこと。 読み取り権限のない実行権限だけのファイルってどういう扱いになるんだろう。— ゑぬぽい改@電探が出（ん）たん？ (@NPoi) March 27, 2014 実際にやってみるとわかるけど、実行権限だけついてるファイルは実行可能です。でも、「読み込めないのに実行できる」というのは直感に反するような気もしますね。だって、実行するためにはプログラムをメモリに読み込む必要がありますから！ではなぜ実行権限だけのファイルが実行できるのか、その仕組みを解説します。 実行とはなにか、どういう仕組みなのか Linux において実行とは「forkしてexecする」です（そのへんの詳しい話は プロセスさん を読もう！）。 fork も exec もシステムコール（正確には execve がシステムコールで exec はそのフロントエンドだけ
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
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-
やはりおまえらの MVC は間違えている in バックボーンジェーエス - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下本編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから（あるいは Marionette.js を使ったらから）といって自動的にお前のアプリケーションが MVC になるわけ
*nixのプロセスまわりについて書いてたやつがついに書き終わった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
プロセスさん最終回書いた。 最終回： https://gist.github.com/Shinpeim/5205353 目次： https://gist.github.com/Shinpeim/4736099 第一回を書き始めたときには、もっとさらっと書けるだろうと思ってたんだけど書いてみたらいろいろ書くべきことがあって、なんだかかなり辛い量の文章書いてしまった。最後のほうとかもう書くのがかなりしんどかったんだけど、プロセス周りの話はだいぶ網羅できたんじゃないかなって思う。 小出しに書いてる間、はげましのブクマとかはげましのスターとか付けてくれたひとがいたから書けたし、「おもしろい」って言ってくれたり「わかりやすい」って言ってくれたひとたち本当にありがとうございました。あなたがいなければプロセスさんは存在しなかった。 なんか噂によると Working with Unix Processes
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
Niigata.pm tech talk #1 を開催してきました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
4/28(土)、Niigata.pm tech talk #1を開催してきました。 今回はNiigata.pmとして初の、居酒屋とかじゃないちゃんとした会場でのtech talkでした。自分の力だけでは絶対にこういう場を設けることはできなくて、Niigata.pmに参加されているみなさんや私と交流してくれた新潟の開発者の方々、応援してくださっている東京やほかの地方のPerl Mongersがいたことが、本当に励みになってようやくこういう場を設けることができました。本当に各方面に感謝しています。 さらに、今回のNiigata.pmは技術的にも本当に面白い発表が多くて、発表してくださったみなさんにも大変感謝しています。ありがとうございました。 talkは以下の通りでした @hayajoさん モダンなPerlの開発環境として、perlbrew,cpanm,cartonについて WAFとしてMoj
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
