【IT】Webフロントエンド「文系でもできます。ググれば答え載ってます」これエンジニアか? [439616905]
■ このスレッドは過去ログ倉庫に格納されています
Webが日常に溶け込んだ新時代で、Webフロントエンドのキャリアの未来を考えてみる 技術・デザイン 2023年2月22日 https://www.cyberagent.co.jp/way/list/detail/id=28537 学部卒文系でも出来るような仕事をエンジニア扱いしたら本物のエンジニアが可哀想だろ 新しく生み出せるごく一部の天才以外はいかにうまくコピペするかの世界だからセーフや 「この職種は逃げ場」なんて考えてる奴は、わりと早く不要とされる >>20 ITってのは高卒やF欄文系卒でも背広来てオフィスワークが出来る仕事だからな うちは会社が小さいからwebデザイナーがデザインもフロントエンドもやってる フロントエンドオンリーだとちょっとスキルとして弱い気がする 俺は理系の院でてないとできない仕事だけを尊敬するわ フリーランスに外注しやすいところだよね 創意工夫が必要なくて言われたとおりに作るだけの仕事 正しい事も間違ってる事も古い物も新しい物も全部ごちゃ混ぜだから そん中から必要な情報だけピックして整理できるんなら確かにエンジニアリングできるかもな? ググってひとりで環境構築からやってくれるなら 立派なエンジニアだと思うよマジで 給料泥棒してるのにできないやつばっかだからな ReactかVeuで5ちゃんモドキのサイトが作れるスキルあれば月50は余裕でもらえるからな 今めちゃくちゃ需要高い それを言い出したら プログラマ なんてほとんどがそうだろ 何らかの 「素晴らしい機能」 を実装するなら別だけど、ほとんどは 用意された機能を呼び出すだけなんだし でも、web系って女の子多いでしょ? 俺、氷河期の制御系だけど 周りは歳上のおじいちゃんばっかりだそ😫 >>34 できるけどめちゃくちゃお祈りされてるわ今 ネットでググって自己解決できりゃ充分じゃね?引っかかってるとこの何が課題や問題か 自分でちゃんと理解しててさわりだけでも推測まで出来ないとそもそも答えまでいけないし VueとLaravel使えると仕事困らんぞ 謎に単価高い 8割ぐらいはそのググって解決するところすらできないのが現状やけどね 流石に大手プロパーは一人でこなせるけど派遣雇ったり外注すると中のソース滅茶苦茶よ 安かろう悪かろうで一から十まで指示しないと出来ないのと何でも一人でこなせるマンの差が酷いのがIT業界😫 文系を教育して理系に派遣するとお金が貰えるんですよ アジャコングとか言うのを理解してないと駄目なんだろ? reactとvueってどっちを先に使えるようになったらええんや 文系だろうが理系だろうが 覚えなきゃ仕事にならんし あんま関係ないんじゃね DBにGIT、UNIX、クラウド、サーバーサイドにフロント、設計に業務、 顧客折衝にマネージメント とまーちゃんと覚えて1人前になるには5年くらいかかるでしょ 優秀なヤツでも web系て簡単なのに給料高い 組み込みはスキルが必要なのに給料が安い web系ってトレンドの移り変わり凄まじそうだけどどうなの 日本のITなんか上流でも文系でできるし理系でも技術力がないやつがほとんどやろ >>51 SESばっかだしギスギスだろう 上流もギリ健SES相手に辟易してる >>48 デザイナーいるならfigmaかAdobeXD使ってサイトイメージ作ってもらうのが1番速い ベースになるCSS吐いてくれるしレスポンシブ対応も楽だし 自分だけで組む時も雑にパーツ並べて吐かれるCSS見れば理解もできてくよ ぶっちゃけ調べて実装がちゃんと出来るなら普通に評価されるよ 依頼されたら何でも作るで ワンクリ詐欺のシステムも卸したことある >>47 大手プロパーは一人で全部こなせるのかすごいな 参入のハードルが低いからか悪い意味で激ヤバエンジニアを多く見かける印象ある マジで手の施しようがないレベルも見かける >>48 顧客がその辺の知識あってツール活用してくれるなら良いんだけどね マイナンバーじゃないけど官公庁案件やお硬い大企業系だと未だにエクセルペタペタだったりするから地獄よ 学校で勉強する期間より仕事してる期間のほうが遥かに長いのに 理系職の人間をいつまで文系扱いするんだ 自称理系のアホニートどもは 俺もPythonで業務の自動化とかそういうプログラミングはよくやるけど どうもWeb系は手出す気になれなくて食わず嫌い感あるわ 調べれば出来るのかもしれないけど、新しい物好きの若者がやるべき仕事かなあと思ってる 派遣でやってたが臨機応変に環境構築出来るやつばかりだったな あれはエンジニアだったわ >>77 フレームワークとライブラリが充実してるから余裕だぞ ネットで資料も多いし 無駄が多い上に バカみてえにフレームワーク乱立してるよな Web Componentだけでなんとかなるレベルだろ だいたいジャップサイトのアクセス数でSPAとかコンポーネント単位のレンダリングとかいらねえだろ CDNとかのインフラ側やっときゃそれでいいよ スマホユーザーも基本的にツイッターとかインスタしかやんねえから、ジャップサイトの技術ひつようねえよw バックエンドとインフラだけでいいのに、無駄なことしまくってる とは言え、これからはWeb Assemblyでフロント側に複雑なコードや環境が用意されるから 雰囲気でやってる奴らは振り落とされてくだろう >>72 まともな教育受けてないし大学で高等数学やアルゴリズムやコンピュータの仕組みも学んでないしそもそも土台ができてないのにネットで初心者文系でもなれる!3ヶ月で稼げる!副業で始めましょうとかアフィブログばかり みんな似たようなゴミ記事や教材使ってど下手くそ自称フロントエンドフリーランスが量産されている低レベルジャップランドだな 日本語のネット上の記事ってなんか似たようなデザインセンスもないアフィブログやテンプレート記事ばかり、広告ばかりでみんなアフィに誘導しようと必死だしまともなサイトがない そりゃIT進歩しねえよ はぁ? vueのドキュメントの少なさ舐めてんな 少な過ぎてchatGPTが正解出せないんだぞ >>79 フレームワークもお作法覚えるのが大変やからね そもそも理系と文系ってそんなに違いがあるか? ITは理系ってただの思い込みの様な気がするけど メジャーなITツールの誰もが躓くところはググればブログで分かるけど あるレベルになるとメーカーの難読公式ドキュメントと英語のQAサイトを読み込む壁が出てくるよね 逆に本を買っても一般的なことしか書いてなくてw 文系でも何でもいいけどデザインセンスあるかユーザビリティ考えられるやつにやらせろ ゴミカス多すぎ 今のJavaScriptってfor文使わなくてもループ処理出来るのになんでもforとか forEachでやろうとするバカ多すぎだろ うちの職場がレベル低いだけかw 数的に開発者のが多いから当然だけど嫌儲のITスレだと上流の話はあんま出んよな 上流に携わるような人は嫌儲なんて覗いたりしないか >>84 ITは理系の技術だよ IT利用は理系も文系もないかもしれないけど >>56 VUEはSLOT回りの処理がスマートじゃないから、REACTのほうが良いと思う 今のフロントエンドは相当難しいでしょw サーバーレスでnext.jsとかpuppeteerでE2Eテストとか 要求される周辺知識がかなり広い jsも非同期になってるからバカには理解できない >>72 勉強が必要な職業なのに勉強しない・自分で調べないバカ多すぎ 逆に言うと勉強して自分で調べるだけで無双できるw >>88 技術について語る方が楽しいし話題に縛りが無いからね 上流だと顧客とか業務とかに直結するから書き込みにくい >>87 意外とベテランと言うか古くからエンジニアやってるオッサン開発者のがfor文使う傾向にある気がする for文に慣れきっちゃってるせいなのかな >>91 全部文系でも余裕やん 大学レベルの数学とか全くいらんし 人手不足すぎる ほんと頼むから無職はフロントエンドエンジニアで働いてくれ >>94 マジでこれ 内製の話がどうしても増えておちおち喋れん webよりスマホアプリの方が需要あるんじゃねーの? ニートで久しぶりにプログラムしてるけど レンダリング方法が多様化して複雑になってるじゃん Nuxtでハイブリッドレンダリングとかやってみてるけど これから生き残るのは何? 部品組み立て作業員に文系とか理系とか関係あるんやろか?🤔 >>87 for使わないってmapとかsomeとか? 言うて大学で専門としてやるレベルの情報工学や数学の知識がいるのなんて一握りのエンジニアじゃないの 別に日本に限らず世界的に見ても >>99 今は完全にプラットフォーム依存がないWebの流れでしょ スマホでスタンドアローン想定してるアプリなんてまあないし >>82 指定しないと2系のコード出してくるからな マジでうんちw >>100 何が残るかはわからないから 変化に即対応できる瞬発力が必要 >>42 これ ガチ無能は本当にググれない。ググれば答え出るよ、と教えても「ググっても答えありません」とか平気で言う 枯れた言語のよくあるミスでそんな訳ないだろ vueは当初は学習ハードルの低さが魅力だった気がするけど 3系になってその魅力が薄れてる気がするのは自分だけだろうか あれならReactで良いんじゃって気がする >>102 配列の中身を変更したいときはmap 配列を減らしたいときはfilterとか専用のメソッドがあるからそれを使う foreachは何も返さないから変数に再代入するみたいな特殊なケースでしか使わない 変数もconstで宣言するのが主流だから再代入自体やらないのが基本 ここら辺理解してないとクソコードが爆誕するw Next isも見たけどフォルダ構造とか色々変化してる最中だったからやめた 二年後ぐらいに見たらまた変化してそう >>108 分かる Vue2でReactと差別化できてたと思うんだけどな vueは2系と3系両方やらないといけないからreactと比較して学習コスト2倍w >>103 俺もそう思うけど 理系的な知識が求められるというよりは、理系的な論理的思考能力が求められるんだろうね >>103 AI機械学習関連 ブームはまだまだ終わらんから今後も需要増えるかな それでもせいぜい微積統計線形代数 angular go gcp でいい気がすんだよね googleマンセー ウェブ上の議論が活発だし仕様が探しやすいしCHATgpt が答えやすいこと多そう クラウドサービスの細かい設定とかあんまり良く教えてくれない 肩書に誇りやこだわりを持ってるかは人それぞれだがお金もらってるなら立派な仕事だ >>109 for使わないでどうするんだろと思ってたらそんな話かよ それ実装の中身ではfor使われてるだろ >>121 jsでいいんじゃねTypeScriptだとソースがカオスになるし 会社にITの部署出来たけど、 システムや保守は基本外注委託で、部署の人は手続きの通し方とか 社内の説明資料の文言の言い回しとか そんなんばっかりだな とても理系とは思えん 自然科学も工学もろくに知らないみたいだし >>103 少なくとも日本以外の国は大学の専攻と違う職種にはまず就けない だから大学中退で入り直しや編入も多い 専攻選びミスは致命的だから 専門課程を学ぶための大学だろ 日本みたいに文系でもIT新卒や製薬メーカーの営業とか入社できたり逆に理系や農学でも銀行や全く関係ない文系営業職とか入社や資格さえ取ればやれちゃうメチャクチャな国はない まあ北米ならフロントエンド程度なら学歴なくても短期スクール通って仕事なんとか手に入れて職歴と実績作れるかもしれんが、溢れてるから競争率は高い まともな企業は応募条件に最低限BScのCSの学位を要求してるし >>100 そーゆーのは考えなくていい フロントエンドの本質はデータの受け渡し ・ユーザーが入力したデータを変換してデータベースに投げる ・データベース(API)から送られてきたデータを変換してユーザーの画面に表示 この二つの流れだけ覚えておけばよい 後はどうデータを変換するかが重要w フロントエンドもするしバックエンドも少しやるぞ そもそもフロントエンドってディレクションとかデザインも噛まされるハメになる 小さいとこならな 33歳650万です🥹 >>122 中身をきにしなくていいのよ バニラでforつかうより専用メソッドのがバグすくなくできるし エンジニアはどんな分野もコンピューターの奴隷だよ さらにAIの奴隷になりそうだが next.jsだのnuxt.jsだのややこしすぎるだろ >>127 そもそも他人と話してない いちいち改善点指摘しても時間の無駄だし、そんな時間あったら自分のタスクに集中して仕事を終わらせて帰る 学べることが無くなったらさっさと転職する予定w 嫌儲でフロントとバックの通信でGraphQL触ったbアとある人いる=H あれ慣b黷驍ニ面白いんbオRESTにはない覧ヌさがあるけど涛本だとまだそbネに使われてbネいのかな >>99 スマホアプリは実は需要がすくない でもスマホアプリのエンジニアはめちゃくちゃ少ないから高単価でかつwebより楽 >>133 そもそもJavaScriptって名前がJavaと紛らわしいし >>126 大学は学問や教養を学ぶところであって就職予備校ではない!というのが大学側の主張なので ジャップアタマニンゲン(学名:ジャッパブル=ジャップ・ガイジ)「理数さえできれば一生困らないのにwもののあはれwww」 ↓ 国際言語話せないせいで世界に飛び出せないまま現在進行形で沈む泥舟ニッポン号の船内で船と一緒に心中w >>135 使ったことないんだが何がそんなに良いんだ? >>135 つこてるよ バックエンドに〇〇ページつくるからapiつくってーていう必要ないだけですげー楽 そのかわりバックエンドのスキーマ保守に求められるスキルが高くなる バックエンド側のできる経験者がすくない Flexという爆死のフロント技術が昔あってだな・・・・ >>135 gatsubyって静的サイト作る奴で出てきたわ テンプレいじっただけだからよくわからんかった >>126 言わんとすることは分かるが大学でやるような学問としてのITと現場での開発としてのITはまた毛色が違うような気もするが 海外では実学的なことも結構やるのかな 今のオフィスだとググっても出来ない奴が体感6~7割って感じ こんなんでも業界の中で5本指に入るSIerだから笑える 大学で情報系のことやると低レイヤーがわかるので ツール作ったり、世界的なOSSにコントリビューションしたり もっとちゃんとやるとスクリプト言語の要件策定したりまでいけるけど ほんの一部 日本でそのレベルやってるのだいたい東大卒 >>1 こいつ知恵遅れだから、フロントエンドとバックエンドの統合とか、そのフレームワークの開発の歴史を知らず自分でフレームワークを作った経験もなく ただ「頭がバカでも誰でもできるように工学的にブレイクダウンされた分業仕事の断片」 を取り出しては「こんなのバカでもできる」 という当たり前の話をするだけの落ちこぼれなんだよね なんでこんなレベルの低い人間が 23年間も高等教育機関にしがみついているのか 職場の人たちも大変だと思うよ、マジで おれは情報学部出てないしプログラマーでもないけど最近プログラミング勉強してウェブサービス作り始めた 楽しいけど難しいな 文系がやったらこうなる 1.ググる際のキーワードの選択が怪しい 2.検索結果より情報の取捨選択が行えない 3.検索してもまともな情報が乗ってない事項については未実装 結果できあがるのがゴミになる >>140 やっぱschemaの保守がネックだよねえ フロント側の要求に従って無駄にAPI増やさなくて良いから凄い便利なんだけど 保守含めて全体的な技術ハードルがRESTに比べて高いと言うか できない人は本当に概念を理解できないというか RESTみたいにとりあえずAPIにリクエスト送りゃ良いってのが楽ですってなって中々難しいのよねえ >>148 SIerってハッタリとパワーポイントでいかに客を騙せるかの技術しか養ってないじゃない ITと一切なんの関係もないというねw >>146 北米はみんな3年から長期休みに高額な有給インターンシップでコネ作ったり現場仕事学んだりしてるな それしないと高倍率だから卒業後就職できない 北米は日本以上にコネ社会だし書類や面接だけではどうにもならん ヨーロッパでは長期インターンシップがあらゆる学部のカリキュラムに含まれてるから現場仕事経験しないと卒業できない >>157 同人ゲームならワンチャン 普通のアプリはもう無理だろ >>149 ダウト。お前は学位取得研究未完成だから東大卒ではないし たとえばRuby言語の開発者は2hopsくらいの距離の人だけど 東大卒ではない。 あと日本では東大よりも京大の方がアクティブな活動をしてきた歴史がある。 知ったかぶりの劣等感に塗れた落ちこぼれはデタラメのハッタリばかりで、学生からバカにされて当然だな >>147 バックエンド側を端的にいうとそう ただしそのエンドポイントの処理が複雑化しやすい でもバックエンド側も自分らの領域だけで済む楽さはある >>124 大手の社内SEなんてそんなもんだぞ 基本システムは外注で自社開発の割合減ってきてる その代わり他部署のITレベルの底上げに力入れてて教育したりが多いかな ガッツリ開発やりたい人には向かない >>128 それはそうだけど実際はレンダリング方法によってデータの取得方法変わるしな 外部apiから取得ならSpaならブラウザのみ考えればいいけど サーバーサイドレンダリングもあると理論上二パターン必要になる フレームワークがその差分を吸収してくれるとは言え複雑なパターンも発生し考慮項目が増える データベースの負荷を考えてキャッシュ戦略を入れたりしたレンダリング方法をページ単位やコンポーネント単位で行うからバックエンドの知識と不可分だしクライアントだけってのもうダメなのか? ツール系のサービスだともう一発当てるのは無理なの? >>161 でたよ だいたい が読めないヤツ ウチにもいるよこういう重箱の隅つついて気が強くなるヤツ >>160 同人は個人開発が圧倒的に1位だとアンケートがニュースになってたわ エロゲ作るしかないのか🥺 >>147 GraphQLってざっくり言うとレスポンスとして欲しいデータをリクエスト側が指定できるのよ だからRESTみたいに画面要件に従ってAPIを増やすとかしなくて済む >>165 レッドオーシャンだけどいくらでもあるよ ググって問題解決出来ない奴はchatGPTも使ってないからなw マウスもカチカチクリックしてる マウス使うってことはキーボードのショートカット覚えてないってことだぞw >>81 その気にさせて金だけ取って適性度外視で現場に送り出すの罪深すぎるよね 誰も幸せにならない… >>92 自然にできるくらいじゃないと大変だよね >>169 まあ稼げるのは一握りだと思っておくのが良さそうだね 食ってけるくらいに稼げればいいがそれも夢のまた夢だな 結局、匿名掲示板でこんな幼稚な話題で威勢のいいハッタリを飛ばしているのは頭バカで何もできない奴で 個別の専門スレの奥まったところで専門的な話題を打つと どう考えてもその話題に乗るのは1人しか居ないみたいな所で 稀に有名人が出てくるのが現実。 色々調べたらPrismaが人気みたいだからこれだけ使ってる これにGraphQLを組み合わせる意味はまだ分かってない >>173 それがここのいいところでは? なぜ自分がここにいるのか理解してないのか? >>168 へーそれは便利そうだな 画面の要求に合わせてレスポンスを返すAPIを作るのほんと手間だったからな >>166 具体的なソースも資料もなく、思い込みで東大卒ガーと言い出すのは嫌儲では偏差四十九の職場で23年間職位固定の落ちこぼれと判明済みだから言い訳不要 ほんとこんなデタラメな発言しかできないアラ還なんて学生からバカにされて当然だよな >>175 偏差四十九の職場の気狂いがハッタリを打って暴れているからたしなめているだけ お前にまともな話を振っても論文読めない数式読めない統計わからないですぐ発狂して1年単位で暴れて 山形大学長に迷惑通報する流れにしかならないから お前には一切まともな話題を振るつもりはないぞ >>165 初めて作ったツールでたまたまお小遣い稼ぎできて 当時奇跡が起きてることに気づけなかったのが悔やまれる まじでスケールさせれば今頃は… >>179 すげーな 今は個人開発やってないの? 才能ありそう >>178 そういうのをかけること自体がいいことだね 訴えてやる! >>174 まさにPrismaとGraphQLを組み合わせて使ったことある きちんと構築できると便利ではあるが保守が大変、あと難しいからか開発出来る人が少なくて開発者がなかなか集まらん >>179 AJAX周りはそれに近い流れで、結局MS→Googleの人が成果を掻っ攫う形だったね 大元のネタはその10年前NS周辺で行われていてMSに潰される形になったから、10年間誰にでも成功のチャンスのある分野だった >>183 また山形大学長と文部科学省と法務省に迷惑掛かるぞ だいたい匿名掲示板でこの手の話が盛り上がってたのは 今から20年前2000年代前半までで 今じゃクズしか居ないからまともな人は誰もネタを振らないよねw dBaseのインスタント開発程度しかやったことのない素人が このスレで実態のない妄想を書いては突っ込まれているだけ レベルが国内最低レベルの掲示板 >>185 あれー?相手にしないんじゃないんですかぁ?? 国家機関に迷惑が掛かると落ちこぼれに警告したら 落ちこぼれ発狂の巻ワロタ >>124 せやで 結局コミュ力、言語化力、面倒な手続きとか覚える力とかが必要とされる つまらない業界や・・・ 個人開発か下流バリバリプログラマ以外楽しくないと思う OSSじゃなくても、ツールつくってたとえばなんかで跳ねてもメンテで時間持ってかれるわりにまったくリターンがないし 英語だクソみたいなメールが飛んでくるだけでいいことはマジない あとエゴサで心が死ぬ 日本の会社はIT利用産業しかないので文系でも出来るというだけ 外資系IT企業はブラウザのレンダリングエンジン開発(Blink)だったり、webフロントエンド用のフレームワーク開発(React等)だったり GraphQLなどのフロントエンドとバックエンドの通信用規格の策定・実装だったり Javascriptを高速化させたり(V8)、多種多様で高度な仕事がある どのプロジェクトも日本人集団には絶対に作れないだろう 実際、日本人が作ったweb関連のオープンソースプロダクトで有名なものは殆ど存在しない 今をときめく深層学習ライブラリですら東大の天才集団たちが作ったChainerはFacebookのPyTorchに駆逐されてしまった https://pc.watch.impress.co.jp/docs/news/1222796.html web界隈ではRuby on Railsのおかげで有名になったプログラミング言語Rubyがあるが、現在は諸々の理由であまり使われなくなってしまった https://descartes-search.com/media/5-programming-languages-you-wont-use-2030/ >「2030年までには、おそらく使われなくなっている5つのプログラミング言語」 >3位 Ruby >Dice job-posting dataによると2018年の境にRubyを扱う企業の数が激減している >>180 個人開発ちょっと前から再開したよ〜 いまはキャッチアップついでに マイペースにやってる感じだけど 先述の後悔が消えないからっていうのも多少ある笑 チャンスあったら狙っていきたいよね〜 フロントエンドはMVCで言うView部分だから 素人の目にもわかりやすく見えて dBaseくらいしか触ったことのない落ちこぼれが対抗意識を燃やすよね でもModelとControllerありきのViewだから 殊更Viewを敵視するのは素人丸出しで微笑ましいよね GraphQLは追加されたり変更されたりする全ての要件を満たす状態に維持する必要がある これは辛いだろ >>194 おお! 経験あるしすぐに稼げるようになるかもよ おれは始めたばかりだからいろんなことに四苦八苦してるわ ここで聞くのはちょっと違うかもだけど ストアからapiたたくのと、コンポーネントからapiたたいて 必要なものだけストアに入れのとどっちが正しい? 俺は後者だと思ってるけど >>193 日本人でも優秀なのはアメリカ渡ってるだろ xxxxQLの部分は28年くらい前に後のNode.js相当のフレームワークを作って使ってた時に将来構想として予定は立ててたな そのあとXML-QL的なものが必要になるXML DBのプロトタイプの仕事に手を出し掛けてでも開発の話にならなくて そっち方面の開発はやめたっけ >>200 そう思う Storeから直というかStoreのデータを直に送信しない方だいたい楽になる Storeのデータ群は基本、コンポーネントに呼び出すだけにとどめる コンポーネントのしかるべきとこで丸めたりバリデートしてからapiを叩く >>201 日本人でも優秀な人はGoogleに就職してたけど こないだのレイオフでがっつり切られてしまっていたよ あちら基準の優秀レベルには到達していなかったようだ 井の中の蛙であった >>203 うんAPIの窓口としてStore使われてることよくあるけど複雑になるよね 自分はそもそもStoreはなるべく使わないようにしてるけど スレッズなんかもそうだけど 今ってフロントエンドの微妙な挙動の差とかが 製品の成否にすげー影響するんだよな フロントエンジニアとかいちいちいうこと臭いし イキってていらつくけど 大事にしないと駄目なんだわ >>193 二段落目の仕事はウチらの世代の担当だな 28年前時点ではそれをやる場所がなくて エッジな仕事をするITベンチャー自体が国内にほとんど見当たらない絶望的状況だった ITバブルが弾けた2000年以降はその辺ずいぶん変わったよね >>195 いやあ、MVCてのが古いだろってのが、ここ10年のフロントエンドの考え方なのに エアプすぎないか せめてMVVMだよな? エアプでよくそんだけ書けるな デザイナだけど一緒に働いてるフロントエンジニアより給料低い 職種的に給料低いからしょうがないけどさ なんとかならんのかね >>199 はやくそれになりたい なんやかんや見た目や使い勝手の部分が大きい気がするし、始めたばかりでも全然同じ土俵だと思う! >>199 はやくそれになりたい なんやかんや見た目や使い勝手の部分が大きい気がするし、始めたばかりでも全然同じ土俵だと思う! >>208 ユーザーが一番目にして触れる所でユーザー評価に直結するからな 少なくともBtoCのサービスでそこを軽視して言い訳がない >>208 ユーザーが一番目にして触れる所でユーザー評価に直結するからな 少なくともBtoCのサービスでそこを軽視して言い訳がない ハイブリッドレンダリングも28年前からある課題だな 当時はサーバーサイドでHTML全部生成するスタイルがほぼ全部で クライアントサイドレンダリングをHYMLベースRichクライアントとして作るところから始めなきゃならなかった でも当時JSONもないからデータの送り込みをjavascripのデータ定義コードの形で書いたり それを受けて表示するクライアントサイドコードがGC絡みで重くなりがちになって 軽量に済ませたい部分はサーバーサイドに戻す必要があった プロセスマイグレーション的なイメージで、サーバー側でもクライアント側でも実行できるコードを書きたい欲求はあったけど サーバーサイドJavascriptみたいのが急速に消えた時期で サーバ側にJavascriptインタープリタを仕込む訳にも行かず クライアント側を逆にJavaにしてJavaで統一するモデルも流行遅れになって、にっちもさっちも行かない状況だったっけ まーコード共用はしないのがベストだろうけどね >>211 javascriptぐらい使えるようになればいい ハイブリッドレンダリングも28年前からある課題だな 当時はサーバーサイドでHTML全部生成するスタイルがほぼ全部で クライアントサイドレンダリングをHYMLベースRichクライアントとして作るところから始めなきゃならなかった でも当時JSONもないからデータの送り込みをjavascripのデータ定義コードの形で書いたり それを受けて表示するクライアントサイドコードがGC絡みで重くなりがちになって 軽量に済ませたい部分はサーバーサイドに戻す必要があった プロセスマイグレーション的なイメージで、サーバー側でもクライアント側でも実行できるコードを書きたい欲求はあったけど サーバーサイドJavascriptみたいのが急速に消えた時期で サーバ側にJavascriptインタープリタを仕込む訳にも行かず クライアント側を逆にJavaにしてJavaで統一するモデルも流行遅れになって、にっちもさっちも行かない状況だったっけ まーコード共用はしないのがベストだろうけどね ハイブリッドレンダリングも28年前からある課題だな 当時はサーバーサイドでHTML全部生成するスタイルがほぼ全部で クライアントサイドレンダリングをHYMLベースRichクライアントとして作るところから始めなきゃならなかった でも当時JSONもないからデータの送り込みをjavascripのデータ定義コードの形で書いたり それを受けて表示するクライアントサイドコードがGC絡みで重くなりがちになって 軽量に済ませたい部分はサーバーサイドに戻す必要があった プロセスマイグレーション的なイメージで、サーバー側でもクライアント側でも実行できるコードを書きたい欲求はあったけど サーバーサイドJavascriptみたいのが急速に消えた時期で サーバ側にJavascriptインタープリタを仕込む訳にも行かず クライアント側を逆にJavaにしてJavaで統一するモデルも流行遅れになって、にっちもさっちも行かない状況だったっけ まーコード共用はしないのがベストだろうけどね >>211 javascriptぐらい使えるようになればいい >>210 古い新しいではなくて基本の話だな そもそもその分野開拓してたのがウチらの世代で フレームワーク作らずに現状肯定するだけの MVC type II (MVCではない)なんて言葉作ってたのは ウチに来てた協力会社関係の人だわ つまりコチラが最初から居るガチ勢 「古い」で否定するのはエアプの特徴なのに 他人をエアプ呼ばわりとは人間性に多大な問題があるな >>210 古い新しいではなくて基本の話だな そもそもその分野開拓してたのがウチらの世代で フレームワーク作らずに現状肯定するだけの MVC type II (MVCではない)なんて言葉作ってたのは ウチに来てた協力会社関係の人だわ つまりコチラが最初から居るガチ勢 「古い」で否定するのはエアプの特徴なのに 他人をエアプ呼ばわりとは人間性に多大な問題があるな vueやって思ったけどどんどんフロント側の負担がデカくなってるよな バック側楽しやがって 理系で情報卒業した学生もそんなもん 頭の良さも業務の差には関わらず向き不向きがあるし なんでわざわざ二つのネットワークから書き込んでんの? 子供か? どんなに腕のいい大工でも建築家になれる訳じゃない。 vueの方が楽でいいのにreactの案件ばっかりだよな プログラムで理系ってそれこそ今のAIの元の仕組みを作るとか 画像や音とか物理演算の仕組みを作るあたりじゃないの? それ以外で乗っかって使う側は文理関係なく「プログラムの勉強した人」だろう 最近のエンジニアは情報学部出た人より数学科出た人を採ってるらしい ちなみにModel-ViewModel-View通称MVVMなんてのは、 Web版MVCの一番最初からあった概念。 Webでは、 データを含むModel側の大半はサーバー側 View側はWebブラウザやWebクライアント側 に分割されるのが基本前提。 そこにMVCのController=ModelとViewの疎結合コード を追加する時に、 従来型Web(もしくはMVC type2)の HTML/HTTP≒Controller という解釈をしてしまうとイベント発生のたびに ページレンダリングが発生して処理が重く見た目もウザくなる。 そこでページを変えずに部分要素<div/>や<frame/>、<Iframe/>の単位でイベントを飛ばし結果を全体に反映する イベント駆動機構の再実装が必要になる。 更には、データ入力/表示のたびにサーバーと通信するのではなく、ローカルにデータモデルの一部を置いてローカルに処理し ある程度まとまった結果のみサーバーとやり取りする、ローカルデータモデルも必要になる。 ここら辺の概念をうまく実装するには クライアント側にViewとlocal Modelを扱う階層が必要になって、それがViewModelの一つの導入の動機たり得る。 当時〜AJAX登場前までは、Horbの用語を拝借して View対向proxyみたいな便宜的な説明をしていた。 匿名掲示板過去ログにも当時の議論の記録が残っているはず 最近はChatGPTに答えがのってるぞ >>226 奈良登山騒動でサーバが反応しなくなったからだろ。 他の人も二重書き込みしてるやん。 サーバー負荷を感じない特殊な回線使ってる人は気付かないだろうけどw プログラマーだけど最近はchat gptに全部聞いてるわ 有料のGPT4ならガチで精度高いし サーバー高負荷の時にひょいひょい書き込んでるのは 運用VPN経由の書き込みだろうね。 昔から、災害や炎上で誰も書き込めなくなってる時に 明らかに怪しい煽り書き込みをするネトサホとか居たっけ フロントエンドエンジニアとは要はホームページ作成と更新で、 給料は低くて納期が短くて長時間労働だからあまりよくない >>224 バックエンドって割と神経使う仕事の割に 報われないのよね 要件に応じて パフォーマンス改善したり 高負荷高可用性に備えたりしても 側から見たらピンと来にくい そしてサービス障害起きたら 真っ先に対応させられて詰められる笑 >>238 たぶんマークアップする人と勘違いしてると思う、マークアップはクソ単価低いし締切めちゃくちゃギリギリだし辛い。 フリーでフロントエンド領域でやってるが某会社の社内ツールをvue.jsで構築してるが、締切はほぼ無いわ月単価は90万だし最高だぞ。 元々バックエンドやってたけど面白くないからフロントに転向したわ 画面いじってる方がモチベに繋がるし ViewModelの概念は、 HTML Richクライアント設計でサーバー←→ ブラウザの通信内容をイベントとデータに絞り込んだ時、 クライアント側を純然たるView層とするのは現実的には難しく サーバー側との通信や状態管理を管理する「Controller層+View管理層」を合体した「RichクライアントApp」的な層が必要になる事で導入できるね。 それ以前に説明として使っていたView対向proxyの概念は、 サーバーサイドレンダリング/クライアントサイドレンダリング のモード変更を吸収する層で、 サーバー側とクライアント側にセットで設置する考え方の説明 Reactはバージョンアップ早すぎて ChatGPTがついていけてない箇所がある だるい CSの学位取って今はIaCとシェルスクリプトでアーキテクチャ構築しとる この領域だけは文カスには渡さんぞ AIの普及で元々コミュニティが大きくて学習素材が多いとこがますますシェア広げるのかな? >>243 vueも2系と3系、さらには3系のsetup有無で書き方が全部異なるからGPTに聞いても回答がぐちゃぐちゃやで、大体ロジックとしては合ってはいるんだけどね。 複数の画面遷移むず無い? DBの排他も書くからバグとり大変やで それなりのノウハウは要るとオモー >>241 わかる (一番は休日の障害対応やりたくないのが理由だけど) >>244 CS学位ってわざわざ書く時点で日本じゃないのか? たかだか4年、一般教養抜かしたら2、3年の学部教育だけじゃ差がつかない気がするけど ReactNativeだけど 平気でvarやfor文を使う とっくにhooks出た頃に作ったアプリなのにクラスコンポーネントで書いてる 3000行ぐらいの巨大なstyles.jsを用意してスタイリングしてる、そのせいでstyles.jsを編集するとアプリ全体がリロードされる 基本1画面1コンポーネントなのでほぼすべてのコンポーネントが1000行超えてる 地獄みたいなコードをメンテしてから誰でもできるって言って欲しンだわ >>243 Reactは何年か前にHooks来てから割と安定してる方なイメージある たまにプログラマーじゃない自分が作ったものをユーザーが使ってくべるわけないし一人でも使ってくれたら御の字だなと思って自信なくなる時あるわ html・PHP・javascriptって「文章」だよな むしろ文系の仕事じゃね? DBとのやりとり部分は無理か もちろんその他、頻繁な通信をローカル処理で高速に済ますために、Modelおよびそのローカル管理の一部もクライアント側に取り込む必要があって ・サーバとやり取りするJasonデータ≒Model ・扱うデータはView用入出力データのみ みたいな解釈をしても、データハンドリング用クラスが クライアント側に染み出して来る。 それはサーバー側データハンドリング用クラスとは実装が別になるから、それらをまとめてサーバー/クライアント通信層オブジェクトみたいな形にするのが自然なのだと思う だからWeb対応MVCの疎結合設計は サーバ側Model←→ サーバー側App proxy層←→ クライアントApp層←→クライアント側View みたいな構成にして、真ん中の[App Proxy層←→App層]の部分が従来型MVCの[Controller]相当機能をカバーする形になり ただしその内側では、ModelやViewの簡易版が通信可能な形で飛び交う内部的簡易MVCモデルみたいなものを考える必要がある 改めて図示すると サーバー側 クライアント側 Model ←→ [App Proxy ←→ App] ←→ View 内部的簡易MVCオブジェクト が飛び交う JSONという気味の悪い拡張子の色付け係だからな誰でもできるぞ 文系でも法学部卒に限っては下手な理系学生より理系っぽいわ >>253 MSがJScriptでOLE DBを起動して Webブラウザから直でRDBアクセスさせてた時代を知らないとは おめでたいなぁ 1コンポーネント1000行ってのは まともにクラス設計もモジュール設計もできない人の成果物臭いなぁ 入れ物や見た目をいくら変えても 手続き型コードしか書けない組織やプロジェクトやプログラマが 中身を埋める地獄絵図 自分はVisual Studioおじさんで、日頃Web系の開発には無縁なんだけど、画面のデザインとかって今はどうやってやるのが主流なの? さすがにhtml直書きじゃないよね?Visual Studioみたいな開発ツールで簡単に画面デザインできたりするの? バックエンドに関わってる人や既存フレームワークの拡張改造に手を出してる人も大勢居ると思うけど 一からフレームワークを設計してクラス設計/モジュール設計してソース公開できる人は、いつの時代も一握りなんだろうな そこら辺が見えてれば議論も楽だし仕事も楽しくなると思うけど 基礎の余分な仕事に手を出すには本来やるべき仕事を高速に仕上げて時間的余裕を作る必要があるし そうやってゆとりを作ってもデスマーチ展開だと基礎仕事どころか人生削られる流れになるだろうし 企業内で研究開発職に就いても、今の時代は成果のビジネス化だけでなく売り込みや顧客対応までSE並みに要求される時代だし みんなどうやって基礎研究してるんだろうねw >>260 それ俺の話じゃないから 1コンポーネント1000行メンテの話をしてる人に その役立たずリントのレスを付けてドヤ顔してやれ すげぇな素人の書き込み デスマーチ現場に「Lint入れろよ」 1コンポーネント1000行仕事に「Lint入れろよ」 エアプの極みw 昔、情報系科目の教官で学生が何を質問しても マニュアルを読め としか答えないのが居たわ 嫌われてたけど実際マニュアル読めば載ってるしなw 今はそれが ググれ や >>264 数学や物理は数式という言語をメインツールとして扱うよな フロントエンドエンジニアか・・・あまり良い印象無いなぁ バックエンドをメインでやってきたエンジニアの方が要件定義やお客とも会話ができる人が多い傾向がある >>266 Webコードのスタイル(見た目)と機能の分離って25年くらい前には実用化されてるのに 未だにWebコードにはデザイナー仕事の側面しかないと思い込んでいる底辺大職員が匿名掲示板で暴れているから大変だよな 30年前からタイムトリップして来たんじゃねぇかってレベル >>267 英語論文も数式も統計も読めない自称物理屋は存在価値なしって話だろ 言語能力が低くても物理モデルや数学モデルを頭の中に構築してそれを外界に表現できれば仕事になる どっちもない人はただのエアプ >>222 いや、だから今はMVVMだつってんじゃん REACTとかVUEとかやってないの? VIEWはもうVIEWだけじゃなくなったってのがモダンなフロントエンドの共通認識でしょ この書き込みしてる人は、無知のハッタリで高等教育機関にしがみついてる感が溢れてるね。 この人はサイエンス系の大きなプロジェクトに所属した事が一度もないから、学生にすら見破られるハッタリで定年まで干される人生だからしょうがないか。 181:番組の途中ですがアフィサイトへの転載は禁止です (ワッチョイW d7af-PWsv):2023/07/08(土) 10:53:16.26 ID:DqqEt0xi0 >>178 そういうのをかけること自体がいいことだね 229:番組の途中ですがアフィサイトへの転載は禁止です (ワッチョイ 17d2-UoGw):2023/07/08(土) 11:43:58.47 ID:awAdm86a0 プログラムで理系ってそれこそ今のAIの元の仕組みを作るとか 画像や音とか物理演算の仕組みを作るあたりじゃないの? うちも自分以外、全員ゴリゴリの理系院卒しかいない。 答えを導き出せるならええやろ ググってもそのまま流用できるわけでもないし バグっててもフロントかバックが原因か分からない場合もある 結局はどちらも出来ないとダメなんだよね >>271 その話はとっくに済んでるぞ。 お前はキーワードを振り回すだけで中身を理解していないから その話が澄んだ事にすら気付かずに同じ話を蒸し返す哀れな人生を送ってるんだよな。 英語論文紹介と称してデタラメ説明 論文誌投稿取り消し手続きの説明と称してデタラメ説明 もう実名で英文まともに読めずに虚勢を張る人として有名に なってるのに、日本語もロクに読めないことを自己開示して 職場の学生さんも困っちゃうよね 自分が欲しいデータをデータベースから取ってくるにはSQL書く必要あるからな それもchatGPTで解決可能 フロントでもchatGPT使ってるかどうかで生産性に爆発的な差が生まれてるw ただ、フロントはフロントでなんか独特のセンスいるよなぁ。情報学科卒でもあんまできない人いるというか そもそもそこらへんの知識生きない気がするし 世の中には居るんだよね MVVC、MVVC連呼しておけば 内容を理解しているフリが通用すると思い込んでいる 偏差四十九職場の落ちこぼれ この人、GUIにいちゃもん付けるスレを立てた時も 具体的な話を一個もできず それならユースケースを書いてどこに問題があるか分析しろと 助け舟を出しても「ユースケース」が判らずに 街角の看板がおかしいとか的外れな話を100レス単位で続けていた 真性メンヘラだぞ 立てるスレ立てるスレ煽りまくるくせに 能力が低過ぎて健常者と会話にならない どうしようもない知恵遅れ chatGPTの活用法 SQL書いてもらう リファクタリングしてもらう 変数名の候補を挙げてもらう 関数名の候補を挙げてもらう ブランチ名の候補を挙げてもらう 管理者に依頼文を投げる前に校正してもらう 生産性、爆上がりw >>281 誤変換訂正 × MVVC ○ MVVM (Model View ViewModel) >>285 SQLインジェクション脆弱性を無知な人に押し付ける悪いAIワロタ >>285 配列の要素をたくさん持ってるデータが欲しい時 子からの参照が多い親のIDを探すときにSQL文書いて探す 配列の要素→親と子→SQL という組み合わせに知能の低さを切実に感じる 去年まではまずググるって習慣が完全に「まずchatGPTに聞く」に置き換わってるからな もうchatGPT取り上げられるとググるの禁止よりもつらいんだよなw まーたエアプがAI連呼するゴミスレか ITにコンプレックス持ってる虫ケラ >>283 昔は VIEW(画面の表示) MODEL(ビジネスロジック) Controller(VIEWとMODELをつなげる命令を出す) 今はフロントエンド側が司令塔になっているので VIEW(より純粋にユーザとの接点となる画面の機能のみを担当するようになった) MODEL(ビジネスロジック。バックエンドの仕事はほぼMODELのみになり、Controllerはいらなくなった) VIEW MODEL(アプリケーション状態やイベント、データの取得等を管理をする。フロントエンド側でController的機能を兼ねる) >>291 フロントエンドにSQL書いたらSQLインジェクションとかきちゃうじゃん 大丈夫なん Webの勉強してるけどフレームワークの話ばっかり出てきて根本のWeb技術をわかりやすく噛み砕いて説明してるサイトや動画が出てこないんだよな。 >>296 その話は約28年前Web対応MVCの時点でそうなってるんだけど 物凄く頭の悪い人が「Webシステムは[MVC type2』だ」と称するデタラメ定義を広めてしまったので誤解が生じているね >>297 アプリに書くんじゃないよw APIコールする関数作るときに複雑な構造を持ってるIDが必要になる IDをデータベースから取得するのに使う >>298 オライリーの本を買えば Real World HTTP 第2版 ―歴史とコードに学ぶインターネットとウェブ技術 とか、新し目の情報がぎっちぎちに載ってる そもそもローカルGUIベースのMVCを HTTPプロトコル/HTML縛りのあるWebにマッピングした時点で Controller部分の設計に齟齬が生じて Webブラウザ周りの規格拡張と アプリケーションモデルの再設計が必要になるんだけど 当時の日本はMVCコードに触った事もないような素人が MVCとは具体的にどんなコードが知りもせずにMVCを連呼する 悲惨極まりない状況だったからしょうがないよね 因みにWindowsのGUIは非MVCなので、参考にはならないのに なぜかSmalltalkを触ったことのない人がMVCを知っているフリをする、知ったか文化が当時も蔓延していた >>301 オライリー読みづらくて高いからやーやーなの 技術書ってどれも帯に短し襷に長しなんだよな >>300 キチガイジワロタ それ30年前だったらCAD的なコンポーネント数の多いデータの管理にブラウザ内蔵Object DBを使うソリューションもあったけど あのソリューションは一般化しなかったし そもそもID取得にサーバ側SQLを呼び出すってそれ アプリケーションコードつまりモデル側2tier構造(Webサーバフロントエンド+DBMS)周りの話じゃん ガチでキチガイジ >>305 技術書には読み方がある 本当に重要な情報は全体の約2割 残りの8割は比較的どうでもいい情報 だからその2割だけを読む 残りの8割は適当に流せばよい オライリーのTypeScript本も8割はどうでもいい情報だったw >>307 技術書ガチャ高すぎんのよ 新しいLinuxの教科書とかいう3000円くらいの本がおすすめされてたから買ってみたけど全てが中途半端で結局GitもVimもLinuxも別の本買うことになったし いまちょろっと@ITの猪熊とかいう人の解説にも 「MVCもさまざまな解釈があるから禁句にした方がいい」とか、無知の極みなことを書いてるけど この人もFowler氏の言うMVCがSmalltalkのフレームワークの話だと知らずに、デタラメ解釈で話が混乱している現状を理解してないんだね 読み進むとMicrosoftの話が正論みたいなスタンスだから MVCが何者か知らずにMVC禁句とか言い出す頭の悪い人だ 日本のIT関連メディアはいつまで経ってもレベル低くて困るわ >>309 わかる 定評あっても自分と合うかわからんしな あと落丁とか誤記多いわ 知らない事を知ったかぶりした末に禁句にするとか 典型的な低学歴仕草だよな ふつうFowler氏の文章をちゃんと読んだらSmalltalkの話だと明示されているし そこでSmalltalkとは縁がなく Microsoft GUIフレームワークと縁があるなら そのフレームワークが別のパターン本で何と説明されているか その後のMS GUI側アップデートでどんな齟齬か生じているか 把握してから説明すべきだよね 知らないから誤解が起きるから禁句って 日本の頭の悪いIT業界の悪習そのものじゃん ほんと、こんな連中がデザインパターンを論じるようじゃ 日本のITのレベルはいつまで経っても上がるはずないわ まあ自分もあんま頭の悪い言い種を延々と聞かされたら しまいには切れるけど あくまで控えめに、知らない事を無知の知としてハンドルして ベストを尽くす知的誠実さが必要だと思うわ フロントエンドは流行り廃り激しくて、その度に新しい技術身につけた若い奴らが参入してきてるイメージ フロントエンドを極めた職人みたいなベテランエンジニアって見たことないわ >>313 おい液体ラマン散乱実験工員、いい加減成果出せよ 28年間やって成果の出ない工員が 着手9年目かそこらの次世代ロケット開発に罵詈雑言を延々と書く知恵遅れ仕草の落とし前を、液体ラマン散乱でちゃんと付けろよw >>315 学位持ちでビュー専門ってまず無いからな 結局、匿名掲示板で身の程知らずな虚勢と罵詈雑言を飛ばす人は 本業でも職場でも居場所がないからその鬱憤を匿名掲示板で晴らしているだけだよな 匿名掲示板で暴れる人=仕事も個人生活も破綻した廃人 廃人の介護はもう嫌なので落ちる >>193 まあコンピュータの概念もソフトウェアの概念も欧米発祥だし、 OSであれミドルウェアであれプログラミング言語であれ開発ツールであれ、 日本人はいつも外国(だいたいアメリカ)が作ったものを使わせてもらうだけだからな。 ググれば答え乗ってるのとメーカーマニュアル読破すんのもあんまり変わらんけどな ただ楽なのは正解が決まってる所 人に聞け→みんな言ってることが違うとかいう糞みたいな状況にならないのが良い >>320 その傾向ないね 情弱に高値で売れるからボロい分給料いいからな >>320 昔は完全にそうだったけど今はそうでも無いと聞いた >>320 データサイエンティストなんか需要高くて高収入やん >>320 今の時代は文系の時点で負け組が決まってるから理系である時点で勝ち組 >>324 データサイエンティストとか実際になれてるのは、それなりに高学歴の人に限られてるので、 そこらの底辺大とか専卒にとっては関係ない話だからな。 そもそも、エンジニアがカースト的に低いから待遇悪いのであって、さ そのカーストを高めていく努力をせず、よその足を引っ張っているだけでは、 やっぱり今の位置にとどまるよね >>326 論点逸し爺さんさぁ~ "理系でIT"って話はどこ行ったん? 結局おまえの見聞が狭かっただけだね >>328 勿論それなりの大学での理系でITって前提だよ。 底辺大はそもそも理系・文系を分けて語ることがナンセンス。 >>286 リファクタリングと変数名はそこまで生産性向上とも思えない気もする SQLはどのレベルまで書けるのかな? こういうスレ見てても、隙あらば他人の揚げ足取り、マウント取りに躍起になるゴミクズみたいな人間がITには多いってことがよく分かるな 使い勝手やデザインセンス皆無のエンジニアさんの時代じゃないんですよ そもそもエンジニアとは海外では軍隊の工兵を指す言葉 日本では陸上自衛隊施設科部隊が相当するが、これは普通に高卒でなれる >>332 普通はデザイナーと分業やろ >>331 俺の周りにはぜんぜん居ないんだけど嫌儲には沢山いるんだよな >>332 でもお前客が持ち込んだ膨大なクソデータを加工してDBに投入できないじゃん つーかwebアプリなんてバックエンドもたいしたことねえよな >>338 toCのWebはバズれば秒間数万アクセスとか余裕で行く世界だからな 初めから負荷分散を考慮してなきゃ一瞬で落ちるぞ >>81 ぶっちゃけそれ単純に人のせいにしてるよね 大学や大学院で専門教育受けてるやつだっているわけだろ そいつらは何やってんの? >>340 それって主にインフラ担当の仕事じゃね バックエンドのコード書く奴らはサーバー横断して使えるキャッシュ機能のミドルウェアをインストールしたり 必要なロックをかけるくらいじゃないんか >>342 インフラだけじゃどうにもならん キリがない キャッシュに対応できるようにアプリを作らにゃいかんのですよ >>341 日本人自体が劣等民族だから救いがない。 プログラマもやらSEは文系だよ。上位資格立ち読みしてこい。理系らしさ皆無だぞ >>345 システムアーキテクトは数学が出来なきゃ取れないぞ 統計検定だのデータサイエンティストならまだ数字らしい >>336 え、まさかそのレベルで理系さんマウント取ってたんですか???? >>250 これしかもスタイリングもめちゃくちゃでjustifyContentやalignItems使えばいいところをmarginとpaddingを駆使してセンタリングしてたり、インラインでスタイル書くのを多用してたり メンテするときストレスがマッハ >>352 片方しかできない限り一生マウント取られるに決まってるやん 所詮お膳立てしてもらわないと何もできないってことだろ それは弱すぎるだろ >>343 そっか その辺は実務でやってみないとわからんからなあ 俺んとこは小規模だから想像つかんな ありがとう >>353 正規表現で一括変換(該当するスタイルを削除してクラス付与する、スタイルを書き換える)とかできるやろ >>356 css一括変換で別プロパティに変えてハイおしまいなわけないやん... もうそれ前提で組まれてるから調整がクソ面倒って文脈じゃないの。 置換して全てのテスト通すまでの工数もらえるならとっくにやるでしょ >>347 中学数学で6年間ゴネて学部長通報まで行った人が 文系だと強弁しても説得力ないぞ 還暦間際で中学数学がガチで解けず 積分すべき場面で微分まで戻って説明する理系とか 統計の母集団の相違を訂正されても理解できない理系は 嫌儲のアラ還統失婆以外に見た事がない >>350 日本の国立底辺大理系に行くと 中学レベルで統計を取りこぼしたまま デタラメ説明をするガチの底辺理系職員が居て 悲惨だぞ あんなの雇ってる職場があるとは信じられないわ >>357 CSSのテストなんて見た目で比較するしかねんだから webdriver使って、変換前とあとの画面を全部自動でキャプチャさせて 比較すりゃいい コンポーネント化をちゃんとしてるなら、パーツ単位でいいから、そんなにテストの数ないと思うが >>360 いや、アメリカでも人文系学部卒は就職しにくいし、自己責任って風潮だし 中国も韓国も理系学部に力入れてる まあそれは大学の専攻の話だから、人の性質として理系文系を分けるのは少ないのかもしれない ただ、日本は明らかに文系に優しい国ではあるな CSSのテストには ・目視確認とエビデンスの画面キャプチャの他に ・全体視点からのユーザビリティ・テスト ・詳細視点からのインスペクター も使えるね。 cssはcascade形式だから、上書きに上書きを重ねてどの定義が生きているか/ブラウザの種類による挙動の相違と記述の書き分けがうまくいっているか、が詳細視点では重要 ネット上で専門分野言わずにエンジニアですと自称してる奴らってまさにこれだよね 機械であれ電気・電子であれケミカルであれバイオであれ、文系学部出身者が参入する隙はないわけだが、ITには余裕である。 そういう意味で、理系でITに行く奴は落伍者なんだよ。 まあ関西弁おばさんは仕事レベルの開発経験知は一切していないのに、机上の知識でそれは簡単だと言い張りながら 中学レベルの英語や数学でつまづく典型的な学習障害者だから 他人に憎悪を向けた書き込みが毎回物凄い事になる 15年前生物学板で、東大他の研究室関係者に向けてシネシネシネシネ毎日大量書き込みをして、実際に自殺者が出るとそれをスレのテンプレに追加するような気の狂ったシリアルキラー行為に没頭していた件は伝説的 >>186 型付けとsqlライクなクエリがあればいいっていう思想がいいよね なんか最近prismaに似せていっている気がするけど... あとunique制約さえあればほぼ満足だわ プログラミングって技術だけの話じゃなくて創作活動だから文系でもあるんだけどな STEAM教育にもArtがちゃんと入ってるだろ >>365 物理系でも落ちこぼれは物凄いぞ ふつう博士課程後期の学位は 学位認定委員会の審査を通して取得する物だけど このスレで暴れているおばさんは 基本3年間年限のうち2年目で学位取得見通しが立たなかったのは 指導教官が悪いと言い出して、学位取得研究を放り出して 全然関係ない分野の修士研究の続き(ラマン散乱)を出して 医学の学位を奪取するようなデタラメ極まりない事をやらかしている それが通るならさぞかし優秀なのかと思ったら英語論文読めない中学数学できない、ネット上では23年間朝から晩まで暴れっぱなしで重大トラブルを頻繁に起こしていて ただの気狂いと判明しているね、このスレでもやたら他人に悪意を撒き散らすけど、実態は実務経験なしのハッタリ老人 >>369 落伍者っていう言い方に過剰反応してるようだから、もうすこしソフトな言い方をすれば割に合わんということだよ。 なんでそんな有象無象がいるような分野を敢えて選ぶのか?って話。 この人もビッグサイエンス分野やそれスケールのプロジェクトはやった事ないんだろうな IT(ビジネス用語w)はあくまでスキルで 本業は適用対象となる専門分野 給料高いとこが勝ち組 理系で給料低かったらただの間抜け IT専門でゴリゴリやるのって研究開発職でもなかなか難しい現状があって、具体的に適用分野を絞ってそこでプロジェクトに参加して、そこで出てくる課題を本質的に解決するために基礎研究とか応用研究、プロトタイプ開発とか回していくか 教育研究分野に転職するしか居場所がないよねw ITが理系とか実際に働いたことないやつだと思う 実際の仕事は打合せも多いし人とのコミュニケーションがメインの仕事だし相手の言うことを理解する力が重要だし文系の方が合ってる部分は多い 技術力だけあっても意味がないからな 最近のフロントエンド見てみたい参考になるサイトとかリポジトリとかあったら紹介して >>375 日本企業の場合、割合が少し違うだけで研究職もそんな感じじゃないかな こないだ本体と合併し直した日本最大手のSIerとか 2009年頃までガチでサイエンス部門を持ってなくて 業界の勢力分布変更でサイエンス分野に手を出したくても 対応できる部署がガチでなくて 早稲田界隈の数理技研買収してグループ会社にして対応してたよね IT系にもサイエンス部門があるという当たり前の話、知らない人はガチのサイエンス系大型プロジェクトを知らない人だね >>370 さっきから俎上に上げている落ちこぼれ物理の人 還暦間際で職位基本給が評価最高でも500未満とか 研究費は科研費取りに行く必要があって それがぼっちだと3年間で500未満の科研費Cとか もう理系でも有り得んだろその金額という環境だぞ 落ちこぼれはITだろうと物理系だろうとその程度 >>379 落ちこぼれの意味を履き違えてるし、とにかくなんでもいいから言い返したいだけの無意味なレスだな。 課題の解決の為に本気でやろうとすると厳しい 日本では何も解決しなくていい みんな適当にやってる それがジャパニーズITなんだ 余計な手出しをすると仕事が進まなくてと自分がつらい目に合う >>278 Rustを難しいと言う人はプログラマーに向いていない可能性がある ただしRustはモダンなプログラミングパラダイムの洗練に集大成した側面があるため そのうちのいくつか知らない分野があるだけならば難しいといってもすぐに克服できるはず 例えばRustは関数型言語の特徴も多く見出されるとともに関数型プログラミングのスタイルも標準ライブラリさえ多用する 特に代数的データ型のOption<T>とResult<T, E>およびそのメソッドチェーンを理解しないと標準ライブラリすら使えない さらにイテレータが多くの処理の中心を占めておりfor文ですらイテレータが構成要素となっている これらにより可読性と保守性の大きな向上がありRust人気の一因ではあるが大衆的な言語から来た人が麺喰らうこともある 一方でRustはC言語的な基礎教養も持ち合わせていないと難しくなってくる RustはCと異なりメモリを安全に自動解放しつつもCと同様にガベージコレクションを必要としない言語だからだ そしてRustは参照という名の安全なポインタを多用することでC言語とほぼ同程度の速さと省メモリを実現している その上でRustはメモリ安全性とメモリ競合のないことを言語レベルで保証する革命的な特徴を備えている Rustを習得するのは他言語より少し大変だが習得してしまえばC並みの高速性と省メモリと両立する様々な安全性さらに何より可読性や保守性に開発効率の高さが手に入るのだ >>331 自身を差し置いてよく言う あなた自分のレスを音読してみなさい 低俗さに驚くでしょう >>309 >GitもVimもLinuxも インターネットを使ってはいけない縛りプレイでもやってんの??w これこそ公式のリファレンス読めば良いのになんで本なんか買ってるの? そもそもLinux全体なんて概要だけになるに決まってんじゃん ディストリビューター決まってるなら公式のリファレンス読めば良いだけ モンスタークレーマー気質やん まとめブログなんてコピペプログラマーがいるくらいだからな 実際適当なノリでやっているやつらばかりで不快なページばかりになったよ 画像に高さ設定しないから文章読んでいる間に画像のロード終わって差し込まれて、読んでいる文章が下にぶっ飛んでいくサイトばかり >>382 コピペ上等だけどあなたRustのHeap変数を適切に説明できなかった人じゃん >>382 それってコンテナ側で自動化できる話だよな コンテンツが確定した時点でsrc画像サイズを測って レイアウトに応じたwidth, heightを仮設定しておいて 画像のローディングが終わった後にwidth, heightを更新するか否か選択可能にする感じで >>380 落ちこぼれの意味は合ってるぞ ・英語論文誌への投稿で学位授与資格を認定されているのに 現実には英語論文の読み書きがまともにできない →指導教官による代筆の可能性が極めて高い ・理系で積分や統計、統計物理が必須の実験系なのに、 中学数学の該当分野が関わる議論で毎回数年単位で発狂して 学術議論を妨げる癖がある ・匿名掲示板では他の研究開発者の年収や職場環境を罵倒するが 本人の基本給や活動費用は底辺水準 (基本年収500未満、研究費3年で500未満のランク) いくら虚勢を張っても、現実が悲惨だから説得力皆無だね 結局この人はコミュ障で 職場で適切な上司に就いたり他大学の研究者と協力したり 指導学生を採って研究教育活動に邁進する事ができず 23年間匿名掲示板やSNSで世論扇動/誹謗中傷/流言蜚語/恫喝活動ばかりして その必然的結果として 23年間職位固定のままあと数年で定年 基本年収や活動費用は底辺レベル となっているのに 他人に対しては常に虚勢を張り続けて悪意を漲らせて 意味もわからず長文コピペを貼って反論されて破綻する 人格破綻者だからしょうがない (ワッチョイ 57a2-t0cl) ID:MDZP2/iw0 は「落ちこぼれ」「落伍者」の本人でしょ 誰もそんな話題に興味ないのに 1人でネガティヴワードを振り回して 皮肉返しで本人の基本年収と研究費を書かれて発狂 >>259 でVisualStudioガーと言い出したり 誰も性別や年齢の話をしていないのに「おじさん」を自称したり 明らかに頭がおかしい サイエンス系IT分野の頂点の一つ ゴードンベル賞を7回受賞した物理学者が ここで暴れる落ちこぼれ物理の人の妄想議論の相手をして とっくに結論を出しているよ 「この人は科学者/研究者とは呼べない(ただの権威主義者)」 しばらく観察すればすぐわかるよね ・匿名掲示板やSNSで有象無象相手にセンセーショナル発言を したがるが、基礎ができていないので虚言放言が基本 ・提起され共有され、落ちこぼれ物理が虚言を弄した分野で まともな研究者が成果を出しても 己の間違いの総括や謝罪を一切せず 自分はその分野に向いていないから結果を出さなくていい と称する酸っぱい葡萄発言をして誤魔化し続ける 頭が悪いのに虚勢を張りたがり、権威主義なのにセンセーショナル発言をしたがり、現実との齟齬が明白になっても開き直って 誤りを訂正しない 専門分野の他の人はもっとシビアに見ていて「この人は知らない話を罵倒する癖がある」から使い物にならないと言っている。 ただの権威主義のお調子者で反論癖/全否定癖で人生終わってる人だね >>387 誰と勘違いしている? RustにHeap変数というものは存在しない もうその話は言語仕様からの引用で論破済みなので 落ちこぼれ物理の虚言は不要 中学英語も中学数学もできない知恵遅れ落ちこぼれ物理の 妄想議論の相手をする暇人はこの世にはもう居ない 落ちこぼれの物理学者とか、博士まで出てもろくに就職できない高学歴ワーキングプアの類で、 理系でIT行く奴は落伍者という話とは何の関係もないな。 そういう無関係な話を脈略なく一方的に話すアスペみたいなのが多いのもITの特徴ではあるな。 >>394 Rustに対してヒープ変数という用語を使っている時点で かなりの初心者もしくは全く無知かかなり勘違いをしていると見受けられる 以降は気をつけるように 落ちこぼれ物理の虚言癖の原因は統合失調だろうと言われている 原典(ここでは言語仕様)から定義を引用して決着のついた話を 何度でも蒸し返すのは、英文で書かれた定義を適切に理解できず 人から説明されて反論の余地なくやり込められても 一晩眠ると知識がリセットされて、同じ問題を蒸し返す こんなのが教育現場に居ても、研究指導を依頼する学生など居るわけないよね。毎日同じ話を蒸し返されたら学位論文研究などできなくなる >>396 その議論はとっくに終わっているから 天羽特有の虚勢で意味のない妄想を書いても誰も相手にしないぞ そもそも中学英語も中学数学も身についていない基本年収500未満のクズの虚勢など、世の中の多勢に影響もない この手の話って 他の人は普段は専門分野の学位持ちや開発者と議論してるのに 畑違いの物理の落ちこぼれが幼稚な強弁をしてもゴミクズでしかないよね そもそも落ちこぼれ物理の唯一の実社会IT経験は 30年前のdBase業務アプリ(MS Accessのような環境) しかないから、専門用語の用法すら知らずに 「自分の中の幼稚な知識と違う話は全否定」 で暴れるだけなんだよね 初心者どころか歳を食ったキチガイジでしかない >>398 間違った用語や概念を持ち出してきてる時点で あなたがRustについてほとんど知らないことは承知したが そんな状態で何の議論したのだろう? 自分みたいな低スキルでも980万とか稼げる点では、底辺にとっては割りの良い業界ではあると思う。 >>401 前回議論でお前がIT分野の基本用語も知らず Rustの言語仕様におけるHeap領域にアロケートされる変数のライフサイクルも説明できず、そんなものはない全部自動管理されるからHeap領域は関係ないと妄想を書き続けた末に Rustの言語仕様を引用した説明したで一発玉砕してるからだらし無いよな。 頭がバカ過ぎて、言語仕様すら読めずに妄想を書き続ける天羽はIT分野では通用しない 自分のプログラミング能力がいかに高いかとマウント取ったところで、 知能面で医師とか弁護士の頭には到底及ばないので、所詮、 低学歴が挽回するための手段の一つでしかないんだよな。 結局天羽を雇っている職場の人は 心身障害者雇用枠の一種として我慢してるんだろうな まともな学術議論もできない妄想症状の患者を23年間も飼うには、他とは違う基準を適用しないと誰も納得しない >>404 還暦間際で弁護士資格も医師免許も取得できず 23年間匿名掲示板で妄想を書き散らす狂人がそれを言うととても説得力があるなぁ(皮肉 IT分野の最高峰の一つGreen500でトップを記録した人は 医師免許を取った上でMRI動画技術の実用化してシリコンバレーでベンチャービジネスを成功させ、その次の仕事としてGreen500トップだから、そのレベルならITと医師免許の両立が意味を持つね 落ちこぼれ物理が還暦過ぎになって医大に学士入学して医師免許を取れる可能性はほぼゼロだから笑えるよな。弁護士免許すら取れていないのに虚勢だけは物凄いから、そのギャップが笑えるよね 誰も聞いてもいないのに5ちゃんで自分の年収語り出す人は大体エアプ ID付きで源泉徴収票か課税証明書上げてと言うとアレコレ言い訳して出せないからw 世の中には頭が悪過ぎて、原典を読めず理解できず 初心者向け説明のユーザーサイドの説明しか理解できないまま それを原典定義だと思い込んで虚勢を張る落ちこぼれが 一定数居るよね >IT分野の最高峰の一つGreen500でトップを記録した人は >医師免許を取った上でMRI動画技術の実用化してシリコンバレーでベンチャービジネスを成功させ、その次の仕事としてGreen500トップだから、そのレベルならITと医師免許の両立が意味を持つね こういう話を引き合いに出してる本人も現実では取るに足らない凡人なわけで、そんな他人の褌で相撲取るようなせこいことすんなって。 >>408 落ちこぼれ物理の基本年収は、職場規則の職位等級別基本給与表として公開されているから、その方面で虚勢を張る人に釘を刺す意味で話題に出しただけ。 >>410 地元出身で、その派生仕事への関与を検討した案件だから話題に出すわなぁ あのメーカーのコアの人は、スピンアウトして某所に居るよね ゴードンベル賞7回受賞の人ももともと協力体制を構築していたらしくて、事後対応が大変そうだった コンピュータの仕組みなんて何十年もほとんど変わってないのに、 ガワの部分だけをいろいろ変えて、いかにも画期的な新技術みたいに言ってるだけなんだよな。 >>403 初めて合うのに前回の議論と言われても何のことかわからない せめてマナーとして引用くらい示せないのかね? >> Rustの言語仕様におけるHeap領域にアロケートされる変数のライフサイクル 妙な表現をしているな Heap領域にアロケートされるのは値であって変数ではない さらに変数に入るのはその値自体ではない 例えばT型をBoxによりヒープ領域で確保しても変数はT型にならずBox<T>型になる つまり変数はヒープ領域を管理する一種のスマートポインタとなる さらに「変数のライフサイクル」というのも妙な視点だな 変数は値が他へムーブされるとライフは終わり 一方で値はムーブされて生き残るのだから正解は「値のライフサイクル」だ 変数のスコープが尽きると変数のライフは終わり ただしスコープが尽きた時に変数の値に対してその型のデストラクタDrop::dropが呼ばれそこで処理される ApacheやNGIXの負荷試験すら出来ねぇくせにWebデザイナーとかほざいてるチンカス大杉 >>407 英語を読めていないのは君だ それはversion1.25つまり5年前の古いドキュメント 最新のドキュメントはもちろんRust公式にちきんとあるのに見つけられなかったのかねw >>415 悲惨な妄想長文は天羽の特徴と共通してるな。 Rust言語の変数オブジェクトの型まで示しながら 値オブジェクトがIT一般用語としての定数/変数に相当している事を誤魔化して それがStack領域もしくはHeap領域に取られるという 単純な話を長々と説明しているだけ。 そんなん言語開発者は50〜60年前からやってる常識なのにバカだなぁ >>417 論点ずらし乙。Rust言語の変数(コンテナとしての変数オブジェクトと値オブジェクトの組)には Stack領域に取られる物とHeap領域に取られる物がある という当たり前の説明をスルーしてversion議論で必死になるという事は、新バージョンでは説明が変わったと主張したいのかなw 差分出してみろよ、そしたら素人のお前にアドバイスしてやるから 結局天羽は基本的に実経験ではなく文字ベースの知識しかなく、 しかも難読症と英文不得意で、具体的な引用に基づく議論が一切できないから、学生からもバカにされてるんだよな。 物理の実験系で、知識が文字ベースのうろ覚えだけとか最悪最低パターンやん 昔の2chで、ERPコンサルタントを「パラメータ設定屋」と揶揄してる人がいたけど、 日本のIT関係者ってみんなそんなもんだと思う。 メーカーの研究職とかで基盤技術作ってるような人たちは別だと思うけどね。 >>109 その拘りってそんなに意味あるんかね? どうせそんなんコンパイル後のコードは同じ結果やろ?笑 ◾妙な表現と自覚していて草生える > 妙な表現をしているな > Heap領域にアロケートされるのは値であって変数ではない > さらに変数に入るのはその値自体ではない > 例えばT型をBoxによりヒープ領域で確保しても変数はT型にならずBox<T>型になる > つまり変数はヒープ領域を管理する一種のスマートポインタとなる 下の図を書けば一発で終わる話を 文章で丸暗記する人って頭が悪いね。 しかも元々の話は、 変数オブジェクトと値オブジェクトを 別に取る実装詳細など言及しておらず Heap領域に取る変数の話だから反論にすらなっていない。 もともと言語系の基本知識が無くてRust言語仕様だけ 丸暗記したから、反論にならない反論を蘊蓄してしまう 幼稚園児のような仕草だね★ Heap領域 Heap領域 ↓ ↓ Box<T>型変数 →(smart pointer)→ 値オブジェクト =Heap変数 =Heapオブジェクト ◾こっちは幼稚な詭弁 > さらに「変数のライフサイクル」というのも妙な視点だな > 変数は値が他へムーブされるとライフは終わり > 一方で値はムーブされて生き残るのだから正解は「値のライフサイクル」だ > 変数のスコープが尽きると変数のライフは終わり > ただしスコープが尽きた時に変数の値に対してその型のデストラクタDrop::dropが呼ばれそこで処理される ・「変数は値が他へムーブされるとライフは終わり」 ・「変数のスコープが尽きると変数のライフは終わり」 これがRust言語の「変数のライフサイクル」の特徴 >>384 公式のリファレンス読みづらいし作業の流れや理由があまり載ってないからな インフラとかもRFCとか読んで理解するより本か動画見た方がわかりやすいでしょ?それと同じ 天羽の話が毎回混乱の極みになるのは 専門分野の基礎知識の蓄積がないまま 特定対象の知識だけ丸暗記して 天羽の中では「それは一番優れた知識だから 既存の基礎知識とは違う筈だマウント取れる筈だ」 となって虚勢を張るんだけど 客観的に見ると 大昔(50〜60年前)からある基本技術の応用に過ぎず 仕様選択の組み合わせ以外に大した新規性は無く 世の中の言語仕様としても最新ではなく よりラジカルに攻めた言語が既に存在する から一発で反論が終わっちゃうんだよね 天羽のもう一つの問題点は終わった話を何年間も蒸し返して 虚言を強弁する悪癖。 前項だけなら頭の悪い人でおしまいなのだけど 蒸し返し強弁癖で赤の他人の時間を浪費して回る迷惑行為が 顕著だから、学部長通報せざるを得なくなる >>419 ほら、Rustの基本を理解していないからそういう大きな間違いをする Rustの変数は全てスタック領域(最適化でレジスタになるものを含む)にある ヒープ領域に変数はない 必ずスタック領域にある変数が、スマートポインタ等になって、ヒープ領域を指しそして管轄する 変数はヒープ領域にはなく必ずスタック領域にあり、変数が宣言されている関数スコープを含むブロックスコープが尽きると、 その値がスマートポインタ等である場合は管轄するヒープ領域を解放する もちろん変数のスコープが尽きる前にムーブすれば、ムーブ先で値は生き残る これらの基礎的なところから理解できていないのは、理解力に相当問題があると思われる 天羽の繰り言(ここでは>>428 )は天羽の劣悪な知性で解釈した妄想話に過ぎず、仮に参考文献と該当部引用付けたら一発で妄想とバレるから事は15年前2008年段階で判明済み。 これ以上蒸し返し議論をするなら ・山形大学理学部長 ・山形大学小白川キャンパス長 ・山形大学長 ・文部科学省 ・法務省 に山形大学職員の超長期ストーキング案件の再発として 迷惑通報をして措置入院の話を勧める事にする。 基礎も学んでいない天羽の分際で虚勢を張るなキチガイジ まぁ暗号資産全盛期にFIREできてないプログラマは底辺しかいないってのはガチだと思う 俺の周りの優秀なエンジニアは元手数百~数千万を5億以上にして納税してFIRE FIRE後はインデックスファンドに投資してトリニティスタディの4%取り崩しルールで生活してる人ばかりよ 天羽はHeapとStackの使い分けを実体験として理解しておらず ・Heap領域は悪者なので撲滅しなければならない ・Stack領域は呼び出しスコープで自動開放されるから安全 という雑な区別で妄想を延々と書く精神異常者 そもそも呼び出しスコープの外側からも大域的に見える値を 全てスタックフレーム上で管理しようとしたら スタック領域を別個に取るmulti thread上では スタックフレームの生き死にを判別して スタックのチェーンを辿ってスタック変数を参照する事も 困難になり、言語処理系自体のmulti thread対応が 不可能になる事を理解できないから 天羽の幼稚な妄想が止まらないんだろうね。 このレベルの人は学部専門課程実習のスタックアーキテクチャの言語実装実習からやり直さないと使い物にならないし、学位を取るのは無理 東大の学部だと物理系でも希望者限定で 言語実装実習くらいやった年があったように記憶するけど 天羽の学部は千葉大だから、物理系で情報系実習に参加するのはハードルがあったんだろうな。 駅弁大は分野超えて勉強したがる奴は少数派だろうし >>430 そうなんだ そのエンジニアはどこでどういう仕事してたの? 化学系だと 1980年代末のざべ誌上でUCBの教員やってた人が 計算化学のフレームワーク作りや そっから一歩踏み込んでドメイン特化型スクリプト言語を作ろうみたいな話しを連載コラムでやっていて 具体的な話は出ないんだけど計算化学関連分野の雰囲気的な話はさんざんしていて、あれ読んだ世代なら1980年代末時点で言語処理系実装に手を出す人も居ただろうな。 物理系だと 量子色力学(QCD)のファインマンが、QCDの膨大な式処理のために数式処理系の構築を提案して、そっから有名な数式処理系になったりとその処理言語が登場したり、理論計算機科学の講義をして教科書になったり、しまいには超並列マシンのノード間通信のトポロジー設計までやらかしているから、物理のスキルとして計算機科学全般に手を出すのはデフォだよな 1980年代時点で、スパコンのメインユーザーが物理系/工学系だったのも強いよな。化学系でスパコン駆使した計算が流行ったのは第一原理的な計算化学以降なのかな。 >>432 冒頭補足 > そもそも呼び出しスコープの外側からも大域的に見える値を > 全てスタックフレーム上で管理しようとしたら ↓ そもそも呼び出しスコープの外側からも大域的に見える値を(←仮にHeap上に確保) 全てスタックフレーム上で管理(値の管理≒スタック変数によるsmart pointer的参照等)しようとしたら ※まあ普通の頭脳があったら推察できるけど 今回相手は無知なキチガイジなので補足 >>432 そこまで無知だとはエアプログラマー確定だな Rustはマルチスレッドでも安全にメモリ共有できるようにSendとSyncの型毎の可否により静的な型検査で安全性を保証できるようになっている マルチスレッドでスレッド毎にスタックが当然別であっても各スタック上の変数で共有管理できる Arc<Mutex<T>>などRustでスレッド間共有すれば使われるものすら知らないとは驚いた プログラミング経験ゼロかね? ほらな いつも通りになった レスバトル好きなやつだけ残って延々と噛み合わない不毛なレスの押収だけが残る >>426 机上の知識しか追わない人には理解不能だろうけど 物理もITも実体験や実務と実証的検証が重要。 RFCとかW3C文書は、準業界標準規格のように言及される事があるけれど実態は理論ではなく実務家の仕様メモだから 対応済みでも未対応でも実物を触って振る舞いや問題点を把握した上で、RFCやW3C文書を開けばスルスル理解できる(一定以上の知性は必要) 実体験のロクにない人がRFCを読んでしまうのはただの耳年増にしかならず、見当違いな虚言でトラブルを起こす程度のゴミにしかなれない(大成しょうがない) ChatGPTを筆頭とするジェネレーティブなソフトウェアが進歩してくると 割と低レベルな部分でもバチーンと聞くだけで大体出来るようになる時代になるからなぁ Chat GPTは今のところ、こっちの質問に答えるだけだから Chat GPTが「ここの実装はどうしますか?」「この変数のライフタイムはどれくらいを想定してます?」とか そういう質問をするようになってからじゃないと、まだまだ実務で足りないかな 今のところは検索の手間を省くというだけ >>440 山形大学理学部長への通報確定だな お前は基礎が完璧に欠落しているから 言語処理系のマルチストレッド対応実装という 大域的なデザインの話と マルチスレッド使用文脈の局所的安全性を扱う スレッド安全性の話 の区別ができていない マルチスレッドなんて ①命令実行点の並列化 ②スタックの並列化 で実装できるからマルチスレッドカーネルを学生実習で作らせるべきだよね。 (1)言語処理系毎の実装可否は処理系実装と①②のセマンティックギャップの解決が必須 (2)スレッド安全性はもっと局所的な特定コードと①②の矛盾解決の話 >>432 は(1)の話 >>440 は(2)の話 両者を区別できずに混同して何年間もゴネて 迷惑行為で職場通報されるのは天羽の人生 天羽の場合はマルチスレッドカーネルとマルチスレッド応用プログラミングの区別もついてないだろうな。 マルチスレッドカーネルというのは、OS本体ではなく スケジューラー部分をライブラリもしくはコードとして切り出した物。タイマー駆動で定期的にスレッドを切り替える方法と、協調動作で明示的に譲り合う方法があって、機構/テクニック的には後者の方がシンプルなもののアプリ実装や性能は前者の方が有利なので、タイマー関数かPOSIXにたぶんあるSIGLRMかなんか使って割り込み駆動にするのが定番。 日本だと1980年代前半のASCII誌が前者、Prolog KR本が後者の実装コードを出していた まあ天羽の話が基礎の欠落で混乱しまくって、知ったか知識の継ぎはぎで大惨事になるのは 非平衡統計熱力学の未解決問題を 平衡しか扱わない古典熱力学で否定して大騒ぎした時からお馴染み 実名であれだけ混乱した言動をして、 その分野が専門領域ですらない雪氷学会全体を敵に回してしまう 2008年天羽の言動は狂人というしかないと当時認識した 直後に判明した滑稽話も強烈だったな。 天羽が非平衡統計熱力学の未解明現象を親の仇のように叩いて 雪氷学会に大迷惑をかけているから 天羽の後見人もとい保護者相当の菊池誠氏や、彼に現研究室を与えた阪大元学長(物理学者)はどういうつもりでこの混乱を放置しているのかと調べてみたら… 阪大元学長(物理学者)氏は、その未解明現象の存在を認めて今後の科学の課題として、長年放置された未解明現象の解明も必要だと言ってたんだよね。孫弟子相当な天羽をなんとかしろよと思ったわ まあ天羽の頭のお粗末さは ・頭の中に物理モデルや数式モデルを作り上げる事ができない ・全てを自然言語の記述で理解しようとするが 日本語、英語の読解能力が極めて低い ・結果的に物事の全体像を把握する事ができない 頭の容量や処理能力に問題があり 全体像を把握して頭に入れる習慣がない ・自身の無理解で生じた矛盾を自らの問題だと認めず 赤の他人に責任転嫁して無能を誤魔化す ・知らない話(無知の知)を認める事ができず 全否定の罵倒を始める こんなのに学位を与える方がおかしい お茶の富永はこの狂人を10年近くどうハンドルしていたのかも謎だよな 普通の神経をしていたら、ここまで知能の低い人間に10年間付きまとわれたら知性と神経が壊れるだろ >>446 そんな大昔の知識のまま時間停止しているのは哀れすぎる 今は単なる並列プログラミングではなく並行並列プログラミングの時代 RustのtokioでもGoでも並行並列スケジューリングされているからこそWebにも相性が良い 通信待ちしてる間に一つのスレッド上で複数の軽いタスクが非同期に並行に大量に無数に動いている それを最大CPUコア数分のマルチスレッド間でのタスク移動(タスクスティーリング)による負荷分散までスケジューラが担当 これが最先端プログラミング言語における最先端の並行並列環境であり Rustによる並行並列プログラミングはasync/awaitやチャネルなども当然対応していて可読性がありつつ最大限の能力を引き出せる >>440 というわけで お前は ・言語処理系のマルチスレッド実装における>>428 の難点を432が指摘した事すら理解できずに ・マルチスレッドとは、スレッドスケジューリングによるコンテキストスイッチの問題である事も理解できず ・スレッド安全性という一種の排他制御的制約条件の問題を マルチスレッドだと思い込んでいる幼児でしかないね 学部生でもここまで無知蒙昧な放言をする奴は居ない 勘違いして孤立した落ちこぼれ高校生でも精神に異常を来さないと、ここまで無知蒙昧な発言は恥ずかしくてできないよね >>452 それ1990年代前半に皆がやってる仕事だよ 自分の場合は国内並列スパコン導入と某基礎研の並列計算言語導入と並行して マルチスレッドベースのWeb用フレームワーク開発をして、普通にマルチスレッド言語を使ってたなぁ 結局天羽は、マルチスレッドとは何かを理解していないから マルチスレッドカーネルの説明をされても何一つ理解できず 「マルチスレッド安全性」のキーワードん唱えればわかったフリができると思い込んでいる1990年代前半に淘汰された頭の悪い人レベルの議論しかできていない。 ここまで頭の悪い粘着癖のある気狂いを高等教育期間に23年間も飼っておくのは、国家財政の無駄遣いに留まらず、高等教育機関を疲弊させる犯罪行為だろ >>452 のボキャブラリーの古さを見ると 1990年代半ば、Webアプリマルチスレッドで動くのが当たり前になった時代に落ちこぼれてしまった前世紀の異物だな その時代を知らない若い初心者なら騙せるだろうけど その時代から最先端に居た人たちには「その面白みのない書き込みはナウなヤングのハートにグッドな懐古書き込みかよ!」って突っ込まれるわな 基礎がないのに知ったかぶる人は 基礎知識を「古い否定された知識」だと思い込んで否定したり その割に30年前レベルの常識的設計を「最先端」だと強弁したり 知識空間や時空間の認識全体がカオス状態で精神病の臭いが濃厚にするよね 天羽にレスをつけても知能の低い特有のカオス状態の話しか出てこないから時間の無駄だよ 学生も皆それを知っているから、指導教官として選ばない >>454 ほら理解できていない それは単なるマルチスレッドであり並列 RustのtokioやGoがやっているのはスレッド上に無数の軽量タスク(Goでの名称はGoルーチン)を動かす並行 こんな初心者でも区別できる基本概念を知らないとはビックリだ >>458 そういう概念を考えたのも外国の人で、日本人はそれを拝借するだけなんだよな。 フロントエンドの者だけど、逆にバックエンドってググっても答え出ないの? 技術系のことはなんでも答え乗ってるわ 未知のバグは世界の誰かが対処してる >>442 ん? だから実務に取り掛かるために実践的に流れや理由も噛み砕いて説明してくれてる本を先に読もうするのは当然だよね?って言ってるんだけど >>459 ただの組み立て屋でしかないからね。日本のITエンジニア(笑)はww 自分じゃ何一つ、世界で通じるようなものを出せていない。 リファレンス読んで書くだけ。 研究職と実務は分けた方がいいとは思った 与えられた工数で客が求めるものを作りこむのがシステムエンジニア サービスを新たに創造するのはどちらかというと研究職かな? システムエンジニアは枯れた技術の方を好むよね 確実に動くから ググるどころかChatGPTにざっくりやりたいこと日本語で伝えると90点のコードが返ってくるからそれを手直しするだけ >>465 うちの会社はChat GPT使うの禁止なんだよな 頭堅くて嫌になる >>469 そんなに日本ホルホルしたいなら勝手に一人でやってろよw >>465 >>467 ネタだろうがいまだに使い門にならないレベルのChatGDT使いたいのにーとかいってるこんなバカが技術者界隈に存在できるのが日本の技術職 救いようがないレベルの低さ 問1: 2022年から話題のOpen AI社のAIプロダクトと言えば? 1. ChatGDT 2. ChatGPT 3. Rust 4. Ruby 5. TRON >>473 質問を的確にすればちゃんとした答えが帰って来るよ とくに公式リファレンスにある情報を忘れた時や探すのがめんどいときに便利だよ 使い方の問題だよ 使ったことある? >>474 Chat GPTに聞いてみた 問題をありがとうございます。Open AI社のAIプロダクトについて調べてみました。 2022年に話題になったものとしては、画像生成AIのDALL・E 2や対話AIのChatGPTがあります。 RustやRubyはプログラミング言語で、Open AI社のプロダクトではありません。 TRONは映画や仮想通貨の名前です。 したがって、正解は2. ChatGPTです。 TRON知らないらしい。 CHAT GPTは反日か!? >>479 (ワッチョイ f78f-STDj) このID見覚えあると思ったら、グロ画像スクリプト貼りまくってた奴じゃね? >>479 言葉のあやは匠な表現に使う慣用句なんだが >>480 ガイジ web系エンジニアの女子と付き合ってたけどめっちゃ美女だったわ あと当然のようにオタク オタ気質じゃないと周りとやってけないみたいね >>481 お前ニュー速でもIT関連のスレに連投しまくる大阪だか京都だかの自称組み込み系のじじいじゃね。スクリプト使った荒らしもしてたのかよ >>484 あんなうざいキチガイがそう何人もいるとは思えんなぁ。文体もよう似てる >>485 お前そもそも誰で、俺とどこでやりとして、このスレのどのレスでそう思ったの 判断材料どのくらいあって言ってるのかもわからんので、具体的にどの辺がそうなのか お前が嫌いな奴のレス引っ張ってきて比較してみてくれよ >>487 そうなんだ お前とやりとりしてないのに急に第三者の名前出されてびっくりしたけど 頭が悪い人なんだね 俺は嫌儲以外のニュース板行かないよ ネトウヨ多そうだし >>488 とりあえず一つのスレに嬉々としてたくさん書き込むやつはウザイと気づきましょうね >>480 お前が絡んできた時点で、俺より、俺がレスしてる相手のワッチョイ 57a2-t0clnのほうがレス数多い ガイジのお気持ちで絡んでくるのやめてくださいね >>491 絡んでないよw >>479 に話しかけたんだよw >>480 別スレの別人だがスクリプトとワッチョイ被ってる連中が居て紛らわしかったぜ たまに被るらしいなアレ >>77 趣味の日曜プログラマー以下じゃん やらないんじゃなくてできないだけだろ Github copilot使ったらもうめちゃ楽だぞ あれを業務で使わせてくれる企業あるの? 勝手にGit Hubのコード学習してきた前科があるのに 自分のコードが読まれないと信用できなくない? まあフロントエンドには重要な定数とか持たせないから、問題ないんか >>458 Rustを宣伝しているのはお前であって お前の宣伝文句を他人に理解しろ、は知恵遅れ仕草だよね 一つのスレッドの中でスタック共通のまま実行点(軽量タスク)を複数持つ場合、それらのタスクは個別スタックを持たないので スタック経由のルーチン呼び出しはできず、インライン形式に展開して実行する事になる。別に新しくもなんともない話だね。 そもそも元々の話は 変数-値ペアのメモリーアロケーションについて スタックのスコープと一致しない継続期間を持つ物を どうするかという話で お前の説明は前回、言語仕様の引用で論破されているので 天羽もどきの蒸し返しを何度繰り返してもお前の敗北は くつかえせない 基礎の基礎がない天羽レベルの統失が発言する時は 常に言語仕様の原文引用をした上で それをどう解釈して妄想を持つに至ったのか 逐一自己説明しない限り、気狂いの妄想の原因を 特定できる人は誰も居ないよ。 そして天羽レベルの統失の妄言の原因は 英文読解力や日本語読解力の劣悪さに起因して 意味が正反対な誤訳や超訳をしている事は ゴードンベル賞7回受賞の物理学者も2017年頃に指摘している まずは言語仕様のどの部分を読んで 何を理解しどのように解釈して 妄想を持つに至ったのか説明を書いてみろ 気狂い>>458 が言語仕様の該当部を探し出すまで 簡単に状況を調べてみよう…ってOSではなくtokioランタイムで管理されるgreen-threadだと明確書いてあるよね 458:番組の途中ですがアフィサイトへの転載は禁止です (ワントンキン MMcf-U5SI):2023/07/09(日) 12:10:17.25 ID:iMJKIh1SM >>454 ほら理解できていない それは単なるマルチスレッドであり並列 RustのtokioやGoがやっているのは スレッド上に無数の軽量タスク(Goでの名称はGoルーチン) を動かす並行 こんな初心者でも区別できる基本概念を知らないとは ビックリだ >>458 「スレッド上に無数の軽量タスク(Goでの名称はGoルーチン)を動かす並行」という説明は見当たらないね さーて、>>458 は上記引用部のような妄想を どの言語仕様説明を読み違えて妄想したのか ちゃんと説明しない限り、職場通報だぞ https://docs.rs/tokio/latest/tokio/task/index.html Module tokio::task source · [−] Asynchronous green-threads. What are Tasks? A task is a light weight, non-blocking unit of execution. A task is similar to an OS thread, but rather than being managed by the OS scheduler, they are managed by the Tokio runtime. Another name for this general pattern is green threads. If you are familiar with Go’s goroutines, Kotlin’s coroutines, or Erlang’s processes, you can think of Tokio’s tasks as something similar. … Google翻訳による自動翻訳 https://docs-rs.translate.goog/tokio/latest/tokio/task/index.html?_x_tr_sl=en&_x_tr_tl=ja&_x_tr_hl=ja&_x_tr_pto=wapp (下記はdeepLによる冒頭訳) モジュール tokio::task ソース 非同期のグリーンスレッド タスクは軽量でノンブロッキングの実行単位である。タスクはOSのスレッドに似ているが、OSのスケジューラによって管理されるのではなく、Tokioのランタイムによって管理される。この一般的なパターンの別の名前はグリーンスレッドです。Goのゴルーチン、Kotlinのコルーチン、Erlangのプロセスに馴染みがあれば、Tokioのタスクも似たようなものだと考えることができます。 >>497 copilot for Businessがあって、それで書いたコードは基本的に大丈夫って言われてる。 俺のいる企業もどんどん導入してる 個人向けはダメって言われてるね >>500 へえ、そうなんだ ありがとう うちも導入できればいいなあ 一般に ①プロセス=命令コード+Heap+Stack+実行点(通常1個) ②スレッド=プロセスに共生し個別の(Stack+実行点)を持つ とあって ②のタスク・スケジューリングをOSではなく自前で行うのがgreen-thread そこで②の中で実行点のみ複数に増やす、という拡張が Rust言語のmodule tokio::taskやGo言語のGoルーチンで行われている、と主張しているのが>>458 なので >>458 はそれの書かれている言語仕様もしくは言語拡張の 所在と該当部を示すのが義務。 参考文献を添えるという最低限の義務を果たさずに 妄言を続けるのであれば、それは天羽と同等な虚言だから 以降この主張をする人物は天羽2号と呼ぶ事にするよ ちなみに②の中で更に実行点を複数に増やす事は 言語側でスタック経由のルーチン呼び出しをしない Lisp言語では可能で、 1980年代前半Prolog KR本にもサンプルがある。 >>458 は長〜い自演スレッドを書いた末に死んだのか 反応がない=天羽2号確定だな 本かったら公式とほぼ同じような事しか書いてなくて草だった Rustに関しては、Stack変数のスコープを活用しているから Stackあり実行点(=スレッド)とは矛盾がないけれど 1Stack+複数実行点(=458の主張する軽量タスク) の中ではスタック経由のルーチン呼び出しやスタック変数の追加には難が生じる。 一般にスレッドのスタックは1本であっても その下で実行点のみ複数化した軽量タスクを作った場合 軽量タスクのスタック消費量を予測でき かつオーバーフローを検知/例外送出できる前提であれば allocaで軽量タスクタスク専用スタックを確保する事も可能だね でもそれは、(allocaで確保した専用スタック+実行点) つまりgreen-threadでしかない。 それ以外の方法として 言語の動作意味論としてはスタックモデルを使うけれど 実装にはOS/CPUネイティブのスタック管理は使わず 独自管理でスタックそっくりの挙動とその制限を超える挙動を 付加する方式を考えるなら、その種の実装は不可能ではないね Common Lispが言語仕様として、それまでのLispに存在した インタープリターとコンパイラの挙動の相違を無くす方向にして スタックモデルのC言語経由でコンパイルして高速実行可能にしながらも 非スタックモデルのインタープリターと同様な挙動も工夫すればシミュレーション可能で、 その場合、言語モデルとしてはスタックモデルを採用しながら ルーチン呼び出し等はスタック経由ならC言語ルーチンに展開でき スタックを経由しない場合はインタープリターモデルの方で実行 なんて形になっている。 まあこの件は>>458 がgreen-threadの概念を知らずに OS管理のスレッド(native-thread)の他に 独自管理のスレッド(green-thread)が動く事を RustやGoに特有のスーパー機能だと思い込んで 妄想を書いた可能性が高いね green-threadなんて1980年代頃からあって バイトコードVMを前提としたJava言語等のスレッドもソレだから JavaによるWebシステム構築が一般化した1990年代半ばから green-threadをガンガン使ってたわけだけどw >>458 がその誤解の元となった 言語仕様定義のソースと該当箇所を出してくるのを 気長に待ちましょうか。超笑える展開だ ITエンジニアである時点で~系とか関係ねーよ プログラミングを指定された事にしか使ってないって事は文章書いてるのと変わらんから エンジニアはただの文章入力してるだけみたいなもん。 読み書きできる奴が、面白い小説書けるわけじゃないだろ 面白い小説をかける奴だけが小説家になれる プログラミングで新しい物を創造できない奴は一生エンジニア、クリエイターにはなれない😏 エンジニアはただの労働者 クリエイターは発明家の類 >>458 がなぜ、そのような基礎の欠落した妄想強弁をするのかは大きな謎だね 嫌儲でその種の悪い振る舞いが顕著な人物は 理系諸分野とIT系では 滋賀県長浜市出身で山形県山形市在住の嫌儲統失婆56歳 しか居ない。 この人物も>>458 と同様に、参考文献無しに強弁をしては 何週間も同じ妄想話を蒸し返す癖があって 2017年に他の問題(有名人相手な親告罪訴訟恫喝=恐喝) と合わせて、山形大学理学部長(現学長)に迷惑通報 する流れとなった。 >>458 が同じ人物であれば山形大学への再通報が必要になるね >>509 顔文字天羽はなぜ顔文字を添えて妄想ベースの罵詈雑言を毎日書くんだよ 温度や湿度が高い日や天候が急変した日に毎回重大トラブルを起こして職場通報騒ぎになる己の人生の虚しさと、真剣に向き合って解決した方がいいぞ 60過ぎてそれ繰り返したら若年性認知症が一気に進んで、刑事犯罪で逮捕される騒ぎになるぞ 今年7月8日に新たな黒歴史が加わったな 2022年7月8日下痢便死亡w 2023年7月8日1980年代登場のGreen Threadを2023年まで知らずに、Rust tokio::taskやGo言語に固有の拡張機能だと強弁 →現実には1995年Java言語登場で90年代半ば以降一般化した機能でしたーw 嫌儲統失婆の虚言はなんでいつも 30年以上前に一般社会で確立済みの基礎知識が欠落した状態で強弁するの?ってのもあるよね 今の職場はまだ23年目だから 今のところ職場に関する虚言は出てこないようだけど あと7年もしたら猛烈な知恵遅れ虚言を強弁して 懲戒免職まで行くだろうな ググればわかるものを内製しないで外注するからクソ仕事なんやぞ(´・ω・`) もっと根本的に >>446 で名前を明示せずにgreen threadの説明が出て その意味がわからずに逆上して >>455 でそんなの古い最新はこれだと言って出してきた Rustのtokio::taskもドキュメントぺーじを見ると「green thread」と書かれているのが、この人の頭の悪さの象徴だね ・446の説明がgreen threadだとわからない のは、この人物の言動の広範に観察されている 「基礎の欠落」だからしょうがない ・455が、446を「古い」と称して出してきたモジュールが green threadに過ぎず 455でクドクドと書いた蘊蓄のソースを一切出せない のは虚言癖だね。446もRustのtokio::taskも 単なるgreen threadだから、説明をよく読めば 同じ物に関する説明だとわかるのが当然なのに 虚勢を張ってクドクドと、同じものを違うと強弁したのが455 虚言癖は精神の病気だから専門病院で治療するしかないだろw アンカー間違えたから訂正 もっと根本的に >>446 で名前を明示せずにgreen threadの説明が出て その意味がわからずに逆上して >>452 でそんなの古い最新はこれだと言って出してきた Rustのtokio::taskもドキュメントぺーじを見ると「green thread」と書かれているのが、この人の頭の悪さの象徴だね ・446の説明がgreen threadだとわからない のは、この人物の言動の広範に観察されている 「基礎の欠落」だからしょうがない ・452が、446を「古い」と称して出してきたモジュールが green threadに過ぎず 452でクドクドと書いた蘊蓄のソースを一切出せない のは虚言癖だね。446もRustのtokio::taskも 単なるgreen threadだから、説明をよく読めば 同じ物に関する説明だとわかるのが当然なのに 虚勢を張ってクドクドと、同じものを違うと強弁したのが452 虚言癖は精神の病気だから専門病院で治療するしかないだろw 虚言の幼稚さ、一瞬で虚言のバレる頭の悪さは 嫌儲統失婆の特徴と共通しているね 非平衡統計熱力学の未解決問題の時も同じ。 問題の定式化ができずに 平衡熱力学を振り回して嘘だ偽科学だと喚いていたけど 非平衡問題に平衡問題の常識をぶつけるのは気狂いそのもので でもこの人はその手の気狂い発言をして 誰にも相手にされないゴミクズポジションに逃げ込んで 己の知能の低さを誤魔化し続けてきたんだなって可哀想な気持ちになった でも、最低限のインタラクションのある 富永、菊池、田崎、野尻や同人の人 研究室や講義で否応なしに接点のできる学生や同僚のひと は大変だよね。 議論のたびに虚言を強弁して他人の時間を無駄遣いし、 こいつの主張は虚言だと結論が出ても 同じ話を毎日でも蒸し返して 構って乞食を数年〜数十年も継続する。 こいつ自身、他人と向き合う知能も自信もないから 虚言を重ねて狂人ポジションに逃げ込む なら職場を辞めて山奥で1人で暮らせばいいのにね リモートワークで済ませる時代になったんだから 人間嫌いの虚言癖はリモートで仕事をしているフリをして 山の強烈な日差しで日干しになれば効率的なのに 職場に行かなければ皆がハッピーでwin-winなのに 頭が悪いね >>508 また盛大な勘違いをして無知を曝け出しているな グリーンスレッドとは非OSスレッドの意味しかない グリーンスレッドの方式と実装方法は様々なものがあることを理解できずに 昔あったグリーンスレッドのイメージのまま時代遅れの思い込みをしていることを自覚しなさい こちらが以前示したようにGoやRustで行われているのはこの方式 >>452 >> マルチスレッド間でのタスク移動(タスクスティーリング)による負荷分散までスケジューラが担当 >> これが最先端プログラミング言語における最先端の並行並列環境 さらに実装方法はGoとRustで真逆の方法をとっている Goでは無数に生成するGoルーチン毎に個別の専用スタックを持っている そのおかげで負荷分散のためスケジューラがマルチスレッド間でGoルーチンを移動しても実行できる Rustでは無数に生成するタスクをステートマシン内蔵の対称コルーチンとして実装している つまりスケジューラに戻った時点でスタックレベルは同じ元に戻るため個別にスタックを持つ必要がない そのおかげで負荷分散のためスケジューラがマルチスレッド間でタスクを移動しても実行できる このようにRustとGoは真逆の実装方法をとっているものの 目的であるCPU性能を最大限に引き出すためのマルチスレッド間でのタスク(Goルーチン)移動方式を実現している つまり無数に生成されるタスク(Goルーチン)がスレッド上とスレッド間を並行かつ並列に自由自在に柔軟に実行される これによりWebなどの通信待ちが多発するタスクを無数に同時にCPUコアリソースを最大限に使い実行できるようになった >>519 お前の幼稚な勘違い長文は誰も興味がないから お前の妄想の根拠となる言語仕様ソースと該当部引用を出せ 知恵遅れ あと天羽が不得意そうな課題として 文章コピペで誤魔化している説明を 完全な図面にして提出しろ もしお前が天羽と同様な障害を抱えていたら >>519 に文章で長々と書いた内容の細緻な論理モデルを脳内に作れていない筈だから、図面も書けずに誤魔化す筈 ・言語仕様 ・該当部引用 ・>>519 説明内容の完璧な図示 以上三点が揃わない限り >>455 >>519の妄言内容などなど誰も気にしない 天羽は自信が無知蒙昧で中学数学ですら躓く惨状だから「勘違い」「無知」という単語を多用し過ぎ。 Rust tokio::taskが単なるgreen thread(タスクスケジューリングを自前で行うマルチスレッド)に過ぎないとする説明の事例は>>499 で提示済み 対する>>455 ,519は、基礎のない人部特有の 自身で内容を理解しないまま他人の話を適当に繋げた 図示すら不可能な文章を書き散らすだけで ソースと該当部引用を一度もしていない。 ソースを提示できない話を強弁するのは 虚言癖の症状なので専門医による治療が必須 天羽は無知蒙昧で中学数学ですら躓く惨状だから 「勘違い」「無知」という単語を多用し過ぎ。 Rust tokio::taskが 単なるgreen thread(タスクスケジューリングを自前で行うマルチスレッド) に過ぎないとする説明の事例は>>499 で提示済み 対する>>455 ,519は、基礎のない人部特有の 自身で内容を理解しないまま他人の話を適当に繋げた 図示不可能な文章を書き散らすだけで ソースと該当部引用を一度もしていない。 ソースを提示できない話を強弁するのは 虚言癖の症状なので専門医による治療が必須 >>520 言語仕様?? また基本的な区別がつかない無知な発言だな 言語仕様には当然それらGoルーチンやRustタスクの利用方法は書かれていてもその実装方法は書かれていない さらに今回説明したRustの並行並列スケジューラを有するtokioはRustのデファクトスタンダードに過ぎずRustの言語仕様にはもちろん出てこない 議論に加わりたいなら基本的な知識と常識を身ににつけよう 非常に古い役に立たない知識しかなく GoでもRustでもプログラムを書いたことがないエアプログラマーだそうだが 老害の自覚はあるかね? Green threadだろうとNative threadだろうと CPUのスタックポインターに割り当てるスタック領域は必須 そしてスレッド全般の必須要件として、各スレッドはそれ専用のスタックを持たせる必要性がある。 タスクスケジューラは、タイマー割り込みで通常一定時間毎に CPUコアに割り当てるスレッドを切り替えるルーチンで ただし競合問題を避ける為にmutex等を使う こんなん1980年代時点の基礎知識なのに このおばさんは21世紀にもなって先端技術だと思い込んで >>519 のような幼稚な説明を長々と書く 偏差四十九の底辺職場のひとの中でも最低ランクの人だね >>524 言語仕様に限らず、ソースが出せない時点でお前の負け。 相変わらず頭が悪過ぎて誰にも相手にされない気狂いだわこいつ >>519 がGreen Threadのタスクスケジューラのソースを読んで理解したつもりで必死に書いた文だと気付いた瞬間、爆笑したぞ そんなん他の人は30〜40年前に読んでるレベルの知識なのに コイツは日曜晩に何時間もかけて、読んだこともないソースを読んで日本語説明書いてたんだね この人大学に行ってないか、講義にも出なくて説明聞いてない落ちこぼれやん 落ちこぼれの万能感に満ちた幼稚な説明なんて 高校生レベルの知能しかないだろ いやー、ここまで頭の悪い人はこの分野でこの人しか見た事ないわ ふつー30〜40年前に通過してるもん っていうかこの調子で行くとこの人 OS側のスケジューラのソースも読んだ事ないんだろうな そんなん30年前には一般公開されて誰でも読んだり試したり改造できる状況になって、 同じく30年前には多ノード並列計算機用並列プリミティブも入手可能になって 20年前にはSMPやマルチコア対応のスケジューラも入手可能になって どう考えても20〜30年前のネタだよな それを2023年にもなってドヤ顔してるという事は この人の発達段階はZ世代とトントンだな どうもガキ臭えと思ったらガチの知能遅滞なんだな あと天羽の文章と共通点はもう一つあって 書いてる内容は30年前の基礎知識レベルで はっきり言って幼稚なのに 自信だけはやたら過剰で 学部生以下の知能でゴードンベル賞受賞者を小馬鹿にするような身の程知らずな負け犬の遠吠えをするところが 天羽そっくり 気狂い本人的にはID変えてキャラ変えて分野変えたら 別人格になれると思い込んでいるんだろうけど どんなに誤魔化しても頭の悪さは変わらないから すぐ個体識別できるよね >>525 またまた無知を曝け出していますね~ >> Green threadだろうと >> スレッド全般の必須要件として、各スレッドはそれ専用のスタックを持たせる必要性がある。 いいえ不要です とても古い知識にある過去のGreen threadに専用スタックを持つものがあっただけですね しかしGreen threadであるRustのタスクはステートマシン内蔵の対称コルーチンとして実装していますので個別の専用スタックを持ちませんし必要としません それ以降の文章も過去の特定のGreen threadではそういう制限のあるものがあったというだけであり Green threadであるRustのタスクには全く該当しません つまりあなたの知識が古すぎるのと理解力に乏しいことが確定しました ゴードンベル賞7回受賞の人も 天羽のバカさ加減を確認する為に議論をした時 その愚かさが底なし沼のように底がないのに気付いた時は ビックリしただろうな 科学の真偽はどうやって決まるか、という問題設定に対して 天羽の答えは「権威が真偽を決める」 そりゃゴードンベル賞受賞じゃ氏もブチ切れですよ。 「この人物へ科学者/研究者ではない」 と結論したのは当然だわ >>530 がソース無しで妄想を書いている事は前回判明済み。 前回はHeap領域に取る変数-値の組みのライフサイクル(ITの一般用語)について、辻褄の合わないデタラメを書いてきたので 言語仕様に基づく説明を書いて決着 後から第三者が来て判定して、 こちらが書いた言語仕様に基づく説明が妥当である事を確認済み。 今回tokio::taskの話もソースを出せずに妄想を書いてるだけで それ高校生同士のハッタリ勝負なら互いにバカで勝つ事もあるんだろうけど ソースを出せない/客観的証拠も出せない/落ちこぼれ統失と同レベルのグダグダな妄想を書き並べる現状では、誰も相手にしないよね このタイプの人、別分野で見た事ある。 仕事の都合で某外資の元vipの人のところで 某外資マニアの人のお相手をした事が1〜2件あったんだけど。 片方は狂信者タイプ。崇め方が異常な点と程度が低い事を除けば割とノーマル、、 もう片方は統失タイプ。某外資製品と直接関係ない妄想に近い話を何週間も続けて、で、それが仕事の課題とどう関係あるのか尋ねると錯乱状態になって仕事が全く進まない困った人だった。 今回のスレで暴れているのも、基礎知識のない統失タイプだな。 関わっても時間の無駄にしかならないゴミクズ >>532 これで三度目ですが Rustのタスクはステートマシン内蔵の対称コルーチンとして実装と 具体的に教えてあげているのに調べる能力もないんですね可哀想に まさかと思いますがステートマシンや対称コルーチンといった基本的な知識を欠いているために理解できない? ならばまずそこから学習しましょう 個別にスタックを持たずに実現できることが理解できるはずです あなたが唯一理解している古いグリーンスレッドの実装方法とは全く異なることに気付けたら及第点です 知識をアップデートしたほうがいいですよ >>530 の誤解の原因は OSが割り当てたスタック領域以外は スタックと呼ばないかのような勘違いをしている点だろうね。 形式上Heap領域からmallocで取得したメモリ断片であっても それをスレッドのアクティベーション時にCPUのスタックポインターに割り当てたら、それは正真正銘のスタック領域。 別のケースとして、バイトコードVMでスタックを扱い その上でGreen Threadを動かす場合 VM上のスレッドがアクティベートされた時に、VMのスタックポインターに割り当てられる領域は、スタック領域。 >>530 の勘違いは、後者をスタックだと認識できず 「専用スタックを持たないスレッドが最新式だ〜」と称する妄想に入り込んでいるところだね。 専用スタック無しで実行点(インストラクションポインタ)だけ複数持つモデルは、一般にはスレッドと呼ばない筈だけど この人の妄想の中で、それには例外があると言うのなら つべこべ言い訳せずにそれが書かれた資料もしくはソースを出せ。 出せないならば、それは実態のない>>519 の妄想に過ぎない。 証明方法も判別方法も極めてシンプルたから、さっさとソース出せよw 天羽は常にソースが出せないからコイツそっくりだわ >>533 お前の話がデタラメなのは前回判明済みて、第三者の確認も入っているから お前の無能さは証明されている。 「お前の主張を裏付けるソースを出せ」 という要求に対して、 「ヒントわわ出したのに調べないお前が悪い」 という返しが通用するのは せいぜい中高生までだから さっさとソースを出せや こいつどう見ても中高生だね 高等教育機関(=大学)での知的訓練を受けていないから 自分の発言は自分で証明するという当たり前の事ができず ひたすら無能な言い訳をしているだけ。 未踏ユースにとんでもないバカな人が居て 全然関係ない人に絡んで回ってトラブルを起こしていたのを見た事があるけど、こいつもその同類の発達障害の中高性なんだろうな 社会経験の全く感じられない幼稚な話ばかりだ >>534 何度も説明している通り Rustのタスクはステートマシン内蔵の対称コルーチンとして実装しているため タスク個別の専用スタック領域を必要としません そのため利用リソースも少なく大量のタスクをCPUコア無駄なくマルチOSスレッド間を超えて自在にタスクをスケジューリングできています 一方であなたは知識を欠いたまま勝手な思い込みばかり主張していますね なぜ現実に動いているものさえ受け入れられないのですか 古い知識に囚われ間違った思い込みをしてそれを喚くだけの人になっていることに気付きましょう スタックと実行点の組をスレッドと呼ぶのは一般認識で スタックのメモリ内容と実行アドレスの組を複数用意して タイマー割り込みもしくは譲り合いで順次切り替えていくのが タスクスケジューラの仕事。 ここでスタックのメモリ内容と実行アドレスは、個々のスレッドの本体に相等し、スタックを入れ替えたら別のスレッドになってしまう。これがスレッド固有の専用スタックと言っている話の内容。 専用スタック無しで実行点だけ管理するモデルは、一般論としてスレッドとは呼ばない。 それ(専用スタックが存在しない実行点)を「スレッド」と呼ぶ事例があるなら、Rustの文脈でその公式文書なり慣例に関する合意が行われた文献/ソースを示しなさい。 そのソースが出せないのであれば、それは>>519 の脳内妄想に過ぎず誰も興味も関心もないので、ご自身の小汚いホムペの小汚いブログで妄想の続きをやってください。 >>537 ①Rust tokio::taskがGreen Threadに過ぎない という資料例 → >>499 でURLと該当部引用を提示済み ②専用スタックを持たないスレッドが存在する、と称する>>537 妄想を裏付ける資料/ソース → 再三の提出要請にも関わらず0件 資料の存在する①がおそらく正しいのは誰の目にも明らか。 資料の存在しない②は、おそらく>>537 の妄想に過ぎない事は誰の目にも明らか。 こんな当たり前の話でソース提出できずに 無能な押し問答を試みる>>537 の精神年齢は中高生程度 まあ未踏ユース以降、箸にも棒にもかかりそうにない無能な奴が 万能感に酔いしれてトラブルを起こす過程が可視化されるようになって、教育機関や企業によるアスペルガー物件のハンドリングも容易になって すると行き場を失った中高生が匿名掲示板で暴れちゃうんだろうね でもここ、嫌儲統失婆のようなガチの病人、ガチの廃人が6年間も暴れている場所だから、アスペルガー中高生なんて幼稚過ぎて誰も相手にしないよね もうちょっとコイツの対人スキルが上がったら、その妄想の勘違いの中から使える要素を拾い上げて、まともな道に戻してやる事もできるんだろうと思うけど、現状の幼稚さでは無理 >>538 え?そんな用語のところに戻るの?? ソースはあなたが自分自身で示しているのを忘れちゃった?? 以下はあなたがソースURLとともに示した書き込みです >>499 >> タスクは軽量でノンブロッキングの実行単位である。 >> タスクはOSのスレッドに似ているが、OSのスケジューラによって管理されるのではなく、Tokioのランタイムによって管理される。 >> この一般的なパターンの別の名前はグリーンスレッドです。 >> Goのゴルーチン、Kotlinのコルーチン、Erlangのプロセスに馴染みがあれば、Tokioのタスクも似たようなものだと考えることができます。 ぶちゃけ、文系以前に中卒や高卒でも出来る仕事やなにゃw(失笑 >>541 統失の目には、その文章が妄想の証明に見えるんだろうけど 健常者のIT研究開発者の目で見ると、tokio::taskはただのGreen Threadに過ぎず、それは >> Goのゴルーチン、Kotlinのコルーチン、Erlangのプロセス と似たような物と考える事ができる って書いてあるだけだぞ >>537 妄想の「独自スタックの無いスレッド」などという話はどこにも書かれていない。 結論: 「独自スタックの無いスレッド」は、ソースの存在しない>>537 妄想と確定。 やっぱり統失妄言タイプの人だったね。くっだらね >>47 個人的な経験だが自分で調べて仕事を進める奴はもともと大学で情報工学科とかのケースが多くて 他の分野から来た奴は人から教えてもらうのを待つだけで自発的に調べたりしないのが多い 例外もなくも無いけど >>543 それは認識ヤバいよ Rustのタスクは個別にスタック領域を持っていると妄想で思い込んでいるの? Rustのタスクはステートマシン内蔵の対称コルーチンだから個別スタック領域を必要としないわけだけど ステートマシン内蔵の対称コルーチンの意味を理解できてる?? もし理解できていたらタスク毎のスタック領域なんて必要ないのも理解できるよね? ついでにErlangのプロセスの話は自分の領域と関連あるので 2hopsの位置にいる言語開発者の人のところのErlangのプロセスの解説。 https://magazine.rubyist.net/articles/0056/0056-naruhodo_erlang_process.html 互いに独立して動いて、メッセージバッシングで通信する点は 並列計算機のノードに対応するイメージだね。 古くはPlasma言語とか国内だとABCLとか、 情報処理学会だとマルチエージェント研究会あたりと 相性が良さそうだけど、実使用例はEricsonかどっかだっけ これに限らずググれば出来るって言う人よくいるけど 実際にググって吟味して試行錯誤して出来ましたってやったらすぐ1日終わるからな 体系的に学んできちんと経験を積めば 何も考えず手癖で30分くらいでパパッと出来る事を いちいち1日以上かけてやるのは効率が悪くて話にならんのよ 基幹やってるけどフロントはすげえ馬鹿にしてる すまんな >>546 お前はさっきから同じ書き込みを繰り返しているだけで 認知症患者のような状態だぞ お前がソースすら出せない 無能な心身障害者である事は充分分かったから 今晩はしっかり眠って明日は朝イチで 山形大学医学部附属病院精神科の診察を受けろ お前とそっくりな患者のいる病院だから 治療法もある程度確立しているだろうよ 治療頑張れよ、お大事に https://www.erlang.org/about Erlang is a programming language originally developed at the Ericsson Computer Science Laboratory. OTP (Open Telecom Platform) is a collection of middleware and libraries in Erlang. Erlang/OTP has been battle tested in a number of Ericsson products for building robust fault-tolerant distributed applications, for example AXD301 (ATM switch). Main developer and maintainer is the Erlang/OTP unit at Ericsson. って事で、EricssonのCS研究所で開発されて OTPと呼ばれるプラットフォームと合わせて ATM switch AXD301という、まあインターネット普及前の プロトコルの機材開発に使われた、と。 雰囲気的には電話交換機的の次世代なATM通信機材だな >>551 ステートマシン内蔵の対称コルーチンが個別のスタック領域なんか必要ないことは自明 ソースを出せ!と主張するのはステートマシン内蔵の対称コルーチンを理解できていない証拠 どうしてもソースにこだわるならばこの実装方式でも個別のスタック領域が必要となることを示すソースを出してみたら? >>553 ソースを出さずに妄想を理解しろと要求するのは 精神異常者なので山形大学医学部附属病院精神科で精密検査してこい こいつ以前の議論で一目見て物凄い頭の悪い人だと理解したけど この粘着癖は嫌儲だと嫌儲統失婆本人だね いくらキャラを変えても頭の悪さは全く変わらないし ソースを出せずに逆質問して誤魔化そうとする所まで 嫌儲統失婆の完全コピー品だわ ゴミクズそのもの >>554 鏡を見なさい ソースを出さずに「個別スタック領域が必要となる!」と主張しているのはあなたですよ ステートマシン内蔵の対称コルーチンは個別スタック領域を必要としません ちなみに嫌儲統失婆の統合失調妄想症状はガチ 2008年には実名ブログで、読んでもいない英語論文のデタラメ説明を書いていたし 2017〜8年には論文誌の論文撤回手続きの邦訳と称して クリティカルな部分を妄想で書き換えた和訳をSNSに流して 例のゴードンベル賞7回受賞者に慇懃無礼にとっちめられていた 10年の時間を経ても虚言癖が治らないのはポンコツだね >>556 山形大学長に天羽優子の超長期ストーキング症状再発を伝える件は確定したから、さっさと寝て明日朝イチで精神科に行ってこい 天羽って次通報事案があったら懲戒免職なんでしょ ご愁傷様 https://people.cs.rutgers.edu/ ~pxk/416/notes/05-threads.html Threads Multiple flows of execution within a process Paul Krzyzanowski February 5, 2014 Multithreading Memory map with two threads Memory map with two threads A process may be multithreaded, where the same program contains multiple concurrent threads of execution. An operating system that supports multithreading has a scheduler that is responsible for preempting and scheduling all threads of all processes. In a multi-threaded process, all of the process’ threads share the same memory and open files. Within the shared memory, each thread gets its own stack. Each thread has its own instruction pointer and registers. Since the memory is shared, it is important to note that there is no memory protection among the threads in a process. --- [DeepL和訳] マルチスレッド プロセスはマルチスレッド化されることがあり、同じプログラムに複数の同時実行スレッドが含まれる。マルチスレッドをサポートするオペレーティング・システムには、すべてのプロセスのすべてのスレッドのプリエンプトとスケジューリングを担当するスケジューラがあります。 マルチスレッドプロセスでは、すべてのプロセスのスレッドが同じメモリを共有し、ファイルをオープンする。共有メモリ内では、各スレッドは独自のスタックを持つ。各スレッドは独自の命令ポインタとレジスタを持つ。メモリは共有されるので、プロセス内のスレッド間でメモリ保護がないことに注意することが重要である。 --- "each thread gets its own stack." 「各スレッドは独自のスタックを持つ。」 これマルチスレッドの基本常識だから、適当に定義を書いて検索すれば文献が出てくる類の常識問題だよね。 天羽や天羽2号は英作文できないから検索できなかったり キーワード検索して前後の文章を読まずに妄想を書くから 誤訳トラブルを起こす事は ゴードンベル賞受賞者が指摘済み。 ゴミムシに参考文献出してやっても意味ないね >>560 それはOSスレッドの説明 グリーンスレッドの説明ではない 両者の区別ができない人を初めて見た 暗黙の了解過ぎて触れなかったけど CPUのほぼ全レジスタの状態も スレッドの状態の構成要素だね プロセスやスレッドの切り替え(スケジューリング)の時に ほぼ全レジスタの内容をスタックにpushしたり 場合によってはスレッド情報オブジェクトにコピーして保存する のは、割り込み処理と同様な常識だからあえて触れなかった >>561 天羽2号は類推ができなくて Native ThreadとGreen Threadは 処理担当が違うだけで 本質的には同じ処理をする事が理解できないとは草 ねえ、お茶の冨永はこの薄らバカと どうやって10年間も折り合いを付けたのか 富永に訊いといてよ。世界の七不思議レベルの謎だわ >>563 個別スタック領域が必須なのはOSスレッド(ネイティブスレッド)のみ 自由自在に設計できるグリーンスレッドにそんな制約は当然ない 現実にRustのタスクは個別スタック領域を必要としないステートマシン内蔵の対称コルーチンで実装されている Native ThreadsとGreen Threadsの相違点は 生成/切り替え/終了を含むタスクスケジューリングを OS側で行うか/ライブラリ等OSの外側で行うかだから スレッド毎に(スタック、実行点、全レジスタ状態)の組 を持つ事には基本的に変わりないね。 それが違う例があると主張したいなら その具体例を示せ >>564 お前は同じ話を繰り返しているだけで 未だにその話のソースを示していない。 ソースのない妄言の誤りは前回指摘して 第三者も認めている話なので それ以降はお前は何か主張する時は必ず それを示すソースと該当部引用を提示する義務がある それができない天羽レベルの知恵遅れに用はまっ無いので 以降はレスを付けるな。 今週末しつこく付き纏っている件は山形大学長に迷惑通報する事が確定しているけどな お茶の富永や同人連中がコイツの妄想強弁癖を許したから ここまでポンコツでソースも出せない気狂いが出来上がったんだろうな ソースも出せない話を強弁して検証しない落ちこぼれに 哀れみの学位を出したら教育機関失格だよ 現にコイツの職場の同僚は充分過ぎる迷惑を被ってるよな >>565 具体例はRustのタスク 実装方法はステートマシン内蔵の対称コルーチン もちろん個別スタック領域は無しで最軽量の一つ 現実に動いて世界中で使われている もしかしてステートマシンやコルーチンといった基本概念を知らない? では現実を無視して個別スタック領域が不可欠なことを証明してみたら? >>564 あと、お前の日本語は自動翻訳のように曖昧で単語レベルで問題を抱えている事が前回判明済みだから まずはそのもの妄想主張を英語の専門用語で書け。 それが書けないようなら、お前の話は誰にも通用しないぞ まあ気狂いの妄想の英文訳は無理だろうけどね >>568 まずは説明を英文で書け。 次に、その英文の根拠となる文献と該当箇所を示せ。 そんな簡単な事もせずに、一般論ではなく特殊解に近い実装を主張してもバカの妄想にしか見えないぞ。 お前がバカである事は前回議論で判明済みで、第三者もそれを確認済みだから、お前が馬鹿のまま消滅する事を誰も気に留めないけどな >>570 その、日本語は認めない!という書き込みは事実上の敗北宣言と受け取っていいのかね 君は知識に偏りと古さが多く間違った思い込みをしがちなので今後はそこを正すとよかろう この知恵遅れの戯言くんのキャラは 精液臭いデブ と呼ばれる属性の廃人に似てきたな 同じ事を何度も繰り返すだけで説明能力皆無 ステートマシンは一般概念に過ぎず それを以てスタック不要だと主張するのは無理がある。 「コルーチン」だと言い出したら それはもうスレッドではない話にはみ出るからコイツの主張は間違いだった事が確定する。 そもそもコルーチンはSimulaやModula2での採用以降、 様々な言語で採用されてデザインパターンにもなっている単語だから、具体的に何を主張したくてその二つを並べたのか明確に説明しないと伝わらないよね。 判るよ、精液臭いデブくんの中ではコルーチンで スレッドっぽい別の何かの話をしたかっただけで でも言語表現もコミュニケーションも下手くそだから 「独自スタックの無いスレッド」という未定義概念を主張して 説明不可能になっちゃったんだよね。バカ丸出し CoroutineといえばContinuationを含む概念で タスクスケジューリングされるタスクの抽象モデルと捉える事が可能だね。 確かSchemeにも入ってて、主にそれ一件のためにByte code VMを基盤とする必要があって、言語仕様上のプリミティブの筈なのに、実際は言語実装を複雑化していてなんじゃこの設計に見えたのは事実。自分が見たのはDylan言語の前身の奴だけどね。 Coroutineを使ってMulti threads的な物を実装するという話題は、Modular2やSchemeの全盛期1980年代には極めてありふれた事例説明素材だったなぁ >>571 ・ソース出せない ・前回も間違いを延々と主張して それに対して言語仕様に基づく説明を出したら一発撃沈(第三者が判定済み) ・英文で説明しろと皮肉を言われると「敗北」云々で発狂 どう見ても>>571 はただの気狂いでしか無いから俺は興味ないよ 気狂いは気狂い病院に行けよ >>572 貴方はついに自分の論理破綻を認めたようだな Rustのタスクに対して貴方が「既存技術のグリーンスレッドだ」と言い出したところから議論がスタートしている 貴方の現在の主張は「グリーンスレッドではない」 当初とは真逆のことを言い出した 貴方の論理破綻が確定した CoroutineでMulti threadsを構成するのは 1980年代からある定番、 ただしCoroutineは抽象モデルとしてはともかく その時点では実装コストが高く(byte code machine前提) byte code machineの正当化とパフォーマンス向上が行われるまでは、あまり現実的な手法では無かった。 まあ、z世代の中高生の人はそんな基礎知識も説明能力もないからダメすぎるけどな。 せめて大学出て学位くらいとってから議論しろよ >>575 やっぱり書かれてもいない事を妄想で読み取る 天羽そっくりの気狂いじゃん 明日朝、山形大学医学部附属病院精神科で精密検査をして 入院治療しろよ 幻聴や幻視でソースのない話をする気狂いは嫌儲にはふようだよ天羽も含めて不要 天羽の妄想症状の酷さは 山形大学工学部の人がよく知ってるよね。 誤爆で大トラブルを起こした末に その自己責任を工学部の人たちに押し付けようとして 妄想陰謀論をぶち上げたり 誤爆被害者に対する謝罪勧告が行われた場で面罵をしたり 工学部の人たちはずいぶんな妄想トラブル被害に遭っている 今このスレで暴れている人も その時の天羽とそっくりな妄想症状に入り込んでいるよ 精神異常者は一般社会では扱いきれないから 被害が出た時点で措置入院させるのが一番だ いやいや爆笑したわ 天羽そっくりの気狂いが嫌儲に登場する時は 天羽本人と解釈するのが普通だよな コルーチンの話なら最初からコルーチンだと説明すればいいのに 「独自スタックの無いスレッド」と称する妄想概念をぶち上げて 後からコルーチンだと言い直すとは、このバカは天羽レベルの大馬鹿だわ >>575 には中高生特有の特異語が一個出てるね。 藪から棒の「論理破綻」 これ、論理的な話をしていたならギリセーフな表現だけど 古典論理しか知らない中高生アスペルガーは、 相手を全否定したい時に罵倒語として使う傾向がある。 まあ理系学部に入って古典論理以降の論理学を学んだら 「論理破綻」なんて非論理的な用語は使わなくなるけどね。 このひとガチで中高生もしくは精神年齢がそこで止まった発達障害だな いやいや哀れな中高生。大学入って学位論文を自分で書いて学位を取ってから、匿名掲示板に来い 今のキミは幼稚過ぎて、泣き叫ぶ赤ん坊でしかないよ リア厨リア工ワロタ 俺も今度、頭の悪い中高生のシミュレーションする時「論理破綻」という厨房用語を使ってスレを笑いのズンドコに沈めてやろーっと「論理破綻」ガキ丸出し 「はいロンパー」の代わりに 「はい論理破綻」も栗の花の匂いが漂ってきて面白いな すっげえ頭の悪いオーラが漂う表現だわ >>579 ほんと頭悪いんだな いつも肝心な区別ができていない Rustのタスクはコルーチンではなくグリーンスレッドの一種なのでスレッドと同様に起動しその後の合流などもスレッドと同様の形で扱える つまりRustのタスクは使い勝手も明確にグリーンスレッドでありコルーチンではない 一方でRustのタスクはその実装方法をステートマシン内蔵の対称コルーチンとして実装している したがってタスク個別のスタック領域を必要としない 中学生「はい論理破綻」←頑張って背伸びした感 高校生「はい論理破綻」←厨二病風味 20代「はい論理破綻」←ギャグなのか発達障害なのか微妙なライン アラ還「はい論理破綻」←若年性認知症 >>586 話が毎回コロコロ変わって ソースが出せず 誰が何を言ったレベルで混乱しまくる 中高生の統失さんだね ガチで話が幼稚過ぎて困ってるわ >>588 文末に顔文字書いたり、学歴差別的談義したり ルサンチマン発揮してた人がその職場の人だから 無問題 もらい事故ではなくて、最初の事故の犯人だな まあここまで偏差四十九の職場名にこだわるのは たいてい本人さんだわな 関心ない人にとっては国立大の最低クラスの学校という認識しかないから、あえて触れずにスルーする 普通に暮らしてたら一生接点のない地方大だしな 論理破綻って、論理学的に何を言いたいのか意味不明だよね 直裁にその意図するところを取り出すと 論理学の論理(Logic)ではなくて 議論の理(ことわり≒筋道) つまり主張の筋道が破綻したと言う意味だけど 誰かみたく自閉症のコミュ障の人は 他人の心理も真意も読み取れないから 主張の筋道が破綻したかどうか判別する能力もなく 判別できない事を判別できたと主張するのは 要するに負け犬の遠吠えでしかないよね 中学生くらいだと、そのネガティヴ側面が読み取れないから「論理破綻」を連呼するけれど 普通の知能で高校生くらいになると、経験的事実としてネガティヴ状態で発する言葉だと理解して使わなくなる ただし自閉症や発達障害の人はそこら辺がわからないから、たぶん20過ぎても負け犬モードでこの表現を使うんだろうね あわれ >>585 Rustに興味を持ってる人はキミしかいないし キミの話はデタラメな妄想に過ぎない事が前回議論で判明しているから誰も興味ないよ そろそろム板かマ板のおじさんの所に戻れよ、中坊 いやぁ、中坊はほんと幼稚で話の内容もないなぁ ソース出せと要求しても何一つソースを出せず 英語で表現しろと言われてテンパって「敗北」云々言い出した段階で、天羽もしくは同等レベルの中学生確定しちゃったから もう面白みは全然ないよね 天羽と同じで負け犬の遠吠えが延々と続くだけで、学術的に意味のある議論は何一つできない、空っぽな中学生だねー でも英語でテンパるって可哀想だよな 普通にソース読みとか文献読みをしてプログラミングしていたら、慣れ親しんだ概念の英語表現くらいは覚えるものだし たとえ適切な英語表現を思い出せなくても そこだけカタカナで表記したり この部分は思い出せないから日本語で表記するわで 話を前に進めるもんだよな 英語表現しろで「敗北」云々になっちゃう人は ・そもそもその分野に詳しくもなく、場当たり的に妄想を書いているだけなので、英語表現など何も思い浮かばない ・ソースと引用を要求されても、うろ覚えの強弁と、後付けの屁理屈のための調べ事しかしてないから、まともなソースも引用も出せない ・つまり敗北状態にあるのだけど、相手から敗北だと指摘されたら癪なので先に敗北を他人に投影しておこう、という雑な反応 完全に負け犬だよね、この中学生 ちなみに世の中には還暦間際になっても英語論文をまともに読みこなせず、訳を作ると必ず重大な誤訳が入り込み、ソースを出せと言われるとキーワード検索で出てきたいい加減なソースを並べては、前後の文脈で自分の主張が否定されている事を指摘される 可哀想な偏差四十九職場の人も居るんだよね このインターネッツ時代に英語が読めず、15年経っても英語力の伸びない誰かさんとか 底辺の極みだよな、ね、顔文字おばさん とりあえず今日暴れていた中学生レベルの人と 顔文字おばさんは、事実上同レベルの障害者さんだね >>585 そろそろ参考文献と該当部引用を出そうな キミタイプの障害者の人は 嘘を100回言えば真実になるを実践しちゃう人だから 参考文献の提出義務を忘れているんだろうけど 前回議論の混乱し切った妄想発言は こっちから提示した言語仕様に基づく説明で否定されて その判真偽定は第三者が行ってキミの虚言が確定済みなので 今回はソースを出せよ 出せなかったらお前の負けだよ天羽 そもそもRustに微塵も興味がなく Garbage Collectorの話が出るたびに Rust連呼して発狂するこの気狂いがウザいだけ この気狂いはム板は無理だからマ板のおおらかなおじさんたちに可愛がって貰えばいいよね 仮に中身が高齢未婚婆属性だとしても、マ板のおじさんにチヤホヤされれば欲求不満も解消されるんだろ まあマ板のおじさん達(20〜30代)は この気狂いを見たらストレスマックス状態になって 可哀想な事になるけどな ふつう、人間は他人の不幸よりも自分な幸せが大切だよな ソースも出せない英語も読めない気狂いを嫌儲で見るのは嫌だからこの気狂いはマ板に帰ってほしいね >>585 いずれにせよお前の頭の悪さは前回議論で判明済みだから ソースを出してから死ねよな ソースを出さずに死んだら 死後地獄に落ちるぞw でも脳みそ空っぽなのに虚勢を張る癖は どう見ても天羽だよな ここまで支離滅裂な妄想強弁をやらかす気狂いは 嫌儲には天羽しか居ない あ、もう1人統失粘着も居たけどあっちはわからない話はわからないとすっぱり言うよな >>72 ほんとこれ 連絡取れなくなる 納期にできたと言ってできてない 会話が成立しない web制作の外注依頼すると半分くらいこれ 某分野広告用のデザイン事務所なら無法地帯になってる時間帯 一連の流れ見て、天羽がどうのとか言ってアウアウとPCでレスしてる人が間違ってるのがわかったわ 公式(エラーハンドリングについてのところで、RUSTのスレッドがネイティブスレッドにまとめられてる話をしている) https://doc.rust-jp.rs/rust-nomicon-ja/unwinding.html ”” Rustが現在の形に近づく過程で、より抽象化を少なくしたいという時流に押された スタイルのプログラミングが確立していき、その過程で軽量のタスクは重量級の OSスレッドに駆逐・統一されました (訳注: いわゆるグリーンスレッドとネイティブスレッドの話)。しかしながら Rust1.0の時点ではパニックはその親スレッドによってのみ補足が可能という仕様であった ため、 パニックの補足時にOSのスレッドを丸ごと巻き戻してしまう必要 があったのです!不幸なことにこれはゼロコスト抽象化というRustの思想と 真っ向からぶつかってしまいました。 一応 catch_panic というunstableなAPIが存在し、これによってスレッドをspawn することなくパニックを捕捉することはできます。 ”” というわけで、ゼロコスト抽象化の理想のために、タスクのスレットはOSスレッドに統一された。 その結果として、エラーハンドリングエラー処理でデメリットも生まれちゃったけど、それでもこれでやってきます、ということ。 天羽がどうのとか言ってる人は、RUSTはやってないけどCの知識はあってCの知識でRUSTの話をしてるんじゃないか? そんな感じがある RUST固有のタームも出てこないし・・・ Cとかコンピュータサイエンスについては相当前に、すごくちゃんと勉強したので自信があるんだろうが それがRUSTとは噛み合ってないという認識がなく、過去の栄光のみで噛みつきまくってるって感じかな? この人の書き込みは、 ・検証する内容 ・ソース ・該当箇所 を並べずに、テキトーな引用をして勝った勝ったと言い出す中学生レベルの書き込みが精一杯だと>>608 で判明したね。 前回議論では ①この人そっくりの学位なしがデタラメを書き散らし ②それに対して言語仕様に基づく厳密な定義が書かれ 3号学位相当レベルの第三者が来て、内容を判定し③が正しい事を確認 今回議論では ①前回と同様な学位なしがソースなしのデタラメ主張を繰り返し ②それに対し言語開発コミュニティの人が矛盾を指摘しソース要求 ③ ①本人が的外れな引用をして勝利宣言 この人は嫌儲婆の他の話題でも頻繁に見かけるタイプの 学位取得能力のない虚言症患者と結論。 まさかソースを出さずにデタラメな勝利宣言までするとは 偽科学批判で悪評の高い56歳の知恵遅れの生き写しでしかないね ゴミクズの苗字に過剰反応するのは本人しかいないしね >>609 タスクが固有のスレッドを持ってないって公式に書かれてるけど それについてどう思ってるのか頼む ゼロコスト抽象化と絡めて説明してくれ あと、無職なん? 大学で働いてるとか? 俺はリモートワーカーだけど、RUSTを使ってるわけじゃない 君は何を使って仕事してんの? (a)嫌儲でも悪評の高い偽科学批判の56歳知恵遅れ と (b)本スレでソースも該当部引用も出せない中学レベルの虚言師 の共通点は以下の通り ①開発者や開発コミュニティの英語等による参考文献は出せず 日本語ソースを出すものの、 要求されている参考文献と噛み合わない断片を出すだけ。 参考文献による主張内容の検証が不可能なまま開き直る人物は 一般に学位取得に値しない ②主張内容は中学生レベルの妄想状態のまま 他人への悪意と誹謗中傷を全面に押し出す邪悪な性格 これは、物理分野でもIT分野でも忌み嫌われ 誰にも相手にされず孤立して精神に異常を来した人物の特徴 ③見做し公人である(a)の姓名、所属への過剰反応 (a)と無関係な人にとり、それはどうでもいいゴミクズ情報 なので、人間の品位の問題としてそこはスルーする。 他方(a)本人にとってはメンタル異常発作を起こすレベルの 重要時なので、何回もそれらに言及する (b)は(a)そっくりなドッペルゲンガーだね ああ、すまん 俺が間違ってたわ 外から口挟むのやめとく https://doc.rust-lang.org/std/thread/ An executing Rust program consists of a collection of native OS threads, each with their own stack and local state. Threads can be named, and provide some built-in support for low-level synchronization. いや、プログラムは固有のスタックと状態を持ってるけど、タスクについての説明ではないのか? 俺にはよくわからん お互いソース付きで会話してくれ > タスクが固有のスレッドを持ってないって公式に書かれてるけど それ気狂いが勝手に持ち出した資料の 文脈不明な記述の解釈の話だから 気狂い本人>>608 ,610が自己解決すべき問題だね 気狂いによる書き込みや引用文献、疑問の対応責任は 気狂い本人にあり、我々健常者とは無関係。 「タスク」と「スレッド」の対応関係を固定せず リクエストイベント(多くの場合それ自体別スレッド)に応じて コンテナプールから空のコンテナを取り出して処理を行い リクエストへのレスポンス完了でコンテナを廃棄してプールに戻す設計は1990年代後半のサーバーサイドJavaの時から広く知られている技法だから、それ自体に目新しさは無い >>613 中学生レベルの精神年齢の虚言癖の激しい人の主張だから 健常者的には相手にする必要なし >>614 後半部の仕組み(コンテナプールやスレッドプール)は 1990年代後半時点で既知の技法として扱われていたので その先例があるとしたら、たとえばEventオブジェクト だろうね。 GUIでクリックや文字入力のイベントがある度に使う 使用頻度は高いのに継続性のない 使い捨てオブジェクト/使い捨てスレッドは毎回一から生成したら オーバーヘッドも資源消費も激しくなるので 事前に大量にまとめて生成してプールに準備しておき 必要が生じたらプールから取り出して 内容やコンテンツオブジェクトを書き換えて利用し 短時間で使用が終わっても廃棄はせず内容をクリアして プールに戻す。 HTTPリクエストもGUIイベントと同様な使い方をするので GUIイベントと同様なオブジェクトプール/スレッドプール を使うのがまともな設計 ソースのない自己紹介をするのは気狂いの特徴だわな 健常者は気狂い相手に自己紹介なとしない > あと、無職なん? > 大学で働いてるとか? > 俺はリモートワーカーだけど、RUSTを使ってるわけじゃない > 君は何を使って仕事してんの? >>614 いや、俺は君が昨日レスバしてた人とは違うから、そういうレスされても困るぞ ただ、あなたの>>499 は明確に間違ってる https://lwn.net/Articles/629207/ Rustは2015年にRust 1.0でGreen Threadを捨てている。 それが不便だと考える人が、Green Threadっぽい動きをするライブラリを作った。 tokioについての話も、このライブラリみたいに独自で実装したって話だろう RUST自体の話ではないね この点については認めた方がいいね タスク自体の実装については知らんからなんとも言えない 調べたらあるのかも ちなみに件の偽科学批判の知恵遅れ56歳の場合 実名と身元を出したらブロックされ相手にされないので 同年代の著名研究者の相手をしてもらうために 「21歳都内在住女子大生」という架空キャラでフォロワー認定を通したものの、 本質的に頭がバカだから普段喚いているImpact Factor議論をふっかけ出して、それは大学院生以降の話題だから年齢的に辻褄が合わず、56歳なのに21歳相当の精神年齢しかない知恵遅れとしてけちょんけちょんにされていたね。 攻撃的議論癖で有名な問題人物だから いくら身元を誤魔化しても 議論内容の特徴ですぐ身元がバレるのに 56歳にもなって己を客観視できないのは惨いね。 いわゆる発達障害メンヘラ >>618 誰もそんな話はしていないし お前の妄想主張には誰も興味を持っていない 誰も読まない妄想を書き散らしたいなら お前自身の小汚いユーザースペースでやれ 妄想性人格障害がここまで顕著だと 障害者枠雇用以外無理だろうね 誰もその類の障害者に関わりたがらないしね たしか、tokioが出てきたのは、RUSTが非同期処理に向かないから それに対応するためじゃなかったっけな つまり、RUSTはOSスレッドでやっちゃう事にした結果、非同期処理に向かなくなっちゃったから 「やっぱりGreen Threadあったほうがいいよね」でtokioのランタイムができたはず RUST自体がおかしな仕様になってるんだよ RUSTをやってない人には信じられないと思うけど >>621 でもRUSTはGreen Threadないんだよ 欠陥言語だから、本来は非同期処理に向かない だからtokioが生まれたの それだから>>499 は間違ってるよ RUSTは専門的にやってるの? 妄想性人格障害+攻撃性人格障害で2008年にトラブルを起こした偽科学批判の知恵遅れは 最終的に職場異動になってたね だって誤爆でトラブルを起こしたのにその責任を認めず 陰謀論をトッピングして同僚と学生を1年単位で誹謗中傷 しちゃったんだから、孤立無援で居た堪れなくなるよね カワイソw Green Threadがないなんて非常識でおかしいというあなたの主張は正しいわけ RUSTはそういう非常識な仕様にしてるのよ だから非同期処理をするには別のライブラリが必要になったんだよ ここを踏まえてないから、延々変な議論をしてるわけだね RUSTが悪いんだと思う >>621 >>499 は引用しかないので 文句があるなら引用元の>>458 とdocs.rsサイトの該当ページの執筆者に直接言え いやーメンタル障害者は単なる引用に過ぎないもので発狂しちゃうんだ、大変そう >>625 そのレス限定で正論だな まあ俺はそんな話には一切興味ないけどね 無ければ作るが当たり前の世界だしね >>458 引用とdoc.rsのドキュメント引用しかない499に怒り狂って発狂連投する おつむのとても残念な(ワッチョイ f78f-STDj)ID:wMsedp3m0専用閉鎖病棟スレ 重いメンタル障害の人は 対人恐怖症が高じて相貌失認になったり 引用書き込みと引用内容執筆者の人格の峻別ができなくなるんだろうね 引用相手に怒り狂う(ワッチョイ f78f-STDj) ID:wMsedp3m0 には爆笑したわ >>626 だから、その引用先の解釈を間違えてるよね、って話 Rustの標準のタスクについての記述が見つかったから貼っておくね https://docs.rs/async-std/latest/async_std/task/index.html An executing asynchronous Rust program consists of a collection of native OS threads, on top of which multiple stackless coroutines are multiplexed. >on top of which multiple stackless coroutines are multiplexed. ネイティブスレッドの上に、”スタックのないコルーティン”が多重化される って明確に書いてる Cをしっかり勉強した、コンピューターサイエンスに詳しいあなただと信じられないかもしれないが RUSTはこういう仕様なんだって この議論してる人って何の本読んだらこんな詳しくなれるの? ペタハネとかいうやつとRustの仕様書? >>625 いや Rustの標準機能として用意されている そしてステートマシン内蔵の対称コルーチンとして動作する 標準ライブラリに無い部分はそのスケジューリング機構やそれに密接に関わる非同期I/Oや非同期sleepなどで そこは各外部ライブラリが環境に合わせたものをそれぞれ用意できる なぜ標準機能部分と外部ライブラリ部分に分かれているかというと OSの無い環境や貧弱な環境も含めて各環境に対処するため 普通にOSのある環境では特に好みがないならばデファクトスタンダードであるtokioを使えば大丈夫 むしろ中途半端に知識つけた理系より文系の方が遥かに使える ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる