叫ぶうさぎの悪ふざけ

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

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

MySQL

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界隈は引き続き注視して行きたいと思います！

PHPカンファレンス福岡 2017 に行ってきたぞ！

飛行機を使っての遠征では初となる、 PHPカンファレンス福岡 に参加してきました。 各セッションとスライドはこちらにまとめてくださっています。
[NEW]本家のタイムテーブルを@akase244 さんが更新してくださってます。
最新のPHP7系の話から、つらみのある5.3系を交えた話、レンサバの裏側を支える技術や、高負荷に耐える話など、実装から運用まで幅広い話が聞けた印象です。 新しいプロダクトをスピードで世に送り出す人がいれば、裏で支える人もいる。 そんな カンファレンス自体が大きなプロジェクト という印象を持ったお祭りでした。

前入り (6/9)

前入りした方が絶対に楽しい、と @tomzoh さんより念押しされていたこともあり、喜び勇んで前入りしました。

Fusicさん (6/9 〜18:15)

前入りする人向けに、株式会社Fusicさんが会場を提供してくださいました！

その場で #phpgenba が 収録されるなど、大変面白かったです。 ちなみにデカい笑い声は、@koyhogeさんは確実で、あとは僕かもしれませんw

ちょっとお手伝い (6/9 18:30〜19:30)

会場はCCB、じゃなかった、FFBこと、Fukuoka Fashion Bldg. です。 あっという間に #phpgenba の収録時間が過ぎ、懇親会まで時間もあったので、ちょっとお手伝いに。 エンジニアたちが作業をどんどん最適化していく様を体験できました。 @akase244 さんと @hamaco が名監督！ 甘い脇の乙女もいたし！
しかし、こんなこと言われると…好きになっちゃうじゃない！


前夜祭

非常に楽しく飲んで食べました。 二次会は念願のエールズへ！ 三次会では @gorogoroyasu さんのご案内で、博多で一番うまいというラーメン、元祖長浜屋を堪能！本当にうまかった！(画像なし)

当日のセッション

僕が拝聴したセッション と、感じたことの全てを思うがままに叫んでみます。

PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計：和田さん (10:30-11:15)

このお話はたぶん3度目だったのですが、3度目にしてやっと身に染み入ってきたところもあり「読み返す」「聞き返す」「実行する」のはやはり基本中の基本だと思いました。 まず自分の中の規約的、お手本的に、さらにモノにして行きたいです。



新卒2年目がサービス開発の際に乗り越えた課題とその解法など：濱野さん (11:30-12:00)

もっとよくする方法がたくさんあるので、その後の話をまた聞きたいと思いました。 2年目ということは、今後のご本人の伸び代も含め、未来はどうして行きたいかも加味した登壇があったらいいな。 またどこかで登壇しますよね！！！ レガシー環境と戦った同志としても、応援しています！



ひとりLT大会：(倍速も)安定の平田さん (11:00-11:15)

実は拝聴してないんですが(笑)、y8の懇親会のLTといい、今回の後半のLTといい、平田さんはもう「倍速LT芸人」と名乗ってもいいんじゃないかと常々思ってました(笑) ちゃんと全部聞き取れましたよ！！！


内容も新たな挑戦だけでなく、シンプルでわかりやすい内容、かつ応用の効くテーマ。今後も何を話してくれるのかなって期待しちゃいますし、しています。 後、真面目な話、とりあえず日本で一番の「倍速LT芸人」を襲名してほしいなあと思ってます！

実践Action Domain Responder：竹澤さん (13:00-13:45)

竹澤さんはいつもあまりに突き抜けた話をされるので、正直ちょっと怖い人かと思ってました（笑） が、話してみるとすごく気さくで優しく、そしてあったかい人柄で、周りに人が集まるのは宜なるかな、と一人納得してしまいました。声がすごく甘くてほんわかします。みんな惚れるといい！

speakerdeck.com

内容に関しては「問題を細かくして1つずつ解決できる形にする」のはタスクの基本だと思いますし、これは最初から、もしくは部分的に実施すれば「開発が気持ちいいだろうなあ」と思って聞いてました。 でも「じゃあ実際の開発でどのように用いればいいのか」と@koyhogeさんと話していて、モヤっとしてたのでご本人に直撃。 やはり思った通り「活用する場面やフェーズは選びますし、これが全てではありません」とのこと。 また、Actionが無数に増えていっても、役割ごとに独立していて、それが並んでいるだけだから、1階層に数百のファイルになったとしても、探すのに苦労はしない、というお話も聞け、自分の中にすっと入ってきたことで、総合的にすごく納得感のあるお話を聞けて満足でした。 おそらく「最小の役割別に細かくbranch切ってpushできる」ことで「課題を進めやすい」ところも魅力なのだろうと感じてます。 実際の業務で使うかどうかはわからないですが、自分が作るならこの方法がいいな、と思いました。

1,800リクエスト/秒の世界：長谷川さん (14:45-15:15)

秒間200リクエスト程度をさばいて「ヒャッホウ」してた自分としては、桁が違うアクセスをどうさばいたのかすごく気になってました。

どんな裏技が見れるのかと思いきや、本当に綿密な計画、計測、対策と、段階的なリハーサル、本番での運用体制、工夫など、盛りだくさん。 index張り忘れは全く同じ経験したので「あーw」とか思いながら聞きました。 どこにネックがあり（予測して）、どのような対策を打ち、それでもダメな時どうするか考え、バックアッププランを用意。 それだけでなく、実際のスパイクアクセスを目の前にして「やばい！」って時の即応力。 そんな奥深さを見せていただきました。 今後の自分の指針にもして行きたいと思った発表でした。

WHERE 1 = 1〈LT〉：金澤 裕毅さん (17:05-17:10)

見るだけでパワーワード感満載な「WHERE 1=1」の後にコメントで「– おまじない」って書いてたプロジェクト経験者として、まるで他人事ではありませんでした。 こういうつらみを笑いと共に共有するのって大事だなーと改めて思ったので、僕も今後の啓蒙活動の要素に加えて行きたいと思いました。 LT資料は公開できないとのことなので、金澤さんのブログのURL、PHPカンファレンス福岡 2017に登壇しましたを紹介させて頂きます。

他の方の感想

見直しつつ追記します！

セッションを拝聴しての感想

「堅牢にするにはシンプルに」「運用は綿密かつ慎重に」この2つを再認識できた場でもありました。 通常の業務ではついついおそろかにしがちなこの2つ。 実は基本中の基本、家で言えば土台どころか多分地殻レベル。 今後も地に足つけた活動と、そこで得た知見を広めるべく、全国的に活動したいと思っています。
本当にいい刺激を受けたお祭り！福岡までの繋がりも含め、いろんな人のおかげで、ずっとどこかで喋り続ける気持ちが湧いてきましたよ！

懇親会

LTでは定番の場面があり…

人間の鑑のような人がおり…

おやおや、穏やかではない人がおり…

もう一人穏やかではない人がおり…

そして土下座…

からの…

ひさてるさんとは ちょいワルふざけおじさん コンビということで今後活動したいと思います。
しかし結局 @hamaco が土下座しなかったのが納得行きませんね。ええ。

二次会

@uzullaさん、@MATTENNさん、@kaz_29さんとじっくり話したり。
かずさん、今後は何かやって行きましょう！
そして魚の旨さは優勝レベル！
20170612174619

三次会

定番のエールズ。ちょっとしかいられなかったのですが、「倍速LT芸人」こと @debilityさんとめっちゃ話ができました！しかしこの頃から記憶がちょっと曖昧に…

四次回

@hamacoがサクッと検索して探したバーがすごくよかった！
ちなみにこれはホワイトレディというカクテル。おいしいのですよー。
開会司会の委員長のウイスキーの造詣の深さに驚嘆しつつ、左側で半分寝てた @hacktkさんにソフトタッチしながら、@hamaco、@uessy_akr、@fakephperさん、じゃない、@cakephperさんとまったりお酒を楽しみました。
20170612174623

五次回

ラーメン！ホテルまで送ってくれた上にラーメンまで付き合ってくれてた @uessy_akr、@hamaco、ありがとう！
うえしーとは相合傘でした。



後夜祭

こんなことがあった模様です。



お土産

自宅にて。奥さまの分身みたいなゆるキャラと。
20170612224355

余談

この日になって初めて、僕の作成するスライドが和田さんと酷似しているのに気づき、変な汗が出ました（笑） 「社内プレゼンの資料作成術」という本を参考に

  • コンソールっぽく、かつ照明が明るい場合も考えて背景色は黒
  • 伝えたい文字はとにかく大きく、1ページは五行以内に
  • 強調文字色はvimのハイライトを参考にvividに
  • 話すペースとスライドの進みがリンクするように分割
  • テンポを大事に

などなど考えた末のことだった、とご本人とお話できてよかったです！

ちなみにy8での僕の登壇資料もついでに貼っておきます！そっくり！！



今回一番の驚き

なんと、@tadsanとこんな事実が。思わずしばらく膝の力抜けてましたw



スタッフの皆様へ

スタッフの皆様とは、初めて会った気が全くしませんでしたw そして、皆様あってのお祭り。心身ともに全力で楽しませて頂けたのは、場、資金繰り、宣伝広報、募集、採択、それに伴う全てのタスクをスタッフの皆様全員で着実に実施してきたからこそだと思います。 本当に心からの感謝しかありませんし、前日の袋詰めだけでも参加できて、本当によかったなって思いました。1％くらいは恩返しできたかな？って。 本来ならば一人ずつご挨拶したかったのですが、お祭りの熱気の中でなかなかできず、ちゃんとお礼を申し上げられていないスタッフの方もおられるかと思います。 この場を借りてお礼を申し上げると共に、いずれまたお会いした時にまた、仲良くさせて頂けたら本当に嬉しいです。

そしてもちろん、若い二人の今後にも注目しています！！（意味深ということではないぞ！） 司会進行、本当に微笑ましく、ほんわかしながら、力強く聞かせて頂きましたよ！！

あと、

  • 小心者だが大胆不敵、船上の女神＠土下座の女王様 (@chiyochan81)
  • 漏れ出るつぶやきに人間味満載、影の宰相＠赤の貴公子殿 (@akase244)

にも、よろしくお伝え願います。(誰となく)

終わりに

お財布に厳しい遠征だったにも関わらず、笑顔で送り出してくれた奥さま＆娘さま、ありがとう！

そして、六本木BrewDogで目を見据えながら、開口一番 あのさ、福岡行こうよ！ぜっっっったいに楽しいからさ！って言ってくれた@tomzohさん。福岡に来れたのはキミのおかげだ！ほんとありがとう！

いやー楽しかった！みんなみんなありがとうありがとう！

俺もどこかで何かを発表して行くぞー！