トップ «前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|

ToDo:


2018-10-12

_ proto 批判

http://reasonablypolymorphic.com/blog/protos-are-wrong/

proto はもっとよくできる、と直感的に思う、が、この批判は的を射てる部分もあるけど、外してる部分もあるように思う。 wire format への言及が無いけど、わかった上なのかどうかよくわからない。

現状の問題はこうすれば良いよ、と書いてある点については、要するに普通のプログラミング言語に近付けるということであるけど、シリアライズフォーマットというのは当然プログラミング言語と違うわけで、デシリアライズされた構造体をどこまでリッチにしていっても、結局はホスト言語の機能をフルに使う場合はホスト言語で自分で書いたクラスに移し変えるなり、 proto を持ったクラスにサポート情報を保持して使うことになると思う。そうならないシリアライズフォーマットは、 Smalltalk とかそういう世界観だけな気がする

具体的な例としては、参照みたいなのがまず欲しくなってくるものの一つとしてあって、 YAML とかだと参照があったりするけど、それを足したとしても、今度は、検索が線型より速い構造が欲しいとか、なんだかんだでホスト言語側の機能で自動生成されたコードを補うコードを書くことになると思う

で、どうせ補うコードを書くことになるのであれば、シリアライズフォーマットの仕様はリッチすぎず(ところで最初に批判されてる oneof と map はどちらも後づけ syntax sugar みたいなものだという理解)、便利さと速度やフットプリントのトレードオフがあれば、常に速度&フットプリントの方に倒す、というのは理に適っていると思う。 proto の改善できる部分のうち、どの部分は速度&フットプリントを犠牲にせず使えるかは、ぱっとはわからないなあと思う

API (C++ と Python だけについて書いています) について、 proto は読む方の API はまあ普通で、問題はあると思うがかろうじて苦労なく使えるレベルだと思う。新規にデータを作る時の API も、こっちは多少苦労する程度に気持ち悪い API ではあると思うけど、まあ覚えればなんとかなる。

ただ、 proto の編集は批判されている通り、困った問題が起きることが多い。ただ、それはこう、データを編集しなければならないならちゃんとホスト言語の構造体に移しかえて、編集が終わったらデシリアライズしなさい、というだけのことかなあと思う。めんどくさいよーと思うかもしれないけど、

int LoadInt(FILE* fp) {
  int v;
  size_t r = fread(&v, sizeof(v), 1, fp);
  if (r != 1)
    return -1;
  return v;
}
bool LoadString(FILE* fp, string* s) {
  int len = LoadInt(fp);
  if (len < 0)
    return false;
  s->resize(len);
  size_t r = fread(&(*s)[0], 1, s->size(), fp);
  if (r != s->size())
    return false;
  return true;
}

みたいな関数をいちいち作ってやるのに比べればマシだしねぇ…

なんか、 proto 作った時に、アプリケーション固有の proto と対応した boilerplate コードを作りたい時がある気がしていて、そういうのが作りやすいと良い気がするなぁとか思う。直近での対処は proto とアプリケーション固有コードを両方とも生成することで対処したけど、まあこれで十分という感もある

(18:48)


2018-10-04

_ MNIST in Excel

https://www.youtube.com/watch?v=yKt7SI6vexc

既存研究だったか…

(01:37)


2018-10-03

_ ABC

https://www.quantamagazine.org/titans-of-mathematics-clash-over-epic-proof-of-abc-conjecture-20180920/

どうも間違ってたぽいという話がある、と聞いてせつない。説明を読んでみると実際結構ダメそうな雰囲気なんだなあ

変わった物の見方するユニークな人だけど、 ABC 予想を証明した大天才らしい、なんかすごい、から単なるユニークな人になってしまうという落差(いやそれでも偉大な数学者なんだろうけど。。)

(23:48)


2018-10-02

_ むっちゃおもしろかった

パタソン先生 on CPU

https://atscaleconference.com/videos/scale-2018-keynote-a-golden-age-for-computer-architecture/

(23:24)


2018-10-01

_ structual subtyping

https://twitter.com/kazuho/status/1046566559160791040

とはいえ直行もしてないという理解で、コンテナ以外の用途はたいてい structual subtyping で十分ではあるんかね

クラス template の用途て何があるんだっけ

  • コンテナ
  • static duck typing と僕が呼ぶもの (algorithm とか)
  • TMP

あたり……だけ?

(11:07)

_ huawei

https://smhn.info/201809-huawei-oppo-benchmark-test

僕のスマホでも試してみるかな

(15:00)

_ KotlinConf

https://www.linkedin.com/pulse/talk-amsterdam-nikolay-igotti/

なんだかわからないけど面白そう。少し知った人

(15:04)


2018-09-28

_ ffrk

ヘカトンケイル

バッツ覚醒でなんとかなるようになった。よくわかってないけど、ダメージ与えすぎると2回目のフラッシュを飛ばせなくなって詰む

  • ウララはプロテガから絶マンダを例外なく繰り返す。ここいじるとダメなことが多い
  • ファリスはゲージ溜めて2回弱体撃ってあとは適当にデバフ
  • ラムザはいかたくバッツ、いかたくウララ、魔石をどっかに挟んでおうえん、いかっておうえん、みたいな感じだと思う
  • アタッカーは12秒とかそのへんで攻撃に。バッツは絶纏覚醒の順で良さげ

(21:12)

_ R_X86_64_64

とかどういう時にコード領域に生えるんだよ的なことを思ってたら、 -mcmodel=large というのをつけると 64bit relocation が発生しまくるらしい

( '-') gcc -mcmodel=large -c hello.c && objdump -dr hello.o G R_X86
                        13: R_X86_64_GOTPC64    _GLOBAL_OFFSET_TABLE_+0x9
                        20: R_X86_64_GOTOFF64   .LC0
                        31: R_X86_64_PLTOFF64   puts

とか(涙ぐましいことやってて長くなるので grep した)

( '-') gcc -fno-PIC -mcmodel=large -c hello.c && objdump -dr hello.o

hello.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <main>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 bf 00 00 00 00 00    movabs $0x0,%rdi
   b:   00 00 00
                        6: R_X86_64_64  .rodata
   e:   48 b8 00 00 00 00 00    movabs $0x0,%rax
  15:   00 00 00
                        10: R_X86_64_64 puts
  18:   ff d0                   callq  *%rax
  1a:   b8 00 00 00 00          mov    $0x0,%eax
  1f:   5d                      pop    %rbp
  20:   c3                      retq

とか

後者はなんかコンパイラ初心者が作ったコンパイラが吐きそうなコードで親しみが湧く

またどうでもいい知識を得た…

(22:00)


2018-09-24

_ インクリメンタル

http://shinh.skr.jp/m/?date=20091014#p01

この時の感覚は割とわかる気がして、なんか X でわからんかったら X Y みたいな感じでインクリメンタルにやってるんだろうな

だからどうということはないが

(00:32)

_ そんななかで

http://shinh.skr.jp/m/?date=20180829#p01

書き忘れてたけど、 ARC というプロジェクトにいたこと、当時のあのチームクッソ好きなんで、周りも全て最高なんだが、特にそのチームのリードだった人と仲良くできたのは、すごく良い経験だったと思っている

懐古はともかく、現チームは、僕自身の立場は残念ながら謎別動部隊みたいな感じは継続しているが……スクラム開発というやつをやっているらしい。

僕はまあ、これの良し悪しとかわかんないし、というか、この手の、プロセスに興味が持てないのだけど…… (http://shinh.skr.jp/m/?date=20180121#p01)

いや、なんかいいなって思ってるのは、 ARC の大将が(正確な発言ではないと思う)言っていた、「バグは一週間かそこらで終了させることが望ましく、お前が assignee であればお前は実際それをやっているべきであり、そうでないのに、どうもお前が一番詳しいから、とかそういう理由で適当にバグをアサインするべきではない」という教えで、なんかこれは、最初よくわかんなかったけど、あとでこう本当に正しいポリシーだな……と思ったんだよね

これなんか、普通のことじゃん、て思うと思うけど、まあ僕も思うけど、なんか会社の文化として、バグに assignee がいない = ( 責任者がいない | プロジェクトに責任がない ) 、バグの assignee を渡す = 責任の譲渡 、みたいな雰囲気のあるカルチャーの中では、なんだかカルチャーショックだった

ような そうでも ないような

プロセスに僕は興味ないが、現チームはどうもこいう感じのことやってんのかな?て気がするので、なんか良さそう、と思うのであった

しらんけど

(00:58)

_ 蒼田 夏の生酒

いいかげん、好みだった日本酒はメモっておこう

(23:56)


2018-09-19

_ 設計ミス

設計ミスってると、ミスってることはわかっても、ミスってるコードに頭がひっぱられて、正しい方針がなかなか出てこない。正しい方針に思い至ってからも、ミスったコードに頭がひっぱられて方針をつらぬけない。全体としてミスったコードが存在しなかった方が速かったんじゃねえのこれってくらいのことになりうる。

こういうのをバイアスかかってない思考の人が強制軌道修正できるのは、コードレビューの良さではあるよなぁ

どっかで設計ちゃんと見直さないと破綻しかない

(09:00)

_ isucon

ひっそりと参加してみたけど、 SQL わかんねえな、って感じで気がついたら終わっていた。サーバ分割とかやろうとしてムダな時間すごして、その後すごい遅いとこいじって一番良かった時で 10000 点くらいの

(20:37)


2018-09-04

_ pezy

が今の家からクソ近いことに気付いた

(10:12)

本日のツッコミ(全4件) [ツッコミを入れる]

_ wo [じゃあ多分家も近いので、なんか食べに行きましょう。]

_ shinh [お、ぜひですー!いつがいいですかね]

_ wo [今週来週日曜昼なら行けます。 エチオピアに行ってみたいですが、どうですか?]

_ shinh [エチオピアいいですね。たぶん今週日曜日で大丈夫です。時間とかはもうちょっと後で相談させて下さい。メール……はなんかこ..]


2018-08-31

_ 345c 7140cpp 2795py

(20:45)


2018年
10月
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
1.shinh(2018-09-05 12:26) 2.wo(2018-09-05 03:56) 3.shinh(2018-09-05 01:49)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h