Railsチュートリアルのsample_appに型を導入
ふーが といいます。普段は Ruby on Rails を利用したアプリケーション開発をしているプログラマです。 この記事は Rails アプリケーションへの型導入を試してもらうことを目的とした記事です。主に Ruby on Rails チュートリアル （以下「Rails チュートリアル」と呼称）で学ばれた方向けに「静的型とはなにか」「Ruby での型の扱い」「Rails アプリケーションへの型導入方法」を知っていただくきっかけになればうれしく思います。 この記事では実際に手を動かしながら Rails アプリケーションに型を導入する手順を体験できます。題材として Rails チュートリアルの sample_app を使用させていただいています。 前提 型を導入するにあたり前提となる部分を簡単にご紹介します。「型」と聞いてイメージがつく方はこの段落は飛ばしていただいてかまいません。 型とは何
@ts-expect-errorを自動追加！suppress-ts-errorsの紹介
TypeScript の型チェックを厳格化したいが既存の型エラーが多すぎて、やむなく緩い型チェックにしている方へ改善の助けになりそうなツールを作ったので紹介です。 🔧 作ったもの プロジェクトのコードベースを走査して、型エラーがあるコードすべてに@ts-expect-error or @ts-ignoreのコメントを追加する suppress-ts-errors という CLI ツールを作りました。 以下の GIF のように npx 経由で簡単に利用できます。 さらに、ts、tsx だけでなくVue SFC のスクリプト部分へのコメント追加にも対応しています。 コードはこちらです。⭐ を貰えると泣いて喜びます。 なぜ作った？ 現職のプロジェクトにて型チェックを厳格化できていない（strict: trueにできていない）という状況を改善したいと思ったからです。 型チェックのルールを修正する
ブラウザの要素をクリックするだけでRailsのviewファイルを簡単に開くことの出来るrails-template-inspectorの紹介
<!DOCTYPE html> <html> <head> <!-- ... --> </head> <body> <%= yield %> <% if Rails.env.development? %> <script type="module" src="https://cdn.skypack.dev/@aki77/rails-template-inspector"></script> <rails-inspector url-prefix="vscode://file" root="<%= Rails.root %>" combo-key="command-shift-v"></rails-inspector> <% end %> </body> </html> エディタを開く仕組みとしてはCustom URL Schemeを利用しています。 <rails-inspector>要素の
Web 技術解体新書「第二章 Cache 解体新書」リリース
Web 技術解体新書「第二章 Cache 解体新書」リリース Intro 「Web 技術解体新書(Web Anatomia)」の第二章として「Cache 解体新書(Cache Anatomia)」をリリースしました。 これで予定している八章のうち二章が終わりました。 第一章: Origin 解体新書 第二章: Cache 解体新書 Cache 解体新書 以下の Response Header Field がどういう意味を持つか正確に説明できますか? おそらく多くの Web 開発者が一度は見たことがあり、これを「1 時間キャッシュする」という意味で指定している人もおおいでしょう。 では、どこから 1 時間で、 1 時間経ったらなにが起こるのか、これが Response でなく Request に付与されたらどう変わるのか、きちんと把握できていますか? そもそも、一般的にキャッシュ機構における
GitHub Actionsの手動実行パラメータのUI改善について速報で解説する
11/10に突如素晴らしいアップデートが来たので、興奮冷めやらぬうちに公式よりちょっとだけ詳しい解説を書きます。 GitHub Actionsは素晴らしいCI/CDサービスであり、特にpush, pull-request, その他あらゆるGitHub上の行動をトリガーにしてワークフローを起動させる設定を簡単に書くことができます。しかし、手動でワークフローを起動させる機能の追加は他のトリガーに比べて後発でしたし、パラメータを入力するための機能やUIが少々貧弱と言わざるを得ないものでした。 一方、古より存在するJenkinsはpush, pull-requestなどの自動トリガーを設定するのは難易度が高かった[1]反面、手動でジョブを起動する機能やUIは充実していました。基本の自由テキスト以外に、プルダウンによる選択、booleanのチェックボックス、Jenkinsに登録したシークレットからの
2021年現在Vueを選択すべきでないと思う理由
使ってわかる、Vueへの恨み、つらつらと（随時更新） コンポーネントのローカルスコープでコンポーネントを定義しようとするとJSXが必要 JSXが嫌でReactを使わないならSvelteがあり、SvelteはゼロオーバーヘッドでVueより速い React+JSXと違って、マークアップをJavaScriptの式として扱えないせいで、TypeScriptとの相性も悪い 後述するが、コンポーネントのプロパティの型をジェネリックにできないところなどは、これの例にあたる Vueの新しい機能が出て、新しい構文を必要とするたびにIDEのプラグインの対応が必要になる JSXも構文拡張だが、JS関数呼び出しのシンタックスシュガーでしかないので、関数と同じだけの表現力（汎用性）を持ち、ReactのAPI拡張のためにいちいちJSXまで拡張する必要はない JSX無しだと、マークアップ内でアクセスしたいコンポーネント
GraphQL の Fragment Colocation について
TL;DR 考え方 コンポーネントとセットで、そのコンポーネントが必要なデータを Fragment で宣言する、React の宣言的 UI に合わせた宣言的データ取得（declarative data-fetching）という考え方 Component Scopedに取得データを宣言することで「そのコンポーネントで必要なデータはなにか」を管理しやすくなることで、under-fetching / over-fetching が抑制でき、変更にも強くなる お悩みポイント Fragment-scoped な変数を定義するための標準機構がない Relay は directive を利用した独自の機構を持つ 便利そうなライブラリ graphql-anywhere クエリ結果を Fragment の形に整形する not actively support apollo-link-fragment-arg
図で理解する Flexbox
Flexboxはレイアウト組む上でとても便利だが、justifyだとかalignだとか名前と意味の対応が曖昧で毎回調べていた。 仕組み・使い方を理解しようと思い、図を使って整理してみた。 ※ CSS Grid についても整理してみました Flexbox Flexboxは縦・横に要素を並べられるレイアウト方法です。 Flexboxを使うことにより、縦・横に並べるだけでなく、並べた要素の中央寄せ・上寄せなど細かな位置も調整できます。 コンテナ・アイテム Flexboxを使う上で必要となる要素が「Flexコンテナ」と「Flexアイテム」です。 Flexコンテナの中にFlexアイテムを複数並べてレイアウトします。 <div class="container"> <div class="item">１</div> <div class="item">２</div> <div class="item"
150万MAUのNuxt.js製サービスを機能開発を止めずに1ヶ月&1人でNext.jsに置き換えた話
Nuxt.js で開発されていたAI受診相談ユビーのフロントエンドを Next.js で作り直しました。 まだまだ仮説検証を繰り返すフェーズのスタートアップのため、機能開発を止めて一気に置き換えることはできず、機能ごとに少しずつ置き換えてリリースをしました。結果、5人のプロダクト開発チームによる機能開発と並走して、全体の移行を1人で1ヶ月の短期間で終わらせることができたので、その意思決定や過程、工夫を紹介します。 移行前の課題 まず前提として、移行前の Nuxt.js による実装は 2018 年に立ち上がったもので、当時 toC の Web サービスを持っていなかった Ubie が ほぼ 1 人の小さいチームで PoC 的に作り始めたものでした。また、当時の Next.js は今ほど多機能ではないプレーンなフレームワークでした。 これらを踏まえて、当時の状況で MVP を最速で作るための技
git gc の仕組みを原理から理解してサイズを 136MB → 7.2MB(95%減)まで削減した時の勉強メモ
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
GraphQLが解決する問題とその先のユースケース
サーバーサイドからみたGraphQL Serverlss Meetup#19 2021/03/31 に行われた Serverlss Meetup#19 で上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。 以下内容です。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。 GraphQL and me この1年書いたQiita記事 GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回話す事 そもそもGraphQLはなんで作られたのか、何を解決しようとして
GraphQL のクライアント導入におけるメリット享受レベル
GraphQL のメリットを享受するにあたって、いくつかの側面を適用しやすい順に段階的に考えることができると思ったので書き出してみる。 レベル 1: 型とドキュメントのある REST API GraphQL を利用すると最低でも勝手にこの状態になる。 ここでは、REST API からの移行を重視し、1つのクエリで必要なデータをすべて取ることにこだわらず、REST API を叩くのと同じ単位で GraphQL API を叩く。 例えば、今まで /users を叩いていたのであれば、それと同じ形で返ってくるように /graphql に query { users { id, name, etc } } というパラメータで同じタイミングで投げる。 これであれば、同等の REST API とサーバの負荷も同じで[1]、クライアントの実装変更も最低限に抑えつつ、型とドキュメントが得られる。 Grap
GitHub Actions でも [skip ci] が使えるようになりました
公式ブログ GitHub Actions: Skip pull request and push workflows with [skip ci] - GitHub Changelog コミットメッセージの内容から push と pull_request のワークフローをスキップできるようになりました。 push または pull request (PR) の HEAD コミットに [skip ci], [ci skip], [no ci], [skip actions], [actions skip] のいずれかが含まれる場合にワークフローがスキップされます。 検証 [skip ci] を例に検証します。 1. スキップする単一コミット ワークフローを作成。検証用のためトリガーは paths で絞ってあります。 [skip ci] というコミットメッセージで skip ブランチへコミット
![GitHub Actions でも [skip ci] が使えるようになりました](https://cdn-ak-scissors.b.st-hatena.com/image/square/36dbf96306ba8072bbcbab3c1d643b54ab95ebf4/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--xDnEYgLZ--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3AGitHub%252520Actions%252520%2525E3%252581%2525A7%2525E3%252582%252582%252520%25255Bskip%252520ci%25255D%252520%2525E3%252581%25258C%2525E4%2525BD%2525BF%2525E3%252581%252588%2525E3%252582%25258B%2525E3%252582%252588%2525E3%252581%252586%2525E3%252581%2525AB%2525E3%252581%2525AA%2525E3%252582%25258A%2525E3%252581%2525BE%2525E3%252581%252597%2525E3%252581%25259F%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3A%2525E9%25259B%2525AA%2525E7%25258C%2525AB%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2dsdnpGMmRXRHdxQlZmQ0hHd2Z6bV9PTW5YeTZjVElKVm1WOVV4Tmc9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
React テスト応用、テストに悩む人へ
2022-05-06 更新 「React でコンポーネントテストを書くといいらしい、 React Testing Library や jest でサンプルを参考に書いてみたが 現実どうやってプロダクトコードに合わせていけばいいか分からない」 そういった方が対象となる本を目指しています。 いろいろ調べて実践したものの下記のように感じた方に適しているかもしれません。 - 結局テストで何を担保しようとしているか分からない - React のテストでハマっているか、Jest でハマっているか分からない - モックとかスパイとかアプリケーションとは遠い出来事も多くてピンとこない 誤り・ご指摘あればフィードバックいただけると嬉しいです。 無料で配布していますが、気に入ったらサポートなどいただけると今後もこの本をアップデートし拡張していく気持ちになれるのでよろしくお願いします。
ReactやAngular、VueなどでComponentのスタイリング時に抑えておきたいこと
なんとなく自分の中で言語化しておきたかったので、整理も兼ねて記載しておきます🙆🏻♂️ 普段仕事で様々なAngular、またはReactのコンポーネントを作ったりメンバーから出るPRを読む中で、コンポーネントのスタイルはどういうふうに当てるのが破綻しにくいんだろうと考えていました🤔 Angularは良くも悪くも一つのComponentが結構おっきくなりがちだったのでそこまで意識しなかったですが、Reactは何なら分割しないと気持ち悪いとすら思えるくらいにコンポーネントを分割しやすいです。 コンポーネントを分割することは各ファイルごとに把握すべき事柄が減るので基本的にはいいことだと思っていますが、スタイリングについては意識しないと破綻してしまうなーと思っています。 （もちろん、スタイリングに限らず意識しないと破滅するんだけど、今回はスタイルについての話です） スタイルの破綻っていうのは
Mac を買ったら必ずやっておきたい初期設定を、全て自動化してみた
成果物 https://github.com/ulwlu/dotfiles/blob/master/system/macos.sh このスクリプトに全ての設定と、設定可能なオプションをコメントで記載しています。誰でもこのスクリプトのコメントを外したり任意の値を入れる事で使用可能です。 世界中のいくつかのdotfilesにはmacos.shが存在し、ある程度のMacOSの設定自動化を実現しています。しかし何百と見た中で、全設定と設定可能なオプションを全て網羅して記載しているのは恐らく初です。 これらの設定は破壊的なものではなく、いつかアプデによりキーが有効でなくなっても壊れる事はありません。壊れるのは~/ApplicationSupport/Dockディレクトリ配下のファイルを移動したり、sqlite群に無効な値をいれた時のみです（後述）。 この記事は何か dotfiles Advent C
"CSS Module" をめぐる混乱
"CSS Module" が指すもの ２つある 従来のコミュニティベースのもの これのこと。そしてその実装。 現状フロントエンドエンジニアが指すものはだいたいこれ。 Web 標準になりつつあるもの Import Assertions で実現しそうな Synthetic Module としての CSS Module 標準になりそうな所まで来ている。 この２つに関して話がごちゃごちゃになるんで整理する。 コミュニティベースの CSS Module https://github.com/css-modules/css-modules コレ自体は概念的なもの。 その実装 として Webpack の CSS Loader などがある。 なので、一般的に「CSS Module か Styled Component か」みたいな議論ででてくるものの場合、 Webpack の CSS Loader を入れ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Storybook CSF3.0 時代のテストに備える
Chakra UIの歩き方 & Tips集
React と Vue に関する XSS アンチパターン
