はてなブックマーク

はじめに この記事では、次のような構成で Vue 3 開発を行うためのセットアップ手順について紹介します。 言語: TypeScript ビルドツール: Vite UI フレームワーク: Quasar Quasar とは Vue 3 に対応した Material Design の UI フレームワークです。 「パフォーマンス重視」を謳っていることが特徴のようです。 同じく Vue 用の Material Design UI フレームワークとしては Vuetify が人気ですが、Quasar もそれに負けないくらいの機能を持っておりドキュメントも充実しています (日本語のドキュメントはありません)。 また、Vuetify に比べるとかなり早く Vue 3 に対応できている1点も魅力です。 ちなみに便宜上ここでは UI フレームワークとして紹介しましたが、実際には UI コンポーネントつきの

VSCode Remote Containers とは Docker コンテナを開発環境として使用するための VSCode 拡張機能です。 コンテナ内に開発環境を構築することで、PC の環境を汚さずにプロジェクトごとに言語やツールを使い分けることができます。 また、Dockerfile で開発環境を定義できるためチーム内で開発環境を共有することが容易になります。 Qiita 等に紹介記事がたくさんあるため詳しい説明や使い方については割愛します。 DevContainer と dotfiles ※ この記事では VSCode Remote Container で接続している開発用のコンテナのことを DevContainer と呼称します DevContainer で開発するということは当然 DevContainer の shell 環境を使用することになります。 デフォルトの状態の shel

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

何番煎じかわかりませんが TypeScript でのエラーハンドリングについて考えてみたいと思います。 この記事で扱う TypeScript のバージョンは 4.3 です。 エラーを型安全に扱いたい TypeScript を書いていれば誰もが一度はぶつかる問題ではないでしょうか。 TypeScript では catch した例外は any として扱われます。 これは JavaScript の仕様上どんな値でも throw できてしまうため仕方のないことなのですが、せっかく型安全性を手に入れるために TypeScript を使っているのに any をハンドリングしなければならないのは苦痛です。 次のように例外を throw し得る関数 foo() のエラーハンドリングを考えてみます。

VScode Remote Containers の新機能 Dev container features について紹介します。 VSCode Remote Containers とは Docker コンテナを開発環境として使用するための VSCode 拡張機能です。 コンテナ内に開発環境を構築することで、PC の環境を汚さずにプロジェクトごとに言語やツールを使い分けることができます。 また、Dockerfile で開発環境を定義できるためチーム内で開発環境を共有することが容易になります。 Qiita 等に紹介記事がたくさんあるため詳しい説明や使い方については割愛します。 Dev container features とは 9月のアップデート (VSCode v1.61, Remote - Containers v0.202) で追加された新機能 (preview) です。 2022-11-

表題の件について私見を述べていきます。あくまでも私見です。 そもそもエディタや IDE 固有の設定ファイルをリポジトリに入れるべきなのか 個人的には用法をしっかりと守った上でなら入れてしまって良いと思っています。 入れたところで他のエディタや IDE の害になるわけではないですし、ファイルサイズも知れたものなのであまりデメリットはないように思います。 逆に入れないことでチームメンバーが各々似たような設定をローカルで書くことになってしまうのは労力の無駄です。 特に同じエディタ・IDE を使用している人が多いチームではなるべく設定ファイルを共有してしまった方が良いのではないでしょうか。 エディタ・IDE 設定をリポジトリに入れるときに守るべき原則 基本的には「チームの利益になるものだけを入れろ」ということになるかと思います。 「個人のための設定は入れるな」と言い換えることもできます。 他の開発

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

シンプルな Slack Bot を Go 言語で作ってみます。 順を追って作り方を解説していくので「サンプルコードだけ見たいよ」という方は こちら に記載されているものをご参照ください。 作るもの 下図のように Bot に対しメンションをつけて ping と送ると pong と返してくれるだけのシンプルなものです。 Slack からのイベント受信には Events API を使用します。同様に Slack からのイベントを受信する方法としては WebSocket でやり取りする RTM API があり、こちらであれば App 側から Slack に接続しにいくのでサーバーの公開が不要でお手軽なのですが、現在は Events API の方を使用することが推奨されているようです(こちらの記事 が参考になります)。 Slack App 作成 & 準備 まずはこちらの URL を開き、Create

やりたいこと Markdown を PDF にしたい 文章は日本語で書きたい 自動で表紙を生成したい 見出しから自動で目次を生成したい 見出しを自動で採番したい コードブロックをそれなりの見た目で表示したい PlantUML を画像に変換して埋め込みたい 環境構築が楽な方法が良い 最終的に CI に組み込みたい 方法 変換自体はいくつかの手段がありそうでしたが、表紙や目次を自動生成するとなると Pandoc が良さそうです。 ただ、上記のような要求を満たそうとすると環境構築がそれなりに面倒そう (+ CI に組み込むのが難しそう) だったので、必要なものを突っ込んだ Docker イメージ を作りました。 作成した Docker イメージ frozenbonito/pandoc-eisvogel-ja 特徴 ベースイメージ 公式の pandoc/latex イメージをベースにしています。a

Go で Slack Bot を作る (2020年3月版) の続編です。今回は Interactive Message を活用してちょっとリッチな Slack Bot を作っていきます。 順を追って作り方を解説していくので「サンプルコードだけ見たいよ」という方は 「まとめ」 に記載されているものをご参照ください。 作るもの 今回は ChatOps を意識した Bot を作ります。 下図のように Bot に deploy と命じると、デプロイするバージョンの候補がセレクトメニューで提示されます。 バージョンを選択すると確認メッセージが表示されます。 Do it を選ぶと Bot からデプロイの開始が通知され、その後デプロイ終了が通知されます。 準備 準備として次の作業を行っておきます。 Go で Slack Bot を作る (2020年3月版)#Slack App 作成 & 準備 Go で

シンプルな GitHub App (Bot) を Go 言語で作ってみます。 順を追って作り方を解説していくので「サンプルコードだけ見たいよ」という方は「まとめ」に記載されているものをご参照ください。 作るもの 下図のように Issue を作成すると hello, ${username} と反応してくれる Bot を作ります。 準備 GitHub に動作確認用のリポジトリを作っておきしょう。 また、GitHub から Webhook イベントを受け取る必要があるので、パブリックアクセス可能な URL が必要です。 今回は開発しながら適宜動作確認が行えるように ngrok というプロキシサービスを利用してローカル開発マシンのポートをインターネットに公開することにします。 こちら から ngrok へのユーザ登録を行います。 登録後、セットアップ方法の案内が表示されるのでそれに従ってセットアッ