お久なWeb開発、ポートフォリオサイトを作る。

3939.moe

/吾輩はポートフォリオサイトである。OGPはまだない。\

2015年に取得した3939.moeを、重い腰を上げてポートフォリオサイトに仕立て上げた。ドヤ顔Firebaseの割にはまだWantedlyにも達しないちんけなサイトだが、これからも拡充する予定だ。Stay tuned.

まあ『てんやわんや』と形容するほどのことではないけれど、しかし、なれない世界を歩くぎこちなさが拭いきれない、久しぶりの Web 開発だった。

ドメイン今昔物語

件のドメインを取得したのは、もう懐かしいとすら思う3年前の PyCon JP 2015 だ。今も PyCon JP のスポンサーである Gandi.net が .moe を無料配布していて、ここぞとばかりに初音ミクあたりのキーワードで取ってやろうと奮い立った。

もちろん hatsunemikumiku は埋まっていて「まあそんなもんだ」とか言いながら、じゃあ 3939 はどうだ!?と検索欄に入れたらビンゴだったというわけだ。(ちなみに hatsunemiku の所有者とは後日偶然会うことになる)

会場で猛烈な勢いで素のCSSと素のHTMLを書き、ミクカラーのストライプと「Welcome to 3939.moe!」というひねりゼロの <p> タグを置き、GitHub に push した。Gandi.net のスタッフさんとアゲアゲで話し、記念写真を撮った。

そして時は流れ、何かにつけて「ポートフォリオ作らなきゃなー」と垂れつつ、いやでも面倒だしうわ〜とか言っていたら2018年になっていた。実に24歳の秋口である。

ホスティング

最初は思考ゼロで GitHub Pages を利用した。しかしこれには1つ問題があった。 SSL での配信に対応していなかったのである(当時)。

ホスティングサービスで微妙に悩む中、 @arayaryoma が Firebase Hosting がいいよと教えてくれた。しかも都合のいいことに Let's Encrypt で鍵をいい感じに生成してくれるらしい。緑に輝く南京錠は、思ったより近い存在だったようだ。

Webpack、思ったより良かった

端的に言って、 Web 開発の便利ツールは消耗しながら使うものだと諦めていた。だからアセットをバンドルするツールなんてどれでもいいと思った。本当にどれでもよかったので、なんか最近 [いつ?] 人気っぽい Webpack を採用した。いや、「採用」は過剰だ。なんせ比較なんてしてないのだから。長いものに巻かれる、それが Web だ。(炎上しそうな発言)

バージョン違いの情報に翻弄されたりarayaryomaのBoilerplateを見せてもらいながら格闘した。苦痛が和らぐことはないだろうと思っていたが、フタを開けてみると苦しい期間は思ったより短かった。

nodeenv

別に Webpack 特有の話ではないのだが、 Node.js は nodeenv で環境を切り分けたので、 Python 書きが慣れ親しむ virtualenv の概念が使えた。この時点でまず嬉しい。

公式が最大手な感じ

style-loader を始めとして SCSS を扱うだけで数個の loader が連なるのには閉口したが、こういうよく使われるモジュールは公式謹製で用意されている。だから使い方も丁寧に整備されているし、背景にある理念が一貫しているし、ノリで deprecate しない。いや deprecate 自体はあるのだろうが、「deprecate した」とか「代わりにこれを使えばいい」といった情報はすぐさま手に入った。とにかく Gulp とかで体験した「どっかの人間が作ったよくわからんモジュールのbreaking changeで発生した意味不明なエラーに対処してたらそもそも deprecate しててそもそも最新の Node では動かなかった」みたいな体験がなかった。

なんか全部JSになる

Textで書き出すといったことをわざとしなければ、CSS や画像アセットはすべて1つの JS にまとまってしまう。Webpack が "Module bundler" と呼ばれる所以と、以前使ったビルドシステムとは根本的な理念が違うことをここで悟った。JS 1つ HTML に組み込むだけで全部仕上がる。こいつぁエレガントだ。複数ページに亘るサイトなら話は別だがポートフォリオサイトにはちょうどいい。

FOUC にちょっと悩まされたが、やはり公式が最大手。Issueを見れば「style-loader で singleton: true すればいいよ」と書いてあった。README曰く、CSS を inject する style タグをエレメントごとに生成するのではなく、単一のタグを再利用するのだそうだ。今回はたまたま解決しやすかっただけかもしれないが、このように、loaderごとにリポジトリを分けて管理し、ドキュメントも詳細に書かれていると非常に探索しやすく好感が持てる。

flexbox 対応した Bootstrap 4 が楽しい

以前から知識を更新しない雑な Web 開発しかしてないので、毎度 Bootstrap にはお世話になりっぱなしである。今回も使おうとしたら、以前よりも磨きがかかっていた。それは flexbox を中心としたカラム配置に変わったことである。

何を以って「自然」というかは人によりけりだが、個人的には flexbox によるブロック要素のサイジングはそれまでの手法より自然に感じる。なんかいい感じに伸び縮みしてほしいとき、そのとおりに書くだけで伸び縮みしてくれるし、並びを変えるのも楽ちん。だから Flexbox Froggy を初めて遊んだ時から「Bulma はいいなあ、これが Bootstrap に入ればいいのに」と思っていた。

実際 3939.moe を開発するときも Bulma を選択しかけたのだが、 Bootstrap 4 Beta (当時) は flexbox に鞍替えしたとの情報を聞いて速攻で決定した。

今回は column の使用量が少ないサイトになったので Bootstrap の本領は発揮できていないし、ほぼ形骸化した <div class="row"> を邪魔に思うことすらあった。でもそれ以上に、 "Works" の欄のようにcolumnを分けたい時さっと分けられて、レスポンシブ対応も極めて容易な Bootstrap は改めて使い勝手が良いなと思った。Twitterに感謝。

見た目とデザイン

「Welcome to 3939.moe!」時代と同じくミクカラーのパレット感を全面に押し出したかったので、4色(薄ミク・濃ミク・濃いピンク・ダークグレー)のページをセクションごとにスタックしたような構造を設計した。シームレスで一体感あるページ構造や、 vw を利用した完全レスポンシブな実装はちょっとだけ自慢したい。

ただ、これはわざとなのだが、下のセクションになるほど幅が広がる構造のために中心揃えのコンテンツが次第に左にずれていく表示になる。ここは微妙に悩むところだ。セクションがもっと縦に伸びて1画面に収まらなければ h1 が同時に見えなくなり不自然さは減るので、コンテンツの拡充かデザイン変更か今後考えたい。まあ突然思い立って模様替えとかしてそうだが。

フォントは Google Fonts で計40個ほど候補を選び、順位をつけて絞り込んでいった。フォントというのは好みの塊だが、自然に美しいと思えるタイポグラフィにしたかったので、実際に置いてみて素直に合っていると思えるフォントを選定した。結果、本文に Sans Serif の「Mukta」、ヘッダーに手書き風Scriptの「Pacifico」を選定した。しかしMuktaはもっとウエイトの低い字体も欲しかった。ウエイトが高すぎて本文にしては収まりが悪いし、ヘッダとのコントラストに欠けるからだ。

意味論の再考

コードを書き始めた当初、強調された本文とそうでない本文はそれぞれ <h1><p> に包んで並べていた。これがとにかくひどい見た目だった。

<p>Hello! I'm</p>
<h1>Takumi Sueda</h1>
<p>aka</p>
<h1>puhitaku</h1>

冷静に考えれば、いろいろおかしい。そもそも <h1> はブロック要素だ。文の途中にペロッと出てくるものではないし、肝心の「文」は途中でパラグラフが分かれまくっている。支離滅裂だ。MDN(雑誌ではない、Mozillaの方)とか読んで頭を冷やす。なんだ、強調は古式ゆかしい <em> でやればいいじゃないか。

<p>
    Hello! I'm
    <em>Takumi Sueda</em>
    aka
    <em>puhitaku</em>
    .
</p>

<span> でやれという人もいるかもしれない。個人的には、ememphasize (強調)なのだから、強調されるスタイルが適用されればセマンティクスとして合っているし、 <em> の標準動作であるイタリックである必要はないと思っている。イタリック体はあくまで英語圏でいう「強調」の感覚だ。

今後の拡充

まだ Wantedly に書いているほどの情報量にも達していない。とりあえず趣味と得意分野と若干のアウトプットだけ記したが、これではまだちょっとした自己紹介の域を出ていない。まあ要はもっとアウトプットしろということだな、と自分で妙に納得してしまう。いや、納得しちゃいけない。もっとやっていこう。

PyCon JP 2018 参加・発表した

f:id:puhitaku:20180923190009p:plain

今年も PyCon JP に参加した。おかげさまで2年連続でトークセッションに受かったので、弊社で開発中のロボットで動かしている C 拡張モジュールを Python 3 に移植した事例をもとに、発表用にシンプル化して発表した。

speakerdeck.com

喋った感想

ニッチめの話題だったためか聴いてくれた人数はまあこれぐらいかという感じ。私が入室しようとした時点で廊下から見える位置に「満室」の札が貼られっぱなしだったことや、難易度を Advanced にしたのもあるかもしれない。まあ、聴きたい人が狙って聴きに来れたものと好意的に解釈したい。

喋りは軽快にできて良かったと思う。1スライドあたりの情報量はもっと多くしてもよかったかもしれない。プロジェクターが1024x768と低解像度なので、年代物かと少々身構えすぎた。16:9でのスライド作りに慣れてしまった今、相対的に縦に情報量が増やせるはずの4:3は低情報量であると錯覚してしまう。まあ実際解像度としては低かったのだが。

本当はライブコーディングがしたかったので少しばかり未練が残る。不運というか自分の手際の悪さというか、PyCon JP 以前の1〜2週間が異様に忙しくなってしまいそれは叶わなかった。スケジューリングしかり、トーク内容の追い込みしかりは来年への課題となった。

他のトーク

集計によると、今年はWeb(Django)の話題が多かったそうだ。過去2年ほどはデータや機械学習的なものが多い印象だったので意外だ。個人的にはPythonそのものや知的好奇心をくすぐる話が聴きたいので、スポンサーブースの手伝いで聴けなかったもの以外はできる限りそれっぽいのを選択した。幸いにもライブ放送がそのままYouTubeに上がるので、聴けなかったものは帰宅してから1日ずっと聴いた。面白かったものは以下。(敬称略・表記は公式HPによる)

  • Keynote: Kaufmann Manuel - Argentina in Python: community, dreams, travels and learning
    • 今まで PyCon JP で聴いた Keynote の中で一番良かった
    • Python に魅了された彼は、何度かの事故や食中毒、ボリビアでの暴動(!)に巻き込まれながらも、アルゼンチン国内のみならず周辺諸国にわたって Python を教えて回った。そのストーリーを語りながら発する言葉には並々ならない説得力があり、これから2日間のカンファレンスを始めるよいスタートとなった。
  • Luka Sterbic - Why you should care about types: Python Typing in the Facebook Backend
    • 毎年1〜2セッションはある Static type check 系のセッション
    • 「Type hints は Pythonic だ」と語る根拠として、大きなコードの中のある関数にどういうオブジェクトが渡ってくるかを調べる場合などが挙げられしっくりきた; 実際、でかいコードやデプロイが必要なコードは手元で実行したりデバッガを挟むことも難しいし
    • Instagram 製の MonkeyType は実行時の型情報をスタブに書き出し、コードに反映させられるため既存のコードへのアノテーション追加を加速できる
    • 大きなコードにアノテーションを付加するには、まず共通で使われる小さいモジュールから付加していくといい
  • Atsushi Odagiri - あなたと私いますぐパッケージン
    • aodagさんのセッション
    • 曰く「グ」を入れ忘れていたらしい
    • パッケージングに関するPEPを渡り歩く感じ
  • 北神雄太 - Pythonを使ったハードウェア開発について
    • だんだんと高いレイヤーに応用が進んでいく様子が面白い
  • 澁谷 典明 - JVM上で動くPython3処理系cafebabepyの実装詳解
    • 去年 LT? で cafebabepy のお話を聴いてから興味があった
    • 濃くてよかったー
    • 間違いなくもっと評価されるべきトークだと思う
  • 長谷場 潤也 - AltJSとしてのPython - フロントエンドをPythonで書こう
    • 思ったよりマジで Python なコードがそのままブラウザ内で動いていた
    • 曰く Python の組み込みオブジェクト・関数系はほぼ全部提供されているらしい
    • 型チェックまでできるとか、商業的に使われないにしても本気度が伝わってきて楽しい
  • Hideo Hattori - Rust と Python
    • Rust は数年前に変化しまくっていた言語仕様に翻弄されてから触れてないが、それでも大体伝わってくるぐらいよく整備されているようだ

初スポンサー参加

f:id:puhitaku:20180923185400j:plain (写真は弊社 Twitter アカウントより。本当は自分で撮ったのを貼りたかったがカメラを会社に置いてきてしまった、無念)

GROOVE X は昨年も PyCon JP スポンサーとなっていた(私はそれがきっかけで GX を知ることになった)が、今年はついにブース出展ができた。といっても取りまとめは人事の方にお任せしてしまっていたので、終始頭が下がりっぱなし。我々エンジニアが本当にやるべき仕事は「人と話し、ブランドを広め、弊社を知ってもらう」ことだと改めて思い直し、片付けの時間でもひたすら人と話していた。

ブースの位置もとてもよく、人の流れの中にあった。会場移動に限らずあらゆる時間で多くの人に足を止めていただけたと思う。来年は堂々とロボットを飾れるようになるだろうから、どんなスポンサーになれるか今から楽しみだ。

終わったあとも楽しみました

初めてお会いしたメルカリの Komatsu さんc-bata パイセン と話しつつクロージング。その後とりあえず飲みたくてそわそわしてるパイセンに笑いつつ少しばかり商店街で飲んだ。そのあと PyCon JP を支えたスタッフの皆さんと合流し、労をねぎらいつつビールを飲んだ。独歩の樽生マスカットピルスが本当に美味しかった。また飲みたい。

来年

来年はどんなトークを話せるだろうか。ニッチに振りつつそれなりのクオリティのトークが出来たので今年はひとまず満足。来年はより広いオーディエンスに届き、コード書きたい欲を刺激しそうなセッションにしたいなーと思っている。

Pythonの環境管理ツール良し悪し

EDIT: 2018/06/19 pipenvについて追記

本記事は社内向けに書いた文章を修正したものである。

世の中にある代表的な「Python環境管理ツール」に virtualenv, pyenv, venv, pipenv の4つがある。これらをGoogleで検索すると使い方が書かれたページばかりが出てきて、それらの違いや使い分けを解説する記事は少ない。

本当は必要ではないのに「pyenvは便利」のような謳い文句で何となく使わせる記事や、古い情報を元に書いた「一見新しそうに見える記事」も多く見られる。

この記事では、中立・実用重視な視点から各ツールを解説し、筆者が考えうるベター(ベストは人それぞれ)な組み合わせについて書く。

なおAnacondaは初学者が使うにはおすすめできない。Anacondaについての筆者の解釈は末尾にあるためそちらも参照されたい。

本記事公開後いくつか近い話題の記事を教えていただいた。突っ込んだ話も多く参考になるので、末尾の参考欄から是非あわせて読んでいただきたい。

TL; DR

この文章で話すことをかんたんに言うと、

  • pyenvでPythonの複数バージョンを管理する
  • venvでパッケージ環境を切り分ける (Python 2ならvirtualenv)

以上の組み合わせが比較的シンプルながら柔軟でサポートが安定している。

非プログラマーの場合は、OSのパッケージマネージャーで最新のPythonをインストールした方が簡単でトラブルシュートしやすい。

続きを読む