デッドコードは取り除かなければならない
デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。 デッドコードの削除は、技術的な問題ではない。Kevlin Henney氏によると、それは考え方と文化の問題だ。 独立したコンサルタントでトレーナであるKevlin Henney氏が、ヨーロッパテストカンファレンス 2017において、基調講演「やり方の間違い」を行った。この基調講演で、デッドコードが実行されたために、ある企業が何億ドルもの損害を被ったことを発表した。 InfoQは、このカンファレンスをQ&A、要約、記事で扱う。 ソフトウェアの失敗は、個人的に不便だったり、迷惑だったりするが、経済的、または、社会的に重大な影響を与えることもある。Henney氏は、小さな不具合のせいで、何百万ドルもの損害を出した例をいくつか
言語処理サーバーとそのプロトコル - 檜山正幸のキマイラ飼育記 (はてなBlog)
随分と前にErlangをいじっていたとき、Distelというツールを使っていました。DistelはEmacs上のErlang開発環境なのですが、関数に対するソースの場所を実行中のErlang処理系に問い合わせます。現在のErlangソースコード群に対して一番確実な知識を持っているのはErlang処理系自身なので、その処理系に聞きにいくわけです。 TypeScriptでも同じ発想のツールがあります。tss（TSServer、https://github.com/clausreinke/typescript-tools）とtss.el（https://github.com/aki2o/emacs-tss）です。tssは、TypeScriptコンパイラの能力と知識を、対話的コマンドラインツールとして提供するものです。人間が使うものではなくて、他の開発ツールがコンパイラ機能（主に構文解析）を利用し
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://labs.cybozu.co.jp/blog/kazuho/archives/2009/02/ssd.php
https://labs.cybozu.co.jp/blog/kazuho/archives/2008/03/fastr.php
