筆者は、より多くのWebサイトやWebサービスが、より高いアクセシビリティをもつものになることを強く願っています。 （2024/02/04追記）もう少しわかりやすく書き直したものを投稿しました Webアクセシビリティと合理的配慮 「2024年からWebアクセシビリティ対応が義務化される」というようなことが書かれたWeb上の記事が増えているようです。 しかし、2024年1月現在、日本で「Webアクセシビリティ」について法的な義務が発生している・または2024年内に発生するようになる法的な根拠はおそらくありません。法律の改正が施行され、「やったほうがいい」度合いは高まっていると解釈できますが、「Webアクセシビリティは義務です」とまでは明言できないはずです。 ところが、「アクセシビリティ 義務化」などでWebを検索すると、「2024年にアクセシビリティが義務化します」と説明していたり、あるいは

こういうのを作りました。 こういうの レビューリクエストされている Pull Request の一覧 自分の Pull Request の一覧 通知の一覧 を表示しています。 各アイテムをクリックすればブラウザで対象のページが開きます。 通知に関してはメニューバー上で既読にすることもできます ( 一括既読も可能 ) 。 とにかく仕事が捗ってしょうがないので紹介です。 仕組み xbar というオープンソースの Mac アプリを使って実現しています。 xbar はプラグインを使うことで Mac のメニューバーに様々な情報を表示することができるアプリです。 Homebrew 経由でもインストールすることができます。 xbar プラグインを使用する手順 それでは今回作成した xbar プラグインをインストールして使用する手順を紹介します。 ソースコードはこちら。 0. 前提条件 今回作成した xb

今日のXでは、イベントハンドラの関数名についての話題を見ました。元の投稿はこちらです。要するに、次のhandleClickのようなhandleイベント名という命名は良くないということです。 const handleClick = () => { ... }; <button type="button" onClick={handleClick} /> これについて少し考えたので、せっかくなのでアウトプットしておくことにしました。 この記事の目的 考えたことを頭の中に残しておくのがもったいないので、文章の形にしておく。 色々な意見が出る問題であり、ベストな答えは無いので各々好きにすれば良いということを、読者に理解してもらう。 とはいえ、筆者の考えに納得して同じ考えの人が多いと嬉しいので、なるべく納得してもらう。 筆者の考え 自分の考えとしては、むしろhandleClickいいじゃん！　どんど

こんにちは、ギフティでエンジニアをやっている中屋です! 自分は割とドキュメントが好きです。 ドキュメントはなさすぎるよりはありすぎた方がマシと思っている派閥です。 はじめに 我々のチームでは開発ドキュメントとして ADR（Architecture Decision Record）というものを書き残すようにしています。 ADR とは平たく言うと、「設計上の選択を記録したもの」です。システム開発のなんらかの意思決定に対して、その判断理由などを短いテキストファイルにまとめたものを指します。 自分が初めて ADR という言葉を知ったのは『Design It!』という本でした。 最近ではいろんな企業が ADR を書いているのが、ブログ等から伺えます。 ADR そのもの自体の詳しい解説についてはネット上にたくさん情報があるのでここでは割愛します。 参考: https://cloud.google.co

この記事は LITALICO Engineers Advent Calendar 2021 7日目の記事です。 業務でPull Requestを出す際に気をつけていたり実施していることがいくらかあるのですが、あまりそれをアウトプットする機会はなかったので、ちょっくらまとめてみます。 前提として、社内でGitHubを使っている・数人程度のチームでwebサービスを継続的に開発している環境を想定しています。 また、Pull Requestの変更内容や目的の良し悪しの話題（その変更は必要なのか？目的に沿っているか？など）については本記事の対象外とします。 タイトル タイトルは当然やったことを書きますが、「見る人にとって過不足なく識別できる情報量」を入れるようにします。だいたいサラッと一文、感覚的には助詞が1~2個に収まる程度。 ここで長くなりすぎるようであれば、タイトルには不要な（本文にだけあれば

【VS Code + Marp】Markdownから爆速・自由自在なデザインで、プレゼンスライドを作るMarkdownVisualStudioCodeDraw.ioMarpvega TL;DR Visual Studio Code上で、Markdownから、こんな感じのデッキを生成できるようにします。 使用したファイル類は、GitHub tomo-makes/marp-styles にまとめました。 きっかけ 叩き台となる資料がなく、急ぎプレゼンをする機会があり、Marpで作成した 内輪では使っていたが、多くの目に触れるのは初めてで、もう少しデザインを調整したいと思った 今後も使いまわせるものを、スニペット、およびサンプルテーマ化しておこうと思い立った ついでにいろいろな図表の生成とデッキへの入れ方、必要そうな配色、素材のリンクをまとめておきたい Marpとは Marp: Markdown

優先度B: 強く推奨 ​これらのルールは、ほとんどのプロジェクトで可読性や開発者の使い勝手を向上させることが分かっています。これらのルールに違反した場合でも、あなたのコードは動作しますが、違反はごく少数で十分に正当な理由がなければいけません。 コンポーネントのファイル ​ファイルを結合してくれるビルドシステムがあるときは、各コンポーネントはそれぞれ別のファイルにするべきです。 そうすれば、コンポーネントを編集したり、使い方を確認したりするときに、より素早く見つけることができるようになります。

筋肉量を増やして、効率よく脂肪も落としたい！ ダイエット効果を高めるには、ジョギングなどの有酸素運動に筋トレなどの無酸素運動を組み合せたエクササイズが効果的です。 ジョギングを先にするか筋トレが先か、その日の気分で決める方も多いですが、有・無酸素運動には、効果を得やすくするのに適した組合せ・タイミングというものがあります。 ただひたすらにやっても効果は得にくいので、順番やタイミング（食前や食後、空腹時、寝る前）も意識することで差が出ます。 今回は、有・無酸素運動の効果を高める組合せとタイミングについてお話しします。 有酸素運動の効果的なタイミング 有酸素運動とは、ジョギングやウォーキング、水泳、サイクリングなどでムリなく長時間続けられる程度の負荷を、継続的にかける運動のことです。酸素を使って筋肉を動かすため、代謝アップや脂肪燃焼効果があります。 有酸素運動は「食後約1.5時間」のタイミング

運動で「貯める脂肪」を「燃やす脂肪」に変える 運動を行うことで、脂肪の性質も変わります。“太る脂肪”から、“やせる脂肪”に変わるのです。 「え？　やせる脂肪ってどういうこと？」と思いますよね。 脂肪には、「白色脂肪細胞」と「褐色かっしょく脂肪細胞」という性質の違う2種類があります。 白色脂肪は、中性脂肪を貯め込んでどんどん膨れていく脂肪です。脂肪と聞いて一般的にイメージされる、エネルギーの貯蔵庫が白色脂肪です。 一方、褐色脂肪は中性脂肪を燃焼して熱をつくります。 白色脂肪と褐色脂肪は、正反対の働きをするのです。 つまり、白色脂肪が増えれば太り、褐色脂肪が増えるとやせやすくなります。 ただ、褐色脂肪は大人になるにつれて少なくなり、40歳頃から急激に減り、60歳頃にはほとんどなくなってしまいます。これが、中高年になると太りやすい原因のひとつと言われています。 ところが、ここで朗報です。 効率よ

仕事で Github を使っていたり、 OSS への contribute しようと思ったときに issue を作成することがあると思うが、最近の Github の機能追加もあって、ベストプラクティスが共有されてない感があるので、おれはこうしているということや、アドバイス募集の意味も含めて書こうと思う。 まずは issue を作成する際、頭にいれておいたほうがいいことについて。 ドキュメント Github の公式ドキュメントがあるのでまずざっと目を通しておくとよい。 https://guides.github.com/ https://guides.github.com/features/issues/ https://guides.github.com/features/mastering-markdown/ issue とは何か ? 読み方は「イシュー」。直訳すると「議論すべき重要な話

こんにちは！フロントエンド開発部の石山です！ フロントエンド開発部では、スケールしやすいアプリケーションを目指して日々改善を行なっています。 今回はコードの品質を高めるためにフロントエンドチームが行なっている、モブレビュー会を紹介します！ モブレビュー会とは モブレビュー会を始めたきっかけ モブレビュー会の流れ なぜマージ済みのPRをレビューするのか レビューをするときに意識していること 実際のレビューコメント モブレビューをやってみてよかったこと 他フロントエンドメンバーの感想 さいごに モブレビュー会とは モブレビュー会は1つのPRをフロントエンドメンバー全員でレビューを行う場です。 ここではコードに対しての疑問点や改善点を絞り出すことに焦点を置いてレビューします。 モブレビュー会を始めたきっかけ フロントエンド開発部では、メンバー間でアーキテクチャや知識を共有する目的でモブワークを行

ソフトウェアテスト・ 品質保証 セキュリティ UI/UX DX カスタマーサクセス コンサルティング Our Services サービス ソフトウェアテスト・品質保証

魅力的なアプリケーションや便利なシステムを作ったとしても、不具合により正常に動作しなければ顧客満足には繋がりません。不具合を減らすには、適切なテスト計画のもとで、あらゆる動作をテストし正常に稼働するかを確かめることが効果的です。今回はテスト計画を立てるために不可欠な「テスト観点」について説明します。 テスト観点とは テスト観点とは、アプリケーションやシステムが正しく動作するかを確認するために「どの部分で、どのようなテストを行うか」を可視化することをいいます。テストの方向性を決める要素となるため、システム設計段階までに決定しておくことが望ましいです。「テスト設計仕様書」と呼ばれるテストの指針や骨格を示した書類に一覧にして記載されます。 マッチングサービスの会員登録システムを例に上げると、 登録のボタンを押したときに、登録画面に遷移するか？ 登録情報を入力するフォームに文字が入力できるか？ 使

「つみたてNISAの利回りの平均はどのくらい？」 「利回りが違うと、収益にどのくらい差が出るの？」 「利回り（リターン）で投資信託を選べば良い？」 そうお考えではありませんか？ 金融庁の「国内外の株式・債券に分散投資した場合の収益率の分布」を参考にすると、商品の保有期間が20年では年率2～8％のケースが多いようです。 出所：つみたてNISA早わかりガイドブック（金融庁） ※上記は、将来の運用成果を示唆・保証するものではありません。 また、金融機関で作成されている「資産運用シミュレーション」では、想定利回りを年率1％、3％、5％から選択するものが多いようです。しかし、つみたてNISAは、預貯金のようにあらかじめ「利回り」が示されてはいません。その理由は、NISAで運用する投資信託の場合、株式や債券などの市場は日々変化していることや、商品によって投資する資産や地域が多岐にわたるため正確な数値を

そして、インデックスファンドという投資信託は、これらのインデックスに連動することを目指して運用されています。日経平均株価に連動することを目指すインデックスファンドは日経平均株価が5%上がると投資信託も5%値上がりし、日経平均が3%下がると投資信託も3%値下がりするように運用されます。 インデックス投資とは、このようなインデックスファンドを買ってひたすら持ち続ける投資法です。 この投資法では、インデックスに含まれる銘柄は全部保有するということになるので、「どの企業の株が儲かるか」などと考えずに全部買っておくことになります。世界の株式市場や債券市場などの全体の値動きに合わせて、儲かったり損したりするのがインデックス投資です。 儲かるか損するかは、インデックスが値上がりするか値下がりするか次第です。 個別に値上がりしそうな金融商品を予測するのは すべて「アクティブ投資」 一方、「インデックス投資

何番煎じだという感じかもしれませんが、「SPA、SSR、SSGの違い」について記事にしていきたいと思います。 業務でVue.jsやNuxt.jsを使用していますが、SPA、SSR、SSGのそれぞれの違いについてフワッとした知識しかなく、人に説明を求められても上手く言葉にできる自信がありませんでした。これではまずいなと思い、それぞれの違いについてあらためて調べてみました。 SPAやSSRについて紹介する前にまず比較として、従来のWebサイトについて確認していきます。 従来のWebサイト 従来のWebサイト、いわゆるMPA（Multiple Page Application）の場合、ブラウザからHTTPリクエストをサーバーがもらうと、Webサーバーは内部でWebページを構築してJavaScriptやCSSと一緒にHTTPレスポンスを返します。この処理はリクエスト毎に毎回行われる為、ページ遷移の