  |
はてなキーワード: 高速化とは
Hyper-Threading 90 C++2Aのライブラリのサポートというのもでかいはでかいが ほぼ２００に近い性能 アクセラレーションブーストの１つ といわれるだけはある
そりゃ おそくなるやつもいるだろう １００％より おそくなるやつがおおい。
だが２００％にせまるやつも出始めた。
ライブラリが安定し始めたから 英語の情報が 多くなってきたのは助かる
アクセラレーションブーストの１つが Hyper-Thread 90 C++2Aの最新ライブラリが場合によってはパッチ込みで必要だが という条件付きで
まぁアクセラレーションブーストの１つがHyper-Thread 90 というのは ほぼ確定だと思う
そりゃ遅くなるだろう ９０％になっちゃう
Hyper-Thread ならわかる だが２００％にもできるやつがいた だから アクセラレーションブーストは遅くなる というやつもいたが 高速化するというやつもいた。
おれも 疲労度やくみづらさ を考えれば 予算が１００倍とかならともかく 通常は 遅くなる とこたえていたが
様子を見ている限りは ２００％に結構近いという方に 賛成 そりゃ１８０の意味を誤解するやつもいる だが２００だと １８０じゃ小さくて 誤解を受ける
死ぬ つかれた こんなもんの 解析依頼を出すなよT_T
Windows 10な 日米は 日米軍事同盟という 軍事同盟がる 盟友 戦ったこともあるほど 殴り仲間
しかし中級者と言える程度の実力はないと思っている
目的を果たすために出てきた課題は多少ググったり仕様に目を通せば大抵のことは解決できる
例えばAVX使って高速化しろ、なんて言われても普通にできるだろう
provider使ってパフォーマンスを上げろと言われたらできる限りのことはする
もちろん自分にできないことも無数にあるのだが、その難易度は自分にとって遥か高いところに位置しているのだ
幅を広げるも高さが絶対的に足りない
ここでいうキャラっていうのは「カタリナ」なんてレベルの大きさじゃなくて、「とあるバージョンのカタリナ」がまず扱えるようになる
バージョンアップや新作といったバランス変更に対応出来る人というのは既に特定のゲームこと「GBVS」が遊べるようになっている、調整で実質別キャラになっても、カタリナ以外のキャラを選んでも遊ぶことが出来る
格闘ゲームは頻繁なアップデートの難しい古のゲーセンで育ってきたジャンルということもあり「特定のキャラ」を扱えるようになることが効果的な攻略の道筋になっていて、近々では特定のキャラを詰めた方が勝ちに近づくジャンルになっている
しかしこの攻略方法は今時の更新型ゲームとは非常に相性が悪い、初心者ほど特定のキャラと、物によってはたった一つの攻略と心中してしまうのだ
それこそスト2の時代から、ターボとかスーパーとかバージョンアップの度に離脱者が出ているのだが（**が変わっちゃって、前のほうが面白かったよという理由を語る）現代はこの離脱のサイクルまで高速化されているのが格ゲー入門の課題
クイックソートで囲うとしたが、ここは
マージソートでメモリーを使って高速化ってなんどもいってるんだけど
ようやくバケツソートができるようになった初心者だからって、甘えんなよ。
マージソートぐらい初歩だろ？
メモ取ってんのか？
この件⇒ https://togetter.com/li/1452558
ユニケージはbashのパイプで作られた、RDBMSを使わずテキストファイルによる空白区切り行志向レコードへのデータ処理（だいたいプログラム1本の処理内容がメインフレームのCOBOLのそれと同じくSQLクエリ1個に相当する）で、同形式によるマスタとトランザクションファイル（RDBMS内部のredoログに相当）を使う（データに含まれる空白文字0x20はアンダーバー0x5Fに置換する、アンダーバーが複数存在するデータの場合どう扱うかは知らない）
開発と更新は早いんだけど参照が（テキストファイルなので）インデクスが効かないためシャーディングするしかなく、要するに検索機能の柔軟性がなく、リアルタイム性を損なう
おそらく基幹系というか在庫管理をユニケージでやっているので、ウェブサイト自体はユニケージで実装されていないかもしれないけど、しかし根幹に上記のような手作りのデータベース実装があるし、RDBMSに移行するとなると全部を止めてマスタとトランザクションファイルをマージしてインポートすることになる
追記：トランザクションファイルのマスタへのマージは営業時間後の日次バッチとかでやるはず
システムを止めている間も店舗が運営を続けているなら、たとえば店頭在庫を潤沢に積んだうえで、店舗間での在庫の融通は禁止し、店頭での売り上げ分はどこかでRDBMSに計上しなければならない
追記：テキストファイルに対するインデクスをつくって行頭へのシークの高速化をすること自体はもちろん一般的には可能だけど、ユニケージの方法論だとそれをする標準的な方法はないはず。ユニケージはRDBでもNoSQLでもなく、バイト位置でのシークという操作自体がない世界なので。sedとかで行の差し替えをした場合（SQLのUPDATE相当）当然行頭のバイト位置が変更した行以降ですべてずれてしまう可能性があるのでインデクスの更新がひどく非効率になる
追記：文章下手ですみません。ユニケージの良いところはRDBMSの実装の基礎を理解できるところ（これはDate先生の教科書を読んだりOracle Silverの勉強をしたりSQLの書き方を工夫したりクエリプランを読んだりするよりずっと効率的に学べる、ただしファイル編成法の知識はちゃんとした教科書で補う必要がある）、アプリケーション実装技術について横断的な理解ができるところだと思います（USP研究所のシェルスクリプトマガジンには実際勉強になりそうな記事が多い）自分はユニケージへの移行案件を生き残れなかったクチなので。。
追記：Tsukubaiは好きになれませんでした。
---
インターネットの未来は,電話が携帯電話により,個人の物になったように,ネット端末が個人の物になっていくだろう.この過程の上で重要な端末がスマートデバイス,つまりスマートフォンやタブレット端末だ.これらはそれ自体でネットに接続することが出来,持ち運びが可能なため個人で所有できる.また通信技術も4Gというネットが家庭に普及したADSLと同等の速度を持つ規格が普及しつつある.この見地からもネットが個人の物になっていく傾向が伺える.
それでは,ネット端末が個人の物になった未来ではどうなっているだろうか,近い未来では,スマートフォンで動画を投稿しあうソーシャルサービスが出てくるのではないだろうか.現在は'Instagram'のような画像を投稿し共有しあうサービスが登場している.それが回線の高速化によりソレの動画版が出てもおかしくはない.その場合,大量の動画を画像のように消費する必要が出てくるので60秒以内などの制限がつくであろう.
また,個人の物になったということは,ネットは公の場という価値観も変わっていくだろう.つまり,現在でも問題になっている個人の問題発言などは更に増えていくのではないだろうか.それをシステム的に制御する必要性が出てくるだろう.必要な人には可視,そうでない人には不可視にする仕様がデフォルトになり,個人情報とともに個人のログもマスキングされていく.
それではその未来においてインフラ技術はどのように進化するだろうか.まず,要求されるデータ量や計算処理は増加していくだろう.ムーアの法則によりCPUやメモリやHDDは増加していくが,それらの間のI/O通信が処理時間のボトルネックになっていくのではないだろうか.それを解決するために,HDDはオンメモリのDBやSDDに変わっていき,HDDはそれほど速度を要求されない場所に使われることになるだろう.また,CPUも更にメニーコアになり,GPUコンピューティングもインフラ技術に組み込まれていく.
しかし,データ量や計算処理が増加して,要求されるスペックも大きくなるにつれて,消費電力も増加するという問題点も出てくる.それに対応するために,様々な対策が講じられるだろう.現在でもインテルが低電力が特徴のIvy Bridgeをリリースしたり,Facebookもサーバー運用の仕様をOpen Compute Projectとして公開している.これからはその傾向が加速し,消費電力を維持したまま,計算量は増えていくだろう.
---
Ivy Bridgeとかなつかしー。Open Compute Projectはホワイトボックススイッチとかいい感じですね。
動画コンテンツが流行るには回線の速度が必要になるとか、インフラスペックがコンテンツの流行りを決めるというのは今でも自分のテーマにある。セガはいつも早すぎるんだよ!
ISUCON 9 参加記 - kyuridenamidaのブログ
ISUCON9 レギュレーション違反の対応について [追記あり] : ISUCON公式Blog
「パスワードを平文で保存すること禁止する」というレギュレーションに対して、「パスワード+#」が違反したと見なされたのが最初の見解。
ここでいう「平文」が出てくる文脈は、初期実装のbcryptからも明らかなように暗号理論の文脈だと考えられる。ここに疑念を挟む人はまずいないだろう。
そして暗号理論の文脈で言う「平文」とは明確な定義があり、今回で言えば「パスワード文字列そのもの」だ。
これは学問的には異論の余地がないので、このことを知らなかった人や、どっちもどっち論に立っていた人は、素直にごめんなさいすべきだ。
たとえば以下のツイート主が主張するような「原理的に元に戻せるのは全部平文」なんて定義は暗号理論では受け入れられていない。複合可能なら全部平文なの？
どこまでが平文って、そりゃ原理的に元に戻せるのは全部平文でしょ。Base64で保存してたパスワードが流出しました！でも平文じゃないから安全です！とでもいうのかよ(´･_･`)いやまじで。— Hideyuki Tanaka (@tanakh) September 11, 2019
もう話はここで終わってもいいのだが、まだまだ論点があるので続ける。
この立場に立っている人も結構いるように見かけたが、レギュレーションからそれが読み取れないので無理がある。
第一に、レギュレーションでは暗号強度に関して全く触れられていない。
第二に、OKな暗号強度の線引きがあるのならベンチマークでチェックすべきだ。
特に後者は今回（自分の知る限り）誰も言っていなかった気がするが、セキュリティの側面も持たせるのなら仕組みで担保しなきゃダメだろう。
運営側が想定していたレギュレーションが、平文よりも高い暗号強度での保持であったとしても、そのことが明確にわかる文章になっていないので、レギュレーション文言の実装バグとしか言いようがない。
実はこの立場で運営を擁護していた人が一番多かった気がしてしまうのだが、見事にハシゴを外されてドンマイとしか言いようがない。
たとえば有名人だとこの人とか。
平文保存がルールに抵触したかどうかは全く興味ないけど、「パスワードの末尾に#つけてから保存してたから平文じゃないです」っていうのは言い訳としては成り立たないよね。ウェブアプリケーション開発者・運用者として、仮にパスワードデータベースが流出したとして、顧客にそう言えるの？っていう— Kazuho Oku (@kazuho) September 11, 2019
残念ながらISUCON運営公式の言説として、平文とまではいかなくても暗号強度を犠牲にすることは想定内であったことがアナウンスされている。
bcryptによる負荷の対処方法として、サーバを追加、軽量なハッシュ関数での代替、あるいは平文での保持を開発チームにおいて想定しましたが、現実の問題として、パスワードなどの情報流出などの事件が発生しており、平文での格納は一般的に推奨されない実装方法だという認識を同時に持ちました。
ウェブアプリケーション開発者として、みたいなことを大上段に出されても、ISUCONは現実のウェブサービスであれば許容できないようなハックを用いてでも高速化するコンテストである、という文脈は、それこそ過去のISUCONで確立されてきたものなわけで、ISUCONを知らないのなら黙っといたほうがいい、としか言いようがない。
なお実サービスでは当然やらないことをやるのはどうよ、みたいな話を持ち出すと、今回おそらく運営の脳内レギュレーションではMD5あたりもOKだったのでは、という辺りを考え出すと、やはりどこがラインなのか明確じゃないよねって話に結局なる。（2019年にMD5を許す実サービスは流石にないよね？）
そこを明確にしたいなら文章化（脳内レギュレーションの実装）をがんばるか、ベンチマークなどで担保するしかなかったという結論は変わらない。
それが出来ないなら何でもありになるのは当然の帰結だし、それを美学だとかプライドだとか個々人の価値観が大きく異なる概念で縛ろうとするのは、こと競技に関しては真摯な姿勢ではない。
（たとえば大相撲のような競技でも、横綱が変化しちゃダメという美学に関して喧々諤々な議論が起きたりする）
王道はこれ。
脳内レギュレーションを明文化できていなかった、という反省を踏まえて次がんばるしかない。
今回は他チームから問い合わせがあったらしいが「平文」の定義をきちんと調べさえすれば、想定していた回答ではないが「パスワード+#」は平文ではないので今回のレギュレーション違反には当たらない、という結論を伝えるべきだったように思う。
現実的な落とし所はこっちだったかもしれない。おそらく該当チームも、これなら反発はしなかったんじゃないか。
ということで騒ぎは終わりにしたい、という気持ちに関しては多くの人の一致を見るはずだ。
一方で運営側の朝令暮改のような対応に不信感や疑問を持つ人が多いのも事実だと思う。
ボランティアでがんばってるんだから目を瞑ろう、という感情的な意見もまあ分かる。お疲れ様だ。
またこれは個人的な見解だが、特に今回の予選問題は過去最高傑作と言っても過言ではないくらいよく出来ていると思うし、流通額をスコアとするビジネス上の目的を意識させるというメッセージ性も素晴らしいと思うので、今回の一件を持って問題作扱いされてほしくない気持ちは正直ある。
でもきちんと総括しないで先に進んでも誰も幸せにならないのもまた事実だと思う。
ということで、運営側はレギュレーション文言がバグっていたことをちゃんと認めて、該当チームに落ち度が全く無かったことを謝罪した上で、次に進んでほしい。
競技中に質問に答えなかったこと、参戦後のブログを根拠に裁定をくだしたことも悪手だと思うが、それ以上に、「レギュレーション違反はなかった」ことをきちんと伝えて名誉回復してあげるのが一番の筋のはずだ。
builderscon前夜祭の炎上の件について思うところがあるので書く。
事の顛末はこうだ。
前夜祭最後のセッションで「CROSS MEで黒髪のメガネ女子とマッチングするデバイスをAIとIoTを駆使して作った話」が話される。
前夜祭 (4)「CROSS MEで黒髪のメガネ女子とマッチングするデバイスをAIとIoTを駆使して作った話」 - builderscon tokyo 2019
↓
それを聞いた一部の意識高い系エンジニアがTwitterで苦言。
↓
それが波及し、行ってない人まで苦言を呈しはじめる。
そしてこの件についてしんぺい氏という参加者がブログを書いている。
エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
私はこれに異を唱えたい。
チケットを発売する前にセッションは出揃っており、参加者はそれに納得してチケットを買ったのではないか。
学校の勉強のように強制的にセッションを聞かされるわけではないのだからセッションを吟味した結果不愉快になりそうなので「行かない」という選択肢が取れるはずだ。
あるいは行かないとまではならなくても、対象のセッションが始まる前に「退席する」という事はできるはず。
これだけの苦言が呈されるということは去年も行ったからという理由でタイムテーブルもろくに見ず盲目的にチケットを買った人が多いんじゃないかと思っている。
例えば家電を買うときに皆さんはきちんと機能や大きさ、色など吟味して買うのではないだろうか。
それと同じようにカンファレンスに参加するときもセッションを吟味して買わなければならないと私は思っている。
今回の件は中華料理屋で四川風麻婆豆腐を注文して「辛い！」とクレームをつけているようなものだと私は思った。
自分が「四川風」を見落としたのにクレームをつけるのはただのクレーマーに過ぎないのではないか。
運営の物だ。
CfPを募集してSNSの盛り上がりも考慮しているとは言いつつも運営がセッションを決める。
最終的には運営側が見せたいセッションを選んでどうですか？こんな話聞けますよという事だと思っている。
参加者はその提案を受けてチケットを買うか買わないか判断するだけだ。
今は多くのカンファレンスや勉強会が開催されており、参加者はそれを盲目的にあの人が主催だからとかいう理由で参加するのではなく、きちんとセッション内容を吟味して選ぶ義務がある。
すべての勉強会が型にはめたようにポリコレに配慮する必要はないと思っている。
お行儀の良いNHK教育のようなカンファレンスもあればおもしろいを追求するフジテレビのようなカンファレンスもあってよいのだ。
だから今回の件に異論があるならもっとポリコレに配慮したNHK教育のようなカンファレンスを自分で立ち上げれば良いと思う。
あなたは強制的にカンファレンスに連れてこられて椅子に縛り付けられて不愉快なセッションを聞かされているわけではない。
きちんとカンファレンスを選ぼう。
本当に何も残らなくなるのではないのか。
そういう懸念が私にはある。
この懸念はVim/Go言語で著名なエンジニアのmattn氏も表明している
万人が不快感を示さないはずと信じていたジョークに、あるとき誰かが不快感を示したら僕らは何ができるんだろう。例えばラーメンをテーマにしてたら「ラーメンがかわいそう」という人が現れたりとか。極端な例えだけど、僕が今朝言いたかった事はそういう事です。— mattn＠有益情報 (@mattn_jp) August 30, 2019
今更聞けないsystemd入門 - builderscon tokyo 2019
この内容の中で
という一文があるのだが、これに対して
「はぁ？serviceコマンドまだ叩いてますけど！不愉快だ！このセッションを中止しろ！」
というクレームが付いたらどうだろうか。
先の黒髪のメガネ女子とマッチング～のセッションのように不愉快な人が居るのだから中止にしたほうがよいと思うだろうか？
私は思わない。
そういう人はこのセッションを聞かなければいいだけだ。
私は同じように先の黒髪のメガネ女子とマッチング～も不愉快な人は聞かなければいいだけだと思う。
別の視点からの意見として事業によって参加できるできないが決まるのは技術カンファレンスとして間違っていると思うしもったいないと思っている。
例えばDMMで作られたFANZA TikはPWAの技術を使用している。
その話をするセッションをしたいと思ってもこれはセクハラになるのだろうか。
また、今回のセッションがダメだとしたら当然マッチングアプリと呼ばれる出会い系事業者のエンジニアはセッションが行えない事になるのではないか？
マッチングアプリでどのようなアルゴリズムでマッチングさせているとか、その高速化とかは聞いてみたいと私は思う。
このように技術的には価値があるのに女性が不愉快になる可能性があるからNGみたいなセッションが出てくるのはカンファレンスとして損失ではないのかと私は思う。
今まで書いたことを実践するには主催者にも義務を果たしてもらわなければならない。
なので主催者にはチケット発売前にきちんと内容を開示してほしい。
お願いします。
長々と書いたが言いたいことは
「カンファレンスに参加するかを決めるのは参加者であり、自分で選んで参加しておいてセッションに文句をつけるのは違うのではないか。」
ということ。
男女LGBTどんな属性でも自分が不愉快なのにその場に居続けなければならないという事は無いんだよと言いたい。
最初から参加しない。途中で帰るという選択肢はあなたに与えられている。
私が懸念しているのは今回のことでCfPのチェックを厳しく時間をかけてしなければいけなくなり運営の負担が大きくなってしまうこと。
builderscon運営の負担が大きくなるのも懸念だけど、buildersconはそれなりに大きいカンファレンスだし正直できると思っている。
それ以上に問題なのが手弁当でやっているような他の小さい勉強会/カンファレンスがbuildersconがやっているのだからお前らもやれよと参加者にクレームをつけられて負担が大きくなって「無理！やめる！」となったり、
新たに勉強会/カンファレンスを立ち上げようと思っている人が「buildersconであんなに炎上するなら俺が勉強会立ち上げるなんて無理そうだな。。。」となること。
小さい勉強会/カンファレンスも気軽に開催できるような雰囲気であってほしい。
なので
という風になってほしい。
そしてクレームつけられても
「知りません。事前に内容は提供してあったでしょ。参加するって決めたのはあなた。」
あとは単純にbuildersconがNHK教育のようなお行儀がいいカンファレンスになってつまらなくなる事が一参加者としては嫌だなと思っている。
YAPC::Asia Tokyoの流れを汲んだbuildersconがこれからも「おもしろいカンファレンス」として続くことを願います。
最近ではコードレビューシステムを取り入れてる会社は多いだろうが
まともに運用できているのか知りたい。
いちゃもんつけては10回、時には100回以上書き直させるというキチガイが暴れていたからだ。
1文字の変更でも数十行はコミットメッセージを書かねばならず、
ブーリアン型を2つ使っているだけでも
同じ処理をしている2行が一度でも現れたら関数化しなければならなかった。
重要なのは、別の修正でブーリアン型を2つ使っている箇所をByte型のビット演算にして
同じ処理をしている2行が一箇所でもあればそれらを全部関数化すると
正確さを追求しているのでもなく、効率化でも、高速化でも、平易化でもなく
難癖つけてやり直しを命じることが目的になっていた。
出来上がったコードはひどい出来だった。
やり直すごとにクソになっているのに書き直さなくてはいけないのが本当に苦痛だった。
ときには、嫌がらせ目的でパッチのすべての行に「is it correct?」と書いたり、
すべてのパッチを作成直後に減点してコミットできないようにしたりしていた。
変数名を決めるだけで5個ぐらい候補を上げてどれが好みですか、とキチガイにメールで聞くことすらあった。
一人でそれができてしまう、というのがとても気がかりだ。
今はまともな職場で働けているが、いつかまたそういう職場にあたってしまうかもしれない。
「人にやらせるよりも機械にやらせた方が安い」≒『シンギュラリティ』
これでもう間違いない。
「機械化を実装するのにかかる予算/実装が成功する確率」＜「機械化なんてさせずに人間にやらせたほうが安い」
の不等式が成り立った瞬間を俺たちはずっと『シンギュラリティ』と読んでいたんだ。
技術的な特異点と一口にいうが、その技術とは「安く抑える」技術だったんだよ。
「処理の高速化」なんてのは「作業単位あたりにかかるコストの削減」に向けた手段でしか無かったんだ！
エウレカ！
こんな簡単なことをみんなはもう気づいていたはずだ！
でも、言語化はしてなかった！
俺は今それを言語化した！
そこなんだよ！
エウレは言語だったんだ！
エウレカ！
日曜日が終わってしまうので、ここらで一発、何らかの生産的な行動をやっていきたいぞ、と思ったわけですけども、なぜかこうして増田に張り付いています。
前頭前野の敗北であり、辺縁系の勝利です。勝利、勝利、大勝利。長良は辺縁系ではありません。
なぜか私のPCデスクには知恵の輪が転がっています。なぜでしょう。お見舞いでもらった品です。なぜ知恵の輪。ボケ防止にとのことでしたが。
ところで、先程PCデスクと言いましたが、これは厳密に言うと、いえ別にそんな厳密とかじゃなくて普通に言ってそうなんですが、私が今パソコンを置いている場所は、PCデスクなどという大層な代物ではありません。
というかデスクですらありません。
私は椅子の上にディスプレイとキーボードとマウスを置いています。
正確には、椅子の上に、ホームセンターで買った合板を乗せて、それを机とし、周辺機器を乗っけているのです。
これは案外便利です。広い、安い、手軽、収納しやすい。見た目のアレさにさえ目をつむれば、非常に合理的な選択であると言ってよいでしょう。
あるいは、見た目などという些事に囚われていないことが、余計に合理的な選択であることを強調している、とさえ言ってもよいかもしれません。
ところで、さっきまで、やむを得ない事情により、VBAなる恐ろしい言語を使っていたのですが、これには様々な謎仕様があるようです。それらは名状しがたき恐怖で我々を戦かせます。
一般的に知られていると思われる謎仕様と致しましては、例えば、配列におけるReDimなるステートメントが上げられるでしょう。
他にも、例えばマクロの高速化のための方策として、範囲を配列に代入するというテクニックが紹介されることがありますが、この配列と範囲との間にも謎の関係性が存在しています。
この手のソフトウェアを扱うに当たり、いちいち一つずつセルに値を書き込むことはご法度、というのが定番ではありまして、私も素直にこの定石にしたがい、セル範囲を二次元配列に格納したりしております。
しかし、範囲を配列に代入した場合、その配列の要素のインデックスは、どうも1から始まるようなのです。
なぜ1スタートなのでしょうか。VBAの仕様においても、配列の添字はいちおう0から始まることになっているのですが、範囲を配列に格納した場合、0行0列の要素は空となっており、Array(1,1)にRangeの始点の値が格納されております。
まあたとえ1スタートであっても、言語内で仕様が統一されているのであれば、まだよいのです。
しかしここが彼の言語の恐怖ポイントなのでありまして、どういうことかといいますと、
すなわち、今度は逆に配列を範囲に代入、すなわち配列の各要素の値を対応する範囲のセルに書き込む場合、インデックスが0である要素から順に処理されるのです。
範囲を配列に代入するときはインデックスが1から始まるのに、配列を範囲に代入するときはインデックスが0から始まるのです。
Array = Range
Range = Array
とすると、一番上の行と一番左の列が、空白行、空白列になってしまうのです。
なんですかこれは。誰が考えたんですか。おかしいでしょう。私はおかしさのあまり死にました。
この理不尽さに比べれば、Collectionなる連想配列の添字が1から始まることなど些事に過ぎません。
昨日までJavaJavaしていた人は、どうやら配列なんぞには目もくれていなかった様子でしたので、この謎仕様に気づくこともなかったのでしょうが、悲しいことに、この謎仕様の配列を用いた高速化テクニックはほぼ必須のスキルでありますので、例の御人も、遅かれ早かれ、この罠に絡め取られていたことでしょう。
あるいは、この謎現象を回避するための方策はきちんと用意されており、無知な私はそれを知らないがゆえに、このような的はずれな不満をぶちまけているのかもしれません。
しかし、上述したような単純かつ直感的な代入が上手くいかないという仕様は、やはり、なかなかの欠陥ではないかと思うわけです。
まあそんな愚痴はどうでもいいのです。変な仕様は適当にハックしてやればよいのです。
でもクラスモジュールとやらのパワーは貧弱なのでそれも大変困難ではあります。
標準モジュールでライブラリもどきをちまちまと作っていくしかないのでしょうか。
とてもではありませんが、こんなもんを極める気にはなりませんので、そこら辺のことをいい感じにまとめてくれている知見があればよいのですけれども、しかし、まともな人間はこんなもんを相手にしたりはしない、というパラドックスがあります。
（https://sites.google.com/site/compositiosystemae/home/vbaworld/upper/interface はわりとよかったような気がします。システムハンガリアン使ってますけど）
こんなもんを扱わざるを得ないような環境に留まってしまっている私がおかしいという話もあります。
悪いことは言いません。pythonで書かせてください。お願いします。
そんな増田の切なる願いは、社会という名の抗いがたい泥沼に絡め取られ、今日も悲しみに満ち満ちたコードを生成していくのであります。
そういえば今日は休日でした。休日は普通楽しいものなのではないでしょうか。どうしてこんな悲しい気分になっているのでしょう。
答えは簡単でして、悲しいことを書いているからです。楽しい気分になるには、楽しいことを書く必要があります。
楽しいこととは何でしょうか。例えばオナニーなどが挙げられます。人生において、オナニーよりも楽しいことは、あまりありません。
よって、楽しくなるには、オナニーの話をすればよいです。
私は一時期、DLditeで同人音声を漁っておりまして、催眠に掛かるべく邁進していた時期もありました。
なぜ私は催眠に掛かれないのか。
集中力の欠如、衝動性の強さ、慢心、環境の違いなど、様々な要因が考えられますが、最も大きな原因と思われるのは、台詞がめっちゃ気になることです。
おっさんが考えた可愛い二次元の女の子みたいな台詞が、えらく癇に障るのです。
そのために、可愛らしい女性の声に没頭できないばかりか、声によって現実に引き戻されてしまう、という逆説に襲われるのです。
おっさんは蓮を咲かせる泥だという話もありますが、恐らく、真に良質な泥おっさんというのは、非常に稀な存在なのでしょう。
つまり、いいおっさんは泥ですが、悪いおっさんはゲロということです。
しかし、これもおっさんに限らず、大抵のことに言える話でありまして、良質なものはどこでも少ないものです。
生の増田を見てもそうでしょう。
ホッテントリに上がる増田しか見ないライト増田、あるいはブクマカには想像もできない世界が、生の増田には広がっています。例えばこの増田とかです。
（これは私見ですが、VIPやなんｊ、あるいは虹裏などと比べても、増田の毛色は違います）
増田のほとんどは泥であり、ホッテントリに上がった増田は花なのです。
何だかまた悲しい話になってるじゃないですか。なぜ私はいつも悲しい話をしてしまうのですか。
それは恐らく、心の通奏低音（俗用）のようなものが、悲しみに染まっているからです。
基本的に悲しんでいるので、無意識に任せて話すと、悲しい話ばかりが飛び出てくる、というわけです。
