特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
「クラウド」というと、スーツを着た営業が創りだしたバズワードに過ぎない。まあ、ここでは聞こえがいいのでクラウドという言葉を使う。 クラウドと言った所で、その本質は、サーバー側での処理だ。たとえばYouTubeなどの動画サイトは、ユーザーがアップロードした動画を共通のフォーマットに変換している。これを実現するためには、多彩な動画と音声のフォーマットをデコードするソフトウェアが必要だ。現在、そのデコードするソフトウェアは、ffmpeg(あるいはlibav)が担っている。これは、自由なソフトウェアである。自由なソフトウェアであるので、非常に使いやすい。使いやすいというのは、単に機能的に使いやすいだけではない。必要であれば、使いやすく改変することができるという点で、使いやすいのだ。 ffmpegが、今の地位に至るのは、容易ではなかった。多くの動画圧縮フォーマットは、そのフォーマットの詳細が公開され
5月31日で、2年とちょっと働いたパナソニックを退社しました。最初半年ぐらいは研修だったので、実質1年半ぐらいで辞めたことになります。 辞めた理由はシンプルで、私はソフトウェアの開発がしたかったのですが、実際にはソフトウェアの開発が出来なかったこと。それから、社内の雰囲気が合わなかったことです。 もし今就活中、または来年就活の方で製造業を志望されているソフトウェアエンジニアの方がいたら参考になるかもしれませんので、少しだけ書いてみます。 ただ、大きな会社なので、部署によっては全然雰囲気が違うようで、楽しく仕事をしているところもあるようです。たまたま、私が合わなかっただけです。実際離職率は低めです。 それから、仕事の方針にはミスマッチはありましたが、部署の皆様には大変お世話になりましたし、私の考えに共感して助けてくださることもありました。特定の方を非難する意図はないことを申し添えておきます。
完全に自由なソフトウェア環境のPCを手に入れるのは可能だろうか。少し考えてみた。 まず、BIOSが自由でなければならない。とすると、マザーボードの選択は非常に限られる。 Supported Motherboards - coreboot corebootのサポートは、AMD用のマザーボードの方が圧倒的に優れている。これは、AMDはcorebootのために、チップセットのドキュメントを提供しているからだ。Intel用のマザーボードの対応はひじょうにおろそかだ。 もちろん、これだけではまだ不自由だ。なぜならば、マザーボード上には、BIOSではないソフトウェアがある。たとえば、NICやGPUやRAIDコントローラーなどだ。これらもすべて自由なソフトウェアでなければならない。 これを突き詰めるとどこまで行けばいいのかわからない。たとえば、マザーボードのソースコードである設計図は公開されているべきだ
High Priority Free Software Projects — Free Software Foundation — working together for free software 自由ソフトウェア財団では、「高優先度自由ソフトウェアプロジェクト」と題して、自由ソフトウェアの注目を集めるためのプロジェクトを発表している。多くは、すでに同等機能を持つ不自由なソフトウェアの存在がある。なぜ優先度が高いのかというと、自由なソフトウェアが不自由なソフトウェアと同等以上にすばらしいことを見せつけ、人々をもっと自由なソフトウェア側に転身させるためである。多くの不自由なソフトウェアは、対価を要求する。しかし、その金を自由なソフトウェアの開発に当てれば、同等以上の機能を持ち、しかも自由なソフトウェアが実現する。その点で、いくつかの自由ソフトウェアのプロジェクトは重要である。 どうも、最
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
このウェブページでは、「脆弱性検出の普及活動」(*1)で公開した「ファジング活用の手引き」等の「ファジング」(*2)に関する手引書などを紹介しています。これらの手引書などをご活用いただき、ソフトウェア製品の開発ライフサイクルへのファジング導入につながり、ソフトウェア製品の脆弱性が減少することを期待します。 ファジングコンテンツ一覧
本来のミッションから少し離れて、本業の参考にと思って知己を得ていた先方の会社さんを訪問したり情報交換したりして過ごしていたんですが、いろいろ凄いです。「事情を日本のブログで紹介するよ」と言ったら、どこか明かさないという条件で許してくれました。 ● ソフトウェアの開発効率はあまり考えない シャチョーも担当者も現場の人も、効率は大事だけど開発に取り組む要員の創意工夫ややりがいを重視しているとのこと。現場レベルでは18ヶ月のプロジェクトが50ヶ月遅延した笑い話をしてくれたり、某ドイツの基幹系をロシア企業に提供する際にドイツ人の定義定義のやり方に嫌気が差し、そんなことだから戦争に負けるんだと掴み合いになった話を披露してくれました。 ● でっかいものを作りたがる どっちかっていうと日本では小さくて正確なコーディングを求めて、バージョンがアップするごとにコンパクトかつバグが少なくという方向で作業指示が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く