はてなブックマーク

Mermaid Graphical Editor VSCodeの拡張機能です。 Mermaid記法を利用してマークダウン内部で作図しながら、Mermaidそれ自体のエディタを立ち上げることができます。 逆にMermaid Editor側で編集した内容もマークダウンにフィードバックされます。 vs Draw.io Integration 類似ツールとしてDraw.io Integrationがあります。 こちらは.drawio拡張子のファイルをVSCodeで作成すると、draw.ioのエディタが開いて作図ができるツールです。 しかし、draw.ioはあくまで図が書けるところを生業としていて、作成したdraw.ioファイルをマークダウンファイルに埋め込むには画像としてexportが必要です。 できれば自分はマークダウン以外のファイルを作らず、一つのマークダウンファイルだけで完結したいと思ってま

type-challengesは型システムの仕組みをより深く理解し、独自のユーティリティを記述したり、あるいは単に型パズルを楽しんだりできるOSSプロジェクトです。 とはいえ、いきなりtype-challengesに挑むと挫折します。少なくとも私がそうでした。 なので、この記事ではまず最初にtype-challengesを解くために必要なTypeScriptの知識を解説します。 その後、実際にtype-challengesの問題を解いてみることで、座学→実践という形式でTypeScriptの型システムを学ぶことを目指します。 この記事は「一度はTypeScriptの公式ドキュメントやサバイバルTypeScriptを通して読んだけど、実際にコードを書こうとすると手が動かん…」[1]という方向けです。[2] なのでRe:です。 今回は初級編です。今後も何回かに分けて中級編、上級編と続けていく予

type-challengesをやってるときの、ナニコレ シリーズです。前回はこれでした。 今回もやっていきます。前回同様、「あーなるほどね」となった方や「またinferの話か、どんだけこすんねん」となった方はわざわざ読む必要がない記事っぽいです。 手っ取り早く何か知りたい人・答え合わせしたい人 私が解説せずとも、ドキュメントで似たような使い方をちゃんと説明してくれているので、そっちを読むのが正解です。 extends この文を読んでくださってる方は興味を持ってくださった方ですね。ありがとうございます。順を追って説明していきます。 まずはextendsからです。これも公式ドキュメントを読むのが一番いいのですが、Conditional Type Constraintsというヤツです。 使い方はConditional Type Constraintsという名前通り、型を条件分岐して決めたい場合

使い方 拡張機能をインストール後、アイコンをクリックして表示されるテキストエリアに、存在をお知らせしてほしいconnpassユーザーのIDを改行して入力します。 connpassユーザーIDはプロフィールページに(xxx)と表示されているものです。 入力後、保存ボタンを押せば準備OKです。 あとはconnpassのイベントページから、参加者一覧ページに移動した時に保存したユーザーがいた場合はこんな風にAlertでお知らせしてくれるようになります。 拡張機能のインストール chrome ウェブストアは公開審査中です。 「公開される前から使いたい！」って人はGitHubからソースをcloneしてchrome:https://extensions/から「パッケージ化されていない拡張機能を読み込む」を選んでcloneしたリポジトリのsrcフォルダを読み込ませて使ってみてください。 想定場面 使い方の想定として

誰しもLaravelのbladeでformを書くにあたって、@csrfという魔法の呪文を書いたことがあるかと思います。 「これを書いておけばCSRF対策はOK」 ドキュメントにも要約するとそういう旨が書いてあります。 この記事では@csrfについてLaravelの実装を実際に見てみることで、CSRFとその対策への理解を深めたいと思います。 ちなみにこの記事はぺちこん2024で残念ながら採択に至らなかったCfPの供養です。[1] 利用するサンプルアプリ @csrf はなにをしているのか？ そもそもですが、@csrfが何をしているのかを見てみます。 bladeに@csrfを埋め込んだ場所を、HTML変換後の状態から見てみます。 <input type="hidden" name="_token" value="G5FzKXaCYA4w8kdWbftEZMYoglQgD9yPIG9r2zzx"

導入 ローカルの開発環境は各々のマシンに直接構築し、STGや本番はコンテナの上で動かす。 こういった構成を取ることは珍しくありません。 あるいは、開発用にいろいろライブラリを入れたDockerfileと、本番用に最小限のライブラリのみを入れた構成を取ることもあるでしょう。 このような場合はいずれにしても、Dockerfileを書くということからは逃れられません。 今回は、 ローカルの開発環境は各々のマシンに直接構築し、STGや本番はコンテナの上で動かす。 という場合に、Dockerfileを開発者が書かずにCloud Runへコンテナイメージをデプロイし、アプリケーションを動かす技術について、実践してみた経験を書いてみようと思います。 アプリケーション 今回はnode.jsのv.20.11.0で動くNest.js10系のアプリケーションを動かしていました。 元のソースは諸事情で詳しい内容は

Dockerは公式にDockerfileのベストプラクティスを表明しています。 が、このベストプラクティスに沿っているかどうか？を人間がいちいちレビューしていくのは正直しんどい、というか現実的ではない… そこで「せや！静的解析したろ！」という時に便利なのがhadolintというライブラリです。 使ってみる 今回はVSCode拡張機能とGHAのCI時に静的解析してもらいたいと思います。 今回はちょうどメンテナンスしていない自分のリポジトリがあるので、これに対して静的解析をかけていきます。 まずはVSCode拡張機能で利用するための下準備として、hadolint本体をOSにインストールします。 Macの場合はこちら。 docker/php/Dockerfile:8 DL3008 warning: Pin versions in apt get install. Instead of `apt-

TL;DR Fake SMTP について MailHog と mailpit の機能差について maiplit の機能について(メール送信,API,SMTPS,SMTP_AUTH の検証) 今回の検証用ソースはこちらです。 Fake SMTP について Fake SMTP はメール送信テストの際に有用です。 わざわざテスト用の SMTP サーバーをレンタルしたりする必要がなくなります。 また実際にメール送信をするわけではないので、テスト時に誤って本番メールアドレスへ送信するという事態を防ぐことができます。 Fake SMTP の仕組みとしてはざっくり以下のような感じです。 メール送信 実際にメール送信が行われるのではなく、Fake SMTP で設定したストレージにメールが保存される そのストレージに保存したメールをブラウザもしくは API 等から確認できる 製品としては以下のようなものが有

システムコールの問題点 シンプルに遅い 特定のバイト単位でしか入出力できない stdio システムコールの問題点を解決してくれるのがコイツ。 では、どのように解決してるのか？という話。 バッファ システムコールで読み書きするデータを一時的に保存しておく場所のこと。 stdioはバッファに対して読み書きの指示を出すことで、汎用性を上げている。 読み 読みの場合は、ディスクからバッファに塊で書き出したデータを、「1バイトとか10バイトとかの単位でちょーだい」と命令することで読み込める。 システムコールも別に1バイト単位で読めるけど、遅いという問題があるので現実的じゃない。 書き 書き込みの場合、バッファに書き込んでから一定の単位でシステムコールのwrite()を呼ぶ。 一定の単位というのがミソで、これはストリームの向こうにターミナル(端末)がある場合は改行単位になるだろうし、ファイルがある場合

手を動かしながら、Vitestの使い方を学ぼう！

自分自身を一つの製品と見なし、段階的にレベルアップしよう！購入者特典としてDiscordサーバーへの招待コードを付与しています。

TL;DR 最近チーム内で、mergeではなくrebaseを推奨する動きが出てきたので、この機会に rebase の動きをちゃんと理解しておこうという足跡です。 merge の動きを確認する まず、merge_aというブランチを作成し、一つコミットを作ります。 次にmerge_bというブランチを作成し、一つコミットを作ります。 再びmerge_aブランチに戻り、一つコミットを作ります。 ここで、merge_aにmerge_bをマージします。 すると以上のようにマージコミットが作成され、コミットの時系列の順にブランチが並びました。 rebase の動きを確認する まず、rebase_aというブランチを作成し、一つコミットを作ります。 次にrebase_bというブランチを作成し、一つコミットを作ります。 再びrebase_aブランチに戻り、一つコミットを作ります。 ここで b をベースにリベー

TL;DR こちらのツイートで紹介されていた内容が気になったので、紹介されていた内容 8 選を翻訳するとともに、自分でも試した結果を共有しようと思います。 Google Bard はこちらから 1. 2021 年 9 月以降の情報にも応えてくれる ChatGPT は 2021 年 9 月までの情報しか教えてくれませんが、Bard は直近のニュース内容にも対応しています。 2. 音声入力 ChatGPT はテキスト入力のみですが Bard は音声入力にも対応しています。 3. Google ドキュメントまたは Gmail へ 2 クリックでエクスポート可能 例えば Gmail へエクスポートするとこんな感じです。 4. URL を渡すと Web ページの内容を要約してくれる 例えばこのページの URL を渡すとします。 結果はこんな感じです。 5. 複数の下書き案を提供してくれる 「他の回答

はじめに idea カテゴリで投稿するか迷いましたが、一応 ChatGPT へリクエストを投げる GAS のコードも紹介しているので、tech 記事で投稿することにしました。 ほしかったもの Qiita には急上昇記事を紹介する公式アカウントが存在しています。 が、Zenn には公式のそれが存在していませんでした。 一応公式アカウントがピックアップとして紹介しているものの、おそらく手動。(そう思うのは、GW 前から更新が止まっているから) とにかく一番欲しかったものは、Zenn の人気記事を数時間間隔で教えてくれるなにかでした。 そしてどうせなら Qiita の記事も紹介する機能をつけようと思いました。 "なにか"には Slack や LINE bot という選択肢があったのですが、しかし単に記事だけを紹介しつづける無機質な bot は可愛くないと思っていました。 せっかく"私"が作るのな

はじめに この記事は、「Laravel considered harmful」という英文記事に書かれている18 個の Laravel の有害な習慣のうち、個人的に関心を持った一部を抜粋・翻訳[1]し、私見を交えたものです。 この記事の主題は原文記事からいただき、副題は日本語で翻訳し私見を踏まえた上での原文記事の要約的なものをつけさせていただきました。 注意点として、この記事の中では原文に沿った形で harmful="有害な"という表現で通していますが、記事タイトルとしては攻撃的すぎると思い、かなり意訳ですが"イマイチな"とさせていただいています。 原文記事は結構 Laravel に対して痛烈なことを書いているのですが、個人的には「まあせやな…」となる内容かなとは思います。 特に、オブジェクト指向について理解が浅い状態で Laravel を使っているな、という自覚がある方にとってはぜひ知って