叫ぶうさぎの悪ふざけ

うさぎが目印のWebエンジニアが、得たことや思ったことを言の葉に乗せて叫ぶ場所です。

吉祥寺.pm14に行ってLTしてきました

3回目の参加となる 吉祥寺.pm 今回はLTでの参加となりました。

いやー今回も楽しかった!そして濃厚! と言うわけで個人的な感想などをしたためたいと思います。

15分セッション

毎回軽快な @magnolia_k_ のオープニングトークから始まる吉祥寺.pm 今回の前振りは「一句」 なるほど?ということで本編開始です

Talk1: 辛い開発を色々使って迂回した話(@s2otsa さん)

1つの技術にこだわらず、触れちゃいけないところを迂回して工夫して、短納期や諸問題をエンジニアリングで解決したお話でした。(個人の感想です)

個人的には特に以下が印象深かったです。

  • でも本体であるMagentoでなんとかするのはナシだ
    • 首がもげそうなくらい心で頷いてました
  • MySQLの更新できるViewを使って解決
    • 昔に痛い思いしたなーw
  • CSV出力ってよく考えたら管理画面いらない
    • 確かにー!と思いました

  • Magento 2 を使ってECを作ったけど色々あって辛かった
  • でも本体であるMagentoでなんとかするのはナシだ
    • 首がもげそうなくらい心で頷いてました
  • REST APIが結構あって、Reactでレンダリング、クエリはキャッシュで高速化
  • 2つの窓口、異なるドメイン、異なる管理画面
    • クエリだけ分け、同じDBを見る
    • MySQLの更新できるViewを使って解決
  • CSV出力ってよく考えたら管理画面いらない
    • 確かにー!と思いました

Talk2: スクラムやってみた(@papix さん)

このかたはもう、とにかくお話がうまい!そして泰然自若。 トークが始まった瞬間、この場の主のような存在感。 軽快なトークにも魅了されたと言っても過言じゃないです。 スライド公開がなさそうなので感想をつらつらと。

  • チームメンバーが何してるか知るのすごく大事
  • スクラムに正解はない、腹をくくる
  • githubのprojectのカンバン
    • エンジニア・デザイナーが管理するタスクかんばん、プロデューサー、ディレクター、プランナーが管理する企画かんばんを分ける
  • 企画かんばんから次にやるタスクを選ぶ。ディレクターたちと相談して
  • タスクかんばんの見積もりは、みんなでポイントをつけて精度をあげる
    • 一人でやらないってことだし、みんなの目線も合わせられるし、レベル感もわかる
  • あらかじめチームビルディング会を開催。自分がしたいことで、できること、期待してることなどを共有

Talk3: 非エンジニア企業でエンジニアリングしようとした話(@Korenari_D さん)

涙なしでは語れないし聞けない内容を飄々としたトークで展開。やってることの凄さと現場の凄さがなぜか楽しく伝わってきてしまう… こちらもスライド公開はないようなので、感想をつらつらと。

  • 基本的に辛い話
  • シェル芸人
  • 当然Excelなんで
  • JSON渡すとブチ切れる人がいる
  • 一人DevOps
  • エラーが全て400番
  • フェイルセーフの概念がない

あと、一句がなかったので勝手に詠みます。

DevOps
一人でやっても
DevOps

Talk4: データアナリストからwebディレクターに移って1ヶ月経った話(@Yuxio さん)

前々からお名前や活動は知っていたのですが、初めてお目にかかりました。 データアナリストからプレイングWebディレクターへ転したお話、単純にすごいし、控えめな声と仕草からは裏腹な大胆かつ繊細なトーク内容で驚きの連続。 自分が今続けている学習ともリンクする部分があって、色々気づかせてもらいました。 スライドはこちら。繰り返し読んで、個人的なマニュアルにします。

https://docs.google.com/presentation/d/e/2PACX-1vQ8EKGofHJkq3b-FaPzUQ4lcfmy999xCo6GbG5l7UHeayEESOMJZdPLmW38erNZ8V47XGuf0lAAhgJw/pub?start=false&loop=true&delayms=3000&slide=id.p

  • 人の体験をデザイン、すごい
  • バッターボックスにすぐ立てるよういつも素振り
  • ホームランより安定したヒット
  • スキルの安売りをしない
  • 〇〇を任せるならあなた、と言わせる
  • 目的に応じた道具を選択する、目的志向、ゴールの設定
  • 人は自分の思考から抜け出せないから、人に話て枠を広げる
    • 常に勉強!

5分LT

LTは合計8トークもあるので、それぞれ短めに感想を言わせていただきます!

LT1: 僕が考えた最強のRDBリファクタリング(@soudai1025 さん)

詳しくはそーだいさんのエントリを読めば全てわかる!

https://soudai.hatenablog.com/entry/2018/05/25/121801

  • 1年くらい担当を離れてたら、外部キー制約が全て外されていた
    • 感想はこれに尽きますw

LT2: やってよかったこと(@sakura さん)

なんとスライドなしで手元のメモを見ながらトーク! 検索が好き、というか検索という概念が好き。 検索への愛がほとばしる5分間でした!

そしてなんと!たった5分の間にグラレコしてもらっちゃいました!ひゃっほー!

LT3: エンジニアリングで解決するために非エンジニアと一緒にやったこと(まみー)

自分のトークなので割愛、スライドだけ貼っておきますw

一言だけ言うと、そーだいさんとさくらさんが川柳で締めてくれたし、トークもめっちゃ面白かったのでハードルがめっちゃ上がったってことです!

LT4: Const::Common探訪(@songmu さん)

実はPerlは数年前に1年ほど…もはや記憶のカナタに… なので感想を…っ! http://songmu.github.io/slides/kichijojipm-14/#0

  • Perlのgotoよくわからん
    • 色々とすごいコードを見させていただきました

LT5: コンテキストと仲良く(@karupanerura さん)

  • Perlはコンテキスト(データの型解釈をPerlに伝えるルール)を覚えれば仲良くなれる!
    • Perlで開発していた頃は、わかってた気がするんだよなあ

LT6: p5-Lodash 紹介!(kfly8)

Perlで数値と文字列を区別する実装、ってことでいいのだろうか… 自分のPerl力は5なので追いかけるのがやっとでした(震え声

LT7: 機械学習で星座占い(仮)(anapple07_jp)

機械学習で占いを自動生成したお話。 VOGUEのしいたけ占いをスクレイピングしてマルコフ連鎖とか本当にガチな方。 あとでスライドをゆっくり見たかったのだけど、公開はないのかなー?

LT8: 飛び入り(@papix_ さん)

飛び入りではてなブログHTTPS化を頑張った(頑張ってる)話。 Mixed Contents 辛い… 解決したと思ったその時!

  • 絵文字記法が、https対応してない
    • papixは激怒、ならぬ発狂した。丁寧に対応してる!

全体を通して

お小遣いの関係で懇親会に出れなかったのが本当に悔やまれる… いやもう本当に楽しいんですよ。怒涛のトークが凄まじいクオリティで突き抜けていく。 これはもう小さなカンファレンスです。 今後も盛り上げるための一助になりたいなあと毎回思わせてくれます。

そしてとにかく懐が深い! エンジニアリングに関係あってもなくても、Perlに関係あってもなくても、みんな優しい。 何よりバリエーションに富んでいるので、何か必ず持って帰れる。 参加してくださる皆さんの層も多様で、トークをしても必ずインプットを頂ける。 こんな永久機関はなかなかないと思います!

今後は毎回参加をしていきたいし、テーマによっては何度でも登壇していきます。

あと、できれば会費集めてください!こんな素敵な場所を提供してくれているのに、持ち出しなんて…もしマイナスになる場面があったら俺も出しますから!

運営、トーク、聞いてくださったみなさま、本当にありがとうございました!

冬休みの折り紙記録 2018

f:id:Mamy1326:20180115223030j:plain

入社して半年。有給をいただいたので、いいタイミングだなと思い2週間ちょっとの冬休み。 1 結果として今までで一番リフレッシュできました。

そんな中、娘のリクエストで作った折り紙が結構あったので書き残しておきます。

ちなみに撮影は奥さまです。俺には写真のセンスがカケラもない。

もみじ:難易度10

出来上がりはこんな感じ。
f:id:Mamy1326:20180115223122j:plain

裏面はこんな感じ。もうちょい綺麗にしたかった。
f:id:Mamy1326:20180115223208p:plain

1枚の紙で作りつつ、面から見た際に、徹底的に裏側の余白を排除する作りになってます。

海外の方が制作した動画を見ながらでしたが…なんと5部構成。 難易度が高く、試行錯誤を経て完成まで3時間。 これ、ハサミなど一切使わない、1枚の紙から作ってるんですよ…図面書いた人天才だ。

想像以上に綺麗にできたので、今度は黄色と緑のも作ってみるかな。

クリスマスツリー第一弾:難易度6

出来上がりはこんな感じ。
f:id:Mamy1326:20180115223548j:plain

幹+5層、つまり6枚の折り紙で構成されています。

もみじに比べて難易度は高くないものの、折る枚数が多いので完成まで数日。 日に日に高くなって行く様子に娘も喜んでくれたようです。

クリスマスツリー第二弾:難易度8

第一弾の幹がずんどう過ぎて納得が行かず。 他の作品の幹だけ作って移植しようかと思ったら形が合わない。 そのまま放置してたら あー!もうひとつツリー作るのー? とにこにこの娘。

難易度が上がったクリスマスツリー第二弾を作りました。 f:id:Mamy1326:20180115223604j:plain

これは最初に折り目を全部つけてから構築して行きましたので、ちょっとした誤差が完成を妨げる感じに…丁寧に積み重ねました。

4段で完成なのだけど、納得いかないのでテッペンに1段足す予定です。

雪の結晶:難易度7

雪が降らないかなー氷張らないかなー と毎日楽しみにしている娘。 次に何を折ってくれるのかも楽しみにしているらしく、じゃあこれどう?と聞くと作ってー!

というわけで雪の結晶です。折り目なども模様と見立てる作品のようです。 f:id:Mamy1326:20180115223849j:plain

とにかく細かかった。本来はもうちょっと大きな紙で折るみたいだけど、小さい方が綺麗だしなー。 裏に磁石貼って、冷蔵庫に貼りたいよねーってことで小さめに作りました。 ちなみに紅葉の裏にも磁石を貼り、冷蔵庫で遊んでいます。

ダリア・ガーベラ・ちょうちょ:難易度5

どれも簡単でした。ちょうちょは最初普通の折り紙で折ったのですが、花と同じくらいの大きさになったので、4分の1の紙で折り直し。 f:id:Mamy1326:20180115223947j:plain

ダリアは08小隊に出てくるアプサラスみたいだねって奥さんと笑ってましたが、娘はダリアに見えてるみたいなのでよし。

次は…

あまりハサミを入れたり、形が正方形から大きく外れたりするものは個人的に好みではないので。 あくまでも1枚から作る系で作りごたえのある作品を選びたいと思います。

これかなー。長方形だけど面白そうだし。

にぎやか

というわけで、お正月飾りをしまった代わりに玄関を彩ってくれています。にぎやかー。 f:id:Mamy1326:20180115224628j:plain


  1. 2017年12月28日〜2018年1月14日までゆっくりと

2017年を振り返って〜恵まれた1年〜

f:id:Mamy1326:20180101000608p:plain
ねんがじょう

こちらの更新は久しぶりです。 年末にちょっとだけ続いた忘年会も過ぎ。 自宅の内窓の施工や娘との折り紙遊びなどを経て寝かしつけ、やっと年末の落ち着いた時間を感じています。

今年を振り返って、MySQLに始まり、終わりは…うーん…10月あたりから年末までは、ひたすらにAWSだったような気がします。

というわけで、登壇とイベント参加を通して2017年を振り返ります。

登壇

ほとんどMySQLでの登壇でしたね。幸いなことに、年明け早々my.cnfが空っぽのサーバーを持つサービス担当になったので、思う存分調べて設定して計測して調整してました。

第111回 PHP勉強会@東京(初登壇:2月)

第111回 PHP勉強会@東京 2017年2月 のLTで初登壇。 最初はイチ参加者のつもりが、主催者さんからお誘いをいただきお話することに。 MySQLサーバーをセブンセンシズに目覚めさせるお話 と題して、my.cnfから調べてチューニングした話をしました。

いやー5分じゃ全然収まんなかったですね。ここからこのテーマで1年話すと心に決めました。

第112回 PHP勉強会@東京(登壇2回目:3月)

おなじみになった第112回 PHP勉強会@東京 2017年3月 で、MySQLの無駄無駄ァ!を波紋でチューニングするお話 と題して、さらなるチューニングとしてクエリキャッシュを導入し、計測した話をしました。

どうでもいいですが、無理に笑いを取るのは愚策だけど、技術的な内容を話しながら面白くするのはどうしたらいいか、という裏テーマをずっと考えていた時期でした。

第113回 PHP勉強会@東京(登壇3回目:4月)

これまたおなじみになった第113回 PHP勉強会@東京 2017年4月 で、MySQLサーバーをレプリケーションするお話 と題して、初めてレプリケーションし、冗長構成にした話をしました。

会場ではデータに欠損がある指摘をいただいたりして、やり方に間違いがあることにも気づき、あとでやり直しで綺麗にするきっかけをいただいたりもしました。 あ、そういえばQiitaの記事を直してない。これは年始早々にやらねばですね。

MySQLユーザ会(5月)

ほんとMySQLから始まった2017年でした。勢いで MySQLユーザ会会 in 長野 2017 に参加させてもらい、一気にRDB界の巨星たちに出会えたのは僕の人生でも非常に大きなことでした。遠征しての勉強会参加も初めてでした。

とみたさんと梶山さんという巨星中の巨星と3人でそばを食らう、という贅沢な時間からスタートしたのを覚えています。 あとyoku0825さんと初邂逅。めっちゃ背がでかくてポカーンとしてしまった記憶あります。あんなすごい人がこんなのんびりした感じでこんなのっぽだったのか…なんて勝手なこと考えててちょっと混乱してましたw

Y8(登壇4回目:5月)

もっといろんな人が集まる場所で話したい。3回の登壇を経て、そういう思いが募っていました。 そんな時に見かけたY8、さっそくCfPを出しました。CfPも人生初だったので、めっちゃドキドキしてたし、場違いなんじゃないかってずっと思ってました。 お題としては、初めてのMySQLパフォーマンスチューニングという内容で、my.cnf、クエリキャッシュ、レプリケーションまでを比較的丁寧にお話しました。

この頃から、初学者から初心者、初心者から普通まで人を引き上げる層が足りないのでは、という疑問を持ち始めていたような気がします。

PHPカンファレンス福岡(6月)

飛行機での遠征が初となる、PHPカンファレンス福岡。行く前から楽しみにしてましたが、未来の同僚が副委員長だったり、登壇してたりと、盛りだくさんのカンファレンス。 参加者全員をゲストとして丁寧に、本当に丁寧にもてなす。それでいて内容が最高に濃密で、技術が楽しいと思えるお祭り。 遠征してよかったと思うより、これを遠征しない理由がないと心底思わせてくれました。

いろんな意味で、目からウロコ。6月当時は前職の退職を決意していたり、色々あったのですが、このおかげで本当に前向きに物事を考えられた記憶が蘇ります。

builderscon tokyo 2017(登壇5回目:8月)

Y8で勢いがついたこともあり、builderscon tokyo 2017 でCfPを出しました。前回のY8では詰め込みすぎ、20分では駆け足になってしまった反省点もあり、50分枠で応募。初めてのMySQLサーバーチューニング -データベースは怖くない!- というお題でお話しました。

質疑応答含めて55分くらいお話させていただきましたが、この頃ははっきりと、初学者を軌道に乗せるには何を提供したら良いか、と意識してスライドを作り、お話をしていました。

ベストトーカーのsoudai1025さんと控え室でお話させていただいて、僕はそういうアプローチで行きますという決意表明的なことを言ったのもこの時だったと思います。

PHP BLT #8(登壇6回目:8月)

個人的には駆け足だけれど、一つの完成形に至ったと思ってました。 掘り下げるテーマを変えたいな、と思っていた矢先、RDBに画像を入れる是非を呟いた ら神々が降臨したので、そのお話をPHP BLT #8 でLTさせていただきました。

5分にほぼ収まりましたが、ちょっと5分じゃ足りない。そんな感じがしてたのと、もっと個人的に掘り下げたいな、という思いが残った記憶があります。

PHPカンファレンス(登壇7回目未遂:10月)

個人的にPHPerの登竜門と思っていたPHPカンファレンス。同僚と互いに煽るようにCfPを出した記憶があります。 テーマは前述の話を掘り下げた、MySQLで画像を扱うメリット・デメリットと障害・解決事例 と題してお話させていただく予定が、娘の運動会が順延になりまさかの欠席に。。。

非常に楽しみに、かつ同僚と一緒にその場に立つことも楽しみにしていたので、無念さもひとしおだったのを今でも思い出します。

第119回 PHP勉強会@東京(登壇7回目:10月)

そんな折、またもPHP勉強会@東京の中の人からお誘いをいただきました。そんなわけで第119回 PHP勉強会@東京 にて、無事に MySQLで画像を扱うメリット・デメリットと障害・解決事例 をお話させていただく機会に恵まれました。

あー本当に生きててよかったなーくらいに感謝した日でもありました。

LTLovers 3rd(登壇8回目:11月)

かねてから、健康に関する話をしたいと思ってました。なぜなら、みんなおおっぴらに話せないくらいにダメージを受けてしまうことがある内容だったからです。 そんな折、秘密の話題で話すことをテーマにした LTLovers 3rd 話せなかった話 があると聞き、早速申し込み。 とある負傷兵の回復日誌 と題しまして、僕自身が体を壊して回復するまでのことをお話しました。

初のesaのスライドモード、技術なんにも出てこない、センシティブ、と今までとは違うこと盛りだくさんにした登壇でしたが、一定の手応えは感じました。 今後はこういうテーマも積極的に話して行こうかな、と思います。

さいごに

不特定多数の前での登壇、二の足を踏んでました。 が、こうして1年続けてみると、いつからか抵抗が無くなります。 かつ、誰かに役立つことができる、そこから交流が生まれる。 新たな技術の活路が開ける。 意外な人からリプライをいただく。

本当に開眼した1年でした。

僕の話を聞いてくださったみんなに感謝し、2017年を締めたいと思います。

ありがとうございました! 2018年もぼちぼち登壇して参りますのでよろしくお願いいたします。

では、みなさま良いお年を!

MySQL 5.7 以降の初期パスワード変更方法、および強度の話

MySQL 5.7 以降から、インストール直後のパスワードの生成方法が変更になって久しいです。 今更感もあるのですが、僕がしょっちゅう忘れて、個人esaに記録したのを読み返すので、いっそのこと公開してしまえ、と思い、エントリーを書いています。(MySQL 5.7.18で確認)

インストール直後のパスワード

yumなどでインストールした際、rootユーザーのデフォルトパスワードが ランダム生成 されるようになり、パスワードrootではログインできなくなりました。 そして、インストール時、パスワードは コンソール上には表示されません 故に以下から獲得し、ログインする必要があります。

/var/log/mysqld.log の中に以下の記録があります。

[Note] A temporary password is generated for root@localhost: [12桁の英数記号ランダム文字列]
  • まずは初期ログインします
$ mysql -u root -p
Enter password: [上記のパスワード]

パスワードの強度を確認し、必要に応じて変更

さてパスワードを変更しよう、と思って「とりあえず簡単なパスワードにしよう」と軽いノリで変更すると パスワードポリシーでエラー になります。

  • 安直なパスワード変更はエラー
mysql> SET PASSWORD FOR root@localhost=password('root');
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

ではパスワードのポリシーどうなってんの、と確認してみると、初期値を変えろと怒られます。

  • パスワードポリシーの確認
mysql> SHOW VARIABLES LIKE 'validate_password%';
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.

というわけで強度の高いパスワードに変更します。 MySQL5.7 のパスワードポリシー初期値はMEDIUMとなっていて、後述しますが 8文字以上、英数大文字小文字と記号 で構成されている必要があります。

  • 強度の高いパスワードへの変更
mysql> SET PASSWORD FOR root@localhost=password('Mamy1326@');
Query OK, 0 rows affected, 1 warning (0.00 sec)

MySQL5.7 のパスワードポリシーは以下の種類があります。 よりセキュアにするならば、強度を低くしたくはありませんが、適切に管理するから緩くする 判断は各自の責任で行って頂ければと思います。

パスワードポリシー 概要 サンプル
共通 8文字以上
LOW 文字種の制限はなく、パスワードの長さのみチェック 12345678
MEDIUM LOWポリシーに加え、最低1つの数値文字を含み、1つの小文字および大文字を含み、1つの特殊文字 (英数字以外) を含む Mamy1326@
STRONG MEDIUMポリシーに加え、4文字以上の部分文字列が、(辞書ファイルが指定された場合に) 辞書ファイル内の単語と一致してはならない

パスワードポリシーを確認してみる

パスワード変更実施したので、パスワードポリシーを確認してみましょう。

  • パスワードポリシーの確認
mysql> SHOW VARIABLES LIKE 'validate_password%';
+--------------------------------------+--------+
| Variable_name                        | Value  |
+--------------------------------------+--------+
| validate_password_check_user_name    | OFF    |
| validate_password_dictionary_file    |        |
| validate_password_length             | 8      |
| validate_password_mixed_case_count   | 1      |
| validate_password_number_count       | 1      |
| validate_password_policy             | MEDIUM |
| validate_password_special_char_count | 1      |
+--------------------------------------+--------+
7 rows in set (0.01 sec)
  • validate_password_length パスワードの長さが8文字以上 に設定されています。

  • validate_password_policy パスワードポリシーがMEDIUMに設定されています。

あまり変更する必要はないと思いますが、低くするならば相応の覚悟で実施しましょう。

パスワードポリシーを変更してみる

一応、変更方法は以下になります。

  • パスワードポリシーの変更(ゆるゆる)
mysql> SET GLOBAL validate_password_length=4;
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL validate_password_policy=LOW;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE 'validate_password%';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| validate_password_check_user_name    | OFF   |
| validate_password_dictionary_file    |       |
| validate_password_length             | 4     |
| validate_password_mixed_case_count   | 1     |
| validate_password_number_count       | 1     |
| validate_password_policy             | LOW   |
| validate_password_special_char_count | 1     |
+--------------------------------------+-------+
7 rows in set (0.00 sec)

注意点

validate_password_policy=MEDIUM に設定しても、LOWだった頃に設定したパスワードは有効です。 LOW→MEDIUMに強度を上げた場合は、パスワード再設定を忘れないようにしましょう。

さいごに

パスワードを適切に取り扱い、あなたも素敵なセキュアライフを!

未来の九十九神との出会い

先日、一生使うであろう家具と出会いました。 が、それは買うときとは違う傷が付いていました。 僕たち家族はそれを当たり前のように受け入れ、生活の一部としました。

その顛末と、

  • 出会いのきっかけ
  • お迎えの覚悟
  • 到着、そして…
  • 人とのお付き合い

に付いて語ってみたいと思います。

出会いのきっかけ

7月末に引越しをしたのですが、その際、お部屋のレイアウトが前回とまるで違って来ました。 抜本的に解決するには ちゃんとした食器棚 が必要だと感じ、探し始めたのでした。

推測と、検証を前提とした選抜

  • このくらいの高さで
  • このくらいの奥行きで
  • このくらいの幅で

と言う メジャーでの推測 は幾度も実施しました。 が、実際の圧迫感、使用感、質感など、検証はできていませんでした。 そこで、まずはネット上で検索した数多の食器棚たちの中から、選抜していくことになりました。

選抜

計測したサイズから、

  • 最適な用途
  • 希望する容量
  • 許容できる高さと奥行き
  • 我が家に自然と溶け込む好み

のレンジをあらかじめ決め、それに沿って複数の候補を選択。 リスト化し、メリットデメリット的なことを話し合い、選抜して行きました。 結果を家庭内Slackでメモしつつ、ここである程度の条件は固まりました。

出会い

最初はサイドボード、もしくはカウンターのような 補助的な家具 を探していました。 なぜなら、今ある家具をそのまま活かしつつ、不足を補うことを考えていたからです。 しかし、とある出会いから考えが一変します。

なんと、現在ある家具を2つ廃してでも、一生使いたい食器棚に出会ってしまったのです。 まさに運命の瞬間でした。

僕と奥さまがうん、うちにお迎えしたいね って思えるものであったことと同時に、娘が これいいねっ って言ってくれたことも大きかったように思います。

お迎えの覚悟

お迎えするにはそれなりの覚悟が必要でした。なぜなら…

ワンクッション

それなりに高額でした。 今ある予算を大幅にオーバーするお値段。 お迎えしたいという強い気持ちはありつつも、気軽に購入するのは、財政的にも、気持ち的にも、ワンクッション置く必要があるように思われました。 八王子の村内家具まで行って出会った子でしたが、そうそうなくなりはしないだろう、と言う判断もあり、その日は帰っていったん熟考することにしました。

検証

帰宅する前に、あらん限りの撮影をしていました。 娘を寝かしつけたあと、

  • 実際の奥行きと幅にビニール紐を切り、床と壁にテープで貼り、導線を検証
  • 実際の高さのダンボールを立て、圧迫感を検証
  • 財政的に可能かどうか、家計を検証
  • 移動する家具の再利用が可能かどうか実測して検証

を実行しました。

結果として、 問題ない と言う結論に至りました。

セカンダリーインデックス?

自宅からほど近い、我が家の大事な家具たちも来てくれた大型家具店でも確認してみようという流れに。 翌日のスケジュールを立て、就寝。

動作検証

翌日、家族3人、軽い気持ちで出立。 行ってみると、なんとそこには…

  • ナラ材の高騰から、生産がストップした関係で
  • 現品処分で全く同じ商品
  • お値段5分の3

が鎮座しているではありませんか。

覚悟を決める

とはいえ展示品。どこかに見えない傷や凹み、歪みがある可能性は捨て切れません。 店員さんに詳しく聞くと、詳細かつ丁寧なご説明をいただくことに。

ちょっと考えさせて欲しいとお伝えしたあと、再度その子のもとへ。

開け閉めし、なんども触れ、ちょっと離れて眺めつつ。 よし、この子を我が家にお迎えしよう と僕と奥さまの覚悟は決まりました。

購入手続き

近いとはいえ送料もかかるし、梱包から配送まで時間もかかります。 大型家具を梱包して届けていただくには破格のお値段(送料は¥1,000 でした) 家具屋さんに感謝の意をお伝えしつつ、購入手続きを経て帰宅しました。

「やったねー」「楽しみだねー」なんて3人で話しながら帰ったものです。

到着、そして…

予定通りの日時に、その子は我が家にやって来ました。 手際よく梱包を解き、土台から組み上げていく配送担当さん。 ほどなく、予想していなかった説明を受けることになります。

傷と凹み

おそらく配送担当さんに引き渡したあとだったのでしょう(後から本社より詳しく誠意満点な説明をいただけました) 普段使いでは一切に気にしない場所、でも食器棚の下段の奥を見ると、明らかな凹みと傷 がありました。 配送担当さんには、

  • 購入した際にあったかどうか

を丁重に聞かれ、それはなかったことをお伝えし、

  • 購入の意思は変わらないか
  • 現状を撮影し、すぐに本社で判断、連絡をさせる

と言う旨を説明いただきました。

揺らがない覚悟

僕ら家族は、自分たちの一部としてその子をお迎えする覚悟をしていました。 これが

  • 真っ二つになっていたり
  • ガラスが割れていたり
  • 扉が閉まらない

など、外観と機能性に問題があれば、考えたと思います。 が、普段使いでは気にすることなく、機能性も堅牢性にも影響がないことは説明でも実感でも理解できました。

また、誠意ある対応もあり、僕らは一もなく二もなく そのままお迎えすること をお伝えし、設置していただきました。 まったく覚悟は揺らぎませんでした。

惚れるということ

商品をドライにやり取りするだけなら、過剰なクレームにも発展 することもあるのでしょう。 のちに本社から連絡をいただいた際に 全く問題ないし、惚れて我が家にお迎えすることに変わりはないです とお伝えした時の先方の感謝の気持ちは、電話越しでも本当に伝わって来ました。こちらから何も言ってないのに、想定外の割引 までしてくれました。

こういう時、普通なら大きなクレームとともに返品されて、かつ何か別のものを無茶に要求されたりするのだろうなあ…と想像しつつも、この子もお店ともいい出会いをしたなあ って思ったのを覚えています。

惚れるってこういうことなんだろうなあ、って。

余談ですけど、奥さまの実家で犬を飼うとき。 この子は本当に性格がきかんぼうですけど、本当にいいですか? と何度も念を押されたそうです。

その際に奥さまのご家族全員で即決したのが。 うちに来たのもご縁。他所に行くより我が家で可愛がって、共に過ごそう ってことでした。

この時、笑いながら奥さまと「その時と同じだね」なんて話をしたのも思い出します。

人とのお付き合い

僕らは日々、何かを売り、何かを買うわけです。 そこには必ず 人が介在 します。

人には必ず情があり、生き物ですので疲れもすれば傷つきもします。 しかも互いに覚悟を決めて、誠意ある対応をいただいてました。 これもまた 何かのご縁 と、我が家では思うようになっています。

そういう人だからこそ、互いに結婚したのかもしれませんね。

人がいるからこそ、僕らは生きていける

壮大ではありますが。 どんな小さなことでも、誰かが作っています。 誰かが受け継ぎ、誰かがメンテナンスし。 誰かのおうちに旅立っていきます。

作る人。 売る人。 買う人。

全部いるからこそ、僕らは生きていけるのだと感じます。 であれば、感謝しあった上で、生活していきたいと、少なくとも我が家では思います。

これもまた、 いい人との出会いだった のだなあ、と思っています。

未来の九十九神

我が家では、相当の覚悟がない限り、大きな家具を買いません。 近い将来、戸建てを購入しようとも思っています。 それを考えてもなお、お迎えしたい。 長く長く使いたい。

我が家の 未来の九十九神 となる。

そんな子がまた増えました。

立派な食器棚を目の前に、奥さまと二人 …一杯やれるよなあ なんて言いながら、新しい子をお迎えしたのでした。

今では、とてもとても自然に、我が家に溶け込んでいます。 帰って落ち着く場所。 いいなあって想いをエントリーにしてみました。

感謝って大事だなってこと、忘れないようにしたいです。

ものを作るとはどういうことか考える -誰のためのデザイン?-

Goodpatchメンバーに聞いた!UIデザインを知りたい人へのおすすめ本13選

こちらの記事を読みました。

  1. 誰のためのデザイン?

見た目の良いものを作る職業ではなく、使い手(ユーザー)を思いやった設計をする

この記述から、僕が日頃思っていることを書いてみます。 他の項目はまだ読み込みと考察が足りないので、また今度。

ユーザー体験不足とデータの歪み

データと画面は写し鏡であって、ユーザーがどんなデータを求めているかが、そのまま画面に表れると常々思っています。

テーブル設計が歪だと、利用するパターンの洗い出しや想定、シミュレーションが不足していることになり、結果データは歪むことになります。 つまり、作り手がUXを体験していないということになるのだろう、と思っています。

歪みは負の遺産

作り手がUX不足だと、当然UIも歪みます。 UIが歪んでいくと、付随してデータが歪むだけでなく、同じかそれ以上にプログラムが歪むことになります。 こうなるともはや「負の遺産を製造」しているにすぎず、世の中に無駄を配信するに他ならないと感じています。

「要件」は神の啓示ではない

自社であろうと、お客さまであろうと。 要件とは神託ではなく、我々が共に作り、運用で共に歩むものだと思います。

ゆえに。 要件に対し、お客さんよりもその先のユーザーに、可能な限り真摯でありたいといつも思います。

求めているものと違うUIなど、お客さんにツラい体験をさせているだけ。 つまり「最悪なUX」の提供に他ならないのですから。

世の中に価値あるものを生み出すために

決して押し売りや自己満足であってはならない、といつも自分に言い聞かせています。 「誰のためのデザイン」かを、肝に銘じて、大事なところを妥協せずに行きたいです。

db tech showcase OSS 2017 に行ってきた

MySQLのいろんな話題が聞きたいなって思ったので、db tech showcase OSS 2017の初日に行ってきました。

ハッシュタグは「#dbts2017 #dbtsOSS」こちら

諸般の事情で後半2セッションしか視聴できませんでしたが、僕にとっては、以下の情報が得られたので非常に有意義でした。

  • Spiderによるシャーディング
    • そもそもシャーディングをよくわかっていなかった
  • MySQL5.7のトラブルシューティング
    • 書籍・ブログ以外で誰かに習ったことがなかったので、基礎を確認したかった

視聴したセッション

Spiderストレージエンジンの使い方と利用事例 他ストレージエンジンの紹介

正直、僕のスキルでは話についていくのがやっとだったので、Tweetを貼るだけにしておきます。 実務で使う場面を想像できないけど、「こういうもんだよ」ということはわかった気がします。



MySQL 5.7トラブルシューティング 性能解析入門編

言うまでもない漢のコンピューター道の人、奥野さん。 ここ半年やってたトラブルシューティングは手探りだったので、基礎をきちんと聞いておきたかったのです。 視聴した内容は全部録画して見直したいくらいですが、自分の理解を振り返るためにも、これまたTweetをメモ代わりに貼るだけにします。 時間見つけて調べた結果を形にしたいとは思いますが・・・未定です。

www.slideshare.net

パフォーマンスとスループットの違いや・・・

それぞれの基礎・・・

工夫や計画大事だよ、と

動作を知って仮説を立てる

統計情報は前後が大事、単発では意味ないよ、と

ビジュアルでEXPLAINが見れることを初めて知る

5.5では調べてなかったパラメーターを知る

セッション関連は下手にいじらない方が良いとのこと

パフォーマンススキーマの基礎の話や・・・

ダイジェストサマリテーブルの話

sysスキーマの話

オプティマイザトレースの話で本の紹介!

5.5から5.7に変えない理由はないと呟いたら、@i_rethi さんからご指摘を頂く!

理解を深めるためにも、1つずつ検証する必要がありますね。 本がまだ届いてないので、来たら資料にまとめたいと思います。

懇親会

なんと1000円。 まさかの🍣🍺

前回、MySQLユーザー会会@長野でお会いした方々にもお会いでき、明治さんとお腹を触りあったり、奥野さんと会話させて頂いたり、データベース界隈の有名な方々と交流できてよかったです!

家族でお出かけのため、二日目は参加できませんが、DB界隈は引き続き注視して行きたいと思います!