Articles

Ruby で自分のための問題を解決していく話 (個人の Wiki を esa に移行した話) : 続き

  • ARTICLES
Ruby で自分のための問題を解決していく話 (個人の Wiki を esa に移行した話) の続き。前回は文章とコードでの説明ばかりになってしまったので全体的にやっていることを図にしてみた。 PukiWikiをesaへ移行する流れ 作戦としては、 一連の PukiWiki のファイルはローカルに置いて失敗があれば最初からやりなおせるようにする esa の記事作成以外は繰り返し実行可能にする Markdown の変換で PukiWiki と esa の仕様の差分を吸収できるようにがんばる 最終結果を esa 上で確認し、意図しない表示になっているものは Markdown の変換からやりなおして差分が出た記事について esa へ更新をかける という流れで、実行制限のある esa の API 呼び出しを最小限にしつつ、Wiki 内のページリンクなど PukiWiki 資産を最大限に活かせる形を考えた。実際はここまで全部最初から考えてやったわけではなくて、やりながらやっぱり Wiki 内のページへのリンクも有効にしたいなとか #ls もただ機能をつぶすのじゃなくて活用したいなとか考えては実装し、そして再度手順を実行し、という繰り返しだったのでやりなおせる構成にしたのは正解だった。 ここからは esa への新規投稿による記事 URI 確定と、二度目に Wiki 内リンクを解消した更新をかける流れを説明し、最後に繰り返し修正と更新を繰り返す中でどんな PukiWiki の仕様で引っかかったかとその対処を説明する。 esa への新規投稿で記事 URI を確定させる ページ名を日本語でもつけていることもあり、WikiName による Wiki 内のページのリンク機能を前提として書いている文章はさほどないが、[[Page name]] と囲むことでページ名を指定してのリンクは多用しているのでこれは活かしたい。 実際は記事の URI を確定させたいというだけなのだけど、esa 上に記事をつくるしかその手段がないので全記事を投稿して記事番号を採番してもらい、URI を確定させる。

Ruby で自分のための問題を解決していく話 (個人の Wiki を esa に移行した話)

  • ARTICLES
はじめに 遅くても 2008 年ごろから使っている個人の Wiki があって、調べたことや頻繁に探すことをメモしたりして使ってきた。当時職場で使っていたのが PukiWiki で使い慣れていたという理由だけで使い始めた PukiWiki をそろそろさすがに別のものにしたいなと感じていたので esa に移行をした。そのときに考えたことやこうやって移行をしたという記録。移行対象となった PukiWiki のバージョンは 1.5.0 のため、以後の各仕様は v1.5.0 のものになっている。 最初に考えたこと まずなにはなくとも PukiWiki 記法を Markdown にする必要がある。それから自分の用途としてダウンロードした各種スライドを添付していて、中にはすでに WWW 上では見つけられないものもあるので添付ファイルを完全に移行したい。そこまでどうにかできればあとは互換性のない移行をあきらめることでどうにかなるだろう。 と、まあ、あまり細かいことは考えずに始めた。 PukiWiki 記法を解釈して Markdown に変換する 検索すると正規表現を使ってごりごりと変換していくサンプルはいくつか見つかったのだが、自分でこれを修正しながら互換性を上げていく土台としてはきついなというものが多かった。そこで、パーサジェネレータを使ってみたかったという興味もあり、Parslet で PEG スタイルのパーサを書いてみることにした。 Parslet のパース結果はツリーで Array として返され、Hash が入ってる。Hash は Symbol と Parslet::Slice でできてる。Parslet::Slice は出自の位置をもった String みたいなもの。to_s をすると文字列を取り出せる。 {:toc=>"#contents"@0} #=> [Symbol, :toc] [Parslet::Slice, "#contents"@0] 実装進めるにあたっては、他の実装を参考にするのが一番イメージがつかみやすかった。 https://github.com/kschiess/parslet/tree/master/example frsyuki さんの MessagePack パーサの実装 できあがった実装が pukiwiki2md として公開されている。この Gem を使うと、Parslet に則って、Parser#parse でパースし、その結果を Transform#apply で Markdown へと変換することができる。

実行力こそが違いとなる

  • ARTICLES
(時間の)95%は企業がしっかりとその計画を遂行できるようにすること CEO と成長の苦しみ - Sam Altman とのインタビューを読んだ。全体にとても納得感があり、自分の感じるものと近いところの多いインタビューだった。 Sam Altman CEOという役職に求められるのは、企業が何をすべきかを見極めること、そして実際に企業がそれを行動に移すようにすること、基本的にはこの2点です。 (略) Sam Altman この難しい部分は、多くの人たちが最初にやるべき部分、つまり会社が何をすべきなのかを見極めることです。しかし実践において、時間的にはこの仕事は5%に過ぎず、残りの95%は企業がしっかりとその計画を遂行できるようにすることだと思います。ですが、こういう風に計画を確実にこなせるようにするというのは、要するに信じられないほどの繰り返しの作業なので、ほとんどのCEOにとっては面倒で厄介なことです。 そのためには従業員やプレスや取引先と何度も何度も同じやり取りをする必要があります。「私たちは今これをしている、これが理由だ、そしてこれがそのやり方だ」と繰り返し言うことになります。コミュニケーションを取り、企業のビジョンとゴールをエバンジェライズしていくこと。これこそがCEOが一番多くの時間を割いて取り組むべき仕事です。 『経営は「実行」』という本があって、英題はそのものずばり “Execution” というのだけど、今いる会社はこれを非常に重視していて、戦略とその実行というのが経営を支える屋台骨になっている。会社としての仕組みもそれを維持するために設計されていて、全社がそれで動いている。入社して最初に見たときにはこんな会社があるのかと心底驚いた。 今の自分はその会社では経営と近い立場で思考や実行をするべき役割をしていて、ただ一方で「開発は実行」と割りきってスピードと実行力だけを重視するというのは今まで自分が見てきた開発の実情と合わない部分があるなと感じ、じゃあはたしてなにを大切にするのがよいのだろうと考えながら働いてる。 その中で、フローの仕事だと目の前の流れる仕事の成果を最大化することを一番重視すると大体結果と「それははたしてよいことだったのか」というものが相関しやすいのだけど、ソフトウェア開発という仕事は少し特性が違っていて、開発という活動の結果はソフトウェアとして蓄積され、それが良いほうにも悪いほうにも将来に影響を与えるストック型の仕事だという理解が今の自分の理解になっている。 そして、Web のサービスとして提供し続けていくというのは時間の変化の中で提供をし続けていくことで、それをするためのチームやプロセスというのが必要になってくる。ソフトウェアの性質に引っ張られて、このチームやプロセスを維持する活動もストック型の性質になり、ただ「つくる」ということからイメージされるのとはやや違った価値観が必要になってくると考えている。 Talkin’ ‘bout my “Execution” さて、”Execution” だがこの大事さは理解しつつ、自分はこれが非常に苦手だ。「実現とそのための工夫」は好きだ。開発者なのでむしろそこには喜びを感じる。でもこの「実行」ってやつときたら、もっとつまらないもので、率直にいって創造性が少なくただやるべきことをやる 。それだけだ。それだけのことが多くの人ができないので、重要なのだ。 やることを決める。誰がやるか決める。いつまでにやるか決める。やったかどうかを追いかける。やっていなかったら実現するにはなにが必要か、実現されるまでフォローし続ける。 たったこれだけのことではある。でもやれない。人に嫌がられることもあるし、面倒になって手を抜きたくなるときもある。 以前いっしょに働いていた中にこれがとても得意だった同僚がいた。彼らは会議の場でも状況を聞くのだけど、折にふれてあちこちの場面で声をかけていた。席に来て、「あの件なんだけどどうなってる?」「ほんとに? どうもありがとう」「忙しいところ悪いんだけどさ、でもやっぱりどうしても大事なやつだからさ。よろしくね」「そこで困ってるんだったら協力してもらえないか聞いてみるよ」こんな言葉をかけて嫌らしさを感じさせずに物事を進行させていく名人だった。いつも「いや、ほんと悪いね」と言っていた。 割込されるのは嫌なものだ。だから、アジャイルの開発プロセスではこういったものが解決されるための仕組みというのをいろいろな場面でつくっている。でもあちこちでプロジェクトを見ていて、この “Execution” が弱いなと思う場面が多かった。プロセスの問題ではなくてそこで働く人たちの前提に置いているものだったりに左右される部分が大きいのだろう。同じプロセスで働いていても、この実行をするようにうながす役割を誰かがしてくれるだけで断然結果の出方とスピードが違ってくる。 この実行を支えるための一言はナッジングという呼び名もついているらしい。HIGH OUTPUT MANAGEMENT でアンディ・グローブも nudge することの重要性を書いていた。振る舞い方を間違うと嫌なマネージャーに見えがちな仕事だけれど、かつての同僚を見習って上手に nudge する人でいたい。

実装を直すのじゃなくて問題が起きないように直す

  • ARTICLES
文字列からリンクで開いて次のページへ進むというのが必要な場面で文字列が空のためリンクがクリックできず、意図した動作ができないというバグがあった。 実装をそのまま修正すると、 if name.present? link_to name, some_path(object) else link_to another_name, some_path(object) end てなかんじで、起きたバグに対処するように直す。 でも、自分で開発しているときはこういうのは不安があって、そもそも name が空文字や nil だというのも自分が想定してなかったからバグが出ている。 どうせ修正をするなら、ここでけして同じ種類の問題が起きないように直したい。 ということで、こんな風に直す。 name_candidates = [name, another_name, 'fallback name'] visible_name = name_candidates.find {|n| n.to_s.length > 0 } link_to visible_name, some_path(object) ここでの問題は実装上は present? かどうかというものだったけれど、意味上は空文字列だと表示がされずリンクが有効に働かないということ。なので、その問題を解消するようなコードにしておく。 これで、絶対に同種の問題は起きない修正になったと安心できる。 「fallback name となってしまうケースがそのまま表示され次に進めていいのか」というのはまた別の問題としてあって、それをケアするのならまた別のそれに適した場所で対応をしてやるといい。 細かい話ではあるんだけど、わりと「実装上のつじつまはあってる」というコードで push されているコードをよくみるので書いてみた。

Netlifyで Deploy previews に認証をかけたい

  • ARTICLES
仕事で聞く要望のうちいくつかは CMS 使うほうが今後のメンテが楽そうだなと感じる機会がよくある。Hugo でサイトを構築するとして、動かすのはなるべく楽に面倒見ずにすませたい。でも独自ドメインだったりある程度機能は求めたい。というわがままを Netlify なら叶えてくれるんじゃないかということで Netlify を試している。 その中で、本番はいいんだけど動作確認用の環境をどうしようかなーというので迷って Deploy previews で対応したことの記録。結論には Business plan で有効になる site access control by roles が必要なので仕事とはいえお金は Pro までしかかけられないという場合は使えないけど、そういうときはトレードオフで URL がばれなきゃいいっしょの精神でいけばいいと思う。 なお、同じ会社で Netlifyが仕事で使えるか試す(追記あり) という方法でやっている話へのアンサーソングでもある。 やりたいこと まずやりたいことから。 Netlify で動作確認をする環境は public に見える状態を避けたい Netlify を使う動機がリポジトリをつくったらあとはなるべく環境構築やその後のデプロイの手間をかけたくないというものなので手間かけたくない 本番となるべく近い形で動作の確認をしたい 考えてたこと 同じ会社で同僚が似たことをやっていたのでまずはその repo を見たり、軽く話を聞いたりしてたんだけど、好みからいくと本人も書いているとおり “しかし、Productionはデプロイの方法を別で作っておかないといけないという面倒なことになってしまう。つらいね。” についてはだいぶ後で嫌になりそうで回避したいなと感じたのと、Heroku で Review Apps の便利さを享受したことのある身としてはぜひ Deploy previews を活かしてやりたい。そして、環境に応じたあれこれをビルド時に考慮してやれば稼働環境は同一でいけそうな気がするので Selective Password Protection のやり方は筋がよさそうに感じる (というか Basic 認証ならこれでいい)。 ということで、 Identity と Visitor Access Control を使ってやってみた。 やってみたこと Makefile じゃなくて rake でやりたいなーとごちゃごちゃやった結果、 Makefile で書くのが一番シンプルだったというサンプル があるのでこのコードを見ながらやってみたことを解説。