【固定用記事】アナウンスまとめ

一覧について

一覧画面から『のーたいとる』カテゴリの記事を非表示にするスクリプトを動かしています。

思考回路をそのまま吐き出した極めて個人的なカテゴリなので、興味のある方は上記リンクをご利用ください。

LoLカレンダー(※正確さは保証しません / 随時更新)

C9の試合は網羅未定(EGを追うかも)、LCKとLCSは注目カード、LPLやLEC、LJLはほぼなし(主に私の観戦日程)。

【ネタバレ】プリコネR第一部の雑記

もしも仮にあのボスがロールプレイなのだとしたら、別にこの世界のメタ話なんて挟む必要もないし、現実側と干渉していたのはすべてボスの攻略のためでしかない。

確かにキャルの話とか色々で現実を見かけていたけど、別にそれなんて必要な下りだったかっていうと曖昧で、グラブルで言うところのグランサイファーメインメンバーの過去話みたいなところじゃないかなって気がする。それよりも若干、将来的な興味を惹かせるとか、そっちに寄せた感じだけど。

コッコロが現実に出てきたのはいいんだけど、まあ結局は晶さんが体よくその後干渉するための布石みたいな感じであのタイミングだったのかなーって印象はある。

キャルのエピで現実を介したのは、ぶっちゃけ現実であるかというよりか、大惨事のゲーム内でしゃべるわけにいかねーだろっていう解釈が一番いいんじゃないっすかね。

というかあれ現実っぽい見た目をしていたけど現実じゃなくて、マジな方の記憶の中っぽい気もする。そういえばペコリーヌだったかコッコロがそう言ってたっけ?

日記:2020-05-20

結構たくさんの新アルバムがリリースされているのそれについて書いていきます。

Run Girls, Run!さん、藤井風さん、flumpoolさんがワタシ的に気になったものです。

まだflumpoolさんの曲は聴いていないのと、ランガさんのアルバムは気になった曲だけ、藤井風さんのアルバムは書きながら聴いてます。

まずRun Girls, Run!さんから、一番気になったイルミナージュ・ランド、キラッとプリ☆チャンシーズン3 OPを聴いてみましたが、結構シンプルで、意外な展開はないですね。一方でシンプルなOPという点で極めてキャッチーで、3期からも取り込んでいこうという意気を感じます。

藤井風さんは「もうええわ」で刺さって気になって結構気にしていました。まずアルバムの楽曲を見て面白いと思ったのは、既存曲をすべて1, 2, 3, 4曲目で完結させているところですね。

よくあるパターンとしては、1曲目に新曲or1曲目に一番の人気曲、以降に既存曲を挟むパターンだと思っていて、1, 2, 3, 4で既存曲を持ってきたのはすごく面白いパターンだと思います。それもリリース順。

まるで、進化順を追っかけてくれと言わんばかりのセトリにまず惹かれますね。

そして新曲一発目の開幕早々に、昭和歌謡曲みたいなイントロから藤井風さんらしいメロティと声が流れてきてあ~~~~~~~~~~~~~~~これが面白いんだよ!!!!!!!!!!!!!!!!!!!!!!!!!って感情が押し寄せてきた。

のーたいとる(2020-05-17版)

私は文章をドバドバ書くのが好きです。

え? 知ってるって? それは私のファンですね。今すぐFanboxで石油王コースを突っ込んでください。こちらから多分チェックできます。

それはそうと、なんかドバドバ書きたいんで書きます。若干ネガティブ気味な表現を含むので逃げたい人はどうぞ逃げてください。

昨日は10時から休憩を抜いても6時間くらいは発表会を聞いてました。疲れたっていうか、やる気あるのかっていうコメントしかできないですね。

確かに自分にも欠点は見つかったし、フィードバックを受けてどういった展望にするかを見据えることもしました。

別に私は完全であることを求めているわけじゃないんですよ。

ただね、自分の研究分野について、勉強不足ですっていうの、たしかに分野によっては学習難度が極めて高いこともあると思うんすよ。一部の方は確かに難易度が高いから数ヶ月かけて学習するのわかるよねっていうのありましたよ。

でもさ、お前それもわからんのにそれで卒業目指すの?てっていう程度の状況で、流石に明らかに見えてる次すら進んでないよねっていうのも多いんすよ。

ここまでの3年間ってなんなんだろうなってめっちゃ思うところはあります。自分はWebを知って、プログラミングは色々あれど、私にとってはクリエイティブなプログラミングがあってるなって理解をして、誰かに何かを届けるための技術を追いかけてきました。

それは、自分のとっての三年間で学べると思った範囲に留めたりとか、現実的な範囲に収めるための取捨選択の結末なんです。

私には三年間でクリエイティブで、パフォーマンスを発揮させつつ可読性上優れたコードを、マネタイズなどを考慮した上で、適切な宣伝の上で広めて展開するなんてことはできませんでした。

悔しいけど、それは事実なんです。私にはそれができないって思ったんですよ。

私は私の思う良いを表現したいと思って、より多くの人に届けられるプラットフォームに惹かれただけです。

偶然にもお仕事は巡り会えて、私の思う「好き」が刺さるサービスに携われる気がしてすごく嬉しいです。私はこのツイートが真理だと思っていて「好き」って感情は何にも負けないだろって信じていたりします。私も上に負の感情を書いたのでなとも言えないんすけど、負の感情じゃなくて「好き」を推してほしいなって思ってます。

あなたの「好き」はほんとに人を救います。

なんでこの記事を書いたのかも、前半なんかめっちゃ文字量多いのに記憶にないけどまあとりあえずリリースしますね。

日記:2020-05-09

普段よりなんか勢いよく飲んでるので怪文書を残して死んだら察してください、

 

このあたりの続き。

人類は生きるためじゃなくて、豊かに生きるための時を歩んでいるんだなって考え方をした。
私は誰かを豊かにするから、誰かは私を豊かにしてほしい、って構図が理想なんだと思うんだよ。
でも現実に、生きるためだけに働くのだって必要じゃないですか。いやまあ、生きられるって豊かなんだけど。なんていうんだろう……。

なんだろうなぁ、難しいね。私のための世界ではこの仕組みを変えてみようかなあ。

日記:2020-05-07

久しぶりの日記です。駄文を大量に綴るのには誰の迷惑にもならないこの場所が好き。

アイカツ一話を見ているのですが、3DCGは間違いなくタツノコプロのほうが上に感じるんだけど、アニメーション部分に比べて3DCGは少女漫画っぽく目が大きすぎて手足がクソ細いっていう特徴のせいで生々しさが感じられないことにあるのかもしれない。

それはそうと、一話のアイドルライブを見に行く前日と後日の対比がめっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっちゃエモくないですか? 「煌めきに触れてしまった日の夜」をここまでうまく描けるのすごくいいと思うんすよね。

あと格言、それでいいんすかね? 今はまだそう思わんだけ?

---

映像研には手を出すな!に興味があったんすけど、独占配信なので仕方なく諦めることにした……。

---

二話の序盤からいちごとあおいの今後をなにか意識させるカットを挟むの良い。

---

しかしまあ、VALORANTのレイテンシやらをベータで調査しておきたかっただろうに、このご時世でそもそも世界中のネットワークが想像以上に耐えられていないって話もあるので、"普通"の日常でどうなのかを今判断することはできなさそうだよね。

dragleaveを制御するカウンターを用意するためにVueのemitを使った話

こんにちはMarcoです。今作っているi4Sketchで詰まったのでメモしにきました。

個人的なメモなのでサンプルとかちゃんと用意してません*1。他の所探してもなんもわからん……って方は藁にもすがるような感じで参考にしてください。

Drag and Drop APIというのはまあ名前の通りで、Drag and DropをするためのAPIで、Drag中に貯めておくデータ置き場やらどんな処理をするかのタグ付け、あとはDragやdragenter、dragleave、dragoverなどのイベントが用意されている感じです。

詳しくはMDNとか仕様書読んでください。

本題

状況など

まず詰まったのが、子要素に移るとdragleaveが親で発火するという挙動です。

いやお前まだ中におるで……とは思いましたけど、子に入ったということは親直下から離れたのでleaveなんでしょう(多分)。

んで、stackoverflowではこれに対してcouter作るといいよ!って言われてました。発火順としてはenter -> leaveのようなので確実にカウントできるみたいです。

ただ、Vue(のようなコンポーネントベースでスコープが切られている)環境だと親コンテキストの制御に子の生イベントは使いにくいです。

生の伝播を利用すると親の親の親の……まで伝播していくので、例えばenter時になにか計算を挟んで背景色を操作する、みたいな処理をする必要があるなら制御がめんどくさすぎて吐血します*2

私のケースだと子でも処理が必要だったのと、dragoverでやるのはパフォーマンス上割けたかったのでemitさせて自前のイベントで処理することにしました。

やりたいこと

その要素内にdragがあるかを管理して、その要素からleaveするときに0であれば本当に消えたことを保証する。

子に移動したときは子のdragenterをemitして、+1(初期値) -> +2(emit enter) -> +1(dragleave)という流れを作る。戻ってくるときは子のdragleaveをemitして +1 -> +2(dragenter) -> +1(emit leave)という流れを作る。

外部に移動するときは +1 -> 0(dragleave) になるので処理をする。

発火の順序について

カウンター用途でemitするので発火順序は非常に重要になります。

div(親) > img(子)で試してみました。*3

dragleave: function (event: DragEvent) {
    console.log("leave", self.element.tagName);
    event.stopPropagation();
},
dragenter: function (event: DragEvent) {
    console.log("enter", self.element.tagName);
    self.$emit("bubbles-dragenter");
    console.log("entered", self.element.tagName);
    event.stopPropagation();
},
"bubbles-dragenter": function () {
    console.log("listen emit enter", self.element.tagName);
},
"bubbles-dragleave": function () {
    console.log("listen emit leave", self.element.tagName);
}

こんなのを用意しました。

マウスをdiv -> img -> divとしたときのconsole.logがこうなります。

  1. enter img
  2.  listen emit enter div
  3.  entered img
  4.  leave div
  5.  enter div
  6.  entered div
  7.  leave img
  8.  listen emit leave div

まずenterが発火して、そこから呼ばれたemitが発火します。

次に親にleaveが発火して一旦終了。

今度は親に動かすと、enterが発火して、子のleaveが発火、そこから呼ばれたemitが発火します。

emitされたイベントはキューに入るのではなくて即時に発火されることがわかったのでよかったですね(?)。

あ〜なんかこの記事書いたのはいいけど中身が薄くて公開するか迷うけど公開しちゃお。

自分のための記事なのでセーフ!よしっ!

*1:用意しようと思ったけど意外とめんどくさそうだったのでやめました

*2:処理が一番親だけにあるなら伝播させたほうがcounterの実装が容易だと思います

*3:手元で親の領域から投げ込みやすいのがimgだったからです。特に理由があるわけじゃないです。