投稿

ラベル（SQL）が付いた投稿を表示しています

HHKB Professional HYBRIDを買って半年ちょっと使っている話。

-
イメージ
昨年の9月に購入しましたHHKB。 一時期英語配列のキーボードを使っていましたが、今回は日本語配列をチョイス。 PFU キーボード HHKB Professional HYBRID 日本語配列／墨 良かったところ タイピング時の打鍵感、音が心地良い     これがかなりデカい。直近の生成AI周りの発展のおかげで直接タイピングしてコードを書くことは以前に比べるとかなり減ったけど、それでも全然使うのでここのストレスがないことは大きい。 ただ、これも人による部分が大きいと思う部分なので事前に触れる箇所があれば触った方が良い。 HHKBの公式サイトにタッチ&トライスポット というページがあるので実際の打鍵感や音を確認したい人はそこで検索してのをおすすめします。 僕の場合、当初は HHKB Studio を買おうと思って秋葉原の遊舎工房というお店で触らせてもらいましたが、正直打鍵感と音の感じが好みではなかったのでボツ。 横に置いてあったこっちのキーボードを触ってみたらかなりしっくりきた。他にも色んなキーボード（同モデルの静音タイプとか）が置いてあったけど、長いこと使うなら手に馴染むモデルが良いと思ってそのまま購入という流れ。 あと、個人的には気にならなかったけど、色んなところのレビューを見る感じ音に敏感な人と同居してるとか赤ちゃんがいる家庭とかだと少し苦情が出るかも、なくらいの音が出るのでそこは注意すべき。多分そういった人向けに静音モデルがあると思う。 Bluetooth接続できるデバイスの数が多め これもかなりポイント。仕事用のPCにもプライベート使っているPCも両方ともクラムシェルモード（PCを折りたたんだまま外部ディスプレイに接続して使用するモード）で使っているので、仕事を始めるタイミングや終えて切り替えるタイミングで物理ケーブルの切り替えに手間が掛かるのが嫌だった。 HHKBを使用する前に使用していたMagic Keyboardなんかは複数デバイスに対応していなかったため、いけてないなと思いつつ使っていた。 今はコマンドで接続先を切り替えるだけなのでそのストレスは大きく減った。お高いキーボードであれば標準的に乗っている機能なんだろうけど、なんでMagic Keyboardはこの機能がないんだろう・・・ 良くないところ 割と頻繁な頻度で単三電池...
コメントを投稿
続きを読む

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

-
イメージ
概要 問題 解法 概要 前回 に引き続き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は列の比較には強くても、行の比較は思ったより苦手ということを改めて感じました。
コメントを投稿
続きを読む

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

-
イメージ
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 で一般化できるということですね。 今回はここまで。お疲れ様でした。
コメントを投稿
続きを読む

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

-
イメージ
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文とは関係ないので当然追跡はできません。そこには注意が必要ですね。
コメントを投稿
続きを読む