「高速化」を含む日記 RSS

はてなキーワード: 高速化とは

2020-05-25

anond:20200525012727

残念ながらそうではない。外付けGPUってコスパ悪いんだよね。

わかりやすい例だと、CPUGPU間のデータ通信が遅い。

まり

CPUだと計算時間100msecだったのが、

普通GPU搭載マシンだと、

CPU計算時間10msec + データ通信10msec + GPU計算時間 5msec =合計25msecて感じで

4倍高速化になるんだけど

これが、外付けGPUだと

CPU計算時間10msec + データ通信60msec + GPU計算時間 5msec =合計75msecて感じで

微妙な感じになっちゃう。

2020-05-18

風呂およびラップトップ

風呂はいろうかな?

風呂に入ろうかな?妻が先ほど「追い焚きが・・・」って言っていたのでもうReadyなきがする。ちっと下りて聞いてコヨーテ

 古いラップトップWindows10アップグレード

しか高速化ということでいろいろやってある程度マシになったが、なんか疲れてきた。そうまでしてWindows OSにこだわらなければならない

理由は?なにかな?っていう気分になってきたので、お風呂気分転換しよぅ。

2020-05-13

anond:20200513081538

いや、給付金制度が万全かもチェックしないとならないでしょ、、、、。

それから経済を再開しようと思えばやはりしらみつぶしにコロナ感染者疑いは隔離しないとならない。とすると、PCR検査はやっぱり増やして隔離を進めないとならないわ。

あと作業が滞ってるのなら、現在ライン別に高速化ラインも準備し始めないとならない。今のラインに負荷をかけない方法でな。

2020-05-11

今日はあっという間に一日終わり

午前中は慣れてない遠○○修なんてやったのでえらい時間を食われた。古いラップトップ高速化するとかで色々作業ソフトインストールも行ったわ。ああああしんどい。あとリポ関係か?もうほぼ6時やで( ^ω^)・・・明日もっと要領よくいこうぜ!!

2020-05-10

Windows10高速化億劫

億劫って漢字で書くとこうなるんだ?!自宅にあるデスクトップ以外は(おもに職場だが)

というどうしようもないメンバだ。職場ではパスワード保護したマイクロソフトオフィス文書を送り付けることが常態化している。あと日本語ファイル名の添付文書問題もある。ファイル文字化け問題回避のために職場Windows10マシンが1台は必要だ…_| ̄|○

メールのエチケット守ってくれればいいだけのこと

添付するならファイル名は英語・・・あとみんながマイクロソフトオフィス持ってるわけじゃないんだからパスワード保護するな!どうしてもしたいならZIP側に保護設定しろ!できれば添付もやめて宅ふぁいる便かにしろ

どちらかはLinuxマシンちゃうとしても、一台はのこしておかねばなるまい。Windows10高速化して、現実的スピードにする改善必要億劫だ。「不要アプリ削除」って簡単にいうけど、アプリの削除って手作業から・・一個一個削除。時間食う。質の悪いアプリ再起動をそのたび要求するし・・ノートパソコンメーカーパソコンから、どうでもいいアプリがいっぱいプレインストされてそう。ああああああああ!

メーカーさんよ!!

頼むからchocolatey使ってプレインストールしてくれよ。頼むわ。

2020-04-29

anond:20200428143858

こういうゲーム攻略っていうのは段階があって、

最初特定キャラが遊べるようになる

次は特定ゲームが遊べるようになる

最後ジャンル(他のゲーム)が遊べるようになる

ここでいうキャラっていうのは「カタリナ」なんてレベルの大きさじゃなくて、「とあるバージョンのカタリナ」がまず扱えるようになる

バージョンアップや新作といったバランス変更に対応出来る人というのは既に特定ゲームこと「GBVS」が遊べるようになっている、調整で実質別キャラになっても、カタリナ以外のキャラを選んでも遊ぶことが出来る

格闘ゲームは頻繁なアップデートの難しい古のゲーセンで育ってきたジャンルということもあり「特定キャラ」を扱えるようになることが効果的な攻略道筋になっていて、近々では特定キャラを詰めた方が勝ちに近づくジャンルになっている

しかしこの攻略方法は今時の更新ゲームとは非常に相性が悪い、初心者ほど特定キャラと、物によってはたった一つの攻略心中してしまうのだ

それこそスト2時代からターボとかスーパーとかバージョンアップの度に離脱者が出ているのだが(**が変わっちゃって、前のほうが面白かったよという理由を語る)現代はこの離脱のサイクルまで高速化されているのが格ゲー入門の課題

Windows10高速化

今どきこんなネタって感じかもしれないが、当該ブログを閲覧してたら、「クラウドアプリ動作を遅くするのでアンインストール推奨」とあった。ファンレスCPUデスクトップがすぐに熱暴走する問題解決のためにラップトップと交代で使おうとしている俺は軽い衝撃。

クラウドアプリの使えないWindows10マシンなんて

クリープを入れないコーヒーみたいなもの。InvokeWebrequestで毎朝クラウドの中身をうわー!ってダウンロードする?参考文献とかデータ集とかクラウドアプリに保存?職業動画とかは扱わないし・・・それ以降はそれぞれのハードディスクアクセス

何でもかんでもGitHub

そうする?最近在宅ワーク始まってからテキストベースで何とかなる部分(コードとか報告書原稿とかCSVとか)はリポジトリにぶっこむようにしてるが・・

そうまでして

熱暴走やすい古い(わけではない)マシンを使い続ける理由とは?

2020-04-17

スマホもう買い換えないか

新型iPhone SEを今ポチった。

128GBを選んだので6万ちょいくらいだった。

安い安いと聞いてたけど正直高く感じる。

そもそも今持ってるスマホじゃダメ理由がないかもしれない。

ゲームiPadでする。

WiFi6はNASとの通信高速化に欲しいが、今でも45MB/sくらい出てるしそれで十分速い。

長年待ち望んだSEだったが4インチでもない。

うーん、ひと通りさわったら返品しようかなぁ…。

OSが非対応になるまでは今のままでいいかも。

2020-02-02

なんとかして、ゆっくり丁寧にやろうとしているのに

もっと高速化といわれてもな

もともとエンジン、そこまで上位じゃなくてもちゃんと記録とってるぜそこそこの大会

2020-01-26

anond:20200126050922

人もモノも必要能力値を満たす個体が大量にあれば移動速度がどんどん高速化するんだよ。

個人視点から見ればそれは擬似的なものではあるけれど、経済学的にはそれで十分だ。

増田東京無職になったコンマ5秒後に増田互換人材沖縄就職すれば、それは人材としての増田が高速移動してるのと経済学的にはほぼ等価だ。教育なんてのはそのために存在する。

モノだって同じだ。東京セブンイレブンにある午後の紅茶帯広でも売っていれば、それは商材として高速移動しているのと同じようなものだ。Amazonネット通販アイテムを全国の倉庫分散して持ってるのはそういう意味だ。

2020-01-09

半導体を使った主記憶装置のうち、CPUからの直接的な一時アクセスの変わりに高速化されたもので、CPU外部にあることが多いものメモリーと呼ぶ場合

ヒープソートメモリー上の、スタック領域ではない、管理領域これをヒープと呼ぶにおくソートとした場合

ヒープからメモリーを確保して、ソートを行う方式ヒープソートと呼ぶことになるが

 

これ説明していくとながくなるので、ヒープソートって書いていい?

 

ところで、ヒープソートって英語日本語

2020-01-08

クイックソートで囲うとしたが、ここは

マージソートメモリーを使って高速化ってなんどもいってるんだけど

ようやくバケツソートができるようになった初心者からって、甘えんなよ。

マージソートぐらい初歩だろ?

メモ取ってんのか?

こんなことぐらい1度いわれたら分かれよ、マージソートなんて基礎だぞ、この業界どんだけ難しいとおもってんだ

マージソートぐらい1回の授業でメモして覚えろよ。石頭。

無印良品ウェブサイトが止まってる件について思うこと

この件⇒ 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は好きになれませんでした。

追記anond:20200115152201

2019-09-29

2012年就活で書かされたインターネット未来って課題が出てきたので貼ってみる。

---

インターネット未来は,電話携帯電話により,個人の物になったように,ネット端末が個人の物になっていくだろう.この過程の上で重要な端末がスマートデバイス,つまりスマートフォンタブレット端末だ.これらはそれ自体ネット接続することが出来,持ち運びが可能なため個人で所有できる.また通信技術も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はホワイトボックススイッチかいい感じですね。

動画コンテンツ流行るには回線の速度が必要になるとか、インフラスペックコンテンツ流行りを決めるというのは今でも自分テーマにある。セガはいつも早すぎるんだよ!

2019-09-22

anond:20190922194246

もう何年も前に実用化されてるぞwww

今はもっと高速化しようという段階

2019-09-12

ISUCON9予選のレギュレーションバグについて

ことの顛末

ISUCON 9 参加記 - kyuridenamidaのブログ

ISUCON9 レギュレーション違反の対応について [追記あり] : ISUCON公式Blog

TL;DR

本文

そもそもレギュレーション違反なのか問題

パスワードを平文で保存すること禁止する」というレギュレーションに対して、「パスワード+#」が違反したと見なされたのが最初見解

ここでいう「平文」が出てくる文脈は、初期実装のbcryptからも明らかなように暗号理論文脈だと考えられる。ここに疑念を挟む人はまずいないだろう。

そして暗号理論文脈で言う「平文」とは明確な定義があり、今回で言えば「パスワード文字列のもの」だ。

まりパスワード+#」は「平文」ではない。

これは学問的には異論余地がないので、このことを知らなかった人や、どっちもどっち論に立っていた人は、素直にごめんなさいすべきだ。

たとえば以下のツイート主が主張するような「原理的に元に戻せるのは全部平文」なんて定義暗号理論では受け入れられていない。複合可能なら全部平文なの?


もう話はここで終わってもいいのだが、まだまだ論点があるので続ける。

平文と同程度の強度は実質平文なのでは問題

この立場に立っている人も結構いるように見かけたが、レギュレーションからそれが読み取れないので無理がある。

第一に、レギュレーションでは暗号強度に関して全く触れられていない。

第二に、OK暗号強度の線引きがあるのならベンチマークでチェックすべきだ。

特に後者は今回(自分の知る限り)誰も言っていなかった気がするが、セキュリティの側面も持たせるのなら仕組みで担保しなきゃダメだろう。

運営側が想定していたレギュレーションが、平文よりも高い暗号強度での保持であったとしても、そのことが明確にわか文章になっていないので、レギュレーション文言実装バグしか言いようがない。

そもそも効率化のためにセキュリティ犠牲にするのはどうなのよ問題
ウェブアプリケーションとしてありえない実装ダメでしょ問題

実はこの立場運営擁護していた人が一番多かった気がしてしまうのだが、見事にハシゴを外されてドンマイとしか言いようがない。

たとえば有名人だとこの人とか。


残念ながらISUCON運営公式の言説として、平文とまではいかなくても暗号強度を犠牲にすることは想定内であったことがアナウンスされている。

bcryptによる負荷の対処方法として、サーバを追加、軽量なハッシュ関数での代替、あるいは平文での保持を開発チームにおいて想定しましたが、現実問題として、パスワードなどの情報流出などの事件が発生しており、平文での格納は一般的に推奨されない実装方法だという認識を同時に持ちました。

ウェブアプリケーション開発者として、みたいなことを大上段に出されても、ISUCON現実ウェブサービスであれば許容できないようなハックを用いてでも高速化するコンテストである、という文脈は、それこそ過去ISUCON確立されてきたものなわけで、ISUCONを知らないのなら黙っといたほうがいい、としか言いようがない。

なお実サービスでは当然やらないことをやるのはどうよ、みたいな話を持ち出すと、今回おそらく運営脳内レギュレーションではMD5あたりもOKだったのでは、という辺りを考え出すと、やはりどこがラインなのか明確じゃないよねって話に結局なる。(2019年MD5を許す実サービスは流石にないよね?)

そこを明確にしたいなら文章化(脳内レギュレーション実装)をがんばるか、ベンチマークなどで担保するしかなかったという結論は変わらない。

それが出来ないなら何でもありになるのは当然の帰結だし、それを美学だとかプライドだとか個々人の価値観が大きく異なる概念で縛ろうとするのは、こと競技に関しては真摯姿勢ではない。

(たとえば大相撲のような競技でも、横綱が変化しちゃダメという美学に関して喧々諤々な議論が起きたりする)

運営はどうすべきだったか

今回は見逃して次回からルール文化をがんばる

王道はこれ。

脳内レギュレーションを明文化できていなかった、という反省を踏まえて次がんばるしかない。

今回は他チームから問い合わせがあったらしいが「平文」の定義をきちんと調べさえすれば、想定していた回答ではないが「パスワード+#」は平文ではないので今回のレギュレーション違反には当たらない、という結論を伝えるべきだったように思う。

運営側が求める最低限の強度の実装で追試験

現実的な落とし所はこっちだったかもしれない。おそらく該当チームも、これなら反発はしなかったんじゃないか

今回は競技中の質問に回答をしなかったという問題もあった。

まりこういうことを伝えたらどうだったか



今後のこと

まだ本戦があるんやで

ということで騒ぎは終わりにしたい、という気持ちに関しては多くの人の一致を見るはずだ。

一方で運営側の朝令暮改のような対応に不信感や疑問を持つ人が多いのも事実だと思う。

ボランティアでがんばってるんだから目を瞑ろう、という感情的意見もまあ分かる。お疲れ様だ。

たこれは個人的見解だが、特に今回の予選問題過去最高傑作と言っても過言ではないくらいよく出来ていると思うし、流通額をスコアとするビジネス上の目的意識させるというメッセージ性も素晴らしいと思うので、今回の一件を持って問題作扱いされてほしくない気持ちは正直ある。


でもきちんと総括しないで先に進んでも誰も幸せにならないのもまた事実だと思う。

ということで、運営側はレギュレーション文言バグっていたことをちゃんと認めて、該当チームに落ち度が全く無かったことを謝罪した上で、次に進んでほしい。

競技中に質問に答えなかったこと、参戦後ブログ根拠裁定をくだしたことも悪手だと思うが、それ以上に、「レギュレーション違反はなかった」ことをきちんと伝えて名誉回復してあげるのが一番の筋のはずだ。

2019-09-02

参加者にはカンファレンスを選ぶ義務がある #builderscon

builderscon前夜祭の炎上の件について思うところがあるので書く。

事の顛末はこうだ。

前夜祭最後セッションで「CROSS MEで黒髪メガネ女子マッチングするデバイスAIIoTを駆使して作った話」が話される。

前夜祭 (4)「CROSS MEで黒髪のメガネ女子とマッチングするデバイスをAIとIoTを駆使して作った話」 - builderscon tokyo 2019

それを聞いた一部の意識高い系エンジニアTwitterで苦言。

それが波及し、行ってない人まで苦言を呈しはじめる。

そしてこの件についてしんぺい氏という参加者ブログを書いている。

エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

私はこれに異を唱えたい。

チケット参加者自主的に買ったもの

チケットを発売する前にセッションは出揃っており、参加者はそれに納得してチケットを買ったのではないか

学校勉強のように強制的セッションを聞かされるわけではないのだからセッション吟味した結果不愉快になりそうなので「行かない」という選択肢が取れるはずだ。

あるいは行かないとまではならなくても、対象セッションが始まる前に「退席する」という事はできるはず。

これだけの苦言が呈されるということは去年も行ったからという理由タイムテーブルもろくに見ず盲目的にチケットを買った人が多いんじゃないかと思っている。

それではダメなのだ

例えば家電を買うときに皆さんはきちんと機能や大きさ、色など吟味して買うのではないだろうか。

それと同じようにカンファレンスに参加するときセッション吟味して買わなければならないと私は思っている。

今回の件は中華料理屋で四川風麻婆豆腐を注文して「辛い!」とクレームをつけているようなものだと私は思った。

自分が「四川風」を見落としたのにクレームをつけるのはただのクレーマーに過ぎないのではないか

カンファレンス参加者のものではない

運営の物だ。

CfPを募集してSNSの盛り上がりも考慮しているとは言いつつも運営セッションを決める。

最終的には運営側が見せたいセッションを選んでどうですか?こんな話聞けますよという事だと思っている。

参加者はその提案を受けてチケットを買うか買わないか判断するだけだ。

税金も投入されていないので市民の声を聞く必要もない。

今は多くのカンファレンス勉強会が開催されており、参加者はそれを盲目的にあの人が主催からかい理由で参加するのではなく、きちんとセッション内容を吟味して選ぶ義務がある。

すべての勉強会が型にはめたようにポリコレ配慮する必要はないと思っている。

テレビチャンネルのように選択すればよいのではないか

お行儀の良いNHK教育のようなカンファレンスもあればおもしろいを追求するフジテレビのようなカンファレンスもあってよいのだ。

から今回の件に異論があるならもっとポリコレ配慮したNHK教育のようなカンファレンス自分で立ち上げれば良いと思う。

あなた強制的カンファレンスに連れてこられて椅子に縛り付けられて不愉快セッションを聞かされているわけではない。

きちんとカンファレンスを選ぼう。

不愉快排除していった先

今後全員の不愉快排除していったら一体何が残るのだろうか。

本当に何も残らなくなるのではないのか。

そういう懸念が私にはある。

この懸念Vim/Go言語で著名なエンジニアのmattn氏も表明している

ラーメンジョークとしても例えばこのセッション

今更聞けないsystemd入門 - builderscon tokyo 2019

この内容の中で

2020年にはCentOS 6がEOLを迎えますが、まだserviceコマンドを叩いている、なんて言いませんよね?

という一文があるのだが、これに対して

「はぁ?serviceコマンドまだ叩いてますけど!不愉快だ!このセッションを中止しろ!」

というクレームが付いたらどうだろうか。

先の黒髪メガネ女子マッチング~のセッションのように不愉快な人が居るのだから中止にしたほうがよいと思うだろうか?

私は思わない。

そういう人はこのセッションを聞かなければいいだけだ。

私は同じように先の黒髪メガネ女子マッチング~も不愉快な人は聞かなければいいだけだと思う。

エロ事業出会い系事業者は発表できるのか?

別の視点から意見として事業によって参加できるできないが決まるのは技術カンファレンスとして間違っていると思うしもったいないと思っている。

例えばDMMで作られたFANZA TikはPWA技術使用している。

その話をするセッションをしたいと思ってもこれはセクハラになるのだろうか。

また、今回のセッションダメだとしたら当然マッチングアプリと呼ばれる出会い系事業者のエンジニアセッションが行えない事になるのではないか

マッチングアプリでどのようなアルゴリズムマッチングさせているとか、その高速化とかは聞いてみたいと私は思う。

このように技術的には価値があるのに女性不愉快になる可能性があるからNGみたいなセッションが出てくるのはカンファレンスとして損失ではないのかと私は思う。

参加者カンファレンスを選ぶ義務を果たすために

今まで書いたことを実践するには主催者にも義務果たしてもらわなければならない。

それはセッション内容の開示である

勉強会/カンファレンスの内容がわからないと選びようもない。

なので主催者にはチケット発売前にきちんと内容を開示してほしい。

お願いします。

まとめ

長々と書いたが言いたいことは

カンファレンスに参加するかを決めるのは参加者であり、自分で選んで参加しておいてセッション文句をつけるのは違うのではないか。」

ということ。

女性排除しろ!」等とは微塵も思っていない。

男女LGBTどんな属性でも自分不愉快なのにその場に居続けなければならないという事は無いんだよと言いたい。

最初から参加しない。途中で帰るという選択肢あなたに与えられている。

私が懸念しているのは今回のことでCfPのチェックを厳しく時間をかけてしなければいけなくなり運営負担が大きくなってしまうこと。

builderscon運営負担が大きくなるのも懸念だけど、buildersconはそれなりに大きいカンファレンスだし正直できると思っている。

それ以上に問題なのが手弁当でやっているような他の小さい勉強会/カンファレンスがbuildersconがやっているのだからお前らもやれよと参加者クレームをつけられて負担が大きくなって「無理!やめる!」となったり、

新たに勉強会/カンファレンスを立ち上げようと思っている人が「buildersconであんなに炎上するなら俺が勉強会立ち上げるなんて無理そうだな。。。」となること。

小さい勉強会/カンファレンスも気軽に開催できるような雰囲気であってほしい。

なので

という風になってほしい。

そしてクレームつけられても

「知りません。事前に内容は提供してあったでしょ。参加するって決めたのはあなた。」

と言えると運営が楽なのではないか

あとは単純にbuildersconがNHK教育のようなお行儀がいいカンファレンスになってつまらなくなる事が一参加者としては嫌だなと思っている。

YAPC::Asia Tokyoの流れを汲んだbuildersconがこれからも「おもしろカンファレンス」として続くことを願います

2019-07-30

anond:20190730095437

まり

3DCGアニメ表現を取り入れる事(ペルソナのドカバ吹き出しアーク格ゲーアニメに見える3DCGなど)を進化としてしまって、グラフィックの向上や戦闘システム高速化などスペックアップによる進化が成されていない」

って事?

2019-07-29

anond:20190729120744

ほーん 解説ありがとう

 

どれもそうだけど通信高速化(容量軽減)策は

人為的ミスによる脆弱性をひろげるものともなり得るので

もっと文系じじばばにわかやすい「仮称 相互協力新幹線ネット ※ご利用は計画的に」とかい名前つけないといかんと思うぞ

それさえできれば総務省パブコメ投げて終わりだろ

2019-06-29

私はIT企業で働くプログラマだ。

最近ではコードレビューシステムを取り入れてる会社は多いだろうが

まともに運用できているのか知りたい。

私が以前勤めていた会社では地獄運用がされていた。

変数プラス1するだけのパッチでも

いちゃもんつけては10回、時には100回以上書き直させるというキチガイが暴れていたからだ。

1文字の変更でも数十行はコミットメッセージを書かねばならず、

ブーリアン型を2つ使っているだけでも

メモリ無駄からビット演算しろとか

同じ処理をしている2行が一度でも現れたら関数化しなければならなかった。

重要なのは、別の修正ブーリアン型を2つ使っている箇所をByte型のビット演算にして

同じ処理をしている2行が一箇所でもあればそれらを全部関数化すると

今度は読みづらい・非効率から直せと言われる。

まり間違っているから直さなくてはいけないのではなく、

正確さを追求しているのでもなく、効率化でも、高速化でも、平易化でもなく

難癖つけてやり直しを命じることが目的になっていた。

出来上がったコードはひどい出来だった。

簡単コードが難解になればなるほど彼は満足げだった。

やり直すごとにクソになっているのに書き直さなくてはいけないのが本当に苦痛だった。

ときには、嫌がらせ目的パッチのすべての行に「is it correct?」と書いたり、

すべてのパッチ作成直後に減点してコミットできないようにしたりしていた。

変数名を決めるだけで5個ぐらい候補を上げてどれが好みですか、とキチガイメールで聞くことすらあった。

この会社でのコードレビューシステムは完全に崩壊していて

一人でそれができてしまう、というのがとても気がかりだ。

今はまともな職場で働けているが、いつかまたそういう職場にあたってしまうかもしれない。

(そういう会社に限っていつも大量に募集してるものだ)

1文字修正でも10回以上やりなおせと言われる職場はどれくらいの割合存在するのか。知りたい。

2019-04-27

シンギュラリティが何処にあるかようやく分かった

「人にやらせるよりも機械やらせた方が安い」≒『シンギュラリティ

これでもう間違いない。

機械化を実装するのにかかる予算/実装成功する確率」<「機械化なんてさせずに人間やらせたほうが安い」

の不等式が成り立った瞬間を俺たちはずっと『シンギュラリティ』と読んでいたんだ。

技術的な特異点一口にいうが、その技術とは「安く抑える」技術だったんだよ。

「処理の高速化」なんてのは「作業単位あたりにかかるコストの削減」に向けた手段しか無かったんだ!

エウレカ

こんな簡単なことをみんなはもう気づいていたはずだ!

でも、言語化はしてなかった!

俺は今それを言語化した!

そこなんだよ!

エウレカとは言語化だったんだよ!

エウレは言語だったんだ!

ラテン語言語はエウレなんだ!

エウレカ

2019-04-07

日曜日が終わってしまうので、ここらで一発、何らかの生産的な行動をやっていきたいぞ、と思ったわけですけども、なぜかこうして増田に張り付いています

人はなぜ、このような選択をしてしまうのでしょうか。

前頭前野の敗北であり、辺縁系勝利です。勝利勝利、大勝利長良辺縁系ではありません。

なぜか私の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やなんj、あるいは虹裏などと比べても、増田の毛色は違います

増田ほとんどは泥であり、ホッテントリに上がった増田は花なのです。

私も泥として、増田たちに養分供給していきたいと思います

何だかまた悲しい話になってるじゃないですか。なぜ私はいつも悲しい話をしてしまうのですか。

それは恐らく、心の通奏低音(俗用)のようなものが、悲しみに染まっているからです。

基本的に悲しんでいるので、無意識に任せて話すと、悲しい話ばかりが飛び出てくる、というわけです。

この休日も悲しいまま終わりそうです。恐ろしい恐ろしい。これも人生という感じですね。

2019-03-15

仕事高速化だけでは幸せになれない

大量生産とか、高速化とか、そういう生産性向上ができる市場では

生産性向上の競争になって、結局ジリ貧になる

 

2倍生産たから2倍儲かるだろう!と思ったら、市場相場が1/3になって結局儲かってないみたいな話になる

走り続けることを強制され、走るのを止めると死ぬが、走りきった先にも何もない

 

重要なのは生産性向上ではなく、市場優位性でしかないんだ

生産性生産量/単位リソース」ではなく「生産性市場平均」だ

 

足が速い、生産性向上しやすそうな市場は魅力的にうつるが、寿命も短いから注意しなければならない

それに気づかないと生産性向上の競争に陥ってやがて死ぬ

それを知った上で走る大企業ももちろんたくさんあるけれど

 

____

 

もっとわかり易い例

時間労働市場と、受託納品するタイプ市場だと、意外と時間労働の方が安定する

時間労働ってのは生産性向上が見込めない手がかかる物が多い

2019-03-13

anond:20190313182132

javascript高速化に貢献してる部分もあるのだがな。

増田ダイアリーの「▼言及エントリを開く」もjavascriptだけど、これないとすげぇ使い辛くなると思う

ログイン ユーザー登録
ようこそ ゲスト さん