builderscon2019振り返り(not技術編) - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
builderscon2019に参加してきました。以下技術的ではない部分の振り返りです。技術的な部分の振り返りはまたあとで書きます。 今年はすごく自分のメンタルが乱高下する、とてもヘヴィなbuildersconとなった。というのも、まさに前回の記事に書いたことが起こったのがbuildersconの前夜祭だったからだ。前回の記事は自分もまだ混乱のさなかにあるときに書いたものなので、だいぶ落ち着いた今、再度そのあたりの話をするところからはじめたい。 前回の記事にも書いたけれど、「マッチングアプリのいいね自動化」という内容そのものが悪である、という立場にぼくは立たない。マッチングアプリというのは、そもそも男女ともに「性的に選別」しあうものである。そうである以上、「マッチングアプリ上での性的な選別の自動化」は問題ないはずだ、という立場ではある。「どんな文脈であれ人間を性的に選別するような発表はそも
エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ
RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
やはりおまえらの MVC は間違えている in バックボーンジェーエス - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下本編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから（あるいは Marionette.js を使ったらから）といって自動的にお前のアプリケーションが MVC になるわけ
要するに 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-
後方互換性についてさいきん考えていることを書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
後方互換性を守るべきブロダクトと、そこまで気にしなくていいプロダクトがあると思っている。 後方互換性を守るべきもの これはもうシンプルで、「依存関係の下のほうにあるプロダクト」。下のレイヤーを担うことを狙っているものについては後方互換性を守って行かないとみんなが困る。多くのライブラリがすでに依存してるライブラリとか、あとはまあデータフォーマットとかも変わるとそもそも溜め込んだデータとかが使えなくなったりするので困る。 Perl5 が後方互換性を保つことに熱心なのは、そもそも Perl がシステムツールによく使われていることと無関係ではないはずだ。system perlのversion上げたらシステム動かなくなりましたみたいなことになったら困るからかなり気を使ってる。その点、Python が 2 系から 3 系に移行するときにばっさりと後方互換を捨ててしまったのは失敗だったんじゃないかなと私
「オブジェクトをイミュータブルにしろ」って言うけど、それってたとえば状態が変わったらオブジェクト作り直すってことでしょ、ちょう非効率じゃん。って思ってたんだけど、 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
オブジェクトの内部の値がイミュータブルであれば、今後もその値は変更されないことが保証されているので、新しい状態を持った新しいオブジェクトの内部の値のうち、変更のない部分(つまり値のうちのほとんど)は古いオブジェクトの値をそのまま参照すればよく、コピーする必要がないということを @takkkun が言っていて(正確には、イミュータブルなリストに新しい値を追加した新しいリストを作るときには、中身をコピーする必要ない。変更されないことが保証されてるから、という話だった)目から鱗が落ちたのでここに記して置こうとおもった。 で終わろうと思ったんだけど、もう少しちゃんと書く。 ミュータブルな世界では同一性の問題がある。 たとえば playerA と playerB の HP がたまたまおなじ 10 であったとしても playerA と playerB の HP 変数が同じ数値オブジェクトを参照していた
Git を怖くなくする 荒技 tips - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
プログラマーに対しては「四の五の言わずに覚えろ」でいいんだけど、そうじゃないひとにも使ってほしいみたいなことって仕事であると思う。だから前の記事みたいなやつ書いてるんだけど、どう考えてもコミットメッセージ 書くときにターミナルで使うエディタ使ってもらうのはかなりのつまずきポイントなので、なんか方法ないかなーって考えてた。 で、かなりの荒技なんだけど、open コマンドで mac のエディタ開いちゃうってのを思いついた。 $ git config --global core.editor 'open -t -W' で、エディタを 'open -t -W' にしてしまうという荒技。 "-t" は、「標準のテキストエディタで開く」っていうオプションで、"-W" は、テキストエディタが終了するまでブロックするってオプション。"-W" 付けないと、openしたあとすぐプロンプト戻ってきちゃって、空の
よけいなプライドは捨てたほうがいいという話について書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
雑文を書く。 ぼくはどちらかとプライドが高いほうで、単なる趣味であるところの音楽でも「下手なところは見せられない」とか、「アレを聴いてないことが恥ずかしい」みたいな気持ちを強く持ってる。なんというか、「下手なところを見せたら舐められるんじゃないか」とか「アレを聴いてないとバカにされるんじゃないか」みたいなふうに感じてしまう。 で、こういう話をしてるとよく、「プライドを捨てよ、そして楽になるがよい」みたいなことを言う人間がどこからともなく現れてOSEKKYOを始めたりするのだけれど、そういうのに対しても結構大きな違和感を持っている。こういう「舐められたくない」みたいな気持ちがないと、クオリティの低いものばかり作り出す邪悪な人間になってしまうし、プライドがあるからスキル上がって行くみたいなところはあると思う。 一方で、こういうプライドがじゃまになることもたしかにあって、馬鹿にされるのが嫌だから
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
