概要 1回1回、行頭に#を挿入したり、行頭の#を削除するのは、結構地味で面倒だと思いますので、vimでコメントアウトを複数行に挿入したり、削除したりする方法を説明します コメントアウトを挿入する場合前のApacheの設定ファイル <LocationMatch "^/+$"> Options -Indexes ErrorDocument 403 /.noindex.html </LocationMatch> <Directory /usr/share/httpd/noindex> AllowOverride None Require all granted </Directory> Alias /.noindex.html /usr/share/httpd/noindex/index.html Alias /noindex/css/bootstrap.min.css /usr/share/h
タイトルがふわっとしてるけど見れば多分わかる。 ghc-compiler-notes 経緯とか 注意: 作ったと書いてるが私の力ではなく主に水無さん(@mizunashi-mana)とわどさん(@waddlaw)のお力添えによるところが大きい。 GHCのソースコードにはNoteと称して有益な(GHCの内部実装等に関する)情報が書いてあることは有名だと思うけど、実際にそれはまとまったりはしてなかったので知る人ぞ知る、みたいな情報であった。こういう他のドキュメントには書いてないような貴重な情報が誰にも読まれることなく眠っているのはもったいないと常々感じていたのでそれを読めるようにしたかった。 このプロジェクトは最近GitLabに移った方のghc/ghcのソースコードに埋められているNotes部分を抜粋しそれを比較的読みやすい形で並べて整理したものである。 現在の仕様一覧(ざっくり) compi
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
