更新履歴兼雑記 抽象化を嫌う理性的な理由を少し考えてみた
過度の抽象化はダメ、とかアーキテクチャ宇宙飛行士がどうこう、っていうのはまぁ正しいとして、普通に抽象化してもいいかな、って局面でも、まだ抵抗がある時があって、それがなんでかなぁと考えたという話。 おぶじぇくとしこーでふわふあーとかでざぱたもげもえーとか、 DI でむにむいーとか、そういった抽象化されて整理されたコードは全般的にメンテしやすくなって、ソースを変更しても汚くなりにくい、とかそういうのは一応わかってはいるつもりなのですが、常に絶対必ずやるべきだ、と言われると強い反感を覚えるわけです。 まぁもともと「絶対暴力はいけない」とかそっち系の命題は嫌いなのもあると思うのですが、プログラムにおける抽象化の場合はそれ以外にもあるなぁと。 で、何かっていうと、ちゅーしょー化はたしかに、数百行の変更には強くなるのですが、数十行以下のダーティハックはしにくくなるよな、と。 こいう話の時は必ず私が出す
開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
Base64 decoder/encoder in Perl - 兼雑記
http://shinh.skr.jp/obf/b64_dec.pl dXNlIE1JTUU6OkJhc2U2NDtwcmludCBlbmNvZGVfYmFzZTY0IGpvaW4nJyw8PjsKX19FTkRfXwo+ s//v62/e+s//v60/e+s//v44/e+s//v39/e+s//v39/e+s//join/+s//v32/e+s//base64/ss+ s//v95/e+s//decode/+s//v32/e+s//print/+s//v59/e+s//Base64/+s//v58/e+s//v58/e +s//MIME/+s//v32/e+s//use/s/evalこの Base64 ぽく見える物体は Perl コードで、実行すると引数で指定したファイルに対する base64 デコーダとして機能します。 $ perl b64_dec.pl b64_dec.pl >
static link について - 兼雑記
案外、 static link ってわかってないもんです。というかリンカってわかってないもんです。そして案外はまるものです。以下のクイズに答えられるでしょうか。 クイズ1 $ nm main.o # int main() {} 0000000000000000 T main $ nm foo.a # void foo() { bar(); } void baz() {} foo.o: U bar 0000000000000010 T baz 0000000000000000 T foo $ nm bar.a # void bar() {} void baz() {} bar.o: 0000000000000000 T bar 0000000000000006 T baz $ gcc main.o foo.a bar.a最後のコマンドで、何が起きますか？ 普通にリンクできる undefine
転職してからやってること - 兼雑記
転職してからやってるプロジェクトについて何か書いてみようかと思います。 https://github.com/pfnet-research/chainer-compiler/ 公式ぽいブログも書きました。 https://research.preferred.jp/2019/01/chainer%E3%83%A2%E3%83%87%E3%83%AB%E3%81%AE%E3%81%95%E3%82%89%E3%81%AA%E3%82%8B%E9%AB%98%E9%80%9F%E5%8C%96%E3%80%81%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%81%AE%E7%B0%A1%E4%BE%BF%E5%8C%96%E3%80%81/ あまり綺麗にまとまった文章を書ける気がしないので、つらつらと時系列で思い出して行こうかと思います。 転職前、 define
Unix v6 の C コンパイラが面白かった話 - 兼雑記
Unix v6 の C コンパイラをいじってみようと見てたのですが、これがなかなかすごい物体でした。 読んでて、「いやいくらなんでもこんな作りなわけが…」と思って説明文を探して、 http://plan9.bell-labs.com/7thEdMan/v7vol2b.pdf の「A Tour through the UNIX C Compiler」に説明あるよと教えてもらって読んでみたら、本当にそんな作りだった、みたいな。 コンパイラの1段目はプリプロセスして構文木的なものをファイルに吐いて終わりです。2段目は構文木を読みつつコード生成していく。 構文木のノードの種類に対して switch してやること決める…的なものが、データドリブンな方法で書かれてます。データを保存するフォーマットは、 JSON とかではなく、時代が時代ですのでアセンブリです。こういうやつ https://github
就職して9年が過ぎる - 兼雑記
転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ わりと重要でない Borgチーム (の周辺) いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。 さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない？みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。い
ゴルフ場のなかみ - 兼雑記 (2009-09-29)
最近ゴルフ場を新しいマシンに引越そうとしていて、ついでなのでシステムをもうちょっと丁寧にパッケージ化しようとしてます。そのついでとして、現在のゴルフ場について内部がどうなってるか、ということを少しまとめてみようと思いました。 結構似たようなことをするサービスもあるんですが(codepadとかllevalとか)、そのへんのコードとかは全く参考にしてないので、そういうのを見た方がいいかもしれませんし、あとゴルフ場固有の事情も色々あったりするかもしれません。まぁでも日本語でそのへん書いてるのはあんまり見たことがないので、多少参考になる部分もあるかもしれません。 今作業中のコードは github に入れていっています。 apt で入らないパッケージの処理以外はだいたい入ってるはずですが、まだ足りないものとかあるかもしれません。 http://github.com/shinh/ags システム自体は
emscripten であそぶ - 兼雑記
hello int main() { puts("hello"); } 生成されたコード // EMSCRIPTEN_START_FUNCS function _main() { var label = 0; var $1=_puts(((8)|0)); return 0; } Module["_main"] = _main; // EMSCRIPTEN_END_FUNCS 8がだだっぴろいメモリへのインデックスなのはわかるけど、それはどこで定義されてるのかな…と hello で検索しても見つからない。 104 で検索すると見つかった。 STATIC_BASE = 8; STATICTOP = STATIC_BASE + 8; /* memory initializer */ allocate([104,101,108,108,111,0,0,0], "i8", ALLOC_NONE, R
binutils にパッチ投げてみた話 - 兼雑記
Mach-O バイナリをコード見ながら逆アセンブルする方法が無いってのがずっと困っていました。つまり linux でよくやっている objdump -S みたいなことがやりたかったんですが、 objdump -S は Mach-O に対しては動かないし、 otool -tvV もソースコードは見せてくれないし、っていう。でまぁ一念発起して binutils というか libbfd をいじってみたのでした。 今回はじめて FSF なソフトに patch 投げてみて、まぁ特に著作権の処理とかどのくらい時間かかるもんなのかよくわからなくて、こちらのかた以外にあまり体験談的なのが見つからなかったので、なんか書いていみようかと。 とりあえず適当にパッチ書き。経験上デカいパッチいきなり投げるヤツはうざがられるので、なんか小さめな目標で…ってことで objdump -S を .o に対してだけ動くような
sedlisp.sed 00:54 - 2014-06-08 - 兼雑記
https://github.com/shinh/sedlisp Lisp インタプリタを書きました。 sed で。 https://github.com/shinh/sedlisp/blob/master/sedlisp.sed README に書いた通り、それなりにややこしいプログラムも動く気がします。具体的には eval.l として、 eval の無いところで eval を実装しました。で、その上で FizzBuzz なんかが動きます。これはつまり S 式のパースは省略した Lisp のインタプリタと言って良いので、 sed で書かれた Lisp の上で Lisp が動いて、その上で FizzBuzz が動いてることになります。ちなみにもう一段かますことはできませんでした。 Ruby で書いた実装でも動かないので、 eval.l がとりあえず循環できない作りになってしまってるみたいで
NaCl について - 2013-12-18 - 兼雑記
カーネル/VM Advent Calendar 2013 にさっき登録しました。需要の無さそうな NaCl について語ります。 https://qiita.com/advent-calendar/2013/kernelvm NaCl はグーグルが作ったものの中で一番好きくらいに好きなものです。理由は低レイヤコンポーネント集だから。概要としては安全に実行できる(ここでいう安全はブラウザが動いてる OS 上での任意コード実行ができない、という意味) Active X というか、 C/C++ でコードが書ける Java Applet というか、まぁそういう感じの。 NaCl はおおざっぱに言って、 検証可能なバイナリを出力するコンパイラツールチェイン (gcc, binutils, etc.) ユーザプログラムを検証して起動する service runtime service runtime と
2012-12-10 ■ Hello golf in Malbolge - 兼雑記
Esolang Advent Calendar 2012 用のエントリです。 Esolang 的な自己紹介としては、今年は ICFP のコンテストのために巨大な befunge プログラムを書きました。 Malbolge 概要 ご存じの人が多いかと思いますが、 Malbolge という超難解言語があります。この言語の難解さは brainfuck などがかわいく見える、というか、私の感覚では ruby と brainfuck くらいの差が brainfuck と malbolge の間には存在しています。いや、もっと広いかもしれず。 Malbolge について一言で紹介すると、「抜群のバランス感覚で適当に設計された神クソゲー」という感じ。ざっくりとした説明としては、 A,C,D の3進10ケタ(つまり0-59048の値を持てる)レジスタと、 59049 個の 0-59048 の値が持てるメモ
プログラムコンテストと逆言葉の壁仮説 - 兼雑記
ゴルフやるアメリカ人が全くいない、という話のあと考えてた謎仮説。 考えてみると topcoder や ICPC もロシアやら中国やらが強いという印象。 ICFP programming contest もたとえば Google Japan はたぶん他の全 Google をあわせたより多い人数が参加している気がする。そういうのが好き、って国民性もあるのかもだけど、ふと、英語が得意でないからじゃないだろーか、ということを考えた、ってのがこの仮説。 プログラムを覚えて、特に学生とかは、イマイチ客観的な評価が得られにくいので、試したくなると思う。自分のプログラム力ってどのくらいなんでしょか、通じるんでしょうか、っていう。あるいは、能力に自信がないから、なんか修行したいな、とか。 そういう時に、英語ネイティブなら、単にどっかのオープンソースプロジェクトに参加してみたり、よくわかってないけど十分優秀な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
