JavaScript の質問用スレッド vol.123 [無断転載禁止]©2ch.net

2017/04/03(月) 00:31:25.68

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-6のテンプレを読んだ上で質問してください。次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。
(10) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
※前スレ
JavaScript の質問用スレッド vol.122
http://echo.2ch.net/test/read.cgi/tech/1472426483/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2017/06/26(月) 19:21:23.33

>>557
何もおかしくないよ。

V8エンジンはJavaScriptのコードを
コンパイルしてネイティブに変換して実行するものだろう？

ソースコードをバイナリに変換するという処理は
単なるテキストファイル読み込んでバイナリデータを
書き出すだけなんだからJavaScriptでだってできることだろう？

2017/06/26(月) 20:10:21.50

もういい加減新しい簡単な仕組み作ってくれよ
webpackとかbabelとかようわからん
何かに躓いた時直せる自信がないよ

2017/06/26(月) 20:16:38.23

>>559
まずフレームワークを選べ

React、Angular、Vueあたりの有名所であればCLIが用意されてる
これでプロジェクトをすぐに作れる。そのプロジェクトはwebpackやbabel等が設定済みだ
そしてフレームワークのやり方に従え。
その結果JavaScriptばりばりのSPA ウェブアプリが簡単に作れる。

JavaScriptバリバリのアプリなんか作る気はないという人は、
webpackやbabelは使わず、jQueryやlodashを使うことをおすすめする
大半のウェブサイトではこれだけで十分なはずだ。

2017/06/26(月) 21:47:37.55

はいはい、俺様仕様最高ねｗ

2017/06/26(月) 22:52:02.29

Backbone.js( + underscore.js, jquery.js)は？

早速、山田祥寛が、AngularJS に目を付けたようだ。
本を出してる

2017/06/26(月) 23:15:01.98

Javascriptで文字コードの変換って出来る？
調べてもよその人が作ったencoding.jsっていうライブラリ使ってね～
くらいしか出てこないんだけど

2017/06/26(月) 23:16:02.58

会社でjavascriptの業務アプリ作ってる。
ライブラリはいざ何かあった時にセキュリティに問題無いのか証明出来ないし、そもそもワザワザダウンロードしたらシステム部署から即連絡来るから全部素でコーディングしてる。

2017/06/27(火) 01:25:21.86

>>564
ブラウザやOSにセキュリティに問題がないことは
どうやって証明してるの？

2017/06/27(火) 01:32:28.99

自作の方が、有名ライブラリよりも、はるかに危険だろ

開発体制・レベルが違いすぎる

2017/06/27(火) 02:14:17.76

利用者が多いライブラリに限るけど、
一般的には自作するよりもライブラリを使ったほうが安全だよね
なんで自作したほうが安全って思い込むのかを考えてみたんだが
その根底にあるのは、メンテナンスするのが嫌ってっことなんじゃないだろうか？

他人が使ってるライブラリを使うと、そのライブラリは勝手にバージョンが上がっていく
最新版への追従をしたくない。と考えてるのではないか？
自分で作ったものならば、そんなことはおこらないからね

有名ライブラリならば脆弱性があれば発表される。
そして対応しなければいけない。それをやりたくない。

自分で作っていれば、脆弱性があっても発表されることはない。
だからメンテナンスしなくていい。メンテナンスの義務はない。
脆弱性に気づいてないから攻撃されても俺のせいじゃない。攻撃したほうが悪い。
それに俺は運は悪くない。攻撃されないだろう。とかそういう発想なんだと思う。

2017/06/27(火) 03:17:19.47

AngularJSとかVueとかいらんから
React一本に絞ってくれよ－！

2017/06/27(火) 04:00:24.98

10年以上も、エアバッグの破損を認めなかった、タカタは倒産した。
同族企業は、ろくに仕事なんかしない

自作する奴は、他人に間違いを指摘されたくないのだろ。
自作にはバグが無いという、夢を見てる

客観的に見ると、OSSの方が圧倒的に、確かめられていて修正もされている

2017/06/27(火) 06:47:33.09

>>565
ローカルだけで動かしてるから問題無しと思ってるんだけど…共有サーバーにも載せてない。それでもダメ？

2017/06/27(火) 06:59:35.79

>>567
何故ライブラリは自作よりも安全か

という証明の手段を持ってないから。
ライブラリの中身のコードまでどんな動きしてますって分からないし説明出来ない。

純粋に聞いてみたいんだけど、皆はライブラリ使う時に、会社や客にライブラリの安全性の証明とか求められたらどうしてるの？
有名で皆が使ってるので安全です。とかじゃなくて。
そのライブラリが元で特にセキュリティ関係のトラブル起きた時にはどうしてる？
参考にしたい。

2017/06/27(火) 07:31:26.37

たぶん役所は、テストを外注する。カネも時間も（半年とか）かかるね

2017/06/27(火) 07:33:19.11

>>563
Encode/Decode APIがある

>>571
非常に難しいね
でも今の時代外部サービスを利用することがどんどん増えてきてるからなぁ
結局自分や相手が中小企業じゃ、自分たちのところにサーバたててしっかり管理していくよりも
多少のリスクがあるのかもしれないけれど委託した方がコスパ面で合理的なんだよね

まあ、論理的な回答は難しいんじゃない？
その客だって自身じゃできないから君のところを信用して任せてるわけだし、
ならどうして君のところに頼むという結論を出したのかを考えて、それを元に適当に回答してあげたら良いんじゃないの？

まあでも開発に携わってる人誰もライブラリの中身理解できませんは問題かもよ
場合によってはそれを改変したり、APIを真似して作ったりする手段も持っておかないと困ると思うよ

2017/06/27(火) 07:57:26.53

>>573
APIがあっても追加のencodingってのが無くない？
CP932使いたかったんだけど結局そのAPIはあきらめたわ。

2017/06/27(火) 07:59:31.61

>>571
自前とライブラリ使用時の工数を出すだけ

2017/06/27(火) 08:27:44.23

>>573
563だけども
Encode/Decode APIって調べたらライブラリ入れないと駄目なやつだよね
ライブラリ入れずに文字コード変えるのはやっぱり不可能なのか

2017/06/27(火) 08:37:09.16

違ったわライブラリじゃなかった

でもIE11だからどのみちEncode/Decode API使えない悲しい

2017/06/27(火) 08:40:38.02

>>571
> 純粋に聞いてみたいんだけど、皆はライブラリ使う時に、会社や客にライブラリの安全性の証明とか求められたらどうしてるの？

自分で書いたコードに、安全性の証明を求められたときとやることは一緒だろ？

自分でコード書いたから安全性はバッチリです！なんて言って終わらせないだろ？
自分たちは信じられないので第三者のセキュリティチェックをうけるわけで、
それをライブラリに対してやればいいじゃん？

2017/06/27(火) 11:32:46.68

オブジェクト指向コンパイル言語にするって方向は間違ってない
とおもうよ、でも乱立する必要ある？？
Coffee ECMA6 Type Babel
やりたいことは同じなのに別々の文法覚えて
Coffeeに基づいたフレームワーク
Typeに基づいたフレームワーク
Babelにもとづいたフレームワーク
それぞれ限定されたものしか使えなくなる
そのフレームワークも乱立して
Reactに基づいた拡張
Anuglarに基づいた拡張
全部文法がバラバラじゃん、いい加減にしてよ！
やりたいことは１つなのに、
テンプレエンジンもそうだよ、文法変える必要ある？統一してよ。

2017/06/27(火) 12:16:31.70

>>576
不可能じゃないよ
その為のjavaScriptなｗ

2017/06/27(火) 12:31:26.63

>574-577
最初からこれというのが分かってれば自作することも十分に可能
大抵巨大な変換テーブルが要るからそれ見つけて来て
ちょっとパターン分け書いてやるだけで済む
メディアファイルのデコーダに比べたら遥かに簡単
TAの入門練習にちょうどいいと思う

あ (ｽﾌｯ Sdbf-d3f0) · 2017/06/27(火) 15:36:41.85

>>571
ライブラリの安全性は求められるから、安全性が担保できるライブラリしか買えない/使えないな。
責任がはっきりする、外注の納品物でも品証がOK出すかわからん。

大体のEULAで割と序盤にお前らは別に保守契約しろよなって書かれてる業種だからちょっと特殊だけど。

**デフォルトの名無しさん** (JP 0H4f-LvKX) · 2017/06/27(火) 15:51:05.73

WindowsもLinuxもMacもセキュリティホールだらけだから、自作OSでいくしかないな

2017/06/27(火) 16:19:05.10

>>582
> 安全性が担保できる

ライブラリじゃなくて、自分で作ったものの
安全性の担保はどうやってるの？

2017/06/27(火) 16:27:43.42

ん？もしかして

× 安全性が担保できるライブラリしか買えない/使えないな。
○ 安全性の担保を丸投げできるライブラリしか買えない/使えないな。

と言いたいのかな？

これも

× 責任がはっきりする
○ 責任を相手に押し付けられる

こう言いたいんじゃないのか？

責任を相手に求めるのは間違ってるだろ？
ライブラリを使った責任は、使った人が責任を取る。
どうせ自分で作った場合は、作った人が責任を取るわけで
そこは変わらないはずだ。

作った人 = 責任を取る人という固定観念があって
責任を取ってくれないからダメって言ってるんじゃないか？

使った人が責任をとるならば何の問題もないはずなんだが？
そもそも仕事だって作った人じゃなくて会社が責任を取るわけだし
「会社が責任を取るライブラリ」を社員が作ったか外部の人が作ったかにすぎないはずだよ？

あ (ｽﾌｯ Sdbf-d3f0) · 2017/06/27(火) 17:01:45.05

>>583
半分ホント。
割とガチガチな枯れ切ったカーネルに自社で手を入れてるよ。

>>584
全条件分岐、直行表で試験するよ。

>>585
製品の瑕疵責任はうちが、部品の瑕疵責任は納品者が。
受け入れ試験するけど、受け入れでハネたものを修正するのはあっちだよ。

**デフォルトの名無しさん** (JP 0H4f-LvKX) · 2017/06/27(火) 17:13:49.26

>>586
> 全条件分岐、直行表で試験するよ。
C1カバレッジでカバーできないC2カバレッジの範囲や、直交表から漏れたケースでバグがあるかもしれないよね
さぁ、どうする？

2017/06/27(火) 17:27:27.83

>>586
> 全条件分岐、直行表で試験するよ。

セキュリティに関するものはそれで試験できないよね？

2017/06/27(火) 17:29:04.29

>.586
> 受け入れ試験するけど、受け入れでハネたものを修正するのはあっちだよ。

自分で作ったものだって試験するだろ？
なら試験の量は変わらない。

修正は開発元に修正依頼投げれば良いんじゃない？
githubで提供しているならIssueを立てればいい。
障害はないはずだよね？

**デフォルトの名無しさん** (JP 0H4f-LvKX) · 2017/06/27(火) 18:13:38.53

てか、ここJavascriptスレなんだけど、Javascriptの話なのか？

2017/06/27(火) 18:24:08.88

JavaScriptの話とは言えECMAScriptの仕様や技術的な話は
殆どされて来なかったどころか敬遠されてきたじゃん

私の代わりにコード書いてくださいという質問と
揚げ足の取り合いで成り立ってきたスレだよここは

**デフォルトの名無しさん** (JP 0H4f-LvKX) · 2017/06/27(火) 18:41:41.39

>>591
とはいえ、組み込みの品質保証の話を始められても困るとは思わないか？

あ (ｽﾌｯ Sdbf-d3f0) · 2017/06/27(火) 19:12:38.09

>>587
分岐網羅、条件網羅で網羅できないならば、網羅できるようにするしかないわな。
品質都合でコード変えないといかん代表例だと思う。
というか、漏れてる時点でやる価値のないテスト。

>>588
どー言うこと？疑似環境自体作るから微妙なとこかと。
テストしてない、かつ証明できてないセキュリティっておかしいと思うけど。

>>589
するけど。試験の量も変わらんが。
発見した時、どーせパッチなんか待ってられないしこっちがコミットしまくるなら、もうそっからフォークして内製してしまったほうが良いってのが現状かなぁ。
だから、ハンドリングできる内製や外注の方が余程なん楽じゃん。

>>590
JSも最近やっと、まともに「安易に時刻を直接取らずにラッパーから取る」とか思想が広まってきてるし、良いと思うよ。
組み込みにだって、ウェブUIもありゃ、その上のJavaScriptだってあるんだから。

2017/06/27(火) 19:58:39.67

>>593
> どー言うこと？

どういうこともなにも、セキュリティっていうのは
客から要件定義される類のものじゃないので
セキュリティに対するテスト仕様書を作ることはできない。

そしてセキュリティというのは見逃しが原因で発生する。
そもそも見逃しているのだから、そこにテストが必要なことも思いつかない。

セキュリティはテストで担保できるものじゃない。

2017/06/27(火) 19:59:43.06

>>593
> するけど。試験の量も変わらんが。

試験の量が変わらないならば、
他人が作ってくれる分コストは下がるね。

2017/06/27(火) 22:13:44.63

10人以上死んでるけど、タカタは、10年以上、自社の破損を認めていない。
破産会見でも、自社製品は安全だと言ってる。
絶対に非を認めないから、自社の証明では無理

結局、トヨタ・ホンダは、5千億円ずつ払ってリコールして、
その費用をタカタに請求したから、タカタは払いたくないから破産した

結局、トヨタ・ホンダは、5千億円ずつ損した

自社の証明なんて、信じる人はいない。
OSSのように、外部の他人が監視しているものじゃないと、安心できない

2017/06/27(火) 22:16:07.43

netflixとか基幹で使ってるライブラリをオープンソースにして
検証してもらってるって感じだもんな。
ドキュメント読むと不具合見つけたらとにかく報告してくれって書いてる。

2017/06/27(火) 22:31:07.65

他者のライブラリのメリットというよりもOSSのメリットという印象だな。
自作ライブラリもOSSとして公開すれば、同様のメリットを享受できるわけで、論点がずれている気がする。

2017/06/27(火) 23:39:25.24

クローズなものは検証できないから、簡単にねつ造できる

橋下が言ってたけど、大阪の犯罪件数を減らそうと、目標を立てたら、
警察の方でねつ造して、数値だけが下がった

クローズでは、何か目標を立てて利益誘導すると、皆で数値をねつ造してしまう。
それで簡単にボーナスが増えるから

政治家の目標と官僚機構の、阿吽の呼吸で、即座に成功させてしまうw

つまり、ここでは当事者は2人で、ユーザーは無視されている。
なぜかというと、ユーザーはどうであろうと、常に税金を払うから、
政治家・官僚の仕事が減って、ボーナスだけが増えれば、それが正解だから

あ (ｱｳｱｳｲｰ Sa0b-d3f0) · 2017/06/28(水) 00:24:50.31

オープンに夢見すぎだろw

2017/06/28(水) 01:23:30.14

>>600
それは俺も思った。
OSSといっても実際にメンテしているのは限られた人数だけだし、よくある「世界中のエンジニアが見ている」の売り文句も机上の空論な印象。
実際のところ、品質を決めるのは、テストにどれだけコストをかけているかで自作/他作は関係ないと思う。
>>594の「セキュリティはテストで担保できるものじゃない」にしても、XSSとかSQLインジェクションとか攻撃法を想定してテストする事は出来ると思うんだが。

2017/06/28(水) 03:18:31.03

例えばlodashとかjqueryは普通に使ってるわけでしょ？流石に。
ossでちゃんと多数に使われてるなら信頼性はあると思うけど。
そこを嘘だと言うならv8も信用できなくなるわけだが。

あ (ｱｳｱｳｲｰ Sa0b-d3f0) · 2017/06/28(水) 07:33:04.85

>>601
うん。
目の数あっても、手の数は限られてるし、
手を使うなら、もう全部自分らでやろう、って発想になるよね。

>>594
の話。そんなインジェクションを想定していない訳がないからな。品証の前にテスターに出した段階で、テスターの方が「前提条件が足りないため不能」とか言い出すやつ。

一番面倒な乱数使う類の暗号も、ライブラリ側が正しく動作することが何らかの方法で単体テストできてりゃ、
C2カバレッジで各条件作ってるんだし。

>>602
うちのjQuery、jQueryにとてもよく似たライブラリになってる。テセウスの斧状態。

2017/06/28(水) 14:22:20.89

>>603
それはjqueryなのか？
特定のバージョンからのjqueryからforkしてきて独自メンテナンスしてるってこと？
それとも最初から互換ライブラリを作ったって話？

**デフォルトの名無しさん** (JP 0H4f-LvKX) · 2017/06/28(水) 14:28:19.43

>>601
> 自作/他作は関係ないと思う。
他作なら、ものによっては全世界レベルで何万何十万もの実稼働と呼ばれるテストが日々行われているわけだが

2017/06/28(水) 16:23:01.71

>>605
これ。そもそもgithubのお陰でバグ報告の仕組みがだいぶ簡単になったし、
どんどんバグ報告して改善していってるよ。

2017/06/28(水) 17:02:19.32

>>605
> 他作なら、ものによっては全世界レベルで何万何十万もの実稼働と呼ばれるテストが日々行われているわけだが
それが幻想だといっているのだが、「何万何十万もの実稼働と呼ばれるテスト」とはどこから出てきた数だ？
「実稼働 = テスト」の図式はどこから出てきた？

あ (ｽﾌｯ Sdbf-d3f0) · 2017/06/28(水) 17:13:30.96

>>604
最初は互換ライブラリで、途中からフォークで、今はもはや独自、かな。正確に言えば。

>>605
エビデンスなきテストはテストではない。

2017/06/28(水) 17:20:38.85

まあ、未完成品を公開して利用者にテストさせるベータテスト的な考え方もあることはあるか。
だが、それは初版(ベータ版)の品質が悪い事を暴露しているようなものだし、ユーザの使い方が多様性を持っていて、しっかりとしたテストレポートが出てこなければ機能しない。
ほとんどのユーザは同じ使い方をしていて発見されないバグがあるかもしれない。
ユーザが報告しても環境起因や勘違いかもしれないし、本当にバグであっても曖昧な報告で再現出来ないかもしれない。
世界中のユーザがテストしてくれるってのは幻想に過ぎない。
テストはコードを理解している人物が行うものだ。

**デフォルトの名無しさん** (JP 0H4f-LvKX) · 2017/06/28(水) 17:33:58.64

>>609
> ユーザが報告しても環境起因や勘違いかもしれないし、本当にバグであっても曖昧な報告で再現出来ないかもしれない。
github見たことないの？

2017/06/28(水) 17:50:20.37

こんな感じだから日本人は海外に大差つけられるんだろうな
今はもうそんな時代じゃないのに

**デフォルトの名無しさん** (JP 0H4f-LvKX) · 2017/06/28(水) 18:03:34.50

伽藍とバザール(1997)以前のメンタリティ

2017/06/28(水) 19:02:01.25

>>610
githubは知ってるが、あれはプログラマ寄りのユーザを対象にしてると思う。
「何万何十万もの実稼働と呼ばれるテスト」といわれるようなのはコードに触ったこともないような一般人よりの感覚だと思っているのだが、そうでもないのかね。
「実稼働=テスト」という感覚がどうにも信じがたいが。

2017/06/28(水) 19:07:42.81

あと、何度もいってるが、自作/多作に関わらず、githubに公開すればその恩恵は享受できるのだから「他作だから信頼性が高い」わけではない。
彼の主張を聞いていると「先発のライブラリが信頼性が高い。自作ライブラリ(後発)は信頼性が低い。」といっているように聞こえるが、そんな事はないだろう。

あ (ｽﾌｯ Sdbf-d3f0) · 2017/06/28(水) 20:02:56.65

>>612
伽藍とバザールでは、あくまでユーザはデバッガ兼共同開発者では？

2017/06/28(水) 20:30:59.42

>>607
> それが幻想だといっているのだが、「何万何十万もの実稼働と呼ばれるテスト」とはどこから出てきた数だ？
全世界のサイトのうち72.5%で使われてるのだから、
何万何十万とどころじゃなくて、7億以上実稼働されてるよ。

サイト数2度目の10億超え - Netcraft報告
http://news.mynavi.jp/news/2016/03/22/265/

jQueryが使われてる割合
https://w3techs.com/technologies/history_overview/javascript_library/all/y
2017年6月 72.5%

2017/06/28(水) 20:34:03.91

こいつらの言うことを全部正当化するなら使ってるlinux鯖も全部ソース検証して手直しビルドということになるな
いきすぎると社畜の年寄り老害とかわんねーよ

2017/06/28(水) 20:34:26.49

>>608
> エビデンスなきテストはテストではない。

エビデンスあってもテストにならないものも多いけどね。

例えば、人によって解釈が異なるテスト、
エクセルに日本語が書いてあって読み手によって
実行するテスト内容に幅があるようなものはテストではない。

また実行結果画像も捏造が可能なので
こちらもエビデンスと呼べるものではない。

適当なテストやってるところは、
これをエビデンスとかいっちゃってるけどねｗ

2017/06/28(水) 20:38:01.66

結局社畜理論なんだよね
上から何か言われて責任逃れが言えるかどうかしか考えてない

「テストしました！検証しました！」

で？その検証が正しいという証拠は？

どこの馬の骨ともわからんライブラリ拾ってくるのはどうかと思うが、物事にはレベルってもんがあるだろ

jQueryに難癖付けて使わないレベルとさあほとしか言いようが

2017/06/28(水) 20:38:12.31

>>616
稼働実績ではなく、テストしているユーザの実数が問題なわけだが

2017/06/28(水) 20:44:49.62

>>611
じゃあ半島に帰れよマジで

韓国人死ね

>>613
見りゃ分かるが明らかにエアプか？ってのも混ざってるだろ。
そういうのは無視でいいぞ。
GitHubがどうだとか、ここでグダグダ言わずとも、使えば分かる。
OSSについての過大/過小評価をしている奴は、要するにやってないだけ。
そんな奴らと話しても水掛け論にしかならない。

ただしインフラ系や組み込み系と比べたら、
Web系の検証なんてやってないに等しいくらい酷いぞ。
ただそれが一方的に悪いわけでもなく、それがニーズでもあるんだが。

そしてお前らマジで別スレ立てろ。
この手の話に食いつきがいいのは以前からで、
多分今のお前らには必要なんだよ、JavaScript中級者用雑談スレがね。
なお俺はそれには参加しないから安心しろ。

2017/06/28(水) 20:44:52.17

ちなみに実稼働とは別にもちろんjQuery側で用意しているテストもちゃんとある
https://github.com/jquery/jquery/tree/master/test

テストの数とかカバレッジは知らない（見つけてない）けど、
こういうテストを行っていることがはっきりわかるし
誰がやっても同じテストを行うことができる。
こういうのが正しいエビデンス

あと気になるのが、実稼働とテストコードどちらが信用できるか？
jQueryは両方あるので関係ない話だけど、一般論の話をすると
実稼働数が少なくて、十分なテストがされている場合は、使われてない機能も
ちゃんとテストされているはずとうことでテストコードの方が信頼性が高い。

だけど実稼働数が膨大であれば、テストされてないマイナーな使われ方を
発見することがあるという点で、実稼働のほうが信用できる。
特に特定のスマホだけに発生する問題とかあるからね
（実際jQueryにはその対策コードがいくつも入っている。）

実稼働の数が膨大であればエビデンスはなくてもテスト以上に信用できる。
エビデンスだけを求めている所は「政治的な理由」でこれがダメだと言うだろうけど
それは政治的な理由であって、正しく動くという事実を否定するものではない。

2017/06/28(水) 20:59:09.11

>>619
> 結局社畜理論なんだよね
> 上から何か言われて責任逃れが言えるかどうかしか考えてない

それだろうね。

「外部が作ったライブラリを使って責任は取れるのか？」
っていうのは実は、

「外部が作ったライブラリを使って問題が起きたらお前が責任は取れ！」
って言ってるのと同じなんだよね。

そして、責任取りたくないだろう？なら
「お前が作って、問題が起きたら、お前が責任を取れ！」
と言ってるのと同じことに気づいていない。

結局責任を取るのは「お前」なんだが、そこに気づいてないやつが
あ、自分で作れば責任取らなくていいんだ。って勘違いしちゃうわけｗ

2017/06/28(水) 21:04:33.40

>>608
> 最初は互換ライブラリで、途中からフォークで、今はもはや独自、かな。正確に言えば。最初は互換ライブラリで、途中からフォークで、今はもはや独自、かな。正確に言えば。

jQueryをフォークしないと修正できない問題って
思いつかないんで無いと言わせてもらうけど、

フォークしたのは技術力不足とか発想力が
足りなかったとかいうこと？

フォークしなければ修正できない問題なんてないよね？

2017/06/28(水) 21:12:57.59

そういや、どこかのスレでエビデンスとは
テスト作業をちゃんと行ったという証拠（エビデンス）として
求められているものであって、テストの内容については関知しない。

システムが正しく動く証拠ではなくて、
さぼってないかを証明するために必要なもの
みたいなことを聞いたことがあるなｗ

もちろん皮肉としていってるんだけど

2017/06/28(水) 21:24:21.63

>>623
> 自分で作れば責任取らなくていいんだ。って勘違いしちゃうわけｗ自分で作れば責任取らなくていいんだ。って勘違いしちゃうわけｗ

分かるわーw

しかし、テスト使ってカバレッジとかやればそれでOKとか思ってる考えの浅いバカってホント多い
カバレッジは全ての引数パターン網羅してるのか？ん？
結局、テストしたという結果が欲しいだけ（それが最重要だと思い込んでる）
上司に出す報告書にそれらしい事がかかれていればそれでOK（そもそも上司に判断能力がない）の世界
そして重大なミスが起これば責任のなすりつけ&皆で土下座といういつものスタイル

2017/06/28(水) 21:29:57.25

このように、ITという半分クリエイティブな仕事をゼネコン同様のツリー構造にしてしまってる日本の最低センス
全てが資本の食い物にされてるだけなんだよね
国内だけならいくら効率悪くても単価高くなっても、客にふっかければそれでOKでいままでやってきたんだよ
それがネット社会になって国際化が進んで他国と比較される機会がでてきて笑われてるというのがここ十数年の日本のIT

さすがにそろそろおかしいと気付けないもんかねえ

あ (ｽﾌｯ Sdbf-d3f0) · 2017/06/28(水) 21:34:29.47

>>618
人によって解釈が変わるのはテストとして絶望的だわな。
「正常に表示されること」って文言見ただけで即却下の類。
結果のエビデンスに関してはどうとも言えんな…。捏造を疑い出すときりがない。

あ (ｽﾌｯ Sdbf-d3f0) · 2017/06/28(水) 21:40:23.94

>>619
検証が正しいと言う保証は、首かけるぐらいしか無いだろ。
テスト上失格は仕方ないが、メクラ判ついたらクビだよ。

>>624
確かテストケースが組み合わせ爆発するのがあったはずで、その辺去勢した。

なんか勘違いしてるみたいだけど、本気でやってるからなぁ。

2017/06/28(水) 21:46:44.53

>>628
本当に必要なことと、政治的に必要なことが逆になってるからねｗ

テスト結果をエビデンスとしてキャプチャ画像を残すのは政治的な理由。

テスト結果なんて「All OK」の文字だけで本当は良いはずなんだよ。
本当に必要なのはテスト内容。テスト結果をいくら見たって意味がない。
テスト内容を見なければ意味がない。

でもエビデンスを求めてる方は、テスト内容が理解できない。
だからテスト内容の代わりに、テスト作業をやったという証拠を
もらうことで安心感を得られるｗ

だからテスト作業の内容が簡単であっては許せないんだよ。
安心感の根拠となってるのが
「こんな面倒なこと（画面キャプチャを取る）をやったんだ。
頑張ってるということは、ちゃんとやってるに違いない」
という思いなんだからｗ

本来はテスト内容は書くのが大変。テスト作業自体は簡単。テスト結果も簡単。であるべきなんだが
テスト内容がわからない人に、頑張ってる所を見せるため、テスト作業を大変なものにしてしまう。

そしてエビデンスを求めてる方も「俺らはキャプチャ画像をチェックした。ふぅ～大変だったぁ～」
と言いたいがためにキャプチャ画像を要求してるｗ

大変なことを頑張ってやり遂げた！偉い！感動した！
これが駄目なやり方の全てだよｗ

2017/06/28(水) 21:47:49.13

>>629
> 確かテストケースが組み合わせ爆発するのがあったはずで、その辺去勢した。

だからそれを修正するのに、jQueryをフォークする必要はないと言ってんだけど？

2017/06/28(水) 22:04:10.32

強く建前を要求しその建前さえあれば中身糞でもOKなのが日本のITだよなぁ

**デフォルトの名無しさん** (JP 0Hcb-LvKX) · 2017/06/28(水) 22:20:22.76

まぁ実際に使いたい機能はほんのちょっぴりなのに
無駄にでかいフレームワークやライブラリ使うと
使わないロジック部分で変な影響あったらやだよねと思うことはある
最近は行儀のいいコードがほとんどなのでそういうことないけど

2017/06/28(水) 22:40:11.31

所詮は生産性を観点に於いて使えば宜しい
あとはオナニーの世界

あ (ｽﾌｯ Sd62-H77/) · 2017/06/29(木) 00:12:45.84

>>630
テストケース作るのは大変だな。
シナリオ作って、なんやかんや。

チェックは後から確認するくらいで、普段は正直エビデンス画像見ないよ。見るだけで時間かかるし。

>>631
なんでしたんだっけ。
追従やめて内製にしたのは確か覚えあるんだけど。

2017/06/29(木) 03:41:19.14

reactってAjaxの文法サポートしてんの?

2017/06/29(木) 04:29:41.54

情報公開が大切だって、常に橋下が行ってる。
公開していないものは、簡単にねつ造できる

教授になった医者の話を聞いたら、実験サンプルは、10個もあれば十分。
それを少しいじって、データを100以上に増やす

そういうやり方をすれば、他人よりも仕事が速く、材料費も安くつくから、出世できる

臨床実験など、外部から検証できないものは、ダメ。
皆で、数値合わせだけするから

真面目に働くのがイヤだろ。
しかも、まともに検査するにはお金がかかるけど、会社は出さないから、できない。
それなのに、上司はいじめてくるから、ねつ造せざるを得ない

**デフォルトの名無しさん** (JP 0H16-CicO) · 2017/06/29(木) 14:08:41.17

>>630
> テスト結果なんて「All OK」の文字だけで本当は良いはずなんだよ。
ユニットテストならそれでいいがな

2017/06/29(木) 18:38:01.98

>>623
ライブラリを使おうが、使わなかろうが、責任をとるのはコードを書いた本人。
ライブラリを使って書いても、書いたコードにバグがあれば不具合は発生するし、脆弱性が発見される事もある。
つまり、ライブラリを使うことは安全を担保する事にはならない。
セキュリティを意識するなら攻撃手段を知って対策をとる必要があり、「脆弱性対策でコードを修正するのが嫌」なんて意識の奴にはそれがないから安全なコードは書けない。
いい加減、「ライブラリの方が安全」という幻想は捨てろ。

2017/06/29(木) 19:44:32.14

>>639
もとまとそれは、
有名どころのライブラリーと同レベルの"安全"を構築するのに必要な知識と工数、それらの後々の保守
それを自分で行ってまで、ライブラリーは安全が確認できないから使わないとか言い出すバカへの反論だろ

2017/06/29(木) 19:56:45.52

>>640
例えば、有名でgithubで配られてたなら良いんだ。無条件で何もかも信用すると。

2017/06/29(木) 20:01:07.23

>>641
おまえって文章の理解力はおろかコミュニケーション能力すらないんだな
そんな人間が客の要求するものを提供できるのか？ん？

で？640のどこに有名でgithubにあれば信頼すると書いてあるんだ？ん？

だいじょうぶか？

2017/06/29(木) 20:58:30.42

何勉強すればいいのかわからん
JavaScriptなのか
TypeScriptなのか
Node.jsなのか
io.jsなのか
CoffeeScriptなのか
Jadeなのか

Babelなのか
Webpackなのか
gulpなのか
Gruntなのか

2017/06/29(木) 21:00:37.94

>>640
いいたいことはそっちか。

まず、考え方のスタート地点からして間違っている。
計るべきは「安全」ではなく、「リスク」だ。
安全は定量的に計ることが出来ないが、リスクはテストで計測できる。
「有名どころはライブラリと同レベルの安全」なんてものは主観的なイメージでしかない。
具体的なリスクを想定するならテストは容易。
例えば、ipaはSQLインジェクション検出ツールというものを公開している。
https://www.ipa.go.jp/security/vuln/iLogScanner.html
XSSやDOSだってテストは可能だろう。攻撃手法は確立されているのだから、実際に攻撃してみれぼすむことだ。

2017/06/29(木) 22:22:51.18

>>644
本当にレベルが低いなおまえ
先日のレスのやりとりをもういちど読み返してみろよ
サラリーマンITドカタとしてならおまえの言うことも分かるがそれが原因で海外と大きく差が開いてるって話だろ
一生高みを目指すこともなく、社内でがんばりなさい

2017/06/29(木) 22:24:00.88

>>643
まず何をしたいか（何を作りたいか）、どこまで行きたいかだろ

2017/06/29(木) 22:51:27.98

>>643
勉強なんかすんな
好きなものを学習しろ

2017/06/29(木) 23:06:47.99

>>638
> ユニットテストならそれでいいがな
レスの仕方間違ってるって言われない？

「ユニットテストはそれでOK」じゃなくて
NGな場合を言うべきでは？

ユニットテストがそれでOKってのは
最初からわかってることでしょ？

2017/06/29(木) 23:12:51.48

>>643
あなたさては…極めし者ですね？

2017/06/29(木) 23:26:13.53

>>639
自分で言うことを整理してから言おうよｗ

「ライブラリの方が安全」というのと
問題が起きた時に「責任を取るのはコードを書いた人（ライブラリを使った人）」
というのは両立できるでしょ？

責任を取るリスクを減らすために
より安全なものを使うんだよ。

2017/06/29(木) 23:27:37.65

問題が起きた時に責任を取るのが自分なのはどちらも同じだから、

問題が起きにくいものを選んでも
問題が起きやすいもの選んでも
リスクは変わらない

なんて思う人居ないよ？

あ (ｱｳｱｳｴｰ Sa4a-H77/) · 2017/06/29(木) 23:38:19.05

なんか話が散らかってるな。

問題が何故問題かと言うと、テストケースとして無茶苦茶なパターン数になるものや、完全に使わない関数を削除して、品証通して出荷した物に、
次のバージョン入れたら同じ事せなならんでしょ。
そうなったら最早同じようにパッチを内製してしまう方が効率的だとは。

一回認証取ったらそれ改修する≒リコールに近い取り返しつかんものもあるんだし。

2017/06/29(木) 23:41:00.76

>>652
> 次のバージョン入れたら同じ事

「同じ事」って何？

2017/06/29(木) 23:45:50.62

なぜか世の中には不思議な人が居て、

あるライブラリに自分でパッチを当ててバージョンを上げると、
テストが不要になると考えてる人がいるということ。

2017/06/29(木) 23:46:35.74

結局自分でパッチを当てるのはテストをしたくないからなのかな？

2017/06/30(金) 00:19:46.25

「勉強」って言うと具体的に何をするのかがわかりにくくなるんだよな
例えば「資料を集めて最新情報を頭の中にぶち込んでいく」とかならいいと思うね

あ (ｽﾌｯ Sd62-H77/) · 2017/06/30(金) 08:13:14.22

>>653
うん、もう一回改修/去勢して、もう一回テストせなな。

>>654
何言ってるんだ…？テストするよ。
そのままVerUPするとそのタイミングと範囲が自分たちが使う範囲外であろうがなかろうが、テストケース自体切り直さないといかんくなるだろ。
パッチはその辺り、既存テストへの増分として考えればだいぶマシだし、デグレの原因わかりやすい。

テストしたくない、したい、ではないよ。
どうせするんだから。
有意義なテストしないと、意味ないじゃん。

内製≒ノーテストだと思ってるんだろうか？