taichi

コードレビューの基本

---

一番大事な事

ソースコードはプロジェクトの共同所有物である

• 誰かだけが触れるコードを無くす

rui314

MIPSのABIは変だという話をこないだのシステムプログラミング会でしたら、ややザワッとしたので、なにがおかしいのかというのをちょっとまとめてみました。まとめてみて思いましたが、やっぱりMIPSのELFファイルはちょっと変です。

謎のmixed endianフィールド

これが僕は一番ひどいと思ったものです。

ファイルにマルチバイトの数値を保存するときはエンディアンというものが問題になります。たとえば0xBEEFという2バイトの数を保存するときは、1バイト目にBE、2バイト目にEFを書くか、逆順で書くかは、ただの決まり事でどっちでもいいわけですが、書く側と読む側で認識があっていないと困ります。世の中的にはリトルエンディアン（下位バイトから書く）のが主流ですがビッグエンディアンなシステムもあります。

それがですね、MIPSのELFヘッダのr_infoという64ビットのフィールドはリトルエンディアンでもビッグエンディアンでもない謎なエンコーディングになっています。具体的には下位32ビットが最初にリトルエンディアンで書かれていて、ビッグエンディアンでエンコードされた上位32ビットがそれに続くという構成になっています。つまりリトルエンディアンだとABCD EFGH、ビッグエンディアンだとHGFE DCBAとなるところが、MIPSのmixed endianだとEFGH DCBAというふうにファイルに書かれていることになります。

djspiewak

Explaining Miles's Magic

Miles Sabin recently opened a pull request fixing the infamous SI-2712. First off, this is remarkable and, if merged, will make everyone's life enormously easier. This is a bug that a lot of people hit often without even realizing it, and they just assume that either they did something wrong or the compiler is broken in some weird way. It is especially common for users of scalaz or cats.

But that's not what I wanted to write about. What I want to write about is the exact semantics of Miles's fix, because it does impose some very specific assumptions about the way that type constructors work, and understanding those assumptions is the key to getting the most of it his fix.

For starters, here is the sort of thing that SI-2712 affects:

def foo[F[_], A](fa: F[A]): String = fa.toString

pathikrit

/**
 * Solves the n-Queen puzzle in O(n!)
 * Let p[r] be the column of the queen on the rth row (must be exactly 1 queen per row)
 * There also must be exactly 1 queen per column and hence p must be a permuation of (0 until n)
 * There must be n distinct (col + diag) and n distinct (col - diag) for each queen (else bishop attacks)
 * @return returns a Iterator of solutions 
 *     Each solution is an array p of length n such that p[i] is the column of the queen on the ith row
 */
def nQueens(n: Int): Iterator[Seq[Int]] = 
  (0 until n)

alexandru

Monix Task: A diverging design

This document is about Task, an alternative for Scalaz's Task or Scala's Future. Note this is work in progress and this document suffered multiple modifications already:

• Jan 26, 2016
• Dec 23, 2015
• Dec 22, 2015
• Dec 21, 2015
• Dec 20, 2015

hashrock

シーケンス図とかフローチャートをしごとで描画することになった場合、 テキストから生成できたら楽なので、それ系のツールまとめ

GraphViz

http://www.graphviz.org/

• C製
• Doxygen, Moinmoinなどと連携可能
• ブロック図、クラス図、ネットワーク図など

kazuho

大きなテキストファイルをawkで処理するときにcatで投げ込むと速い理由のような事象が発生する原因についての推察。

自信はあまりない！

Linuxカーネルのreadahead実装についての理解

• __do_page_cache_readaheadは、次にreadaheadを実行すべきページについてのみReadaheadフラグをたてる
• 次にreadaheadを実行すべきページ「以降の全てのページ」ではない
• do_generic_file_readはReadaheadフラグの立っているページをreadするタイミングでpage_cache_async_readaheadを呼ぶ
• page_cache_async_readaheadはBDI_sync_congestedが立っている場合はreadaheadしない

gakuzzzz

UserId などの型はどうするべきか

1. primitive 型をそのまま使う

case class Person(id: Long, name: String, organizationId: Long)
object Person {

  def groupByOrg: Map[Long, Seq[Person]] = ...

azu

Incremental DOM

Introducing Incremental DOM — Google Developers — Medium

Reactやvirtual-dom、Glimmer(Ember)などVirtual DOMの実装は色々あるが、これらのVirtual DOM実装には2つの問題がある

• 既存のテンプレート言語を利用していない(しにくい)
• モバイルでのパフォーマンス、特にメモリに関しては大きすぎる

これらを解決するためにIncremental DOMと言うものを作っている(WIP)

yudai

Oracle v. GoogleのAPI著作権裁判の話

「OracleとGoogleの判決文を斜め読む」を読んで裁判の経緯は理解できたものの、判決の詳細があまり理解できなかったので判決文を自分で読んだ。法律的な難しさはあまりなく、技術的な論点と関係する条文および過去の判例などが非常にわかりやすく解説されており、判決の根拠もたとえ話を交えて書かれているなど非常に読みやすい印象を受けた。

• 判決文

全体の内容としては比較的単純で「あらゆるプログラムのコードは著作権で保護される。ただしFair Useによる合法的な利用に関しては差し戻し審で審議せよ」という事のようだ。実は「API」という言葉は一切判決文には出てこないため、内容を良く読む必要がある。

17 U.S.C. 102(b)を巡るGoogleの主張