トップ «前10日分 最新 次10日分» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|12|
2025|01|02|03|04|

ToDo:


2016-01-11

_ メガネ

右 S-8.00 左 S-7.50 C+0.50 S-7.00 C-0.50*

と書いてある。意味は調べてない

(23:29)


2016-01-07

_ ハーモニー

も読んだんだった。ついでに映画も。

映画のオチは「あーなるほどこういう意味だったんだ」と思ったけど、まあ普通に映画で勝手に解釈したぽい。映画の方がわかりやすくていいんじゃね、原作者墓下で文句言ってそうだけど。

内容はまあ、意外とストレートにわかりやすい、みんな良い人になりすぎた理想郷は人間くささが消えてつまらんよ系の。類似ストーリーとしては斑鳩を最初に思い出す。それはいいし、素直に先が気になったんだけど、なんか途中の展開が全体的にこうちょと違和感ある感もあった。もやっと

(01:38)


2016-01-04

_ 読んだ本

  • 論考: ウィトゲンシュタイン。だいたい読んだ。哲学をずいぶん狭い世界に勝手に限定して、「これで哲学完成!もう哲学者のやることは無いっ」てのはちょっとひどいんじゃないかとか思った。哲学屋の友人に聞いてみたところそういう面もあるかもね次のやつ読んだらということだった。でもこういうのも一冊読むのは結構だるいな。
  • 心にナイフをしのばせて: 少年犯罪の被害者側の家族が悲惨な生活、加害者本人は弁護士になって順風満帆な人生、ていうやつ。少年法とか被害者加害者人権てやつは難しいなあと思う。基本的には加害者には死を!みたいなのには賛成できないけど、これ読むと被害者悲惨すぎやろ感強いので一定の保証があっていい気がする。気休めみたいなもんかもだけど
  • 僕はやってない: 筋弛緩剤点滴事件の容疑者が冤罪と主張するというやつ。今は無期懲役確定で再審請求してる感じぽい。これ読むと、あっこの人本当に冤罪だなって思う
  • 真実のカルテ: 筋弛緩剤点滴事件を警察に届けた病院の人たちの主張。これ読むと、あっあの人やっぱり犯人だったんだって思う。ありえそうな正解のパターンは 1. 実際殺してた 2. 冤罪でかつこの病院が医療事故をゴマかすための陰謀 3. 冤罪だが病院側は本当に殺人だと信じている、の3つか。3つ目がクズ人間がいないという意味では良いのだけど、筋弛緩剤無くなったのとかヘンすぎるので、1か2が現実的なんだろうな。真実のカルテの方、警察が逮捕した時点で「やはり事実であったか」と思った、とか書いてあるんだけど、これ人狼的には黒要素とか思いながら読んでた。僕はやってない側は黒要素無いかなと思うけど、すごい嘘つきてのはいるもんだから1もありえるとも
  • 東大駒場寮物語: なんかうまいことまとめてるなと。身贔屓かもしれないけど。時代的には昔が半分、著者がいた時代が半分て感じでなんかちょうどいい。しかしものすごい量記録あったのによく読んだな

マンガは特に面白いこともなく

School rumble こんな終わり方してたんだ、と思った。あとは変ゼミが終わりました

(23:44)


2016-01-02

_ 経県値

なんか前やったんだかやってないんだかわからんけど、記録残ってなかったので

http://uub.jp/kkn/km.cgi?MAP=44340444443354404144034344543000444040043000000&NAM=%82%CD%82%DC%82%B6&CAT=%90%B6%8AU%8Co%8C%A7%92l

行ったことあっても記憶が無いとこはのぞいた

(18:16)


2015-12-28

_ フェス

http://togetter.com/li/917489

ごめんなさいごめんなさい…

これとかひどい

https://stat.ink/u/hamaji/190197

(02:18)


2015-12-24

_ 進捗

min-caml についてる test てディレクトリのコード、浮動小数以外は完動した。

rs232c RX のシミュレーションはテストではしないようにした…ので入力ともなうシミュレーションが安定

負数のシフトをなおしたところ sort.l 動いた

なんか iverilog 普通に割り算やらしてくれるもんだから追加したら fizzbuzz.l も動いた

がまあ当然除算入ってると実際の回路合成でこらあかんという感じ。マルチクロックな割り算は IP コアがあるぽいのでそれ使えば良いかな。

いよいよ浮動小数かなあ。ソフトでやるより IP コアの方がラクだったりしないかな。。ただ iverilog でテストしにくくなるんだよな。

(01:21)


2015-12-23

_ こんぱいる

6分くらいだと思ってたら、15分かかるぞ。。。。。。。。

@toyoshim 先生がクロック落とせ、って言ってたのを思い出したので、 PLL 入れて 10MHz まで落としてみたら 2,3 分くらいになった。やったー PLL て何か知らんけど。

しかし気付いたら LE 結構使ってるもんやな

; Family                             ; Cyclone IV E
; Device                             ; EP4CE22F17C6
; Timing Models                      ; Final
; Total logic elements               ; 7,736 / 22,320 ( 35 % )
;     Total combinational functions  ; 7,225 / 22,320 ( 32 % )
;     Dedicated logic registers      ; 1,646 / 22,320 ( 7 % )
; Total registers                    ; 1646
; Total pins                         ; 86 / 154 ( 56 % )
; Total virtual pins                 ; 0
; Total memory bits                  ; 524,288 / 608,256 ( 86 % )
; Embedded Multiplier 9-bit elements ; 12 / 132 ( 9 % )
; Total PLLs                         ; 1 / 4 ( 25 % )

(01:47)

_ りすぷいんたぷりた

動きはじめた

(print 42)

で 42 て出せるだけだが。まあトレース見るとバグってるぽいが

(03:05)

_ りすぷ

(print (- (+ 5 (* 3 13)) 2))

くらいも動くようになった。

そろそろこれ以上複雑なプログラムは iverilog の速度的に不愉快という感がある

(03:33)

_ TODO

符号ついてる計算がたぶん色々おかしい。 sort.l が sort しない理由はたぶんこれ。まあむしろ動く方が不思議ですらある

fizzbuzz.l が動かないのはたぶん除算が無いから

rs232c の RX 側のシミュレータ実装がロクでもない。 iverilog に $getchar みたいなのがあれば話が早いと思うんだけど、どうもそいうの無いぽいんだよな。まあ rs232c は実機で十分動いてるんだから、もうちょい上のレイヤでシミュレーションする感じかな、その方が速度も出るしな

そろそろ浮動小数のソフト実装を使ってみるか

つーか min-caml が生成したバイナリを全部通すってのが先か

カーネルというかブートストラップローダというか、そういうものを最初に送る作りにすると複雑なプログラムを高速に送り込みやすいけど…まあ実際的なメリットが無いか

(04:38)


2015-12-21

_ instagramのセキュリティバグ見つけた人の話

http://www.exfiltrated.com/research-Instagram-RCE.php

を教えてもらって、ふむふむ任意コード実行とはひどいなーとか思ってたけど、その後の FB とのもめ事の方が面白かった。要はその任意コード実行使ってもっと探ってバグ報告したら、規約にそういうこと書いてないにも関わらずバグ使って権限のエスカレーションやるのは違反であると FB に言われて、その後自分の会社の CEO に連絡が行ったと。

まあこれ会社クビになったりしなくて良かったなあ。

で FB の CSO の反論らしい

https://www.facebook.com/notes/alex-stamos/bug-bounty-ethics/10153799951452929/

まぁ、規約に書いてないんだから、そのへんしっかりしてるべき大会社の FB の非は大きい…という感がある。だから対応の仕方も微妙な気がする。

でも CSO の "was not ethical behavior" てのはその通りな気がするんだよな。あと CSO は過剰反応されてびっくりした的に書いてるけど、これ実際そうなんじゃないかな… FB がこの人いじめる理由が無い気しかしないし

(00:01)

_ CPU進捗

N queen が解けた。

いさぎの良いメモリアロケータ

__attribute__((section(".heap")))
char heap[0x1000];

void* malloc(size_t s) {
  static char* p = heap;
  char* r = p;
  p += s;
  return r;
}

void free(void* p) {
}

(12:13)

_ null リファレンス

http://cpplover.blogspot.jp/2015/12/blog-post_21.html

これ、 warning 切ってるだけじゃないの?

$ cat null_cmp.cc
#include <vector>
using namespace std;
bool func(const vector<int>::iterator& i) {
  return &*i == nullptr;
}
$ clang++ -std=c++11 -c null_cmp.cc
null_cmp.cc:4:11: warning: reference cannot be bound to dereferenced null
      pointer in well-defined C++ code; comparison may be assumed to always
      evaluate to false [-Wtautological-undefined-compare]
  return &*i == nullptr;
          ^~    ~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/stl_iterator.h:753:7: note:
      'operator*' returns a reference
      operator*() const _GLIBCXX_NOEXCEPT
      ^
1 warning generated.

(12:22)

_ たらいを回して速度を測る

手元の i7 だと 0.02 秒で終わる tarai(12, 6, 0) を実行するのにだいたい30秒かかった。1500倍遅い。

クロックの比が68倍ありますけどね。まだ22倍の差があって。僕のCPUだいたい 5 CPI くらいだと思ってたんだけど、だとすると i7 0.22 CPI かよってことになって、いくらなんでもインテルすごすぎ感がある。

まあたぶん 5 CPI という見積りがあやしくて実際はもうちょい遅いとか、あと PPC て時点で命令数増えてたりしそう。そのへん考えると順当な差なのかなー

(20:55)


2015-12-20

_ ruby kaigi

前々日の宴会で、 TravisCI の人と話せて既に黒字化しとるという話を聞いてびびった。なんとなく気前が良すぎると思ってて客寄せ段階なんだと思ってた。

IBMのこれ、

https://github.com/rubyomr-preview/rubyomr-preview

ダウンロードだけしてまだ中見てない。 OMR 側のコードはまだ出てないんだよな

前行った時も思ったけど、ずいぶんプロぽい感じになったよなあとか。別に長くつきあってるわけじゃないけど、まあ最近だけ見ても

akrさんがmakeのやばさを理解しててさすがと思った

Ruby 自体に興味がなさすぎて話のわからないぷりがさらに増えてる感があった。 rails より最近の単語がすごく基本的な説明すらできない。 sinatra …聞いたことあるな、なんかweb。くらいの

(00:38)


2015-12-19

_ 業務を劇的に改善する3つのスピリチュアルプログラミング技法

ポエム Advent Calendar 2015 向け記事です。ここから書いてあることは、現代の科学では残念ながら理解されていませんが、全て現実に起こっていることですので、いずれ科学的に証明されるはずです。ご存知の通りこういうこと言う人はだいたい全部間違ってます。

古来、プログラマは祭祀であり神託を執行する為政者でもありました。科学万能時代の現代では、残念ながら多くの秘儀が失われてしまいましたが、二拝二拍手一拝や十字を切ってからのお辞儀など、3動作にまたがる儀礼が sync sync sync の簡易な代用として発生したものであることは知っている方もいるかもしれません。二拝二拍手に比べて一拝が短く終わるのは、通常最後の sync は何もせずに終了することが多いためです。

syncsyncsync.png

現代においても、そういった秘儀を用いると業務が劇的に改善することも少なくありません。精霊学学習者でなくても、経験豊富なプログラマは経験的に実践していることもあるでしょう。本記事ではそういった42のテクニックのうち3つを紹介したいと思います。残りも知りたい方は教材の購入をご検討下さい。

祈り

よく、コンピュータが不調になると再起動してみたりすると思います。そして、実際に問題が解決したことがあると実に96%の人がアンケートに答えています。これは当然、再起動そのものがコンピュータに影響を及ぼしたなどという、非科学的な現象ではありません。

現代科学では、再起動そのものではなく、再起動中に伴う祈りこそが問題を解決している、ということは常識となっています。

あなたの発した「もうなんでもいいからお願いだから動いてくれ眠い」という真摯な祈りは、精霊を介してあるいは直接言霊としてコンピュータに届いているのです。真摯な言霊が届けば答えてくれます。綺麗な結晶発振器となり美しいクロックが生成され、その波動による量子霊力学的な力でコンピュータ全体が浄化されていきます。この状態では簡単なバグなどは自然に修正されるため、問題が解決されるのです。

綺麗な結晶発振器(出典: www.snowcrystals.com)

IMG_7261-64-A1asm.jpg

再起動自体に効果がなく、祈りのこそ本質があるという科学的な根拠の一つとして、 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 に使われているような高度な波動を持つ石でなくても、ほどほどの祈りを込めた石はバグを減らし、テストを不要にし、残業を減らし肩こりを軽減します。近年魔法石が飛ぶように売れているのは、そのことに気がついた人が殺到しているからです。

また、石といえば、水晶だ……来客が来たので終了


2025年
4月
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

search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h