2024/10/5 YAPC::Hakodate 2024

GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを

本記事はANGEL Dojo 2024参加者によるアドベントカレンダー「ANGEL Calendar」の最終日の記事になっております。 他のみなさんが書かれた記事はこちらからご覧ください！ ※…ANGEL Dojo 2024に関しましてはAWS JAPAN APNブログをご覧ください。 こんにちは、ひるたんぬです。 今日で2024年度上半期が終わりますね。これを書いてふと思ったのですが、なぜ「YYYY年度」は4月始まりなのでしょうか？ 1月から始めてくれていれば色々スッキリするのに…と思い、なぜ4月からになったのか調べてみました。 （前略）当初から4月始まりだったわけでなく、明治政府により会計年度が初めて制度化された明治2年（1869）は、10月始まり。続いて、西暦を採用した明治6年からは、1月始まりになりました。つまり、暦年と年度の始まりが同じ時代があったのです。明治8年からは、地租の納

しばたです。 前の記事は既に更新済みですが、2024年9月26日ごろから利用者向けにAWS WAF Classic (v1)のサービス終了が通知され始めています。 本記事では通知の詳細と既存リソースの移行方法を簡単に解説します。 詳細 通知の詳細は各自でご確認頂きたいのですが、最初の一文だけ引用すると We are contacting you because your AWS account has AWS WAF Classic resources. After careful consideration, we have decided to end support for AWS WAF Classic. Starting March 2025, you will not be able to create new WAF Classic WebACLs. On September

はじめに アクセスキー発行するのって非推奨なの？ 普段、CLI操作はCloudShellや、Cloud9上で行うようにしているのですが（環境構築 したくない。）、デスクトップ上で操作したい時があります。 そこで、一番簡単な方法であるアクセスキーを発行しようとすると、こんな代替案を提案されます。 この警告にモヤモヤしていたので、今回は「IAM Identity Center」を使ってみた。っていう記事です。 実は、アクセスキーは丸見えだったり。 最近、職場の本番リリース中に気づいたのですが、AWS CLIに保存したアクセスキーや、シークレットアクセスキーは丸見えだったりします。 (↓は既に削除しているキーたちです。) アクセスキーの何がいけないのか？ おおむね以下の理由から、非推奨の模様。 永続的な認証情報だから。 キーが流出すると、攻撃者がリソースにアクセスし放題。 キーの管理が面倒。 複

2024年9月25日 アフラック生命保険株式会社 アフラック生命保険株式会社（社長：古出 眞敏、以下「アフラック」）は、アフラック中期経営戦略（2022～2024年）の中で掲げる「DX@Aflac」の取り組みとして、すべてのお客様接点において、一貫性を持った体験価値をお客様へ提供し、感動的なユーザー体験を創出することを目指しています。その具体的な取り組みの一つとして、「アフラックデザインシステム」を構築し、その一部であるUIライブラリを公開しましたので、お知らせします。 ■「アフラックデザインシステム」について アフラックデザインシステムは、お客様にご利用いただくウェブサイトから保険代理店の募集人が使用する業務システムまで、あらゆるデジタル接点の開発時に利用するデザインプラットフォームです。これによって、アフラックに関わるすべてのステークホルダーに快適なユーザビリティを提供するだけでなく、

はじめに こんにちは。データシステム部/推薦基盤ブロックの佐藤 (@rayuron) です。私たちはZOZOTOWNのパーソナライズを実現する推薦システムを開発・運用しています。推薦システムごとにKPIを策定していますが、データの欠損やリリース時の不具合によってKPIが意図しない値を取ることがあるため定常的に確認する必要があり、これをKPIのモニタリングと呼んでいます。 先日、推薦システムの実績をLookerでモニタリングするというテックブログで推薦システムのKPIをモニタリングする方法を紹介しましたが、運用していく中でいくつかの課題が見えてきました。本記事では、より効率的かつ効果的なKPIのモニタリングを実現するための取り組みについて詳しくご紹介します。 はじめに 改善の背景と課題 背景 課題 トレンドを考慮した異常検知が不可能 モニタリングの設定が面倒 アラート対応フローが不明確 サマ

宮本氏： ひとつは、アーケードゲームを始めとする膨大な資料や、毎年何百本と増えていくゲームソフトなどをどのように保存・管理していくかということです。アーケードゲームは動かないと意味がないですし、ゲームソフトもただパッケージだけ残していてもしょうがないので、なんとか管理していかなければいけない。 もうひとつは、任天堂に百人～二百人と入ってくる新入社員に対して「任天堂とはなんぞや」という説明をする時間の問題です。かつては2時間かけて新入社員セミナーという講座をやっていたんですが、それがいつしか2時間半になり、気付けば3時間近くになってきました。社員は面白がって聞いてくれるんですが、20年近くセミナーをやっているといい加減にそれを引退したいと思うようになりました。 本ミュージアムの展示は、そのセミナーで話していた内容がベースになっています。 たとえば、Wiiを作るにあたっては、『ウルトラマシン』

カストディアルとノンカストディアル ウォレットの比較暗号資産ウォレットは、第三者が鍵を保有するカストディアルと、自分で鍵を管理するノンカストディアルに分類されます。 ウォレットの基礎知識暗号資産ウォレットは、誰もがデジタル資産を保存、送信、または受信できる主要な方法です。暗号資産ウォレットは、ブロックチェーンネットワークに接続するクライアント（ツールやサービス）であり、ネットワーク上の口座残高や取引履歴などの情報を表示することで、ブロックチェーンネットワークと視覚的に対話する手段を提供します。また、デジタル資産の送受信プロセスを、一般ユーザーにとって便利で安全、かつ簡単なものにします。 暗号通貨ウォレットの重要な構成要素は、公開鍵と秘密鍵のペアです。これらは、ウォレットと、その中に保管されている資産のユーザーの所有権を識別するために使用される、ユニークな文字列です。 公開鍵は、銀行の口座番

Case Study for Repurposing Video Content With Generative AI / AWS Community Day Taiwan 2024

はじめに この記事は、「GUIプログラミングのベンチマークとして提案された7つの課題を題材に、React状態管理ライブラリのJotaiを学んでみよう」というテーマのJotai学習記事の第一回Counter編です。 完成したコードの解説がメインになります。もしご自身で実装してみたい場合はネタバレになってしまうのでご注意ください。 7GUIsとは 言語やライブラリ系のベンチマークといえば計算速度が評価軸にされることが一般的ですが、この７GUIsはいくつかの指標を軸に7つGUIアプリのお題を用意し、それをベンチマークとして提案しています。 2018年頃に話題となったようで、web系だとReact/MobXやSvelteが実装例として掲載されています。 詳しくはこちら。 7GUIs x Jotai の元ネタ Jotai作者の@dai_shiさんが過去に取り組んでおり、CodeSandboxで既に実

こんにちは、Jotaiの作者です。Jotaiが生まれるまでに様々な取り組みをした歴史を短い記事にしてありますのでよろしければご覧ください。今後のJotaiの発展に期待します。 以下、ChatGPTによる翻訳です。 はじめに この投稿では、なぜ私がJotaiの開発を始めたのか、その背景にあるストーリーを共有したいと思います。JotaiはしばしばRecoilと似たような解決策と見なされますが、その開発にはもっと長い歴史があります。 React Hooks React Hooksが最初に発表されたのは2018年10月のことでした。Reactコンポーネントの外でロジックを開発するというアイデアが気に入り、すぐに多くのライブラリがこのアプローチを採用するだろうと考えました。何か開発したいと思い、グローバル状態管理という分野を選びました。私のモチベーションは、Reduxのセレクター、当時「mapSta

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、いくつかの場面でWebアクセシビリティについて、コーディングに関する技術的な説明をする機会がありました。そのなかで、そもそもWAI-ARIAというものが、どういう立ち位置のものなのかがわかりづらい状態にあるということに気付きました。その結果として、WAI-ARIAの活用を含めたWebアクセシビリティ向上に取り組むことへのネガティブな印象が生まれてしまったり、理解が足りないままWAI-ARIAの属性を使うことでかえって問題が発生しやすくなってしまったりしている現状があるのではないかと思うようになりました。 そこでこの記事では、なるべ

皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ