CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
ここ→配列操作の比較表に触発されて、Rubyの文字列メソッドの対応物をJavaとHaskellで探してみました。 Javaの文字列処理がそれほど高機能じゃないのはある程度想定内だったけど、Haskellもなかなか1対1の対応物がない。 lines,unlinesとか逆にあまったけど。 そもそもHaskellのソレって文字列処理用っていうよりほとんど汎用リスト操作関数なわけで。 Haskellって 「汎用性の高い関数を用意したから自由に組み合わせて使ってね」 って思想だと思うわけで。 カリー化された関数の強力な応用力とあいまってこれはこれで一つの便利さの方向性だとはおもう。 ただこれの欠点は 「もっとエレガントで短い書き方があるんじゃないか?」 って不安がいつまでも付きまとう事。 (しかもタチの悪い事にパズルみたいで楽しすぎる!) 自分の修行が足りなくてイディオムを知らないせいもあるけどね。
C++やVisual Basic 6.0の世界でプログラミングしてきた技術者が.NET Frameworkの世界に入ってきてまずおどろくのは、プログラムを実行していると、プロセスが使用するメモリ量がどんどん増えていくことである。「メモリ・リークか!?」と焦ることもあるが、これは正常な動作である。 メモリの解放忘れは典型的なバグの要因であり、メモリ解放を自動化することによって、プログラムの信頼性は向上し、プログラマーの負担も減る。自動的なメモリ解放を行う機構は、ガベージ・コレクタと呼ばれ、解放する行為をガベージ・コレクションと呼ぶ。問題は、ガベージ・コレクションがいつ行われるかであるが、これはメモリが不足してきた場合や、明示的に動作を指示された場合にのみ行われる。つまり、メモリが潤沢に余っている場合には、プロセスの使用するメモリ量が増加するのが正常な動作である。そのままメモリ不足でプログラム
別のファイル名にリネームしたら問題なく添付できる。 trac.logは下記のとおり。 2012-04-18 10:16:12,953 Trac[main] ERROR: Internal Server Error: Traceback (most recent call last): File "D:\TracLight\python\lib\site-packages\trac-0.12.2.ja1-py2.6.egg\trac\web\main.py", line 511, in _dispatch_request dispatcher.dispatch(req) File "D:\TracLight\python\lib\site-packages\trac-0.12.2.ja1-py2.6.egg\trac\web\main.py", line 237, in dispatch r
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く