CHIKACH.NET

〔2022/04/09更新: 第2見出し以降の文章を書き直しました。〕 【2023/04/28更新: 一部文章を読みやすく書き直しました。不要と思われるセクションを削除しました。】 八重神子の仕様変更問題 事の発端について 事の発端は2020年3月30日、v2.6アップデートと同時に原神公式のお知らせにv2.6リリースノートが掲載されたことです。 そこには以下のように記載がありました。 キャラクター「浮世笑百姿・八重神子（雷）」の創造した「殺生櫻」が、周囲の敵をランダムに攻撃する不具合を修正しました。修正後、「殺生櫻」は範囲内で最も近い敵を優先的に攻撃します。 一見改善されたように見えるこの修正ですが、これに対して多くの「弱体化だ」という声が上がりました。この修正が弱体化となる理由は大きく分けて3つあります。 雷元素を広範囲にばら撒くことができなくなる ターゲットが盾持ちのヒルチャール暴徒に吸収され、背後にいる小型のヒルチャールを倒しづらくなる 2凸効果の一部が特定のシーンで無意味になる 1つ目の「雷元素を広範囲にばら撒く」性能は、例えば別の元素で範囲攻撃をした際に、元素反応が起こしやすくなります。それが一番近い1体しか攻撃されなくなるためにばら撒き性能が低下します。この性能狙いで八重神子を引いた方も多いはず。 2つ目は書いてあるとおり。殺生櫻を設置して背後の雑魚敵を一掃してくれている隙に盾を持ったヒルチャールを別のキャラで倒す、というような立ち回りができなくなります。 そして3つ目。八重神子の2凸効果には「殺生櫻の攻撃範囲を拡大する」というものがあります。これはランダムに攻撃してくれていたからこそ、攻撃範囲拡大が重宝されていました。そのため、最も近い1体の敵しか狙わなくなると2凸前の範囲内に1体でも敵がいれば効果が死んでしまいます。もちろん、敵が遠くにいる場合は無意味ではありませんが、敵が近くに群がっているケースのほうが遥かに多いはずです。 と、このように「ランダムに攻撃」という唯一無二の性能欲しさでガチャを引いて、八重神子をゲットした人々から「弱体化だ」という声が多数上がりました。 数日後、公式の声明 2.6リリースの翌日、公式からこの件について声明を発表。そこから一部抜粋すると、 改善・修正計画を立てた後、2022年3月1日にテストサーバー上で更新し、2週間のデータ観測を実施しました。戦闘データでは、一連の仕様変更によって、八重神子の「索敵不明確」というネガティブな体験がある程度改善されました。また、戦闘面での性能にはっきりとした悪影響がないことが確認されております。そのため、今回の修正を含む一連の仕様変更を、3月30日のVer.2.6アップデートに伴い実装いたしました。 つまりは、ランダムに攻撃しているこれは 「不具合」 ではなく 「仕様」 であり、索敵の明瞭性を向上させるために 「仕様変更」 を行っていたとのこと。先程のv2.6リリースノートの記載と食い違っています。そして、公式が考える八重神子の使い方とユーザーによる実際の使用方法との間に乖離があったようです。 しかも、3月1日の地点でベータサーバーにすでに実装していて、仕様変更の予定があったにもかかわらず公式からのお知らせが一切ありませんでした。 私たちは引き続き、今回の調整に対する皆さまのフィードバックや、正式サーバー上の八重神子の戦闘データに注目してまいります。ご意見やご感想、そして戦闘データをもとに、制作チーム側で調整が必要と判断した場合は、改めて告知をさせていただきます。 と記載がある通り、リリースしてからどうするか考えるつもりだったのでしょうか。それとも、あまりこの仕様変更を深刻に捉えていなかったのでしょうか。 その1日後、ロールバックを発表。 流石にここまでことが大きくなれば公式も何らかの対応をせざるを得ません。そして、実際にロールバック対応が行われました。公式の発表がこちらです。 以前のテスト検証の過程において、この調整によって影響を受ける戦闘シーンへの考慮が不十分であったために、修復によるゲーム体験への影響を分析した際、慎重さに欠く調整案を策定してしまっていたことが判明いたしました。 この度の調整案により、旅人の皆さまに多大なご迷惑をおかけいたしましたこと、幾重にもお詫び申し上げます。今後のテスト検証のプロセスでは、一部のシーンにおいて旅人さんの体験が損なわれるような調整を極力避け、より総合的な検証方法を策定いたします。また元の体験に影響をもたらさないことを前提に、ゲーム体験の最適化に尽力してまいります。 対応の速さはさすがとしか言いようがないです。ロールバック対応が実際に行われるのがちょっと遅い気がするのを除けば真っ当な対応だったと思います。 この一連の騒動では何が問題なのか。 「ロールバックも行っているのだから一件落着では」と思うかもしれません。しかし、実際には一連の騒動で大きな問題が2つあります。それは、この仕様変更をリリースする前に公式による告知が一切なかったこと 、そして 仕様変更のタイミング です。 仕様変更が決まったのはPU期間が終了した後のようですが、事前に告知があれば仕様変更がリリースされるよりも前に騒動が起きることになります。そうすれば、実際にリリースされることを未然に防げた可能性もあります。特に今回の仕様変更は八重神子の戦闘スタイルの根幹に関わるため、事前に告知をしないのは「有耶無耶にしようとしたのでは」と疑いの目を向けられても無理はありません。 また、この仕様変更はPUが終了したすぐ次のバージョンでに行われました。つまり、「ガチャ期間中にはプレイヤーに有利な仕様でガチャを誘い、ガチャ期間が終われば勝手に仕様を変更して他キャラとのバランスを取る」といったことを意図しているとも考えられてしまいます。 せっかく引いたキャラが後出しで弱体化を食らうようなことがあれば、安心してガチャが引けなくなってきます。そしてこのようなことが今後平然と行われる可能性もあります。 実はこれ、今に始まったことではない。 実はこの「PU期間が終了したタイミングでの不具合修正に見せかけた無告知ナーフ」は、今に始まったことではありません。私が知る限り、原神でこのような手口が使われたのはこれで3回目です。そのうち2回はどのようなものなのか、解説します。 1個目: 草の燃焼ダメージ爆上がり問題 1年近く前、v1.1のアップデートが事の発端です。v1.0ではクレーの1回目PUが行われていました。最初期のキャラですね。今でも他キャラとの組み合わせでめちゃくちゃ強いので愛用してます(どうでもいい) クレーのPUが終わってすぐ、v1.1がリリースされました。そのリリースノートにはこんな記載が。 燃えている草地の燃焼ダメージが世界ランクの上昇に応じて変化しない不具合を修正しました。 クレーは言わずもがな、炎をばら撒く爆弾魔です。そのため、フィールド探索で使うと草は必ず燃えます。そうするとクレー自身にダメージが入ってしまいます。v1.0地点では1回3ダメージとか1桁台だったのが、v1.1では200ほどに急上昇。多くのクレーユーザーが悲鳴を上げました。これも 事前告知はなかった と思います。 幸い、すぐに対応があり100程度にまで下げられ、現在に至ります。 2個目: スライムの当たり判定変更問題 これはほぼ話題にならなかったと思いますが、v1.3アップデート時にひっそりとこんな修正がされました。ちなみに1.2では甘雨のPUがありました。 魔物「大型スライム」がジャンプ後、踏み切り点を攻撃するとダメージが発生する不具合を修正しました。 PU期間中はスライムがジャンプしても下にダメージ判定があるため、甘雨の重撃が当てやすくなっていました。そのため、比較的シチュエーションは限られますが、若干環境的にナーフされたと言えると思います。 一見ただの不具合のように見えますが、実はこれ、v1.1地点では存在しなかった不具合 です。つまり、甘雨PU期間中のバージョンで不具合が追加され、その次のバージョンで削除されています。 実装面でも考えます。Unityにおいて、一般的に当たり判定はオブジェクトの位置を基準にして決められます。そのため、スライムがジャンプした地点で当たり判定も一緒に上に移動するはずです。要は、意図的に当たり判定を固定しない限り、当たり判定が踏み切り点に留まるなんてことは普通はありえません。もちろん、原神がどんな実装になっているかを知るすべはないので、憶測の域を出ませんが。 ただ、これら2つはすべて環境によるナーフです。今回のようにキャラ自体に弱体化を食らうのは初めてのケースです。 なので この件について皆さんの意見を是非お願いします。「それは違うぞ」っていう指摘もある程度は受けます。 憶測も混じえて書いたので、もしかしたら本当にmiHoYo(COGNOSPHERE)側のミスだった可能性もあります。その際はごめんなさい ※憶測と事実ははっきり分けて書いたつもりですので、さも憶測が事実であるかのような捉え方をして拡散しないようお願いします。

今回のテーマは、 MacBookとWindowsノートPCは結局どちらがどう良いのか？ です。現在製品として売られているPCの種類には2大巨頭としてWindows機とMacがあります。 この2つは普段使い勢の間でも、ソフトウェア開発勢の間でも、しばしば対立が起こります。そこで、今回はバリバリ主観は混じりますが、できるだけ広い意見を取り入れて、どんな場合にどちらがどう優れているのかを解説していきます。これらは一個人の意見ですので、コメントで「それは違うだろ」とか「こんなのもあるよ」とか教えていただけると嬉しいです。私が納得すれば随時追記しようと思います。 [2022/04/05更新: タイトルを変更しました。AirDropについて追記しました。] [2023/11/15更新: Finderについて追記しました。] いきなり蛇足 ちなみにですが、ハードの名前は頭文字が大文字の「Mac」、ソフト(OS)の名前は小文字で始まる「macOS」です。 Macの方が良い点 まずはMacは何が良いのかを解説します。 トラックパッド これがMacを使う上での最大のメリット。Macのトラックパッドは、はっきり言ってWindowsのものとは 訳が違います。 Windowsのタッチパッドは、基本的には上部がカーソル移動、下部がクリックとなっています。ジェスチャー操作でも、クリックはカーソルを動かして一度離してタッチ、ドラッグは2回タップした指で動かすという、何度もやるには少々面倒なジェスチャーとなっています。 Macはというと、全面どこでも役割は変わりません。タップではなく、押し込みでクリックやドラッグができます。クリックしたい場所にカーソルを移動させてから指を離す必要がないため、非常に流れるように操作が可能です。ドラッグも押し込んだまま動かすことが出来るため、非常に簡単にウィンドウを動かしたりすることが出来ます。この操作感は実際に使ってみないと分からない気がします。ちなみに設定でWindowsと同じ動作をするように変更できます。 また、押し込みには2段階あり、強く押し込むとその単語の意味などを調べることができます。正直個人的にはあまり使いませんが、人によっては便利だと思います。 このようなトラックパッドを持ったWindowsノートは、調べた限り見つかりませんでした。ジェスチャーを設定することは可能ですが、押し込みでクリックが出来るものは見当たりません。(あったら教えて下さい…) ソフトのインストールが簡単 Macはほとんどのソフトが、アプリ本体を「アプリケーション」フォルダーにコピーするだけで完結します。コピーすると自動的にLaunchpad(ソフト一覧)に表示されるようになります。たまにその説明が分かりづらい、という意見を見ますが、それはソフトの制作者が悪いです。 ただ、アンインストールは面倒ですが(後述)。 AirDrop iPhoneを持っているなら、Macの近くで転送操作をするだけでiPhoneで撮影した動画とか写真をAirDropで送信できます。もちろんファイルも転送できます。 WindowsにはMicrosoftから出ている「Windowsにリンク」アプリを使えばAndroidやiPhoneと同期できますが、写真しか転送できません。スマホ側での操作が不要という利点はありますが、LANかモバイルネットワークを利用する必要があります。AirDropはP2Pでダイレクトに転送できます。 他にはサードパーティ製のファイル転送ソフトを使うという手もありますが、セキュリティ的に不安な部分があります。また、クラウドストレージを使う方法もありますが、受け取り側でダウンロードが必要で面倒くさいです。なので、スマホ-PC間でのファイル転送で一番手軽で安全な組み合わせはMac-iPhoneだと思います。 方法 メリット デメリット AirDrop 近づけて転送操作をするだけで直接転送。手軽で安全。 MacとiPhoneを揃える必要がある スマホ同期 スマホ側での操作が不要。Microsoft謹製。 写真しか同期できない・直接転送できない(ネットワーク経由) サードパーティの転送ソフト(サーバー経由/Wi-Fi Direct) 転送手段の乏しいAndroidとWindowsに救いの光 サードパーティなので安全性に疑問 クラウドストレージ (Google Driveなど) 安心安全の最終手段 受け側でダウンロードする必要がある さらに、同じApple IDでログインしている、iPhoneのブラウザーで開いているWebページをDock(画面下部のアイコン)からそのままMacで開くことが出来たりもします。逆も然りで、iPhone側でアプリ履歴を開けばMacでアクティブなタブが表示されます。正直あまり使いませんが、いざという時にめちゃくちゃ便利です。(Firefoxにも同様の機能があります。こちらは送りたい時に転送するという感じ) Finderが非常に多機能 macOSに搭載されているFinderは、非常に 痒いところに手が届く機能がたくさんあります。 例えば、ファイル名の一括変更機能。複数のファイルを選択して「名称変更」をクリックすると、どのように一括で変更するか指定する画面が表示されます。ここで、特定の文字を消去、追加、置換したり、連番を付加したりと色々できます。 また、フォルダーのサイズ順ソートもでき、エクスプローラーに比べ非常に楽にファイル整理ができます。 切り取り機能は無いと思われがちですが、元のファイルをコピーした上で ⌘⌥V を用いて貼り付けることで同じことができます。 OS自体の安定性 macOSは、OSごとフリーズすることがほぼありません。Windows 11ではカーソルすら動かなくなることがたまにありますが、macOSを使っていてモッサリ感を感じたことは全くと言っていいほど無いです。 フォント表現の正確性 これはよく言われるやつですね。例えばRounded Mgen+のような丸いフォントを14ptくらいの小さいサイズで表示させると、Windowsでは丸まった部分がギザギザになって読みにくくなります。macOSではフォントを縮小してもはっきり読めます。フォントという概念をコンピューターに初めて持ち込んだAppleならではの長所ですね。 色表現の正確性 写真などを表示させる際、色を正確に表示できるらしいです。あまり色にシビアなものを作ったことがないのでよく分かりませんが、一部のクリエイターには重宝されているようです。 iOS/macOSアプリを開発(ビルド)できる Apple製品向けのアプリをビルドする(完成させる)ためのツール「Xcode」はmacOS版しか存在しないため、iOSアプリを作りたい場合は必然的にMacを買う必要があります。(現在はSwift Playgroundを用いてiPadでもApp Storeに公開できるようです。どれほど手のこんだものが作れるのかはよくわかりませんが。) 私はこのためにMacを買いました。開発自体はXamarinやFlutterなどを使ってWindows等でもできますが、アプリとして完成させることはできず、ソースコード止まりです。 Windowsの方が良い点 ここからは、MacにはなくてWindowsにはある利点を解説します。 ゲームソフトやマイナーなツールが充実している テキストエディターやMicrosoft Officeなど、大手のツール系ソフトはMac版が大抵存在します。しかし、ゲームソフトや個人・小さなグループで作っているマイナーなツールはMac版が公開されていないことが多いです。 実はMacは殆どのゲームで採用されているゲーム処理用API、DirectXに対応していません。その代わり、独自のMetalというAPIを搭載しています。その仲介をするソフトの開発も行われてはいるようですが、まだ公開されていないようです。メジャーなゲームエンジンのUnityはMetalも一応サポートしていますが、Mac向けの最適化作業が必要になり、シェアの低いMacにリソースを割く企業やデベロッパーが少ないのでしょう。 そもそも、Macはゲーム機としてではなく仕事ツールとして設計されており、AppleはMacでゲームをされることをあまり望んでいないようです。(最近は少しゲームにも力を入れているようですが) その点、Windowsはシェアも高く、ゲーム分野にもかなり力を入れて開発されているため、ゲームには向いていると言っていいと思います。 インストールされたソフトが一元管理されている Macはアプリケーションのインストール方法が複数あるため、アンインストール方法がバラバラです。アプリケーションフォルダーからゴミ箱にぶち込むだけのソフトもあれば、Application Supportに設定ファイルが残るソフト、シェルスクリプトを実行する必要があるソフト、Launchpadからアイコン長押しで削除するソフトなど色々です。 Windowsでは、インストールされたソフトはレジストリに登録され、全て1つの画面からアンインストールできます。 安価で低性能なPCから高価で高性能なPCまで多種多様 Windowsノートはメーカーを選ぶことができます。軽量性が凄まじいLGや安心の日本製NECや富士通など様々です。使い方にあったPCが選べるのが魅力です。 MacはAppleが作るPCですので、選択肢はさほど多くありません。選べても年式や画面サイズ、AirかProかくらいです。 結論 ここまでの長所短所を見て好きなのを使おう。

今回は、私が大学生活を1年間送ってみてどうだったのかをブロク的に記述していこうと思います。拙い文章ですがご容赦を。 まず最初に、私は自分から他人にアプローチできるほどのコミュ力を持ち合わせていないので、大学では殆どの時間をぼっちで生活しています。それでも(あまり座学に身が入らなかったことを除けば)ある程度は充実していたと思います。2年になったらちゃんと勉強しよう。 なぜこんなのを書こうと思ったのか？ 2, 3年後この文章を見た時にどう感じ方が変わるかを調査したいから。大学が始まる前に投稿されたラムダさんのこちらの動画を一度見たことがあって、その意気で大学に入学しました。その1年後、YouTubeのおすすめに出てきたので2回目を見てみると、色々共感することもあれば自分の場合は境遇が大きく違うこともありました。それをもう1度味わいたい！(+自己顕示欲)というわけで、生地を加工と思いました。 大学に入学した経緯 私が大学に入学した年は大学入学共通テストの1年目で、問題の傾向が大きく変わると言われていました。私は興味のない教科にはほとんど身が入らないような人間なので、化学や地理などは模試で全く得点できませんでした。 そして共通テストを受けてみると、数学は8割近く得点でき、国語や地理も模試よりはかなり高い点数が取れました。本番に強いタイプなのか、たまたま解き方が分かる問題が多かったのか、自分にしてはめちゃくちゃ良い点が取れました。 高校のある先生はあまり私に期待していなかったようで、自己採点のミスを疑っていましたが、別の先生には地元の偏差52くらいの大学に共通テスト+推薦で入らないかと言われました。私は面接が大の苦手なので乗り気がしませんでしたが、なんか流れで面接練習をしてくれることになりました。 結果受かってこの大学に入ることになりました。(かなり端折りましたが) 前期 前期は授業の教室の廊下で待っていると話しかけてくれた人が1人いて、その友達とオンライン授業を教室で受けていました。授業が終わると食堂で一緒に昼食をとったりもしました。 しかし、その友達は割と遠方から通学しているらしく、授業が1時間しかない日などには来なくなり、次第にあまり会うことがなくなりました。というのも、同じ学部学科ではあるもののコースが違うため、同じ教室・時間で授業を受けることがありません。ネットで話すのも苦手なので本当に接点がなくなってしまいました。 学食はラムダさんが言っていたのと同じような感じですね。割と堂々と入って一人で食べていました。食堂は一定期間でメニューが変わるので飽きないし、美味しくて、めちゃくちゃ満足感がありました。 そんな中で学校終わりに通っていたのがゲームセンターです。アーケード音ゲーをずっと詰めてみたかったんですよね。ぼっちだということを利用して、空きコマなど好きな時間に行っていました。4月頃は主にCHUNITHMをやっていましたが、5月頃に誰もいない時間帯のゲーセンのベンチでくつろいでいると、maimaiの筐体が目に入りました。試しに1回だけやってみると意外と楽しくて、その日以来は手袋を買ったりして毎日maimaiを遊んでいました。お陰様で10ヶ月後の現在はRATING14300近くまで上がりました。 後期 前期の終わり頃にmaimaiでモ°ルモ°ルをやっていると、ある人に話しかけられました。「もしかして、さっき同じクラスだった…」「割と上手いね」みたいな感じに。どうやら同じ授業を後ろで受けていたらしく、私に気づいて話しかけてくれたようです。彼も音ゲーが好きで、CHUNITHMをプレイしに同じゲーセンに通っていました。maimaiはプレイしたことがないらしいです。 後期になってからは彼と一緒に授業を受ける機会が増えて、帰りに一緒にゲーセンに寄ったりするようになりました。他にも私が好きなArcaeaもやっているらしく、割と仲良くなりました。その人のいるコミュニティーにも比較的参加させてもらっていて、テストの過去問を共有してもらったりしていました。 LINEグループは存在を知りませんが、まぁわからないことがあっても自分で調べられるし、大学からのメールはGmailアプリに追加していて常に通知が来るので大して困ることはありませんでした。 そして現在に至る その後、なんだかんだあって必修科目の単位は半分ほどしか取れず。春休み中に猛勉強しようと思った。いやしないとヤバい

皆さん、こんにちは。 今回は、Vercelを用いてreCAPTCHAを導入してBot対策する方法を解説していきます。Vercelを用いた方法の日本語記事はざっと探しても見当たらなかったので、記事を書いてみます。 以前投稿した記事は一部誤っている部分があったため、再投稿です。 下準備 まず、reCAPTCHA のコンソール画面から利用登録します。以下のページに飛んでください。 :::btn reCAPTCHA ::: すると、以下の画面が表示されるはずです。 ここでは、以下のように選択・入力してください。 ・ラベル：任意の名前 (サイト名) ・reCAPTCHA タイプ：reCAPTCHA v3 を選択 ・ドメイン：公開予定のドメインを入力 ・「reCAPTCHA 利用条件に同意する」にチェックを入れる 送信後、「サイトキー」 と 「シークレットキー」 が表示されますが、これは後で使用しますのでページは閉じないでください。 実装 ここからは実装です。reCAPTCHA は、以下のような仕組みで成り立っています。 ユーザーがフォームの「送信」をクリックする クライアント側で検証し、トークンを生成 トークンをサーバーに送り、検証し、結果を返却 結果が設定したスコアより高ければフォームの送信処理をする reCAPTCHAでは、利用者がどれだけ人間だと思われるかのスコアが結果として帰ってきます。しきい値を上げればボットをたくさん弾けますし、低くすれば誤検知のリスクが下がります。 クライアント側 今回はNuxt.jsを用いて実装しますが、それぞれのフレームワークに適宜読み替えてください。 まず、スクリプトをロードします。以下をnuxt.config.jsに追記してください。 export default { head() { return { script: [ { src: "https://www.google.com/recaptcha/api.js?render=<SITE-KEY>" } ] } } } <SITE-KEY>部分は先程のサイトキーに置き換えてください。 次に、送信ボタンのクリック時の処理を書きます。axiosパッケージをインストールしていない場合は、npm i axios もしくは yarn add axios でインストールしておいてください。 grecaptcha.ready(() => { grecaptcha.execute("<SITE-KEY>", {action: 'submit'}).then((token) => { axios.get("/api/checkRecaptcha?response=" + encodeURIComponent(token)).then(async (response) => { if (response.data.success) { // スコアは任意で変更 if (response.data.score >= 0.5) { // 送信処理 } } }) }) }) 同じく、<SITE-KEY>部分は先程のサイトキーに置き換えてください。 ここで、VercelのサーバーのAPIを叩いて、トークンを検証します。スコアのしきい値の目安は0.5くらいが良いと思います。試してみたところ、ボタンを1回だけ押すと0.9、数回連打すると0.7、何回も連打すると0.3、というように下がっていきました。 サーバー側 次は、Nuxt.jsのプロジェクトルートにapiフォルダーを作成し、その中にcheckRecaptcha.jsを作成します。中身は以下です。 const axios = require("axios").default module.exports = (req, res) => { const response = req.query.response console.log("recaptcha response", response) axios.post(`https://recaptcha.google.com/recaptcha/api/siteverify?secret=<SECRET-KEY>&response=${response}`).then(result => { // console.log("recaptcha result", result) if (result.data.success) { res.send({success: true}) } else { res.send({ success: false }) } }).catch(reason => { console.log("Recaptcha request failure", reason) res.send("Recaptcha request failed.") }) } <SECRET-KEY>部分は最初のシークレットキーに置き換えてください。 エミュレーションするには、yarn devではなく、Vercelのコマンドラインツールを利用します。yarn add vercelでインストールし、vercel devコマンドを実行します。初回は色々表示されるかもしれませんが、読めば分かるはずです。 これでVercelにデプロイすれば、reCAPTCHAで認証が可能になります。

現在、新「提出物マネージャー」こと「Submon」を開発しています。 今回は、現在実装が完了している範囲で、Submonでの旧版からの変更点を解説します。これらは暫定的なもので、今後変更される場合があります。最終的にタイトルに「決定版」を付加した記事を公開しますので、それが最終的にリリースされる内容となります。 :::btn 提出物マネージャーはこちら ::: ウィジェットの追加 ホーム画面からでも提出物リストが確認できるウィジェットをAndroid・iOSともに追加しました。別々に実装する必要があったため、地味に頑張りました。 Android 12以降ではウィジェットから提出物を完了にできます(iOSおよびAndroid 11以前ではこの機能のみご利用いただけません)。 Androidではウィジェットをスクロールすることですべての提出物を確認できます(iOSでは縦2マスサイズでは最大4個、縦4マスサイズでは最大10個表示されます)。ウィジェットからの新規作成もシームレスに行えます。 マルチ時間割機能の追加 ご要望があったため追加しました。時間割表を複数作成することができます。 Googleカレンダー連携機能の追加 Googleカレンダーに提出物を追加することができます。編集したり削除したりしても同様に反映されます。 パスワードレスログイン機能の追加 登録時に設定すれば、パスワードレスでログインすることができます。仕組みとしては、登録されたメールアドレス宛にログイン用URLが送信されるため、それをタップすることでログインができます。パスワードを覚える必要はありません。 Appleログイン機能の追加 これに関連して、iOSにはAppleログイン機能も追加しました。Androidについては、ライブラリ側に不具合があるようなので実装を見送っております。 暗記カード作成カメラのUIを大幅に改善 暗記カードをカメラ入力で作成する部分のUIを刷新しました。以前より直感的に使いやすくなりました。 まず、本バージョンではなぞったテキストの枠の色が変わるようになりました。どのテキストをなぞったかわかりやすくなっています。 また、テキストをなぞる判定ロジックを改善し、反応する範囲が広くなりました。遠くから撮った細かい文字でも確実になぞれます。他にもなぞっている時になぞったテキストの表示が隠れたり、カメラ部でタップしてフォーカス、認識中のアニメーションなど細かな改善も多数あります。 (※今後の更新で利用可能になる予定です。) 提出物リストのデザイン変更 デザインを刷新しました。残り日数は「週間」「ヶ月」でも表示され、タップで日数表示に切り替わります。今まではタップで展開されて詳細が表示されていましたが、今後は詳細ページが全体にアニメーション表示されます。また、曜日表示を追加しました。 情報量の削減 画面上に表示される無駄な情報を削減しました。例えば、時間割の全削除時に表示されるダイアログを削除するなど、余計な確認等を減らしました。この例では「元に戻す」ボタンを使えばすぐに元に戻せます。 マルチプラットフォームで展開予定 提出物マネージャーはAndroidのみの展開でしたが、Submonでは(最終的に)以下の4プラットフォームで公開する予定です。 Android (Google Playストア) iOS/iPadOS (App Store) macOS (Mac App Store) Web このうち、初期は Android版 / iOS版 のみ公開する予定で、Web版 / macOS版 は今後公開予定です。ただし、Web版 / macOS版では以下の機能はご利用いただけない予定です。 暗記カードのカメラ入力 その他細かな点 時間割の表示時限数に「5時間目」を追加しました。 内部データの構造と扱い方を大改修したため、以前よりデータ同期系のバグが大幅に減少しました。 広告を追加しました。iOSアプリの公開には年額1万円程度かかるため、広告なしでは採算が取れなくなります。ご了承ください。 提出物は次にそのタブを開いた際に並べ替えられます(追加や編集、スターの付け外しをした直後は並べ替えられません)。更新するには別のタブを開いてから開き直してください。 リマインダー通知と時間割表通知がプッシュ通知(サーバーから送信される通知)となります。オンライン時のみ通知され、この機能利用にはログインが必要になります。また、通知時刻は常にJST(UTC+9)です。 以下の機能は実装が面倒臭かったため不要と判断したため、削除いたしました。ご要望があれば再実装いたします。 提出物の複数選択(一括削除・一括完了) ローカルバックアップ 自動スクロール ダークテーマの設定項目 (今後は常に端末の設定に依存して切り替わります。端末側に設定項目のないAndroid 9以前ではダークテーマをご利用いただけません。) Facebookログイン カメラ入力のズーム 未保存でバックしようとした際の確認ダイアログ

いつも私作のアプリをご利用いただき、ありがとうございます。 この度、Google Play Storeにおけるデベロッパー名を以下の通り変更いたします。 これまで: 「chikach」 今後: 「C2K Studio」 アプリの内容やクオリティーには一切変わりありませんので、ご安心ください。Play Store上での表記は、名称の審査に通り次第反映されます。今後とも宜しくお願いします。 ※名前に込められた思い等は特にありません。私が好きなコンポーザー3○2さんみたいに、名前に数字入れるの良いなぁと思ったのと、G○ARISUTA(GY○RIさんの公式サイト)みたいに、名前に「スタジオ」入れるの良いなぁと思ったのと、イニシャルです。読みは「シーツーケースタジオ」。

Flutterに同梱されたDart SDKをarm64版に置き換えるシェルスクリプト を作りました。 背景 / Background 現在、Dart SDKはM1 ネイティブ版が配布されていますが、Flutter SDKに同梱されているDart SDKは依然としてIntel版です。このシェルスクリプトは、Flutter SDKに含まれるDart SDKをM1 ネイティブ版に置き換えます。 こうすることで、かなりの高速化が期待できます。 ※Flutterの保証対象外の使い方ですので、その辺は常識の範囲内でお願いします。 ※flutter upgradeするたびにもとに戻りますので、その都度実行する必要があります。 追記(2022/03/24) Flutter SDK v2.12.0-4.1.preよりArm64版も合わせて配布されるようになったため、本スクリプトは不要になっていくと思われます。 使い方 / How to Use 実行権限を与えて実行し、Flutterのホームパスを入力します。 / Run it with execute permission and enter the home path of Flutter. % chmod u+x ./flutter-dartsdk-arm64-mac.sh % ./flutter-dartsdk-arm64-mac Input Flutter SDK home path: <Flutter SDKのパスを入力> ダウンロード / Download :::btn Download :::

デスクトップエントリとは Linuxにおけるプログラム等へのショートカット。アイコンクリックで起動できる。 作成がめんどくさい デスクトップエントリのテンプレート [Desktop Entry] Type=Application Encoding=UTF-8 Name=Android Studio <アプリ名> StartupWMClass=jetbrains-studio　<ウィンドウクラス名※1> Exec=/home/chika/android-studio/bin/studio.sh <実行ファイル> Icon=/home/chika/android-studio/bin/studio.svg　<アイコンファイル> Categories=Development　<カテゴリー※2> ※1 普通は指定する必要はないが、これを指定しないとアイコンクリック後、別のアイコンがタスクバーに表示される場合がある。取得方法は、以下のコマンド入力後、該当のウィンドウをクリック。 xprop WM_CLASS ※2 指定可能なカテゴリーはこちらを参照

問題発生 FlutterのiOSプロジェクトをXcode側でビルドしようとすると、module not found 'xxx'のようなエラーが出てビルドに失敗してしまう。その他にも多種多様なエラーが発生する原因になる。 これ、根本的にどのような原因で、どういう条件が重なって発生しているのかはよくわからないが、確実に直った方法がこちら。 対処法 Podsプロジェクトを選択し、Build SettingsからBuild Active Architecture OnlyをすべてNoにすることで直った。 ただ、GUIで設定変更すると次にpod installした際に もとに戻ってしまう ため、Podfileに以下を追記する。 # 〜略〜 post_install do |installer| # ここから installer.pods_project.build_configurations.each do |config| config.build_settings["ONLY_ACTIVE_ARCH"] = "NO" end # ここまで installer.pods_project.targets.each do |target| flutter_additional_ios_build_settings(target) end end 環境 Xcode 13.1 Flutter 2.18.1 MacBook Pro 2020 M1

問題発生 Androidアプリ開発中。AppWidgetにListViewを実装しようと思い、クリック時に開くページをsetOnClickFillInIntentで設定しようとしたが、何故か RemoteViews$setPendingIntentTemplate で設定したPendingIntentのテンプレートが setOnClickFillInIntent の Intent で上書きされない。 setPendingIntentTemplate(R.id.listView, PendingIntent.getActivity(context, UUID.randomUUID().hashCode(), Intent(context, MainActivity::class.java), PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT)) setOnClickFillInIntent(R.id.listItemLayout, Intent() .putExtra(MainActivity.EXTRA, list[position]["id"] as Int)) Result intent.extras -> Bundle[{}] 解決方法 Android 12以降をターゲットにする際、PendingIntentをImmutableにするかMutableにするかの指定が必須になった。何も考えず全部Immutableにするとこういうことになる。 setOnClickFillInIntentは実質的にPendingIntentの書き換えをしているため、PendingIntent.FLAG_IMMUTABLEが指定されていると追加のIntentが完全に無視される。そのため、Android 12以降ではPendingIntent.FLAG_MUTABLEの指定、Android 11以前では無指定にする必要がある。地味にハマった。 val flags = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) PendingIntent.FLAG_MUTABLE or PendingIntent.FLAG_UPDATE_CURRENT else PendingIntent.FLAG_UPDATE_CURRENT setPendingIntentTemplate(R.id.listView, PendingIntent.getActivity(context, UUID.randomUUID().hashCode(), Intent(context, MainActivity::class.java), flags))