- 【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ46【pl,rb,php,js】
398 ：デフォルトの名無しさん[sage]：2014/09/11(木) 00:04:00.64 ID:WdQgW6yP - >>396
ということは、オブジェクトが受信したメッセージが実装されているかを
実行時に検査する Smalltalk は type-checked language に分類される、ってことね
分類法の基本だけど、各要素は同じ基準(切り口)で定義するものだよ
たとえば生物を分類するのに、素人が：
・哺乳類：親の乳によって子を育てる
・鳥類：空を飛ぶ
・魚類：卵によって繁殖する
などと定義するのと、>>396は同じレベルに見える
（哺乳類の正しい分類法は Wikipedia 等を参照してくれ）
>>395で求めたのは「正確」な定義だから、そこんとこヨロシク
|
- 【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ46【pl,rb,php,js】
409 ：デフォルトの名無しさん[sage]：2014/09/11(木) 19:38:03.74 ID:WdQgW6yP - >>399
ダーメダコリャw
|
- 推薦図書/必読書のためのスレッド 74
73 ：デフォルトの名無しさん[sage]：2014/09/11(木) 19:45:49.94 ID:WdQgW6yP - >>62,65,69
IT後進国の典型例
IT分野どころかフィールズ賞やノーベル賞の受賞者が未だにゼロな科学技術の不毛国家
--
[OSS] 韓国でオープンソースの利用が進まない理由は本当に英語？：日経パソコンオンライン
http://pc.nikkeibp.co.jp/article/NPC/20070912/281736/?rt=nocnt
韓国では「韓国人は英語が苦手だからオープンソース利用が進まない」と言われているが、
韓国人よりもさらに英語が苦手な日本では結構進んでいるのではないか、という話。
でも、韓国で「オープンソース利用が進んでいない」という印象はあまりないんだけど、
韓国内にいる人はそう思うのかな。少し前まではWindows全盛という話は聞いていて
政府や大企業のサイトがActiveX使いまくり(なのでWindows以外ではネットバンキングも
政府サイトアクセスもできない)という状況だったそうだけど、
今ではずいぶん改善されているんで無かったかな。
各郵便局に配置されているという公衆端末はLinuxらしいし。
しかし、そんなことよりなにより印象に残ったのはここ。
> 日本だって英語が苦手な人が多いのに、韓国のマスコミの報道によると
> 5000人以上のOSS開発者がいるという。韓国では100人にも満たない。
確かに韓国発のオープンソースソフトウェアについて聞いたことはないが、
それは言語の壁に遮られているせいだと思ってた。
国全部で100人以下？ マジで？
どういうことだろう？ 確か韓国って3千万人くらい人口があるんだよね。
利用が進むのは勝手だが、利用ばかりで開発に回る人が少ないのは
あんまり望ましいことではないなあ。
(2007.9.12 Matzにっき) http://www.rubyist.net/~matz/20070913.html
|
- Ruby 初心者スレッド Part 55
444 ：デフォルトの名無しさん[sage]：2014/09/11(木) 19:50:23.40 ID:WdQgW6yP - >>442
>はやくPythonやJavaScript系に乗り換えた方がいい。
ついつい本音が出てしまったねw
アンチが乱入して暴れるのはRuby関連スレの恒例だな
まあ、それだけ他のスクリプト言語プログラマからすれば、
Ruby が気になって気になって夜も眠れないんだろうなぁ（棒
|
- テスト駆動開発はなぜ流行らなかったのか？2
804 ：デフォルトの名無しさん[sage]：2014/09/11(木) 20:00:47.63 ID:WdQgW6yP - >>797
テストの目的やその定義によりけりだね
もし「テストコードを書いて、それがすべてパスすること」をもって
「テストした」とするなら、その(>>797)解釈でも不思議は無い
自分のテストの目的は >>779 の後段に書いた
これらの目的を達成するには(テスト対象のコードと同様に)
テスト仕様/テストケース/テストコードも長期間の保守に耐えられる必要がある
言い換えると、適切に「テスト設計」して「文書化」することが前提になる
つまり「動いているコードが仕様です(>>796)」と同様に、
「動いているテストコードがテスト仕様です」という発想も否定する
|
- テスト駆動開発はなぜ流行らなかったのか？2
805 ：デフォルトの名無しさん[sage]：2014/09/11(木) 21:04:23.04 ID:WdQgW6yP - >>799
>って発展してきている認識なんだけど、TDDとアジャイルは関係ないの？
アジャイルは(>>796で書いたように)開発プロセスにエンドユーザを巻き込む手法だから、
TDDとは関係ない
>ウォーターフォールの標準的な工程にリファクタリングの文字が含まれているのか(反語
古典的なウォーターフォールでは含まれていない
ただし、(同じく>>796で書いた)1990年代に知られていたスパイラルでは、
リファクタリングに対応する用語として「制御された再作業(controlled reworking)」がある
たとえば「動くプログラムを開発する」という目的で最初のスパイラルを廻し、
次に「品質改善」を目的とする２回目のスパイラルを廻す、という開発プロセスを認めている
ウォーターフォールへの問題を改善する手法としてプロトタイピングが考案されたのが1980年代、
その後に開発プロセスという概念が生まれ、そこからインクリメンタルやスパイラルといった
(ウォーターフォールに代わる)新しい開発プロセスが1990年代に登場するという歴史を経ている
>リファクタリングを矯正するのもTDDの利点だと思いまする
テストを前提にしなければリファクタリング(=コードの品質改善)ができないプログラマであれば、
TDDに頼るのも「しかたがない」のかもしれない
|
- テスト駆動開発はなぜ流行らなかったのか？2
809 ：デフォルトの名無しさん[sage]：2014/09/11(木) 22:43:23.38 ID:WdQgW6yP - >>806
いろいろと間違っているなぁ
まず、バグ対策とリファクタリング(=品質改善)は異なる概念を指す用語だよ
リファクタリングとは、テストが全件パスした(=すべてのバグを摘出した)後に、
機能(または外部インターフェイス仕様)を変更せずに内部の設計(または実装)だけを
改善するもの
設計段階のレビュー等で発見されたバグ、あるいはテスト段階で摘出されたバグ、
それらを前工程にフィードバックすることは、当然ながらウォーターフォール手法の一部だ
対して、前工程へのフィードバックが存在しない(魔法のような)開発手法はクリーンルーム法になる
魔法の種明かしは、形式的設計手法を前提にすることによって検証によりバグを0にする発想にある
当然、形式的設計手法を使いこなせるプログラマは少数だから、
クリーンルーム法は理想論として現場で普及することなく歴史の流れに埋もれていった
そして形式主義(formalizm)なクリーンルーム法よりも、実践主義(pragmatism)な
プロトタイピングが現場では歓迎されて普及していき、現在に到る(までを>>805 で書いた)
|
- テスト駆動開発はなぜ流行らなかったのか？2
812 ：デフォルトの名無しさん[sage]：2014/09/11(木) 23:33:37.18 ID:WdQgW6yP - >>808
その定義であれば、それをテスト駆動開発と呼んで
「個人の開発プロセス」に組み込むことは否定しないよ
一個人に割り当てられる(=品質に責任を負う)モジュールの規模は数Kから10数Kステップにもおよぶ
それをサブモジュール(たとえばJavaならパッケージ/クラス/インターフェイス)へと
適切に分解して定義していくプロセスには、常に試行錯誤が伴うものだ
むしろ、その「個人の(試行錯誤の)開発プロセス」を効率化するために
そうしたテストファースト的な手法の導入を考える発想は、
力任せに突き進むアプローチよりもずっと好ましいと思う
個人的には(>>779 で書いたように)時間をテストより設計へ費やすべきと思うけど、
個人が負う責任の範囲内であれば、つまり担当モジュール内部のコード設計であれば、
(リスクを含めて)個々が好む開発手法を選ぶ権利はあるはずだからね
対して明確に否定するのは、(個人の開発プロセスではなく)プロジェクトの開発プロセスを対象に
TDD をソフトウェア設計の方法論として捉える姿勢だ
アジャイルやらエクストリームとやらも同じ理由で否定する(>>785)
|