スレ立てるまでもない質問はここで 156匹目

**デフォルトの名無しさん** · 2021/02/20(土) 17:17:54.73

この板はプログラムを作る人のための板です。
あらゆる質問はまず
スレ立てるまでもない質問はここで
スレにしてください。

【前スレ】
スレ立てるまでもない質問はここで 155匹目
https://mevius.5ch.net/test/read.cgi/tech/1606439237/

次スレは>>980が立てること

**デフォルトの名無しさん** · 2021/04/14(水) 02:42:32.31

https://developer.android.com/studio/terms
3.5 Use, reproduction and distribution of components of the SDK licensed
under an open source software license are governed solely by the terms
of that open source software license and not the License Agreement.
訳してみると、
「OSSライセンスの下にライセンスされているSDKの構成成分の使用/再生成/配布は、
　単にOSSライセンスによってのみ左右され、「ライセンス同意」によっては左右されない。」
Android SDK のほとんどはApacheライセンスに基づいているんですが、Android SDKの
「ライセンス同意」には、例えば、他のSDKの開発のためには用いては良くない(may not)
と書かれていますが、Apacheライセンス的には、自由に使用/配布できるとされます。
矛盾しているようで、理解できません。
may not は、must not より緩いとされているので、禁止ということではないということ
なんでしょうか。

**デフォルトの名無しさん** · 2021/04/14(水) 02:52:16.79

>>393
「may not」は立場が上にあるものが、上から目線で「してはいけません」という
時に使われる言葉だと解説しているサイトがありました。
また、3.5は、「components」に関していっていることなので、SDK全体の
ことはさしていないと解釈することもできます。なので、adb.exeや
xxx.jar のようなSDKの中の一部分だけなら自由に配布/使用してもいいが、
SDK全体では駄目、と解釈することも出来るかも知れません。
Android SDKのソースは、AOSPにおいて大部分がApacheライセンスで配布
されているとされ、ApacheライセンスはBSD系ライセンスとされているので、
プロプライエタリなソフトを作りたい人目線ではかなり何でもして良い緩い
ライセンスです。
AOSPのソースコードは100GBあり、ビルドにはさらに150GBも必要とされ、
ダウンロードするのもビルドするのも大変です。
ソースはどう使うのも自由だが、バイナリにどんなライセンスを与えるのも
自由とも解釈できます。「配布を妨げてはならない」などいうような条項は
無かったと思いますので。
結局、良く分かりません。

**デフォルトの名無しさん** · 2021/04/14(水) 10:14:14.50

JavaScriptを知らないのにいきなりTypeScriptを勉強するのと、
JavaScriptを勉強してからTypeScriptを勉強するのとでは、
どちらが早くTypeScriptを習得できそうですか？

※ ちなみに、他の言語はCやC#やPythonなど10年ぐらい経験があります

**デフォルトの名無しさん** · 2021/04/14(水) 10:16:01.80

TypeScript

**デフォルトの名無しさん** · 2021/04/14(水) 10:22:32.32

>>396
前者ということですか？
理由もお願いします

**デフォルトの名無しさん** · 2021/04/14(水) 10:29:49.91

別の言語だからです

**デフォルトの名無しさん** · 2021/04/14(水) 10:41:56.14

この人ダメです
他の人お願いします

**デフォルトの名無しさん** · 2021/04/14(水) 10:44:44.60

javascript自体は理解しておいた方がいいよ
javascriptが消えることは無いけど、typescriptのようなjavascriptにトランスパイルする為のものはそもそもずっと使えるかどうかなど分からないし

**デフォルトの名無しさん** · 2021/04/14(水) 10:52:05.18

>>400
ありがとうございます
なるほど、納得です
それは大きな弊害ですね
それとTypeScriptから始めるとJavaScriptとTypeScriptの境界が分からなくなりそうですし、
やっぱりJavaScriptから始めてみます

**デフォルトの名無しさん** · 2021/04/14(水) 10:52:41.03

別の言語だから
これでわからないならノーセンス

英語を学ばないといけないのですが
ラテン語と英語どっちを先に勉強したほうがいいですかね？

それらは別の言語です
英語を習得したいなら英語を学びなさい

C言語を学ばないといけないのですが
アセンブリ言語とC言語どっちを先に勉強したほうがいいですかね？

それらは別の言語です
C言語を習得したいならC言語を学びなさい

**デフォルトの名無しさん** · 2021/04/14(水) 10:57:14.74

なるほど、TypeScriptとJavaScriptの関係を知らない人が回答していたんですね・・・
恥ずかしくないんですかね・・・？

**デフォルトの名無しさん** · 2021/04/14(水) 11:10:25.44

We frequently see the question “Should I learn JavaScript or TypeScript?“.

The answer is that you can’t learn TypeScript without learning JavaScript!

https://www.typescriptlang.org/docs/handbook/typescript-from-scratch.html#learning-javascript-and-typescript

**デフォルトの名無しさん** · 2021/04/14(水) 11:42:20.28

>>404
OK, I'll learn JavaScript first, then move to TypeScript.

**デフォルトの名無しさん** · 2021/04/14(水) 12:20:43.88

あらら
時間を無駄にしたな

**デフォルトの名無しさん** · 2021/04/14(水) 12:23:23.81

つうか10年やってきてJavaScript知らないというのは少々非現実的な設定だ
自演したいならもう少しキャラ設定には気をつけたほうがいいぞ

**デフォルトの名無しさん** · 2021/04/14(水) 12:38:10.88

Javaを知らないのにいきなりKotlinを勉強するのと、
Javaを勉強してからKotlinを勉強するのとでは、
どちらが早くKotlinを習得できそうですか？

※ ちなみに、私は失礼無礼な>>395ではありません

**デフォルトの名無しさん** · 2021/04/14(水) 12:39:14.52

>>408
Kotlinを勉強したほうが早いですよ
当たり前ですよね

**デフォルトの名無しさん** · 2021/04/14(水) 12:48:18.85

>>409
でもJava自体は理解しておいた方がいいと思うよ
Javaが消えることは無いけど、KotlinのようなJavaにトランスパイルする為のものはそもそもずっと使えるかどうかなど分からないし

**デフォルトの名無しさん** · 2021/04/14(水) 13:35:30.54

Kotlin/JSはトランスパイラだけど
Kotlin自体はトランスパイラじゃないぞ

**デフォルトの名無しさん** · 2021/04/14(水) 15:33:57.73

トランスパイラという言葉が使いたかっただけだ。
どういう意味だ？

**デフォルトの名無しさん** · 2021/04/14(水) 15:43:09.85

別言語のソースコードに翻訳するプログラム
その別言語で動かしたり、更にコンパイルしたりする

**デフォルトの名無しさん** · 2021/04/14(水) 15:46:14.74

コンパイラが翻訳で
トランスレートも翻訳

**デフォルトの名無しさん** · 2021/04/14(水) 16:45:03.36

デジタルトランスフォーメーション
デジタライズ
デジタライゼーション
それぞれの違いを教えてけれ

**デフォルトの名無しさん** · 2021/04/14(水) 16:49:21.41

>>415
ググレカス

**デフォルトの名無しさん** · 2021/04/14(水) 18:09:31.12

git cloneでダウンロードしたVS C++のソースをコンパイルしようとするとutf8のファイルが文字化けしてエラーになります。

BOMを付ければ良いそうですが、ソースが大きい為、手動ではとても全部はできません。
git cloneの段階でBOMを付ける指定などできないでしょうか

またはutf8のファイルに自動でBOMをつけてくれるツールなどはないでしょうか

**デフォルトの名無しさん** · 2021/04/14(水) 19:22:44.82

メイクファイル、ましてや/utf-8でコンパイルできないような妙なソースを拾ってくるんじゃありません
拾ってきた場所に返してきなさい

**デフォルトの名無しさん** · 2021/04/14(水) 19:51:00.20

株式市場の板みたいなのって大量にリクエスト受信しますよね？
どうやってさばいてるのですか

**デフォルトの名無しさん** · 2021/04/14(水) 20:12:16.65

リクエストをロードバランサーで大量のサーバーに振り分けてる

**デフォルトの名無しさん** · 2021/04/14(水) 20:42:59.37

専用の機械もあるし、ソフトウェア的なバランサーもある

**デフォルトの名無しさん** · 2021/04/15(木) 01:20:58.49

CDNとか使ってるんじゃないの

**デフォルトの名無しさん** · 2021/04/15(木) 07:03:08.77

>>417
ム版だし、ここは自作したら？
ファイルの先頭に3バイトつけるだけの簡単なお仕事

いろんな文字コードが混ざってるならちと面倒くさいけど

**デフォルトの名無しさん** · 2021/04/15(木) 07:08:54.91

UTF-8自動判定させようとしてBOMって言ってるんだろうから加工じゃなく418がベストだと思うがなぁ

**デフォルトの名無しさん** · 2021/04/15(木) 07:42:45.67

いろんな国の人が関わってちゃんぽん状態だから
utf8の必要な部分と、アスキーでいい部分と混在してるんですよね

**デフォルトの名無しさん** · 2021/04/15(木) 08:16:42.67

ん、チャンポンだとそれこそメイクファイルあるんじゃないのか？
git pull からの make 出来ないと不便だろ

**デフォルトの名無しさん** · 2021/04/15(木) 11:56:37.12

gitでコンパイルまではしなくて
別にコンパイル用のwindowsのバッチがあってそこで
ＶＳのコンパイルをする部分に問題があります。

ＢＯＭがないと文字化けするのはＶＳに問題があるそうです。

**デフォルトの名無しさん** · 2021/04/15(木) 12:06:51.91

メモ帳すらもBOM無しが標準となった現代で、VSに責任転嫁するのは無理がある
UTF-8とShiftJISの自動判定は理論上不可能で、コンパイルオプションで明示してやる必要があるのは、それこそ常識に近い
エンコーディングを意識していないメイクファイルしか入ってないプロジェクトじゃ、メンテナンスの品質もお察し
そこを踏まえての>>418なんだよな

**デフォルトの名無しさん** · 2021/04/15(木) 12:25:59.06

本当にアスキーとutf-8だけなら区別する必要無いんじゃね

**デフォルトの名無しさん** · 2021/04/15(木) 13:09:15.34

>>429
内部でのコードは統一されるので文字列リテラルの文字化けが問題
コメントなんて化けても良いんだが
なお、識別子に全角文字使うのは馬鹿としか言えないので考慮の外

**デフォルトの名無しさん** · 2021/04/15(木) 14:56:45.68

>>417
> またはutf8のファイルに自動でBOMをつけてくれるツールなどはないでしょうか

Notepad++で出来る
https://www.howtonote.jp/notepadplusplus/install/index7.html

あと、>>423が言ってるように自作するならここに答えがある（bash, sed, VBAなど複数の方法がある）：
https://stackoverflow.com/questions/3127436/adding-bom-to-utf-8-files

**デフォルトの名無しさん** · 2021/04/15(木) 15:02:55.26

>>431
ありがとうございます

**デフォルトの名無しさん** · 2021/04/15(木) 16:26:12.89

た

**デフォルトの名無しさん** · 2021/04/15(木) 17:44:55.89

もういい加減utf-8に統一できないのだろうか…

**デフォルトの名無しさん** · 2021/04/15(木) 18:05:39.42

日本語には不利だ

**デフォルトの名無しさん** · 2021/04/15(木) 19:10:43.25

エンコードもだけど、新規の案件なのにSubversion使うのはやめてほしい

**デフォルトの名無しさん** · 2021/04/15(木) 20:27:23.34

>>436
そんな現場じゃ他にもっとゲロクソな要素山盛りでしょ
Subversion自体は

**デフォルトの名無しさん** · 2021/04/15(木) 21:18:23.41

>>428
内容を自然言語処理すれば理論的には可能だが

**デフォルトの名無しさん** · 2021/04/15(木) 22:06:53.01

>>434
使う人々の問題だからね。
OS側に文句を言っても解決しない。

**デフォルトの名無しさん** · 2021/04/15(木) 22:11:37.35

git で、指定したhash値の位置にresetしたいんですがhash値がテキストファイルに書かれていた場合ワンライナーでどのように書けばいいですか？

因みに以下では無理でした
cat hoge.txt | git reset --mixed

**デフォルトの名無しさん** · 2021/04/15(木) 22:18:48.30

--mixed `cat hoge.txt`
とか

**デフォルトの名無しさん** · 2021/04/15(木) 22:26:11.24

>>441
ありがとうございます！

**デフォルトの名無しさん** · 2021/04/16(金) 11:13:26.52

勉強で作ってるプロジェクトで
OAuthアプリのidとsecret keyを書いたファイルをうっかりgirhubにpushしてしまいました
アプリは新しく作り直してキーを再取得して、環境変数から読むようににファイルを修正して再度pushしました
ただ、当然ですが前のid等を書いたファイルは履歴から辿れてしまう状態だし
コミット履歴は消せないみたいなので
諦めてリモートもローカルもリポジトリ自体を消して作り直す方がいいですか？

**デフォルトの名無しさん** · 2021/04/16(金) 11:30:17.42

もうキー変えたんだったら放置でいいだろ
GitHubのサポートに連絡すれば消してくれるらしいけど、そこまでするくらいならリポジトリ作り直すわ俺なら

**デフォルトの名無しさん** · 2021/04/16(金) 11:34:15.01

svnの取り消しのVって何の略?

**デフォルトの名無しさん** · 2021/04/16(金) 12:07:57.66

>>444
ありがとうございます
キーは変えたけど、こういうのがずっと履歴に残るのって問題ないのか不安だったんです
大丈夫ならこのまま進めます

**デフォルトの名無しさん** · 2021/04/16(金) 12:26:27.22

Linux や、VSCode, サクラエディタも、BOM付きUTF-8 には対応していない

世界標準は、UTF-8 だけ。
それ以外のソースコードは、古いから危険！

まず、すべてのファイルを、UTF-8に変換した方が良い

**デフォルトの名無しさん** · 2021/04/16(金) 12:37:42.09

>>446
仮にもプログラマなら不安じゃなく事実で判断しろ
当時のキーがいつでも参照できる状態にあるという事実、それ以上でも以下でもない
それが問題になるかどうかは君次第

**デフォルトの名無しさん** · 2021/04/16(金) 12:45:50.01

>>446
消したいならrebaseすりゃいいよ

**デフォルトの名無しさん** · 2021/04/16(金) 12:58:24.75

>>449
GitHubにキャッシュが残るから、サポート依頼が必要
docs.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository

**デフォルトの名無しさん** · 2021/04/16(金) 14:56:00.09

>>445
Vがどこに現れるか知らんけどrevertじゃない？

**デフォルトの名無しさん** · 2021/04/16(金) 18:53:53.45

revertだと前のリビジョンに戻すイメージなんだよな
単に書きかけのものをやっぱりなしにするだけ

**デフォルトの名無しさん** · 2021/04/16(金) 19:19:06.30

svn revertってそういうコマンドだろ
git revertはまた違うけど
何をどこからどこに戻すかの決まりが違うだけで
revertという英単語のニュアンスに反してない

**デフォルトの名無しさん** · 2021/04/16(金) 21:30:26.96

リベートリベートうっさいわ

**デフォルトの名無しさん** · 2021/04/16(金) 22:27:19.51

誰もリベートなんて言ってないんだが
釣りか？

**デフォルトの名無しさん** · 2021/04/17(土) 12:46:25.27

何が問題だったか簡潔に述べよ。
①　日本のプログラマーの低レベルさ　
②　出来もしない仕事を持ってきた営業のミス
③　①②を雇っている社長

【COCOA受託業者 1200万円返納】
ttps://yahoo.jp/yIs0wa
新型コロナ対策の接触確認アプリ「COCOA」の不具合に関し、厚生労働省から保守運用を受託していた業者のパーソルプロセス&テクノロジー社。
同社は16日、業務対価1200万円を自主返納すると発表した。

**デフォルトの名無しさん** · 2021/04/17(土) 12:54:29.79

テスト環境ないからテストせずにリリースしよう
ということを決めた奴がいて、そいつが犯人

**デフォルトの名無しさん** · 2021/04/17(土) 14:19:15.99

1200って何%だ？

**デフォルトの名無しさん** · 2021/04/17(土) 15:53:40.45

プログラミングの技術力とはなんですか？

一通りWEBアプリなどを作れるようになりました。
わからないことがあれば、調べて実装すればいいこともわかってきました。
多分、大抵のことは調査すればできるようになるのではないかと思ってきました。

そこで技術力を上げろと言ってる人たちが、よくネットにいますが
なんの事を言ってるのでしょうか？

一度作って理解してしまえば、次に作るとき早く作れるようになります。
技術力とは作成するスピードの事を言っているのですか？
それなら理解できますが
実際、技術力とはなんのことを言ってるのでしょうか？

**デフォルトの名無しさん** · 2021/04/17(土) 15:56:47.44

>>459
お前天才だからもうやることないよ
コンプリートしたってこと
別の業界行け

**デフォルトの名無しさん** · 2021/04/17(土) 16:08:42.20

日本最強プログラマー学生選手権やるから参加してみたら

**デフォルトの名無しさん** · 2021/04/17(土) 16:10:19.70

>>459
営利目的としてシステムを動かしてみればわかるよ

**デフォルトの名無しさん** · 2021/04/17(土) 16:47:03.87

>>459
>多分、大抵のことは調査すればできるようになるのではないかと思ってきました。

技術力とはなんのことを言ってるのか調査してもわからなかったの？

**デフォルトの名無しさん** · 2021/04/17(土) 17:15:06.39

プログラム作れるはスタートライン
そこからが大変

**デフォルトの名無しさん** · 2021/04/17(土) 18:27:41.48

実際のサービスをやることを考えたら負荷やら色々問題が出るのに動けばokは素人しか許されないよね
インフラどうするかとかはプログラマーは管轄外だとしてもソフトウェアのパフォーマンスチューニングとかはどこに負荷がかかってるのか調べたり色々やることはあるからね
>>459レベルだとSQLもよく分かってないでしょw

**デフォルトの名無しさん** · 2021/04/17(土) 18:53:05.70

>>459
そういう業界談義はマ板でやれよ
板の主旨すら読み取れないのに技術がどうとかバカじゃないの

**デフォルトの名無しさん** · 2021/04/17(土) 21:01:10.12

>>462
こういう答えなんだよな
まったく具体的じゃないから、なんのことかわからないんだよ

>>465
つまり、効率よく動かす事を技術力というのか

**デフォルトの名無しさん** · 2021/04/17(土) 21:29:41.83

>>467
技術力を上げろを実力を上げろに変換すれば
ネットで調べたらだいたいできるよねとか
慢心することもない

**デフォルトの名無しさん** · 2021/04/17(土) 23:13:46.68

完全に理解した奴が現れたわけだ

**デフォルトの名無しさん** · 2021/04/17(土) 23:38:47.85

>>467
具体的にしたら本何冊にもなる
だから自分で何が必要か考えて文献を紐解くしかねえんだ
思考停止した時点でおわり
頑張ってな

**デフォルトの名無しさん** · 2021/04/18(日) 00:39:34.65

一人でWebアプリを作れて問題が出ても自己解決できるメンバーはかなり頼りになる
もう少し上のレベルになると困ってから調べるんじゃなくて、事前に一通り知ってたり勘所を押さえてるから無駄なく効率的で、想定漏れのバグもほとんど作り込まない
高スキルの人になるとネットの質問に回答が付いていないような情報の少ないミドルウェアやライブラリのバグやその迂回方法なんかもすぐに答えにたどり着く

**デフォルトの名無しさん** · 2021/04/18(日) 00:50:40.72

セキュリティや性能なんかは技術力の低いチームだと知らない間に下手こいていて、問題に気付いてないことも多々ある
要件が緩いなら別にいいけど、本来1秒で済む処理を毎回1分掛けてたら作業効率は下がる
保守性が高くメンテしやすい設計やソース、開発環境が整備されていると生産性も品質も底上げされる

**デフォルトの名無しさん** · 2021/04/18(日) 05:57:52.63

医学でもそうだけど、技術なんて無限にある。
何万冊もの本・論文が出てる

個人じゃ太刀打ちできないから、
大事なのは、歴史・先人の成果を流用すること

Ruby on Rails から、Elixir のIoT・Nerves へ進んでいるのは、その証拠。
サーバー側も、RubyからGo へ

つまり技術力とは、無限の範囲があるから無意味。
自分ができる、限られた範囲で答えるしかない

**デフォルトの名無しさん** · 2021/04/18(日) 11:23:18.59

おいおい、お前がRuby見捨ててどうする

**デフォルトの名無しさん** · 2021/04/18(日) 15:13:24.79

イメージボタンの表示についてだけど、例えばスピーカーに斜線の図柄とかみたいな奴なんかがすんごく困る
現在がミュートという状態を示しているのか？
それとも、ボタンを押すとミュートするという機能を示しているのか？
UXの取り決めとしてコイツはこう、と決めてる規約はあっても、それはその団体が強権的に決めつけてる話
そんな規約なんて知らんという、団体ごとに変わってくる

状態と機能、どちらを示している方が多いと思う？

**デフォルトの名無しさん** · 2021/04/18(日) 15:31:36.04

状態を表すほうが多いと思う
でもアイコンの変化だけで状態を表すのはオシャレ感重視の悪いUIが多いんじゃないか
デフォルトでまず斜線のないスピーカーが表示されている場合、そのボタンがミュート機能を表すということが伝わりにくい
（ただ、ミュートの例に限ってはこのスタイルが一般的に認知されてるので例外ではある）
トグルスイッチであればトグルスイッチのUI部品を使うべきとするデザインガイドラインが優れていると思う

**デフォルトの名無しさん** · 2021/04/18(日) 15:57:13.64

電灯のスイッチがonとoffで赤と緑が切り替わるんだけど、
どっちの色がどっちを示しているか毎回判らなくなる

**デフォルトの名無しさん** · 2021/04/18(日) 21:50:22.92

javascriptで簡単なパズルゲームを作りたいと思っています
ゲーム内容の描画にはcanvasを使うつもりです

ここまでは決まっているのですが、最近Reactを公式のチュートリアルで少し勉強したのでせっかくなのでそれも取り入れたいと思いました

そこで気になったのですが状態の変更によって色々なコンポーネントを再描画するReactで単一のコンポーネントであるcanvasを管理するのって相性としてどうなのでしょうか

調べてみてもReactとcanvasを使ってゲームを作ってる人がいなかったのであまりいいやり方ではないのでしょうか

**デフォルトの名無しさん** · 2021/04/18(日) 22:20:29.05

どうなんだろ？
Reactは投げたクチなんで深いところは理解してないけど、仮想DOMでのコンポーネントの一般化が肝じゃないのか？
それに対してゲームで使うCanvasAPIはグラフィックコンテキストで描くAPIだからDOMとはレイヤーからして違うんじゃない？

**デフォルトの名無しさん** · 2021/04/18(日) 22:56:07.88

ReactでCanvas扱うライブラリあるよ
Konva.jsのReact版はHooks対応

**デフォルトの名無しさん** · 2021/04/18(日) 23:18:37.50

うーん、これ使うならSVG書くかなー

**デフォルトの名無しさん** · 2021/04/19(月) 23:05:22.70

PHPやってて、Laravelというフレームワークを使ってみたら
bladeとかあって便利だと思ったんですが
フロントエンドにVueとか、Reactとか使うメリットって何があるんですか？
表示するだけなら使わなくてもいい？
それとも使ったほうが便利になったりする？

**デフォルトの名無しさん** · 2021/04/19(月) 23:08:25.20

なんでこんなに言語増えるの

**デフォルトの名無しさん** · 2021/04/19(月) 23:14:55.31

メリットはコンポーネントを作りやすいこと
あとはフロントエンドとバックエンドが綺麗に別れてるので理解しやすいこと

**デフォルトの名無しさん** · 2021/04/19(月) 23:18:22.21

>>482
bladeである程度開発して経験してから再度質問してみてね
何も知らないのにVueの方が優れてるので今すぐ採用しましょうとか言っても
分からないかと思うので

**デフォルトの名無しさん** · 2021/04/19(月) 23:57:03.64

>>485
もうLaravelでアプリ完成させたから
次の技術使ってみたいんだよね
bootstrapも使ってみて便利だった

だから、次はVueとか使ってみたいんだけど
何が便利なのか知りたいです

ちなみにJavaScriptとか、ほとんど使ったことないです
フロントエンドにあまり労力を使いたくない
ただ、bladeやbootstrapみたいに楽できるなら使いたいです

**デフォルトの名無しさん** · 2021/04/20(火) 00:01:53.79

めんどくせぇ奴だな
イライラする

**デフォルトの名無しさん** · 2021/04/20(火) 04:38:17.14

Ruby on Rails では、Bootstrap, jQuery, React、
規約だけのフレームワーク・Stimulus

Vue.js はほぼいないので、やらなくてよい

**デフォルトの名無しさん** · 2021/04/20(火) 16:10:44.80

MySQLやJavaには有料版が有りますが、企業は、もし無料版で機能的に
足りる場合で、ライセンス的にも一見問題ないような場合でも
安心感やライセンス的なトラブルを避けるためなどのため
有料版を買いたがるものでしょうか？

**デフォルトの名無しさん** · 2021/04/20(火) 16:19:42.69

>>489
大きく「うん」
主には延長サポート目当て
問題発生時にお金で解決出来る可能性が高いのは大きい

**デフォルトの名無しさん** · 2021/04/20(火) 16:24:13.28

>>490
「サポート」とは、電話やメールでの技術的な問い合わせのことでしょうか。
それとも、不具合があった時に「報告できる明確な窓口がある」程度でも
安心材料になるものでしょうか。

**デフォルトの名無しさん** · 2021/04/20(火) 16:29:55.07

>>491
お前が担当者として全責任を取りますって宣言するか？
してもお前の価値次第だがな

**デフォルトの名無しさん** · 2021/04/20(火) 16:52:52.60

でも大昔は酷い所もあった
明らかなバグでOSが例外吐いて落ちるんだが、そのサポート回答(有料)が、「次のメジャーバージョンでは直っていますので購入してください」
潰れたんだがDEC