「オープンソースの注意点」、オープンソースを利用する際はまず開発企業を調べろ？ | スラド オープンソース
ITmediaのブログにて、「オープンソースの注意点」なるエントリを発見した。要旨をまとめると、「オープンソースソフトウェアは開発者が自分の環境のみで開発を行ってしまう傾向があり、そのため公開されたソフトウェアを実行しようとすると環境の違いによってエラーになる場合がある。そのため、オープンソースソフトウェアを利用する場合は開発を行っている会社を調べる方が無難」ということらしい。 個人的には、開発者が個人であろうがなかろうがこのような問題は発生し得ると思うのだが、このような理由でオープンソースソフトウェアの利用が制限される/忌避されるのなら非常に残念だと思う。
OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん
OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr
![OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん](https://cdn-ak-scissors.b.st-hatena.com/image/square/04e015dad70084a57fdfa9a2686c0c93441c5d2d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127128184977%2F17680117127128193858%2F1557447212)
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
googleの開発プロセス - 森崎修司の「どうやってはかるの？」 [ITmedia オルタナティブ・ブログ]
昨日に続きますが、ディベロッパーサミットでgoogleの開発プロセスについて聴講してきました。Googleは一味異なるプロセスや組織をお持ちのようです。請負開発をされている方には新鮮なのではないでしょうか。工藤氏はGoogleのインフラ寄りの話、小松氏は開発プロセスの話で講演されていました。サービスインフラも開発プロセスも私にとっては身近な話ですが、ここでは、小松氏の講演について書こうと思います。講演では、極めて異例/エキセントリックというプロセスは話されていませんでしたが、以下は、特徴的と感じました。 異なる観点から複数のレビューを実施していること。いわゆるperspective-based readingを実施しているそうです。役割分担型レビュー（reviewというよりはおそらくinspection）で、セキュリティやユーザインタフェースの観点から見たデザイン/ソースコードの妥当性検証
![googleの開発プロセス - 森崎修司の「どうやってはかるの？」 [ITmedia オルタナティブ・ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/7f2a4ced7f91e578679d11d5fcc8f34c5d080289/height=288;version=1;width=512/https%3A%2F%2Fblogs.itmedia.co.jp%2Fmt-static%2Fsupport%2Fassets_c%2Fuserpics%2Fuserpic-83-100x100.png)
「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法：ITpro
上段左からティーアンドエフカンパニー 事業推進統括責任者 情報化戦略コンサルタント 西岡祐弥氏，ティーアンドエフカンパニー 代表取締役社長 佐藤裕司氏，パフ 代表取締役社長 釘崎清秀氏，下段左よりティーアンドエフカンパニー 最高技術責任者 出羽健一氏，パフ 取締役兼株式会社プロシンクワーク代表取締役社長大場京子氏，パフ 事業サポートグループ グループマネージャー 保坂光江氏 Webシステムを開発する際にはほとんどの場合，ユーザーとの打ち合わせのためにHTMLによるモックアップを作る。「このHTMLがそのまま仕様書になれば」と思ったことはないだろうか。就職情報サイトPuffの再構築プロジェクトでは，まさにモックアップをそのまま仕様書した。「十数人の開発者で，5カ月で1000画面のシステムを開発する」必要に迫られたからだ。 HTMLに仕様とメモを埋め込み，CSSで切り替え 「この未体験のスピー
デモではものができあがっているように見せない
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
開発者にアジャイルを強制するのは、危険信号：An Agile Way：オルタナティブ・ブログ
開発者にアジャイルを強制するのは、危険信号だ（Imposing Agile Is A Very Red Flag）とマーチンファウラーが書いた。 http://martinfowler.com/bliki/AgileImposition.html 要約すると、 アジャイルを管理者が押し付けてはならない、それは、 「プロセスとツールよりも、個人と対話に価値を置く 」という価値にも反するし、その背後にある原則である、 「動機付けされた人たちを中心にプロジェクトを構成する。彼らに環境と支援を与え、彼らが仕事を成し遂げることを信じる」、そして、「最高のアーキテクチャ、要求、そして設計は、自己組織化されたチームから創発する」 にも反する。 というのだ。 チームは自発的にウォーターフォール型の方法を選ぶことだってできる。その場合、アジャイルではなくなるだろが、アジャイルはもともと万能ではないのだ。私は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
