kakakakakku blog

Weekly Tech Blog: Keep on Learning!

投票サービス「DirectPoll」を使ってイベントを盛り上げよう

最近イベント中に「参加者アンケート」を取得する必要があり,普段はお手軽に挙手をして頂くことも多いけど,より臨場感のある演出を検証するため,前から気になっていた投票サービス「DirectPoll」を試してみた.投票するとリアルタイムにグラフが更新されるため,とても盛り上がった.「DirectPoll」は無料で使えて,すごく便利なので,基本的な機能を紹介したいと思う.

directpoll.com

設定画面("Cockpit" と呼ぶ)

新規投票("Poll" と呼ぶ)を作る場合,"Cockpit" と呼ばれる設定画面にアクセスする.以下はブログ記事用のサンプルとして「よく使うプログラミング言語は?」という新規投票を作った.タイトルと選択肢を直感的に入力できるし,迷うことはなさそう.さらに右側に「SETTINGS」「QUESTION TYPE」があり,細かな設定もできるため,後述したいと思う.

f:id:kakku22:20190717213533p:plain

投票画面("Vote" と呼ぶ)

作成した新規投票を公開すると,以下のような "Vote" と呼ばれる投票画面にアクセスできるようになる.

f:id:kakku22:20190717214235p:plain

もし設定画面で「multiple choice」を有効化すると,以下のように複数項目に投票できるようになる.

f:id:kakku22:20190717214936p:plain

投票結果画面("Results" と呼ぶ)

実際に10件ほど投票し,"Results" と呼ばれる投票結果画面を表示すると,以下のようにシンプルなグラフで結果を確認することができる.投票するとリアルタイムにグラフが更新されるため,大人数であるほど臨場感が出る.大きなスクリーンに表示するとなお良し!

f:id:kakku22:20190717214547p:plain

また設定画面で「Show results in %」を有効化すると,以下のように % 表示をすることもできる.投票数よりも割合を重要視する場合は「Show results in %」を使うと良さそう.

f:id:kakku22:20190717214743p:plain

投票結果画面のデザイン("Look" と呼ぶ)

"Look" と呼ばれる投票結果画面のデザインは以下の計4種類から選ぶことができる.

  • Dark background look(デフォルト)
  • White background look
  • Transparent background, light look
  • White background, single colored bars

例えば,2番目の「White background look」を選ぶと,以下のように白基調になる.

f:id:kakku22:20190717215137p:plain

Restricted Poll

設定画面で「Restricted Poll」というオプションを有効化すると,プライベート利用を前提とした新規投票を作ることができる.プライベート利用として,投票画面にアクセスする前にトークンを求められるため,事前に管理者からトークンを配布する必要がある.

f:id:kakku22:20190717215432p:plain

トークンは設定画面からダウンロードすることができる.以下のような5文字のランダム文字列となり,最初から500個取得できた.

axwqn
e4pw3
rtmpm
xfe69
ukhm7

まとめ

  • 投票サービス「DirectPoll」を試してみた
  • 「single choice」「multiple choice」「Show results in %」など細かな設定もできる
  • プライベート利用の場合は「Restricted Poll」を有効化して使う

2019年(1-6月)のプルリクエストを振り返る

2016年から OSS に送ったプルリクエストを振り返る記事を書いている.今までは毎年年末に振り返っていたけど,今年は既にプルリクエストの件数が多いため,2019年(1-6月)の期間で振り返ることにした.過去の振り返りは以下にある.そして,2019年(1-6月)で「計12件」だった.

プルリクエストを振り返るための検索

プルリクエストを振り返るために GitHub の検索条件を使う.created:2019 を使うと2019年に限定できるけど,今回は「2019年(1-6月)」に限定する必要があるため created:2019-01-01..2019-06-30 を使う.

is:pr is:public author:kakakakakku -user:kakakakakku created:2019
is:pr is:public author:kakakakakku -user:kakakakakku created:2019-01-01..2019-06-30

日付の検索条件は,GitHub の公式ドキュメントに「Query for dates」として載っている.今回使った .. 以外にも :>:>= などもサポートされている.とても便利!

help.github.com

2019/01

docker/docker-bench-security

「Docker Bench for Security」を試していたら README.md に載っていないオプションを発見して,修正した.Docker (Moby) 関連のリポジトリにプルリクエストを出す場合,コミットメッセージに署名を追加する必要があり,git commit --signoff を経験することもできた.

github.com

「Docker Bench for Security」の詳細は以下の記事にまとめてある.

kakakakakku.hatenablog.com

openfaas/workshop

FaaS フレームワークの「OpenFaaS」に興味があり,公式ワークショップを試していたところ,日本語の手順に誤りがあり,修正した.もう1件は手順として意図を読み取れなかった部分を修正したけど,Close となった.

github.com

github.com

「OpenFaaS」の公式ワークショップの詳細は以下の記事にまとめてある.

kakakakakku.hatenablog.com

2019/02

awsdocs/aws-sam-developer-guide

AWS SAM CLI を使って sam init --help を実行したときに,ランタイムの一覧がドキュメントと異なることを発見して,修正した.

github.com

2019/03

awslabs/aws-devops-essential

CI/CD を体験できるワークショップ「aws-devops-essential」を試していたところ,Markdown をより読みやすく改善できる部分が多くあり,修正した.

github.com

2019/05

microservices-demo/microservices-demo

マイクロサービスの学習に使えるサンプルアプリケーション「Sock Shop」を試していたところ,Fluentd + Elasticsearch + Kibana を使ったログ可視化の機能が動かず,Docker Compose に指定されているイメージ名に問題があることを特定した.本来なら Elasticsearch 7 など,最新バージョンを使うべきだけど,アプリケーションの実装と合わない部分があり,ワークアラウンドとして Elasticsearch 5 + Kibana 5 にして,動くようになった.

github.com

「Sock Shop」の詳細は以下の記事にまとめてある.

kakakakakku.hatenablog.com

jmespath/jp

「JMESPath」の仕様を学ぶために JMESPath CLI : jp を試そうとしたら,README.md に書いてある brew の手順に誤りがあることを発見して,修正した.早めに Merge してもらえると良いんだけど.

github.com

「JMESPath」の詳細は以下の記事にまとめてある.

kakakakakku.hatenablog.com

awslabs/aws-devops-essential

3月に続き「aws-devops-essential」を試していたところ,手順に不明確な部分があったり,AWS Lambda のランタイムとして指定されている Node.js 6.10 が EOL になったりして,うまく動くように修正した.ワークショップを今後試す人たちのためにも継続的にメンテナンスをしていく.Merge してもらえると良いなぁー!

github.com

github.com

github.com

mackerelio/documents

mkr コマンドの新機能 mkr wrap を試していたところ,ドキュメントに typo を発見して,修正した.Mackerel 関連のドキュメントは今年3月頃に OSS 化されている.今後も積極的にプルリクエストを送りたいと思う.

github.com

mkr wrap の詳細は以下の記事にまとめてある.

kakakakakku.hatenablog.com

mikegcoleman/todo

Amazon Lightsail Workshop を試していたところ,サンプルアプリケーションで TODO を編集するとエラーになった.MongoDB 関連の実装に問題があることを特定して,修正した.

github.com

まとめ

2019年(1-6月)で「計12件」のプルリクエストを送ることができた.2019年(7-12月)も頑張る!

「DevLOVE X」に参加してスピーカーの情熱を感じた

6/23,24 に開催された「DevLOVE X」に参加した.少し遅れてしまったけど,印象に残っているセッションを中心に紹介したいと思う.どのセッションもスピーカーの情熱を感じた.DevLOVE X では,久し振りに会う人がいたり,ブログメンタリング卒業生に会えたり,Twitter でフォローしている人に会えたり,様々な出会いもあり楽しかった!

devlove.wixsite.com

僕自身は「Day.2 4-D」に発表し,既に記事を書いているので,合わせて見てもらえればと!発表でも「勉強会参加レポート記事の大切さ」を説明している.勉強会に参加したらレポート記事を書こう!

kakakakakku.hatenablog.com

f:id:kakku22:20190706021402p:plain

Day.1 1-C : 「嫌われない」を諦めない @ykmc09

  • アジャイル推進組織の仕事領域
    • トレーニング
    • チームの支援
    • 社内アジャイルコミュニティの構築
  • 大切なのは「背中を押すこと」
    • リーンとアジャイルを好きになってもらいたい
  • 「勝手に広まっていきそうか?」が重要
  • 「マーケティングファネル」を参考に「Lean/Agile Promoting Funnel」を作った
  • 手段に固執せず,本質的な課題を探す
    • 「スクラムを導入するべき」とは絶対に言わない
  • 最初の成功にこだわる
  • Don't just Do Agile, Be Agile

DevLOVE X 最初のセッションは,前職でのチームメイトでもあった @ykmc09 の応援に行った.事前に発表資料の相互レビューをしていたため,プレゼンテーションを楽しめた.名言も多く出ていたけど,特に「最初の成功にこだわる」という話が良かった.「失敗から学ぶ」ことも重要だけど,それでも失敗より成功が良いし,最初の小さな成功が次の一歩に繋がる.そして「誰が言うか」という話もあり,今までは「信頼残高のある人が言うと良い」という前向きな理解をしていたけど,「あの人が言うから嫌い」という後ろ向きな側面もあることに気付き,これは個人的に盲点だった.何かを推進するときに気を付けたいと思う.

ykmc09.hateblo.jp

Day.1 3-B : エンジニア、エンジニアリングマネージャーとして成長するために必要なこととは? @tsuyok

  • 成長とは何か?
  • 個人の成長に対するアプローチはあまり情報がない
  • 「学び」のベース
    • コルブの経験学習モデル
  • 「エンジニア」の学び
    • 「学びの根源」が様々ある
    • 小さな行動を習慣化する
    • 自分自身を振り返る
      • KPT + 感じたこと
  • 「エンジニアリングマネージャ」の学び
    • オーセンティックでいる(自分らしさを貫くこと)
      • ジョハリの窓
    • アンラーニングする

僕自身とても興味のある「成長とは何か?」がテーマだったので参加してみた.「コルブの経験学習モデル」「ジョハリの窓」など,今まで学んできたことが多く出てきて,理解を整理することができた.「小さな行動を習慣化する」という話は重要だし,僕としては書籍「小さな習慣」をオススメしたい.また 1 on 1 活動に取り組まれているという話もあり,僕のブログメンタリングと似ている部分もあり,共感できた.

途中に「自分自身を毎週振り返っている人はいますか?」という話があり,僕は毎週日曜日の振り返りをもう4年以上続けているので,振り返りもオススメしたい.発表資料を見直して,もっと学んでみたいと思う.

www.tsuyok.work

Day.1 7-A : モブプロの聖地 Hunter Industries で学んだこと @kawaguti

大好きな書籍「Fearless Change」の翻訳者でもある @kawaguti さんが,実際に Hunter Industries に行かれた話をするということで,絶対に聞きに行こうと思っていた.特に「モブプログラミングは場所である」という話は刺さった.現場に行かれたからこそ気付けたことなのかもしれない.マシントラブルが起きたときに別の場所に行き,その場所にいるチームのタスクに着手したという話も「モブプログラミングは場所である」からこそだと思うし,噂は聞いたことがあったけど,本当だと知れて興奮した.また Enterprise Agile と Agile Enterprise の話なども興味があり,話を聞けて良かった.

kawaguti.hateblo.jp

Day.2 7-E : テスト駆動開発ライブ @t_wada

  • TDD
    • Red → Green → Refactor(を繰り返す)
  • FizzBuzz 問題
  • テスト → 仮実装 → 三角測量 → 実装

今まで @t_wada さんのライブコーディングを見る機会がなく,今回とても楽しみにしていた.内容としては FizzBuzz 問題をテスト駆動開発(実況解説付き)で進めていく.Eclipse を使って Java + JUnit で実装していくけど,ステップバイステップに進むし,ステップごとの実況解説で思考がうまく言語化されていて,わかりやすかった.何よりも,見ていてモチベーションが高まった.テストコードのメソッド名は日本語で書いて良いことや,テストを通すための return "1"; にも意味があることなど,実践的な学びもあった.前に Fukabori.fm で聞いた話を思い出したりもした.より良くするために,あえて1点フィードバックを送るなら,実況解説が早口過ぎて,聞き取れない部分も多かった.時間不足である制約は理解した上で,もう少し工夫できる余地もありそう.

fukabori.fm

Speaker Deck に発表資料がなく,Togetter を載せておく!

togetter.com

運営フィードバック

DevLOVE X 運営メンバーの皆さんがいたからこそ素晴らしいイベントになったと思う.本当にお疲れさまでした!今後のために個人的に感じた点をフィードバックしておこうと思う.参考まで!

  • (当日にページが分割されたけど)スピーカー一覧ページの表示が重すぎた
  • 有料イベントだし,スポンサーも入っていたので,一般参加者の皆さんにランチの提供かコーヒーの提供があると良かった
  • 計5部屋のサイズがバラバラで,特に人気のセッションだと座席数が不足していた

まとめ

  • 「DevLOVE X」に参加した
  • どのセッションもクオリティが高く,スピーカーの情熱を感じた
  • また今度 DevLOVE コミュニティに参加するぞー!

Packer 未経験者に最適な HashiCorp Learn の Packer コースを実施した

少し前に Consul を学ぶために活用した「HashiCorp Learn Platform」の学習コンテンツに最近「Vagrant / Packer」も追加されていた.今年3月末時点では「Vault / Consul / Terraform / Nomad」の4種類だったため,現在は6種類になっている.Packer は AMI (Amazon Machine Image) を作るときに使うこともあり,基本的な機能は理解しているけど,学習コンテンツに興味があり受講してみた.Consul の学習コンテンツとは異なり,Packer の学習コンテンツに動画はなく,ドキュメントベースになっていた.

Learn to build automated machine images with Packer : Getting Started

現時点だと「Learn to build automated machine images with Packer」「Getting Started」が公開されている.全6ステップから構成されていて,累計「46 min」と,コンパクトにまとまっている.内容的には Packer で AMI を作ったり,DigitalOcean と Vagrant のイメージを作ったりする.Packer 未経験者に最適な学習コンテンツだと思う.

  • Install Packer (5 min)
  • Build an Image (20 min)
  • Provision (5 min)
  • Parallel Builds (10 min)
  • Vagrant Boxes (4 min)
  • Next Steps (2 min)

learn.hashicorp.com

Install Packer

「Install Packer」ステップでは,Packer をインストールする.今回は Mac で動かすため,brew を使うことにした.

$ brew install packer
$ packer --version
1.4.1

OS ごとにバイナリも公開されている.

www.packer.io

Build an Image

「Build an Image」ステップでは,さっそく AMI を作るため,以下の example.json を用意する.今回は aws_access_keyaws_secret_key はテンプレートに含めず ~/.aws/credentials を参照するようにした.

{
  "builders": [
    {
      "type": "amazon-ebs",
      "region": "us-east-1",
      "source_ami_filter": {
        "filters": {
          "virtualization-type": "hvm",
          "name": "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*",
          "root-device-type": "ebs"
        },
        "owners": ["099720109477"],
        "most_recent": true
      },
      "instance_type": "t2.micro",
      "ssh_username": "ubuntu",
      "ami_name": "packer-example {{timestamp}}"
    }
  ]
}

次に packer validate でテンプレートを検証し,packer build でビルドをすると,すぐに AMI を作れる.

$ packer validate example.json
Template validated successfully.

$ packer build example.json
amazon-ebs output will be in this color.
(中略)
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-east-1: ami-xxxxxxxxxxxxxxx

詳細は以下の公式ドキュメントに載っている.

packer.io

次に「File Provisioner」「Shell Provisioner」を組み合わせてプロビジョニングを試す.

まず,以下の firstrun.json を用意する.テンプレートに provisioners を追加することにより,welcome.txt を作成したり,example.sh を実行したりしている.builders の部分は既に用意した example.json とほぼ同じ設定になっている.

{
  "builders": [
    (中略)
  ],
  "provisioners": [
    {
      "type": "file",
      "source": "./welcome.txt",
      "destination": "/home/ubuntu/"
    },
    {
      "type": "shell",
      "inline": ["ls -al /home/ubuntu", "cat /home/ubuntu/welcome.txt"]
    },
    {
      "type": "shell",
      "script": "./example.sh"
    }
  ]
}

同様に packer validatepacker build で AMI を作ると,以下のように provisioners の処理が進んでいる.

$ packer validate firstrun.json
Template validated successfully.

$ packer build firstrun.json
amazon-ebs output will be in this color.
(中略)
==> amazon-ebs: Waiting for SSH to become available...
==> amazon-ebs: Connected to SSH!
==> amazon-ebs: Uploading ./welcome.txt => /home/ubuntu/
welcome.txt 19 B / 19 B [=======================================================================================================================================================================================================] 100.00% 1s
(中略)
==> amazon-ebs: Provisioning with shell script: ./example.sh
    amazon-ebs: hello
(中略)
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-east-1: ami-xxxxxxxxxxxxxxx

最後は Windows AMI を作る内容になっているけど,今回は実施しなかった.

他にも AMI を指定するときに source_ami ではなく source_ami_filter を使う理由だったり,provisioners ではなく user_data_file を使うこともできたり,実際に Packer を使うときに知っておくべき内容も記載されていて良かった.

packer.io

packer.io

Provision

「Provision」ステップでは,「Shell Provisioner」を使って Redis をインストールする.今回は example.json に以下の provisioners を追加する.意図的に sleep を追加している理由は「正常に OS が初期化されるまで待つ」と書いてあった.

{
  "builders": [
    (中略)
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "sleep 30",
        "sudo apt-get update",
        "sudo apt-get install -y redis-server"
      ]
    }
  ]
}

同様に packer validatepacker build で AMI を作る.

$ packer validate example.json
Template validated successfully.

$ packer build example.json
amazon-ebs output will be in this color.
(中略)
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-east-1: ami-xxxxxxxxxxxxxxx

実際に AMI から Amazon EC2 を起動すると,Redis がインストールされていた.

$ dpkg -l | grep -i redis
ii  redis-server                     2:3.0.6-1ubuntu0.3                         amd64        Persistent key-value database with network interface
ii  redis-tools                      2:3.0.6-1ubuntu0.3                         amd64        Persistent key-value database with network interface (client)

Parallel Builds

「Parallel Builds」ステップでは,「AMI Builder」「DigitalOcean Builder」を使って,マルチプラットフォームを実現する.DigitalOcean のアカウントを持ってなく,今回は実施しなかったけど,以下のように builders に複数の type を並べると自動的にビルドされる.

{
  "builders": [
    {
      "type": "amazon-ebs",
      "region": "us-east-1",
      "source_ami": "ami-fce3c696",
      "instance_type": "t2.micro",
      "ssh_username": "ubuntu",
      "ami_name": "packer-example {{timestamp}}"
    },
    {
      "type": "digitalocean",
      "api_token": "{{user `do_api_token`}}",
      "image": "ubuntu-14-04-x64",
      "region": "nyc3",
      "size": "512mb",
      "ssh_username": "root"
    }
  ],
  "provisioners": [
    (中略)
  ]
}

Packer の良さは Builder に指定できる種類の多さにあり,「DigitalOcean Builder」以外に「Docker Builder」などもある.

packer.io

packer.io

Vagrant Boxes

「Vagrant Boxes」ステップでは,Post-Processors の機能を使って,ビルドされたイメージを圧縮したり,アーティファクトとしてアップロードできることを学ぶ.今回は Vagrant 用の .box ファイルを作るため,テンプレートに post-processors を追加する.

{
  "builders": [
    (中略)
  ],
  "provisioners": [
    (中略)
  ]
  "post-processors": [
    "vagrant"
  ]
}

同様に packer validatepacker build で AMI を作ると,実際に packer_amazon-ebs_aws.box も一緒に作られていた.

$ packer validate example.json
Template validated successfully.

$ packer build example.json
amazon-ebs output will be in this color.
(中略)
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-east-1: ami-xxxxxxxxxxxxxxx

--> amazon-ebs: 'aws' provider box: packer_amazon-ebs_aws.box

packer.io

Next Steps

「Next Steps」ステップでは,公式ドキュメントや GitHub や Google Group の紹介となっている.

packer.io

github.com

まとめ

  • 「HashiCorp Learn Platform」の学習コンテンツに「Vagrant」「Packer」が追加されていた
  • 「Learn to build automated machine images with Packer」「Getting Started」を実施した
  • Packer を使って AMI を作れるため,Packer 未経験者に最適な学習コンテンツだと思う

HashiCorp Learn 関連

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

技術ブロガーを育てる!ブログメンタリングで何を教えているのか

週末に開催された「DevLOVE X」に参加し,2日目に発表をしてきた!今回の発表タイトルは「技術ブロガーを育てる!ブログメンタリングで何を教えているのか」で,今まで約1年半続けている「ブログメンタリング」の事例紹介をテーマにした.さらに関連する話題として,「アウトプットの再定義」「ブログを書く理由(モチベーション)」「メンタリングの技術」も話した.発表資料をフォローアップする.

devlove.wixsite.com

発表資料

speakerdeck.com

Public URL-ize

アウトプットの重要性はもう聞き飽きるほど聞いていると思うし,今回の DevLOVE X でも何度も話題に上がっていたけど,僕の発表では,改めてアウトプットを再定義し,うまく言語化したいと考えていた.結果として「Public URL-ize」という言葉にした.意図としては,発表資料にも記載した通り,「URL で誰でもアクセスできて,検索可能な情報を作り出すこと」を意識することにより,多くの人に見てもらえる可能性があるし,フィードバックをもらえる可能性もある.「公開された履歴書」と表現することもできる.

f:id:kakku22:20190623093442p:plain

なぜブログを書くのか?

ブログの習慣化に悩んでいる人と話すと,様々な「書くことを諦める理由」を聞く.例えば「二番煎じだから」とか「誰でも知ってることだから」という理由をよく聞く.もし本当に似た内容の記事が既にあるとしても,自分自身に新しい学びがあったのであれば「自分の学習メモ(学習履歴)」として書き残しておくことに価値はある.最初から「誰かの役に立ちたい」なんて考えなくて良いと思う.「ブログを書く理由(モチベーション)」は段階的なので,まずは「自分のために書く」ことを意識すると続けやすくなると思う.

f:id:kakku22:20190623093509p:plain

なぜブログメンタリングを始めたのか?

アウトプットをしたり,ブログを書くことに価値があることは理解しつつも,実際に習慣化しようとすると挫折してしまう人は多い.そんな状況をどのように打破できるかを考えた結果,もしかしたら「習慣化できた!」という小さな成功体験を感じてもらうことに価値があるのでは?と考えた.そこで,ブログのパーソナルメンターになるべく,約1年半前に「ブログメンタリング」をはじめた.今では「ブログのライザップ」と言われることも増えている.

f:id:kakku22:20190623231502p:plain

過去に発表をした「ブログを書く技術」「習慣化する技術」も,伝えていることは何も変わってなく,参考にしてもらえればと思う.

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

メンタリング技術

後半は「ブログメンタリング」の事例をベースに,よく知られた「メンタリングの技術」に対する僕のスタイルを紹介した.発表資料の下側に青枠で囲っている部分はメンタリングの技術をできる限り抽象化して言語化している.

f:id:kakku22:20190623204804p:plain

僕自身,多くのメンタリング経験があるわけではなく,数年間担当していた「Engineering Manager の経験(1 on 1 など)」「プログラミング講師の経験(マンツーマン)」をベースにしている.さらに2017年に書評を書いた「コーチングの基本」から学んだ内容も自分なりに応用している.例えば「傾聴」「他責/自責」「アクノレッジメント」など.また発表資料にも載せている通り,最近では「エンジニアリング組織論への招待」にも「メンタリングの技術」が詳しく載っている.

kakakakakku.hatenablog.com

発表中

DevLOVE だ!と感じられるポジティブな雰囲気の中で発表できた.冒頭に「笑って OK 😃」という話もしたため,楽しく聞いて頂けたように思う.締めは鬼スベリも覚悟しネタに挑戦した!多くの実況ツイートもして頂き,Togetter を見たら非常に盛り上がっていた!また最前列に座られていた id:yoshidashingo に褒めて頂き,とても嬉しい!

togetter.com

まとめ

「DevLOVE X」に参加し「技術ブロガーを育てる!ブログメンタリングで何を教えているのか」というタイトルで発表をしてきた.「ブログメンタリング」の事例紹介は今までしたことがなく,今回はじめて公開した情報も多くある.ブログの習慣化に悩んでいる人の助けになれば嬉しいし,もし興味があればブログメンティに応募頂ければと思う.

そして今回は友人たちに発表資料の事前レビューをしてもらったことによりクオリティを高めることができた.本当に感謝!特に id:ykmc とはカフェで打ち合わせをして,ストーリー展開の客観的なフィードバックをもらえて助かった.さらに今回 DevLOVE X という最高のイベントで発表をする機会を頂けた id:HirokiHachisuka に本当に感謝!

おまけ : MigMix 1P

最後に発表資料に使ったフォントを紹介しようと思う.直近2年間は「コーポレート・ロゴ」をずっと使っていた.パッと見たときに惹かれるインパクトがあり,今でも個人的によく使っているけど,今回はフォントを変えてみることにした.様々なフォントを検討した結果「MigMix 1P」にした.丸さのある美しいフォントですごく気に入っている.

発表資料は Keynote を愛用している.「Keynote ベストプラクティス」は以前に公開した記事を見てもらうと良さそう.

kakakakakku.hatenablog.com