タグ

2012年11月11日のブックマーク (6件)

  • 設計と実装の狭間で - 急がば回れ、選ぶなら近道

    ・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて(懐古趣味の老人を除いた)皆さんが毛嫌いするCOBOL+汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず

    設計と実装の狭間で - 急がば回れ、選ぶなら近道
    takamR1
    takamR1 2012/11/11
    「何をどうするのか、最後まで考える」ということです。
  • Redmineプラグインを作るなら読むべき本家チュートリアルの日本語訳

    Redmineのプラグインを作りながらRailsのテスト方法を学ぼうと思ったら、プラグインの作り方すら完全に忘れていたので、備忘録としてredmine.orgのPlugin Tutorialを訳してみる。これを読めばRedmineプラグイン作成が簡単にできるはず。 注意:チュートリアルを活用するにはRedmineのr1786以上が必要とのこと。 プラグインを作成する プラグインを作るときは、様々なコマンドを利用する必要があるので、パスを通しておくとよい。 https://gist.github.com/daipresents/cd8c75cbe343487bfa7968ee231b6589.js?file=gistfile1.txt Redmineのプラグインはプラグインジェネレータがあるので、ジェネレータを使って雛形を作成する。コマンドの構文は以下。 https://gist.githu

    Redmineプラグインを作るなら読むべき本家チュートリアルの日本語訳
  • サービス終了のお知らせ - NAVER まとめ

    サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。

    takamR1
    takamR1 2012/11/11
    ビックウェーブに乗って楽天カードこの際だから解約するかな。auじぶんカードの方が、毎月の携帯代支払いという形で、確実にキャッシュバックできるし。
  • ソフトウェア資産の価値を可視化すべし

    ソフトウェア開発の効率化、高品質化がなかなか進まない。なかなか進まないと言っているのは、普通はどんな組織でも何か問題が起これば特に何らかの手法を使わなくても緩やかではあるが改善の方向に進むのだが、ことソフトウェアの開発では放っておいてもいっこうによくならない、よくならないどころか放っておくと悪い方向に向かってしまうということだ。そこには、メカやエレキの世界にはないソフトウェアだけの問題というのがありそうなような気がする。 メカ(機械設計)、エレキ(アナログ、デジタルを含む電気設計)、ソフト(ソフトウェア設計)の3つを比べたとき、開発の効率化、高品質化がやりやすいのは、メカ>エレキ>ソフトの順番ではないかと思う。 たぶん、その理由は各設計ドメインにおける開発の成果が見えやすいか否かの違いだろう。メカはできあがったものを見て動かしてみればできの善し悪しを判断できる。評価はできあがったものをみん

    ソフトウェア資産の価値を可視化すべし
  • 組込みソフトエンジニアの心理

    組込みソフトプロジェクトにおける未熟な組織では、試行錯誤でシステムを作り上げてしまう。ここで、未熟といっているのは、先人の成功や失敗の経験を体系化したソフトウェア工学を使わず、かといって自分たちの成功や失敗の経験も体系化せず、ただその組織、その製品開発に長く携わっているだけで組織的な取り組みが十分にできていない状態のことを言っている。 20年、30年前の組込みソフトウェア開発では、ハードウェア、ソフトウェアの区別もなく、ソフトウェアはハードウェアを動かすためのシーケンス処理の記述でしかなかった。このころプログラムの規模は1000行にもなっておらず、試行錯誤でソフトウェアを作ってもランダムテストでバグを潰し切れた。開発の時間的な余裕もあったし、どちらかといえばソフトウェア開発は技術者の個人的な取り組みだった。 このようなソフトウェア開発のアプローチで成長した技術者が20年たってマネージャクラ

  • なぜドキュメントを書かない?

    ジョエル・オン・ソフトウェアの著者である Joel Spolsky はソフトウェア業界での豊かな経験を持つ開発者で、彼のウェブログ "Joel on Software" はプログラマ向けサイトとしては最も人気のあるものの一つで、彼はマイクロソフトの開発者だったころ Microsoft Excel 等多くの有名なソフトウェア製品の開発に携わった。 彼がブログで記事にしたことをまとめた最初のが『ジョエル・オン・ソフトウェア』である。もともとはブログの記事であり。アメリカ人でないとわからないようなスラングや引用(例えばジョージ・ブッシュ大統領の口癖 Not gonna do it! 「それをやるつもりはない」等)がふんだんにちりばめられており、読みにくいと言えば読みにくいが、ところどころで「まさにその通り!」と膝を打ちたくなる部分がある。

    なぜドキュメントを書かない?