  |
はてなキーワード: モジュールとは
彼はお金がない( )車を2台買った。
「ここが”ので”じゃなくて”けれども”になる理由が分かりません」
これについて「文脈がわからないから、どちらか決まらない」とか「文法的にはどちらも成立する」とか、全然文が読めていません
「本当は3台買うつもりだったけど、お金がないから2台にした」とか、問題なのだから書かれている情報以外の事は考えてはダメなんです
ここで考えるのは「～がない」というネガティブな状態 と 「～を買った」というそれに反する行動結果
という矛盾・対立の関係を考えたら、接続詞は「のに」「けれども」という逆説しか選択肢はないんです
でもそれがわからないというのは、文が読めていないんです
文を読むというのは
このプロセスのことです
「文脈がわからないから」というのは、入力の情報が少ないということです
これが多くなればもちろん正解する確率も上がりますが、それは大規模言語モデルであるChatGPTと同じレベルってことです
※参考
https://www.coelang.tufs.ac.jp/mt/ja/gmod/contents/card/082.html
奥さんの場合、普段は不安というモジュールが活性化してるけど薬を飲むと不安モジュールが不活性化して社交的な明るいモジュールが活性化するだけ
俺が博識すぎて生きるのが辛い
ChatGPTに日本語で命令したら秒で作ってくれるのでVBAやGAS書く能力は不要になったんだが。「A1からI9に数独の初期値入れてあるシートの残りのマス埋めるVBAマクロ作って」の一言で数独解くの作ってくれるぞ
ChatGPTが補足している通りロジックは基本しか使っていないので初期値から最終形までに仮定して入れる局面があるものは解けないし非効率ではあるものの初級は解けるし遅いPCでも一瞬で終わる。必要なのは入力の形と欲しい出力を日本語にする能力とHello World実行できるレベルの知識。コード読んでデバッグできる能力があればなおよいがGPTに教えてもらえばいいし、今業務やってる派遣の人に動作確認してもらって不満なところをAIに修正させればよいので業務をよく分かっている社員にやらせたほうが会社としてはいい戦略。
A1からI9に数独の初期値入れてあるシートの残りのマス埋めるVBAマクロ作って
数独を解くためのVBAマクロを作成するのは複雑ですが、以下は一つの例です。このマクロはシートのA1からI9の範囲の数独を解きます。
Function IsPossible(y, x, n, grid) As Boolean Dim i As Integer Dim j As Integer ' 同じ行や列にnが既にあるか確認 For i = 1 To 9 If grid(y, i) = n Or grid(i, x) = n Then IsPossible = False Exit Function End If Next i ' 3x3のボックス内にnが既にあるか確認 Dim x0 As Integer: x0 = ((x - 1) ¥ 3) * 3 Dim y0 As Integer: y0 = ((y - 1) ¥ 3) * 3 For i = 0 To 2 For j = 0 To 2 If grid(y0 + i + 1, x0 + j + 1) = n Then IsPossible = False Exit Function End If Next j Next i IsPossible = True End Function Sub SolveSudoku() Dim grid(1 To 9, 1 To 9) As Integer Dim i As Integer Dim j As Integer ' グリッドをシートから読み込む For i = 1 To 9 For j = 1 To 9 grid(i, j) = Cells(i, j).Value Next j Next i If Solve(grid) Then ' 解をシートに書き出す For i = 1 To 9 For j = 1 To 9 Cells(i, j).Value = grid(i, j) Next j Next i Else MsgBox "解けませんでした" End If End Sub Function Solve(ByRef grid) As Boolean Dim i As Integer Dim j As Integer Dim n As Integer For i = 1 To 9 For j = 1 To 9 If grid(i, j) = 0 Then For n = 1 To 9 If IsPossible(i, j, n, grid) Then grid(i, j) = n If Solve(grid) Then Solve = True Exit Function End If grid(i, j) = 0 End If Next n Solve = False Exit Function End If Next j Next i Solve = True End Function
このコードをVBAのモジュールに追加して、シートに数独の初期値を入力してからSolveSudokuマクロを実行すると、マスを埋めることができます。
ただし、このコードは基本的なバックトラック法を使用しており、非常に複雑な数独には効率的ではない場合があります。より高速な解法や最適化を求める場合は、追加の手法やアプローチが必要です。
https://si-coding.net/sudoku4.html
2 3 5 7 8 3 3 4 5 1 6 6 1 2 4 4 9 8 2 2 5 1 3 9 4 6 1 4 1 2 6
1 6 9 2 3 5 8 4 7 4 5 8 1 6 7 9 3 2 3 2 7 9 8 4 5 1 6 5 3 6 7 1 2 4 9 8 7 1 4 3 9 8 6 2 5 9 8 2 5 4 6 1 7 3 6 9 1 8 2 3 7 5 4 2 4 5 6 7 9 3 8 1 8 7 3 4 5 1 2 6 9
おいらのポンコツとうとうイカれちまった((c)RCサクセション)
一度電源モジュールのスイッチおOFFにしてONにしたら、もうマザボのLEDも光らなくなった。
電源モジュールのどこかを短絡させれば、単独で動作確認が出来るらしいが
ちょっと道具が無いと無理だなこれ。
電源モジュールが壊れてないかどうかは、明日近くの修理専門ショップで診てもらおう。
6年ほど使い倒したわけだし、電源かマザボかは分からんが、まあ寿命だとしても驚かない。
買い出しは土曜日。。。あ、三連休やん。せっかくだし新しいの組もうか？
グラボは最近RTX3060に替えたばかりなんで据え置きとして。
今までずっと、こだわりがあるわけでもないのに何故かAMDのCPUばかりで組んでたが、初のIntel行くか！？
夢がひろがりんぐ。
ワイが理解出来ないのはApple信者では無いエンジニアなのにドヤ顔でMac使ってるヤツと
カーネルエンジニアやデストリでもWindows使ってるのにドヤ顔でデスクトップLinux使ってるヤツ
デスクトップ環境周りのコミッターとか自作OSやドライバ作ってるとかなら納得だけど
どーせ単なるユーザー利用でしょ？
https://anond.hatelabo.jp/20220910173047#
https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20220910173047
アンサー幾つか
あとこれ↓
○組織名は差し控えますが大学のお話です
最近は React とか Vue とかのフレームワークでコンポーネントにできるようになった
だけど客からああしてこうして言われて作るものとコンポーネントは相性悪い
開発者が仕様も考えて作るようなパターンはコンポーネントで考えて、機能の追加などもそれに準じて実装しやすいものになる
でも、客の要望はそうじゃない
全然関連なさそうなデータを参照して、この時あのデータも見て、ああだったからこうして・・・みたいなのが来る
ここを書き換えたらあっちも変えたいとかが無秩序に
昔の方法だったらページ内のデータは全部グローバルだから苦もなくそれらに対応できたけど、コンポーネントやモジュールでスコープを小さくするよう設計してると相性が悪すぎる
＞当たり前の話だけど内燃機がなくなったら無くしただけでいいわけじゃない
＞日本が有意なものを捨てて外国から買うようになるから日本の雇用が失われるという事
e-axleとバッテリは、EV化で失われるだけの雇用を生み出すことにはならない、って書いたじゃん。どっちも内燃構成部品に比べて圧倒的に資本集約型の生産設備で作るパッケージ度の高い部品だから、そうなる。国外流出で雇用が減るって話はしていない。純国産EVでも雇用は減る。
実際e-axleは国産いっぱい出てるよね。日本電産とかジヤトコとかデンソー（ブルーイーネクサス）とか。旧系列系がe-axle作ってる企業（トヨタと日産）はそこから買うし、そうでないメーカーは電産から買うだろう。バッテリは国内だとパナとトヨタがやるしかなくて、実際やるって言ってる。でも、どっちも、今までの内燃が生み出していたビジネスボリュームを埋め合わせることにはならない。
あと、EV時代のECUは、多数のチップでやってたのを3チップ程度に高度に統合する路線なので、これも関連雇用は減る。熱マネも同様に統合型に持って行ってるので、これも関連雇用は減る。メガキャスティングも圧倒的にボディ部材の点数や工数を減らす。この3つは全部テスラがはじめて、中国勢もトヨタも追従してる路線。
おれはテスラの作る車は別に好きじゃないし、今後買うこともないだろうけど、テスラが乗用車製造においていろいろな生産革命（e-axleのパッケージ化、統合ECU、統合熱マネ、メガキャスト、アンボックスド・プロセスなど）をぶちこんで、今後のクルマ作りのあり方を変えたのは事実（この中にはEVじゃなくてもできたこともあるけどね）。その方向性は、基本的にはモジュール化と総部品点数削減と無人化。自動車部品のうち内燃ベースの駆動システムに紐づく部品類（エンジン部品＋駆動・伝導・操縦装置部品）の割合は35%程度と言われている。ここがごっそりなくなって、生産自動化に好適なe-axleとバッテリに置き換えられていく。こんなん、安くならないわけないじゃん。
全固体電池は眉唾（これまでもずっと「数年後に実現」と言いながら全くロードマップが進んでいない）だから今回はスルーするとして、遂に来たかというのがメガキャスト（ギガキャスト）。
モノづくりの軸では、車体を3分割の新モジュール構造とし、ギガキャストの採用で、大幅な部品統合を実現することで、車両開発費、そして、工場投資の削減にも貢献します。さらに自走生産の技術で、工程と工場投資を半減します。
https://global.toyota/jp/newsroom/corporate/39288466.html
ばかでかい金型を使ってアルミのダイカストでフレームを一体成型する、テスラがいち早く採用し、他社も追従している技術（テスラは「ギガプレス」、他社は「メガキャスト／ギガキャスト」と呼ぶことが多いが、同じこと）。今までは複数パーツの分かれた鋼材部品をスポット溶接でやっていたのを、一発で作れる。当然コストも製造期間も激減する。
「メガキャスティングなんてちょっとぶつけたら溶接で直せないクソみたいな技術」
「トヨタみたいなクルマ作りを分かってる企業がメガキャスティング採用するはずがない」
とさんざん息巻いてた人達は何だったんだろうかと思う。
トヨタを擁護する人達が良く言ってた「たとえ後発でも、トヨタのパワーで追いつけばイーブンで何も問題ない、EVだけにベットするよりその方が戦略として良い」みたいな話、あれは「後発」側がどれだけのディスアドバンテージを背負うか分かっていない。テスラはメガキャスティング導入に伴って、トポロジー最適化シミュレーションで構造的にリブやトラス構造などの変形部を持たせてクラッシャブルゾーンを確保するための特許を多数持っている。こういうノウハウを知財化できることは先行企業の特権で、この関連特許は、トヨタ他、今からメガキャスティング導入にトライする企業にとって重い足枷になるだろう。「トヨタは全方位戦略、EVが主流になるなら後から総取りすればいい」みたいなことを言ってるうちに、こうなってしまった。
これからこういうことがどんどん増えるんだろうな。
技術的負債というワードはウォード・カニンガムが発祥と言われており、それこそ「スピード」と「コードの品質」のトレードオフのことを指している。スピードを得るために、借金をすることで、未来のコードの品質を改善するために利子を払い続ける必要があるという意味のメタファーである。
しかし、最近は技術的負債という言葉の誤用が広まり、それが定着化している。
例えば「モダンではない（古い）技術選定」「要求仕様の変化によって荒れたコード」を指して会話していることが多い。
誤用であるので会話の最中に自分とコンテキストが一致しないこともある。とはいえ時代の変化とともに言葉の扱われ方が変わるのは、事実であるので、これは65535歩譲って理解はできる。
しかし、問題なのは誤用で解釈しているエンジニア達がこぞって「技術的負債」という存在そのものを生み出しているエンジニアを糾弾していることだ。
残念ながら、彼らに「技術的負債はなぜ悪なのか」を聞くと「自分の開発体験が損なわれるから」という利己的な解像度でしか相手に伝えられない場合が多く、コミュニケーション能力も乏しいと感じることが多々ある。
開発体験が損なわれると「感じる」というのはわかるが、彼らはこれに対して数字で反論することはない。感情的なのだ。
彼らは自分自身を利口で地頭がよく、論理的に物事を捉えていると誤認しているが、これらの行動原理はただの感情ベースであり、彼らもまた感情的な生き物であることがよくわかる。
脱線するが一部のエンジニアには「○○言語が書けるから入社を決める」みたいな頭が悪い会社の選び方をする者もいる。
好きな言語を仕事にしたいという安易な発想で、糾弾している技術的負債を目の当たりにし、自分が書きたいと思ったコードが書けないで会社を去るものもいるだろう。本当に愚かである。残る選択をしたエンジニアは技術的負債に手を加えて、自分が嫌悪しているのにも関わらず技術的負債を生み出すのである。
そして、彼らもビジネスの都合で技術的負債を生み出して、後に入社するエンジニアに技術的負債を生み出したことで糾弾されるのである。数ヶ月、もしくは数年後にはモジュールなどのエコシステムが刷新されることによって、結果としてオナニーコードが技術的負債として罵られるのである。滑稽としか思えない。
つまり誤用の技術的負債ワードを用いるエンジニアが、技術的負債を糾弾するというのは無知によるポジショントークであり、自分自身が技術的負債を生み出していることに気づかないピエロなのだ。
さらに言えば、言葉の定義にうるさい割に、技術的負債という言葉の定義を自分たちの都合のいいように解釈して誤用しているのである。
gssapi-with-micとあるので、音声が背後で収集されてるんか！？とビビってしょんべんまでチビってしまったが、そういうモジュールではなかった
The term message integrity code (MIC) is frequently substituted for the term MAC, especially in communications to distinguish it from the use of the latter as media access control address (MAC address). https://en.wikipedia.org/wiki/Message_authentication_code
個人的には、きちんとしたオブジェクト指向をきちんとやる方法を調べきれなくて
base.pm といったような、オブジェクト指向を目指すためのモジュールは昔から色々と公開されてて
きちんと調査できていれば、きちんとしたオブジェクト指向をやれたんだろうけど。
Perl5の実用的な面での特徴は、異常なまでの後方互換性にある。
25年前のPerl4向けのスクリプトですら、ほとんど修正なしに最新のperl 5.36.0で動いてしまう。他のプログラミング言語ではあまり見られない特徴である。この特徴はある程度は今後も維持されるし、いまPerl5を書いている人の多くが望んでいることだろう。
しかし、後方互換性を守るあまり現代の言語に備わっているような機能が欠けている現状がある。ただ、それも改善されつつあり、後方互換性を守る形で慎重に取り入れられている。
一方で自由度が高すぎる文法は、後から修正を重ねていくようなものには不向きかもしれない。linterであったり、型アノテーションを書くようなモジュールも存在する。このようなものを用いて自分を律して書く分にはメンテ可能であるものの、現代のように多くの人が一つのスクリプトをいじることが求められる環境では不向きと言える。
実用的な面で向いているのは「一回書いたら修正を行わないスクリプト」かつ「10年単位で動かす必要のあるもの」である。そんなものはあるのかと思う人もいるかもしれないが、規模が小さければぴったりハマる場面もある。
言語としてはコンテキストだったり、ブロック単位で言語の挙動を変えられる点などが面白ポイントであるものの、これらはホビーとして楽しむのが良いというのが私の見解である。
HTML5/CSS3の段階でWebページ構築の基本的なしくみや考え方はほぼ確立してしまった。
ということは、HTML5/CSS3をマスターしてしまえばだいたいのモダンなサイトは作れてしまう。
しかしそのせいでそCSS Level 4 以上のモジュールを学習する意義が見いだせず、CSS3で知見が止まってしまっているコーダーをよく見る。
たしかに、HTML4.01/CSS2.1→HTML5/CSS3の時のような華々しい進化が Lv4 には（あまり）ない。
なんだこれ！並ぶぞ！動くぞ！消えるぞ！飛ぶぞ！みたいな興奮が少ない。
手駒だけで何とかなっている状況で興奮のないものを学ぶモチベーションがわかないのもわかる。
「できないこと潰し」「新しいこと探し」だったHTML5/CSS3に対して、それ以降は「今までも苦労すればできてたけど、もう少し簡単にしたい」という方向に進化している。
モーダルウィンドウがいい例だ。従来は何十行ものJavaScriptやCSSを使って実現していたが、dialog 要素の登場によってマジで簡単に実装できるようになってしまった。
そういう「できるけど厄介」を片っ端から潰そうとしているのが今のHTML/CSSの進化だと思う。
いやHTML/CSSだけではない。JavaScriptだって新仕様がどんどん追加されているが、そのどれもがコードをより簡潔に、合理的に記述できるようにするためのものだ。
家電とか車とかに例えると、製品の機能を増やすフェーズは終わり、組み立てに必要な技能やかかる手間を減らすフェーズに入ったと言えそうだ。
だが知っていれば確実にトクをする変化だ。
DMM版ウマ娘プリティーダービーを遊ぼうとしても、エラーダイアログを出さずに起動しなくなる現象に遭遇した。
Windowsのイベントビューアーを除くと、こんなログが吐かれていた（各IDは削除）。
=====
日付:
ユーザー:
説明:
障害が発生しているアプリケーション名: umamusume.exe、バージョン: 2020.3.24.51085、タイム スタンプ: 0x
障害が発生しているモジュール名: apphelp.dll、バージョン: 10.0.22621.963、タイム スタンプ: 0x
障害が発生しているアプリケーション パス: D:\DMMGames\Umamusume\umamusume.exe
障害が発生しているモジュール パス: C:\WINDOWS\SYSTEM32\apphelp.dll
結論から言うと、Windows本体のapphelp.dllが原因でウマ娘が起動できなくなっているという。
アプリケーションに罪は無いため、DMM Game Playerやウマ娘を何度再インストールしても直らない厄介な現象だ。
Windowsは数十万のファイルが存在するため、今回のようにWindows Updateやアプリケーションのインストール・アンインストールを繰り返すだけでシステムファイルが壊れる事がある。
Windowsでは、これを直すためのコマンドがコンソールUIのみに用意されている。
Windowsのスタートメニューを右クリックして、コマンドプロンプトまたはターミナルを管理者権限で起動する。
を実行する。これは、オンライン上にある正しいWindowsのシステムイメージを元に、壊れたファイルを修復する操作となる。
実行するとこう表示される。
[==========================100.0%==========================] 復元操作は正常に完了しました。
DISM.exeを実行すると、正しいWindowsのシステムイメージがPC内に保存された状態になる。
この状態で、
sfc /scannow
を実行すると、次のように表示される。
システム スキャンを開始しています。これにはしばらく時間がかかります。
Windows リソース保護により、破損したファイルが見つかりましたが、それらは正常に修復されました。
オンライン修復の場合、詳細は次の場所にある CBS ログ ファイルに含まれています
windir\ Logs\CBS\CBS.log (たとえば C:\Windows\Logs\CBS\CBS.log)。オフライン修復の場合、
これで、とりあえずWindows自体の修復コマンドによってシステムファイルが正しい状態に復元された状態となる。
実行してもまだメモリ上には古いシステムファイルが読み込まれて実行されている状態なので、終わったらPCを再起動する。
さて、準備は完了だ。ここまでの操作でWindowsを回復しDMM Game Playerで「ダウンロード版をプレイ」を押す事でウマ娘が起動し…ない！
イベントビューアーには今もウマ娘を起動しようとする度にアプリケーションクラッシュイベントが追加されている。救いは無いのですか？
結局、今回のケースではPCで常駐していたリモートデスクトップ用のSplashtop StreamerとVirtual Desktop Streamerをタスクキルする事でウマ娘が起動できるようになり、DMMブラックフライデーで得た有償石でおはガチャを回すことに23時成功した。
