  |
はてなキーワード: 高速化とは
WinNTSetup は、主に大規模展開を目的として、Windows オペレーティング システムをインストールする前にカスタマイズするように設計されています。
インストール中に、約 2MB の Microsoft アプリである Windows アセスメント & デプロイメント キット (Windows ADK) をダウンロードするように求められます。
インターフェースは非常にユーザーフレンドリーなようです。このタブは 2 つのタブに分かれており、1 つは Windows 7 以降用、もう 1 つは Windows 2000、XP、および 2003 のみ用です。理解できないものの上にマウスを置くと、バルーン ヒントが表示されます。
Windows インストール ファイルの場所、ブート ドライブの場所、およびインストール ドライブの場所を選択する必要があります。パッチ UxTheme.dll、無人インストール、ドライバーの追加、ドライブ文字の事前割り当て、モード、微調整、VHD (仮想ハード ディスク) などの追加オプションが提供されます。
25 の追加調整を備えた設定ボタンがありますが、それらは古いオペレーティング システムに適用される標準的な調整に重点を置いています。例としては、「へのショートカット」矢印の削除、システムの復元の無効化、XP スタイルのタスクバー ボタン、クイック起動の表示などが挙げられます。 Windows 10 と 11 のユーザーは、Cortana やその他の不足している設定を削除することによりプライバシーに関心を持つようになりました。私たちの多くが使用しているもう 1 つの不足しているオプションは、ドライブのアクセスを高速化するためにインデックス作成を無効にすることです。
北陸新幹線が敦賀まで延伸開業したが、新大阪まで延伸するには問題が山積みである。
小浜京都ルートが環境問題だけでなく建設費高騰も懸念されていて、米原ルートを復活させる声が浮上してきているがこちらもJR東海との調整など問題が多い。
しかし、敦賀での上下移動を伴う乗り換えは関西と北陸の流動の障害になっており、現状維持もするべきではない。
こう解決してはどうか。
1. 敦賀〜近江塩津間に、鳩原ループをバイパスするフル規格三線軌条路線を建設。在来線車両でも160km/h対応に。
3. サンダーバード、しらさぎは1.新線を通るようにして、敦賀で北陸新幹線と対面乗り換えを可能にする。
4. リニア中央新幹線開業後に、近江塩津〜米原のフル規格新線を建設。
これなら敦賀〜近江塩津間だけの小さい建設コストで現状の敦賀での乗り換え負担を軽減でき、鳩原ループのバイパスと湖西線の高速化による多少の時間短縮を期待できる。
○ご飯
朝：納豆たまごかけご飯。豚汁。昼：お菓子。夜：餃子、長ネギ、人参、キノコの鍋。間食：柿の種。チョコ。
○調子
むきゅーはややー。おしごとは、おやすすー。
携帯電話専用ゲームとして発売されていたADVのニンテンドースイッチ移植版。
終電を逃した主人公が何故か臨時で運行している臨時終電なる謎の電車に乗り込むことから始まるホラー。
いつまで経っても駅につかない、応答がない車掌、次々起こる怪奇現象で恐怖を煽ってくる。
これらの恐怖体験を乗り越えつつ、この電車が何故このような奇妙なことになっているのかを解き明かすちょっとした謎解きパートもあるのが良き。
今まではルート毎に大きく異なる設定の妙が面白かったが、今作は一本大きなメインルートがありそこからの分岐を楽しむスタイルに変わっている。
ホラーだけ一辺倒というわけではなく、数個のコメディも用意されているがオマケ程度。
あくまで謎の電車に閉じ込められてのホラー展開を楽しむ作品になっている。
特徴的なのは、視点乗り換えシステムと名付けられたザッピングのシステム。
普通の会社員の主人公の他に、メーンヒロインで大人しいあかり、インテリながら失業中でやさぐれ気味の幸子、シングルマザーで色々と疲れているめぐみ、中年男性で記者の南武、ヤンチャな若者吾妻と言った他のキャラ視点のルートも楽しめる。
彼らのルート独自のエンディング、独自の世界観も用意されているのが良かった。
特に、シングルマザーとして子育てと仕事の両輪に疲れてしまった烏山めぐみさんのルートでは、女性側から男性にアプローチをかけるシーンなんかもあったりして興味深かった。
本筋を追う場合には、主人公だけでなく彼らのルートでも電車の謎を追うための行動を成す必要がある。
そうして、6人それぞれが臨時終電にまつわる手掛かりを持ち寄り、最終的に立ち向かう構成がシッカリしている。
今までの二作品は低予算なりの試行錯誤を小さな良作だったけど、今作はそれらを踏まえての王道ホラーものとして規模感関係なくちゃんと面白かった。
フローチャートや既読スキップの高速化などのシステム面の成長もありがたい。
特にフローチャートは、前作までと違いフラグ立ての概念がある本作には非常に嬉しい仕組み。
全ルートを制覇すると見れるオマケシナリオを読むためにも、このフローチャートを見ながらの穴埋め感は楽しいシステムだった。
プレイ時間は2時間ほどと短いものの、メインストーリーに集中できる時間がしっかりあるので物足りなさはなく良い塩梅。
ただ、その分ルート分岐でのしっちゃかめっちゃかさや、キャラクタの面白い出鱈目さ加減など、前作までのふざけた部分がかなり控えめなのは寂しくもある。
特にキャラクタの個性は、各位のルートがあるだけに、もっとはっちゃけても良かったかもしれない。
逆にここまで真面目なら真面目なりに、例えば実は彼らにミッシングリンクがあるなんて展開でも良かったかもだ。
静岡県の川勝知事が辞任して、焦っているのはJR東海の役員連中ではないでしょうか。
ここから先の遅れは静岡県のせいにできません。これからが勝負というところです。
簡単に言うと、中央新幹線を、リニアモーターカーという方式で作ろうと言うものです。
中央新幹線はJR中央線をなぞって作られる予定だった新幹線です。
ちょうど、東海道新幹線は旧東海道本線をなぞった路線であることに似ています。
元々は東京から山梨県甲府あたりを抜けた後、今の中央線のように、山脈を迂回、長野県諏訪市を通って木曽谷を抜けるAルート、伊那谷を抜けるBルートの2ルートで検討され、伊那谷を抜けるBルートで意見が集約されていたと言う経緯がありました。
ところが、2010年頃に、JRがリニア中央新幹線を作るに当たって、首都圏の大深度トンネルと、大規模山岳トンネルを使い、ほぼ直線上に結ぶ「Cルート」を提案、沿線自治体もそれに同意し、建設が始まっています。
そのため、リニア中央新幹線は、並行在来線に該当する路線が無い全く新しい路線という事になりました。
中央新幹線計画は、戦前まで遡れる計画です。初の新幹線は東海道新幹線で実現しましたが、中央新幹線ルートが日本初の新幹線になっていた可能性もありました。
さらには、その当時は長大トンネルではありませんでしたが、山脈を峠越えして直線的に結ぶというアイデアは当時からあったようです。
リニアモーターカーとは、超伝導磁石で車体を浮かせると同時に推進すると言うものです。これはJR方式と言われ、
と言う特徴があります。
中央新幹線をリニア方式で建設するというアイデアは、1980年代に決まっています。山梨県にあるリニア実験線は、最終的に本線に組み入れられる予定で建設されています。
しかし、実は鉄輪式で作ると言うアイデアもありました。ですが、最終的にCルートに決まったことで、リニア方式でなければ建設ができなくなりました。
現在のルートは、リニアモーターカーの登坂性能が実現を可能にしたルートです。鉄輪式の新幹線に比べて、リニアモーターカは坂に強く、加速が速いと言う特徴があることから、実現しました。
また、リニアモーターカーは加速減速が非常に早いため、Cルート以外の迂回ルートでも、最大で7分程度しか時間が変わりません。それぐらい優秀な方式です。
東海道新幹線は東京名古屋大阪の旅客輸送で圧倒的なシェアを持っています。これを航空機で代わりにしようとすると、羽田空港が今の数十倍の規模が必要になるレベルの輸送を担っています。
ですから、これをバックアップするには、同等規模のシステムが必要です。
これは、大きなメンテナンスができないと言う事も示しており、改善が必要です。
さらに、JR東海はその収支のかなりの部分を東海道新幹線に依存しており、これが長期停止するようなことになると会社の存続が危うくなる、と言う意味でもバックアップです。投資をして利益率が下がったとしても、事業の継続性を高める必要があるのです。
ただ、以下の様な理由から、バックアップの社会的な必要性は低いという意見もあります。
東海道新幹線は既に増便数が限界に至っており、これ以上の増便ができない状態になっています。
そして、実際にはかなり無理をして増便をしているため、柔軟な運行ができない状態になっており、災害などの影響を受けやすいと言う問題を孕んでいます。
東京名古屋大阪の輸送需要があまりにも巨大なため、それをこなすためにこだまなど各駅停車の便が遅くなっていると言う問題もあります。
それを、最速到達手段の「のぞみ」をリニアに移管することによって、輸送容量の向上を行おうとしています。
これは言うまでもありませんね。新幹線の目的です。中央新幹線が通る周辺は、高速鉄道と飛行場の空白地帯になっており、東京からの時間的距離ではかなり遠い土地になっています。それらをリニア中央新幹線で解決していきます。
品川から名古屋まで40分、大阪まで67分というスピードがあります。これは大深度地下トンネルを通して、大ターミナル駅である、品川駅、名古屋駅、新大阪駅に直接乗り入れるため、相当に利便性が高くなります。
乗り換え時間も考慮されており、先行開業する名古屋駅では、リニア中央新幹線と東海道新幹線の間の乗り換えは3分を実現する設計です。
品川駅では、山手線までの乗り換えが9分とされており、この数字は、東京駅において、中央線から新幹線へ向かうのと同程度の乗り換え時間ですから、標準的な乗り換え時間と言えるでしょう。
リニアは東京名古屋大阪の大都市間をノンストップで結ぶ便が通常になりますが、1時間に1本程度各駅停車の便が設定されてる予定です。
この、1時間に1本という数字は、成田エクスプレスなど一部の例外を除けば、多くの在来線特急と同等かそれ以上の便数です。
このように早くなることは、従来は宿泊を伴っていた需要が日帰りになってしまうといった問題や、ストロー効果と言われる問題など、負の面も多く考えられますが、利便性という面では間違い無く向上します。
増えると思われます。東海道新幹線の旅客数は、コロナ禍の影響を取り除くと、右肩上がりで増え続けています。
（一般的にコロナ禍は2020年からとすることが多いのですが、鉄道・運輸に関しては、2019年の年末から影響が出ています。そのため2019年以降をコロナ禍の影響とすると、その直前2018年がピークで長期的なトレンドでは増え続けています）
さらに需要は回復傾向にあります。特に新幹線に限定すると、2023から2024の年末年始はコロナ禍前の予約数を10%上回っています。
また、JR東日本は、全線開業によって、東海道新幹線とリニア中央新幹線の輸送量は、2011年に対して1.2倍以上伸びるという予想をしています。ですが、実はこの予想、リニアが開通する前に達成されています。
2010年の東海道・山陽新幹線の旅客数はのべ約2億人でしたが、リニアの直前2018年には2億4千万人と2割増加しており、目標を達成しています。今後も増加していくことでしょう。
様々に分析がありますが、コンセンサスが得られているものは内容です。
ある説に寄れば
一方、インバウンドにその理由を求める方もいますが、実はインバウンドの旅客数は、全体に影響を与えるほど大きくはありません。
最新のJR東海の資産では、7兆円となっています。ただし、既に二年前の発表なので、今は更に増加しています。
更に工事の遅延や問題の発生などがありますので、東京名古屋間だけで10兆円を超えるのでは無いかと言う指摘も一部でなされています。
一方で、運賃は、東京大阪間、東海道新幹線に対して＋700円程度と言う話は堅持しています。
単体では黒字にはなりません。何故ならば、東海道新幹線という強力なライバルがいるからです。
しかし、単体で議論する事に意味は無いです。JR東海は、リニア中央新幹線は、東海道新幹線と一体運用で利益を出していくと言っています。
例えば、リニア中央新幹線を黒字にする最も簡単な方法は、東海道新幹線を廃止する事です。ですが、そのような事に意味はありません。
先ほど乗客は増えるのか？の質問に対して応えたように、需要は堅調に推移していますから、計画通り進むでしょう
まとめると
と言うことになります。
なお、リニア中央新幹線はトンネルが多いと言う事で、崩落したら困るから被害が大きくなる、と言った心配がなされていますが、設計的に強度は担保されているという事、またトンネルはそもそも地震に強いため、そのような心配はほとんどありません。
また、リニア中央新幹線は浮上しており、強力な力で保持されているため、浮上しているなどから、鉄輪式よりも地震には強い方式です。
もし停電になっても減速に従って着地するので、急に落下するというようなことはありません。
少なくとも、震度6弱程度でおかしくなるようなことはありません。
日本のリニア技術は既に最先端ではありません。特に中国で盛んに研究が行われており、新しい方式も考えられています。
ですが、実際に実用として実装仕様とする試みは、最先端を言っていると言えるでしょう。
また、JR東海と日本政府などは、アメリカなどに売り込みを図っていますが、まだ正式に決まった計画はありません。これはまだ商用で動いているものがないからです。まずは国内での事例確率に力を入れていくことになると思われます。
また、JR東海の意向や安全保障上の理由として、かつての情報漏洩の教訓から、中国など東側諸国に対して輸出することは現状、有り得ないと思われます。
リニア中央新幹線によって最大の経営リスクが取り除かれるため、経営は安定するようになるでしょう。
JR東海の財務状況を見ると、東海道新幹線への依存が非常に高い状態が続いています。他のJRのように不動産などはあまり伸びていない上に、都市圏の路線が手薄です。
一方で、JR東海は、他のJRに比べて廃線などを行わず、維持する方向で経営を進めています。これは、新幹線で得た利益で地方路線を維持していると言えるでしょう。
この状態で最大のリスクは、大規模災害などで東海道新幹線が動かせなくなることです。これが解消できることで、経営上最も懸念される問題点が緩和される事になります。
最大の問題は、資金です。JRは当初自社資金のみで実施すると表明し、社債を発行、金融機関も融資を実行する予定でした。その返済計画は非常に堅調なもので、東海道新幹線が生み出す現状の利益でも無理なく返済できるような計画でした。
しかし、その計画でいくと、リニア中央新幹線は、名古屋まで開通した後、負債を減らす期間をおいてから大阪延伸に進むと言う計画になっていました。
その状況に、リニアが開通することで、名古屋が東京と事実上一体の経済圏を形成することになる（何しろ、品川から山手線の反対側にいくのと同等の時間で名古屋まで来れてしまいます）事に危機感を持った大阪周辺の政治家・経済界の要請により、国が財政投融資によって低利の資金を供給する代わりに、前倒しすることになっています。
このようなことから、今回の財政投融資は、かつて特殊法人などに資金を供給した「第二の予算」とは性質が大きく異なるものであることがわかります。
もちろんです。辞める理由はありません。
ただ、技術的や制度的には大きな課題が山積していて、本当にできるかどうかは、まだわかりません。
以下に挙げますと
金銭的問題や人手不足などは、時間か資金のかけ方次第ですからどうにでもなると思われますが、技術的問題はなかなか解消が困難です。
最も困難だと思われるのが、大都市圏の大深度地下トンネルの技術的な問題です。ここが最も時間がかかるとしていて、真っ先に着工したものの、進捗が芳しくありません。
一方で、山岳トンネルは技術的にも安定した工法を採用しているため、比較的進捗は良いので、ここは致命的な問題にはならないと思われます。
もしかしたら、2034年に、神奈川県相模原市の車両基地から、岐阜県駅or名古屋駅の間の先行開業というようなこともありうるかも知れません。品川駅までは大阪延伸と同時期ぐらいまで延期はありそうです。
JRは静岡工区のことを強調しながら、2034年以降と言っていますが、それ以外の工区でも遅れが出ています。
近隣自治体には、正式に2032年完成予定といった線表が通知されているそうですので、計画では2032年にできる様な線表で進めつつ、もう2年ほど安全マージンを取っているものと思われますので、早ければ2032年、遅くとも2034年がキーになり、首都圏の大深度地下トンネルという最難関の工事が遅延した場合、部分開業も検討するのでは無いでしょうか。その時点で名古屋まで開業しており、首都圏トンネルの完成目処が立っていない場合は高確率で部分開業へ舵を切ってくると思われます。1
また、関係者はそもそも2027年にできるなんて誰も思っていません。予定通りだった山岳トンネルもコロナ禍で1年半近く事実上工事がストップしていましたし。
さあ？
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
Evernoteの同期が早い。
過去一の速度ではないだろうか？
避難先を探す動向もあるようだが、
挙げられているサービスには、
避難してくると思われる。
その実数などは不明だが決して少なくない数ではないのではないか？
そして、そのユーザーたちは、
今後も無課金であり続ける人たちだ。
つまり移籍先サービスにとってマイナスになってもプラスにはならない人たちなので、ユーザー数の増加を補うための投資には結びつきにくい。
以前のフリーズしているのか？と思わさせられる悪夢のような同期速度は改善され、さらに高速化している。
そして今回の施策により、
不良資産であった無課金ユーザーが減ることはメリットのほうが多い。
お金を払わない人たちのために使われていたリソースが課金ユーザーに回ってくるからだ。
ただ、残念なのは料金が以前より高額になってしまった点だろう。
その点は心配なところだ。
を書いてはや1年。生成AIの進歩によって凄いことになった。早々に使うのをやめてしまったStable diffusionでもface swapが簡単にできるようになった。その上、この1年でNVIDIAはドライバ更新やTensorRTによりStable diffusionを劇的に高速化した。さらに、先日リリースされたReActor extensionがやばい。その結果、とんでもなく自炊が捗ることとなった。
次の処理をスクリプト化した。
去年の手法よりも生成にやや時間がかかるものの、クオリティが比べるまでもなく高いので許容できる。当然ながら実用性の高い動画はできなかったし、生成した動画はすべて抹消したが、本当に捗っている。
来年はどうなっているんだろうか。
【攻撃力】ありとあらゆる物をグチャグチャに崩壊させる不可視ビームを発射可能。
【防御力】ありとあらゆる攻撃を無効化する"無敵"バリア持ち。
バリアは自分の崩壊不可視ビームや空間そのものを削り取る攻撃は防げない。
【特殊能力】読心能力持ち。何らかの手段で肉体を破壊しても復活する。不老。
精神攻撃無効。肉体操作能力・再生能力持ち。食事の必要が無い。
特別な出自の関係で全平行世界に一人しか存在しない。因果律操作能力無効。
など数々の意見が挙がったけどど…どれが一番しっくり来るのか分からないんだッ
この最強キャラクターが死亡or退場してる所から物語が始まる設定だから何らかの方法で倒さないと話が始まらないんだよね
【返信】
特殊な出生由来でこの最強キャラの能力をコピー出来るコピー能力はこいつと同じ世界に居ないんだ
最強議論スレ上位に居るキャラになら普通にぶっ殺されると思われる
人質取られて殺された展開が読者受けが良い上にストーリー展開的にも後々使い勝手が良さそう。知り合う人間が全員常に狙われたら能力的に全員の護衛は不可能だし、友の死でメンタル病ましとけば読者も人間味を感じる
うむ…「こいつはどうすれば退場させられるのか」を考えたら人質作戦は非常に有効だと思われる。
こんな能力では、もし素体が人間ならば他の人と社会的な関係を築けず孤立し不老のために時が経つごとに徐々に精神が蝕まれていくだろう。したがって、廃人になったところから物語を進めると良いのではないか。
こいつには人間らしい精神が無いんだッまるで自然現象の化身のような何を考えてるのか余人には計り知れない奴なんだッ
チェーンソーで一撃
うむ…神殺しの一撃なら仕留められると考えられる
しゃあけど…死亡しても即復活し再生能力持ちのこいつが酸欠くらいで死ぬとは思われんわ！
検索してやっと思い出せた。ナルトのシカマルの元ネタみたいな能力してるよねこの人
後出しがなければ未来予知や時間移動とかも無いからどうにかなりそう。時間停止から崩壊不可視ビーム(主人公限定の設定無し)で殺して死の状態で時間空間を固定とか。あとはシンプルに遠い未来に飛ばすとか
うむ…時止めとか超加速みたいな時間系の能力には歯が立たないんだよね。運命改変耐性持ちだから未来改変は効かなさそうだと思われるが…
ナイスでーす♂ 「どういう手段でこいつは殺されたのか？」を探る話に出来るんだよね
何でも突き通す矛と何でも防御する盾を登場させても矛盾がないように、TRPGのルルブには『ファンブルでの失敗』『クリティカルでの成功』『レベル差が大きい場合の≪無効≫無効』が付記されているとの都市伝説が
このキャラの場合は明確に矛の方が強いんだよね。三代目雷影のような物だと思われるが…
地球滅亡。太陽爆発。太陽系崩壊。銀河系壊滅。宇宙消滅。もしくは「創案者たる増田の死、そしてそのキャラクターを知っている人全員の死、つまり完全なる忘却」でもイイよ。
何らかの方法は未来の自分が考える事にするんだ。妄想しながら設定を煮詰めていけばいいんだ
なろう系だとたまにいるレベルでは。よく倒されてる
正直色んな作品の強キャラと比較したらそんなに強い方ではないんだ。こいつが出て来る設定の剣と魔法のファンタジー世界にこいつを倒し得る存在があまりいないのが問題だと考えられる
それだけ無敵のはずがなぜか死んだ、倒された理由を探る話にしたらどうか
そいつを倒した謎の存在Xを設定して、物語の随所にXの痕跡を示唆するも最後「結局Xって何だったんだ…宇宙はまだまだ謎だらけだ…」とか言ってごまかす（みんな同じこと言ってた…）。「飽きた…俺は消えるぜ」は？
それやると謎の存在Xが気になって仕方ない奴なんだよね。飽きるどころか人生これからだって所で殺されたようなイメージなんだ
うむ…本人も知らぬうちにじわじわ弱体化していく展開は良い物なんだ
しゃあけど妖怪のさとりとかは寿命死しないし読心能力持ちでも普通に生きてるわっ
そのキャラの力の源となっているものを(とくに今のところ明確になってなければ)後出しで設定する。その源を破壊・消滅させる。
指輪物語のサウロンはそういう倒され方だったんだ。良い展開だと思うんだ
倒されたところからストーリーが始まるなら、倒す方法を考える必要ないだろ。 / とりあえず火口に落としておけばなんやかや噴火して宇宙に飛んでってくれるよ。
倒される所から話が始まるからどうやって倒したかを考えたいんだろうがよーえーっ！フリーザ様みたいに宇宙に飛ばす事が死因にならないキャラも割と居るんだよね
これから書くのなら新たに弱点を設定すれば良いのでは？ 弱点＝チャームポイントなので、キャラクター設定の際は能力より弱点を魅力的にする方が重要だ。
うむ…バスタードのダーク・シュナイダーは超絶美形無敵主人公だったがヨーコさんにだけは頭が上がらなかった。はっきり言って弟のような存在だと言える
時を止めて"無敵"バリアをぶち抜ける武器を使えば理屈の上では倒せるんだよね。
ヒロインによって良心に目覚めた後、彗星の衝突を知り、宇宙へ行って全エネルギーを放出して彗星と対消滅。破片の流星に向かって願い事をする地上の人々の中、ヒロインが「綺麗」と呟いて終わり、とかじゃ駄目なの？
しゃあっ いぬやしき
おおアメイジング・スパイダーマンに出てた子やん。実写映画やらないのん？
最強キャラが何故突然消息不明になったのかわからないので調べていく→どうやら何らかの方法で封印されたようだ→実は数千年後に現れる主人公を殺すために自らを封印して待っていた、というストーリーはどう
その設定は別のキャラにも流用出来そうなんだ。数千年を数十年にすれば使えそうなんだ
しかし…再生能力と復活能力持ちが呼吸しないくらいで死ぬとは思えんのです
老衰。
不老者のおっさん。
作者の都合で殺す。
物語的にはそいつの死の理由が何であってほしいのかの方が重要だと思うなあ。人間賛歌の敵としての無感情であれば、多少こじつけでもそれが原因で追い詰められる方が面白い。虐げられた大勢の無力な人間の力が文字数
こんな奴に人間的な情が薄ら芽生えてきたばかりにそこを突かれて負けるんじゃないかと思っていたんだ。
ワープ能力ないから適当な宇宙空間に放り出すなり太陽にぶち込むなり地球消滅させるなりすればそのうち考えるのをやめたり自殺を繰り返したりしそう。時間停止とかが攻撃と解釈されるかはアンデラ式？
うむ…ワープ出来ないから超遠距離に吹っ飛ばしてしまえば帰ってくるのにかなり時間がかかると考えられる。時間停止は「この最強キャラの低速化」は防がれるけど星の白金のような「自身の超高速化」には付いていけないと思われる
粉塵爆発でキャラ周囲の酸素を無くし、酸欠で倒れたところを第二宇宙速度を超えるスピードで打ち上げて宇宙に放り出す。しばらくしたら回復するだろうが、戻る方法がない＆酸素がなくて苦しいのでビームで自殺する
宇宙に吹っ飛ばしてもビームを推進力にして頑張って帰ってこようとするんだ。カーズ様は凍り付く酸素しか推進力が無かったから帰ってこれなかったと思われるが…
肉体操作と再生能力があるから死なないんだッパープルヘイズみたいな殺傷力ヤバイ超即効性ウイルスで殺されても死後に蘇生するしな(ﾇｯ
ミーム汚染。現実の神殺しも解明していくと実は思い込みや噂でしかなかった、というように多数決で現実に影響を及ぼす魔法的な技術によって超越者を地に落とす
癌
消し方の方法なばいくらでも。例えば１『呪術廻戦』の『五条先生』を封印した『獄門疆』パターン。２レベルを上げすぎて霊化してしまい実体が消滅パターン、３.戦死した彼女の魂を求め、何処かへ旅立ったパターン
1.あっ呪術まだそこまで見てないからネタバレ食らったッ。2.割と綺麗な感じで好き。3.こいつがそれくらい一人の相手に心を奪われるような展開良いな
まだ読んでないけどジャンプ・作品のアンチ的な奴らに愚弄されてて悲しいんだ…
スタープラチナ・ザ・ワールドには対応出来ないけど何らかの方法で首を落としても死なないんだ。厳密には肉体が何らかの方法で死んでも即復活するんだ
胎界主の強くなりすぎて周りが認識できなくなった（超意訳）って設定好きなんだよな
しゃあけど残念ながら剣と魔法のファンタジー世界に味噌汁は無いわ！食事も不要な設定だしな(ﾇｯ
そいつに全員滅ぼしてもらえば勝手に退場してくれるのでは(雑) なぜか生き残った(または外来)主人公が世界の崩壊を紐解く話になりそうだが。
不殺とまでは言わないけどあんまり殺しはしない設定なんだ。そこが弱点と言えば弱点なんだ。
昔から不死身キャラは封印されるものと決まってるので罠にはめるか人質や何かの条件と交換で封印ですな。もしくは宇宙の果てとかの遠くに飛ばす。復活（帰還）の可能性を匂わすかどうかはその後の展開次第。
うむ…人質を取って封印した上で宇宙に放逐するのがこいつに一番効く対処法だと考えられる
タンスに足の小指ぶつけて痛さのあまり能力が暴走し、ビームが痛みを感じている神経を狙い頭から上半身にかけてを蹂躙 でいいんじゃね
痛いくらいで暴走するタイプじゃないんだよね。しゃあけど自分にビームを撃てば確かに自滅するわっ
どこでもドアかワープ装置で宇宙空間に飛ばしてしまえば。一番近くの銀河まで数百万光年かかるヴォイドに飛ばせば、まず、地球に戻ってくることはできない。
ワープ能力ないから遠距離追放はマジで対応出来ないんだよね…その手の対処法はベストアンサーに近いと思われる
うむ…一種の運命操作には入ると考えられる。デスノートも人間はともかく死神相手には効かないあたり人外には効かないと思われる
無敵バリア、“攻撃”では無い偶然の危害には有効なの？／能力バトルの金字塔であるジョジョは、戦闘能力では敵わないラスボスを運命の力で倒すというのがかなり意識されてて、個人的にはそういうのが好み。
うむ…「滑って転んだ結果偶然ヘッドバッドになってしまった」みたいなのは防げないと思われる。ジョジョは一部二部四部七部の倒し方は好きだけど三部五部のラスボス戦はごり押しな気がするんだッ六部はまあ普通
三体読もうぜ。こんなキャラの強い弱いとかどうでも良くなるよ。死神永生でのあれには絶対勝てない。平行世界に存在できないのも弱点でしかないな。水滴にも負けそう。
SF小説って難しそうなんだ。
説得。
一時的にその場で説得に応じてくれたとしてもすぐ約束を破るような奴って感じがするんだ。しゃあけど説得が足枷になって弱体化するって展開は使えるわっ
【返信終わり】
そもそも高い賃金が欲しくてプログラマーになったようなやつは勘違いしているようだけど
なぜなら経済として会社を支えているのはどんなときでも営業だからだ
現に9割9分の会社は技術などないが営業が優秀なので存続している
（ちなみにここでいう営業というのはプロモーションや戦略系も含まれる）
例えば流行の機械学習を生業としているようなベンチャー企業であっても
最新のトレーニング手法やパラメータ定義なんかを使っても得られる利益はほとんど無いのだ
Web系でもAngularだろうがReactだろうがVueだろうがどうでもよくて
とにかくデザイナーの出したものを忠実、もしくはそれ以上のものを生み出せれば技術などどうでも良いのである
という人もいるが、残念ながら全ての技術は5年後に負債になっている可能性が等しくあるということを理解していただきたい
そんな中で日本での人材流動性の高まりであるとかプログラマー育成問題なんかもあって
技術系（プログラマー）の市場価値が高まり、たまたま今だけ高給になっているわけである
卵が少なくなって卵の値段が上がったとしても
その卵が美味しいかと言われるとそんなわけはないのだ
どちらかと言うと腐った卵まで流通するのが恐ろしいところである
私が見てきたベンチャーの腐った卵には下記のようなジャンルがある
メガベンチャーや伸び盛りのベンチャー系に多く、特に旧帝大出身（特に東大）に多いのがこのパワハラ系
とにかく（自分の）理論が正しいということを前提に自覚無くパワハラを繰り返す
これが雇われ社員ならそれほど問題でもないのだが、経営者側のCTOなどだった場合は目も当てられない
テックだろうがベンチャーだろうが雇用主と雇用者という関係性は変わらないのに平気でゴリゴリパワハラを行う
雇用主側に主張されると組合も無い弱い立場の雇用者は何も言えない
その状況を理解していないのか雇用主側のパワハラはエスカレートしていく傾向にあり
社員は退職するが新しい人材は集まらずたいていの場合は逆に雇用主側が病む
この手のテックマウントパワハラ系の特徴は、ドメイン駆動や過度の抽象化、もしくは無駄な高速化や機械語への執念などが挙げられる
例示するのは難しいが、PRを上げてきた新人社員をSlack上で公開にボコボコに論破した上に
「社会人としてできて当たり前」
みたいなことまで説教を始める人を何人か知ってる
小さめで大きくなってきているベンチャーに多いのが、この結局全部自分でやる系
締め切りの前日もしくは当日、もしくは過ぎた後に自分で全部やり直す人
それまで部下や関係者が相談しつつ進めていても結局は全部ぶち壊して全部自分でやる
などというのは完全な素人で、単に他者に業務依頼できない人である
「言ってくれればもっと早く出来たのに」
ということしかない
そんな調子で依頼することができないので結局は自分で実装を繰り返し更に時間がなくなる
「俺ほどの技術力を持った人がいなくて困る」
みたいな自己肯定感を醸成しているのでそのうち上のパワハラ系へと移行していく
特徴としてはSlackにしろPRにしろ話が抽象的すぎて文章力が無い人である
「1を聞いたら10を知るのが当たり前だろ！」
と言う人が多く（1と10から100は分かるけど1だけで10を知ったら変態ですよ）
ヒドイ人になるとIssueやPRの管理も全然できず、ブランチも規則無く乱立してしまっていて
新しく入った人もいったい何をどうすればいいのかさっぱり分からない状況で放置してしまう
これも例示すると、新サービスの仕様だけは決まっていてページレイアウトが無い状態で
デザイナーの配属が難しいので実装側が考える、ということになったとき（割とある）
と言っても音信不通で渋々とこれまでのレイアウトを踏襲して3人できっちり作ったところ
リリース前日になってCTOが徹夜で全部作り直す、ということがあった
レイアウトも全然変わっていて、実はニュースリリースの段階から新規テーマになることが決まっていたらしく
それに合わせて全部作り替えたそうだ
新規テーマは1ヶ月も前から決まっていたのだから共有さえしてくれればそれに合わせて作ったのになぁ、という話をした
余談だがこういうときにこの手の人が「デザイン共有できず申し訳なかった」というような一言はほとんど無い
そういうコミュニケーションが取れる人は最初から業務依頼ができるのだ
最後が最近一番多いのだが、単に技術力が無くて頑張ってるだけの技術者
JavaScriptでリストの中に'apple'があるかどうかを調べる時に array.includes('apple')と書くとして、
10個のフルーツのリストがあってそれらが含まれているかを調べる時に10個のincludesを書いてしまうような人である
「せめてfor文で書こう」「そもそもデータ構造がおかしい」「というか本当にやりたい処理は？」
などなど様々な疑問が出てくるが、不思議なことにこれらを指摘しても絶対に直ることは無く、全く同じことを何度もやる
他にも例えば男性か女性かでメッセージを変えて出力しているコードがあったとする
if( gender === 'male') { ... } else { ... }
これに、20歳以下の場合は男女共通で違うメッセージを出す場合に
if( gender === 'male') { if ( age ＜= 20 ) { ... } else { ... } } else { if ( age ＜= 20 ) { ... } else { ... } }
みたいなコードを書いてしまう（20歳以下の部分は同じコードのコピペ）
メッセージ表示させるだけなら大したことないが、実際にはもっと複雑な処理をコピペで貼り付けるのである
そのため
「20歳以下の表示部分のバグについて、男性の場合は直ってるけど女性の場合に直ってない」
if ( gender === 'female' && age ＜=20 ) { ... }
これでもだいぶオブラートに包んでいて、実際にはもっと複雑なロジックをぐちゃぐちゃのまま整理せずに追加するのでとてもじゃないがメンテできない
（最近だとそういう部分はまとめてChatGPTに放り込むと綺麗にしてくれるので非常に助かっている）
こういう低レベルな技術者は結構いるのだが、大企業だと時間をかけて成長していくのに対して
ベンチャーになると自己肯定感が高いのか成長せずに偉そうである
「動いてるものは触らないで欲しい」
「Javaだとこういう書き方するんだよね」（そんなことはない）
みたいなことを言って、とにかく学習しない
曲がりなりにもそういう職に一度就いてしまうと指摘されることもないので学習しないんだと思う
特にCTOだとあくまで雇用主側の立場なので雇用者側から指摘されることも少ないし
同業他社のレビューなんてのもないからそこで時間が止まってしまうんだろうな、という感じ
こういう技術者のコードでも、見た目は動いているので営業側から見ると売るには問題ないのだ
なので営業が優秀だと下手に売れてしまって成功体験からますます自己肯定感が増して手が付けられないモンスターCTOの誕生である
「成功してから伸び悩んで大手企業が買収したけど技術的負債が凄まじ過ぎてリファクタリングだけで一大プロジェクトになる」
「リファクタリングが上手く行かずに仕様変更することになって『大手企業に買収されてダメになった』というレッテルが貼られる」
「当時のCTOは別の会社で新しい事業のCTOとして活躍している」
という流れはこうして生まれている
Photoshopのタイル構造はどのように実装したら良いですか？何か参考になるソースコードなどはありませんか？
Photoshopのタイル構造は、画像を小さな矩形のブロックに分割して、各ブロックを個別に処理することで実現されます。これにより、大きな画像の処理を高速化することができます。
このアルゴリズムを実装するには、以下のような手順が必要になります。
画像を読み込む
処理が完了したら、結果を保存する
以下は、Pythonで実装された簡単なタイル構造のコード例です。この例では、画像を単純にグレースケール化しています。
import numpy as np from PIL import Image # 画像を読み込む im = Image.open("input.jpg") # タイルのサイズを決定する tile_size = 128 # 画像をタイルに分割する tiles = [] width, height = im.size for y in range(0, height, tile_size): for x in range(0, width, tile_size): box = (x, y, x + tile_size, y + tile_size) tile = im.crop(box) tiles.append(tile) # 各タイルを個別に処理する for i, tile in enumerate(tiles): tile = tile.convert("L") tiles[i] = tile # 処理されたタイルを結合して、元の画像を再構築する output = Image.new("L", (width, height)) x = 0 y = 0 for i, tile in enumerate(tiles): output.paste(tile, (x, y)) x += tile_size if x >= width: x = 0 y += tile_size # 結果を保存する output.save("output.jpg")
このコードは、Pillowを使用して、画像の読み込み、タイルの分割、処理されたタイルの結合、結果の保存を行っています。このコードを改良することで、より高度な画像処理アルゴリズムを実装することができます。
回答ありがとうございます。しかし、実際にはこれに拡大縮小、タイルを跨いでのコピー＆ペースト、ペンツールでの描画などが加わります。拡大縮小は画像ピラミッドのようなもの、メモリ以上の巨大な画像を扱えるのはmmapを使っているのではないかと予想しています。これらを一言で回答するのは難しいと思いますが、何かアドバイスをいただけないでしょうか。よろしくお願いいたします。
拡大縮小、タイルを跨いでのコピー＆ペースト、ペンツールでの描画などを実装するためには、より高度なアルゴリズムとテクニックが必要になります。
拡大縮小に関しては、画像ピラミッドを使用することで実現できます。画像ピラミッドは、複数の解像度レベルで同じ画像を表現する方法です。画像ピラミッドを使用することで、拡大縮小のプロセスを簡単かつ高速に行うことができます。OpenCVやPillowなどのライブラリは、画像ピラミッドを構築するための機能を提供しています。
タイルを跨いでのコピー＆ペーストは、オーバーレイ技術を使用することで実現できます。オーバーレイとは、複数の画像を重ね合わせることで、新しい画像を生成する技術です。タイルを跨いでのコピー＆ペーストは、オーバーレイを使用して、複数のタイルを重ね合わせることで実現できます。また、透明度を使用することで、重ね合わせたタイルの一部を透明にすることもできます。
ペンツールでの描画に関しては、画像のピクセル単位での操作が必要になります。これは、OpenCVやPillowなどの画像処理ライブラリを使用して実現できます。画像のピクセル単位での操作には、色の変更、描画、消去などが含まれます。これらの操作を組み合わせることで、複雑な描画機能を実現することができます。
最後に、メモリ以上の巨大な画像を扱うために、mmapを使用することは可能です。mmapを使用することで、ファイルをメモリ上にマップし、ファイルと同じようにアクセスすることができます。これにより、ファイルがメモリに収まらない場合でも、ファイルの一部をメモリにマップし、必要な部分だけを読み書きすることができます。ただし、mmapを使用する場合は、適切なメモリ管理が必要であり、オーバーヘッドが発生する可能性があるため、十分なテストと調整が必要です。
検算しろとは言うけど必ずしもできるとは限らないんだよな。そもそも計算できないからコンピューターにやらせてる処理もある。理論的には正の値になるはずだけど、ごく稀に誤差でゼロや負になった時に、バグるみたいなのも再現難しくて辛い。
メモリーまわりは、高速化のために生ポインタでアドレス計算してる時はどうしてもミスる時がある。偶然ゼロ初期化されてるところを見てればそのまま動いちゃうけど、実行環境が変わると違うとこ見てて落ちるみたいなパターンも辛い。
ランダム性を持たせた処理というのは、ある種の最適化とか数値計算とか。そもそも答えを出すために処理してるから、正解がわからないしなかなか再現しないこともあって辛い。
