そのuseRef+useEffect、refコールバックのほうが良いかも？ - Qiita
Reactにおいて、useEffectのユースケースとして知られているのが、DOMノードに直接アクセスしなければいけない場合です。useRefでDOMノードをrefオブジェクトに取得し、エフェクト内からDOMノードにアクセスするというのがその場合の基本的なやり方です。 このようなuseRef + useEffect の使い方は、問題ない場合もありますが、実は別の手段を使った方がいい場合もあります。その場合に別の手段として適しているのがrefコールバックという機能です。 そこで、この記事ではどのような場合にuseRef + useEffectよりもrefコールバックが適しているのか、そしてrefコールバックを使う場合の注意点について解説します。 復習: refコールバックとは React DOMでは、組み込み要素（divなどHTMLの要素）に対してrefという特殊なpropを与えることができ
UIコンポーネントの大きさは外から制御しよう - Qiita
昨今のフロントエンド向けUIライブラリでは、コンポーネントの設計が重要です。この記事では、コンポーネントのスタイリング、その中でもとくにコンポーネントの大きさに関わるコンポーネント設計について考えます。 私の考える結論は、むやみに大きさを指定できるpropを生やさずに、CSSで外から大きさを制御できるようにしたほうがいいです。 コンポーネントの大きさを制御したい UIの一部分を再利用可能なコンポーネントとする場合、同じコンポーネントがさまざまな場面で使えるのが望ましいでしょう。コンポーネントが提供する機能にもよりますが、場面に応じてさまざまな大きさでコンポーネントを使用できたほうがよいこともあります。 具体例として、このようなコンポーネントを考えてみましょう。例はReactで示しますが、この記事の内容はReactとは関係ありません。 const Card: React.FC<React.P
Adaptive Typography - Figma から CSS へ - Qiita
この記事の概要 デザイントークンとしてタイポグラフィスケールを定義する手法はかなり市民権を得てきました。 しかし、あくまでそれぞれのトークンは固定値であることが多く、Web デザインで言えばデバイスサイズごとの最適化はあまりなされていないように思います。 Figma の variables を使いビジュアルとして整理し、その後 CSS に移植するまでの流れを記事にしてみます。 Figma での定義 タイポグラフィスケール（グローバル） あくまで 1 つの基準ですが、Lighthouse にて「フォントサイズが 12px 以下だと読みづらい」といったメッセージが出ます。 そのため 12px を下限とし、スケールをつくってみたいと思います。 今回はこの式を用いて、n = 3 からスタートします。 すると、次のような結果が得られます。 12 13 15 17 19 21 24 27 30 34
個人開発で月1万円を稼げるようになった話。 - Qiita
はじめに こんにちは。こんばんは。おはようございます！ 今回は個人開発話でも書いてみようと思います。個人開発で月1万円を稼げるようになるというのは僕にとって1つの目標でした。同じように月1万円稼げるようになりたいぞ〜！という人もいるかもしれません。そういう人にこの記事が少しでも参考になればと思っています。 そして、実際にこの記事を読んで「個人開発をスタートした！」「眠らせてたアプリをバージョンアップした！」などのアクションにつながったとしたら、それが一番嬉しいです。 ちなみに僕はiOSアプリを開発しているので、iOSアプリによった話がメインです。 個人開発で一番大事なこと 大事なのは続けること ごくごく当たり前のことで何の捻りもありません。でもやっぱりこれが一番大事です。とにかく続けましょう。 まだ月1万円に到達していない人で、アプリを20回以上アップデートしたという人はほぼいないんじゃな
エンジニアとしてフルリモートワークで8年生き残る技術 - Qiita
こんにちは。吉田智哉です。 岩手県盛岡市に住みながらエンジニアとしてフルリモートワークで東京の開発案件を請けてます。 気が付くとこの働き方で8年間も経過していました。 8年生き延びることができたので、そのコツをシェアしたいと思います。 その日のコミットはdraftのpull requestとして出す エンジニアは成果物が全てです。 いくら一生懸命働いていたとしても、成果物、つまりコードがなければその日働いていたとしても 成果として認められません。 チームメンバーやリーダーに対してちゃんと働いていることをアピールするために、 その日のコミットはその日のうちにpull requestとして出すようにしています。 作業が途中の場合はdraftのpull requestにしています。 pull requestとして出せない調査系のタスクの場合は 調査した記録をドキュメントとして残しておいて、 他の
入力欄のプレースホルダーって結局どうなの - Qiita
入力欄のプレースホルダーの話をします。プレースホルダーというのは、フォームの入力欄で、ユーザーが入力するまでの間に表示されているテキストのことです。 書籍「Webアプリケーションアクセシビリティ1」では、「3.1 ラベルと説明」のところで、紙版にして約1.5ページの分量を割いて、フォーム入力欄のプレースホルダー（<input> 要素や<textarea> 要素の <placeholder> 属性）の問題点を指摘しています。 この本で指摘されているプレースホルダーの問題点は以下の3つです。 プレースホルダーの色が薄く視認しづらい プレースホルダーとフォームコントロールの値との区別がつかない フォームコントロールに値を入力したときにプレースホルダーの値が見えなくなってしまう Webアプリケーションアクセシビリティ さらに、Nielsen Norman Groupによる「Placeholders
がんばらないObsidianノート術 - Qiita
はじめに Obsidianという素晴らしいプロダクトが登場してから、デジタルノート術は活発化したと思います。私もその１人で、今日も楽しくObsidianを使っています。 しかし、その一方であまりノート術にこだわりが強くない方や深く理解するほど価値を感じていない人の中ではまだまだ単なるメモ帳として使われている現状があります。 そこで、今回は「がんばらない」Obsidianノート術として、「こだわりすぎない」「多様な原理原則がない」形で『書く』習慣を付けるためのノート術を書きました。 そんなノート術であったとしても、今後ノートを分解していけるような構造にしておくことで、今後の拡張性を残しています。ぜひ「難しくて挫折しまった」という人はチャレンジしてみてください。 『書く』ことで整理術は生きる Personal Knowledge Managementはの概念やLYTといった考え方は斬新で、とて
知的・技術的進歩のスピードを限界まで加速するノートアプリ『Heptabase』 - Qiita
はじめに 1年半ほどObsidianというノートアプリを使い、Qiitaにも記事を３つほど公開をしていました。 効率的に成長するためのデジタルノート術(Obsidian x Zettelkasten(LYT Framework)) コーディングのようにノートを取る技術 がんばらないObsidianノート術 確かにNotionやEvernoteとは違う感覚のノートアプリであり、双方向リンクを利用したグラフで繋げていくノートに当時は感動を覚えました。 その反面、Obsidianを百パーセント有効に活用できていたかと聞かれると「はい」と答えることは難しいと感じています。がんばらないObsidianノート術の記事はまさにその一角であり、Obsidianの拡張性と自由度に翻弄されてしまわないように書いた記事です。 1年半を通して紆余曲折した中、先日新しいツールとの出会いがあり、自分に合うツールを見つ
もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
現職と前職で感じたスクラムの違い - Qiita
はじめに 今の会社に転職してきて２ヶ月が経ち、まだまだ分からないことも多いですが少しずつ環境にも慣れてきたので頭の中を整理するためにも今感じていることをアウトプットしたいなと思い書きました！ 現在、私が参画しているチームはスクラムをベースとして開発を行なっており、前職もスクラムでの開発を経験していたので、その違いを整理していきます。 前職 スクラムを導入するまでの背景 前職では、美容医療・精神科クリニックを運営している会社で、クリニックスタッフが使用する社内システムの開発に携わっていました。働き方としてはフル出社になります。 チーム構成は以下で、私はメンバーでした。 チーム構成（7名） ディレクター(PM) 1名 リーダー 1名 アーキテクト 1名 メンバー 4名 はじめからスクラムを導入していた訳ではありませんでした。 開発の流れとしては、クリニックスタッフまたは関係者からディレクター（
htmxとは何なのか？ その背景にある思想について - Qiita
先日、Qiitaに投稿された一つの記事が注目を集めました。 元記事では、htmxというJavaScriptライブラリが英語圏で認知を獲得しているとして、インストールの仕方から使い方について公式のドキュメントの全体にわたって簡単に説明が行われています。 さまざまなプラットフォームでこの記事に対する反応を観察してみると、どちらかというと懐疑的な見方のほうが優勢のように見受けられます。ただ、多くのコメントは誤解に基づいているように見受けられました。「JSが要らない」といった元記事のミスリードによるところも大きそうですが1、なぜhtmxが大きく支持を得つつあるのかを理解するには、背景情報を含めて理解することが必要です。 htmxは、最近の複雑化するフロントエンド技術に対する単なる逆張りではありません。これまで30年ほどのあいだウェブ上のシステムを支え続けた「ハイパーメディア」の持つ強力さに今一度目
【Figma】他の人のカーソルを表示させない方法 - Qiita
はじめに 最近弊社のデザイナーと話をする機会があったのですが、その際に他のメンバーが参照してもカーソルを表示させない方法はあるのかと質問をもらいました。 確かにFigmaはリアルタイムでやり取りができる点は便利だと思いますが、これはかえって不都合になり得ることもあるなど実感しました。 そこで他のメンバーが参照していてもカーソルを表示させない方法を備忘録的にまとめておこうと思います。 カーソルを非表示にする方法 非表示にする方法は非常に簡単で、メニューの【View】 → 【Multiplayer cursors】のチェックを外すことで非表示にすることが可能です。 また、以下ショートカットでも表示非表示を切り替えることが可能です。 cmd + option/alt + \ 以上になります。 さいごに 常に誰かのカーソルが自分の近くにあったらやりづらいですよね。 そんな時は是非この設定を活用して
Web サイトやアプリケーションのモックアップを作る際、Figma データとして作らないもの - Qiita
この記事の概要 Figma での○○の作り方 といった記事は多く存在します。 一方で ○○は Figma で作らない方が良い といった記事は少ないように思います。 意外と、無理やり頑張ってしまったがゆえに後々大変になるパターンもあるので、作らない方が良さそうなものを 3 つ紹介します。 複雑なネストが必要になるコンポーネント 例として ol や ul の挙動をしっかり再現するためのコンポーネントを考えてみます。 これらの要素はネストがあり、しかも ol > ol ul > ul ol > ul ul > ol と色々なパターンがあります。 そしてリストアイテムがいくつ並ぶかも分かりません。 Figma は 2023 年 12 月現在、コンポーネントの中に自由にコンポーネントを配置することができません。 予めパターンを網羅できるのであれば variants として定義できますが、逆に言えば網
confluenceのページ名を変更するとURLが変わる場合と変わらない場合がある事例 - Qiita
インフラの人に教えてもらったよ 実は、自分が勘違いしてたのですが、どうせならと情報共有しておこうと思います。 Confluenceの仕様とのこと。 ページ整理やタイトルを変更すると起きること 日本語名タイトルで新規作成したページは、pageIdが紐づいています。 ex) https://...pageId=xxxx そのため、スペースのお引越しをしても、迷子になりません。 英数字のみのタイトルで新規作成したページは、pageIdが定義されていません。 ex) https://...display/spaceName/pageName そのため、スペースのお引越しをすると、同じURLではアクセスできません。 これ知ったとき、結構衝撃でした。 なぜこの話になったかというと、スペースのページお引越しをしたときです。 いくつかのページが、not foundになってしまい、いくつかのページはちゃんと
一番分かりやすい OAuth の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の資金調達！→『AUTHLETE 凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表) 説明手順 （１）ユーザーのデータがあります。 （２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバ
【議事録作成もさくさく！】Googleドキュメントでマークダウンプレビューをする方法 - Qiita
Qiitaの記事を書く前に、Googleドキュメントで下書き→社内で校閲してもらってからQiitaに下書き→記事投稿の流れで私は記事を書いているのですが、Googleドキュメントだとマークダウン記法がちゃんと出来ているのかどうか確認と変換が面倒くさい…。 書きながらマークダウンで表示されたらいいのに。出来ないの？と思って調べてみました。 出来ました！！！！！ 出来ました。あっさり悩みが解決したので嬉しい＆便利だったのでまとめてみました。 Qiitaの記事だけじゃなくて簡単なドキュメントを作る際に役立ちそうなので是非お試しあれ。 設定方法 1.Googleドキュメントを開く 2.上部に表示される「ツール」→「設定」をクリック 3.設定の中から「Markdownを自動検出する」にチェックを入れる これで設定は完了！ 実際に書いてみる。 まずは見出し。 見出しの書き方は文頭に「#」をつける。 半
FigmaのOrganizationプランで未使用Componentを撲滅しよう - Qiita
この記事の概要 Figmaを使っていて、こんな場面に遭遇した経験はありませんか？ 「このComponentってどこで使っているんだろう？あまり見た覚えが無いけど、もしかして削除しても大丈夫なのかな？」 Componentは便利ですが、増えすぎては管理が行き届かなくなります。 もし未使用なComponentがあれば削除しておく方がベター。 Organizationプランであれば安心してComponentを削除できるので、その機能ややり方を紹介します。 伝えたいこと Library Analyticsの存在と使い方、これに尽きます。 よくあるしんどい状況 みなさん、以下のような話をしたことはありませんか？ 「似たような見た目のComponentがいくつかあるぞ。」 「こっちのパターンはどこで使ってるんだ？あまり見覚えがない……。」 「ほぼ同じ内容だし1つのComponentにまとめちゃいたいな
Figma でアイコンコンポーネントを作るときのデータ構造 - Qiita
この状態で、レイヤー数 2 のインスタンスに swap します。 すると、1 つのレイヤーは色の変更が反映されましたが、もう 1 つのレイヤーには反映されていません。 レイヤー数 3 のインスタンスに swap した際も同様に、1 つのレイヤーにだけ色の変更が反映されています。 今度はレイヤー数も揃えます。 具体的には、複数のレイヤーがあるアイコンは Union にしてしまい 1 つのレイヤーとします。 そのままでは Rectangle と Union という 2 種類の名前が生まれてしまうので統一します。 ここでは Rectangle に揃えます。 この状態で、レイヤー数 2 のインスタンスに swap します。 無事、すべての要素に色の変更が反映されました。 レイヤー数 3 のインスタンスに swap した際も同様に、すべての要素に色の変更が反映されました。 条件にあわせて実施すること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアにも知って欲しいChatGPT基本テクニック - Qiita
React 19 での style 要素の実験 - Qiita
