タグ

programmingに関するcockokのブックマーク (9)

  • 400万行のコードを15分で見える化! プログラム解析ツール『Understand』で開発効率アップ

    システムの多機能化により、プログラムの内容が複雑化している。テクマトリックスの『Understand』は、プログラムの構造を可視化することで、ソースコードの解析時間を大幅に削減できる開発支援ツール。今回は同社の福永一寛氏に、Understandの機能や特徴について聞いた。 システムの多機能化により、プログラムの内容は複雑化している。既存コードの改修や多人数での開発における情報共有のためには、プログラム構造の理解が必須だが、ドキュメントと実装内容とが乖離している場合も多く、解析自体に工数がかかることもある。テクマトリックスの『Understand』は、プログラムの構造を可視化することで効率的なソフトウェア開発をサポートするソフトウェア開発環境。「組込みシステム開発技術展(ESEC)」にて、同社の福永一寛氏にその特徴を聞いた。 ソースコードの解析作業時間を大幅に削減する『Understand』

    400万行のコードを15分で見える化! プログラム解析ツール『Understand』で開発効率アップ
  • 病みつきになる「動的計画法」、その深淵に迫る

    数回にわたって動的計画法・メモ化再帰について解説してきましたが、今回は実践編として、ナップサック問題への挑戦を足がかりに、その長所と短所の紹介、理解度チェックシートなどを用意しました。特に、動的計画法について深く掘り下げ、皆さんを動的計画法マスターの道にご案内します。 もしあなたが知ってしまったなら――病みつきになる動的計画法の集中講義 前回の『アルゴリズマーの登竜門、「動的計画法・メモ化再帰」はこんなに簡単だった』で動的計画法とメモ化再帰を説明しましたが、前回の説明ではまだ勘所をつかめていない方がほとんどでしょう。そこで、これらを完全にマスターするため、今回はもう1つ具体例を挙げながら練習したいと思います。 どういった問題を採用するかは悩みましたが、非常に有名な「ナップサック問題」を取り上げて説明します。 ナップサック問題とは以下のような問題です。 幾つかの品物があり、この品物にはそれぞ

    病みつきになる「動的計画法」、その深淵に迫る
  • いまさら聞けない「変数の命名規則」 - 基本へ帰ろう

    変数の命名規則って名前がついているのですね・・・というのをさっき知ったので・・ほんといまさら聞けない感じです・・w アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)(Pascal記法) キャメルケース - Wikipedia 複合語の先頭を、大文字で書き始める。 例 : CamelCase ローワーキャメルケース (LCC)、または単にキャメルケース キャメルケース - Wikipedia 複合語の先頭を、小文字で書き始める。 例 : camelCase アプリケーションハンガリアン(ハンガリアン記法) ハンガリアン記法 - Wikipedia アプリケーション ハンガリアンは、間違えたコードを間違えて見えるようにする記法である。 たとえば、論理座標にRelative Positionのrp、絶対座標にAbsolute Positionのapというプレフィッ

    いまさら聞けない「変数の命名規則」 - 基本へ帰ろう
  • ググるな危険:プログラマで、生きている:エンジニアライフ

    だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。 その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。 検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。 そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。 そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。 その新人が「Windowsのレジス

    ググるな危険:プログラマで、生きている:エンジニアライフ
  • WritingTestableCode - テストできるコードの書きかた

    WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この

  • プログラミングのスピードを上げる方法 - teruyastarはかく語りき

    http://q.hatena.ne.jp/1203667934 ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか? プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。 そのため いつもつらい思いをしています。 環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。 マウスもゲーム用の高精度のものを使っています。 調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。 DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。 出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。 単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。 しかし開発速度は効率化とは無縁だとすら感じてい

  • ユメのチカラ: ソースコードの読み方

    ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか? 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな

  • http://ja.doukaku.org/

  • http://tsuttayo.sytes.net/php/env/phpeclipse/

  • 1