Posts

Showing posts with the label SQL

ゴールデンウィークにTwitchでゲーム配信を始めた話｜古いMacBook Pro・PS4・OBSで配信環境を作ってみた

-
Image
古いMacBook ProでもTwitch配信はできる？PS4・Switch2用にOBS配信環境を作ってみた ゴールデンウィークで時間があったので、以前から少し興味があったTwitchでのゲーム配信を始めてみました。 アカウントは うえはら000 。 主にストリートファイター6や、趣味で遊んでいるゲームを配信しながら、だらだら話すようなスタイルで配信しています。 この記事では、実際にTwitch配信を始めるまでに用意した機材、古いMacBook Proで配信してみた感想、配信を始めて分かったことをまとめます。 これから「家庭用ゲーム機で配信を始めてみたい」「古いMacでも配信できるのか知りたい」という人の参考になれば嬉しいです。 配信を始めたきっかけ もともと格闘ゲームは好きで、ストリートファイター4シリーズをそれなりに遊んでいました。 スーパーストリートファイターIV AE Ver.2012の頃は、家庭用でやり込みつつ、休みの日に新宿のタイトーステーションにも遊びに行っていました。 当時は、AE時代と比べて大幅に弱体化された後のユンを使っていて、一瞬だけグランドマスターに到達したことがあります。 とはいえ、グランドマスターだった期間は本当に一瞬で、実際にはマスター上位からグランドマスターに届くか届かないかくらいの位置にいることが多かったです。 ちなみに、強かった頃のユンはほとんど触っていません。スパ4AEの頃はまだライトゲーマーで、フェイロンを使っていました。 その後、Ver.2012でユン・ヤンが大きく弱体化されたのですが、対戦しているうちに「弱くなったとはいえ、まだかなり強くないか？」と思うようになり、試しに使い始めました。 使ってみると思った以上に自分に合っていたので、そのまま使い続けて、最終的にグランドマスターに届くところまでやり込みました。 その後、ウルトラストリートファイターIVが発表され、ユンに有利なシステム(赤セビ)やキャラ自体の強化も追加されました。ユンは再び強キャラの一角に戻ったのですが、当時は大学受験の時期と重なってしまい、ほとんどプレイできませんでした。 受験が終わった後も、大学生活や社会人生活がそれなりに忙しく、気づけばストリートファイターからはかなり離れていました。 他のゲームはちょくちょく遊んでいたものの、ストリートファイターを本格的...
Post a Comment
Read more

SQLで連続するレコードの比較をする(LeetCode Database)

-
Image
概要 問題 解法 概要 前回 に引き続きSQLです。 問題 +---------------+---------+ | Column Name | Type | +---------------+---------+ | id | int | | recordDate | date | | temperature | int | +---------------+---------+ 今回用意されているテーブルは以上です。 以下のように、前日よりも気温が気温が高かった日のレコードの id を表示してください、という問題です。 解法 SELECT w1.Id FROM Weather w1, Weather w2 WHERE w1.Temperature > w2.Temperature AND subdate(w1.recordDate, 1) = w2.recordDate テーブルを二つ用意し、 subdate 関数を使うことで時間の差を求めます。 売り上げが前日よりも上の日とか抜き出すのに使えそうなSQLとなりました。 SQLは列の比較には強くても、行の比較は思ったより苦手ということを改めて感じました。
Post a Comment
Read more

重複している要素をSQLで抜き出す(LeetCode Database)

-
Image
LeetCodeにDatabaseのカテゴリがある話。 問題 例 解法 LeetCodeにDatabaseのカテゴリがある話。 実はSQLの勉強にも使えるんですよね。 暇な時にEasyから潰したりしてます。 で、解くのはいいのですが、一度解いただけで解きっぱなしだとなんだかもったいない！ あれ？記事として書いてパターン化しておいたら楽なんじゃない？ と感じたので書いておきます。 問題 182. Duplicate Emails Person テーブルのEmail列に重複する文字列が存在するのでそれを抜き出して欲しい、という問題ですね。 例 ±—±--------+ | Id | Email | ±—±--------+ | 1 | a@b.com | | 2 | c@d.com | | 3 | a@b.com | ±—±--------+ 仮に上記のテーブルなら以下の形で返すようにクエリを設計してください。 ±--------+ | Email | ±--------+ | a@b.com | ±--------+ 注意 : Email列は全て小文字です。 解法 # Write your MySQL query statement below SELECT Email FROM Person GROUP BY Email HAVING COUNT(Email) > 1 重複というのはつまり二つ以上存在する、ということなので GROUP BY で分類します。 その後に条件( HAVING 句)として上記の重複の条件を集計関数である COUNT で数え上げを行えば無事完了です。 つまり、重複する要素だけを抜き出したいときは # Write your MySQL query statement below SELECT カラム FROM テーブル GROUP BY カラム HAVING COUNT(カラム) > 1 で一般化できるということですね。 今回はここまで。お疲れ様でした。
Post a Comment
Read more

LeetCodeのDatabaseカテゴリで見つけたTRUNCATE TABLEについて

-
Image
LeetCodeのDatabase問題にて。 181. Employees Earning More Than Their Managers という問題を解いた時の話。 LeetCodeのDatabaseカテゴリの問題では SQL Schema という欄があり、どういったクエリを実行して該当テーブルが作成されているか、またその中に入っているデータはどういったものかを見ることができる。 その中に TRUNCATE TABLE　Employee という一文を見つけた。 Employeeはテーブル名なので TRUNCATE TABLE　テーブル名 という使い方をするものなのだろう。 恥ずかしながら知らなかったので調べてみたところ、指定したテーブルの全てのデータを削除するという内容らしい。 これまではそういった操作はDELETE文で実行していたが、どうやらTRUNCATE TABLE文には以下のようなメリットがあるらしい。 オートインクリメントの初期化 大量のデータが存在する場合はDELETE文よりも高速であること オートインクリメントの初期化がされるのは知りませんでした。確かにDELETE文だと初期化されなかった記憶があるので助かります。 削除が高速なのはDELETE文はあくまで特定のデータを削除することに特化しているからなのだろうか？確かに全て消去しかないのと特定の条件を付けられるものだと後者の方が処理は複雑になる傾向があるが。ここら辺も根本的な理由を調べる機会を設けたいな。 一方で、DELETE文を実行した際のログなどを記録するようなトリガーを設定していても、TRUNCATE TABLE文はDELETE文とは関係ないので当然追跡はできません。そこには注意が必要ですね。
Post a Comment
Read more