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/23(金) 09:33:27.67

いやぁ
「他の言語と比べて変わったところ」という意味ではJSもPyhonも変わらんよ
Rubyはそれらと比べて一回り自然になることを目標に作られているが

つうかJSでそれらの本は時代遅れよ　だってES5の本じゃん
それにそれらを必ずしも読む必要はないよ
確かに特にプロトタイプチェーンとかを理解しようと思えば
仕様周りの説明を理解することが必要だけど
別にそういうこと自体の量や難しさは高くない

ただそれらを理解せずとも使える、わかった気になれるので
学習に良くない情報が溢れてしまってる
そんな知識に染まりきった後に勉強しようとすると大変
そもそも本当ならクラスベース的なものを教える前に
そのベースとなっているプロトタイプベースを教えないとおかしいが、そういう指導書はまだ無い

あとはJSは「正解」を作らない主義というのも影響が大きい
「正解」が明確にないからこそ、偉い人の言葉だったりとか、最新のAPIの策定状況を見て
今の「正解」を常に感じ取っていく必要がある
５年前の最新の知識、例えば上の本の内容を今使ったら笑われる　それがJSの難しさだった
が、ここ１年くらいはJS周りが停滞してる（その代わりCSSなどスタイル周りが進歩した）ので深く学ぶチャンス

2017/06/23(金) 09:48:05.19

> あとはJSは「正解」を作らない主義というのも影響が大きい

正解を作る主義の言語なんてあったか？

> 最新のAPIの策定状況を見て
それはJavaScriptじゃなくてブラウザAPIの話ですね
これらは違うものなんで分けて考えられるようになりましょう

2017/06/23(金) 11:57:19.92

オブジェクト指向JavaScript、2012、Stoyan Stefanov

この本の第6章「継承」だけで、40ページある。
プロトタイプで、クラス継承を真似るのは、非常に難しい。
12パターンも書いてある

1. ECMA標準の方法
2. YUI, Ext.js の方法
3. jQuery, Prototype.js の初期バージョンの方法
4. jQuery の最近のバージョンの方法

普通の言語では、クラス変数で悩まないけど、JSでは、
obj.prototype.prop = 'aaa'
と自分で、1階層上へ持って行かないといけない

obj.prototype, obj.__proto__ の違いとか、わかりにくい

2017/06/23(金) 12:02:48.36

正解を作らないというより、用意された正解がないんだよ
ベストと思われてる手法がすでにトリッキーで他言語からみたら意味不明な形の場合が多い
当然こんなのは入門書よんだくらいじゃ想像もできない
使い手側の熟練度によって言語世界が進化してきたようなものだからなぁ
先人たちの変態努力により、こんなのJSでできるの？！の繰り返しで進化してきた物

あと、JSはwebブラウザ上でありとあらゆるメディアを扱うインタラクティブなUIを構築する言語というのがでかい
そもそもrubyレベルとは仕事の大変さが100倍違う

2017/06/23(金) 12:45:18.23

ES2015でクラス構文用意されてんだから、それ使っとけばいいのよ。

2017/06/23(金) 12:50:37.53

>>497
何のためにトランスパイラとかが存在すると思ってる？
クライアント気にせずに最新仕様でつくれるなら誰も苦労はしないんだよ

2017/06/23(金) 13:55:47.25

>>498
？トランスパイラ使ってるならなんの問題もなく最新構文使えるじゃん。何言ってんの？

2017/06/23(金) 15:58:55.19

>>499
ここはaltJSのスレじゃないんだよ
JavaScriptの構文の話してんだろ？ん？

2017/06/23(金) 16:11:36.09

on railsなしのrubyに実用性があるのか？ってのと
環境構築の観点から言ってrubyってどうなの？って思うんだけどな特に初心者とか

2017/06/23(金) 17:04:17.71

>>500
ES2015はjavascriptですが。

2017/06/23(金) 17:24:47.76

>>494
違うものじゃないよ
例えばPromiseベースに変わっていったりすることだとか、
APIをどの程度普通に活用していくか、またAPIを提供する側では貰うか
例えばWebComponents関係のAPIを見て、
ああ今からはO.cをこの様にこの程度使ってもいいし、使ってもらってもいいな
ああ、O.cはこの程度の機関のつなぎのために使えるもので、
将来的にはクラス構文に頼るべきなんだね
じゃあ今はO.cでそこそこ自然に、そして将来はきちんとクラス構文を自然に適応できるような設計が良いんだね
のように関数などの設計の仕方、他にも名付け、役割のもたせ方などの今のベストプラクティスが学べる

2017/06/23(金) 17:34:10.86

>>495
確かにprototypeプロパティの存在が一番理解をややこしくしているとこだね
だって一番でしゃばってるくせに一番本質的でないものだからね
あと、昔は__proto__が非標準という点も教えにくかった理由の一つだと思う

本当はプロトタイプベースというのは好きなクラスシステムを用意に構築できるものだけど、
JSではプロトタイプに直接触らせてもらえないばかりか最初から用意されてる唯一の駄クラスシステムを使うしか無かった
それで駄クラスシステムをハックしてバックのプロトタイプ操作を活用するテクが要るようになった時点で終わり
でも今はそんな過去すっぱり忘れて自由なプロトタイプ操作と、ベターな新クラスシステムで覚えていっていいと思うけどね
それなら難しくないはずだよ
ただしnewTarget周りまで踏み込むとやっぱり仕様実装レベルの理解が要るし、シンボル周りもちょっと臭いけどね

2017/06/23(金) 19:20:59.60

>>502
だからね

クライアントの環境無視で最新仕様を使い放題なら苦労はないつってんの

大丈夫かい？

2017/06/23(金) 22:30:15.32

>>505
だからね、どの環境でも最新の仕様が使えるようにトランスパイラがあるんだけど？

2017/06/23(金) 23:49:03.52

> クライアントの環境無視で最新仕様を使い放題なら苦労はないつってんの
Rubyとかでもクライアントの環境で動かすツールを配布するのであれば
クライアントにインストールされているRubyのバージョンを意識ないといけないんですが？

逆にJavaScript（nodejs）で動くサーバーアプリであれば
クライアントの環境無視できますよ。

あんたが言ってる問題点の原因は全部ブラウザのせいでしょう？
JavaScriptではなくてブラウザのせいでしょう？
だから分けて考えられるようになりましょうっていってんの

2017/06/24(土) 00:23:38.41

>>506
だからそれはaltJSの話だろ？ん？

JSの構文の話してんのに関係ないじゃん

大丈夫かい？またループしてるよ

2017/06/24(土) 00:26:18.66

>>507
君も話ができない人間だなあ

↓ちゃんとかいてるだろ？

>JSはwebブラウザ上でありとあらゆるメディアを扱うインタラクティブなUIを構築する言語というのがでかい
そもそもrubyレベルとは仕事の大変さが100倍違う

2017/06/24(土) 00:33:07.24

世の中にはJavaScriptとほとんど同じ文法を持つ
altJSがあるんだぜ？
その名はECMAScriptっていうんだ

2017/06/24(土) 05:43:28.56

インタラクティブなUIを構築する言語というより、
そもそも自己完結してるセマンティクス性の強いHTMLをハック、拡張する程度だったのが
アプリケーションプラットフォームとして利用する用になってきてどうしよう、大変ということだな

結局はそのための最低ラインまで持っていくのに何らかのフレームワークが必要になってくる
とは言えあくまでブラウザで自然に使えるWebページの１つだし、
Web Componentsで全てオレオレに構築してやるぜみたいなことはなかなかしない

結果非常に中途半端な微妙なラインで色んな技術やフレームワークと共に
周りの様子を常に伺いながら生きていかないといけない
自由が一番あるようで最もお手上げ状態なのが今のJS界

Nodeなんかもその呪縛から解き放されてるわけじゃない
最初は結構独自にやろうとしてたみたいだが、結局大きくなって
「標準的なこと」を意識すればAPIの設計だったりWebに引っ張られるし、
Promiseだったり重要なコア部分もWebの発展とともにある

2017/06/24(土) 12:56:08.56

> 結局はそのための最低ラインまで持っていくのに何らかのフレームワークが必要になってくる

で、そういう話の最低ラインまで持っていこうとするなら
どの言語でもフレームワークが必要になるわけで

2017/06/24(土) 13:14:33.08

ライブラリはほぼ必須だがフレームワークはちがうな

2017/06/24(土) 13:55:43.97

>>513
それはお前の最低ラインが低いだけだよｗ
JavaScriptと同じラインまでやろうとすると
どの言語でもフレームワークが使われてる

2017/06/24(土) 13:57:36.02

最低ラインを低くすればJavaScriptでもjQueryというライブラリと
UI専用マークアップ（HTML+CSS）だけで十分な場合も多けどね。

2017/06/24(土) 14:00:05.98

>>514
具体的は？

フレームワークの多くは品質を固定して大量生産したり、チーム内のワークのばらつきを抑えるためのものでレベルや品質を極めるために使うものじゃないぞ
バカでもがんばれば一定のものが作れるというだけの話だよ
逆にレールから外れる必要があることをするときは寧ろ手間が増える

ライブラリーとフレームワークの違い分かってるかい？ん？

2017/06/24(土) 14:07:41.35

>>516
何の言語のフレームワークを教えて欲しいの？

Rails？
Spring？
Django？
.NET Framework？

なんでどの言語でもフレームワークが使われてると思う？

2017/06/24(土) 14:09:26.36

>>517
javascriptで

2017/06/24(土) 14:10:03.31

あとオレオレフレームワークの定義なんてしないで、
どこから引用することで、説得力を上げるようにした方がいいよ

http://e-words.jp/w/%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF.html

ソフトウェアの分野では、ある領域のソフトウェアに必要とされる汎用的な
機能や基本的な制御構造をまとめた半完成品のことを「ソフトウェアフレームワーク」
「アプリケーションフレームワーク」などと呼び、これを略してフレームワークと
呼ぶことが多い。具体的なソフトウェアだけでなく、汎用的に適用できるプログラムの
設計モデルや典型的な処理パターンなどを含めてフレームワークと呼ぶ場合もある。

フレームワークは特定のプログラミング言語で書かれた、そのまま利用できる
ソフトウェアの主要部分の雛形(テンプレート)と、汎用的で再利用可能な
クラスやライブラリ、モジュール、APIなどで構成され、また、開発者がコードを
記述して機能を追加、拡張するための方法や規約などが定められている。
開発者は規約に従ってフレームワークの一部を改変したり、自らの必要とする
機能や処理を記述して追加することで、主要部分の設計・記述を省略して迅速にソフトウェアを完成させることができる。

2017/06/24(土) 14:10:48.86

>>518

https://furien.jp/columns/187/

◆AngularJS
◆Backbone.js
◆Ember.js
◆Vue.js
◆Knockout.js
◆React
◆Riot.js
◆Aurelia.js

2017/06/24(土) 14:13:42.94

>>519
小学生かな？
ことばなんて狭義広義でいろいろ解釈あるだろ
ライブラリーと対比する形でフレームワークという言葉が出る場合、それが何を意味するかくらい分かるだろ
そういうコミュニケーション能力の低い人間が"人の求める物"を作るなんて難しいよね

2017/06/24(土) 14:13:51.32

最低ラインをクリアするにはどの言語でもフレームワークが必要だけど
多くのサイトは最低ラインまで必要ではなくて、jQueryという
ライブラリで十分ということはjQueryのシェア（72.6%）からも明らか

https://w3techs.com/technologies/overview/javascript_library/all

2017/06/24(土) 14:14:25.17

>>521
なんでフレームワークの一般的な定義に
文句つけてるの？

2017/06/24(土) 14:16:02.46

もしかして引用先を見ないで
俺のレスだけみて脊髄反射（笑）してしまったとか？

引用の続き

http://e-words.jp/w/%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF.html
> 汎用的で再利用可能なコードをまとめたものであるという意味では
> ライブラリやモジュールに似ているが、ライブラリでは全体を
> 制御するコードを開発者が記述し、ライブラリの提供する個別の
> 機能を呼び出す形となるが、フレームワークは全体を制御するのは
> フレームワーク側のコードで、そこから開発者が個別に追加した
> 機能を呼び出す形となる。このように制御-被制御の関係が
> 反転している状態のことを「制御の逆転」(IoC：Inversion of Control)という。

2017/06/24(土) 14:16:08.51

>>520
で？
それらのどこが必須なのかな？ん？

2017/06/24(土) 14:16:53.00

>>525
最低ラインを満たすなら（どの言語でも）必須だし、
最低ラインを満たさないなら必須ではない

2017/06/24(土) 14:22:37.32

最近は普通のアプリはご無沙汰でnodeとsocket.ioをサーバーにしてクライアントはpixi.jsとglslのwrbGL使ったスマホゲームばかり開発してるけど
JSゲーム関連でもゲームフレームワークと呼ばれるものがあるがクオリティ考えるとほぼ使い物にならんぞ？

おまえのような業界の流行を使う事が目的になってるようなやつ結構いるんだよね
googleのアングラーですら識者の間だと賛否あるってのにそれに頼りきって使う=クオリティってどんだけレベル低いんだ？ん？

2017/06/24(土) 14:44:13.37

「クオリティ」という理由を言った以上
どういう点の「クオリティ」が理由で
使いものにならないか説明する義務がある。

思いつかなかったからってクオリティ以外の話に逃げるなよ？

2017/06/24(土) 14:46:56.26

あと逃げられないように、JavaScriptの
有名ゲームフレームワークを上げておこうか

もちろん俺がまとめても説得力がないんで

HTML5ゲームの種類とゲーム用エンジン・フレームワーク15選
https://furien.jp/columns/216/

Cocos2d-JS
enchant.js
Kiwi.js
略

あとUnityでもJavaScriptは使えたな

2017/06/24(土) 15:07:32.10

gameQueryが載ってない
pixi.jsも載ってない

2017/06/24(土) 15:09:39.25

>>530
無名だから乗ってないのでは？

自分からマイナーなものを使って
クオリティが低いって言ってりゃ世話ないなｗ

2017/06/24(土) 15:15:02.76

jQueryのゲーム用拡張版とRPGツクールMVのPRGスクリプトのベースライブラリなんだけど
まぁgameQueryはマイナーっちゃマイナーだけどpixiがマイナーっていうのは違うと思う

2017/06/24(土) 15:17:39.77

>>512
言い方が悪かったな
.NETのような取り敢えずこれでしょと言えるほどの準標準クラスのUIフレームワークが無いということ

2017/06/24(土) 15:28:56.29

準標準クラス（？）でなければUIフレームワークはあると
力説されましてもｗ

2017/06/24(土) 15:29:25.85

UIフレームワークがいくらでもあることなんて知ってますよｗ

2017/06/24(土) 15:35:47.77

>>508
babelは
最新のjs仕様を解釈してES5等のコードに変換するトランスパイラでありaltjsではないよ。
altjsというワードが何か良くかんがえてみて。

babelがなんでできたかかを調べてみると良いと思う。

2017/06/24(土) 15:43:30.87

また俺様仕様でケンカしてるのか？ｗ

2017/06/24(土) 18:54:19.51

WebのUIフレームワークはHTML+CSSというUIフレームワークのフレームワーク
だからやりきれない部分がある
かと言ってフルCanvasにする勇気はない

2017/06/24(土) 20:02:07.57

>>538
Reactが当てはまるんじゃないかな。
あればCSS-in-JSと言ってCSSもJSコード化できるから
class名前衝突みたいなことも起きない。

2017/06/24(土) 20:23:15.13

確かにReactは素晴らしいがあれはUIフレームワークというより
UIフレームワークのための下地を敷き直すためのものなんだよね
だから実際なにかをしようとするとReact＋αで使う

何かベース技術を高度にまとめあげたものと言うより、沼地の舗装なんだよね
本当ならそこまで標準で持ってくるべきだと思う

2017/06/24(土) 21:03:21.38

つまりC言語の標準ライブラリに、GUIライブラリを追加しろと
言ってるようなもんだｗ

2017/06/24(土) 21:57:01.47

Reduxで非同期処理。特に async -awaitを使う上で
おすすめのミドルウェアはなんでしょうか？
いくつかあるんで悩んでます。
やはりredux-promiseあたり？

2017/06/25(日) 05:15:16.70

async-await構文とReduxって相性良いのかなあ
いっそ捨ててまだPromise非対応のWeb APIを容易にPromise化する手段と
observable系のもうワンランク規模が小さい補助フレームワークと
非同期系以外のフレームワークでこなすのが良い気がする

2017/06/25(日) 06:14:30.51

jQuery 3.0のAjax関連がWeb APIをPromise化してくれるよ
正確にはDeferredなんだけどPromise互換になった

jQuery 3での変更点～ Promises/A+互換となったDeferred機能を中心に
https://codezine.jp/article/detail/9588

2017/06/25(日) 07:41:17.07

個人的には今のところredux-sagaが正義。だな

2017/06/25(日) 11:06:59.71

>>529
おまえって本当にうわべだけのweb屋なんだな
blogぐぐって"流行"うんちくを貯めるのが目的と化してるじゃん

で？

フレームワーク使わないものはレベルが低い云々の落とし前をはやくつけたら？ん？

2017/06/25(日) 11:18:22.43

まぁ、こういう経験もセンスもない人間って"何かを使う"ことで自分のスキルがあがったと勘違いするんだろうなあ
誤解を恐れず他言うとフレームワークなんてのは学習コストがかかるかわりにバカがバカなことできないレールが敷かれることなんだよね
それによるコードや構造の制約がチーム開発に向いてるという側面もあるが、
なにを曲解してるのかフレームワーク使わない=その程度の低いレベルなんて言い出すバカが居るんだよな
blog屋の言うこと真に受けてるるんだろうが、ああいう奴らはとにかく新しい流行を作り出してそれを記事にして必要性をアピール、ページアクセス稼ぐのが目的なのにね

2017/06/25(日) 11:29:28.28

ちょと新しいフレームワークを皆で使ってみようという試みが許されない職場はレベルが低いと思う。

2017/06/25(日) 13:07:18.05

>>546
遠吠え吐いてないで、何か言い返せよｗ

2017/06/25(日) 13:08:07.55

結局この質問に答えられない挙句ｗ

「クオリティ」という理由を言った以上
どういう点の「クオリティ」が理由で
使いものにならないか説明する義務がある。

思いつかなかったからってクオリティ以外の話に逃げるなよ？

2017/06/25(日) 17:16:09.16

ここ質問スレだよね？
1のルールがん無視なんだけど、ここ質問スレだよね？
ライブラリ関係の質問どころかライブラリで議論しちゃってるけど、ここ質問スレだよね？

2017/06/25(日) 19:34:26.21

もはやそれがこのスレの伝統だから
そのツッコミも含めてな

2017/06/25(日) 22:48:16.18

4年近くこの状態だからな
NGにいつもの荒らしと構う馬鹿のID二つ突っ込む癖を付けとけ

2017/06/26(月) 08:26:17.61

俺様仕様のクオリティｗ

2017/06/26(月) 14:37:47.78

JSデバッグしているときにConsoleに出てくるエラーメッセージの
右側のソースファイル名: 行番号のリンクに
「VMxxxx: 行番号」ってなっていることあるんだけど、
この「VM」ってファイル何？

2017/06/26(月) 19:06:26.51

VMっつったらバーチャルマシンしかないだろう
つまりエンジン内の内部ファイルのJSバックエンドのこと
こういうの
https://chromium.googlesource.com/v8/v8/+/master/src/js/array.js

2017/06/26(月) 19:10:38.37

ああ、このVMがv8エンジンなのね、
でもJSの本体エンジンがJSで書かれてるのっておかしくね？
俺はバイナリだと思ってたよ。
このエンジンのJSコードは誰が処理してるのさ？

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だってあるんだから。