タグ

programingに関するgabariのブックマーク (5)

  • Perlプログラマの人気No.1エディタはVim | エンタープライズ | マイコミジャーナル

    When you need perl, think perl.org 21日(米国時間)から4日間に渡って、Perlプログラミングにどのエディタ/統合開発環境を使っているかというアンケートがPollDaddyにおいて実施された。 最終的に3,234の投票が実施され、集計結果がPerl IDE and Editor Poll, October 2009において公開されている。公開された結果は次のとおり。 順位 エディタ 投票数 割合 1 Vim (またはvi、gvim) 1097 34% 2 Emacs (またはxemacs) 430 13% 3 Ultra Edit (plainまたはStudio) 224 7% 4 Eclipse EPIC 210 6% 5 そのほか 143 4% 6 Notepad++ 142 4% 7 Komodo IDE 128 4% 8 Komodo Edit

    gabari
    gabari 2009/11/03
    Emacsのシェアが意外と低くてビックリした。
  • ふぁぼったーが負けた本当の理由

    なぜふぁぼったーは英語圏で負けたのかhttp://d.hatena.ne.jp/ono_matope/20091102#1257177656 おれも外人に聞いてみた。7人に聞いてみた。現時点で5人から返答があった。たったの1人に聞いてそれを鵜呑みにするってサービス開発者としてどうなのよ?マーケティング的な力がなさすぎる。プログラマーとしては普通程度の能力あるのかもしれないがその程度の姿勢でサービスは大きくできないよ。あのエントリ読んで「この辺がエンジニアの限界だな」思ったマーケ寄りの人間は多いと思う。さて話がそれるので5人に聞けたことをまとめてみる。あくまでたったの5人だがな。聞くなら気合い入れて数百人に聞くとかしろ。話はそれからだ。1.レスポンスが遅すぎる2.503を何度か見た時点で使う気なくした こんな不安定なサービスを使うお人よしいるわけない3.twitが全然クロールされていない4.

  • 概要設計工程でRedmine導入してみた事例 - T/O

    やっぱり事例だよねということで、自分とこの事例をまとめてみる。 お仕事の概要 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。 期間 => 2ヶ月 メンバー => 3~4名。自分込み。 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。 概要設計に先立ち、要件定義は完了。30項目ほど。 滝。 Redmineの設定など 「概要設計」をバージョンとして作成。 30項目の要件をチケットとして登録。 ターゲットバージョン => 「概要設計」 開始日 => 登録したその日 期限日 => 概要設計完了予定日の2w前 予定工数 => それぞれの見積もり値を設定 担当者 => 設定しない ユーザの権限は全て「管理者」。 5名程度なら問題ないんじゃないの? チケットのフロー 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了 運用方法 タスクの割り振り それぞれが

    概要設計工程でRedmine導入してみた事例 - T/O
  • C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す

    C++0Xの新機能が搭載されたVisual Studio 2010 Microsoftの開発者向け技術情報サイト「MSDN」では、Visual Studio 2010 β1 がリリースされています。IDEがWPFで作られていたり、.NET Frameworkのバージョンが上がっていたりと、Visual Studio 2010では様々な変更/拡張が施されているようですが、C++屋の筆者としては、Visual C++が部分的にせよC++の新規格(通称C++0X)の新しい機能を積極的に取り入れていることが、とても嬉しく思います。 Visual C++ ver. 10に追加されたC++0Xの新機能のひとつ、「ラムダ式(lambda expression)」を少しばかり触ってみましょう。 関数オブジェクトとは C++templateをサポートし、それにあわせてSTLに代表されるテンプレート・ライブ

    C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  • コードコメントに書くべきは「意図」 - プログラマーの脳みそ

    2.トリッキーな実装 ソースを読んだだけではすぐにわからないようなアルゴリズムを採用している場合や、使用しているライブラリのバグ回避のための特殊な処理を行っている場合、または他の人が見たときや自分が数年後に見た時に「なぜここでこんなことを?」と感じる可能性がある場合にはソースコードにコメントを追加するべきだ。これは言わばトリッキーな実装である。 ソースコードのコメント率は20%を切ることが望ましい : 小野和俊のブログ 私はこの部分にはもうちょっと汎用的に「意図」を書くべき、とすることを提案しよう。*1 トリッキーな実装というのは、「普通」ということが分かっていて初めてトリッキーかが分かる。普通か、トリッキーか、というのは時代背景*2というかハード的な制約も関係するだろう。常識は移ろいゆく。人がトリッキーではないと確信して書かれるコードと、トリッキーなコードとの線引きはどうしたらよいのだ

    コードコメントに書くべきは「意図」 - プログラマーの脳みそ
  • 1