progrhyme's tech blog

主にIT関連の技術メモ

HTML5 Conference 2018に行ってきた

掲題のイベントに行ってきたのでログを残しておく。

HTML5」ということで、比較的フロントエンド寄りの話が多かったと思うが、プロトコルや認証、CDNといった話題もあった。

朝から行って、最後のスペシャルセッションの前で引き上げた。
LT大会も盛り上がっていたようなので、もう少し残っても良かったかも。

聴講したセッション

光を超えるためのパフォーマンスチューニング/アーキテクチャ @mizchi

FIDO認証によるパスワードレスログイン実装入門 / 合路健人

Web Components のリアル @aggre

コンパイルターゲット言語としてのWebAssembly、そしてLINEでの実践 @uta_tti & @kawasako

HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで / 浅井智也、永井泰裕

セッション動画

YouTubeチャンネル https://www.youtube.com/user/html5j で公開されるようだ。
現時点で、ホールでの基調講演やLT大会含むセッション動画が公開されている。

上の動画中のLT大会の様子を流し見しながら、この記事を書いた。

全体的な感想

自分はインフラ~サーバサイドを見ることが多いのだけど、Webシステム全体の最適化を考えると、クライアントサイドの技術の進化も見過ごせない。
本カンファレンスでは、種々の最新Webテクノロジーについて、濃いセッションを多く聴くことができ、なんとなく肌感覚のようなものを掴むことができたように思う。

ありがとうございました!

関連リンク

Engineering Manager Meetup #2 に行ってきた

f:id:progrhyme:20181027235422j:plain

  • はじめに
  • オープンスペース(テクノロジー)
  • OSTセッションのテーマ
  • 参加したディスカッション
    • 第1回OST - 「エンジニアの文化づくり」
    • 第2回OST - 「エンジニアリングマネジメントの勉強法」
  • その他、感想
  • 終わりに
  • 関連エントリ
  • 脚注

はじめに

昨晩、こちらのイベントに初めて参加して来ました。

会場はWantedlyさんでした。
レセプション兼プレゼンテーションスペースですかね(?)
おしゃれで広々としたカフェのような雰囲気のスペースで、いい感じでした。

前回、このシリーズの最初のミートアップは9/25に開催されたようです。*1
その時はスルーしてしまったのですが、イベント後にタイムラインやはてブなどで反響を見て、「次回はぜひ参加しよう」と思っていました。

オープンスペース(テクノロジー)

今回のミートアップでは、前回と同様に オープンスペース形式 で議論が行われました。
私はこのオープンスペース形式について知らなかったのですが、下のようなものだそうです。

続きを読む

「Jenkins ユーザ・カンファレンス 2018 東京」に行ってきた

昨日、掲題のイベントに行ってきました。
下がイベントのページです。

以下、聴講したセッションのログや感想などを記します。

  • 聴講したセッションとその資料
    • 基調講演 @kohsukekawa
    • Accelerate with Jenkins X @jdrawlings
    • Continuous Delivery Best Practices with Jenkins and GKE @yuki_iwnr
    • AWSとJenkinsを活用して1年間で約500回商用デプロイした話とKubernetes活用 @takamii228
    • LT: Jenkinsを簡単運用ツールとして活用して非エンジニアに喜ばれた話 @morihaya55
    • LT: DevOps World | Jenkins World 2018の参加報告 by 坂本さん
    • LT: Jenkinsで運用業務の改善をしてみて気づいたこと @y0shirak0
    • LT: JenkinsとCodeBuildとCloudBuildと私 @irotoris
  • 感想
  • SPECIAL THANKS
  • 参考
  • 聴講ログ
    • 基調講演 @kohsukekawa
    • Accelerate with Jenkins X @jdrawlings
    • Continuous Delivery Best Practices with Jenkins and GKE @yuki_iwnr
    • LT: DevOps World | Jenkins World 2018の参加報告 by 坂本さん
続きを読む

はてなブログのHTTPS化とblogsyncによる一括編集

このブログでHTTPS配信を設定したのは3月のことでした。

このブログは開設から日が浅く、記事数も少ないので特に記事内容のリンクを修正するといった手間はほとんど発生しませんでした。

…が、つい先日、軽い気持ちで管理者権限を持っている別のはてなブログHTTPS化したところ、mixed contentsが大量に発生し、スライドなどの埋込みコンテンツが真っ白になるという事態になってしまいました。
最近の記事は手作業でちまちまとリンクを修正したのですが、合計で300以上の記事数が有り、さすがにやってられんということで自動化できる手段がないかな…と調べました。

そこで思い出したのが、 @kiririmode さんが書いていた下の記事です。

blogsync というツールを使うと、はてなブログの記事を一括で編集操作できるようです。
というわけで、やってみました。

blogsyncのインストール

以下、動作環境はUnix系OSの前提で書きます。

blogsyncはGo言語で書かれたCLIツールです。
下のコマンドでインストールできます。

go get github.com/motemen/blogsync

設定ファイルの用意

READMEの通りですが、 $HOME/.config/blogsync/config.yaml という設定ファイルを用意します。
このブログをサンプルとすると、下のような内容になります:

tech-progrhyme.hatenablog.com:
  username: progrhyme
  password: <APIキー>
default:
  local_root: /home/progrhyme/my/blog

ここで、 <APIキー> は、はてなブログの詳細設定画面から取得することができます。

全エントリをはてなブログからダウンロード

blogsync pull tech-progrhyme.hatenablog.com

これにより、設定ファイルの local_root で指定したディレクトリ配下に記事のテキストがダウンロードされます。
下のように tech-progrhyme.hatenablog.com/entry/${日付}/${記事名 or タイムスタンプ}.md というファイル名で格納されます。*1

/home/progrhyme/my/blog
└── tech-progrhyme.hatenablog.com
    └── entry
        ├── 20170314
        │   └── 1489417212.md
        ├── 20170331
        │   └── 1490886079.md
        ├── 20170521
        │   └── 1495292715.md
        :

記事のリンクを一括置換

ここではシェルのワンライナーを使って一括置換しました。*2

git grep -l http://tech-progrhyme | xargs perl -pi -e 's|http://tech-progrhyme|https://tech-progrhyme|g'

他に、いくつかのドメインについても、以下の条件を満たすものは同様に一括置換しました:

  • http://https://機械的に置換して問題ないもの
  • はてなブログのembedリンクを使って埋め込んでいたもの(読み込めずに真っ白になってしまうので)

ワンライナーとしては下のようになりました:

for domain in www.slideshare.net qiita.com togetter.com connpass.com; do
  echo $domain
  git grep -l http://$domain | xargs perl -pi -e "s|http://${domain}|https://${domain}|g"
done

更新したコンテンツをアップロード

これらの記事テキストはGitで管理することにしたので、以下のようにして差分のあるファイルをblogsyncコマンドでpushしました:

git diff origin/master --name-only | xargs -t -n1 blogsync push

以上で、作業は完了です。
ブログのページにアクセスすると、ちゃんと各リンクのURLが更新されていました。

終わりに

調べてみて「これなら簡単にできそうだな」と思ったのですが、やってみると実際に簡単でした。
こういったツールやAPIが整っていて良かったです。

もし、はてなブログHTTPS化をまだやっていなくて、このような記事内容の一括編集が必要な方がいたら、blogsyncが活用できそうです。
ご参考まで。

参考

脚注

*1:ファイル名が*.mdなのはMarkdownで編集しているので

*2:実際は別のドメインですが、説明の流れで http://tech-progrhyme.hatenablog.com を対象としています。

HashiCorp Japan Meetup #3 に行ってきた

サブタイトル: 「DevOpsを支える今話題のHashiCorpツール群について」

会場はDeNAさんでした。
生ハム原木がその場でスライスされて振る舞われる勉強会は初めてでした。
美味しかったです。ご馳走さまでした。*1

  • 資料
    • AI&分析基盤で活躍!HashiCorp Products
    • コンテナ基盤を支えるHashiCorpソフトウェア
    • applibotのDevOpsを支えるterrform/packer
    • tfnotify - Show Terraform execution plan beautifully on GitHub
    • HashiCorp OSS in dwango
  • 所感
  • 個人的ハイライト
    • Mitchell HashimotoはHashiCorpにおけるダジャレの伝道師
  • 結びに
  • 備忘メモ
  • 脚注

資料

AI&分析基盤で活躍!HashiCorp Products

@mazgi / DeNA

コンテナ基盤を支えるHashiCorpソフトウェア

@linyows / ペパボ

applibotのDevOpsを支えるterrform/packer

@gacharion / アプリボット

tfnotify - Show Terraform execution plan beautifully on GitHub

@b4b4r07 / メルカリ

HashiCorp OSS in dwango

@eigo_s / ドワンゴ

所感

(雑文にて、すいません)

今回はTerraform成分が多かったです。全発表で登場していました。
どこでも使われているんだなーというのがわかったのと、各社の運用の知見を色々聞くことができました。

*1:一方で、発表者の横でスタッフが生ハム原木をスライスしている様子がシュールだという声もTLで見かけました。

続きを読む

プロフィールサイトをGitHub Page + CloudFlareによる独自ドメイン×SSL配信に移行しました

はじめに

このブログからもリンクしている私のプロフィールサイトは、これまでは手抜きをしてGoogleサイトで作ったもの*1でした。

大したコンテンツがあるわけでもないので、特に問題は無いのですが、いまのアカウント(id:progrhyme)を作ったときに自分用のドメインも取得していたので、せっかくならばそれを活用したい、という気持ちはありました。

調べたところ、Googleサイトで独自ドメインを利用するにはG Suiteが必要そうです。*2
G SuiteはBasicプランが月額600円と、個人で使うとしても決して高いものではありませんが、今のところ本件以外にG Suiteを使うモチベーションはありません。
また、せっかくWeb業界にいるエンジニアなので、もう少しテクニカルにやってみようと思いました。

GitHub Pages + CloudFlareの設定

GitHub PagesGitHubが提供している静的なWebサイトのホスティングサービスで、GitHubユーザであれば無料で利用できます。
また、CNAMEレコードを設定することで、独自ドメインも使うことができます。

数年前なら、ここでSSL証明書をどうするか頭を悩ませることになったかもしれませんが、ここ最近は無料で証明書を提供してくれるサービスが増えてきました。
そもそも、今年の5月にはGitHub PagesそのものがカスタムドメインによるHTTPS配信を無料でサポートするようになりました。*3

初め、私もこの機能を使ってSSL化を試みましたが、一般的にZone Apex(サブドメインドメイン名そのもの)にはCNAMEを設定できないというDNSの仕様があるため*4https://www.progrhy.me のようなURLになりそうでした。
それでも特に実害はないのですが、なんとなく嫌だなということで更に調べていたところ、Cloud FlareのDNSの場合、 CNAME Flattening という仕様が有効になっており、Zone Apexに対してもCNAMEを利用することができるとのことでした。*5

というわけで、ドメインを購入したレジストラでCloudFlareにネームサーバを転送する設定をして、 https://progrhy.meGitHub Pagesで作ったサイトが見られるようになるところまでは一晩で設定できました。

Bootstrap Themeによるデザイン調整

最初はデザインは適当に済ませて、とにかく旧サイトから移行をしてしまおうと考えていたのですが、中々いい感じのテンプレートやツールを見つけることができず、意外に悪戦苦闘してしまいました。

最終的にGrayscaleという比較的シンプルなBootstrapのテーマを選びました。

おかげで期せずしてgulpやSassという新しめのフロントエンドのツールに触れることになりました。
あと、CSSのメディアクエリの書き方などを覚えました。

移行の現状

上述の通り、 https://progrhy.me/ で新サイトを閲覧できます。
このブログも含めて各種サイトやSNS等のリンクは一通り更新したつもりなので、移行としては完了です🎉

今後の予定

色々やり得ることはあるのですが、まずfaviconがまだ無いので、早めに作って設置したいと思います。

他方、npmの依存モジュールで脆弱性があるようで、GitHub上でセキュリティの警告が出ています。
大したことはしてないはずなのに package-lock.json が6218行もあって、npmの世界は怖いなと思ったものですが、ともあれ整理が必要そうです。

本サイトの更新頻度は高くはならないと思いますが、CloudFlareのキャッシュクリアなど含めてCI設定もできるといいなと思っています。

終わりに

この記事を書いている間にMicrosoftの「Sketch 2 Code」という新サービスのニュースが飛び込んできました。*6
AIによって、手書きのワイヤーフレームをHTMLに変換してくれるもののようです。

やってみて実感したのですが、素人がHTMLをいい感じに組むのは難しいので、AIで簡単になるといいなと思いました。

脚注

『SQLアンチパターン』を読んだ

3〜4年前に買って積ん読していた『SQLアンチパターン』を、最近やっと読了しました。*1

本書について

本書は、技術書の良書として有名で、「ITエンジニアが読むべき本」のようなまとめに挙がることも多いので、知っている方や既に読んだという方も多いでしょう。

本書では、著者が長年SQLに関する仕事に携わるなかで遭遇した25個のアンチパターンが紹介されています。
アンチパターンとは即ち、「SQLを使用するプログラマーが最も頻繁に犯しがちなミス」とのことです。*2

特徴

本書では25個のアンチパターンが紹介されていますが、それぞれにキャッチーな名前が付けられています。
これは、本書の冒頭部で書かれている、以下のような業界の慣例に従ったものでしょう。*3

世の中のアンチパターンの多くには、「黄金のハンマー(Golden Hammer)」「車輪の再発明(Reinventing the Wheel)」「委員会による設計(Design by Committee)」などの、ユーモラスで刺激的なタイトルがついています。優れたデザインパターンアンチパターンには、比喩的で内容を連想しやすい名前を与えることが慣例となっています。

また、各章が統一された1つのフォーマットに従って構成されている、という点も特徴に挙げられるでしょう。 即ち、下の構成です:

  1. 導入
  2. 目的
  3. アンチパターン
  4. アンチパターンの見つけ方
  5. アンチパターンを用いてもよい場合
  6. 解決策

このようにフォーマットが揃っているので、次に来る内容が予測しやすく、とても読みやすいです。

更に、導入部分はちょっとしたエピソード仕立てになっており、あわれな登場人物(=「あなた」)がいかにアンチパターンにハマったかが綴られています。
その点で、読み物としてもセンスの良さが感じられました。

どんなアンチパターンが紹介されているのか

本書で紹介されているアンチパターンは全て、以下のいずれかに該当するそうです。*4

  • 著者がソフトウェア開発やRDBMS製品のテクニカルサポート、研修、インターネットフォーラムでのやりとりを通じて実際に見てきたもの
  • 著者自らが陥ってしまったもの

私の(著者よりは乏しい)Webエンジニアとしての経験からは、以下のようなパターンがあると見受けられました:

少しだけ例を紹介します。

①については、例えばRuby on RailsなどのWAFではすべてのテーブルに id という名前のPrimary Keyを作るのがデフォルトの挙動となっていますが、その挙動は 「ID Required(とりあえずID)」 アンチパターンを生みかねません。

②に関して、 「Keyless Entry(外部キー嫌い)」「Multi-Column Attribute(複数列属性)」 あたりの章を読むと、胸がむかむかとしてきました。
名前から想像がつくかと思いますが、前者は外部キー制約を極端に避けるアンチパターン、後者は本来従属テーブルに切り出すべき属性を親テーブルに attr1, attr2, ... のように複数のカラムで持たせてしまうものです。
「Index Shotgun(闇雲インデックス)」「Spaghetti Query(スパゲッティクエリ)」「Poor Man's Search Engine(貧者のサーチエンジン)」 などのアンチパターンの名前を聞くと、Web開発に馴染みのある方であれば、頭が痛くなってくる方もいるのではないでしょうか。

③については、 「Readable Passwords(読み取り可能パスワード)」SQL Injection(SQLインジェクション)」 はポピュラーな問題だと思います。

これらに当てはまらないものでは、私にとって馴染みが薄いものも多く、学びがありました。

本書を読むべき人は誰か

本書の冒頭部には、「初心者から経験豊富なエキスパートまで、あらゆる段階の方に役立つ内容をお届けします。」とあります。

私自身は、Webシステムの開発や運用に携わるようになってもう10年近く経ちますが、上に書いたように十分に学びがありました。
ただ、もっと早く読んでいればよかったな、という感は否めません。

RDBSQLの入門書ではないので、全くの初心者向けとは言えないと思います。
RDBSQLについてある程度学んで、かつ、実際に多少のシステム開発や運用を経験した上で読むと良いのではないでしょうか。

どちらかというと、開発時――中でも、DB設計時に考慮すべき事柄が多いと思います。
その意味で、DBAよりはむしろアプリケーション開発者が読むべき本かな、と思いました。

まとめ

掛け値なしの良書でした。
オススメです。

参考

SQLアンチパターン』を含むIT技術書籍まとめ:

*1:オライリーのサイトで電書版を買いました。

*2:本書「はじめに」の「対象範囲」より

*3:本書「はじめに」の「本書の構成」より

*4:本書「はじめに」の「対象範囲」より