MySQL Clientのちょっと便利な設定

MySQL

MySQL Clientでサーバにつないでからのちょっと便利な設定。使いそうなものをピックアップ

use \u

Databaseのスイッチ

pager less -S

less -S と同じようなpager設定になる。-S 1行が長いときに折り返さない設定になる。

tee hoge.log(\t)

hoge.log という名前でログファイルを取る。間違って tee 'hoge.log' とするとファイル名にシングルコーテーションが入るので注意する

ego (\G)

これは query \G として使うことが多い。結果を縦に表示してくれる。

source hoge.sql (.)

hoge.sql を実行する。

status (\s)

現在の設定を表示する

system (!)

\! ls と書くとlsコマンドを実行する

delimiter (\d)

文の区切り文字を変更する。デフォルトは ; 。誰かがきっと使うんだろう

MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.5.1.2 mysql コマンド

MySQLのinsert on duplicate key update と replace構文の違い

MySQL

忘れてたので思い出しながらメモ

TL;DR

  • upsert構文として、insert on duplicate key update と replace構文の2つがある
  • 似たような挙動だけど違う
  • insert on duplicate key update はupdate
  • replace構文はdelete insert になる。

実際にやってみた

こういうテーブルを作ってみる

CREATE TABLE `replace_sample` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `email` varchar(255) NOT NULL,
  `name` varchar(100) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `email` (`email`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

insert into replace_sample(email,name)values('taro@example.com','taro'), ('jiro@example.com','jiro');

mysql> select * from replace_sample;
+----+------------------+------+
| id | email            | name |
+----+------------------+------+
|  1 | taro@example.com | taro |
|  2 | jiro@example.com | jiro |
+----+------------------+------+

insert on duplicate key update を投げる

mysql> insert into replace_sample(email, name) values('taro@example.com', 'saburo') on duplicate key update name='saburo';
Query OK, 2 rows affected (0.00 sec)

mysql> select * from replace_sample;
+----+------------------+--------+
| id | email            | name   |
+----+------------------+--------+
|  1 | taro@example.com | saburo |
|  2 | jiro@example.com | jiro   |
+----+------------------+--------+
2 rows in set (0.01 sec)

replace構文を投げる

mysql> replace into replace_sample(email,name) values('taro@example.com', 'ichiro');
Query OK, 2 rows affected (0.00 sec)

mysql> select * from replace_sample;
+----+------------------+--------+
| id | email            | name   |
+----+------------------+--------+
|  2 | jiro@example.com | jiro   |
|  3 | taro@example.com | ichiro |
+----+------------------+--------+
2 rows in set (0.01 sec)

delete - insert されているのがわかる

リンク

#ISUCON9 に一人チームで参加してきた

結果

2,410 　うまいご飯が食べたい (一人チーム) で敗退でした

詳細

  • 10:40 サーバが10分立っても立ち上がらずに若干焦る。この間にレギュレーションの再確認
  • 10:50 ようやく3台立ち上がったので、gitとかsshを仕込む。
  • 11:00 3台あるので、2台APサーバ・1台をDBにしようと決意
  • 12:00 MySQLのbindの設定で5分ほどハマるが大したことはない
  • 13:00 APサーバの冗長化はできた(Redisを入れることを忘れてた)
  • 14:00 Redisがなぜか aptからうまく入らない...
  • 15:00 APサーバを単に冗長化すると画像がうまくとれないので、冗長化を諦める(ここは後で特定URLだけ1台にすればよかったと気づいた)
  • 17:30 コード改善を諦めてindexを貼る作戦に移行する
  • 18:10 終了。

感想

とにかく一人は手も、アイデアも全てが足りないということを再認識させられました。2年前にチームで出たのですが、個人戦だと全然違ってました。終わってからこうすればよかったと気づいたので、適度な休憩が必要でした。チームでの開発の大切さを再認識と同時に個人で全部やることの楽しさを実感。講評を見ずにどこまでコードのボトルネックに気付けるのか、直せるのか再度挑戦する予定。こういうイベントは非常にワクワクして楽しい。

運営の皆様ありがとう & お疲れさまでした

正しいものを正しくつくる を読んでいる

読書 エンジニア

第3章まで読んだので一旦ブログをまとめる

前提など含めたまえがき

自分は15年弱ぐらいエンジニアやっていて最大でも10人ぐらいのプロジェクトでリーダーをやることが多かった。SIer〜自社サービスとやっている。また、アジャイルでのプロジェクトはあまり経験なくほぼ自己流でやっている。アジャイルコーチやスクラムマスターなどがいたプロジェクトにはいたことがない。

感想

1つの守・離・破の形としてはすごいいい本だと思った。自分がプロジェクトを進める上でできているところ・できていないところをトレースしやすく、このプロジェクトだとここはできてたな、このプロジェクトだと反対にうまくできてなかったなというのが考えやすい気がした。

第2章でのスクラムのコンセプトを推し進めるために５つの価値基準(確約、勇気、集中、公開、尊敬)があるというのが自分の中で印象に残っていて、よく振り返りでKPTで何を振り返ればいいのかよくわからなくなるときがある。(特にKeep)この5つの価値基準を軸にするといいかもしれないと思った。

第3章も自分ではなんとなく「こうしたほうがいいだろうな」と思ってやっていたところを言語化されていたり、ベロシティの計測などできていなかった部分が明確に気づいた。

自分が特にできてないなと思ったところ

  • スプリントの強度の高め方。成功体験は徐々にやっていったほうがいいというのはわかるがどこで強度を上げるか
  • 見積もりのやり方。相変わらず見積もりが下手くそ
  • 余白の使い方が下手なので、調整の余白の使い方は参考にしたいと思っている。広さと深さは意識するようにしたい
  • 言語化、単語化、メンバーに意識をしてもらうところが毎回うまくできてない。自分の経験値で進めてしまっているところが多々あるのでもう少し周りに単語化をして背景含めて明確にしたい

メモに色々書いたけどうまくまとめきれないので自分で書いたメモをまた読み返そう

正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

AWS Solutions Architect - Associate に合格してきた

aws

資格試験なんか 約1X年ぶりに受けたから緊張した

なぜ受けたのか

会社や前職でもAWS使っている(た)し、AWS Summitのラウンジで優遇されたいなーという思いから受けてきた。今年は幕張メッセだから少し萎えてるw あとは都合で時短勤務をせざるを得ない状態なので勉強する時間ができたというのが理由

勉強時間

大体1ヶ月ぐらいだと思う。ただし常に勉強できるという状態ではなかったので毎日はやってない

試験を受けての感想

試験受けて合格したときはホッとしたけどこれをうまく使わないと＆アップデートしないとなぁという思いが湧いてきた。結局AWSとかしょっちゅうアップデートされてるからその時の知識はその時の知識としていいと思うんだけど追従しないと腐っていく知識が多い。(実際に問題集とか見たときには古い情報とかあったし)まぁ「他の人よりは俺AWS好きだよ」ぐらいに捉えておいてもいいと思う。

OKRの本はメンバーが読むには最適の本

読書 エンジニア

感想

記事タイトル通り、導入する会社側が読むのもいいとは思うが、どちらかというとメンバー側がOKRがどういうもので、何をやっていけばいいのかなーという全体的な流れやそれによって自分たちが今と何を変える必要があるのか/ないのかを考えるには最適な本だと思った。サマリはみんな共有できればいいと思うんだけど会社でなにか勉強会的なものやるのかな。それともやったほうがいいかな |дﾟ)ﾁﾗｯ

OKRを導入する目的、手法、どうやってトラッキングしていくかという一通りのことが書いてあった。今までの会社では目標と実際の仕事と評価が乖離するということは多々あって、過大/過小評価されることが多かったが自分の中ではこの手法は現実的にしっかり評価できるイメージが湧いた。決める・ワークさせるところが恐ろしく大変そうだけど。

自分が一番共感できたのはプロダクト・チームのOKRのところ。うちも職能のチームとプロジェクトチームのクロスファンクショナルチームになっているので、OKRを決めたら板挟みになる(優先度P1のタスクが並行して2つある)みたいな感じになるので、どうすんだ？という話になるところの明確な解が出てた。ただし、自分プロダクトチーム以外の人事にも関わっているのでそこはどうすんべか。去年はここの優先度付けを間違えた気がするので改善していきたいところ。

また、OKRを立てるためのスケジュールの章では最初に「全員に次四半期に追求すべき目標を出してもらう」とあったが、オープンに会社の数字やプロダクトの状況、課題を見えるようにしてないと自チームだけ、自部署のみの狭い目標しか出てこない気がするがそれは微妙な気がしているので、OKRの最初に立つためにも色々仕込みは必要そうな気はした。

あとやっぱり iPadMini + ApplePencil 便利やわ。メモアプリに全部書いて色々思考をまとめられる。本の文章を書き写しているのでメモを公開すると著作権的に引っかかる可能性はあるので公開するとはしないけど見直すのに便利だ。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法