タグ

programmingに関するisdyyのブックマーク (35)

  • 近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)

    2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー

  • ドメインロジックとSQL

    以下の文章は、Martin Fowler による Domain Logic and SQL の日語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの(rich SQL queries)を用いるので悪しからず。 エンタープライズアプリケーション(訳注:以下、EA)構築に関する(私の近著『P of EAA』など)を読むと、ロジッ

  • 細かすぎて伝わりにくいTopCoderのコーディングスキル向上マジック

    細かすぎて伝わりにくいTopCoderのコーディングスキル向上マジック:最強最速アルゴリズマー養成講座(1/3 ページ) 競技プログラミングはレベルの高い人たちの集まり――そんな考えを持っている初心者の方、TopCoderはあなたのコーディングスキルを爆発的に高める魔法のような場です。今回は、初心者にこそお勧めしたいTopCoderの魅力について考えます。 教育的な観点から見るTopCoder 今回からTopCoderに関する実践的アルゴリズムを解説していく予定でしたが、序盤のうちに触れておきたいことがありましたので、今回の枕は“教育的視点から見るTopCoder”というテーマで少し書こうかと思います。 まず、最初に宣言しておきたいことは、この連載は初心者向きである、ということです。「どう考えても上級者向けだろう」という意見はたくさんの方から寄せられていますが、筆者は、まだプログラミングレ

    細かすぎて伝わりにくいTopCoderのコーディングスキル向上マジック
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 優秀なプログラマにたまに起こる逆行(退行)現象

    あれは私がまだ大学助手をしていたころだから3年ほど前のことだと思う。 私の勤めていた大学(情報系)では「プログラミング研究会」みたいなサークル活動が行われていて プログラミングの講義を受け持っていた私はそのサークルにちょくちょく顔を見せるようになっていた。 そこにはとびっきりかわいい女子学生が一人いたのだけれど、その子はゲームが大好きで 「自分でもゲームが作りたい」と一念発起してゲームコンテストに作品を出品することになった。 しかし、彼女はプログラミングの講義(Java)を1年くらい受けているものの、 格的なモノを作った経験がなく、ひとりでは行き詰まりをみせているようだった。 彼女はひとりでいることが多く、パソコンに向かって黙々とプログラムを書いているのをよく見かけた。 それを気にかけていた私はたまに彼女をランチに誘うようになり、彼女の方もしだいに私に打ち解けてきた。 私たちはだんだんと

    優秀なプログラマにたまに起こる逆行(退行)現象
  • http://www.nabble.com/Models-as-Singletons-tt24575704.html

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 【プログラミングで感じた理不尽な事】 何でも構いません。…

    【プログラミングで感じた理不尽な事】 何でも構いません。 あなたがプログラミングをしていて「理不尽だ」と感じた事を教えて下さい (HTML も含めます)。 例えば、コンパイル前なら完全に動作するにも関わらず、何故だかコンパイルするとエラーを生じてしまうであるとか、 a = b + c と記述したのに、a には b + c どころか z などという考えられない値が…とか、 開発環境として用意されているエディタは何でこんなおかしな仕様なのか、等々。 それが生じた言語やハード、OS も併せて書いて頂けますと幸いです。 ※ 但し、依頼者 (クライアント) との間で生じた様な人間的事柄については除かせて下さい

  • オープンソースをライセンス的に正しくつかうための11のチェックポイント - builder by ZDNet Japan

    「オープンソースカンファレンス2009 Sendai」が1月24日、宮城県仙台市の東北電子専門学校で開催された。公式サイトのタイトルには「来ないとお仕置きだっちゃ☆」との追記が見えるが、アットホームな雰囲気の中で進行するカンファレンスであった。 稿では、NEC OSSプラットフォーム開発部 エキスパートの姉崎章博氏による講演「OSSをライセンス的に正しく使う/プロプラだけの製品とするための11のチェックポイント」を紹介する。なお、特に断りがない限り、全て日の著作権法について説明している。 オープンソースソフトウェアをライセンス的に正しく使うために 姉崎氏が挙げたチェックポイントは次の11点。 その社製プログラム、すべて自社の著作物ですか? 商用プログラムを同梱している場合、必要な手続きはお済みですか? 他人の著作物を使用していないことを確認するためコード検査をしていますか? OSSの

  • DRY (Don't Repeat Yoursel) の意味を勘違いしてたかも - kなんとかの日記

    なんか、DRY の原則をすっげー勘違いしてたかも。 The DRY (Don't Repeat Yourself) Principle states: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. http://c2.com/cgi/wiki?DontRepeatYourself DRY (Don't Repeat Yourself) っていうから、単に「同じことを繰り返さない」という意味だと思っていた。だから、たとえば class Node end class Element < Node def accept(visitor) visitor.visit_element(self) end end class Text < N

    DRY (Don't Repeat Yoursel) の意味を勘違いしてたかも - kなんとかの日記
  • ゲームプログラマだけどなにか質問ある?

    1 名前:以下、名無しにかわりましてVIPがお送りします:2009/01/01(木) 19:05:18.46 ID:H67nJ+Kz0 答えれる範囲で答えます 3 名前:以下、名無しにかわりましてVIPがお送りします:2009/01/01(木) 19:06:11.23 ID:F7f5GAvH0 年収は? >>3 400万くらいかな 4 名前:VIPの帝王 ◆koxjyhajbE :2009/01/01(木) 19:06:31.93 ID:ijQ2eBqp0 やっぱブラックなの? >>4 他の業界をしらんからなんとも言えんが、 α、β付近になると終電帰りがデフォになる。泊まりはそれほどない。 残業代はなし。これはブラックなのかな? 5 名前:以下、名無しにかわりましてVIPがお送りします:2009/01/01(木) 19:06:35.75 ID:+TELd9IE0 DirectXとOpenG

  • Concepts + Principles - プログラミングの原則 - リファクタリング

  • プログラミングファースト開発 - ひがやすを技術ブログ

    プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら

    プログラミングファースト開発 - ひがやすを技術ブログ
  • http://diaspar.jp/node/176

    See related links to what you are looking for.

  • takeda-soft.jp

    takeda-soft.jp 2024 著作権. 不許複製 プライバシーポリシー

  • 最適化の心得 or HTTP::MobileAttribute最適化祭りに参加してみた - D-6 [相変わらず根無し]

    最適化の心得 or HTTP::MobileAttribute最適化祭りに参加してみた HTTP::MobileAttributeの最適化祭りに突発的に参加してみた。 正直言うと未だにHTTP::MobileAttributeの中身であるClass::Componentを分かってない。なのでできることも限られてるわけだが。 今回のミニ祭りを見ていてよくわかるのは結局のところスピードに最も影響があるのは端的なコードの書き方ではなく構造(ストラクチャ)を見直す事であるというだ。id:tokuhiromのところでパフォーマンスチューニングの結果を追ってる人はわかると思うけど、結局俺が参加したのはもう当にコードの書き方をチューニングするというレベルのところで、例えばループをアンロールしてif/elseで実装してみるとかね。でもそこはどんなにがんばっても数%のパフォーマンスゲインにしかならない。

  • メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ

    その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの

    メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
  • 「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

    昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

    「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
  • MOONGIFT: » VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」:オープンソースを毎日紹介

    ※ 画像は一部公式サイトデモより Web2.0(?)の特徴はCGMや共有と言ったキーワードだ。サイト側から与えられるコンテンツではなく、ユーザが皆で協力してコンテンツを作り上げていく楽しさがある。ブックマーク、ニュース、コミュニティ…様々な要素がシェアされている。 そうした中、これもまた新しい共有の要素になるだろう。それはソースコードだ。 今回紹介するオープンソース・ソフトウェアはReview Board、ソースコードレビュー共有サービスだ。 Review Boardはリポジトリを登録し、そのDiffファイルを使ってReview Board上でソースをグラフィカルに表示する。そして差分に対して皆でコメントしていくのだ。ソースの一部分に対して的確にレビューできるので、分かりやすい。 SubversionやCVS、Perforce、Git、Mercurialのリポジトリに対応している。興味深い

    MOONGIFT: » VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」:オープンソースを毎日紹介
  • ActivePerlの開発元、ActiveState製エディタがオープンソース化·ActiveState Komodo Edit MOONGIFT

    プログラマにとって、エディタは生産性に大きく関わる重要な要素だ。Windows向けのキーバインドのエディタを使っていても良いが、サーバにつないで修正を行おうと思うとviやEmacsなどでキーバインドが慣れない、なんてこともある。 特にviやEmacsが良い、という訳ではないがマルチプラットフォームで動作するエディタを選ぶのは大事だと思う。そこでこれを試してみてはいかがだろう。 今回紹介するオープンソース・ソフトウェアはActiveState Komodo Edit、ActiveState社製のプログラマ向けエディタだ。 ActiveState Komodo Editは元々シェアウェアだったようだが、最近オープンソース化された。ActivePerlの開発もとだけあって、相当に優秀なソフトウェアだ。WindowsMac OSXLinux版が提供されている。 各種言語(Perl/PHP/Ru

    ActivePerlの開発元、ActiveState製エディタがオープンソース化·ActiveState Komodo Edit MOONGIFT