くろもワークス

しがないWebエンジニアの日記です。

PHPerKaigi 2020の参加メモ #phperkaigi

去年に引き続き、PHPerKaigi 2020 に2/11に参加してきました。
この後くらいから例のコロナウイルスでいろいろな勉強会が中止になっていたので、今思うとギリギリでした。 f:id:kuromoka16:20200227045606j:plain

簡単なまとめ

去年もノベルティはたくさんもらったのですが、今年面白かったのは↓のようなカードをもらったことです。 f:id:kuromoka16:20200227050503j:plain

カードをもらえることは自体は知っていたのですが数枚程度と思ってたので、当日少し戸惑ってましたｗ
だいぶ交換させて頂いたのですがまだ半分以上はあるので、他の勉強会で自己紹介代わりに撒いていきたいなーと思っています。

懇親会は相変わらず超豪華でした！
特にビールは普段ほとんど飲まないのですが、PHPerKaigiのビールはクオリティ高いので今年も何種類か頂きました。（余ったビールは持ち帰りできたので、家で開けようとしたら栓の開け方に苦戦…） f:id:kuromoka16:20200227051400j:plain

またさっきのカードのおかげで懇親会で話すきっかけを作れるという効果もあったので、その点でも良かったですね。

聞いたセッションのメモ

マスタデータの管理と運用について

https://www.slideshare.net/KentarouTakeda/ss-227566415

  • マスターデータはフロントとバックエンドで使う
  • DB管理は管理画面いる
  • エンジニアでなくても更新できたり管理画面とかがいらないとかの条件を満たした管理方法
    • Excel😂
    • まあそうなるよね、って感じだった
  • PHPだと「PhpSpreadsheet」というパッケージでExcelを扱える
  • Excel→JSON→PHP化して、最後のPHP化したマスタデータをアプリケーションから使うらしい
    • JSONだとパースがいるので少し遅い
    • PHP化することでテストコードが書けるので、無効なデータは弾く
    • マスタデータのPHPをautoloadにして、どこからも使えるようにする
  • パフォーマンス
    • OPcacheによって最初は重いが、次は早くなる
    • PHP7.4のpreloadでキャッシュに乗せる

PHPerがこれから「型」とお付き合いしていくために

https://speakerdeck.com/penguin045/phpergakorekara-xing-toofu-kihe-isiteikutameni

  • 前半は型付け言語そのものみたいな話
  • PHPの型
    • 弱い型付けの動的型付け言語
    • 最近は型に関する改修多い
  • 型宣言が性能を上げる
    • PHP8のJITで型宣言の情報を使う
    • タイプヒンティングをすると性能が悪いのは過去の話
  • ケースごとの例
    • ケース1
      • 既存システムの開発者
      • 動的型付け言語として開発されていた
      • レガシーシステムかもしれない
      • 開発環境はPHPStorm
      • 既存システムに型宣言を書くのは難しいので、PHPDocを書いてIDE側の恩恵を受けれるようにしていく
    • ケース2
    • ケース3
    • 既存システム
    • 型は意識していない
    • 型宣言されたライブラリを使うことになった
    • ケースバイケース

PHPでPHPを実装する 〜プログラミング言語実装入門〜

https://speakerdeck.com/tzmfreedom/phpdephpwoshi-zhuang-suru-puroguraminguyan-yu-shi-zhuang-ru-men

ぼっちからはじめるレガシーカルチャー改善ガイド 〜はじめの一歩編〜

https://speakerdeck.com/blue_goheimochi/phperkaigi2020

  • 2013/5にオウケイウェイヴに入社。PHP4とPHP5が共存していた
    • こういう話が出るたびに、闇深そうだけどPHP4のプロダクション環境を一度触ってみたいなーと思う！
  • 去年Laravelにリプレースした
  • はじめの一歩の期間
    • 自己研鑽
      • 本を読む
      • ブロク記事を読む
      • ギャップをしる
      • アウトプットして知識として定着させる
        • プロダクトに影響ないところからやっていく
    • 信頼貯金
      • 目の前にあるタスクをやりとげる
      • プラスアルファとなる工夫を加える
      • 目線や視座をあげる
    • 1人目の改善仲間をみつける -　なにか改善したいとおもったときに賛同者がいる状態
    • 仲間を見つけられたきっかけ
      • 自分の興味を伝えるコミュニケーションをする
  • そこから次の一歩
    • 次のゴール
      • 3人目の改善仲間をみつける
        • ランチにさそう
        • 勉強会に誘う
        • 社内に向けたアウトプットをする
  • レガシーな文化の改善には時間がかかる
    • できることを積み上げる
    • 同じ志の仲間を見つける

今だからこそ振り返る register_globals

https://speakerdeck.com/gongo/phperkaigi-2020

GitHub Actionsで始めるPHPアプリケーションのCI実践入門

https://speakerdeck.com/fortkle/ga-phperkaigi2020

  • Github Actions
    • 設定ファイルはyaml
      • CircleCIとパット見、かなり似てそう
    • publicリポジトリは無料
    • Github上のあらゆるイベントをトリガーにできる
  • ワークフロー
    • runs-onでubuntuとか指定できる
    • runでコマンドの実行
  • アクション
  • 現実的な使い方できる
  • 各種ツール
    • PHPUnit, phpstan, phpcs
    • composer installしてコマンド実行
  • Github ActionsでPHPアプリをCIするのは、十分現実的な選択肢になっている

SRE NEXT 2020の参加メモ #srenext

イベント参加

遅くなりましたが、1/25にSRE NEXT 2020というイベントに参加をしてきました。

f:id:kuromoka16:20200129040855j:plain

そもそも最近までは「SRE」という言葉自体あまりよく知らなかったのですが、ここ最近この分野の個人的な関心が高まっていることもあり参加してみました。

簡単なまとめ

同時進行のセッションがあったので全部聞けたわけではないのですが、大まかには次のような話が多かったです。

  • SREの概念的な話
  • SREを実践した技術的な話
  • SREの組織的な話

またどのセッションでもしきりに「SLI / SLO」というワードがよく出てきて、決めた指標を元に各社いろいろなSREの取り組みをしているんだなーという印象でした。

懇親会も参加したのですが、話をした限りではSREという組織やチームの中で働いている人は意外と少なく、自分と同じようなバックエンドエンジニアやインフラエンジニアの方が多かったです。

聞いたセッションのメモ

分散アプリケーションの信頼性観測技術に関する研究

https://speakerdeck.com/yuukit/a-study-of-sre

  • さくらインターネットで研究をされている方の発表
  • SREとはなにか
    • 失敗を前提として信頼性を制御する工夫
    • 信頼性低下のリスクを減らすことで変更速度を上げる
  • 失敗のリスクをへらす工夫
    • 事前予測
      • キャパシティプランニング
      • サブシステムの依存関係の把握
    • 事後の最小化
      • 自動回復（フェイルオーバー）
      • アラート
      • 因果関係の特定
      • インシデントの対応体制
      • 高度なデプロイメント
  • 地理的に分散したアプリケーションの信頼性向上というテーマでの研究
    • 既存アプリケーションへの影響を与えないようにする
    • 目的
      • 時間軸方向での可観測性
      • 空間軸方向での可観測性
      • データの一貫性を保証
    • 具体的な研究内容については、レイヤーが低めの話もあり自分には少し難しかった

絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長

https://speakerdeck.com/tjun/sre-next-2020

  • メルカリとメルペイそれぞれで、SRE組織をどうやって作ってきたか
  • メルカリ
    • マイクロサービス化を進めている
    • chocon
    • 半分近い開発チームはマイクロサービスの開発に関わっていて、SREとしてもその状況を後押ししたい
    • これまでは本番環境を支える「門番」として信頼性向上に関わってきた
      • 今後のマイクロサービス化に伴い、SREチームがボトルネックになるかもという懸念
      • マイクロサービスの開発チームに対応していきたい
    • 専門性の異なる3つのサブチームに分けた
      • SRE Core
      • SRE Edge
      • SRE Advocacy
        • マイクロサービス開発の一員
  • メルペイ
    • @tjunさんが、2018年に1人目のSREとして入社してから現在までの話
    • 2019年の2月にメルペイがリリースされるまでは、なかなかチームとしては動けなかったようで結構苦労してそう
    • 現在
      • エンジニア組織の生産性や運用負荷を改善したい
      • サービスの信頼性を高める
      • 自分ではなくメンバーにできるだけ任せる
    • 組織やチームの段階によってリーダのやるべきことは変わる
    • 最終的にSREチームを超えて、エンジニア組織の生産性と信頼性を作っていく

計画的に負荷リスクを排除するためのキャパシティプランニング

https://speakerdeck.com/sekino/ji-hua-de-nifu-he-risukuwopai-chu-surutamefalsekiyapasiteipuranningu

  • タップルSREの話
  • 全体的に少し駆け足感はあったので、20分ではなくもう少し長い時間でも聞いてみたい
  • 負荷的な観点でセキュアベースになるための取り組みについて
  • 取り組むことになったきっかけ
    • イベント開始のpush通知をきっかけに大量アクセスが発生
    • サービスの復旧に時間がかかった
  • キャパシティプランニングのゴール
    • 継続的なシステムキャパシティの把握
    • 負荷レビューの手順と実施フローの整備
  • 継続的なシステムキャパシティの把握
    • 定期的な負荷試験環境を構築
      • 本番と同様の試験環境
      • AWSアカウントだけ分けて、スペックとか構成は同じにしているっぽい
      • 誰でも使えるようにスクリプトや手順書を作った
    • 負荷試験の実施フローの整備
      • 定期実施
        • 限界値を把握するためのロードテスト
        • 限界値を把握するためのスパイクテスト
          • 固定したECSタスクにスパイクアクセス
            • オートスケールの設定がスパイクアクセスを想定していない設定のため
        • エンジニア主導での実施
          • 性能劣化をチェックするテスト
    • レイテンシSLOを定める
      • ビジネスサイドとの連携にも使用したい
      • APIが遅い環境を用意し、各リーダやPMに集まってもらって「API遅延体感チェック会」を実施
        • こういうのいいなーと思った（小並感）
      • チェック会を元に具体的なSLOを決定
  • 負荷レビューの手順と実施フローの整備
    • 施策単位でのレビューフロー
      • 施策の一覧をSREが負荷的に問題ないかをチェック
        • 施策段階では具体的な情報が少ないので、経験則や体感的なものによる
      • 担当エンジニアによる負荷レビュー
        • 施策の担当エンジニアが実施
        • 手順
          • レビューに必要な情報をプランナーに聞く
            • 施策の概要
            • 施策の想定効果
          • 担当エンジニアが増加するアクセス数の想定を出す
          • 負荷試験結果と付き合わせる
            • ここで定期的な実施が聞いてくるのかなーと思う
        • すべての施策で負荷レビューするのはコストがかかるので特定の施策のみ
    • push通知の設定レビュー
      • サービスをスローダウンさせないように配信するため
      • SREが配信設定をレビュー
      • 手順
        • レビューに必要な情報をもらう
          • 配信ユーザ数
          • 配信時間帯
          • 流入の期待値
        • 想定流入数を出す
        • 想定流入数から必要なスループットを出す
          • 最初のフリックの操作をほとんどのユーザが行うので、このエンドポイント単位
        • スパイクテストの結果を元に配信スケジュールを決定
          • 必要なECSのタスク数
          • 限界スループットを超えている場合はpushを分割
          • ECSにスケジュールベースのオートスケールの設定
  • これらを行ってきた結果
    • push通知や施策のリリースでSLOに違反するようなスローダウンが減った
    • エンジニア主導での気軽な負荷試験の実施

freee のエンジニアは障害から何を学び、どう改善しているのか？

https://speakerdeck.com/manabusakai/what-do-freee-engineers-learn-and-improve-from-failures

  • 障害対応に課題を感じている人が改善のための第一歩を踏み出せそうと思えるようになること
  • freeeの特徴
    • お金や人に関する情報が多い
    • 上場をした
  • 障害へのシビアな対応が求められる
  • ただし新しい価値を生み出す上で障害は避けられないもの
  • 障害にどう立ち向かってきたか
    • 2017年ごろまではフォーマットもバラバラで障害対策の学びも属人化していた
    • 2018年に「SOC1」取得に向けた準備の一貫で、障害対応フローが作成
    • 障害の影響度に応じてレベルを定義 -障害判断のブレがなくなった
    • 2018/10/31の障害
    • この障害をもとに対応を改善
      • 対応の明瞭化
        • 「SOC1」取得に向けて整備した障害対応フローをブラッシュアップ
        • 障害発生時の対応について、「すべて」をまとめたドキュメントを用意
          • 初動対応
          • 障害対応における役割
            • 指揮を取る人や意思決定者は手を動かさない
          • 社内外のコミュニケーション
      • 障害対応エリアを設置
        • ディスプレイがある物理的なスペースを用意
        • 情報を集約して作業のお見合いなどを防ぐ
      • 初動の省略化
        • Slackのbotで障害対応のドキュメントが出るように
        • ポストモーテムの自動作成
        • GASでの社内に連絡すべき人への告知の自動化
  • 障害の学びを広める
    • freeeの開発文化には失敗から学ぶ文化が根付いていた
    • 失敗.js
      • 障害の学びを開発組織全体に共有する場
      • 犯人探しや責任追及の場ではない
      • 障害がなかった月は寿司
    • 割れ窓を改善し隊
    • alertを振り返り隊
      • 直近1週間のalertを振り返りノウハウを共有
      • 障害対応の属人化を防ぐ

SLO Review

https://speakerdeck.com/chaspy/slo-review

  • SLI / SLOを定めることは重要
  • ただし最初は完璧ではない
  • Quipperでのケーススタディ
    • Define the Ownership
      • 日本と海外にチームがあり、それぞれのチームでオーナを決める
    • SLO review by myself
    • SLO review with Devs
      • Dos Detector
        • Dos攻撃対策として503エラーを返していた
        • 設定しているSLIに5xxが含まれているため、攻撃されるとするとすぐに違反になってしまう
        • 代わりに429を返すようにした
      • パスが分からないので送るようにした
      • Envoyでのマイクロサービス間のメトリクスを取得（たしか）
    • Set Error Budget Policy
      • まだ
  • こんなSLIを定めたほうがいいというデフォルトセットを用意しておく
  • SLIの設定はコード化しておく
    • 開発者が簡単に変えられるようにするため

急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

https://speakerdeck.com/kaneshin/how-to-keep-growing-sre-team-at-eureka

Designing fault-tolerant microservices with SRE and circuit breaker centric architecture

https://speakerdeck.com/takanabe/sre-next-2020-c6-designing-fault-tolerant-microservices-with-sre-and-circuit-breaker-centric-architecture

  • Cookpadのグローバルチームでの話
  • Cookpadのレシピ検索の改善として、「Serch v2」と「ML API」を開発
    • この開発チームを「Serch / MLチーム」として、SREとしてどのように改善したのかといった構成の話
  • 最初はMLの研究者と開発者とバックエンドエンジニアがコラボして作業をしていた
    • うまくいかず…
    • 理想と現実のギャップ
      • 技術
        • 新しいプロダクトはpythonやk8sを使う予定でいた
        • チームごとに使う技術がバラバラになってしまうのはよくないと考えている
        • ただ機械学習はpythonを柄う
      • サービスレベル
        • 実験的な内容をプロダクトに入れたことによるエラーの発生
      • オンボーディングなしで簡単なプロセスで、リリースをできるようにしたい
  • 解決するためのSREチームの具体的な取り組み
  • すべての課題に対してDesign Docsを書く
  • Serch / MLチームの技術選択
    • AWSアカウントやリソースを分けて、本体側に影響出ないようにしてチーム内で自走するようにする
  • 本体側が停止しないようなマイクロサービスの導入
    • サーキットブレーカーを導入
      • サービスが不安定なときにすぐに本体側と切り離せる仕組み
      • 設定したしきい値を超えたとき、マイクロサーヒスへのリクエストを遮断（503を返す）
      • ヘルスチェックの結果をもとに元に戻す
    • TraefikというGo製のツールを使っている
    • サーキットブレーカーのしきい値をどうやって決める？
      • SLOをもとにする
      • なにをSLOにするかは難しいのである程度のプリセットを用意しているらしい
    • しきい値を超えたらサーキットブレーカーによって、リクエストが遮断されるコンセンサスをチームと取る
  • オンコールからの開放
    • サーキットブレーカーで切断したあとに自動的に古いプロダクトに戻すことで、手動での対応を不要にしているっぽい
  • 実験的な内容のリリース
    • リクエストパスごとに、新旧のプロダクトを切り替える

サイト信頼性エンジニアリングの原則

  • SREの何たるが全然分かってない自分にとっては、エラーバジェットなどの説明や具体例も一緒に話してくれたのは非常に分かりやすかったです。
  • スライドは公開されてないですが、登壇した@ymotongpooさんのブログ記事があったので、こちらをメモ代わりに貼っておきます。

ymotongpoo.hatenablog.com

Webサービスを1日10回デプロイするための取り組み

https://speakerdeck.com/fujiwara3/sre-next-2020

  • 内容はタイトルの通り
    • こういう闇を改善していく話は聞いてて面白い
  • Lobiのサービスでの取り組み
  • 1日10回デプロイしたい
    • 以下すべてをデプロイと定義
      • サーバサイド
      • フロントエンド
      • EC2のプロビジョニング（Chef）
      • AWSの構成変更（Terraform）
    • 修正や機能追加や削除はすぐにデプロイしたい
    • 常にデプロイしていればデプロイが怖くなくなる
  • 1日に何時間使えるか
    • 営業時間内（9時間）
    • 営業時間外や休日の前の午後は基本的にデプロイしないようにしている
      • 夜のピークタイムに問題が発生
      • 夜間バッチで問題が発生
      • ユーザからの問い合わせが休日に増える
  • 7時間で10回デプロイするには
    • 1回のデプロイに使える時間は30分以下
    • 1回1回のデプロイの高速化
    • 専任の担当者を作らずだれでもデプロイできるようにする
    • いつなにがデプロイされたかを記録する
  • 以下のデプロイの要素を早くする
    • CI
      • テストが通ってないものはリリースできない
    • ビルド / 配付
    • エラー検知
    • ロールバック
  • CI高速化
    • 本体APIはPerlでのモノリスなアプリ
    • アプリケーション26万行 + テスト26万行
    • 実際にMySQLやRedisを起動してテストをしている
    • 何も考えずにテストを実行すると日が暮れるとか…
    • 並列化を行い10分で終わるようにした
      • 10分だとpushをしても他の人のテスト待ちで10分以上掛かる
      • ローカルで修正箇所だけテストをするようにしたりしたが、pushして全部をテストするとこけたりしていた
      • 緊急対応時にもどかしい
    • Jenkins → Circle CIにして、コンテナの並列化をした
      • 10分から3分になった
      • PRを作ってから説明を書いているうちに、CIが終わるようになった
    • Circle CIのイメージはus-east-1に置くようにして、Circle CIの実行環境と物理的に近くなるようにするとよい
  • ファイル配付の高速化
    • 2010年〜
      • EC2のデプロイサーバから各ホストでgit pull
    • 2013年〜
      • デプロイサーバから各ホストにrsync
      • 10並列でrsyncしても終わるまで3-4分
      • この方法だとオートスケールへの対応がやりにくい
    • Stretcherを開発
      • https://github.com/fujiwara/stretcher
      • デプロイの配布物をS3に置くようにして、各ホストでStretcherコマンドでS3から取得して展開するようにした
      • オートスケールで起動したホストもS3から取得して展開
    • rsyncの3-4分から、1分程度に短縮
  • エラー検知
    • デプロイはエラーがないことを確認してからでないと完了にならない
    • ログから問題を検出する仕組み
    • NorikraでログにSQLクエリを投げれるようにした
    • ログ検知を適切なwindowsで実行する
      • エラーが大量発生しても1分に1回だけ通知する（通知が膨大に来ないようにするため）
  • ロールバック
    • デプロイして問題が発生したらすぐに戻したい
    • いままでのフロー
      • リバートのPR作成、レビュー
        • 間違ったコミットをリバートしていないか
      • リリースブランチにマージ
        • CIの待ち
      • デプロイしなおし
    • どう急いでも5分以上かかっていた
    • Stretcherでロールバック
      • デプロイ前の直前の成果物がS3に残っている
      • 直前のURLを指定すればロールバック完了
    • 30秒でロールバックが完了するようになり、人間が介入しないのでミスしないようになった
  • 誰でもデプロイできる仕組み
    • これまでは特定の担当者がデプロイをしていたが、コードを書いた人がデプロイできるようにする
    • Rundeckを使った
    • デプロイ履歴の管理にghch
    • Slackbotによるデプロイの管理
      • テストが通ってなかったり時間外のデプロイを行おとすると警告する
  • コンテナ移行後のデプロイ

VS Code Meetup #1 で登壇してきた #vscodejp

イベント参加

この記事は「Visual Studio Code Advent Calendar 2019」の19日目の記事です。

12/18に以下のイベントでLTをしてきました。

vscode.connpass.com

スライドはこちらです。

発表内容について

「初回基礎編」というサブタイトルだったので、「2年半VSCodeを使ってきて意外と知らなかったこと」という題目で、あまり難しくない基礎的な内容にしました。
自分がVSCodeを2年半使ってきて「え、こんな機能あるの？」と思うことがたびたびあり、そういう機能を紹介するような内容です。具体的には以下の機能について紹介しました。

ワークスペース

ワークスペースを使うとフォルダを2個同時に開くことができます。これを知るまでVSCodeも2個開いてたという話をしたら、結構同じ方がいるようで安心しました！

詳細検索

検索パネルの右下にある「…」みたいなボタンを押すか、フォルダー内検索をしたときに有効化になる機能です。
通常の検索では全体を検索しますが、詳細検索では検索対象に含めたり除外したり*1するファイルやフォルダを指定することができます。

Git機能

左バーの分岐マーク（でいいのかな？）を押すとソース管理のパネルが開き、コミットや変更を戻すなどの操作ができます。ブランチの作成や切り替えなどは左下のブランチ名を押すとメニューが出てくるので、そこからできます。

タスク

任意のコマンドをタスクとして登録しておくと、VSCodeからそのタスクを指定して実行できるような仕組みです。作り方はスライドに書いてあるのでご参照頂ければと思います🙏
当日は@sakkuruさんが、LT前のセッションでタスク機能の説明やデモまでしてくれたので、発表ではあまり細かくは触れませんでした。

その他もろろろ

と称して、ペラ1のスライドで以下の3つの機能を紹介しました。

選択範囲のみ検索

ファイル内を「command+F」で検索するときに、デフォルトだと選択範囲がある状態でもファイル全体が有効になってしまいます。
右の方にある棒グラフみたいな謎ボタンを押しておくと、選択範囲のみを対象にして検索することができます。

マルチカーソル

「option+クリック」をするとカーソルを増殖させることができます。複数行や複数箇所を同時編集したいときに便利です。
ただ実はこれは一例で、マルチカーソル機能は結構奥深く私もまだまだ使いこなせてはいません。以下の記事がとても詳しく説明されていておすすめなので、ぜひ見てみてください！

mugi1.hateblo.jp

Compact folders

これは機能というよりまあ設定なんですが、最新の1.4.1のバージョンで新しく入った設定です*2。
デフォルトが有効なので気づいている方も多いと思いますが、子供のフォルダが1個しかないときの表示が変化します。

反響

まず反響がとても多く正直驚きました。LT直前にスライドをツイートしたのですが、拡散していただきありがとうございます！

はてブのホットエントリーにもなって、一時的に「テクノロジー」カテゴリの一番上にも掲載されたのでキャプチャを残しておきました。

f:id:kuromoka16:20191219193333p:plain

そんな中で良い反応もあったのですが、「内容が薄い」って反応もチラホラあり、これについては完全同意で反省点かなーと思っています😢
5分間のLTという時間の中で、多くの機能を紹介しようとしたので個々のスライドでの説明が薄くなってしまったかな、と感じています。逆に言うと今までの登壇活動ではこういう指摘をもらうほどの反響がなかったので、今後の登壇を改善していくための良い機会と捉えていきたいと思っています！

全体的な感想

まずVSCodeは自分がとても好きなエディタで、そういったVSCodeに関する勉強会の1回目に参加して登壇できたことはとても光栄でした！今後2回目、3回目と続いていくとのことなのでとても楽しみです。
LTの登壇者にはイケてるバッチをもらえたのもよかったです！

今回は「初回基礎編」 で、次回は「Live Share編」とのことで*3、全然使ったことない機能なので登壇はお休みして、一般参加として参加できたら勉強をしにいく心構えで行くつもりです。もしまた登壇する機会があったらぜひ登壇したいなーと思います！

*1:スライドでは除外のことしか書いてないのに、例は含めるの方を紹介するようなキャプチャになっていますね、すいません！

*2:https://code.visualstudio.com/updates/v1_41#_compact-folders-in-explorer

*3:https://vscode.connpass.com/event/160083/

Vuetify StoreからVuetifyグッズを買ってみた

Vuetify Storeは、Vue.jsのUIフレームワークの一つであるVuetifyが開いているショップです。ショップ自体はShopifyというサービスで作られているみたいです。

store.vuetifyjs.com

Vuetify用の有料テーマなどもここで売られていますが、帽子やTシャツなどのVuetifyグッズも売られています。

Vuetify好きとして、またOSSで開発されているVuetifyがさらに発展してほしいという意味も込めて今回グッズを買ってみました。

購入方法

Vuetify Storeのページから、欲しい商品を選んで「Add To Cart」でカートに入れていきます。

TOPページに薄い字で書かれているんですが、合計が$85以上の場合は送料無料になるのでまとめて買ったほうが絶対お得です！

f:id:kuromoka16:20191025005227p:plain

それ以下で注文した場合、アメリカからの発送のため日本への配達にしようとすると結構えぐい送料になります😇

f:id:kuromoka16:20191025010927j:plain

$85以上になるようにして、最終的には以下の商品を注文しました。ステッカーのほうはサービスで1個無料になりました。

f:id:kuromoka16:20191025010839j:plain

商品を選んだらページ上部のカートのアイコンから「CHECKOUT」を押すと、メールアドレスや配達先を入力する画面になります。*1

f:id:kuromoka16:20191025011933p:plain

入力後に「Continue to shipping」で先に進むと、計算された送料が表示されます。$85以上注文してた場合は「Free」になっているはずです。

配達までの日数

アメリカのテキサス州から、USPSでの発送でした。

9/23にVuetify Storeから注文→9/25に発送→通関手続きなどを経て10/7に一度配達されました。ただこのときは不在で取れなかったので、10/9に再配達で受け取りました。そのため日本への配達は概ね2週間くらいと思ったほうがよさそうです。

届いたグッズの紹介

ステッカー

Vuetify Dark StickersとVuetify Light Stickersです。<v-developer/> ロゴがVuetifyでコンポーネントを書くときと同じ感じになっているのがイケてますね。

f:id:kuromoka16:20191025015140j:plain

帽子

White Vuetify Capです。被ってたら一発でVuetify使ってると認識できます。

f:id:kuromoka16:20191025015541j:plain

Tシャツ

Special Edition Vuetify Teeです。真ん中にでっかくVuetifyロゴが入ってます。

サイズは少し大きかったです。いつも日本で服を買うときはXLを買うことが多いので同じサイズを買ったのですが、あくまでアメリカ基準でのXLのようなので1段階下げるくらいがちょうどいいかもしれません。

また商品ページに、よくあるXLはこれくらいのサイズだよ的なのは載っていますが、アメリカらしくセンチではなくインチ表記なので注意が必要です。

f:id:kuromoka16:20191025020230j:plain

ジャケット

Full-Zip Vuetify Jacketです。こちらは控えめに左胸のところに小さくVuetifyロゴが入ってます。

これもXLを買ったんですが、袖が萌え袖になっちゃうくらい大きいですね。まあ小さいよりは全然マシですが・・・これから冬場になるので活躍機会は増えそうです。

f:id:kuromoka16:20191025022200j:plain

また前を閉めようとしたとき違和感を感じたのですが、ファスナーが右側に付いています。調べた感じどうもアメリカの服は日本の左側と逆のことが多いらしいですね。大したことではないですが、右利きで慣れてないのもあり少し閉めにくさは感じますね。

f:id:kuromoka16:20191025022440j:plain

最後に

こういうグッズ販売をするようなOSSプロジェクトはあまり見たことがなかったのですが、応援する側にとっては好きなOSSのグッズがもらえるのは嬉しいし、良い取り組みなのかなと思いました。

今後もVuetifyが発展していくことを祈って、みなさんもぜひVuetify Storeでなにか買ってみましょう！

*1:英語での住所の書き方は、海外通販するなら必ず覚えたい！住所入力フォームの英語での書き方などのページを参考にしてみてください

We Are JavaScripters! @36th で登壇してきた #wejs

9/30に以下のイベントでLTしてきました。 wajs.connpass.com

スライドはこちらです。

発表内容

タイトル通り「TypeScriptでVSCodeの拡張機能を作っている話」をしました。ほんとうは登壇までに完成させて「作った話」にしたかったですがｗ

VSCodeの拡張機能を作るのもTypeScriptを触るのも初めてだったので、今回の開発経験をもとに以下の3点について話しました。

作っている拡張機能について

「CircleCI Status」というVSCodeの拡張機能を作っている話を最初にしました。

github.com

スライドにもあるように正常系は大丈夫そうですが、それ以外がまだ怪しいので修正して頑張って公開までこぎつけたいと思います！

VSCodeの拡張機能開発について

拡張機能開発を実際にやってみて、「こんな流れで開発してたよ」って話をしました。

簡単にまとめると、「ドキュメントを読むよりはコード読むほうが開発の参考になるかも？」という話です。まあ公式ドキュメントは英語しかないから理解が追いつかないって部分もありますが 😇

特に以下リポジトリの、公式のサンプルコード集には本当にお世話になりました。

github.com

TypeScriptで開発してみて

（拡張機能開発には直接的には関係しないですが）TypeScriptを初めて触ってみて、良かったところ・辛かったところを話しました。

VSCode上での開発体験本当に素晴らしすぎます・・・

会場について

会場のSmartHRさんが入っている六本木グランドタワーは、すでに何度か行ったことがあったので特に迷わず行けました。ただビルに入ってからどこに行けばいいかは分からなかったので、以下の記事がとても分かりやすく参考になりました。

shanaiho.smarthr.co.jp

会場の中はとてもきれいでした！

感想

「We Are JavaScripters」の参加は1年以上ぶりくらいでしたが、当時から良い意味で登壇への敷居の低さは感じれる勉強会だったので、特に変わってない感じで良かったです。

またスピーカー側にはバッジをもらえたのですが、こういうのがあると懇親会のときに誰がスピーカーだったか分かりやすくなるので、良い仕組みだと思いました！

f:id:kuromoka16:20191003025539j:plain

登壇枠の倍率がいつも高いので次がいつになるか分かりませんが、機会あったらまた登壇したいですねー

技術書典7にサークル参加したので頒布数や大変だったことの話 #技術書典

イベント参加

9/22 の技術書典7に「くろもワークス」で参加してきました！ ブースの様子はこんな感じです。当日来て頂いた方ありがとうございました 🙏 f:id:kuromoka16:20190923233941j:plain

頒布した本

「PHP7時代のコードの書き方」という、あとがきでもTwitterでもたびたび言ってますが我ながら偉そうなタイトルの本を頒布しました。

内容的にはPHP7.3までのPHP7の新機能についていろいろ紹介している本です。PHP7使っているけどPHP5のころと何も変えてなかったり、PHP7の新機能をまだ知らない方とかの参考になることを期待した本になっています。
正式版はまだなので付録としましたが、PHP7.4にもちょっとだけ触れています。（印刷するにあたってページ数を4の倍数にする必要があるので急遽入れたという事情もあったりなかったり・・・）

boothでもPDF版・冊子版を販売しています。冊子版のほうはこの記事を書いた時点ではまだ入荷待ち状態なので、「入荷お知らせメールを受け取る」をポチってくれると嬉しいです。

当日の頒布数

当日は冊子版と急遽キンコーズ大先生にお願いして、DLカードも作ってみて頒布しました。頒布数としては以下のような数値になりました。

  • 冊子版
    65冊
  • DLカード
    9枚

サークル側からはチェック数が見れるのですが最終的には「被チェック数：151」になりました。もちろん全員が必ず来て買うわけではないのは理解しているんですが、それを加味してもちょっと少ない印象はあるので本のクオリティを上げていくことが必要かなと感じています・・・

また今までの技術書典ではコピー本でやってきたのを、今回は初めて印刷所に入稿（日光企画さんにお願いしました）して本を作ってみたりしたので、気合が入ってたのと単価を安くするために200冊刷ったので、冊子版が結構あまってますｗ
手元に少しだけ残して大半は会場からboothに直接送ったので重い荷物を持ち帰ることはなかったですが、単価に目がいって自分のレベル感にあっていない部数を刷ったのは課題ですね。

あとは執筆にいっぱいいっぱいでSNSなどでの宣伝に時間を掛けれなかったのも敗因とは思ってて、次は余裕を持って原稿完了させて宣伝に時間を掛けれるようにしたいです。

大変だったこと

売り子が大変

サークル「くろもワークス」は私一人でやっているので、一人だと当日もスペースに私しかいないのでなかなか離れづらいのが難点です。自分のほしい本を買えなかったり会場の様子とかも本当はもっと見て回りたかったです（3Fはこれまでと比べて平和でしたが2Fはすごかったらしいので）。
売り子の募集もかるーくTwitterで掛けてみたんですが、自分の本がほんとうに出来上がるかが不安で万が一落としてしまったことを考えるとあまり積極的には宣伝できなかった、というのもあります。

デザインが大変

ただ売り子は最悪当日自分が我慢すればなんとかなるんですが、それより大変だったのは間違いなく各種デザインの作業でした。
具体的には、本の表紙の作成・頒布物紹介の作成・DLカードの作成・印刷所への入稿データの作成など・・・デザイン知識皆無の素人がこれらをやるのはめちゃくちゃ大変でした。
逆に言えば、普段エンジニアとして働いているとまずやらないことなのでデザインを作る楽しさもあるんですが、やはり他のサークルのきれいなデザインの表紙の本とか見ると凸みますorz

良かったこと

印刷所に本を入稿して本を作れたこと

今回の個人的目標でもありました（前回の技術書典6後のツイート）

入稿はギリギリになってしまったので当日に初めて製本された自分の本を見ました。朝に自分のスペースにつくと印刷所の方が置いてくれた段ボールがあったのですが、開けたときのコピー本との品質の違いにちょっと感動してました。 f:id:kuromoka16:20190924012554j:plain また入稿しようと思うとイベント前に強制的に期限ができるので、これまでみたいに前日のギリギリまで執筆するような事態にはならず、心理的に楽な状態で当日を迎えれたのは良かったことでした。

過去に比べて一番多く頒布できたこと

先ほど当日の頒布数も書いたのですが、このくらいの頒布数は技術書典のサークルの中では全然ありふれた数だと思っています。
ただ自分の中では技術書典5からサークル参加してますが、今回が一番多く頒布することができました。これは5や6が正直適当な心構えで薄いコピー本で参加していたのもありますが、本の内容的にも今回は初めて黒歴史化しないレベルにはまとめられたのが大きいと思っています。
boothでの販売も初めてやってみて、そちらでもぼちぼちと売れています。ありがとうございます！

次回の目標

次の技術書系のイベント参加は技術書典8になると思いますが、まずは今回出せなかったVuetifyの本を出したいです。今回Vuetify目的で来てくれた方もいたのですが申し訳なかったです。

またデザインはさすがに自分だけだと限界を感じたので、素直にデザイナーの方に頼めるような状態を作っていきたいかなと思っています（残念ながら私の周りには今のところあてがいないですが・・・）

あとは原稿に余裕を持たせて、早割入稿（早めに入稿するほど印刷代が安くなる）を決めたいところです。

改めてになりますが、当日来て頂いた方またboothで購入してくれた方もありがとうございました！

あるあるLT〜サーバーサイドエンジニア〜 Vol.3 でLTしてきた #あるあるLT

イベント参加

6/17に以下の勉強会でLTをしてきました。

andfactory.connpass.com

スライドはこちらです。

テーマについては自分が好きなPHPネタとも悩んだのですが、技術領域がバラバラなことが推測されたので今回は汎用的なテーマにすることに決めて、
自信の経験を元に「チームにジョインしたての開発あるある」というテーマで発表しました。
内容は以下の3個のあるあるネタについて、それぞれ話をしてきました。

  • ローカルの環境構築が大変
  • ドキュメントのサーバ情報が古い
  • 同じエラーログがたくさん出ている

今回この勉強会には初めていったのですが、いい意味でかなり登壇テーマが自由な印象を受けました 😊
人数的にもそこまで大規模でない分、懇親会で多くの人と話せる機会があって楽しかったです！

雑記

前の記事に引き続き、会場に着くまでネタです。

kuromoka16.hatenablog.jp

会場のand factoryさんは、住友不動産青葉台タワーというところでした。 f:id:kuromoka16:20190620011357j:plain

地図を見ると分かるのですが、割と駅から離れていたのでどうやって行くのか悩みました。
調べてみるとシャトルバスが出ていることが分かったので、仕事帰りであまり時間がなかったので、行きについてはこれに乗っていきました。
参考になったら嬉しいです！