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

**デフォルトの名無しさん** · 2022/05/10(火) 14:24:35.29

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

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

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

**デフォルトの名無しさん** · 2022/07/12(火) 15:39:37.31

>>299
まずデータ共有のためにグローバル変数を用いるのは他に手段がない場合に限定されしかも以下の点に注意する必要か出て来ます
データを多者で共有するということは
その多者の関係によってはデータ競合が発生するため一般的には排他制御を行うことになります

**デフォルトの名無しさん** · 2022/07/12(火) 15:55:20.39

>>301
設定ファイル名は固定ならば変数ではなく定数であるからグローバル変数ではない
変わりうる時は引数や環境変数や設定ファイル等が出自となりこれもグローバル変数てはない
ファイルはファイル等のモジュールのオープン関数にファイル名やパスを指定して扱うからグローバル変数の要素はない
ローカルDBも同様でありグローバル変数を必要としない
まともなコードならばグローバル変数は出て来ない

**デフォルトの名無しさん** · 2022/07/12(火) 16:11:36.31

>>299
どの言語を前提に話してるの？

**デフォルトの名無しさん** · 2022/07/12(火) 16:17:16.03

C#やJavaなんかで

**デフォルトの名無しさん** · 2022/07/12(火) 16:40:13.27

>>305
その2つともグローバル変数がそもそも機能的にないやろ
static classのstatic変数使う

C#ならnamespaceを切って、使う側で明示的にインポート

**デフォルトの名無しさん** · 2022/07/12(火) 17:07:57.77

>>289
変数や関数は台帳で管理する
F00001、F00002みたいな名前にしておけば悩む必要はない
なおF00100以下の番号は、前々社長など
会社の偉い人に割り当てられている
その関数は伝説となっており誰も手を付けてはいけないことになっている

**デフォルトの名無しさん** · 2022/07/12(火) 17:28:55.51

アセンブラとか変数どころかアドレスの番地やろ

**デフォルトの名無しさん** · 2022/07/12(火) 18:28:32.11

レジスタ名は変数に含まれますか？

**デフォルトの名無しさん** · 2022/07/12(火) 18:28:36.82

10 GOTO 10

**デフォルトの名無しさん** · 2022/07/12(火) 19:27:13.54

コンストラクタの引数とフィールド変数は毎回困るわ
this着けて回避してるけど未だに嫌だわ
C#はprivateフィールド変数にアンダースコア付けるように成ったらしいから良くなったけどjavaはコンストラクタだけthis付きだわ

**デフォルトの名無しさん** · 2022/07/12(火) 21:28:56.55

>>305
そんなにパフォーマンスにこだわりたいなら、とりあえず C で書いたら？
なんでもグローバルに置くなんてことをしなくても、変数確保のコストをごっそり下げられるよ。

**デフォルトの名無しさん** · 2022/07/12(火) 22:36:21.49

最近はRustのようにグローバル変数を持たない言語も増えているね

**デフォルトの名無しさん** · 2022/07/13(水) 02:51:31.38

「〇〇の言語では」という話は、既存のコードを直す場合には残念ながら無効
新規のコードだって普通は言語縛りがあったりする
事件は現場で起きている

**デフォルトの名無しさん** · 2022/07/13(水) 03:10:40.16

>>307
実際そういうソース見たことあるわ
グローバル変数名がみんなそういう番号なのな
で、関数はほとんど関数ポインタの配列に入ってて、添字頼りで呼び出す、、、
しかもコメントはほぼ皆無、あったとしても「なぜかこうしないと動かない」的な独り言

きっと天才が作ったんだろう、俺には解析できなかったよ

**デフォルトの名無しさん** · 2022/07/13(水) 21:10:40.45

OSがLinux・unixでは昔makeを使ってたと思います
今は何が主流なんですか？

**デフォルトの名無しさん** · 2022/07/13(水) 21:14:50.95

make

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/13(水) 21:29:01.08

cmake

**デフォルトの名無しさん** · 2022/07/14(木) 00:38:53.58

Makefileなんか使わない
ソースコードはCファイル一つでできている

**デフォルトの名無しさん** · 2022/07/14(木) 00:54:33.55

>>316
最近はCとほぼ同速度が出るのに自動メモリ解放で安全に楽できるRustで書くことが増えたから
makeに相当するのはcargoかな
ライブラリのバージョン管理や自動ダウンロードなど含めて何でもしてくれる

**デフォルトの名無しさん** · 2022/07/14(木) 02:45:06.09

ポケモンの交換は途中で電源を消してもポケモンの増殖や消滅が起こりませんが、どのようになってるのでしょうか

**デフォルトの名無しさん** · 2022/07/14(木) 03:58:54.48

起こるようだが？
ちゃんとトランザクション処理してないのか？

**デフォルトの名無しさん** · 2022/07/14(木) 05:44:56.23

>>320
意味わかんねー
それは本当に「主流」か？？？
cargoでパッケージをインストールするのがデフォルトなディストリなんてあるか？
テメーが覚えたてのこと言いたいだけなんじゃないかと

あとソフトウェア開発の現場では「自動メモリ解放で安全に楽できる」新言語よりもただ単に枯れてるからというだけの理由でC/C++が優先されることが非常に多いということを理解してないように思う

もっと言うとメモリの管理で苦労したくないという浅い浅い動機ならC++でできる限りSTLでプログラミングした方が圧倒的に導入のコストが低く済むという事実
ま、「いや組み込みを想定するとSTLなんて使えないから～」とか訳の分からん擁護に走る奴が出てくるのは目に見えてるがな

**デフォルトの名無しさん** · 2022/07/14(木) 06:25:21.21

>>323
例えばLinux開発陣営も
失敗言語C++を採用しませんでしたが
成功言語Rustは採用したように
言語としての優劣は明確となっています

今までの蓄積の差がC++の優位点です
今後は時間とともにC++が相対的に衰退していくのでしょう

**デフォルトの名無しさん** · 2022/07/14(木) 06:27:36.20

>>314
そのような合理性に乏しい判断が生産性の低下と各リスクの上昇を招く

>>323
ttps://foundation.rust-lang.org/members/
気をつければ問題などと言う認識は時代遅れっすよ

**デフォルトの名無しさん** · 2022/07/14(木) 08:16:34.89

>>323
> cargoでパッケージをインストールするのがデフォルトなディストリなんてあるか？
なんでデフォルトじゃなきゃいかんの？

**デフォルトの名無しさん** · 2022/07/14(木) 12:11:36.28

Ruby では、Rake, Thor みたいなタスクランナーを使う

**デフォルトの名無しさん** · 2022/07/14(木) 12:46:07.15

>>325
「メモリ管理に苦労したくないだけならSTLを積極的に使うことにすれば済む」というのを「気をつければ問題ない」と読んだなら文盲かSTLが何か知らないということになる
組み込み等のSTLが使えないような背景を勝手に想定してるなら話にならない

「メモリ管理に苦労したくない」以外にも山程Rustに良いところがあるのは当然認めている

>>326
論点のすり替えであって、「Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流か」という問いに何ら答えていない
（もちろんこれはただの反語表現であって、答えるまでもなく>>320は頓珍漢なのだが）

**デフォルトの名無しさん** · 2022/07/14(木) 14:00:51.16

>>323
C++がクソ言語だと理解できていない時点であかんやん
メモリ解放の話に限定したとしてもC++ではプログラマーのミスで解放忘れ、多重解放、解放済みエリア利用などのコードとなってしまってもC++コンパイラはそれらを通してしまう
複雑化すれば人間のミスが入り込むことは避けられないため現実にバグやセキュリティの穴をC++は生んできた
現在はそれらのミスを起こしたコードをコンパイラが検出して通さず指摘してくれるRustが登場したのだからC++は着実に退場していくだろう

**デフォルトの名無しさん** · 2022/07/14(木) 14:39:49.64

退場するまでなんとしても生きねば…… ゴホゴホ……

**デフォルトの名無しさん** · 2022/07/14(木) 14:50:50.28

>>329
自己流あるいはアンチパターンにはまってわけわかんないことしてるくらいなら (問題によっては) STLを使えば良いだろっていう指摘なんだが、
> メモリ解放の話に限定したとしてもC++ではプログラマーのミスで解放忘れ、多重解放、解放済みエリア利用など
なんでこんなことになるのか

**デフォルトの名無しさん** · 2022/07/14(木) 15:45:39.13

>>328
> 論点のすり替えであって、「Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流か」という問いに何ら答えていない

Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流かどうかを聞いてなんの意味があるの？
どうせ主流ではないと言いたいんでしょ？

主流ではないから○○だみたいに、
その先を説明してよ

なんで自分の意見を相手に聞くかな？ｗ
自分の意見は、自分から言えば良いんだよ。

**デフォルトの名無しさん** · 2022/07/14(木) 15:47:01.75

相手に自分の主張を言わせることで
「勝った気になる」というテクニックに名前ついてない？

**デフォルトの名無しさん** · 2022/07/14(木) 16:35:58.76

>>331
なぜそれら致命的な欠陥のあるC++を勧めるのか？
他に解決手段が無かった昔はC++が次善手として使われてきたのは仕方ないとしても現在は避けることが可能なのだから

**デフォルトの名無しさん** · 2022/07/14(木) 19:50:08.27

ふう、なんとか致命傷で助かった

**デフォルトの名無しさん** · 2022/07/14(木) 21:11:03.19

お前はすでに死んでいる

**デフォルトの名無しさん** · 2022/07/14(木) 22:27:22.85

>>320
＞ライブラリのバージョン管理や自動ダウンロード

これ、すごく嫌なんですが、オプションでオフにすることはできますか？

**デフォルトの名無しさん** · 2022/07/14(木) 22:28:41.63

>>329
＞解放忘れ、多重解放
これはデバッグ用にラッパをかませれば、すぐにわかりますよ
工夫がたりないんじゃないですか？

**デフォルトの名無しさん** · 2022/07/14(木) 22:38:35.64

>>388
工夫とはPOSIXコマンドだけで何とかすること
依存しているものが使えなくなったら動かなくなる

**デフォルトの名無しさん** · 2022/07/14(木) 23:58:11.93

>>339
あのね、ラッパは自分で書くの
malloc(), free() をラッパでくるんでおいて、解放忘れや二重解放を検出すればいいわｋでしょう？

＞解放済みエリア利用
すなわち、前世バグは、解放時にラッパで乱数を書き込んでおけばいい
本番ではラッパをはずすように #ifdef しておけばいいだけの話でしょう

なんでこんな工夫もできないの？馬鹿なの？

**デフォルトの名無しさん** · 2022/07/15(金) 01:34:39.13

>>340
そんな前近代的なことをしている人がいて驚く
・まず手間も時間もムダ
・その作業も漏れなくミスなくすることを保証できない
・実行しないと何も判明しない
・レアケースに露見するミスはレアケースが来るまでわからないまま
様々な点で問題が多すぎる

C/C++を捨ててRustへ移行すれば
・コードに問題があればコンパイラが通さず問題点を指摘してくれる
・つまりチェックは人手でやる必要なくコンパイラにより完全自動
・コンパイルが通れば安全性が保証される
・つまり実行前に静的に問題がないことを確定できる
・使われなくなった時点で即座に自動的にメモリ解放されるためC/C++で手動で最善にメモリ解放した時と同様に高速
このようにRustへ移行すれば問題が解決する

**デフォルトの名無しさん** · 2022/07/15(金) 01:41:41.27

>>340
解放忘れは機械的にはプロセス終了時点まで分からないと思うけど、プロセス終了時にその領域の情報はどうやって報告するの？
未解放メモリの全部のポインタをどこかに覚えておく？
そして、どこからの malloc で確保されたメモリなのかはどうやって管理する？
他にも new や delete はどうするのとか。
そのノウハウは聞いておきたい。

**デフォルトの名無しさん** · 2022/07/15(金) 04:34:16.20

>>332
> どうせ主流ではないと言いたいんでしょ？
イエス
反語表現の意味を調べよう
（中高で習うそんなに難しくはない概念だし、注意してみると日常生活の中でもよく使われているので、勉強しておくことを勧める）

> 主流ではないから○○だみたいに、
> その先を説明してよ
ホワァイ？
元々>>320が頓珍漢な回答をしているのを指摘しただけなので、そこで終わってる話
頓珍漢に輪をかけたレスがその後も相次いでいるので驚いているが

> なんで自分の意見を相手に聞くかな？ｗ
> 自分の意見は、自分から言えば良いんだよ。
言ってるんだよなあ
まあこの先日本語をもっと勉強することでいずれ理解できるようになると思う
頑張って

**デフォルトの名無しさん** · 2022/07/15(金) 04:37:28.40

>>334
勧めていません
ただし、低レベルプログラミングが必要な場面でないのに「C++はメモリの解放が～」とか言ってるのは誤謬でしかないし、標準ライブラリで提供されてる範囲内で簡単に解決できると示しているだけ

**デフォルトの名無しさん** · 2022/07/15(金) 04:40:39.28

>>340はヤバいね
これなら思考停止でRust使ってた方が良い

今自分でmalloc、free、new、deleteしなきゃいけない場面なんて特定の領域を除いて存在しないでしょっていう話だから

**デフォルトの名無しさん** · 2022/07/15(金) 04:43:52.51

>>343
その件もmakeでやってた前近代的な方法を根本的に見直し捨て去ることで
全く新たなcargoというエコシステムが作られてそれ単独でmakeやその類似を必要とせずに動作しているわけだから
makeの代わりの新たなものという位置付けも一つの見方であると思われる

**デフォルトの名無しさん** · 2022/07/15(金) 04:44:34.45

>>343
だから、Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流じゃないから何？
OSの仕事はあくまでOSのパッケージの管理であって
プログラミング環境のライブラリの管理じゃないんだよ
あんたcargoの役目を理解してなさすぎｗ

**デフォルトの名無しさん** · 2022/07/15(金) 05:21:48.13

>>344
その後半の「標準ライブラリで提供されてる範囲内で簡単に解決できる」は二重にダウト
標準ライブラリの範囲内でも解放忘れや多重解放などは起こり得る
さらに標準ライブラリの範囲内のみで解決できるとはかきらない
したがって標準ライブラリを持ち出すことに何の意味もない

**デフォルトの名無しさん** · 2022/07/15(金) 05:25:05.82

>>346
ていう話なら是

>>347
ええ。ですから>>316に対してcargoとか言い出すのは頓珍漢なのですよ
私と反対のことを言いたいばかりに元々がどんな話だったかすっかりお忘れになられているようで、本当に気の毒ですがもう少し日本語のお勉強に真剣になられた方が良いです

**デフォルトの名無しさん** · 2022/07/15(金) 05:39:30.79

>>349
はぁ（苦笑）

あのねぇ、makeはね、OSのコマンドなの。UNIXの中に含まれてるから。
でね、makeっていうのはビルドツールなわけ。
昔のunixにはパッケージ管理ツールなんてなかったのから
ビルドするしかなかったの

今はビルドツールにOSのコマンドを使わなくなってきてるの
cargoはプログラム専用のパッケージ管理ツール兼ビルドツールなわけ

つまりね、
・パッケージを使う場合はOSのパッケージ管理ツールを使う
・しかしパッケージ管理ツールは、make、ビルドツールのことじゃあない
・今の話はmakeの代わりに何を使うって話
・makeの代わりはcargoや各言語のビルドツールなわけ
おまえはmakeをパッケージ管理ツールだと勘違いしてる

ここまで丁寧に教えないと理解しないんだろうな

**デフォルトの名無しさん** · 2022/07/15(金) 05:44:04.50

makeの代わりに何を使う？って話なんだからcargoは間違いじゃない

makeの話なのにOSのパッケージ管理ツールってなんだよ？とかいいだしてる>>323がアホと言う結論

**デフォルトの名無しさん** · 2022/07/15(金) 06:06:48.38

>>350
>>346で止めときゃ合ってたのに……（もしかして「是」の意味がわからなかった？）

OSのコマンドとして見るなら尚更cargoを持ち出すのは頓珍漢だろ

**デフォルトの名無しさん** · 2022/07/15(金) 07:03:07.90

とりあえず>>340って実際にどんなことをしてるかちょっとだけ気になるんだけど
よかったら具体的な説明を

**デフォルトの名無しさん** · 2022/07/15(金) 07:08:23.44

と思ったが、あれかな、valgrindとかでやることを自分でやるみたいな?
普通にそういうツールやライブラリに頼った方がいいような

**デフォルトの名無しさん** · 2022/07/15(金) 07:28:20.56

>>352
今どきはOSのコマンドでビルドしないって言ってんだろ
いい加減OSの話忘れろよ
おまえだけだぞ

**デフォルトの名無しさん** · 2022/07/15(金) 08:15:46.31

Rust Foundation Platinumに日本企業はない。中国企業はいる
日本は中国未満

**デフォルトの名無しさん** · 2022/07/15(金) 09:59:34.96

現時点でRustで構築されてるOSってある?
カーネルはLinuxでもいいけどそれより上の部分で

**デフォルトの名無しさん** · 2022/07/15(金) 10:57:19.78

Rustなんて結局流行らんでしょｗ
まぁ、スレ違いなのでしょーも無い事を語るなら別のスレにいけ

**デフォルトの名無しさん** · 2022/07/15(金) 11:39:33.98

gitでマージしてコンフリクトしなかったファイルとコンフリクトしたファイルがあって
これをコミットする際、コンフリクトせずマージされたコミットとコンフリクト解消したコミットのように2つに分けたいのですが
どうやればいいのでしょうか

**デフォルトの名無しさん** · 2022/07/15(金) 12:11:03.83

単純にマージする前にブランチ切っていれば戻れるし好きに出来るのでは？

**デフォルトの名無しさん** · 2022/07/15(金) 12:12:45.10

>>359
stageに上がった修正だけがcommitされるから、
コンフリクト解消前のstageをcommitした後に
コンフリクト解消してまたcommitすりゃいい

**デフォルトの名無しさん** · 2022/07/15(金) 12:44:10.41

>>361
コンフリ解消前のをcommitするとコンフリ解決してないので
committing is not possible because you have unmerged files
とエラーが出てコミットできないんですが
コンフリしたファイルをそのままaddしてコミットしろってことでしょうか？

**デフォルトの名無しさん** · 2022/07/15(金) 15:05:45.09

>>362
merge状態から抜ければcommitできるので、そうしてもいいし
コンフリクトしたファイルだけを元に戻してもいい

でも、どちらにせよビルドできない状態をcommitすることになるだろうから
ちゃんとコンフリクトを解消してからcommitした方がいいと思うけどなぁ
まあ、最初のやりたいことからは外れちゃうけど

**デフォルトの名無しさん** · 2022/07/15(金) 15:18:15.30

>>357
これからは一つの言語で構成されるOSはなくなっていく

**デフォルトの名無しさん** · 2022/07/15(金) 21:04:15.70

>>341
＞・まず手間も時間もムダ
ちょいちょいと 200 ステップくらいで簡単に実現できますよ、一晩で書けちゃいますよ

＞・その作業も漏れなくミスなくすることを保証できない
＞・実行しないと何も判明しない
何もしないよりはましでしょうね、簡単なラッパを置くだけでケアレスミスは弾けますね、やったことなければわからないでしょうが

>>342
末尾に解放忘れを列挙する関数を置けばいいだけですよ、リリース時には #ifdef で無効にするようなものでね

>>345
私は別に rust を否定しているわけではないですよ
指摘された問題点はちょいちょいとラッパを書くだけで割と簡単に弾けるのに、というだけですね

>>353
ヘッダ：https://ideone.com/E6J83P
本体：https://ideone.com/WpsIxp
一晩で即席に作ったけれども結構今でも役に立っていますね‥‥

**デフォルトの名無しさん** · 2022/07/15(金) 21:41:31.38

リーク検出なんてVCは標準であるけど、他の環境にはないの？

**デフォルトの名無しさん** · 2022/07/15(金) 21:52:23.36

>>363
コンフリしたファイルをHEADの内容で更新commitして
コンフリしたファイルを再度修正してそれをコンフリ解決としてコミットすれば
やりたいような感じのことができました
レスありがとうございました

**365** · 2022/07/16(土) 06:41:19.01

>>366
昔の bcc にもありました、ちょっとバグってたけれども
clang　ベースの今の bcc にあるかどうかはちょっとわかりませんね

**デフォルトの名無しさん** · 2022/07/16(土) 11:51:34.05

質問と言うかご意見をお聞かせください

daoパターンを調べていてトップに出てきたのがこれです
https://kanda-it-school-kensyu.com/java-jdbc-contents/jj_ch04/jj_0401/
気になったのは
selectIsbnAll、selectTitleAll、selectPriceAllが、内部で使うSQL文以外は全く共通の構造になっているということです
例えば受け取ったSQLを実行して結果を返す関数xxxを別に作る、上の3関数ではSQL文を作ってxxxに渡して呼び出す
そういう構造にするのはダメなんでしょうか

それとも重複させたほうがいい理由が何かあるのでしょうか。よろしくお願いします

**デフォルトの名無しさん** · 2022/07/16(土) 11:55:03.81

失礼しました。SQL文以外にも取得する列名も関数ごとに別ですね
まぁその場合でもxxxに列名を引数として追加すればいいのではと思いますが

**デフォルトの名無しさん** · 2022/07/16(土) 12:32:31.14

>>369
>そういう構造にするのはダメなんでしょうか

全く問題ないよ

**デフォルトの名無しさん** · 2022/07/16(土) 12:37:49.48

しいて言えば
他の開発者が重複させた状態でパターン認識してれば共通処理に切り出すと分かりにくくなるとか
すべてのDAOが依存する共通クラスができるのでその維持管理に少し手間がかかるとか
そういうデメリットはあるかもしれない

**デフォルトの名無しさん** · 2022/07/16(土) 14:05:36.11

Java のJDBC って、何十年前の話なの？

Ruby on Rails では、Active Record というO/R マッパーで全自動。
こんなコーディングを見た事がない

**デフォルトの名無しさん** · 2022/07/16(土) 15:47:30.46

markdownってなにが便利なの？
見る人にわざわざViewerをインストールしてもらわなきゃいけないの

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/16(土) 16:12:32.42

>>374
HTMLよりも文法が簡単で、わかりやすい。
テキストベースでGitと相性が良い。
markdownが書ければ本も出版できる。

**デフォルトの名無しさん** · 2022/07/16(土) 17:00:15.16

本を出版できるかどうかは関係ないでしょ
書く内容があれば、markdownがかけなくても出版は出来るでしょうし。

整形されたものを見るためには、ブラウザ側の準備とかも必要ですし
○○をインストールすれば、綺麗に見えますよ
なんていってもそんなの面倒といわれるのがオチですよね

**デフォルトの名無しさん** · 2022/07/16(土) 17:08:33.25

ブラウザ等が必要なのはHTMLやTextileも同じ
それらに比べてプレーンテキストでの視認性は良い

**デフォルトの名無しさん** · 2022/07/16(土) 20:25:35.05

gitと相性良いってのは本当にでかい
未だにword/excelをSVN管理してるところの多さよ

**デフォルトの名無しさん** · 2022/07/17(日) 08:58:42.91

音楽を流すプログラムを公開する時、著作権の問題を回避するため、曲データそのものは省いた状態で公開したい。
でもデモというかサンプルとして、そのデータのシーケンスの様子を youtube で公開して、ようするにそれを見ればデータを再現できるわけだけど、
そういう公開の仕方で著作権の問題は出そう？
公開したいものの主体としてはシーケンサの方ではあるけど、その曲を入れたくて作ったという側面がある。
もちろん使う人がお好きなデータを入れられる。

**デフォルトの名無しさん** · 2022/07/17(日) 18:48:28.79

仕事中に転職予定のプログラミングの勉強をしたいのだけど
いい方法はないかしら？
今の仕事中はときどきアイドル時間があってわりと勉強できそうだけど
周りにチームリーダーやまじめ君がいてPCをのぞきこまれてそれを見つかるのはまずい。

**デフォルトの名無しさん** · 2022/07/17(日) 19:38:41.12

スマホPDFでみれば

**デフォルトの名無しさん** · 2022/07/17(日) 19:51:05.43

>>381
それもなかなか難しいんですよ。
理想はPCで仕事してるふりしてPCの小領域に勉強のためのWebサイトを開くみたいな。

**デフォルトの名無しさん** · 2022/07/17(日) 19:53:22.97

PC介すと検閲に引っかかるとかないの？

**デフォルトの名無しさん** · 2022/07/17(日) 20:52:28.23

えー要約すると仕事中に仕事と全く関係なくて見つかるのもまずいことしようとしてるんだけどいい方法ありませんか

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:13:42.26

通信URLが監視されてたら何してもばれる。

それでもやりたいならWin+D

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:21:33.73

「ボスが来た」で検索すると、そういうツールが見つかるよ。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:22:16.77

通信内容も隠蔽したいならテザリングするといいよ。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:26:39.21

内部通告は社会の正義だからね。がんばってね。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:41:58.23

今ならメガネ型の端末やコンタクトレンズみたいな端末があるって。
それでネットサーフィンできるよ。

**デフォルトの名無しさん** · 2022/07/17(日) 22:12:12.21

などと自宅警備員が言っており

**デフォルトの名無しさん** · 2022/07/18(月) 02:41:01.00

その言語の研修に行かせてもらえば？

**デフォルトの名無しさん** · 2022/07/18(月) 09:09:17.65

UMLとかどこ行っても潰しの効く技術を勉強しといたら？
特に最下流なゴミ案件だと設計ドキュメント無かったりするから、それを作ってますと言い訳

**デフォルトの名無しさん** · 2022/07/18(月) 10:38:54.88

OSSのライブラリって設計ドキュメントとかなかったりするよね
OSSの開発には参加できない低レベル人材ということだよね

**デフォルトの名無しさん** · 2022/07/18(月) 12:40:49.12

設計資料の無いプログラムなんて、何の価値も無いでしょ
個人が趣味やってるようなものなら話しは別だけど
会社で仕事としてやってるなら、ソースだけなんてありえない。

そこらに建ってるビルで設計図ないビルなんて無いだろ
犬小屋つくるのとはわけがちがう

**デフォルトの名無しさん** · 2022/07/18(月) 12:47:50.22

設計図は保守のために必要なのであって開発のための設計図は不要

**デフォルトの名無しさん** · 2022/07/18(月) 12:49:37.70

会社に入れば分かるよ
学生さんがお遊びで書いてるようなおもちゃコードとはダンチレベチだから

**デフォルトの名無しさん** · 2022/07/18(月) 13:25:28.89

OSSはわかる人が参加するものであって
企業内の製品は誰でもわかるようにしなければいけない
設計あるなしは要否によっても決まるもの、という位置付けに変化した

**デフォルトの名無しさん** · 2022/07/18(月) 13:28:37.05

会社でコード書いてるのなんて高卒とか専卒のやつらだろ
大学でちゃんとコード書いてる学生さんの方が上だよ

**デフォルトの名無しさん** · 2022/07/18(月) 13:34:29.85

なぜか学歴の話しになってて草草草
頭の悪い人って物事を別の方向に捉えて勝手に結論付けるよね

**デフォルトの名無しさん** · 2022/07/18(月) 14:19:10.39

N□□セキュアとかの仕事ですら、設計ドキュメント無かったぜ

**デフォルトの名無しさん** · 2022/07/18(月) 14:39:42.97

ビルは完全にウォーターフォールでしか開発できないからな
途中で改善点など見つけても後戻りできない
そこがソフトウェア開発と建築との違いで何度でも試行錯誤してブラッシュアップできるのがソフトウェアの良いところなのに
混同して考えているという時点でセンスないし向いてないから別の業界に転職した方が良いよ