ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
巨大リポジトリの世界 #22
Facebook のエンジニアが git のメーリングリストに投げたメール[1]が話題になっていた。大体こんな内容だ。 Facebook ではgitを広く使っているが、リポジトリがでかくなるにつれて性能が問題になってきた。今後も git を使い続けるべきか検討するために、テスト用の超巨大リポジトリを作って性能評価をしてみたところ、遅すぎるという結果がでた。性能を上げるにはどうしたらいいだろうか？ これに対して、リポジトリを分割すれば？という反応が寄せられたが、元のエンジニアは、以下のような感じに答えている。 リポジトリを分割するという試みはすでに始めている。が、これは長期的なプロジェクトだ。我々のコードは複雑に絡み合っている。ひとつの巨大なリポジトリを共有することでたくさんのメリットがあるから、無闇に分割するのはよくない。そもそも、バージョンコントロールシステムの性能上の制約のせいで、コー
適切な抽象度を求めて #5
以前に思いついたジョークでこんなものがある。 初級プログラマへのアドバイス コードを読みやすくするために、もっと抽象度を上げよう。 上級プログラマへのアドバイス コードを読みやすくするために、もっと抽象度を下げよう。 これはジョークなんだけど、抽象度が低すぎても高すぎてもコードは読みにくくなる、というのはある程度当たっていると思う。 抽象化が低すぎるケースを考えてみよう。数百行もある長大な関数に何十もの変数があり、ループのネストはやたら深いし、しかも変数は途中で別の用途に再利用されちゃっている、なんていうとんでもないことになっているコードを見たことがはないだろうか？私はある。というのも私は長いこと、そんなコードばかり書いていたからだ。複数の関数に分割するなり、状態を構造体にまとめるなり、変数のスコープを制限するなり、抽象度をあげることでコードを読みやすくできる、ということを学んだのはだいぶ
coLinux の開発版のスナップショット - bkブログ
coLinux の開発版のスナップショット ひさびさにcoLinux (Cooperative Linux) をインストールしよう思い立ち、開発版のスナップショットを入れてみました。 まずはスナップショットのページから devel branch のバイナリをインストール。本日の時点では Snapshot 20070708 of version 0.8.0 with kernel 2.6.17 が最新でした。 インストールしてすぐに気づいたのは、設定ファイルのフォーマットの変化です。以前はXMLだったものが、行志向の単純なフォーマットに変更されていました。 今回はネットワークに slirp を使うことにしました。以前にインストールしたときは TAPドライバを選択して、設定がなかなか厄介だったのですが (0.6.4より前の古いバージョンでは slirp は不安定だったようです)、 slirp
いやなブログ - 文字列操作の比較表: Ruby, Python, JavaScript, P...
文字列操作の比較表: Ruby, Python, JavaScript, Perl, C++ Ruby, Python, JavaScript, Perl, C++ の文字列操作の比較表を作りました。配列操作の比較表の続編です。間違いなどがあったらご指摘いただけると助かります。 Ruby (String) Python (str) JavaScript (String) Perl C++ (std::string)
C++と Pthreads でミニマルなHTTPサーバを書く - いやなブログ
C++と Pthreads でミニマルなHTTPサーバを書く 『UNIXネットワークプログラミング』を読んでいると、自分でも何かネットワーク系の小さなプログラムを書いてみたくなりました。そこで、ミニマルなHTTPサーバを C++と Pthreads で書いてみました。 同じ著者の「詳解UNIXプログラミング」もそうだったように、今回の本もほとんどすべてのページに、重要なことが書かれています（最後のほうのXTIの部分は例外かもしれませんが）。 たとえば、27章ではネットワークサーバの実装として、次の設計方針がそれぞれ検討され、実際のコード付きで解説されています。 クライアントごとに fork 事前に fork - 各プロセスで accept 事前に fork - ファイルロックで accept を保護 事前に fork - Mutex ロックで accept を保護 (PTHREAD_PRO
信じ込ませる - 学校では教えてくれないバッドノウハウ英語 #11
信じ込ませる - 学校では教えてくれないバッドノウハウ英語 #11 学校では教えてくれないバッドノウハウ英語の11回は、 hoge を取り上げたいと思います。 hoge は日本のプログラマの間で、「何か適当なもの」を指す変数として親しまれています。英語圏では hoge の代わりに foo がよく使われます。このような変数は、メタ構文変数(metasyntactic variable) と呼ばれ、ソフトウェアに関する議論や文書などで広く用いられています。 hoge は日本ではなぜかメタ構文変数として定着していますが、英語では「信じ込ませる」という意味のれっきとした単語 (ホウジと発音) です。日本人以外に対して hoge を用いると誤解を生じる可能性があるため注意が必要です。hoge は通常、動詞として用いられます。 例) Please don't hoge me about the sto
bkブログ
bkブログ プログラミングやバッドノウハウについてのブログ 2004-2011年に書いていたブログのアーカイブです。 机の上のもののワイヤレス化 - Microsoft Arc Keyboard の導入 iPodは何を変えたのか? 人が問題にぶち当たったときには、どうするか? ソフトウエアの肥大化について、の続き ソフトウェアの肥大化について ある程度の年齢を迎えたプログラマが抱える悩み Unicode の雪だるま 設定ファイルの整理 - Emacs 編 設定ファイルの整理 - zsh 編 パターン、Wiki、XP ～時を超えた創造の原則 マッキントッシュ物語 - 僕らを変えたコンピュータ GNU diff の地味だけど便利な機能 C++ の string と vector の reserve() の挙動 暗号化 - プライバシーを救った反乱者たち Best Software Writin
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
