タグ

ソフトウェア開発とProgrammingに関するyogasaのブックマーク (11)

  • 眠る開発屋blog|最新オンラインカジノのニューカジノ情報

    もしもこの世から「残業」が完全になくなったら 3年ぐらい前に読んだを思い出した。 1980−90年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」(1985年労働基準法研究会報告)とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」(1992年同報告)と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま21世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人

    yogasa
    yogasa 2012/11/02
    仕様書がないと何故そうなってるのかがわからないので顧客のいいなりになって改修させられ続ける恐れが
  • ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!

    続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解:既にあるソフトウェアを流用し

    ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
  • スタートアップにおけるソフトウェア開発の無駄をなくす大事な3つの考えかた | Social Change!

    資金も人も少ないスタートアップが大手企業に勝つためには、大手と同じことをしていては勝つことができません。大手にできないことをしてこそスタートアップは生き残ることが出来るはずです。もし仮に投資を受けて大手のような振る舞いをしたところで、そもそも基礎的な体力は違う訳で息切れしてしまうことは目に見えています。 大手企業とスタートアップの大きな違いは、大手企業は資金や人を沢山もちすぎているということです。それは正面から戦ったら強みになるでしょうが、新規事業においては弱点にもなりえるのです。 沢山の人や資金を動かすとしたら、必ず無駄が産まれます。長過ぎる会議や総花的な意見まとめなど大企業のオペレーションには多くの無駄があります。小さくて小回りの利くスタートアップが同じように振る舞う必要はありません。 ITを活用するスタートアップにおいて、ソフトウェアを作るという文脈の中でも、大手企業とは違う戦略を採

    スタートアップにおけるソフトウェア開発の無駄をなくす大事な3つの考えかた | Social Change!
  • Joel on Software -

    プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界:すべてのソフトウェア開発が同じではない。 追記:インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし

  • 最近興味深いと思ったWeb記事のリンク集 - give IT a try

    社内のメンバーに紹介しようと思ってためてきた各種Web記事へのリンクが大量に溜まっちゃいました。 ついでにここでも紹介しておきます。 一部の記事は会員登録が必要かもしれません。あしからず。。。 プログラミング/プログラム設計 プログラミングについてあまり知られていない7つのこと http://www.tommyjp.com/2010/08/blog-post_1710.html => どれも超重要。知らなかった人はこれを機に覚えておきましょう。 ソースコードの質 http://el.jibun.atmarkit.co.jp/genmaicha/2010/11/post-5c3e.html => 保守性、可読性、拡張性の重要性について。 技術的負債 http://d.hatena.ne.jp/asakichy/20101210/1291936604 => 技術的負債の原因や解決策について(そ

    最近興味深いと思ったWeb記事のリンク集 - give IT a try
  • ソフトウェア工学とは何か

    ソフトウェア設計とは何か? (原文: What Is Software Design?) by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は,Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 記事では,オブジェクト指向プログラミング言語の代表として C++ を挙げていますが,これは記事が執筆された当時,一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java,Delphi,C# といったオブジェクト指向言語が利用可能となっていますが,そんな今でさえこの記事は古さを感じないものとなっており,ソフトウェア開発の質,現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W. Reeves 氏に,

  • 「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催

    統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」(Empirical Software Engineering、実証的ソフトウェア工学)です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は? マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した

    「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
  • はてなブログ | 無料ブログを作成しよう

    水風呂のすゝめ 毎日めちゃくちゃに暑い。 ここ数年「およげ!たいやきくん」のように昼間は太陽とオフィスビルとアスファルトの三方向から押し寄せる35℃オーバーの熱に挟まれ、夜になっても最低気温が27℃くらいまでしか下がらない。そんな理不尽な東京鍋の中の暮らしが毎年のことにな…

    はてなブログ | 無料ブログを作成しよう
  • もっとも危ないプログラミングエラー25、+16 | エンタープライズ | マイコミジャーナル

    CWE is a Software Assurance strategic initiative sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security. CWE - 2010 CWE/SANS Top 25 Most Dangerous Programming Errorsにおいて脆弱性の原因となる危険なプログラミングエラー25が発表された。開発者にセキュリティ問題の原因となるプログラミングに関する注意を促し、実際にソフトウェアが動作する前の段階で問題を発見し対処できるようにすることを目指したもの。2009年に発表されたリストの更新版にあたり、内容の多くが更新されている。2009年版を使っていた場合には、今回発表された2010年版を再度検討する価値がある。

  • よいプログラマってなんだろう?

    なんか急に書いてみようと思い立ちました。 すべてを書ききれてないし、どの会社なのか、なんのプログラマなのか、どんな立場なのか、だれから見てなのかなど多角的に見たら正しくなかったり当てはまらないところもあるかもですが、個人的になんとなく「よいプログラマってなんだろう?」について現時点で思っていることをまとめてみました。 ちなみに、これらは今の時点で思っていることなので、またしばらくしたら変ってくるかもしれません。 目的への近道を知っている バグってる箇所を効率的に見付ける方法を知っている 目的の実装をする近道を知っている ターミナルでの操作が早い(我流でもよい) 広い視野で設計できる 場当たり的な対応をしない 場当たり的な対応ができる(敢えて) 複数人での開発を意識できる プログラム・作業量・インフラなどのコストを計算できる 自分の書いたプログラムの影響範囲を把握している 実装が早い 無駄な

  • あなたの遭遇したバグや不具合の「イケてない回避策」は? | スラド IT

    時としてベンダーは不具合回避のソリューションとして、へそ曲がりな開発者か、全く何もわかっていない門外漢かが出してきたとしか思えないようなイケてない策を提示することがある。 例えばマイクロソフトは昔Oracleデータソースを使った場合にデータクエリが空で返ってくるのを回避するため、マウスを数分間動かし続けるという対処法を提示したことがあった(そしてこの方法、有効だった)。 また、最近ではHPがOffice2007のクラッシュを避けるため自社製品をデフォルトプリンタから外すよう指示したこともあった。 殿堂入りに値しそうな「イケてない不具合回避策」、他にもあればここに是非。

  • 1