タグ

開発に関するibushiのブックマーク (11)

  • 株式会社マジカジャパンの羽生章洋が書いてるブログ:否定表現と仕様書 - livedoor Blog(ブログ)

    ここでいう仕様書というのはコンピュータのシステム開発における仕様書です。とあるシステムの仕様書を眺めていました。うちが関与しているものではなくて、他社さんがまとめられたものです。それを見てるうちにふと思うところあって、過去の色んな資料などを掘り返してみました。すると改めて感じるものがあったのです。 例えば、「Aの場合にBでなく、あるいはCでなければ、当該処理は実施しない」というようなものです。何となくわかったつもりになってしまいそうですが、コンピュータのプログラミングを経験している方であれば、これを仕様書として渡されて実装するとなると、間違いなく色々なケースについて再質問をすることになるのはご理解頂けることと思います。そして今回様々な資料などを読み返してこの「言質を取らせない」的な、あるいは「文学的表現」な文言が実に多いことを改めて実感したのです。 上記の表現は当該処理なるものを実施しない

    ibushi
    ibushi 2009/01/28
    国語大事だよなぁ。でも国語の先生は論理は教えてくれなかったなぁ
  • Webサイトの制作/運用の効率化を図る 「ガイドライン策定」のすすめ(前編)(1/4):CodeZine

    Web標準に従うことは、SEO効果、ユーザービリティ、メンテナンス性の向上など、Webサイトの利用者と制作者の双方にさまざまなメリットをもたらします。しかし、実際にWeb標準の仕様書に従ってWebサイトを制作しようとすると、制作者の頭を悩ませる多くの問題が待っています。連載では、Web標準のメリットを最大限に生かすことをテーマに、仕様書には書かれていない部分を中心に取り上げ、実際のWeb制作現場で起こり得る問題について、解決の糸口をたらしていきたいと思います。 はじめに Web標準に従うことは、SEO効果、アクセシビリティ、ユーザービリティ、相互運用性、互換性、メンテナンス性の向上など、Webサイトの利用者と制作者の双方にさまざまなメリットをもたらします。しかし、実際にWeb標準の仕様書に従って「正しい(X)HTML+CSS」でWebサイトを制作しようとすると、制作者の頭を悩ませる多くの

    Webサイトの制作/運用の効率化を図る 「ガイドライン策定」のすすめ(前編)(1/4):CodeZine
    ibushi
    ibushi 2008/12/10
    こういうあたりまえの事がなかなかできないんだよなぁ
  • Build seven good object-oriented habits in PHP

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    Build seven good object-oriented habits in PHP
    ibushi
    ibushi 2008/12/04
    オブジェクト指向ちゃんと身に着けよう。
  • [ThinkIT] 第1回:postgresql.confによるチューニング(1) (1/2)

    PostgreSQLに限らず、データベースソフトは大量のデータを扱うので、場合によっては処理にかなり時間がかかることもあります。そのため、できるだけ処理時間を短縮し、処理効率を向上する「チューニング」という技術が重視されています。 Webシステムのように数多くのリクエストを同時こなさなければならないシステムでは、個々の問い合わせの処理時間は数百ミリ秒と短くても、全体の処理時間が膨大になることがあります。このようなシステムでは、1つ1つの処理時間をできるだけ短くすることが重要です。 また、「バッチ処理」においても処理時間の短縮は重要です。バッチ処理とは、ユーザーと対話的に行われる処理ではなく、自動的に実行される処理です(多くの場合、人手を介することはありません)。たとえば1日のデータを夜間にまとめる「日次処理」などがこれに該当します。日時処理が決められた時間内に終わらなければ、処理自体が無意

    ibushi
    ibushi 2008/06/26
    実際にいじりながら読んでみる。
  • オフショアソフト開発 TOP

    ibushi
    ibushi 2008/06/13
    googleのアドでみつけたんだけど。うちよりコスト高なのはなぜ?うちの会社が田舎にあるから?
  • 『無料+ブラウザ』で全部やってしまおう。webジェネレーターとサービス50個まとめ*ホームページを作る人のネタ帳

    『無料+ブラウザ』で全部やってしまおう。webジェネレーターとサービス50個まとめ*ホームページを作る人のネタ帳
  • 仕様はどうして決まらないのか?

    情シス部門の業務力 今回は、IT化対象の業務要件・仕様を決めるために必要な「業務への理解力」=「業務力」について述べます。 まず、業務要件とは何かについて整理しましょう。ある業務を行うには理由があります。その理由を外的要因・内的要因の2つに分けて考えます。 図1に示すように、外的要因では法令や制度、監督官庁の指導など、決められた範囲内で業務仕様を決めなければいけない部分があります。例えば、規制業種の場合は○○業法という形で法律として規定されているので、その規定に沿って業務を進め、エビデンス(証拠)を残すという形になります。 どんな企業でも、なんらかの購買活動を行い、なんらかの販売を行うサプライチェーンの1つを担っています。このとき他社との接点が生じます。サプライチェーンとの接点には、他社との調整が可能な部分があります。 内的な要因として、バリューチェーンが指摘できます。社内の処理はバリュー

    仕様はどうして決まらないのか?
    ibushi
    ibushi 2008/04/01
    なんで決まらないんだろう...
  • 「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

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

    「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
    ibushi
    ibushi 2008/03/25
    実は社内フレームワークを「できるひと」にあわせて書いたらすごいことになってしまった。テスト駆動で「誰が書いても(結果が)同じコード」になるほうが大事かも
  • PHP_UML - Do You PHP はてブロ

    phpソースからXMIファイルを作成するパッケージが提案されたようです。 A reverse engineering package that scans PHP files and directories, and delivers an UML/XMI representation of the classes and packages found. The XMI generated can then be imported into your favourite UML modeling tool. javadocライクなコメントを拾って、XMIを生成してるようで、PHP5.3から導入される(ハズの)名前空間も対応しているみたいです。 で、先日CodeReposに突っ込んだCommand_PharCLIのソースを使って、早速試してみました。sourceforge.netからダウンロ

    PHP_UML - Do You PHP はてブロ
    ibushi
    ibushi 2008/03/22
    PXDocなコメント書いてるからそのまま使えるかな?
  • SIプロセス検索画面

    ibushi
    ibushi 2008/03/21
    要求定義のツールなんかは次のプロジェクトででも試してみよう
  • ITエンジニアの「やってはいけない」---目次:ITpro

    設計・実装から運用,メソドロジまで,最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」(アンチパターン)があるだろう。だが,その理由を問われると,うまく説明できないことがあるのではないだろうか。突き詰めて考えると,状況によっては「やっても構わない」こともあるし,技術の進化に伴い「やれるようになってきた」こともある。そこで設計,実装,テスト,運用,メソドロジの各分野について,取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル3~レベル1の3段階あり,レベルの数字が大きいほど,やってはいけない度合いも大きい。 関連サイト: ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編

    ITエンジニアの「やってはいけない」---目次:ITpro
    ibushi
    ibushi 2008/01/09
    ときどき振り返ってみるといいかも
  • 1