投稿者「byebyehaikikyou」のアーカイブ

byebyehaikikyou について

日記やIT系関連のネタ、WordPressに関することなど様々な事柄を書き付けた雑記です。ITエンジニア経験があるのでプログラミングに関することなどが多いです。

「アマゾンの最強の働き方」を読んだ

書店で見かけ気になったので購入して読んだ。数々のイノベーションを起こしてきたアマゾンではどのような働き方を実践しているのか、自分の職場や働き方をアップデートするヒントを得たい、というのが本書に向き合うモチベーションだ。

アマゾンといえば、「地球上で最もお客様を大切にする企業になる」という企業理念で知られている。多くの企業がマインド・アイデンディティである『企業理念』なるものを掲げているが、なかなか組織の活動や意思決定プロセスの細部まで、組織メンバーの大勢が徹底して実践できている企業は多くはないのではなかろうか。本書を読んで強く印象に残ったのは、理念を具体化した行動規範である「リーダーシップ・プリンシパル」があらゆる仕事とプロセスで実践されている、ということだ。バリューとも言えるだろうか。これは、一朝一夕で成されるものでなく、長い年月をかけて築き上げられるものである。こうして積みあげられた組織カルチャーが模倣困難性を高め、持続的な優位性の獲得につながっているのだと感じる。もちろん、AWSのような巨大なクラウドコンピューティングサービスを実現する技術もとんでもなくすごい。

本書では、現在アマゾンで展開されている、または、立ち上がったものの軌道にのることができなかった事業やサービスについて、実際に立ち上げに関わった著者の視点で当時の状況が説明されている。意思決定のプロセス、失敗に学ぶ姿勢など、まさにリーダーシップ・プリンシパルが実践されている様を感じとることができる。徹底的なこだわり、顧客志向の考え方など、学ベることが多い。

本書の中で、私が仕事の中ですぐに実践していきたいコミュニケーション手法の1つにナラティブ形式による資料というものがあった。1つは、有名な6ページ資料、もう1つは顧客ニーズを起点として新商品開発を行うワーキング・バックワーズである。いずれの手法も、練りに練られた思考を凝集し言語化したアウトプットの塊が成果物である。パワーポイントのような資料は一本道でストーリーを語るには適しているかもしれないが、深い思考を伴う検討が必要なプロセスにおいてはナラティブ形式が適しているというものらしい。このナラティブ形式のアイデア元は、イエール大学エドワード・タフテ教授の論文と記されている。私も企画でアイデア出しに関わることがある。パワーポイントのようなストーリーを語る形式とナラティブ形式を状況に合わせて使い分けていきたい。

 

Node.jsでumzug+SequelizeによるDBマイグレーション

今回は、Node.jsでデータベースマイグレーションツールであるumzugについて整理したいと思います。umzugを使うと、アプリケーション内やコマンドラインからDBマイグレーションを実行するプログラムを作成することができます。

Sequelizeのmigration

Node.jsのORMとして有名なOSSの1つとしてSequelizeがあります。そして、sequelizeにはsequelize-cliというコマンドラインインターフェースがあり、初期データを投入するためのseedや、データベースのスキーマ移行をするためのmigrationがあります。ただ、sequelize-cliが生成してくれるテンプレートはJavaScriptであり、私がGitHubを眺めていた時点では(本記事作成時点)TypeScriptへの対応はまだされていないようでした。

例えば、以下のようになコマンドでUser modelを生成してみます。

生成されたUser modelの中身は以下のようになっています。

sequelize-cliをtypescript対応にしているnpmパッケージもありましたが、あまり更新が活発ではないようでした。

umzug

umzugは、sequelize-cliの内部で使われているマイグレーションツールフレームワークです。sequelize-cliのソースを見ると、マイグレーション実行部分はumzugが担っていることが分かります。sequelize-cliは、umzugを使いやすくしたツールと言えます。umzugはTypeScriptに対応しています。

テスト環境の準備

手元の環境は以下の通りです。

OS macOS Catalina 10.15.7
Node.js v16.13.2
sequelize 6.17.0
sequelize-cli 6.4.1
umzug 3.0.0
TypeScript 4.5.5
ts-node 10.5.0
sqlite3 5.0.2

テスト環境の初期化

テスト環境の初期化を行ないます。今回は、ts-nodeを使ってTypeScriptコードをNode.jsから実行できるようにします。

こんなコードを書いて、実行できることを確認しておきます。

ついでにpackage.jsonに書いて、npm runできるようにしておきます。

npm  runコマンドを実行してみます。

よさそうです。

最小サンプル

雰囲気を掴むため、小さなサンプルを見てみたいと思います。以下は、GitHubに掲載されているサンプルと同じです。

  • Sequelizeインスタンスを作成
  • UmzugのsequelizeインスタンスをDBドライバとして渡す
  • upで上位レベルに向かってマイグレーションを実行

migrationsディレクトリが空でも実行可能です。実行すると以下のような結果になります。

SequelizeMetaはマイグレーションのメタデータを管理するテーブルです。

TypeScriptファイルの雛形からマイグレーションファイルを生成する

続いて、TypeScriptでマイグレーションファイルを生成するようにしてみます。

migrate.tsファイルを以下のように書き換えます。

違いは、以下の2点です。

  • Umzugの引数にcreateプロパティを追加
  • umzug.up()をrunAsCLI()に変更

runAsCLI()は、umzug ver3で使用可能なcli実行インターフェースです。こうしておくことで、npm run migrate create -- --name setup.tsのように引数を渡してumzugに渡して実行することができます。

テンプレートファイルは以下のようにしてみます。

では、migrateターゲットでcreateコマンドを実行してみます。

migrationsディレクトリにsetup.tsファイルが作成されることを確認できます。

ついでに、usersテーブルを作成するマイグレーションを実行してみましょう。

生成したsetupマイグレーションファイルを上記のように修正します。そして、再びマイグレーションを実行します。

無事にusersテーブルが作成されました。

マイグレーションファイルのOrder

辞書でソートされた順にファイルが読み込まれる。タイムスタンプをプリフィックスに元ファイル名にすると良いと思います。

m1.js、m2、…、m10.jsの場合、m1.js、m10.js、…となります。m2.jsよりm10.jsが先にくるということになります。

その他の使用方法

GitHubの公式のドキュメントを見ながら試してみましょう。マイグレーションフォルダには2つの定義を入れています。

ペンディング中のマイグレーションの取得

pendingコマンドを実行します。

未適用の2件が表示されます。

適用済みのマイグレーションの取得

executedコマンドの実行前にDBを空にして、upコマンド実行後に再度executedコマンドを実行してみます。

マイグレーション実行後に2件の適用済みリストが表示されます。

マイグレーションの巻き戻し

最後に適用したマイグレーションを巻き戻してみます。

最後に適用したaddColumnsToUserTableが打ち消されます。

まとめ

  • umzugを使うと、Sequelizeを使ったDBマイグレーションのプログラムを独自に実装できます。
  • umzug#runAsCLI()を使うと、コマンドラインのマイグレーションプログラムを容易に実行することができます。

参考リンク

crop faceless developer working on software code on laptop

Nuxt3をさわってみる

Nuxt3はbeta版になっている、Nuxt3の雰囲気をつかむためインストールから起動するところまでやってみる。

インストール

nuxiという新しいCLIを使う。

nuxiについて、プロジェクトのトップでinfoコマンドを実行してみる。

ディレクトリ構造

initした直後は以下の感じ。Nuxt2までのようなlayoutsやpagesのようなディレクトリがなく、プロジェクト作成直後はとてもすっきりしている。

ドキュメントを見ると、今までのようなlayoutsやpagesといったディレクトリは、Nuxt3でも有効であることが分かる。これらは、アプリの特性に合わせて作成すればよいのだと思う。なお、ディレクトリについては、pluginsディレクトリ下のプラグインファイルが自動で読み込まれるなど新しい点もあるので注意したい。

参考リンク

アプリ起動

この状態でrun devするとWelcomeビューが表示される。 

httpsオプションで自己署名証明書を使ってhttpsモードで起動ができる。Nuxt2では、nuxt.configのserverオプションで指定していたと思うけれど、この辺りとても簡単になっている。

Welcomeビューを変更するには、app.vueを編集するか、pages/index.vueのような新たなビューを作る。

srcDirの変更

公式ドキュメントにあるようなclientの下にアプリリソースを配置する構成にしてみる。ディレクトリを作成し、nuxt.configのsrcDirにclientリソースを格納するディレクトリを指定、そして今ままでのようなlayoutsやpagesにビューを作成する。

上記の変更を加え、改めてrun devしてみると以下のように作成したビューが表示されることを確認できる。

 

参考リンク

開発業務から企画開発業務になる

最近は企画開発業務に携わるようになった。今まで、現場でインフラやアプリケーション開発エンジニアとして過ごしてきたので、慣れない業務にシフトしてあたふたしている。年齢的には良いチャレンジのタイミングでもある。重要なのは、自分の意志でやりたいこと、である。

期待されていることの最終的なゴールのイメージはついているが、グループメンバと同じ方向を向いて、同じ目線で深堀りしながら議論や検討を重ねていくには、私自身のスキル不足を感じる。コミュニケーション、ファシリテーション、良い問立て、課題設定、仮説構築、いろいろ。プロセスやアウトプットの基準を整えてレールを敷かなれば、なかなか前に進みづらい。決済権を有する関係者とのしっかりとした対話も必要だ。

進め方を試行錯誤しているが、やり方の見直しが必要だ。先人の知見とノウハウに学ぼう。

インプットした書籍

とても分かりやすい。アイデア発想法から事業計画作成までの流れが網羅されている。流れや各フェーズでのアウトプットもイメージがつきやすい。事業計画書のテンプレもついているので、状況に合わせてカスタマイズしていけるだろう。ビジネスモデルキャンバスについても説明がある。アイデア発想のためのフレームワークなどを重視したい場合は、別の書籍にもあたるのが良いと感じた。

シンプルでとても分かりやすい。企画の前の段階で確認しておくべきことについても触れられている。特に社内で企画に関わる人にとっては重要なポイントだと思う。また、アイデア発想のための思考フレームワークや効果についても整理されていて、こんな切り口で考えを整理したいときにどの考え方が使えるだろう?、といったニーズにマッチするだろう。思考の切り口に悩んでいる人には有用だと感じた。事業計画や計画書に網羅すべき点の詳細を知りたい場合は、別の書籍にもあたるのが良いと感じた。

こちらはフレームワークを中心に知りたい人向け。フレームワークの種類をたくさん説明しているというより、フレームワークのタイプを体系化して説明してくれている感じである。フレームワークに沿うと思考が整理しやすくなる。ただ、フレームワークの型に沿って必要な項目を埋めていけば、良い分析ができるかというとそうはならない。フレームワークはあくまで思考を整理しやすくするためのツール。フレームワークの背景にある考え方や有用なケースを知っていれば、うまくツールを使いこなせる。今まで、背景にある考え方を説明している書はあまり見てこなかったので、本書は大変参考になった。フレームワークのタイプを体系化しているので、フレームワークを組み合わせたり、自身で応用したりもできるだろう。

世の中のビジネスモデルを知るのに良い。普段目にしているサービスや事業がどんなビジネスモデルになっているのか俯瞰できる。本書では、戦略モデルキャンバスというフレームワークが紹介されている。ビジネスモデルキャンバスに、コンテキストという要素が追加されている。コンテキストには、ビジネスモデルが成立するための妥当性と正当性を書く、となっている。モデル成功の前提を書く、というものであり思考を整理しやすくなっている。

Mattermost Dockerのconfig.jsonの指定

Mattermostのdockerコンテナで、mattermostコマンドを使って設定更新操作を行なうと、あらかじめ作成しておいたconfig.jsonが何故が初期化されてしまう事象に遭遇してしまった、??。(再現性を確認できていないが、pluginをenableやdeleteして何らかのschedulerが動くタイミングで発生している?)

そこで、本記事ではMattermostの設定方法について整理する。

本動作検証バージョンはv5.37.4である。

MattermostのConfiguration

Mattermostは、設定情報をconfig.jsonファイルで管理する。通常、mattermost/configディレクトリにあるconfig.jsonファイルが対象となる。環境変数MM_CONFIGでconfig.jsonファイルのパスを指定することもできる。設定情報は、System Consoleや直接ファイルを編集することで更新できる。設定を更新するとconfigの変更を検知してリロードしてくれる。

v.5.10からはデータベースで構成管理をすることができる。

ファイルで管理する場合

環境変数MM_CONFIGにconfig.jsonファイルのパスを指定する。指定がない場合は、config/config.jsonが対象となる。

ローカルテスト環境で起動する場合は、以下のようにする。Dockerコンテナ環境が必要である。macであれば、Docker Desktop For Mac(個人利用は無料:ライセンスは公式を確認のこと)を使うとよいだろう。

参考:Setting up Your Development Environment – Mattermost

データベースで管理する場合

MM_CONFIGにDatabase DSNを指定する。mysqlの場合は以下のようになる。

参考:Configuration in the Mattermost Database

起動時にカスタムのデフォルト設定を適用したい場合は、以下の環境変数を指定する。

現在有効な設定はデーターベースに接続して確認できる。

mattermostコマンドでconfigを更新してみる。

データベースのConfigurationsのレコード件数を見ると新たにレコードが増えていることが分かる。

値も反映されている。

configファイルの変更検知を停止する

Mattermostでは、構成の変更を検知するconfig watcherが動いており、構成情報の変更を検知して反映する。本機能を止めるには、以下のオプションを起動時に指定する。

config watcherを停止して何度かmattermostコマンドでpluginのenable/deleteを繰り返した限りでは、config.jsonの予期せぬ上書きに遭遇はしなかった。

なお、v5.38からはconfig.jsonの自動リロードはDeprecatedとなっているようである。設定のリロードは、mmctlコマンドで明示的に行なう、となっている。(以下リンクより)

参考:Configuration Settings

今後は、configの変更後、mmctlコマンド(mmctl config reload)で反映という手順になるのであろう。

なお、config watcherを停止した場合、configの変更はmmctlコマンドでリロードしないと反映されなかった。これは、データベース管理でも同様であった。config watcherを停止した場合は、反映漏れがないように気をつけたい。

参考