mrubyを小さくしたり大きくしたりした話 - スペクトラム
最近mrubyにコミットしているので自分の活動をまとめます。 mrubyを小さくした話 mrubyでは、文字列の扱いはシンプルにchar*を構造体でラップしていました。 struct RString { MRB_OBJECT_HEADER; mrb_int len; union { mrb_int capa; struct mrb_shared_string *shared; } aux; char *ptr; }; そのため1つの文字列毎に、構造体分と文字列分の2回のmalloc/freeが発生していました。 ここでCRubyのRStringを見てみます。 #define RSTRING_EMBED_LEN_MAX ((int)((sizeof(VALUE)*3)/sizeof(char)-1)) struct RString { struct RBasic basic; union {
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
