OOMKillerに亭主を殺されて一年が経ちました。 - 私が亭主と出会ったのは今からちょうど4年2ヶ月前、私がGentoo... - Yahoo!知恵袋
OOM Killerに亭主を殺されて一年が経ちました。 私が亭主と出会ったのは今からちょうど4年2ヶ月前、私がGentooをインストールしていたときでした。 亭主はそれなりに経験があるkernel hackerだったので、いとも簡単にGentooをインストールしてくれ、私は一目惚れしてしまいました。 幸い亭主も私も同じVim教だったので、教会で素敵な結婚式を挙げることができました。 少し下品な話ですがmakeに励んだおかげで子宝にも恵まれ、私たちは幸せに暮らしていました。 でも、二人とも気づかなかったのです。 まさか私たちのメモリが限界を迎えていたなんて、思ってもみませんでした。 「メモリ不足な昔の話だからどうせ私たちには関係ない」 - そう思っていたのが間違いだったのです。 亭主は突然、あの悪名高きOOM Killerに殺されてしまったのです。 そこからは悪夢のような日々でした。 毎日毎
プログラムのコメントに『何をしているコードか』を書いても無意味なので、代わりに『なぜそのようなコードになったのか』を書くようにしよう - じゃがめブログ
タイトルで全部言い切ってしまいましたので、後は冗長に書いてブログエントリーに仕立てます。 職業上、プログラムを毎日観ていていますが、一番多いコメントが『何をしているコードか』というものです。「ここでトランザクションを開始する」「もしEOFだったらファイルを閉じる」「セミコロンで分割して最初の文字を取得する」などなど…… それって、要ります？？ 構造や内容については、その言語が読める人なら誰でも解るものです。そもそもコードを読んでる時点で当たり前の部分はクリアしている人のはずなのだから、上記のような『何をしているコードか』は書くまでもないこと*1で、不要なコメントです。 不要なコメントは削除しましょう。 コメントはコンパイルするときに無視されるものです。ソースの内容とコメントが食い違っていてもコンパイルエラーは出ません。コメントは増えれば増えるほど、ソースの内容と齟齬があるという危険性が増し
クリエイティブなプログラマーから学ぶ14個の事柄
世間には非常にクリエイティブで独創的なプログラマーの人が数多くいますが、そんなプログラマーから学べることがたくさんあるようです。プログラマーに限らず、さまざまなことにも当てはまるようなことばかりで、ほかの仕事をするにしても非常に役に立ちます。ではクリエイティブなプログラマーからどのような事が学べるのか見ていきましょう。 詳細は以下より。Creative Code: 14 Ways to Learn From Creative Programmers | LifeDev 1.さまざまな分野に手を伸ばし学び続ける プログラマーは常に新しい言語を学んでいきます。同じように、さまざまな分野に手を広げ、学び続ける姿勢が大切である。 2.土台の部分から物事を始める 物事を土台から固める方がよりクリエイティブな解決方法を見いだすことができる。 3.すべての事に疑問を投げかける 何事にも疑問を投げかけてい
プロパティに対応するインスタンス変数の命名規則について - Awaresoft
最近になって変わったObjective-Cのインスタンス変数の命名規則について。 プロパティに対応するインスタンス変数の変数名をプロパティ名と別にすべきか、また、インスタンス変数名をアンダースコア(_)で始めるべきかどうか、さまざまな場所で議論になっているのを見てきて、自分も長い間悩んだ結果、結論が出たのでその経過をまとめておきます。 背景をとばして結論だけ見たい人はこちらへ。 iTunes Uのスタンフォード大学の"CS193p: iPad and iPhone Application Development"の講義は、iPhoneアプリをこれから作ろうという人にはもちろん、既に作っている中級者の方にとっても、見る価値があると思います。 特に、Paul Hegartyによる2011年秋の講義はiOS5に完全に対応していて、説明も非常に分かりやすく、必見です。何と言っても、こんな白髪白髭の
見やすいコードのために出来るたった一つのこと - 日々常々
タイトルは釣りっぽいですけど、結構まじめ。 フォーマッターを使用すること。 これが全てです。「スペースがどうこう」とか「括弧の位置がどうこう」とかどうでもいいです。そんな美的感覚でかわるような枝葉の話に結論は出ません。 コードフォーマッターを使用してください。そのプロダクトを通して、統一された同じフォーマッターでフォーマットすること。コードはそれだけで格段に見やすくなります。個々人が好き勝手にやったり、気をつけたり、CheckStyleなどでの見た目の警告を処理したり……そんなのしてたら不統一で見難いコードにしかなりません。 個人個人での見やすさとかはあります。当然です。例えば変数代入のイコールの位置がそろってる方が見やすい人もいます。変数宣言は1行開いてた方がいいって人も、メソッド間は2行開いてた方がいいとか、賛同できませんけどそんな人も居ます。そう言うときは自分専用にフォーマットして、
コーヒーサーバは香炉である » 外部SDKを入れる際にとりあえずUDIDを取れないように細工をする
「iOSアプリを開発していて、自分はUDIDを使うのはイケナイという主義なのに、外部のライブラリ (ソースの読めない広告系SDKとか) を入れたらなんだかUDID取得してゴニョゴニョやってるじゃん! 聞いてねーよウワァァァン!!!」という事故を防ぐためには、こんな具合に、UIDevice.uniqueIdentifierを上書きしちゃうといいかも。 (UDIDkiller.h) @interface UIDevice (UDIDkiller) -(NSString*)uniqueIdentifier; @end (UDIDkiller.m) #import “UDIDkiller.h” @implementation UIDevice (UDIDkiller) -(NSString*)uniqueIdentifier { NSLog(@”CAUTION!!! UIDevice.u
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2012/12/19/20121218print-happy-25th-birthday-perl/
TechCrunch
https://jp.techcrunch.com/2012/03/01/20120229coderdojo-hits-the-us/