[VS Code]タブのカスタムラベル設定でpage.tsx、layout.tsxなどのファイルを見やすくする どうも!オペレーション部の西村祐二です。 最近、Next.jsなどでフロントエンドの実装も行うことが増えてきました。 実装を進めていくと、page.tsx,layout.tsx,index.tsx,route.tsなど同名のファイルが増えてきて、どのファイルを開いているか分かりづらいなと思う場面がありました。 VS Codeのv1.88で開いているファイルタブのラベルをカスタマイズできるようになったので、その設定方法を紹介したいと思います。 Visual Studio Code March 2024 結論 最初に結論として、settings.jsonに下記設定をすることでディレクトリ名も表示されるようになりタブを見やすくすることができます。 .vscode/settings.js
こんにちは。ナレッジワークの torii です。 最近、プロジェクトで使用している TypeScript の型検査にかかる時間を 3 割ほど短縮することに成功しました。 参考までにどのようにボトルネックを調査して改善に繋げたのかを書いてみます! きっかけ 改善のきっかけは、たまたまネットを徘徊していて見つけた Zenn 記事でした。 (素晴らしい記事をありがとうございます!) これを読んで「自社のプロダクトでも型検査にかかる時間を短縮できるのでは?」と思い立ち、試してみたところ実際に改善に役立てることができた、というのがこの記事の概要になります。 改善対象 改善対象は、弊社のメインプロダクトであるナレッジワークのフロントエンドです。現在マルチプロダクト化に向けたコード分割に取り組んでいる最中ですが、執筆時点はモノリシックな構成となっています。 改善前の TypeScript ファイルは自動
これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか?[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか? それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール (「How to Write a Git Commit Message」の和訳記事) https://
C# / .NET における、パフォーマンス改善の Tips をお届けします。 これを見れば、効率良く 80 点を取ることができるようになるはずです!
The article is also available in Chinese. Disclaimer: This post is a very long collection of thoughts and problems I've had over the years, and also addresses some of the arguments I've been repeatedly told. This post expresses my opinion the has been formed over using Rust for gamedev for many thousands of hours over many years, and multiple finished games. This isn't meant to brag or indicate su
SNSを利用している方であれば、おそらくほとんどの方が「もふもふ動画」や「最多情報局」といったアカウントを一度は見たことがあるでしょう。 面白動画やかわいいペットの写真などの投稿で、多くのフォロワーを集めていますが、実はその大半が無断転載によるもの。転載を知らされていない元の投稿主らから、問題視されています。 ■ 「削除依頼はDMまで」とあるものの、要請に応じず 投稿を見てみると、完全に無断転載しているものと、Xの動画引用方法(URLの末尾に「video/1」を付ける方法)を使用した、“仕様の範囲内”で引用しているものの2パターンがあります。 しかしながら後者の“仕様”を使った場合でも、投稿者(動画や写真の権利者)が嫌だといえばそれまで。投稿者には著作権および著作者人格権があり、Xにポストしたからといって権利を手放したわけではありません。 これは利用規約の概要にも「ユーザーは、ポストまたは
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
様々な概念を表現する方法がプログラミング言語によってそれぞれ異なるように、React にも、理解しやすい方法でパターンを表現し高品質なアプリケーションを産み出すための慣用的な記法、ないしルールが存在します。 このセクションでは、自然な React コードを書くために従うべきルールを説明します。自然な React コードを書くことで、安全で整理されており、組み合わせ可能なアプリケーションを作成することができます。以下に挙げる特性により、アプリは変更に対して頑健になり、他の開発者やライブラリやツールと連携しやすくなります。 以下のルールは React のルールとして知られています。これらを守っていないならアプリにバグがある可能性が高い、という意味で、これらは単なるガイドラインではなくルールです。またこれらを守らない場合、あなたのコードは不自然で、理解や推測が難しいものになるでしょう。 Reac
Go のコードで文字列の変換をする関数があり、これが Google スプレッドシート上の関数としても利用できれば検証[1]に便利かもしれないと思いました。 Google スプレッドシートでは Apps Script の関数をセル上で実行できるので、Go のコードを Wasm にビルドして JavaScript から呼び出すことができれば良いのではないかと考え、実際に試してみることにしました。 動作環境 Go 1.22.2 Apps Script の設定 Chrome V8 ランタイムを有効にする その他 macOS の pbcopy コマンド[2]を利用した手順を記載していますが、Linux 環境でも pbcopy を他の手段に置き換えることで同様に動作しました。 事前調査 Go を Wasm にビルドして GAS で動かす事例は見当たりませんでしたが、Rust を Wasm にビルドして
こめ @come25136 #IT系応用問題 たかし君は納期が迫っているプロジェクトの仕様変更を受け入れてしまいました 納期日のたかし君の生存確率を求めなさい。 2018-02-13 14:22:38 倉瀬美都 @clausemitz #IT系応用問題 たかし君はSES会社員で出向先で1ケ月後に発売予定の組み込み機器の新聞記事を持った担当者から開発を命じられました。ところが仕様書と称するのは前の機種のソースで「これを解析して作って」と言われました。 たかし君が担当者に暴力をふるう確率を求めてください。 2018-02-13 14:30:49 手動人形 @Manualmaton #IT系応用問題 たかし君は念願叶って独立系のソフトウェア開発会社に入社しました。最新で高速の開発機に囲まれ、優しく教えてくれる先輩たちとホワイトな社風の中、ふとたかし君が言い放った 「皆さんオススメのエディタを教え
黒ブラ @Clorets8lack たかしくんは派遣先が独自に開発したフレームワークを使ってプログラム開発をしています。 たかしくんがフレームワークの問題点を修正したり、便利にする活動を通じてスキルアップし、今よりも条件の良い会社に転職できる確率を求めなさい。(5点) #IT系応用問題 2018-02-12 12:51:48 黒ブラ @Clorets8lack たかしくんは情報システム部員です。 監査部からシステムのログを送って欲しいとの依頼を受け、社内メールに添付して送りました。 監査担当者から添付ファイルの開き方が分からないというクレームを受ける確率を求めなさい。(5点) #IT系応用問題 2018-02-12 13:06:31 黒ブラ @Clorets8lack たかしくんはユーザー企業の情報システム部員です。 現状問題なく稼動している通信回線を同グループの系列ベンダに切替えるよう、
use フックは 2024 年 4 月現在、React の Canary および experimental チャンネルでのみ利用可能です。 use は、Promise や Context から値を読み取るための React フックです。以下のコードのように Promise の値を同期的に読み取ることができます。 import { use } from "react"; const fetchUsers = async () => { const response = await fetch("/api/users"); return response.json(); }; const Users = () => { const users = use(fetchUsers()); return ( <ul> {users.map((user) => ( <li key={user.id}>
https://contrib.rocks はGitHubのAPIから取得したコントリビューター情報からSVG画像を生成している。これまでは SVG.js を使ったTypeScriptでの実装だったが、興味本位でRustで実装したものをWebAssembly(wasm)として実行するようにしたところ、パフォーマンスが顕著に向上したためそのまま採用することにした。 Rustもwasmもまともに触ったのは今回がはじめてだったため、実装には洗練する余地が多分にあるだろうが、この記事ではとりあえず作業の記録を書き残す。 NxワークスペースにRustをセットアップするまずはじめに、Nxのワークスペース内でRustの開発環境を整えた。Cargoにもワークスペース機能があり、複数のプロジェクトの依存関係解決を集約できる。 ドキュメントに従い、ワークスペースのルートディレクトリに Cargo.toml を
チェックボックスの indeterminate 状態は将来多分なくなるdate2024.3.14(Thu.)tagsDesignFrontend 近年お手本にしがちなデジタル庁の Design System では定義がされていませんでしたが、「チェックボックスの indeterminate 状態」について考えたところ、多分将来的に無くなるんだろうなと予想を立てました。 第三の状態: indeterminateチェックボックスを使ったフォームが入れ子のとき、子が全て選択されていないことを示す表現として indeterminate が使われることがあります。 基本的にはチェックされているかいないかを表す checked 属性の true false を使いますが、別の属性として indeterminate (未決定状態)属性 の true か false があるため、トライステートとなります。
Mac と Windows に無償で付属してくる日本語フォントに「游ゴシック」があります。両環境で共通して利用できる希少な「日本語」のデバイスフォントであることから重宝され、ウェブサイトでもCSSのローカルフォント参照で利用されるケースがありました。 「サイトの書体に “游ゴシック” を適用させるCSS記述方法」のような記事は最近になっても大変多く、あたかもMac・Windowsの全てのブラウザで表示可能と錯覚してしまいがちなのですが、 結論から言うと Mac の Safari・Brave・Firefox(プライベートウィンドウ)ではもうローカルフォントとしての「游ゴシック」をウェブサイトの表示に使うことはできません。(Safariにおいては5年前の macOS Mojave 以降から使えなくなっているはず…。) フィンガープリントなぜそんな事態になっているかと言うと、最近のブラウザ界隈の
当ブログのレスポンシブコーディング施策のまとめです。 メディアクエリよりもコンテナクエリを優先する前回の記事でも触れたようにメディアクエリを一切使わずレスポンシブコーディングしました。 僕がメディアクエリを使用しなかった理由は以下の点が気になっていたからです。 各コンポーネントの状態変化をウィンドウのサイズに依存させるのは都合が悪い。実装者はウィンドウのサイズとにらめっこしながらデザインを調整する必要があり、非常に面倒。ある程度の的確な位置・間隔でブレイクポイントを用意するコーディングは効率的だが、全ての画面サイズで完璧な表示を実現するのが難しい。必ずどこかしらのサイズで見た目を妥協しないといけなくなってくる。ウィンドウのサイズではなく各コンポーネントのサイズを基準にデザイン調整するなら、どのように配置されるかを細かく考える必要がなくなる。代わりに、それぞれのコンポーネントが含まれるコンテ
タイトルと ↓ のスクショで出落ちという感じ……。 https://aws.amazon.com を開いたときの様子 CDNだったり、Varnishのようなキャッシュ系のミドルウェアの調査やデバッグをしているときは、ブラウザのDevToolsを使って、Cache-Control レスポンスヘッダだったり X-Cache レスポンスヘッダのようなレスポンスヘッダの様子をめちゃくちゃ睨みつけることになると思う。こういう仕事をしているときには、リロードしては新しいリクエストを選択し直して睨みつける、というような操作を繰り返すことになりがち。 ところが、ネットワークタブのリクエスト一覧表示の表みたいなやつには任意のレスポンスヘッダを表示することができるので、こうすると1クリックの手間が省けて嬉しいねという話。 やり方はこれだけ! ネットワークタブのリクエスト一覧表のヘッダー部分を右クリックし、コン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く