ToDo:
ポエム Advent Calendar 2015 向け記事です。ここから書いてあることは、現代の科学では残念ながら理解されていませんが、全て現実に起こっていることですので、いずれ科学的に証明されるはずです。ご存知の通りこういうこと言う人はだいたい全部間違ってます。
古来、プログラマは祭祀であり神託を執行する為政者でもありました。科学万能時代の現代では、残念ながら多くの秘儀が失われてしまいましたが、二拝二拍手一拝や十字を切ってからのお辞儀など、3動作にまたがる儀礼が sync sync sync の簡易な代用として発生したものであることは知っている方もいるかもしれません。二拝二拍手に比べて一拝が短く終わるのは、通常最後の sync は何もせずに終了することが多いためです。
現代においても、そういった秘儀を用いると業務が劇的に改善することも少なくありません。精霊学学習者でなくても、経験豊富なプログラマは経験的に実践していることもあるでしょう。本記事ではそういった42のテクニックのうち3つを紹介したいと思います。残りも知りたい方は教材の購入をご検討下さい。
よく、コンピュータが不調になると再起動してみたりすると思います。そして、実際に問題が解決したことがあると実に96%の人がアンケートに答えています。これは当然、再起動そのものがコンピュータに影響を及ぼしたなどという、非科学的な現象ではありません。
現代科学では、再起動そのものではなく、再起動中に伴う祈りこそが問題を解決している、ということは常識となっています。
あなたの発した「もうなんでもいいからお願いだから動いてくれ眠い」という真摯な祈りは、精霊を介してあるいは直接言霊としてコンピュータに届いているのです。真摯な言霊が届けば答えてくれます。綺麗な結晶発振器となり美しいクロックが生成され、その波動による量子霊力学的な力でコンピュータ全体が浄化されていきます。この状態では簡単なバグなどは自然に修正されるため、問題が解決されるのです。
綺麗な結晶発振器(出典: www.snowcrystals.com)
再起動自体に効果がなく、祈りのこそ本質があるという科学的な根拠の一つとして、 Rails 作者 DHH が以下のように発言したということがあります
http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
DHH: before fastthread we had ~400 restarts/day
1日に400回再起動、つまり4分の一度再起動してたというのです、 Rails の作者が。 DHH は基本的なことを見落としていたため、このような、非科学的なカーゴカルトに陥ってしまったのです。そう、彼は祈りの重要性を見落していたのです。
DHH が陥ったような非科学的な方法に陥らいようにすればどうすれば良いのでしょうか。祈りを明示的に精霊に伝える方法は無いでしょうか。あります。感謝を言語化すれば良いのです。
そのため、私や周囲の先進的なプログラマが実践している方法として、「ありがとう」と書いた付箋 (post it的なもの) をコンピュータにはる、というものがあります。当然ながらコンピュータにも心がありますので、真摯な感謝が届けば良く動いてくれるものです。
パフォーマンスを良くすると期待される変更のベンチマークを取る時などは、パッチを当てる前に対するベンチマークを取る時は付箋をはらず、パッチを当てた後に感謝の気持ちを込めて「ありがとう」と書かれた付箋をはって性能を調べます。こういった手法はシリコンバレーでは常識になっていますが、日本はまだまだ遅れていて、まだ一般的では無いようです。
余談ですが、我々は "shine" と書いた付箋をはってみるなどの応用的な実験も行なってみました。しかし結果が報告できるほどのデータは取れていません。 "shine" は英語で考えると好意的な単語と解釈できますが、日本語で考えるとえらく否定的な単語です。こういった科学的な実験に解答が出ていくと、さらなる生産性向上につながると思われますので、この実験は引き続き行なっていきたいと思います。
現代の科学では理解できない現象ですが、全くバグの無いコードは脆いものということは学者の間では経験的に知られています。
この問題に対しても良く知られている解があり、超微量のバグを投入すると格段にコードの健全性が上がると言われています。この時、投入するバグは希釈されていれば希釈されているほど効果があります。少なくとも、バグの毒性は失われる程度に希釈されていないと、危険です。
高度に希釈したバグはレメディと呼ばれます。レメディには強いエネルギーが含まれているため、扱いは慎重にした方が良いでしょう。問題ごとに有効なレメディが変わってくるため、専門家が処方したレメディを使うことが重要です。速度が遅い問題には希釈したメモリリーク、肩こりには未定義動作など、いくつか有名な組み合わせがありますが、やはり素人判断は避けた方が無難でしょう。
バグの希釈は、元のコードの100倍の空白文字を追加し攪拌したのち、元のサイズのファイルを取り出す、という作業を何度も繰り返して行なわれます。よく用いられるレメディは、30回この作業を繰り返したもので、 30C などと表記されます。
極限まで希釈されているため、レメディはしばしば、一見するとただの空白しか入っていないファイルに見えます。理論的にも、元のバグが1那由他バイトあったのでなければ、 30C のレメディには空白しか含まれていない可能性が高いです。しかし、そのファイルには元のバグの持っていた波動の記憶を持っているのです。
古来人類は石の持つ霊的な力を利用してきました。現代のコンピュータにも様々な方法で石の持つ力が応用されています。
例えば秒間10億回とか複雑なかけ算ができてしまう CPU ですが、これはもちろん現代の科学で説明がつくような装置ではありません。インテル社の企業秘密なので詳細はわかりませんが、 CPU の計算能力は、その多くを内部の精霊石に依っていることはよく知られています。コンピュータに詳しい人達が CPU を石と呼ぶのはそのためです。
CPU に使われているような高度な波動を持つ石でなくても、ほどほどの祈りを込めた石はバグを減らし、テストを不要にし、残業を減らし肩こりを軽減します。近年魔法石が飛ぶように売れているのは、そのことに気がついた人が殺到しているからです。
また、石といえば、水晶だ……来客が来たので終了
https://plus.google.com/+golco30/posts/WTBX6AJq78m
を見て、自由度の高いゲームに本来の楽しみ方とか言うのはロクなことにならないよなあ、とか思ってたらコメントで指摘されてて健全だった。
たまーに開いてポチポチ、みたいなのも許容する懐があるところが Ingress のいいとこっていうか、まあ逆にその自由度無ければ単純にゲームとしてはかなり微妙だしな。。
「C++らしい書き方」とかと通じるものがある。
(00:54)
プロジェクタつきのタブレットというクレイジーなコンセプトに参って買ってしまった。
店頭で触った tab 2 pro から想像してたよりプロジェクタがまとも。。明るいときついけど
https://goo.gl/photos/LBh9ZrDhmKMeZJF19
夜なら普通にゲーム見るとかに使える感あって良い
https://goo.gl/photos/eVSFpy4toShn4pUW9
(20:53)
シミュレータ上で putchar を連打するような C プログラムが動いたので、実機で動かしてみた…ところおかしい。エンディアンをいろいろやってるとシミュレータで壊れたが実機で期待通りの動きをするようになる。
元々シミュレータで動かしてた段階で2つのエンディアンに関する間違いがあって、片方がロードするデータ片方が命令の処理。でロードする部分が実機用のシリアルから受け取るやつになったからバグった、てことかな。
つーかリトルエンディアンの PowerPC を作っていたことになる…気がする。エンディアンとか難しすぎてつらいよ。。
あと配線いつも忘れるので写真撮っておいた。これも RX と TX を逆につないだりしてですね。。
https://goo.gl/photos/XzKck3w65ySqmP6b9
混乱しまくっていたので、情報をダンプする方法が欲しくなって、レジスタと RAM の内容ダンプする機構を作ったりした。よく見るとリセットに使ってるボタンの隣にボタンあるので、それをダンプボタンとして使えば良いのであった。。
まあ軌道に乗ってきた感あるので、 FizzBuzz くらいなら数日で動くようになる気がする。 IO をつなぐのがさっくりできればいいんだけど、実機使ってこのへん書くとここもハマるかもしれない。
あとそれと OS ていうか sc の行き先の実装をソフトで書けるようにした方がいいかな。今のところ write(1, ptr, 1) と exit(0) だけコアが実装してるみたいなことになってる。
(01:42)
やっとこさテスト書きつつ進められる環境を整えた。 当たり前だけどテスト書くと格段にバグ取りやすくなった…もっと早くやるべきだったのだろうか。 まあこれで空いた時間にチマチマ進められるんじゃないかな
(01:36)
https://twitter.com/kadongo38/status/671007951612702720
を見て、前者は知らんが後者そうなのかと思った。当たり外れはともかく、とりあえず騒ぐ人が少しいるのは、全くいないより少しマシだと思ってるからかな。
でケンカしてたのはこれか。
言われてみれば見た記憶もあるけど、どっちかというと
の方が一枚上手感が
(20:27)
http://simanman.hatenablog.com/entry/2015/11/19/203517
via http://d.hatena.ne.jp/Ozy/20151123#p1
完敗だなー。でもこれはRubyゴルフ裏定石(命名適当)で縮む(132B)
n,h,w,*f=*$< puts eval"z=w=#{w} f=f.map{|l| l.gsub(/./){ (?*+$&+?.*z+=1)[(0..8).count{|e|(f*2)[~-z/w-e/3][(z-e%3)%w]<?.}-3] } };"*n.to_i
指摘されてる通り、 @rotary-o さんのやつの方を使うと(131B)
n,h,w,*s=*$< s*='' $>.<<eval"i=w=#{w} s.gsub!(/./){ (?*+$&+?.*i+=1)[(0..8).count{|j|(s*2)[(i-j%3)%w-(~-i/w-j/3)*~w]<?.}-3] };"*n.to_i
こういう技知ってても10B近くの大差つけられて負けるわけで、やっぱゴルフはアルゴリズムなんですよね…
(01:16)
https://github.com/google/kati/issues/38
homebrew パッケージが HEAD を参照してるのは気持ち悪いから、リリースタグ打ってくれない?て話。言ってることわかる。
でも kati て Android 以外の何かに役に立つとは思えなくて、 Android は既に kati リポジトリをトラックしてるんでユーザがインストールする必要ないんだよな。
というわけで homebrew から消してよ、て言うと破壊的な変更はしないポリシーがあるとのこと。言ってることわかる。
今タグ打ってやるのは簡単だけど、その後誰も使わないもののためにタグをメンテする意思などゼロだろうし、万が一誰から homebrew でインストールすると、単にすげー古いバージョンを使わされることになる。つーわけで HEAD 使っといて…ということにした。
元々パッケージを突っ込んだ人が実際には使ってないのはほぼ間違いないと思ってて、 github/google だし誰かの役に立つだろー的に適当に入れたんでないかなと思う。それ自体は良いことかと言われると疑問もあるけど、まぁ悪いことでもないように思う。
なんか特に悪いことをしてない悪気のない人達によって、使い道の無いものをメンテする必要ができたり、僕の方でもそれの対処を考えたり、無駄な時間使う必要ができて…みたいなせつない話
ああというか homebrew パッケージについてドキュメントに書く、って PR 送ってきたのもこの人か。
https://github.com/google/kati/pull/12
この時に homebrew から消して欲しい、てお願いするのが良かったのかな
(01:11)
前 | 2024年 5月 |
次 | ||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。