突然、Google Play Console デベロッパーアカウントが停止され、アプリが全て削除された話AndroidGoogleUnityGooglePlay 株式会社Neverのshoheiです。 株式会社Neverは「NEVER STOP CREATE 作りつづけること」をビジョンに掲げ、理想を実現するためにプロダクトを作り続ける組織です。モバイルアプリケーションの受託開発、技術支援、コンサルティングを行っております。アプリ開発のご依頼や開発面でのお困りの際はお気楽にお問合せください。 TL;DR 弊社のGoogle Play Console デベロッパーアカウントが突然停止、公開していたアプリが全て削除、アプリのアップロードもインストールもできない状態に 自社ゲームアプリのポリシー違反によるものだが、違反内容に思い当たる節は無く、再審査請求をした 1ヶ月後、再審査請求が承認され、ア

自分が最初に知ったのはカードゲームで去年くらい 意味も読み方もわからないけどTier1は優勝デッキらしい事は何となく察した ゲームの攻略サイトでもTier1から3くらいまででおすすめ度を表してた 知らん間に知らん文化ができてて驚いた 【追記】 たくさん回答ありがとう 昔からあるのはわかった。意味も階層だと理解した でも階層（境がはっきりしている）とランキング（順位）の両方で使われてるので やっぱわざわざ海外の文化を持ってくるほどのもの？という感じは消えない これは国産ゲームしかしないからの感覚だとは思う

これは作成した2次元バーコードの元となったURLを、自社が管理していない外部の「短縮URL作成プログラム」が実行した結果、いったん全く別のページを間に挟んだり、そもそも全く別のURLへとジャンプさせたりといった、利用者が予想していなかった挙動をするようになったものだと推察されます。 全く別のページが間に挟まっていて、そこに広告が表示され、その広告が全く異なるWebサイトへの入会を誘導しているとしても、そもそもが「入会の案内」だった場合、気が付かずに入力してしまう可能性はあるでしょう。 本件は2次元バーコードを使うリスクや、見知らぬ短縮URL作成プログラムを利用することだけが問題ではないようにも思えます。特に企業においては、ITでも「生殺与奪の権を他人に握らせるな」というのが重要なのかもしれません。 短縮URLという“根本解決できない問題”にどう立ち向かうか？ 「短縮URL」は、それなりに昔

const colors = ["赤","青"] as const; type Colors = typeof colors[number]; //"赤" | "青" typeof colors[number]･･･ってよォ～～～～～ typeofはわかる。スゲーよくわかる TypeScritの世界では、typeofで変数から型を作れるんだよなァ だがnumberってのはどういう事だああ～～～～っ!? 配列にnumberを渡せるかっつーのよ───────ッ!! ナメやがってこの型ァ!! 超イラつくぜぇ～～～～ッ!! 解説 これはよォ 「Lookup Type」ってやつらしいぜぇ たとえばよォ 👇みたいに書くとPerson型からプロパティの型を取り出せるよなァ～?? type Person = { name: string, age: number } type name = Person

1. 第3次AIブームの到来 米Google DeepMindが開発した人工知能（AI）の囲碁プログラム「AlphaGo」が世界トップレベルの実力を持つ韓国のプロ棋士、李世ドル（イ・セドル）九段に4勝1敗と大きく勝ち越したことが着火剤となり、2015年より第3次AIブームへと突入した。(ちなみにAIが誕生したのは1950～1960年代で第1次AIブームの到来) 1.1 余談になるがAlphaGo(4億円の知能)はなぜすごいのか？ AlphaGoがそれ以前のチェスや将棋のAIと異なるのは、 畳み込みニューラルネットワーク（CNN） を応用している点だ。このCNNはさらに強化学習を行い、自分自身と対局を数千万回も繰り返した。 間違っていたらすみません、、、、 1.2 ChatGPTによる生成AIのブーム ChatGPTに代表されるLLMは以前から開発競争が繰り広げられていた。 GPT1は201

この記事は「パスワードがハッシュ値で保存されているサイトのSQLインジェクションによる認証回避の練習問題 - Qiita」の続編です。 前回までのあらすじ SQLインジェクションによる影響として、認証回避の例がよく紹介されます。よくある「'OR'a'='a」を入力するパターンはよく見かけるところですが、パスワードがハッシュ値で保存されているケースについても認証回避が可能なケースがあることを示しました（参考:解答編）。 パスワードがペッパー付きハッシュ値で保存されているとどうなる? 今どきはパスワードはソルト付きハッシュ値で保存することが常識になっていますが、加えて「ペッパー（pepper）」というものを付加した方がよいという流れになってきています。ソルトがユーザー毎に異なる文字列であるためにハッシュ値とセットで保存するのに対して、ペッパーは固定値であるもののデータベースとは別の安全な場所に

SQLインジェクションによる認証回避 SQLインジェクションによる影響として、情報が漏洩するとか、データが勝手に更新されてしまうなどとともに、認証回避の例がよく紹介されます（私の本でも取り上げています）。 典型的な例は下記のとおりです。 // $id と $password は外部からの入力 $sql = "SELECT * FROM users WHERE id='$id' AND password='$password'";

らんぶる @tamuramble 知り合いの日本を代表するプログラマーのデスクトップもこんな感じ。 デスクトップ散らかってますねとイジったら、「ターミナルしか見てないし、ファイルもスポットライトで見つけられるので、整理する時間の方が無駄ですよ」って返されて以来、雑然としたデスクトップは天才の証だと思っています。 twitter.com/rikei_ayaka/st… 2023-08-07 09:40:32

TypeScriptでは配列が空でないことを型レベルで表現できます。 この記事ではその型をNonEmptyArray<T>と書くことにします。 結論だけ先に書くと、次のように定義するのが正しいです。 export type NonEmptyArray<T> = [T, ...T[]] | [...T[], T] 現在ネット上では上記とは異なる、少し不具合のある型定義が紹介されているので要注意です。 それらも含めて簡単に解説します。 よくある間違いその1：T[] & { 0: T } ２つあるうち最初に紹介するのはこの型定義です。[1]

はじめに 巷にカレンダーのAPIは溢れているが、万年カレンダーを作ってみるなどした。 実装方針 日付の基本的な計算はChronoライブラリを使う これで今日が何日で何曜日かの計算は簡単にできる。 祝祭日は政府が定義しているルールに従って実装すれば良い。 と思っていた時期がありました。 祝祭日のルール 国民の祝日に関する法律（昭和２３年法律第１７８号）に則り、内閣府が公布している資料では以下の通り この資料の2条の定義と3条のルールに従えば大体の祝日をカバーできることになる。 ただし、このページだけをサラッと読んだだけでは理解できない罠がいくつかある。 ちゃんとリンク先まで読めばまず引っかからないが、一旦ここでも要約する。 春分の日と秋分の日 これらは、日本国内においては天文学的に定まっており年によって変化する。 表にあるように、4年に1回の周期で23と22日で繰り返すように成っているかのよ

荒木町　車力門　炭火焼き　池真と申します。季節の料理と季節の日本酒を提供しております。宜しくお願い申し上げます。 東京都新宿区四ツ谷三丁目3-7阿部ビル1階 0364577340

あゆゆん♪ @ayu_littlewing よく訓練されたITエンジニアは 「住所と文字コードには迂闊に手を出しちゃならん！！」と徹底的に叩き込まれているのだが、この感覚はたぶん素人には分かりにくいと思う。。。 あともうひとつくらい迂闊に触るながあった気がしたけどなんだっけな。。。 2023-06-06 08:57:31

発端 @fumieval 様のツイート。 空の配列を渡したら True を返すべき この関数に空の配列を渡したら True を返すべきである。仕様によるとか状況によるとか相談すべきとか例外を返すべきかもといった意見もあるようだが、議論の余地がないレベルで True を返すしかない。最大の理由は 「True を返さないと、空集合があらゆる集合の部分集合になるというルールに矛盾するから」 である。これは数学における集合論の定理のひとつであり、「これを認めないとそれに連なる集合論のすべてが瓦解する」というルールのひとつであって、認めない相応の理由があるとすれば「数学のもっとも基礎的なルールのひとつを覆してでも実現しなければならないことがある」という次元での話になる。 少なくとも私は 10 年以上プログラミングをしていてそんな状況に遭遇したことはない。 【2023/06/01 追記】 数式がわから

エンジニアの格闘 エンジニアのみなさんはかつてひどいコードや設計と直面し、それと格闘したことでレベルアップした経験はあるでしょう。 つまり、先輩エンジニアたるものクソコードやクソ設計を残して、後輩エンジニアのレベルアップに寄与するのは義務だと言っても過言ではありません(?) 今回はDB設計に焦点をあてて、そのように絶望させる設計の残し方を記しておきます。 初めての投稿なのでレベル的にはかなり初歩になっています。 ↑きっと彼も立派なエンジニアになった時感謝してくれるでしょう 1) 必要な正規化を行わない エンジニアという不思議な不思議な生き物は処理の共通化等なにかと処理をまとめたがる習性があります。 以下のように著者テーブルと書籍テーブルがあるとします。 書籍 書籍ID 書籍名 著者ID