Posted Articles

Pinned Articles
【これは】Ci-enのマイページにNSFW画像が表示されるのでぼかし処理を施した【バグ?仕様?】

いらにか Jun/19/2023 19:16 Updated: Jun/20/2023 01:25

【これは】Ci-enのマイページにNSFW画像が表示されるのでぼかし処理を施した【バグ?仕様?】

ことの発端 Ci-enのマイページで一般(全年齢)フロアにいるはずなのに、支援しているクリエイターの記事の欄はR18でも容赦なく表示される。 なんでやねん!!(怒り) 一般とR18を分けておきながら、なんでマイページは区分けされないんだ?(謎) DLsite Playには(すべて|全年齢|R18)みたいなフィルタがある。 けど、そんなフィルタはCi-enに実装されていない。 設定にも該当するような項目はない。 https://twitter.com/happy_packet/status/1670704853163864065?s=20 ただし、Ci-enは一般とR18はドメインが区分けされている(えらい)。 なので「R18ドメインの画像ならCSSでブラー(ぼかし)フィルタかけるようにすればいいかな」と私は思った。 実に安直だが、当然の思考だと思う。 しかし、一般フロアに記載されているR18記事は、なんと一般フロアのドメインからリダイレクト(又はプロキシ)を経て参照するように設計されているではないか!! 要約すると、ドメインでR18の画像だけにフィルタをかける手段がなくなった。 まぁクロスドメインにならないので、CROSで苦労っすみたいなことも減るし簡単だからサイトの実装手段として気持ちはわかる。わかるけどもさぁ……(声にならない叫び) (ぱっとみた感じだとクリエイターのIDやURLで区別もされていないし、R18判定は無理なんじゃないかと思います) https://twitter.com/happy_packet/status/1670709357896675328?s=20 というわけで、ブチギレた僕は一般フロアに表示される支援しているクリエイターの記事の画像すべてにブラー(ぼかし)をかけると固く決意した。 無ければ作る。 それが一番早い。 dlsite-dark2の改良 というわけで、以前作ったdlsite-dark2を速攻で改良して対処した(もう過去形)。※ChromeWebストアでの公開には審査とか色々あるのでアップデート版の配布は後日になります。 一般フロアのマイページ(https://ci-en.net/mypage)のみ、支援しているクリエイターの記事全てのアイキャッチ画像にCSSでブラーを施している。 画像をホバーするとブラー処理が解除される地味に便利な仕様。 適用しているCSSはこれだけ↓。 #article-new-arrival-all > div.c-cardCase.is-multiCell.is-2line > div > div > div.c-card-header > a > div > img { filter: blur(9px); } #article-new-arrival-all > div.c-cardCase.is-multiCell.is-2line > div > div > div.c-card-header > a > div > img:hover { filter: none; } ブラーでの表示をやめたければ、R18のマイページにアクセスすればいい。 わざわざ、拡張機能内に設定を作らなくてもいいね。 ひとつ問題があるとすれば、モバイル(スマホ等)だと拡張機能が動かないので使えない。 Chromeの拡張機能がモバイルで動くようになるのが先か、 Ci-enがこの問題を解消するのが先か。 個人的にはChromeが勝ったら、笑い話になるのでChromeを応援したい。 まぁ実際にそうなったら、笑えないだろうけどね。 余談 もしCi-en自体を改善するとして、ぱっと思いつく案は DLsitePlayみたいに(すべて|全年齢|R18)のフィルタを作る R18アカウントの記事の画像はブラー処理する(ユーザが設定で有無を選べる) 一般はR18アカウントの記事が表示されないようフィルタする みたいな感じ。 1と2はどれも良さそうだし、両方実装してもいいのではと思う。 3を選んだら愚行だなぁと思う。UX的にも最悪だし、クリエイターもアウトリーチ的な導線が消えるので良いこと無いと思う。 (あくまで外野の個人の感想です)

0 Total Comments
5 Likes

いらにか Oct/26/2024 01:06

【雑記】Mesをアイコントーク対応させるためのあれこれ【遅々開発】

Ci-enでも時々取り上げてきましたが、個人的な趣味で脚本に特化した軽量記述言語Mesを研究開発しています。
簡単に説明するなら「セリフをデコレーション(装飾)するように、キャラ名やト書きといった情報をセリフに付与していくような記述言語で、JSONなどの構造化されたデータフォーマットに変換できる」のがMesの特徴です。


詳しく知りたい人はここをみてください


前の記事からもう1年以上過ぎてしまった事実に驚愕してますが、あれからも裏では報告しても何も面白くない実験やらプログラミングを黙々としていました。
新機能の実装というよりは概念実証とか思考実験とか。




そんなある日、Mesをアイコントークに対応させるための概念実証をしていたら、あることに気づきました。





キャラクターデコレーター”@”が持てる情報はキャラ名だけじゃん……




元々、(舞台や音声ドラマなどを意識した)脚本向けの記述言語として作ってきたので、従来はキャラ名だけで十分だと考えていました。
実際にチャットスタイルの出力はキャラ名だけで良かったので。


ですが、アイコントークでセリフ毎にキャラの喜怒哀楽のアイコンを使い分けたいと思った場合、現状のMesではキャラクター名を「いらにか(泣)」とか「いらにか(怒)」のようにするしかありません。


そうすると「いらにか(泣)」と「いらにか(怒)」は別々のキャラクターとして識別されるので、区別して別々のアイコンに紐づけることができるようになりますが、今度はキャラのセリフを集計しようとするときに「いらにか(泣)」と「いらにか(怒)」を合算するような集計ロジックを別途定義して書き換える必要が出てきます。
(自然言語を柔軟に読み取れる人間なら上記でも、キャラ名=いらにか、表情=泣、のように読み取れますが、機械にはパターンを覚えさせる必要があり少し厄介なのです)


まぁ集計が別々に分かれるくらいなら致命的ではないですが、すっきりとしない気持ち悪さが残ります。
(キャラクター名とアイコンの情報という違うデータを個別に保持できていないのが気持ち悪い)


というわけで、この問題を解消するために新しい言語使用の案をいくつか考えました。
その一つがアトリビュート案です。HTMLのタグの属性っぽいイメージです。


@いらにか ::img=泣きアイコン
生ぎたいっ!!!  //これがセリフ

↓データ構造はこんな感じ?
`
{

Charactor: {
    value: "いらにか",
    img: "泣きアイコン"
},
Dialogue: "生ぎたいっ!!!"

}
`


上記は安直な初期案で、::img="" のような形式だと速記性が悪い(imgを日本語入力のままだと”いmg”のように打ってしまう)ので記述方法はもっと練らないといけません。
そして、記述仕様が変わると解析プログラムも変更が必要になります。
この記述仕様に変更が加わるときのプログラムの修正コストが結構デカイので、どうにか軽減できないかという問題も実証実験したりしています。


完全に趣味の研究開発なので、単に実現することよりも「どうスマートに実装するか」を重視しているため進捗は著しく遅いです。
商業(仕事)だったら絶対にこんなやり方はしないですが、知的好奇心を満たしてスキルを磨くためなので、それを言い訳にして遅々として開発をしています。


実現重視のスピード開発はすでにシンプルMesエディタで散々やったので……

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

いらにか Sep/04/2024 21:25

【雑記】会話の思考はシーンに依存している説、それがTL精神汚染の要因?【メディア性質論】

前々からTwitter(現X)のタイムラインに(相手は悪くないけど)不快なポストが流れてくる現象について、個人的に「タイムライン精神汚染」と名前をつけて色々と原因を考えたりしていた。



一応、僕の環境ではTwitterのセーフティーフィルター設定をONにしていて、センシティブなR-18画像やグロ画像は基本的に自分で画像を開かない限り閲覧できないようにしている。
僕の性格上、公序良俗的に閲覧に場所を選ぶようなセンシティブな情報(エロ画像等)を不適切なシーン(例えば外出先のショッピングモール等)で摂取してしまうことにイラッとしてしまうので、事故を避けるためにもフィルターを自主的にONにしている。
アダルト系のリポストが多いフォロワーもリポストをOFFにしていることが多い。


なので”基本的”にはタイムラインにセンシティブな画像が強○表示されることはあまりない。
ただ、完璧には防げていないので稀にフィルターを貫通してセンシティブな画像が流れてくる。



一応誤解のないように前置きするが、「そういうポストをするな!」と言いたいわけじゃない。
僕だってTwitterでエッチな画像みたいときがるので、好きなエロ漫画家さんをフォローしてたりする。
Twitterの規約に違反するようなポストでない限り、そういうポストに罪はないし、センシティブフラグをちゃんとつけてくれている人もいるので、情報を取得する側(自分)が不快にならないようタイムラインを設定・構築することが望ましいと思っている。
SNSは自己防衛が基本だ。


ただ、少し前からある疑問を感じていた。


なぜ投稿を読む時のシーン(状態)で、そのポストに対する好感や嫌悪感が違ってくるんだろうか?


情報を摂取するときの精神状態によって、反応が違ってしまうのはよく知られている。
それがSNSだと顕著に現れているような気がする理由はなんだろうかと考えていた。


それについてひらめいた仮説がある。

まず前提として、人の会話時の思考はシーンにも依存していることを理解してもらわないとけない。
※理解している人は読み飛ばしていいです

会話の思考はシーンに依存している仮説

僕がこのことを学んだのは学生時代に人に近い会話Botを作ろうとした時のこと。
より人に近い思考をトレースしようと思った僕はフレーム問題に悩まされた。

このフレーム問題をざっくり説明すると、「状況を”深く”理解して行動しようとすると考慮すべき事項が多すぎて可能性が無限に発散するため、計算機では演算できなくなる」という話。
これは人間にも起こる問題で、状況を深く理解しようとすればそれだけ時間がかかる。
ただ、人間には「妥協」のような割り込み処理で計算を途中で終わらせることができ、その時点でのベターだと判断した行動を取ることができるので計算が無限に終わらない状態にはならないと考えられている。

ここですごいのは、人間は会話において相手の言葉から瞬時に状況を理解して自分の言葉を導き出しているということ。
しかも、ほぼ無意識のレスポンス速度で会話をしている人が多いのではないだろうか。

当時学生の僕は「なぜ会話で瞬時に結果を出力できるのか?」が疑問だった。
そこで導き出した仮説が「シーンエンジン」だった。
人間は脳の演算エンジンをシーン別に切り替えることで、その状況にあった最適な思考判断ができるようになっているのではないか?という仮説で、今風に言うなら学習モデルを利用シーンごとに切り替えているようなイメージだと伝わりやすいかもしれない。
それまで、自分の思考は1つのモデルであると思っていたが、よくよく観察してみると仮説は結構いい線なのではないかと思った。
なので汎用的な会話モデルよりは、シーンを限定することで、軽量かつ良質な会話モデルが作れると思って、「バレンタイン前日に彼女と喧嘩してしまったのでどうにか仲直りしてチョコをゲットしたいシーン」というギャルゲみたいなアホ設定で同級生の力を借りて、マンパワーで会話パターンを作り込んだ人工無脳を作ったのだった。

この会話パターンを作り込んでいて一番おもしろいと思ったのが、このシチュエーションだとシーンにそぐわない発言は一蹴しても会話が成立するという点。
喧嘩していて怒っている=理性を多少失っている状態で、関係ない話をしようとすると大抵の人は「いまそんな話してないよね?💢」と反感を覚えるはず。
シーンに関係ない話=シーンを転換させるような話題をキャンセルすることで、シーン固定ができるという点が非常に面白いなと思った。


そして「シーンに関係ない話=シーンを転換させるような話題」というのが今回の本題につながってくる。



【本題】SNSでタイムラインを見ている時、我々はどういう状態(シーン)なのか?

長い間、人のコミュニケーションは対面が基本だった。
そして会話には、トークテーマという話者間に共通した前提事項があった。
共通したトークテーマがあるからこそ、話者同士は相手の言葉に備えることが出来た。
インターネット掲示板でも、スレッドタイトル(スレタイ)がトークテーマの役割を果たしていたと思う。
つまり、会話においてシーンを(ある程度)固定することができた。


では、Twitterのタイムラインはどうか。
人によっては趣味別にアカウントを使い分けて、タイムラインをコントロールしているかもしれない。
そういう人は「この趣味(シーン)の話題」としてタイムラインを見ることができるので、投稿を読む時のシーンが定まっていて基本的に同じシーンモデルで思考・会話をしている可能性がある。


対して、趣味別に分けていないようなフォロワーが様々なトークテーマでポストしているタイムラインの場合、投稿を読む時のシーンモデルが定まっていないのでは無いだろうか。
つまり、ポストのトークテーマごとに異なるシーンモデルで思考・会話をしている可能性がある。
リアルに比べてインターネットは状況に関する情報量も少ないため、もしかすると、シーンモデルを適切に切り替えられないまま、投稿を読んで思考している可能性がある。
リアルでも会話のトークテーマが急に切り替わったとき、思考が追いつかずに混乱することはないだろうか?もしくは、誤解したまま話がアンジャッシュ状態になることはないだろうか。
こういう状態がタイムラインを見ている時に発生している可能性がある。


僕の場合、現実のシーンモデルをそのままタイムラインに持ち込んでいる可能性があり、公共の空間(シーン)でタイムラインを見た時にNSFWな画像が強○的に表示されると、公共空間のシーンモデルが強い嫌悪の反応をしている可能性が高い。
逆に寝る前のオフモードな状態で、NSWFな画像が強○的に表示されるとオフモードのシーンモデルではあまり嫌悪しないように思う。


この仮説を元にすると、例えば見る時間帯等によってタイムラインに流すユーザーを制限するだけでも(事故的な)嫌悪や不快感を軽減できる可能性がある。
もっと高度なアイデアとしては、スマホの位置情報などで「家にいる時」「公共施設」「職場」「電車の中」などリアルの状況(シーン)にあわせてタイムラインを構成できたら面白そうだと思ったところで気づいた。


これ、広告と同じ考えじゃん。




「ターゲット」に「適切な環境」で「効果的な情報」を宣伝すること。
言い換えれば、ターゲットの置かれた状況での思考(シーンモデル)をイメージして、効果的だと思う情報発信をすることが(事故的な)嫌悪や不快感を軽減する方法なのかもしれない。
そう考えると、ターゲットのシーンモデルが推察しにくい状態のタイムラインで、プロモーションすることは(事故的な)嫌悪や不快感につながってるのではないだろうか。
※もしかするとTwitterのプロモーションに嫌悪感覚える一因になってるかもしれない


そう考えると、SNSで見ている人が多いと言われる時間帯でもターゲットのシーンが推察しにくい場合では上手く刺さらない、もしくは真逆の反応になってしまうリスクもあるのではないかと思った。
もちろん、このプロモーションの仮説には穴が多くあるので有効性は怪しいが。




ただ、タイムラインにおけるシーンモデル問題は個人的に結構当てはまるので、時間帯やシーンごとにOKなユーザーリストを作ってホームTLの代わりに利用するのを検討してみようと思った。


やはり、メディア特性論に関する思考実験は面白い。

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

いらにか Jul/05/2024 23:22

【雑記】ソフトウェアの進化論【遺伝子】

長くソフトウェアの開発をしていると、ある壁にぶつかります。


それは 刷新 とか リプレース など色々な呼ばれ方をしているのですが、より抽象的に言うならば 進化 とか 世代交代 が表現として一番しっくりきます。


アップデートや機能拡張も類似するものですが、それらは 成長 という枠の中にいて、進化とは少し異なります。
皆さんにわかりやすく説明するなら、Windowsの遍歴を思い浮かべてもらうのが簡単かもしれません。
Windows10は月次アップデートで段々と成長していきますが、Windows10からWindows11に変わるようなアップグレードではUIや操作系、機能など様々なものが変わって、明らかにWindows10とは異なるものに進化しています。


一般の方は、なぜこのような進化をするのか疑問に思うかもしれません。
Windows10のままWindows11のように機能拡張することはできないのか。
特に、Windows7からWindows8系への移行では散々な言われ方をされてました。


これらの前提として、そもそもソフトウェア開発は生み出した後が本当のスタート地点であるという特殊さがあります。
現代のソフトウェアはリリースされた後も修正パッチやアップデートなどで、バグを修正したり機能追加したり、成長させることが当然になっています。
逆に不具合などが修正されず、メンテナンスがされていないソフトウェアは忌避される傾向すらあります。


「ソフトウェアはリリース後も継続的にメンテナンス(保守)される」という文化は、ソフトウェアの発展に大きく寄与してきましたが、同時に開発者の負担にもなっていました。
開発者が保守しなくなったことで、使われなくなっていったソフトウェアも沢山みてきました。
(その度に代替になるような派生ソフトウェアが台頭してきたりしました)


たぶん、この記事を読んでいる人も使わなくなったアプリやサービスがあるんじゃないでしょうか。


ソフトウェアの死というのは、誰にも使われなくなることだと思っています。
そして開発者は「自分」と「その他ユーザ」のことを考えてソフトウェアを成長させていきます。
ですが、大きくなりすぎたソフトウェアは次第に成長が遅くなり始めます。

自己を作り上げているソースコードが膨大になり複雑化し、不具合が増え、動作が遅くなり、過去のコードが足を引っ張って思ったように機能が実装できなくなり、Etc...といった感じで、膨大に積み上げてきた積木の上にさらにブロックを積むのが困難になるのはソフトウェアの宿命とも言える問題です。
もちろんこの問題と向き合うための学問や哲学などのエトセトラが多く存在しますが、少し脱線するので割愛します。気になる人はソフトウェア工学で調べてみてください。


こうなってくると、開発者は現状を整理して、より理想的に積み上げたソフトウェアが欲しくなります。開発者の多くは理想状態を好みます。
大抵はリファクタリングと呼ばれる整理・修正作業によって改善を試みますが、手が付けられないような致命的な欠陥があると、最早イチから作り直したほうが一番早いという結論にたどり着くことがあります。
そして、古いソフトウェアから良いものを受け継ぎつつ悪いものを排除した、新しいソフトウェアが生まれます。


これらに生命の進化論に通じる部分があると感じているので、冒頭の表現として進化がしっくりきているわけです。


ここまでの説明で、感の良い人は「ソフトウェアの退化」や「モダナイゼーション(近代化)」が起こることの必然性を受け入れられるかもしれません。
端的に言えば生命ですら現在の環境に最適化しようとして退化のような進化をしてしまうのだから、ソフトウェアでも同様の事が起こりえるということです。


Windows8で不評だったModernUI(MetroUI)は、当時の世界を席巻しつつあったモバイルデバイス(スマホやタブレット)を念頭に開発された経緯があり、WindowsがモバイルデバイスのOSに進出するための試行錯誤でもありました。
マルチデバイスでの統一を図るためにモバイルデバイスにおける当たり前(強○フル画面、横スクロール、タッチ操作など)をPCの世界にも持ち込もうとしたことで混乱が大きかった印象が個人的に強いですが、Windowsにおけるウィンドウの利便性が損なわれていたことが一番の失敗だったと思います。あとWindowsボタンのスタートメニュー。
まぁ話が脱線するので戻しますが、ここで重要なのはWindows8.1以後では操作系やUIをWindows7っぽく戻しつつもアイコンのデザイン面ではWindows8のフラットデザインの要素がモダナイズがされて残った点です。


Windows7からWindows10へ移行する人の中で、当時はよくアイコンのデザインの好き嫌いの話がされていました。
Windows7時代は立体感や質感の強いデザインのアイコンで、iPhoneも初めの頃は同様に立体感や質感の強いアイコンでした。
立体感を出すことで押せるものと認識させる意図があったりしたそうです[要出典]。


フラットデザインへの転換期にあたる2012~2014年頃、PCやスマホなどデバイスによって画面解像度やサイズが多種多様すぎることで、アイコンのデザインは苦しめられていました。
例えばリアルな写真のような128x128サイズのドット絵を16x16サイズにしようとすると、情報の欠如が多すぎて元の絵と印象がだいぶ変わってきます(そもそも同じように表現できないかも)
この問題を解消するため当時はフラットデザインやマテリアルデザインなど、マルチデバイスを意識したデザインがいくつか生まれました。
フラットデザインでは、元がシンプルであるためにサイズを変えても印象があまり変わりません。
ですが以前のアイコンの立体感・物体感が持っていた「押せる印象」がフラットデザインで失われたことで、ユーザの違和感に繋がり、前述の好き嫌い論争の一因になりました。
(一応フラットデザインでは薄いシャドウなどの浮遊感によって押せる印象をもたせていたりします)


このようにアイコンの進化があったおかげで、多種多様な解像度への耐性値があがりました。
もしかすると、この転換が無ければ近年のスマホの超高解像・巨大化は無かったかもしれません。


ユーザは以前のままで良かったと思っていても、開発者側に以前のままではいられなかった理由があったりします。
このギャップが(ユーザー視点での)ソフトウェアの退化につながる一因なのかなと思います。
X(旧Twitter)とか、まさにその例かなと。


Windows8はサポート終了しているので(おそらく)滅びを迎えました。
ソフトウェアとして死んだと思いますが、その遺伝子は残り続けています。


そう考えると、死にゆくソフトウェアたちもどこかに遺伝子を残しているのだろうなと思いました。



了。

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

いらにか Apr/14/2024 20:43

【感謝祭】道草恋歌アワード2023【ノミネート】

どうも、ごきげんよう。いらにかです。
まさか多忙と疲労で、道草恋歌アワード2023の記事投稿が感謝祭最終日になるとは想定外でした。

道草恋歌アワード2023では、2023年に投稿された道草恋歌の作品から、いらにかの選出した作品をノミネート(入選)作品として表彰します。
今回は大賞などの区分はありません。批評コメントも野暮なので一部以外は無しです。
(来年は一般投票で大賞選ぶとかやりたいなと思いました)



それでは、ノミネート作品の発表です!


暮れ方の 蛙と野鳥鳴く中に 湿る風吹く 田舎の暇(いとま)

作者:くぁ


まどろみと 寝息ふたつの 布団から 去ぬ猪の子や 温さのこして

作者不詳


アイス殻 ペコペコしない まねしない

作者不詳


快速が職場の最寄駅を越え道草屋まで行けばいいのに

【作者】
黒縁ナイロールのお客様


イタズラじゃないと気づいて葉っぱより重い届けを受理してしまう

作者:黒縁ナイロールのお客様


眠るまで君が宿っていたはずの耳のこんなに浅い空洞

作者:黒縁ナイロールのお客様


春の夜に 繋いだ指先 擦り上げて 微睡む顔は 子供の様で

作者:ちめ


振り向けば 短かったと 言えるのに 明日が遠い そんな冬の日

作者:ちめ


紧落雪 夜半思故人 叶归根

作者:johnsmith


※一般人には解読困難だと思うので、いらにかによる注釈
日本人が読みやすいように日本の漢字にしてみました。
 緊落雪 夜半思故人 叶帰根
私なりの意訳ですが、(かなりの)雪が降る夜半(0時前後)に遠い人(故人)を思っている歌だと解釈しています。

誤解だと恥ずかしいんですが、おそらく落葉帰根に掛けた歌だと思います。
落葉帰根は樹木の葉が落ちて根に帰る様子から、輪廻や循環や原点回帰などの例えとして使われるのですが、「人は死後に故郷へと戻る=故郷への哀愁」という解釈もあります。
落葉のさらに先の季節。
激しい雪が降る中、故人を思い、根に帰ることを願う様子が歌からも想像できますが、土地に根ざした樹木の葉ではなく、雲として遠くから運ばれてその地に降りた雪に焦点を当てていることで「異邦の故郷、第二の故郷への哀愁」という表現が非常に深まって解釈できるなと思いました。
まさに、落雪帰根。
遠い地から来た雲が雪となり、異邦の地の根に帰する様は国内外を問わず、多くの道草屋の旦那様に通じる情景と心情なのではないでしょうか。



P.S.
故人が根に帰ることを祈った鎮魂の歌として解釈しても素晴らしい歌だと思いました。
中華圏の文化にあるか不明ですが、0時頃の描写になっているのも黙祷を正午に捧げる様子と繋がっていて情緒ポイントが高いと思います。


雪解雨 更ける夜長に 通る波 微かな息が 此方に揺れる

作者:いらにか


あとがき

芹さんと
連れて往く道
帰り道

2019年10月。
ふいに脳裏に浮かんだこの句と脳内の情景に思わず涙が零れそうになり、
道草屋と詩歌の融和性と可能性を感じて#道草恋歌 を公開する場所を作りました。

道草恋歌は当初から「自由に詠むこと」「自分のペースで詠むこと」を大切にしてきました。
そんな道草恋歌が、2023年も歌人の旦那様たちのおかげで続いていて嬉しい限りです。
特に海外旦那様の道草恋歌も嬉しい出来事でした。
道草恋歌のシステムが海外旦那様に優しいかどうか不明なので、このあたりは改善しなきゃなぁとか思ってたりします。

まだ道草恋歌を詠んだことがない人はデビューお待ちしております!

https://michikusa-renka.glideapp.io/

匿名性も大事にしている道草恋歌!!
新作の感想などを川柳や短歌の形式で表現して投稿するだけでもOKです。
とにかく自由なので!!


それでは、また来年!

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

いらにか Apr/01/2024 06:30

【5周年】みちくさびゅあー感謝祭2024【1日~14日迄】

今年もやってきた、みちくさびゅあー感謝祭!!

今年でみちくさびゅあーも5周年です。
毎年、4月1日から2週間をみちくさびゅあー感謝祭として、なんか色々やったり、やらなかったりしてます。

現状、2代目びゅあー3代目びゅあー(開発中)の2つがリリースされているややこしい状況を整理したかったんですが、いろいろと間に合いませんでした。




代わりに、エイプリルフール企画として、桃色CODEのホームページをモダン化したパロディWebサイトを作りました。

https://momoirocodo.web.fc2.com/


URLがフィッシングサイトみたいになってるのもポイントです。
確実に怒られるレベルのものなので、4月1日が終わったら非公開にする予定です。



道草恋歌アワード2023

2023年も道草恋歌には良い歌がたくさん投稿されました。
本当にありがたい限りです。

今年の感謝祭では2023年に投稿された作品から、いらにかの独断と偏見により選出した秀作をノミネート作品として、別途記事にて紹介する予定です。

感謝祭は14日まであるので気長にお待ち下さい。

Exclusive to users above "Follower"Free

無料プランに入るとモチベーションを支援できます

Free

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

« 1 2 3 4 5 6 7

Monthly Archive

Search Articles