こんにちは、ふじけん(@kenshir0f)です。 Figma Config 2022 で大きめのアップデートが来て、何がどう機能が変わったのか追いきれなかったのでざっくりまとめたいと思います。 ダークモードの切り替えFigma でデザインするときのサイドバーなど、画面全体をダークモードにする機能が追加されました。白い画面の面積が大きいと少し目がつらかったので普通に嬉しいですね。 左が今までのライトモード、右がダークモード画面左上のメニューからダークモードとライトモードに切り替えることができます。 ⌘(Ctrl) + / で「Use dark mode」と打ってもできます僕は Slack や VSCode など他のツールをダークモードで作業しているので、統一感が増えてめっちゃよき。 オートレイアウトの機能追加オートレイアウト(Auto Layout) はテキストの長さや要素の数によって、自

6回目の JavaScript ライジングスター にようこそ！ JavaScript疲れから逃れるためにここに来たみなさん、ちょうどいいところに来ましたね。 今回はメタフレームワーク、速度の必要性、界隈のオールスターがテック企業にジョインした話などの話題があります。 しかし、まずはチャンピオンの話です。 今年は誰もが予想していなかった新しい覇者が誕生しました！ しかもそれは、なんとコマンドラインツールです！ 以下は、2021年の1年間で増加したGitHubのスター数によるランキングです。Webプラットフォームに関するベストプロジェクトを集めたリストであるBest of JSからの一年間の分析です。各プロジェクトをクリックすると、より詳細な情報を閲覧することができます。

Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。

10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し

共創のための地域基盤としての非公式組織の形成 / Informal community as an infrastructure for co-creation

公開日 : 2021年10月14日 (2023年10月11日 更新) カテゴリー : ユーザビリティ / アクセシビリティ ウェブのフォームにおいて、サブミットボタンをデフォルトで無効化しておいて、ユーザーの入力不備がなくなったときにボタンを有効化する UI があります。たとえば、利用規約などの文書を読んで同意する旨のチェックを入れないと、あるいは、入力必須フィールドにすべて正しく情報を入れないと、ボタンがアクティブにならない、というものです。 サブミットボタンがデフォルトで無効化されているフォームの例。 このような UI は、アクセシビリティやユーザビリティの観点で、以下の問題があります。 そこに存在しているはずのサブミットボタンが使用できないことに対して、その理由をユーザーが理解できずに、混乱してしまう恐れがある。(ユーザーの側に誤っているという自覚がなくても、ちょっとした見落としや入

コードレビューに限らず、いろいろなレビューがいろいろなプロセスに組み込まれている。 だが、レビューにおいて、たとえ内容に瑕疵があっても承認されるなら、そのレビューは単なる形式・儀式に過ぎない。 "何かを保障するためのプロセス"としてのレビューを機能させることを目的とするなら、そこには却下の可能性があることが必要条件だ。 保障: ある状態がそこなわれることのないように、保護し守ること。(https://kotobank.jp/word/%E4%BF%9D%E9%9A%9C-630029) 却下と批判的立場 そのようなレビューにおいて、レビュアーは「これは承認しても大丈夫か」と思考する。 「承認しても大丈夫だ」という確信を得るということは、裏返せば「却下すべき理由がない」という確信を得ることである。 その確信が得られるのは「却下すべき理由を探したが見つからなかった」ときである。 つまりレビュア

私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか？ 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた

ハイクラス求人TOPIT記事一覧「がんばらないTypeScript」のための現実的な設定を考える ─ 4レベルの厳しさを使い分けてTypeScript疲れを克服しよう！ 「がんばらないTypeScript」のための現実的な設定を考える ─ 4レベルの厳しさを使い分けてTypeScript疲れを克服しよう！ エンジニアHubでは2019年に「がんばらないTypeScript」を紹介しました。JavaScriptに静的型付けなどを提供するTypeScriptは、今では実プロジェクトに採用されるプログラミング言語になっています。そこで現実的なTypeScriptの設定を、藤吾郎（gfx）さんに解説してもらいました。 2021年の現在、TypeScriptの価値はますます広く認められるところとなり、多くのJavaScriptプロジェクトがTypeScriptで開発されるようになってきました。またT

こんにちは。ソウゾウの Software Engineer の hiroppy です。「連載：「メルカリ Shops」プレオープンまでの開発の裏側」 の最後は、Web フロントエンドの紹介をしたいと思います。メルカリ Shops は既存のメルカリアプリの中に独立した Web アプリケーションとして動いています。本記事では、どのようなライブラリを選定し、どのようにアーキテクチャを設計してきたかを解説します。 なぜ Web なのか？ アプリの上で動いているのであれば、WebView ではなくても良いと感じる人はいると思います。今回採用した 1 つの理由としては、リリースが柔軟な点が挙げられます。iOS/Android の両方に対して開発サイクルを早めることが可能であり、また機能追加やバグ修正が容易です。どのように WebView で動いているかについては、6 日目のメルカリ Shops のため

こんにちは。開発本部 オンボーディングチームの酒井（@sakay_y）です。社内のオンボーディングコンテンツを、どんどん社外へ公開することを夢見ています。 2021年もエンジニア新人研修を行いましたので、軽い紹介と、講義資料および一部講義動画（New!）を公開いたします。 2021年のエンジニア研修について 講義資料公開 Webアプリケーション基礎 HTTP/DNS ソフトウェアライセンス ソフトウェアテスト テスト自動化 アクセシビリティ Docker Chrome Developer Toolsの使い方 サイボウズのアジャイル・クオリティ デザインの役割と関わりかた データベース CI/CD セキュリティ モブに早く慣れたい人のためのガイド ITコミュニティ文化と情報発信に共通する成長と貢献の要素 正規表現 Kubernetesを使った開発入門 モニタリング入門 gRPC入門 日本語話

Today we are excited to announce the beta release of TypeScript 4.4! To get started using the beta, you can get it through NuGet, or use npm with the following command: You can also get editor support by Downloading for Visual Studio 2019/2017 Following directions for Visual Studio Code and Sublime Text 3. Some major highlights of TypeScript 4.4 are: Control Flow Analysis of Aliased Conditions Sym

noteでの大きくなりすぎたNuxt.jsのアプリケーションを分割する取り組みについて

最近 React コード生成機を作っていて「一番文句言われなさそうな React コンポーネントの書き方ってなんだ…？」と改めて疑問に思ったので考えてみました。 結論から言うと以下の形をデフォルトにするのが良さそうかなと思いました。 function vs. アロー関数 -> アロー関数 型は基本的に VFC でつけて、 children が欲しい場合は明示的に props に追加する return を省略可能な時省略するか -> しない props を destructure するか -> しない派だったけどした方がいい気がしてきた const Hoge: React.VFC<Props> = ({ title }) => { return ( <Fuga title={title} /> ) } ちなみにですが、大事な前提として TypeScript を使うことを前提としています。(型

TL;DR 「可読性が高い」とは、「理解するために使う脳内メモリの量が少ない」ということである。 理解するために使う脳内メモリの量 = コードを理解するのに必要な情報量 - コードについての予備知識 「そのコード 1 行を単独で理解するのに必要な、追加の情報を意識する。その追加で必要な情報が減るようなコードにする」というのが可読性を高めるための一つの大きなの指針としてアリなのではないか。 はじめに 可読性についての細かい Tips は様々ありますが、「結局」何をどうすればいいのか？という漠然とした問いには答えられていない気がします。細かい Tips を包括する大きな指針をがないかと考え、まとめたのがこの記事です。 可読性の高いコードとは？ 脳内メモリの消費を抑える 可読性とは、コードが頭に入ってくる時のスムーズさと言えると思います。すなわち、いかに直感的に、余計なことを考えず、脳内メモリの

HTML 5.2のそれぞれの要素が入れ子にできる「子要素」、包含されることが可能な「親要素」の一覧のルールを視覚化して表示します。 ※1 a要素の親要素が包含可能であること※1 audio要素の親要素が包含可能であること※1 canvas要素の親要素が包含可能であること※1 del要素の親要素が包含可能であること※1 ins要素の親要素が包含可能であること子要素省略※1 map要素の親要素が包含可能であること※1 noscript要素の親要素が包含可能であること かつ body要素の子孫であること子要素省略※1 video要素の親要素が包含可能であること ルート要素＆文書メタデータ html 親 子 head 親 子 title 親 子 base 親 子 link 親 子※HTML 5.2から可能。フレージングコンテンツが期待される場所※head要素の子孫であること meta 親 子※he

Today we’re excited to announce our Release Candidate (RC) of TypeScript 4.3! Between now and the stable release of TypeScript 4.3, we expect no further changes apart from critical bug fixes. To get started using the RC, you can get it through NuGet, or use npm with the following command: You can also get editor support by Downloading for Visual Studio 2019/2017 Following directions for Visual Stu