はじめに こんにちは！ 今回は、6/20,21のAWS Summit Japan 2024にて開催されたGameDayに初出場し、入賞したので感想などをまとめていきたいと思います！ また、先日NIFTY Tech Talkに登壇し、この記事には書ききれなかった詳しい内容も語っています。YouTubeにて録画が公開されており、資料も残っているのでチェックしてみてください！ AWS GameDayはネタバレ厳禁なので、公式のブログにて公開されている情報から逸脱しない範囲でまとめていきます https://aws.amazon.com/jp/blogs/news/aws-gameday-at-aws-summit-japan-2024/ AWS GameDayとは AWS GameDay  は、ある課題に対して AWS サービスで解決するための対応力や実装スキルを試すことができる実践形式のワークショップです。 3～4 名でチームを結成し、待ち受けるさまざまなトラブルやクエストをクリアしながら最終ミッションの達成を目指します。 各クエストをクリアするごとにポイントが付与され、最も多くのポイントを獲得したチームが勝者となります。 ゲーミフィケーションされた安全な環境で、楽しみながらさまざまなことを学ぶことができる機会を得られるワークショップです。 https://aws.amazon.com/jp/blogs/news/aws-gameday-at-aws-summit-japan-2024/ 要約すると以下のようになります。 AWSサービスを使って問題を解決する実践的なワークショップ チームで協力し、様々な課題をクリアしてポイントを獲得 ゲーム感覚で楽しみながらAWSのスキルを学べる AWS GameDayを通してさまざまなAWSのサービスを、チームで協力してゲーム感覚で楽しく学ぶことができます。 参加方法 予約必須！ 予約制なのでAWSの公式サイトから予約します。 予約フォームが公開されるタイミングですぐ埋まってしまうので運要素が結構強いです。 また、この時に取れなくてもキャンセルが出ることがあるので、たまにサイトの様子を見るとワンチャンスあるかもしれません。 予約が取れなくても諦めない！ 当日枠がある可能性があるので、会場で並んで参加することができます。 こちらの告知も公式サイトに出るのでチェックしましょう！ 今回のテーマ 今回のテーマはFrugality Fest（節約祭り）ということで、コスト削減がテーマでした。 https://aws.amazon.com/jp/blogs/news/aws-gameday-at-aws-summit-japan-2024/ コスト削減は色々な企業が課題として持っていますし、当社でも近年課題として挙げられているので、学びを業務に活かしやすいテーマだなぁと思いました。 ゲーム中に思ったこと コミュニケーション大事 最初は知らない人同士でチームを組むため、コミュニケーションが取りづらい面がありました。 しかし、わからないことを積極的に発言し、ペアやモブで解決していくことで、徐々にチームワークが形成されていきました。 自分のスキル不足を他のメンバーが補い、逆に他の人が詰まった時は一緒に解決することができました。 GameDayにおいて、コミュニケーションはとても重要だと思いました。 わからないAWSサービスでのタスクを取りやすい タスクの解決方法が詳細に記載されており、非常に分かりやすい構成になっています。 また、リソースの説明や公式ドキュメントへのリンクが提供されているため、不慣れなサービスでも取り組みやすくなっています。 各タスクには入力欄があり、指定された情報（例：作成したリソースのARN）を入力することで課題が解決されます。 入力内容が正しければ成功、間違っていればエラーが表示されるため、視覚的に進捗が確認できます。 さらに、タスクの難易度に応じてポイントが付与されるシステムは非常に魅力的で、次々とタスクをこなしたくなる意欲が湧きます。成功時の達成感は格別でした！！ 未知の体験 / 知らなかったことを学べる AWS GameDayは、普段の業務では触れる機会が少ないAWSのリソースや機能について実践的に学ぶことができる貴重な機会でした！ この経験を通じて得た新しい知識や経験は、実際のプロジェクトや日常の業務に応用するきっかけとなりました。 また、チームでの協力を通じて他のメンバーの知識や経験からも学ぶことができ、より幅広い視点でAWSの活用方法を考えられるようになりました。 結果 3位でした！ 正直あまりスコアボードを見ずに、がむしゃらに目の前のタスクを解いていました。 最初は10位くらいからのスタートで、徐々にランクを上げていき、最後の方は4位のチームと接戦で、ほぼ神頼み状態でした。 10位から3位とのことでかなり健闘したなぁと思いました。 メダルゲット！ ちなみに、チーム名「GOOD TASTE」の名前の由来は、同じチームメンバーだった当社のrubihikoが当日着ていたTシャツからきています笑 入賞チームの写真が公式サイトに載っているので、ぜひ「GOOD TASTE Tシャツ」をチェックしてみてください！ https://aws.amazon.com/jp/blogs/news/aws-gameday-at-aws-summit-japan-2024/ おわりに AWS Summit Japan自体が初参加でしたが、GameDayでほぼ丸一日拘束されていたので、ブースやセッションにはあまり参加できませんでした。 ですが、GameDayはそれでも参加する価値はあったと思っています。 GameDayは本当に楽しく学べる良い機会だと感じました。 チームで協力し、実践的な課題解決を通じて様々な学びを得ることができました。 この経験を今後の業務に活かし、さらなるスキルアップにつなげていきたいと思います。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは。NIFTY engineering ブログ運用チームです。 ブログ運用チームでは、ニフティのエンジニアに関する情報を広く世間に発信する活動を行っています。 この度、NIFTY engineering ブログの月間アクティブユーザー数（MAU）が20,000を突破しました！ おかげさまでMAUは順調に増加し、右肩上がりの成長を続けています。 MAUの推移 20,000MAUを記念して、最近のブログ運用チームの取り組みをご紹介します。 10,000MAU達成時の記事は こちら をご覧ください。 X（旧Twitter）自動投稿機能の作成 NIFTY engineering ブログを更新すると、X（旧Twitter）に自動で更新情報がポストされるようになっています。 こちらの自動投稿機能をブログ運用チームで作成しました！ ブログを更新しました！ 今回の記事は「【リレーブログ企画第二弾】24新卒リレーブログをやります！」です。 https://t.co/xm4nQtxtbw #nifty_dev #リレーブログ #新卒 — NIFTY Developers (@NIFTYDevelopers) July 19, 2024 自動でポストされた投稿 実現方法については以下の記事にまとめていますので、ぜひご覧ください。 LambdaでX APIを呼び出してみた API GatewayとLambdaでX投稿するAPIを作ってみた ZapierでX投稿するAPIを呼び出して結果をSlackに通知してみた PickUpコーナーの設置 NIFTY engineering のトップページに、PickUpコーナーを設けました。 NIFTY engineeringトップページのPickUpコーナー ブログのタグに「PickUp」を設定することで、こちらのコーナーに表示されるようになっています。 みなさんに見ていただきたい記事を集めていますので、ぜひチェックしてください！ 過去記事のX（旧Twitter）投稿 過去にブログ投稿された記事の中から、あるテーマに沿った記事をX（旧Twitter）で紹介する取り組みをしています。 直近では資格勉強に関する記事を再ポストしました！ スレッドの中でニフティの「資格取得支援制度」「資格手当」についても触れていますので、ぜひチェックしください。 【資格勉強に関する記事をピックアップ】（1/7) 過去にブログ投稿された記事の中から、資格勉強に関する記事をピックアップしてみました。 スレッド投稿で紹介いたしますので、ぜひチェックしてください！ #nifty_dev #資格 #資格勉強 #応用情報技術者試験 #情報処理安全確保支援士試験 … — NIFTY Developers (@NIFTYDevelopers) June 10, 2024 資格勉強に関する記事を紹介したポスト 社内向けレポートのブログ化 ニフティでは、社内に向けて共有したいレポートやメモを書くスペースがあるのですが、その中からブログ化できそうなものをブログ運用チーム内で選定し、代筆する作業を行っています。 また、選定時の参考になるよう「いいね」ボタンを作成したり、代筆時に作業者によるムラが起きないよう、代筆時のガイドラインを作成する等、運用しやすくなる工夫も行っています。 社内向けレポートと「いいね」ボタン リレーブログの企画 ニフティではイベントとして毎年アドベントカレンダーを実施しており、アウトプットの恒例行事となっています。 ニフティグループ Advent Calendar 2023 このようなイベントをクリスマス以外にも実施したいと思い、リレーブログを開催することにしました！ 現在は以下のリレーブログを開催中です。記事は随時更新されていきますのでお楽しみに！ 【リレーブログ企画第一弾】チーム紹介リレーブログをやります！ 【リレーブログ企画第二弾】24新卒リレーブログをやります！ 記事公開通知や週次ブログランキングをSlackにポスト アドベントカレンダーについての記事 でもご紹介しましたが、新着記事のSlack通知やブログランキングの発表を、アドベントカレンダー実施時のみではなく、通年で実施しています。 新着記事のSlack通知 特に、ブログランキングの発表は社内から好評を得ており、社員のモチベーションアップにつながっています。 四半期中に公開された記事のランキングについてはSlackで通知し、全体のランキングはLooker Studioで確認できるようにしています。 四半期中に公開された記事のランキング 全体のランキング おわりに 今回は、NIFTY engineering ブログ運用チームの最近の活動についてご紹介しました。 また、今後の活動としては以下を計画しています。 ①話題になっているテーマの観測とブログ執筆 以前、社内でブログ執筆に関するアンケートを実施したところ「ブログを書きたい気持ちはあるが、ネタが思いつかない」という意見が多く寄せられました。 そこで、IT業界で話題になっているテーマを観測し、社内から執筆者を募集する取り組みを開始しようと考えています。 この取り組みのトライアルとして、ブログ運用チームメンバーがClaudeの新機能「Artifacts」に関する記事を執筆しました！ Claudeの新機能「Artifacts」を使って簡易Todoアプリを作って遊ぶ ②「WP Sync for Notion」を活用したブログ記事のNotion連携 当ブログではWordPressを使用していますが、WordPressの操作に慣れていない社員が多く、別のプラットフォームにできないかという意見が多く寄せられていました。 そこで「WP Sync for Notion」というWordPressとNotionを連携させるためのプラグインを使用し、普段から使用しているNotionで記事の執筆ができるよう、準備を進めています。 今後も様々な取り組みを実施し、社内外から愛されるブログになるよう努めていきます。 今後もNIFTY engineering ブログをよろしくお願いいたします！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

こんにちは！今回ドメイン駆動設計（DDD）についての社内勉強会を開催したので、運営責任者の佐藤、発起人の松尾、ドメインエキスパート役の大里の３名でその様子や学びをブログで紹介したいと思います。 開催に至った背景 昨今のソフトウェア開発において、複雑なビジネスロジックを持つアプリケーションを開発する機会が増えてきています。そんな中、DDDは複雑なドメインを効果的にモデリングし、ソフトウェアに落とし込むための設計手法として注目を集めています。 今回の勉強会では、DDDの第一人者であるログラス松岡 幸一郎さんを講師としてお招きし、DDDの基本概念から実践的な適用方法まで、幅広く学ぶ機会を得ることができました。松岡さんは長年DDDに取り組んでこられた経験から、わかりやすく要点を押さえた説明をしてくださいました。 当日の様子 第１回 第1回のテーマは「モデリング実践講座」。ニフティの実際に提供しているサービスを題材に松岡さんにライブでモデリングを実施していただきました。今回選定したのは「 @niftyつなぎモバイル 」です。「 @niftyつなぎモバイル 」は、例えば引越しや事業者変更などの際に、光回線が開通するまでの期間でもすぐにネットが使用でき、しかも@nifty光や@nifty MAX光をご契約のお客様はタダという、とてもうれしいサービスです。回線が開通後もそのまま継続利用(有料）は可能です。 「 @niftyつなぎモバイル 」の料金プランは以下の３つとなります。 今回はこの「 @niftyつなぎモバイル 」の料金が決定されるロジックについて、ドメイン駆動設計を使ってモデリングを行いました。これだけでワクワクしませんか？ 実況チャンネルも準備して、いよいよスタートです。参加者はこの時点で87名！ 松岡さんの「こんばんわ」の挨拶に次々と反応するニフティのエンジニアたち。 DDD勉強会に対する期待度も上がります。 さて、講義のほうは松岡さんおすすめのsudoモデリングを使用して進みます。 ドメインエキスパートとして松岡さんのヒアリングに回答していくのは、「 @niftyつなぎモバイル 」のシステム担当者の大里さんです。 次々に魔法のように情報を絡め取って、図に落としていきます。このあたりに全く無駄がなく、そして必要な情報を聞き出していくファシリテーション力はさすがです。 それぞれの状態がどのタイミングで変化するのか、またその際の補足情報を吹き出しのコメントで追記していきます。 できあがった図は以下です。詳細はお見せできませんが、雰囲気は掴んでいただけたでしょうか？ トリガーとなるきっかけや関連する人やシステムも多くて複雑ですが、松岡さんのおかげでエンジニアだけでなく非エンジニアでも理解できる状態になりました。 「外部講師の勉強会で過去1よかった」という声もあがるほど、大盛況で第1回目の勉強会は幕を閉じました。 第２回 １回目でモデリングした内容から、実際のコードに落とし込む方法をライブ形式で学んでいきました。 DDDの概念としてドメインモデルや値オブジェクトを学んでも実際のコードに落とし込むとなるとどうすればいいのか・・・と手が止まってしまいがちです。今回の勉強会では、松岡さんのモデリングからコーディングまでの様子を見せていただくことで、机上の空論ではない実践的なDDDの手法を学ぶことができました。 (オフライン参加の様子) 感想：ドメインエキスパートを経験して 言葉での説明が難しかった箇所が図に表されることによって、受講者全員に仕様が共有できたことが体感できました。 slackでの実況で実際にコードを読んだことがないエンジニアの方々にサービスの仕様自体への質問や疑問点が多く挙げられたため、sudoモデリングでサービス関係者の認識を合わせることによる有用性を感じることができました。 知っているサービスでsudoモデリングを説明していただけたため、Youtubeやブログでご説明していただくよりも複雑なサービスでのsudoモデリングの書き起こし方を理解することができました。特にsudoモデリングと主な4つのモデルの違いや図に起こすほどでもない些細な情報の扱い方を理解することができました。 主な4つのモデルの違いについてはsudoモデリングの目的の一つはサービスの共通理解をするというところであるため、しっかりとルールに則ったユースケース図やドメインモデル図などではなくてもよいということでした。ユースケース図やドメインモデル図を作ったことがなかったのですが、sudoモデリングは複雑なサービスを図に起こすことのきっかけにしやすいと思いました。 最後に 今回の勉強会はシステム部門全体に声をかけ、2回合わせると延べ参加人数が150名を超える大規模な開催となりました。社内勉強会でこれほどの規模は運営メンバーとしても初めてということもあり、当日まで様々な心配は消えませんでしたが、終わってみると参加者の満足度が5点満点中4.8点という非常に高い評価をいただくことができました。 松岡さんのDDDに対する熱意や教え導いていただいた力がとても素晴らしかったこと、そして何よりも保守性が高く、またお客様にとって価値の高いサービスを提供したいと思うニフティのエンジニアにとって学びの大きかった勉強会となったと思います。ありがとうございました。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

この記事は、リレーブログ企画「チーム紹介」の記事です。 はじめまして！私は会員システムグループの第二開発チームでマネージャーをしております、松尾です。 会員システムグループは主にWEBサービス系の開発部隊で、中でも第二開発チームは各サブチームがそれぞれのプロダクトを持っているのが特徴です。 サブチームの紹介は後ほど詳しくしますので、まずは私の自己紹介をさせてください。 私は20数年前、新卒でニフティに入社しました。当時キーボードも打てない私でしたが、SEという響きに憧れて開発職を希望しました。その私が今日までずっとWEBエンジニアをやってこれたのはひとえに、会社の仲間たちと自分たちのサービスを作り、たくさんのお客様に使っていただける喜びを知ってしまったからだと思います。 では続いて、私たちの誇るプロダクトとサブチームの紹介をしていきたいと思います。 1. ポイントサブチーム 私たちのプロダクト https://lifemedia.jp/ このチームのプロダクトは、ニフティが運営するポイントサイト「ニフティポイントクラブ」です。ニフティポイントクラブは、運営実績20年以上、累計会員数350万人以上のサイトで、買い物やアンケート、ゲームなど、日常生活で利用するだけでポイントを獲得できます。 私たちのミッションは、このニフティポイントクラブをポイントを貯めやすく、ポイントを使いやすいサイトにすることで、お客様に少しでもお得を感じていただき、ニフティに愛着を持っていただくことです！ チームの課題 今チームが抱えている課題は、スピード感をもって価値を提供していきたいという思いを阻む、レガシーなシステムです。 2023年から約1年がかりで、サイトを構成するメインのフレームワークであるRuby on Railsのバージョンアップや、クラウド環境をAWSに移行するプロジェクトを実施してきました。データベースは旧クラウド環境に残し、フロントとバックエンドのみAWS環境に移行したことで性能問題が発生しましたが、知恵と技術を結集させ、以前より表示速度をあげることに成功しました。 そして今現在、今度はデータベースの移行および脱オラクルを計画しています。またそれに合わせてC言語でできている古いツール群が刷新されますので、プロジェクト終了時には、さらに速度が向上し使いやすいサイトになる予定です！ぜひご期待ください。 メンバー どんな時も前向きで笑顔を絶やさない細野さん 【執筆ブログ】 中途入社１年目から見たニフティとポイント開発チームの紹介 チーム１のムードメーカー、関くん 【執筆ブログ】 主催した社内勉強会の課題でアクセシビリティ的に優れているTODOリストの課題を出した話 いつもマイペースで癒し系の西根さん 【執筆ブログ】 デイリースクラムの見学に行ってデイリーを改善したい！ ニフティポイントクラブのドメイン知識の宝庫、Sさん イラストを書くこと、音楽を聞くことが大好き、Kくん 【執筆ブログ】 「Zapier」を用いたSlackでのChatOps 協力会社さんにも参画してもらいつつ、お互い助け合いの精神で各々の得意分野を発揮しながら明るく元気に開発しています。 2. マイニフティサブチーム 私たちのプロダクト https://csoption.nifty.com/myapp/ チームのプロダクトビジョンは「マイニフティアプリがあることで、安心・便利・お得にインターネットを活用できる」ことです。ニフティの会員が回線の開通から契約情報の更新、トラブルのサポートなど知りたい情報をすぐに知り、手続きが簡単にできるなど、お客様のお困りごとに寄り添って解決し、より長くニフティを利用したくなるアプリを目指しています！ チームの特徴 ニフティ内で唯一のアプリ開発チームです。 iOS (Swift)、 Android (Kotlin)を使ったアプリ開発のみならず、サーバーサイド(Go)から社内ツールまで開発する全方位のエンジニア軍団が集結！ 比較的新しいプロダクトのため、データドリブン開発をはじめ、コンテナ・サーバレスが100%、IaC・CI/CD、Clean Architecture採用など、ニフティの中でも最先端をいくモダン開発を実現できているチームです。今は新しい施策に対応する傍ら、自動テストのカバレッジをあげて品質向上へ取り組んでいます。 メンバー ファシリ力ピカイチ、ニフティの元祖スクラムマスター西野さん 【執筆ブログ】 パターンでわかる効果的なレトロスペクティブ インフラなら俺にまかせろ、いつも穏やかな川上くん 【執筆ブログ】 ISUCON13へ参戦するまでにやったこと 知識とホスピタリティの塊、参謀タイプの村松くん 【執筆ブログ】 URLProtocolでAPI Mockを作成してみる Flutter導入を虎視眈々と狙っている、オンライン配信ならお任せ柴田くん 【執筆ブログ】 Flutterコントリビューターになりました プルリク数チームNo.1、Android開発といえばLinさん 【執筆ブログ】 Gemini AIアプリを作りましょう 個性豊かなメンバーで、毎朝のデイリースクラムの前の15分間の雑談タイムでは話題が尽きることなく大盛り上がり。そのあとは業務に集中とメリハリのしっかり効いたチームです。 後編に続く 残りの２つのチームは後編でご紹介したいと思います。バトンを会員システムグループ長の小松さんにお渡しします。こちらもお楽しみに。 オプションサブチーム 採用マーケティング ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

この記事は、リレーブログ企画「24新卒リレーブログ」の記事です。 はじめまして。 新卒1年目でジョブローテーション中の山本です。 今回、24卒のブログリレー企画で、テーマは「 自由 」ということなので、私が先日 Vision AI Expo 2024 に参加した際に知った「 roboflow 」という画像認識ツールの体験記について執筆させていただきました。 AIの知識がまったくない、、、という方でも簡単に画像認識ができるツールとなっており、大学で画像認識のAIを作成していた身としてもとても衝撃を受けたツールなので、少しでも興味のある方はぜひ参考にしていただければと思います。 　▼目次 roboflowの概要 roboflowとは なぜroboflowが人気なのか 実際にroboflowを使ってみた モデルの選択 デモで動作確認 画像の選択 検出の詳細設定 結果の確認 モデルの利用方法 実際に実行してみた まとめ roboflowの概要 roboflowとは そもそもroboflowってなんぞやって話ですが、 公式によると Everything you need to build and deploy computer vision models Roboflow: Computer vision tools for developers and enterprises とのこと。 なんかすごそうですね、、、 まあざっくりいうと、このroboflowで画像認識に必要なタスクが全てできてしまうすごいツールっていうことです。 画像認識AIモデルの作成から他ユーザとのモデルの共有、作成したモデルの品質管理などが行えるツールとなっています。 このroboflowですが、アメリカでは「AIモデル構築プラットフォーム」としてのデファクトスタンダードとなっているそうで、2022年時点で 60,000ユーザ を獲得し、多くの研究・開発に利用されているようです。 なぜroboflowが人気なのか ではなぜroboflowがここまで人気なのでしょうか？ 簡単にまとめると以下の4点が人気の理由です。 使いやすさ 専門知識が少なくても、GUIで高度な画像認識プロジェクトを実現できる。 効率性 データの前処理からモデルのデプロイまでを1つのプラットフォームで完結できる。 柔軟性 様々な画像認識タスク（物体検出、セグメンテーション、分類など）に対応している。 コミュニティ 豊富な事前トレーニング済みモデルやデータセットが利用・拡張可能。 これらの要因が組み合わさることで、roboflowは幅広いユーザーにとって魅力的なプラットフォームとなっています。初心者から専門家まで、様々なニーズや要求に応えられる柔軟性と機能性を備えているため、画像認識プロジェクトにおける強力なツールとして人気を集めているようです。 AIブームが続く中で、こういったユーザが最新技術を容易に活用できる環境を提供してくれるというのはありがたいですね！ 実際にroboflowを使ってみた では、実際にroboflowを使って、いろいろな物体の検出をやっていきます。 https://roboflow.com/ 上記のページにアクセスすると、roboflowユーザが作成したAIモデルを検索することができます。 （※初回のみアカウント登録が必要になるため、Googleアカウントなどお好きな方法で登録してください） モデルの選択 まずは今回使用するモデルを選んでいきたいと思います。 特定の物体（人や車）のみを検出するモデルなどもありますが、今回はいろいろな物体を検出してみたいので、 COCO Dataset という汎用的なモデルを選択しました。 このモデルではコップや人間、猫など80種類の様々な物体検出に対応しています。対応している物体の種類に関してはOverview画面右側のCLASSESという箇所から確認することができるので、用途に合ったモデルを選択します。 デモで動作確認 roboflowではWebサイト上でどのように検出できるのかデモを行うことができる機能があるので、まずはこのモデルを試してみたいと思います。 画面左側のタブから「 Model 」を選択するとモデルの詳細画面に遷移します。 すると、さっそく画面中央に検出の結果が表示されます。 画像の選択 他の画像で試してみたい場合は、左の「 Samples from Test Set 」の箇所からすでに用意されている別の画像を選択するか、「 Upload Image or a Video File 」の箇所から写真や動画をアップロードすることでも確認することができます。 また、「 Try With Webcam 」でウェブカメラの映像からリアルタイムに検出を行うことができます。 検出の詳細設定 より細かい設定をしたい場合は 右上の「 Confidence Threshold」 と「 Overlap Threshold 」を変更することで指定できます。 Confidence Threshold（信頼度閾値）: これは、AIが物体を検出したときの確信度を表します。 例：猫の検出 高い設定：AIが「100%確実に猫だ」と判断したものだけを検出します。 低い設定：「猫らしきもの」も検出します。例えば、猫に似た模様や形のものも含まれる可能性があります。 調整により、検出の精度と範囲のバランスを取ることができます。 Overlap Threshold（重複閾値）: これは、複数の検出結果をどう扱うかを決める基準です。 例：1匹の猫を複数回検出した場合 AIが同じ猫を少しずれた位置で2回検出することがあります。 この閾値は、「どれくらい重なっていれば、それらを1つの検出結果としてまとめるか」を決めます。 これにより、同じ物体の重複検出を防ぎ、より正確な結果を得ることができます。 つまり、Confidence Thresholdは「検出の確信度」を、Overlap Thresholdは「検出結果をどうまとめるか」を制御する役割を果たします。これらの設定を適切に調整することで、より精度の高い物体検出が可能になります。 結果の確認 画面中央の画像から検出結果を確認することもできますが、 PythonやJavaScriptなどでAPIを利用し検出する場合は画像の右下にあるようなJSON形式で結果が取得できます。 モデルの利用方法 実際に自身のプログラムでモデルを利用して検出をしていきます。 画面下のほうにスクロールすると「Code Snippets」という箇所があり、言語別に具体的な使いかたが説明されています。 PythonのHosted APIの箇所を見ると以下のコマンドでライブラリを読み込むことができ、 pip install inference-sdk 以下のコードでAPIを利用して検出ができると書いてあります。 from inference_sdk import InferenceHTTPClient CLIENT = InferenceHTTPClient( api_url="https://detect.roboflow.com", api_key="vOwAVfDFTbgLcWxJrx5g" ) result = CLIENT.infer(your_image.jpg, model_id="coco/24") 実際に実行してみた 以下のコードを実際に実行して結果が取得できるか試してみました。 from inference_sdk import InferenceHTTPClient import pprint CLIENT = InferenceHTTPClient( api_url="https://detect.roboflow.com", api_key="vOwAVfDFTbgLcWxJrx5g" ) result = CLIENT.infer("input.jpg", model_id="coco/24") # 結果出力 pprint.pprint(result) 使用した画像はこちらです↓ 結果は以下のようになりました。 {'image': {'height': 4096, 'width': 3072}, 'inference_id': '61284435-9a72-4432-b283-2210f3e73318', 'predictions': [{'class': 'cat', 'class_id': 15, 'confidence': 0.9505542516708374, 'detection_id': 'f4b4a946-a391-4173-9cda-9782db7788bc', 'height': 2112.0, 'width': 1788.0, 'x': 1910.0, 'y': 2472.0}], 'time': 0.6150403930000721} 結果を見ると、 'class': 'cat' となっているので、しっかりと猫が1匹検出されているのがわかります。 ただ、JSONで結果を取得するだけではわかりづらいのでコードを少し変更して、結果を画像に描画してみました。(OpenCVを利用） 正しく検出できていそうです！ 　▼描画に使用したコード from inference_sdk import InferenceHTTPClient, InferenceConfiguration import pprint import cv2 import sys # 信頼度の閾値 CONFIDENCE = 0.5 # 画像パスを実行コマンドから取得 image_path = sys.argv[1] if len(sys.argv) > 1 else "input.jpg" # 詳細設定 custom_configuration = InferenceConfiguration( # モデルの信頼度の閾値 confidence_threshold=CONFIDENCE, # クライアントのダウンサイジングを無効にする client_downsizing_disabled=True ) # InferenceHTTPClientの初期化 CLIENT = InferenceHTTPClient( api_url="https://detect.roboflow.com", api_key="vOwAVfDFTbgLcWxJrx5g" ) # 座標系の修正 def convert_coordinates(prediction, image_width, image_height): """ roboflowとcv2の座標系を変換する関数 Args: prediction (dict): 座標を含む予測結果の辞書。 image_width (int): 画像の幅。 image_height (int): 画像の高さ。 Returns: tuple: 変換された座標 (x, y, width, height)。 """ x = prediction["x"] - prediction["width"] / 2 y = prediction["y"] - prediction["height"] / 2 width = prediction["width"] height = prediction["height"] # 座標を整数に変換し、画像の範囲内に収める x = max(0, min(int(x), image_width - 1)) y = max(0, min(int(y), image_height - 1)) width = max(1, min(int(width), image_width - x)) height = max(1, min(int(height), image_height - y)) return x, y, width, height # 推論の実行 with CLIENT.use_configuration(custom_configuration): # 画像の読み込み image = cv2.imread(image_path) # ファイルが存在しない場合にエラーを出力 if image is None: print("Error: Image file not found.") sys.exit(1) # 推論の実行 result = CLIENT.infer(image, model_id="coco/24") # 結果の出力 pprint.pprint(result) # クラス・バウンディングボックスの描画 for prediction in result["predictions"]: x, y, width, height = convert_coordinates(prediction, image.shape[1], image.shape[0]) class_name = prediction["class"] confidence = int(prediction["confidence"] * 100) put_text = class_name + " " + str(confidence) + "%" cv2.rectangle(image, (x, y), (x + width, y + height), (0, 255, 0), 10) cv2.putText(image, put_text, (x, y - 5), cv2.FONT_HERSHEY_SIMPLEX, 5, (0, 255, 0), 10) # 描画結果を保存 cv2.imwrite("result.jpg", image) ちなみに、上記のコードではconfidence（信頼度）を指定できるようにしているので、閾値を0.2に変更してみると、以下の画像のように結果が変わりました。 ピントが合わずにボケている人物の箇所もしっかりとpersonと認識されています。 これは信頼度が低い（ボケていて人間かどうか微妙なライン）の箇所もconfidenceの閾値を下げることで検出結果に含まれるようになったということです。 以下に他の画像の検出結果もまとめました。 このモデルが対応している物体に関しては正確に検出ができていますね！ まとめ このようにroboflowを利用することで少ないコードで画像認識ができてしまいます。 今回は様々な物体の検出に対応したモデルを利用しましたが、人の顔を検出するモデルを利用して顔の箇所にモザイクを入れたり、来客数を継続的に計測し販売戦略を立てたりなど、アイデア次第では様々な活用が期待できますね。 また、roboflowにはまだまだ多くの機能があります。 今回使用した COCO Dataset はハムスターの検出に対応していませんが、追加でハムスターを検出させたい場合、自身で作成したワークスペースに、 COCO Dataset のモデルをインポートして、そこにハムスターのデータを追加することでモデルを拡張することが可能です。 新たなデータを追加する際にも自動でアノテーションをしてくれる機能などもあります。 他にも動画から写真を切り出して、自動でアノテーションをしてくれたり、作成したモデルの品質管理をしてくれたりなど魅力的な機能が多く備わっています。 今後、AI技術がますます身近になっていく中で、roboflowのような手軽にAIモデルに触れることのできるツールの存在は、イノベーションを加速し、さらなる発展に寄与していくと思います。もしこの記事で少しでも興味を持っていただけた方は、ぜひビジネスや研究、個人利用など様々な場面でroboflowの活用を検討してみてください！ 次回は、塚崎さんです。 どんな記事になるのかワクワクですね♪ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

SREチームの島です。 8月3日、4日に開催された SRE NEXT 2024 にて、「FourKeysを導入したが生産性向上には至らなかった理由」というタイトルで登壇させていただきました。 登壇した理由 今回このテーマで登壇した理由は、私自身の経験を共有することでFourKeysの導入を考えている方々の参考になればと考えたからです。 私たちはFourKeysを用いた仮説検証を実施し、その過程で指標への解像度は確かに上がりました。しかし、開発生産性の向上には結びつかなかったという貴重な経験をしました。 FourKeysは注目を集めている概念ですが、単に導入すれば生産性が向上するわけではありません。私たちが直面した課題や、得られた教訓を共有することで、みなさまのFourKeys導入や開発プロセス改善の一助となることを願っています。 NIFTY Tech Talk開催のお知らせ 登壇で十分に触れられなかった内容については、8月27日に開催予定の「NIFTY Tech Talk #21」にてお話しする予定です。興味のある方はぜひご参加ください。 NIFTY Tech Talk #21 〜SRE関係イベント登壇者のAfter Talk〜 登壇の様子 Photo by SRE NEXT Staff Ask the Speakerにもお越しいただき、ありがとうございました。 最後に 約1年半前にSREチームに加わり、昨年初めてSRE NEXTに参加しました。 当時はまだ分からないことだらけで日々苦戦していた私にとって、初めて参加したSRE NEXTは華々しく輝いて見えました。 登壇者も参加者も目を輝かせて楽しそうに発表したり話を聴いたりしている姿が刺激的で、今でも鮮明に記憶しています。 そのような憧れの舞台に今年立つことができ、とても光栄でした。 SRE NEXT運営のみなさま、視聴いただいたみなさま、本当にありがとうございました！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは。ニフティ株式会社の添野隼矢です。 最近、開発業務でSvelteKitに触れる機会がありました。そのシンプルさと学習コストの低さから、未経験者の私でもすぐに開発に活かせることを実感しました。 今回は、そのSvelteKitのエラーハンドリングについてご紹介します。 基本的なエラーハンドリング まずSvelteKitには、エラーをスローするための方法が以下の2つの方法があります。 error（SvelteKit 1.x系ではthrowが必要です。） throw new Error これらの違いについて、説明していきます。 error こちらは、アプリケーション内で発生することが予想されるエラーに使用されます。 例えば、以下のエラーの場合です。 403（アクセス権限がない場合などのエラーコード） 404（ユーザーが存在しない場合やリソースが見つからない場合などのエラーコード） 409（クライアントからのリクエストがサーバー上の現在の状態と競合しているときに発生するエラーコード） 500（サーバー側に発生した問題でリクエストが処理されなかったことを示すエラーコード） 利用例は以下のようになります。 import { error } from '@sveltejs/kit'; export const load = async () => { const user = await getUser(); if (!user) { throw error(404, { message: 'ユーザ情報が見つかりませんでした', code: 'USER_NOT_FOUND' }); } const permissions = await getUserPermissions(); if (!permissions.includes('ACCESS_RESOURCE')) { throw error(403, { message: 'アクセス権限がありません', code: 'FORBIDDEN' }); } return { user, permissions }; }; throw new Error こちらは、想定外エラーが起こった場合やプログラムのバグの際に使用するものです。 こちらは標準のJavaScriptのエラーハンドリング方法のため、throwが必要です。 利用例は以下のようになります。 export const load = async () => { try { const data = await fetchData(); return { data }; } catch (e) { throw new Error('データの取得に失敗しました'); } }; カスタムエラーページの作成 SvelteKitでは、 +error.svelte ファイルを作成して、カスタムエラーページを作成することができます。 カスタムエラーページを作成することによって、ユーザーフレンドリーな体験を提供できます。 試しに先程の403と404のerrorのカスタムエラーページを作成すると以下のようになります。 <script lang="ts"> const dict = { USER_NOT_FOUND: 'ユーザ情報を再度ご確認いただき、ログインしてください。', FORBIDDEN: 'アクセス権限がありません。' }; export function load({ error, status }) { return { props: { error, status } }; } </script> <svelte:head> <title>{status} - エラー</title> </svelte:head> <main> <h1>{status}</h1> <p>{@html dict[error.code]}</p> </main> 上記の例では、エラーメッセージを辞書型で管理し、対応するエラーメッセージを表示しています。 これにより、エラーコードごとに異なるメッセージを簡単に設定できます。 <p>{@html dict[error.code]}</p> の部分は、この場合には以下が表示されます。 エラーコードがUSER_NOT_FOUNDの場合、辞書に基づいて「ユーザ情報を再度ご確認いただき、ログインしてください。」と表示されます。 エラーコードがFORBIDDENの場合、辞書に基づいて「アクセス権限がありません。」と表示されます。 ※上記以外のエラーコードの場合、辞書に定義されていないため、undefinedが表示される可能性があります。 まとめ SvelteKitのエラーハンドリングは非常に柔軟で、単純なエラーから複雑なエラーページのカスタマイズまで対応できます。 適切なエラーハンドリングを実装することで、ユーザーエクスペリエンスを向上させ、問題のデバッグを容易にすることができます。 詳細な情報については、 公式ドキュメント を参照してください。 カスタムエラーページを簡単に作成したい場合は、ぜひSvelteKitを使ってみてください。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

この記事は、リレーブログ企画「24新卒リレーブログ」の記事です。 はじめに こんにちは。新卒1年目のkeyliumです。開発生産性に関心があります。 シェルの入力でも普段使っているエディターのように、行・単語ごとのジャンプや削除などをしてみたいと思ったことはありませんか？ エディターでの快適な操作性をシェルでも再現できると、生産性がぐっと向上します。そんな便利な設定を可能にするのが、 .inputrc ファイルです。 筆者の環境 OS: Windows Terminal: Windows Terminal  　Tera Termを使用している場合、一部のキーバインドや cat -v が期待通りに動作しないことがあります。 Shell: Bash (GitBash) .inputrcとは？ .inputrc ファイルは、GNU Readlineライブラリの設定ファイルです。Readlineは、Bashを始めとする多くのシェルやコマンドラインツールで使われており、コマンドラインでの入力編集を制御しています。 このファイルをカスタマイズすることで、自分好みのキーバインディングや入力方法を設定することができます。 デフォルトの設定 まずは、デフォルトでどのようなキーバインディングが設定されているのかを見てみましょう。 デフォルトのBashシェルはEmacsスタイルのキーバインディングを使用しています。以下に、いくつかの主要なデフォルト設定を紹介します： Ctrl + A : 行の先頭に移動 Ctrl + E : 行の末尾に移動 Ctrl + K : カーソルから行の末尾まで削除 Ctrl + U : カーソルから行の先頭まで削除 Ctrl + W : カーソルの前の単語を削除 Ctrl + Backspace : カーソルの前の単語を削除 Ctrl + Delete : カーソルの後の単語を削除 Ctrl + L : 画面をクリアにする Alt + F : 次の単語に移動 Alt + B : 前の単語に移動 これらのデフォルト設定を確認するために、シェルを開いて実際に試してみてください。 おすすめの キーバインディング # PageUp キーで履歴検索 "\e[5~": history-search-backward # PageDown キーで履歴検索 "\e[6~": history-search-forward # Ctrl + P で前のコマンドを表示する (上キーでも可) "\C-p": previous-history # Ctrl + N で次のコマンドを表示する (下キーでも可) "\C-n": next-history # Ctrl+R でコマンド履歴を逆方向から検索 "\C-r": reverse-search-history # Alt + R で行を元に戻す "\er": revert-line history-search-backward デフォルトキーバインディング: PageUp 動作 : 現在のコマンドラインに部分的に入力されたテキストに一致する履歴のコマンドを、逆方向に検索します。 使用例 : 例えば、コマンドラインに「echo」と入力し、その状態で history-search-backward を実行すると、履歴の中で「echo」 で始まる コマンドを逆方向に検索して表示します。 利点 : 一部入力されたコマンドに基づいて履歴を絞り込みたい場合に便利です。 history-search-forward デフォルトキーバインディング: PageDown 動作 : history-search-backward の逆の操作です。 previous-history デフォルトキーバインディング: Ctrl + P   ↑ 動作 : 現在のコマンドラインの入力に関係なく、単に履歴の中で1つ前のコマンドを表示します。 使用例 : コマンドラインに何も入力されていない状態で previous-history を実行すると、履歴の中で直前のコマンドが表示されます。 利点 : コマンド履歴を一つずつ遡って確認したい場合に便利です。 next-history デフォルトキーバインディング: Ctrl + N   ↓ 動作 : previous-history の逆の操作です。 reverse-search-history デフォルトキーバインディング: Ctrl + R 動作 : インクリメンタルサーチを使用して、コマンド履歴を逆方向に検索します。検索中にリアルタイムで結果が更新されます。 使用例 : Ctrl+Rを押すと、 (reverse-i-search) プロンプトが表示され、キーワードを入力するたびに、履歴から一致するコマンドが順次表示されます。 利点 : インタラクティブに履歴を検索できるため、目的のコマンドを素早く見つけることができます。 character-search デフォルトキーバインディング: Ctrl + [ 動作 : カーソルから順方向に特定の文字を検索し、最初に見つかった位置にカーソルを移動します。 使用例 : Ctrl+[ を押して、特定の文字を入力すると、カーソルから順方向にその文字を検索します。 利点 : コマンドライン内の特定の文字にすばやく移動したい場合に便利です。 character-search-backward デフォルトキーバインディング: Alt + Ctrl + [ 動作 : character-search-backward  の逆の動作です。 revert-line デフォルトキーバインディング: Alt + R 動作 : カーソルのある行を元の状態に戻します。元の状態とは、行が最初に表示された時の内容です。コマンドを編集してしまった場合に、編集前の状態に戻すことができます。 使用例 : 例えば、 history-search-backward などで現在の行に入力されたコマンド を変更してしまったが、元のコマンドに戻したい場合に使用します。 kill-whole-line デフォルトキーバインディング: これはデフォルトでは設定されていません。次の章で設定します。 動作 : カーソルのある行全体を削除します。 使用例 : 例えば、現在の行に長いコマンドが入力されていて、その行全体を削除したい場合に使用します。 .inputrcを使ってカスタマイズする デフォルト設定を理解したら、自分のニーズに合わせて .inputrc ファイルをカスタマイズしてみましょう。 .inputrc ファイルはホームディレクトリに置き、以下のような形式で設定を記述します。この設定は私が使っている設定です。： # コメントは#で始めます # Alt + qで行削除 "\eq": kill-whole-line # ↑↓キーで履歴検索（PageUp, PageDownが押しづらい人向け） "\e[A": previous-history "\e[B": next-history # TABキーで、補完する単語を可能な補完リストの 1 つの一致に置き換えます。 # menu-completeを繰り返し実行すると、可能な補完リストを順に進み、各一致を順番に挿入します。 TAB: menu-complete # Shift + TAB で逆方向にmenu-complete "\e[Z": menu-complete-backward # 補完で大文字小文字を無視する set completion-ignore-case on .inputrc ファイルの変更を適用するには3つの方法があります。以下のどれかを実行しましょう。 シェルを再起動する 以下のコマンドを実行する： bind -f ~/.inputrc C-x C-r を押す（Ctrl + xを押してからCtrl + rを押す） これで .inputrc に書いた機能が有効になったはずです。 履歴に関する環境変数 履歴を参照することが多いため、履歴に関する環境変数を紹介します。以下の設定は .bashrc に書きます。この設定は私が使っている設定です。 # 重複する連続コマンドと、先頭に半角スペースが入っているコマンドを履歴に記録しない export HISTCONTROL=ignoredups:ignorespace # 履歴に保存するコマンドの最大数を設定(デフォルトは500) export HISTSIZE=10000 # 履歴ファイルに保存するコマンドの最大数を設定(デフォルトは500) export HISTFILESIZE=10000 # 履歴に保存しないコマンドのパターンを指定. # 複数ある場合は":"で区切る export HISTIGNORE="ls" # 履歴に保存されるコマンドのタイムスタンプの形式を指定 export HISTTIMEFORMAT="%F %T " HISTCONTROL HISTCONTROL は、シェル（特に Bash）でコマンド履歴の動作を制御するための環境変数です。 HISTCONTROL を使用すると、コマンド履歴に保存されるコマンドの種類を制御できます。以下に、 HISTCONTROL の主なオプションを説明します。 HISTCONTROL のオプション ignoredups 重複する連続したコマンドを履歴に保存しません。 例: ls コマンドを2回連続で実行すると、1回分だけ履歴に保存されます。 ignorespace 空白で始まるコマンドを履歴に保存しません。 例: ls （スペースが前にある ls ）は履歴に保存されません。 ignoreboth ignoredups と ignorespace の両方を適用します。 重複する連続コマンドと、空白で始まるコマンドを履歴に保存しません。 erasedups 履歴全体から重複するコマンドを削除します。最新のものだけが保存されます。 例: 履歴に ls が複数回含まれている場合、最新の ls だけが残ります。 HISTSIZEとHISTFILESIZE HISTSIZE 履歴に保存するコマンドの最大数を設定します。 この設定は、 シェルがメモリ内で保持する履歴の数 を制御します。 シェルセッション中に使用され、シェルを閉じるとクリアされます（履歴ファイルに保存されない場合）。 HISTFILESIZE 履歴ファイルに保存するコマンドの最大数 を設定します。 これは、シェルセッションが終了するときに .bash_history などの履歴ファイルに保存されるコマンドの数を制御します。 次のシェルセッションで履歴を読み込むために使用されます。 HISTTIMEFORMAT HISTTIMEFORMAT 履歴に保存されるコマンドのタイムスタンプの形式を指定します。 フォーマットは date コマンドの形式と同じです。 export HISTTIMEFORMAT="%F %T " という設定を行うと、履歴にタイムスタンプが追加されます。 history コマンドを使うと YYYY-MM-DD HH:MM:SS の形式で表示されます。 Q&A Q: キーがどの制御文字に対応するかを知る方法は？ A: cat コマンドを使う 最も簡単な方法の一つは、シェルで cat コマンドを使うことです。このコマンドは、入力されたキーシーケンスをそのまま表示してくれます。 シェルを開き、 cat -v コマンドを実行します： 次に、調べたいキーを押します。例えば、Ctrlキーを押しながら左矢印キーを押し、Enterを押すと、 ^[OD が出力されるはずです。これは、Ctrl + 左矢印キーが \eOD に対応することを意味します。 ^[ は \e に対応し、 OD がそのまま制御文字として使用されます。 終了するには、Ctrl + D を押します。 機能しない機能 forward-search-history (C-s) 履歴を最初の方から検索する機能。実行するとフリーズする。C-cで抜けられます。 set mark (C-@) 矩形選択を行う機能。これも機能しません。 参考資料 Readline – ArchWiki https://wiki.archlinux.jp/index.php/Readline readline(3) — Arch manual pages https://man.archlinux.org/man/readline.3 history コマンドに日時を付与する – Qiita https://qiita.com/bezeklik/items/56a597acc2eb568860d7   最後に シェルの入力設定をカスタマイズすることで、コマンドラインでの作業効率を大幅に向上させることができます。 .inputrc ファイルを利用して、自分好みのキーバインドや動作を設定することで、コマンドライン操作がより直感的で便利になるでしょう。 シェルのカスタマイズを通じて、日々の作業がよりスムーズに、そして効率的に進むことを願っています。 以上、.inputrc の設定 -Readlineのキーバインディングを知って開発生産性を向上させる-でした。 ありがとうございました。 次回は山本さんです。 楽しみにしています。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ テーマ 2024年6月20日、21日にAWS社の大規模イベント AWS Summit Japan 2024 が開催されました。AWS Summit Japan（以前はTokyo）には毎年ニフティのエンジニアが多く参加しています。 NIFTY Tech Talk #20では、AWS Summit Japan内で行われた実践的なチーム学習演習イベントであるAWS GameDayの入賞チームメンバーから、AWS GameDayの楽しさや学び、あるいは攻略法について語ってもらいます。 ご参考 AWS GameDay @ AWS Summit Japan 2024 結果発表！！ ※ AWS GameDayはその性質上内容のネタバレは厳禁とされてますため、ネタバレを避けた範囲でのトークとなります。ご承知おきください 開催概要 コンパスにて開催しました https://nifty.connpass.com/event/325653/ 資料 こんな方におすすめ AWS GameDayに興味があるが参加したことがない方 AWSを使っているがAWS Summit Japanに参加したことがまだない方 参加したことはあるが、楽しみ方をより知りたいという方 AWS GameDayとは https://aws.amazon.com/jp/gameday/ ある課題に対して AWS サービスで解決するための対応力や実装スキルを試すことができる実践形式のワークショップ 3～4 名でチームを結成 さまざまなクエストをクリアしていく！ 最も多くのポイントを獲得したチームが勝者 学びについて 知らなかったことを学べる 普段扱っていない領域を体験できる チームメンバーとの協力・コニュニケーション 他社のエンジニアと知り合いに 課題解決力が付く 実践形式のワークショップで色々学びがあります。普段触ったことのないリソースや機能について体験できるかもしれません。 そこで得た学びはサービスに適用できるきっかけになるかもしれません！ 心構え 事前準備 がんばって予約を取る 予約が取れなくても、当日並ぶことで入れるかも！？ 資格は無くても大丈夫 グループワーク コミュニケーション取って課題解決しよう 仲良くなるのが大事 モブプロ 後日 イベントレポートを書こう 仕事に適用できるか検討してみよう まとめ AWS Summitの中でも特に大きなコンテンツであるAWS GameDay、参加することで様々な学びがありました。 ここでしか得られない学びと、活かしていきたいと思います。 AWS GameDayは他の予定より優先して参加する価値あり！ 見れなかったセッションは後でアーカイブを確認しよう AWS Summitはお祭り、楽しもう ノベルティ ここでしか体験できないイベントが盛り沢山 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も常時受け付けています。 カジュアル面談 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering

はじめに 最近の尋常ではない暑さに、ついに日傘を買った宮本です。 今回は、Astroでのコンポーネントテストについて紹介します。ただし、あくまでExperimentalな機能を使ったものであり、今後変更される可能性があるのでご注意を。 これまでコンポーネント単体をレンダリングする手段のなかったAstroですが、ついに今年の5月にリリースされた 4.9 にて、コンポーネント単体をレンダリングできるContainer APIがExperimental機能として追加されました。あくまでExperimentalということもあり、軽く触った感じだとやや機能が足りない部分を感じましたが、それでもコンポーネントテストが不可能だったこれまでに比べると大きな進歩です。 それはそれとして、この記事を書こうと思いながらもサボっていたら、いつの間にか4.12までAstroのバージョンが進んでいました。リリース頻度がとても早いです。 環境 Astro: v4.12.3 Vitest: 2.0.3 node-html-parser: 6.1.13 今回の記事は、Astro公式で提供されている、 Vitestを利用したテストテンプレート を元にファイルを追加して作成しました。手元ですぐに再現できるので、気になった方はぜひ試してみてください。 npm create astro@latest -- --template with-vitest コンポーネントテスト 次のようなCardコンポーネントをテストします。 --- // src/components/Card.astro type Props = { title: string; }; const { title } = Astro.props; --- <div> <h3> {title} </h3> <div class="card-body"> <slot /> </div> </div> Cardコンポーネントにはslotとpropsがあるため、テストではこれが正常に記述されているかを確認してみます。 リリース時の4.9.0だとpropsが指定できませんが、4.9.2からはpropsの指定も可能になっています。また、そのほかにもページルーティング時に利用するparamsなども指定可能です。レンダリング時に指定可能なオプションは 公式ドキュメント から確認できます。 // src/components/Card.spec.astro import { experimental_AstroContainer as AstroContainer } from 'astro/container'; import { expect, test } from 'vitest'; import Card from './Card.astro'; test('Card with slots and props', async () => { const container = await AstroContainer.create(); // resultにはコンポーネントをHTMLとして出力した文字列が挿入される const result = await container.renderToString(Card, { props: { title: 'タイトル' }, slots: { default: 'コンテンツ' } }); expect(result).toContain('タイトル'); expect(result).toContain('コンテンツ'); }); このとき、resultにはコンポーネントをhtmlとして出力した場合の文字列が挿入されています。そのため実施しているのは、あくまで文字列の比較テストであるという点に注意が必要です。 上記のテストでresultに入る文字列は以下のようなものです（data-astro-source-fileの内容は変更してます）。テストの途中でconsole.logなどを使って出力するとわかりやすいです。 <!DOCTYPE html><div data-astro-source-file="~/vitest-astro/src/components/Card.astro" data-astro-source-loc="8:6"> <h3 data-astro-source-file="~/vitest-astro/src/components/Card.astro" data-astro-source-loc="9:7"> タイトル </h3> コンテンツ </div> 見てわかる通り、出力されるhtml文字列はローカルのdevサーバを立ち上げた場合と同じものです。そのため、data属性として data-astro-source-file や data-astro-source-loc が自動的に含まれたタグが出力されています。本番環境と完全に同じではないため、注意が必要です。 これを削除したい場合は、 vitest.config.ts にてテスト時に 開発ツールバー機能をオフにする ことで表示されなくなります。 /// <reference types="vitest" /> import { getViteConfig } from "astro/config"; export default getViteConfig( { test: {}, }, { // 開発時のツールバー機能を無効化 devToolbar: { enabled: false }, } ); <!DOCTYPE html><div> <h3 data-testid="title"> タイトル </h3> <div class="card-body" data-testid="body"> コンテンツ </div> </div> また、それ以上に文字列の比較になってしまうため、繰り返しなどを使っていて同じ文字列が複数表示されている場合に、コンポーネントの想定通りの場所にpropsやslotで挿入されているか確実とは言えない点も厳しいです。 そこで、文字列として出力されたhtmlをパーサーを使って解釈し、もう少し精度の高いテストをしてみます。今回はパーサーとして node-html-parser を利用したテストに変更してみました。 yarn add -D node-html-parser // src/components/Card.spec.astro import { experimental_AstroContainer as AstroContainer } from 'astro/container'; import { expect, test } from 'vitest'; import Card from './Card.astro'; import { parse } from 'node-html-parser'; test('Card with slots and props', async () => { const container = await AstroContainer.create(); // resultにはコンポーネントをHTMLとして出力した文字列が挿入される const result = await container.renderToString(Card, { props: { title: 'タイトル' }, slots: { default: 'コンテンツ' } }); const root = parse(result); const title = root.querySelector('h3'); const body = root.querySelector('.card-body'); expect(title?.innerText).toContain('タイトル'); expect(body?.innerText).toContain('コンテンツ'); }); パーサーを用いてhtml文字列を解析することで、より厳密にテストすることができるようになったと思います。もちろんdata-testidのようなテスト用のデータ属性を与えてテストすることも可能です。 注意点 いささかしつこいくらいの注意点になりますが、前提として現在のContainer APIはあくまでExperimental機能であり、今後変更される可能性があります。 RFC 内でも、小さな機能としてリリースしてからフィードバックをもとに改善していきたいと記述されています。 テストから話は離れますが、このContainer APIをもとに AstroのStorybook対応 をするような展望もあるようなので、それに合わせて変更がある可能性もあります。（むしろ、テスト以上にStorybook対応を楽しみにしていた人も多い気がしています。が、これも今のContainer APIですぐに対応するのは難しい模様……。残念です） また、それ以外にもいくつか現状だとテストできないことがあります。 クライアント側で動作するscriptタグ（とstyleタグ）は、html文字列には含まれません。is:inlineを指定すれば含まれますが、これをテストするのはなかなか厳しいと思います。 クライアント側で動作するロジックをテストしたい場合は、関数として別ファイルで定義し、コンポーネント側ではscriptタグ内でimportして利用するのが現実的だと思います。 // src/lib/math.tsで定義して別途テストする export const add = (a:number,b:number) => a+b; <script> // コンポーネント側ではimportして利用 import {add} from "../lib/math.ts"; console.log(add(1, 2)); </script> もっとも、それでもテストし辛いような複雑なDOM操作やクラス追加などを実施するロジックがある場合は、そもそも部分的にReactやSvelteで作成したコンポーネントを用いるのが良いかもしれません。目的に応じてコンポーネントをAstro以外で作成することができるのもAstroの良い点です。 一方で、Astroコンポーネント内でReactやSvelteを利用している場合は、また 別途設定が必要 になるため注意が必要です。 さいごに 今回はAstroでのコンポーネントテストについて紹介しました。 もともとAstroにはコンポーネント単体を独立してレンダリングする機能がなく、そのためコンポーネントテストができないという課題がありましたが、Container APIの追加によって実現できることが増加しました。 まだできることも少ないですが、Astroは半月に1回ほどのペースで頻繁に機能追加を伴うリリースが行われているため、今後がより楽しみです。 参考 Astro 4.9 | Astro Astro Container API (experimental) | Docs data-astro-source-file added when devToolbar disabled · Issue #9324 · withastro/astro node-html-parser – npm roadmap/proposals/0048-container-api.md at rfc/container-api · withastro/roadmap Support for Astro components · Issue #18356 · storybookjs/storybook ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは。会員向けアプリ「 マイ ニフティ 」の開発運用をしている村松です。 現在、マイ ニフティでは現在iOS・Androidアプリにユニットテストを追加しています。 その中で、iOSアプリでのAPIと通信する部分のユニットテストをサードパーティのMockライブラリなどを使わずに簡単に書くことができたので、紹介したいと思います。 AppleのWWDC18のセッションの「 Testing Tips & Tricks 」で紹介されている、URLProtocolを利用したMockのやり方を参考にしています。 背景 マイ ニフティ iOSアプリでは、通信処理では Alamofire を利用しています。APIからデータ取得する部分のユニットテストを追加する際にどのようにしていくか、調査すると、以下のような手段がありました。 Mockライブラリを使う DockerなどでAPIサーバーを立てる しかし、通信処理で複雑なことはしていないため、Mockライブラリを追加するほどではなく、また、DockerなどでAPIサーバーを立てるのは管理コストやテスト実行時間の点で、採用しにくいなと感じていました。 そんな中、URLProtocolを利用する方法だと、自分たちで簡単にMockを作成できそうだったので、採用してみました。 通信処理のMockの実装 URLSessionはURLProtocolのサブクラスで実際の処理を行うため、通信処理のMockをURLProtocolのサブクラスで実装し、URLSessionで利用するようにすれば、Mockを実現することができます。 URLProtocol のサブクラスで実装すべきメソッドは以下の4つあり、startLoading で通信処理のMockを実装します。 canInit canonicalRequest startLoading stopLoading public class LoginAPIMockURLProtocol: URLProtocol { override open class func canInit(with request: URLRequest) -> Bool { return true } override open class func canonicalRequest(for request: URLRequest) -> URLRequest { return request } // 通信開始時に呼ばれるメソッド // Mock処理を実装する override open func startLoading() { } // 通信停止時に呼ばれるメソッド override open func stopLoading() { } } Mockの実装は求められるテスト粒度に応じて、実装していく流れになり、細かくやれば、 HTTPメソッドが正しいか リクエストパラメーターが正しいか APIで想定されているエラーを出し分ける などといったMockを実装することができます。 URLProtocolの実装ではURLProtocolClientのclientプロパティで、クライアント側に通信結果を伝えます。 通信成功時は urlProtocol(_:didReceive:cacheStoragePolicy:) urlProtocol(_:didLoad:) urlProtocolDidFinishLoading(_:) を呼び出します。 client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed) client?.urlProtocol(self, didLoad: responseData) client?.urlProtocolDidFinishLoading(self) 通信失敗時は urlProtocol(_:didFailWithError:) を呼び出します。 self.client?.urlProtocol( self, didFailWithError: APIMockError( errorDomain: "APIMockError.LoginAPIMockProtocol", errorUserInfo: [NSLocalizedDescriptionKey: "HTTPメソッドがPOSTではありません"] ) ) 以上を踏まえて、実装したコードが以下のコードとなります。 import Foundation import XCTest struct APIMockError: CustomNSError { var errorDomain: String var errorCode = 1 var errorUserInfo: [String: Any] } public class LoginAPIMockURLProtocol: URLProtocol { override open class func canInit(with request: URLRequest) -> Bool { return true } override open class func canonicalRequest(for request: URLRequest) -> URLRequest { return request } // 通信開始時に呼ばれるメソッド // Mock処理を実装する override open func startLoading() { guard let originalRequest = task?.originalRequest else { self.client?.urlProtocol( self, didFailWithError: APIMockError( errorDomain: "APIMockError.LoginAPIMockProtocol", errorUserInfo: [NSLocalizedDescriptionKey: "リクエストを取得できませんでした"] ) ) return } guard let method = originalRequest.httpMethod, method == "POST" else { self.client?.urlProtocol( self, didFailWithError: APIMockError( errorDomain: "APIMockError.LoginAPIMockProtocol", errorUserInfo: [NSLocalizedDescriptionKey: "HTTPメソッドがPOSTではありません"] ) ) XCTFail("HTTP Method is not POST") return } guard let httpBody = originalRequest.httpBody else { self.client?.urlProtocol( self, didFailWithError: APIMockError( errorDomain: "APIMockError.LoginAPIMockProtocol", errorUserInfo: [NSLocalizedDescriptionKey: "リクエストボディが空です"] ) ) XCTFail("Request Body is empty") return } // リクエストJSONのデコード let jsonDecoder = JSONDecoder() jsonDecoder.keyDecodingStrategy = .convertFromSnakeCase jsonDecoder.dateDecodingStrategy = .iso8601 let loginUser: LoginUserAPIModel do { loginUser = try jsonDecoder.decode(LoginUserAPIModel.self, from: httpBody) } catch { self.client?.urlProtocol(self, didFailWithError: error) XCTFail("Request JSON is Invalid") return } let response: HTTPURLResponse var responseData: Data let jsonEncoder = JSONEncoder() jsonEncoder.keyEncodingStrategy = .convertToSnakeCase // 引数でMockの処理を変更している switch loginUser.password { case "200": // 正常の場合 let token = TokenAPIModel(accessToken: "accessToken") response = HTTPURLResponse( url: originalRequest.url!, statusCode: 200, httpVersion: "HTTP/2", headerFields: ["Content-Type": "application/json"] )! guard let data = try? jsonEncoder.encode(token) else { self.client?.urlProtocol( self, didFailWithError: APIMockError( errorDomain: "APIMockError.LoginAPIMockProtocol", errorUserInfo: [NSLocalizedDescriptionKey: "TokenAPIModel構造体のエンコードに失敗しました"] ) ) return } responseData = data case "401": // エラーの場合 let userAPIErrorResponse = APIErrorResponse(error: "401 error") response = HTTPURLResponse( url: originalRequest.url!, statusCode: 401, httpVersion: "HTTP/2", headerFields: ["Content-Type": "application/json"] )! guard let data = try? jsonEncoder.encode(userAPIErrorResponse) else { self.client?.urlProtocol( self, didFailWithError: APIMockError( errorDomain: "APIMockError.LoginAPIMockProtocol", errorUserInfo: [NSLocalizedDescriptionKey: "APIErrorResponse構造体のエンコードに失敗しました"] ) ) return } responseData = data default: self.client?.urlProtocol( self, didFailWithError: APIMockError( errorDomain: "APIMockError.LoginAPIMockProtocol", errorUserInfo: [NSLocalizedDescriptionKey: "レスポンス処理が設定されていないパスワードです"] ) ) return } // レスポンス client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed) client?.urlProtocol(self, didLoad: responseData) client?.urlProtocolDidFinishLoading(self) } // 通信停止時に呼ばれるメソッド override open func stopLoading() { } } 通信処理をMockに差し替えて、テストを作成 Mock自体の実装は完了したので、次は通信処理をMockに差し替えます。 通信処理はURLSessionで行われるので、URLSessionの設定である URLSessionConfiguration でMockに差し替える設定をします。 URLSessionConfiguration には protocolClasses という配列のプロパティが存在し、このプロパティにURLProtocolのサブクラスを設定することで、Mockに処理を差し替えることができます。 テストの setUpWithError でURLSessionConfigurationの設定をして、APIと通信するテスト対象の関数にURLSessionを渡すことで、Mockを利用したテストを実現できました。 override func setUpWithError() throws { let configuration = URLSessionConfiguration.af.default configuration.protocolClasses[0] = [LoginAPIMockURLProtocol.self] self.loginAPI = LoginAPI(session: Session(configuration: configuration)) } 以下のコードが今回のテスト対象です。 import Foundation import Combine import Alamofire struct LoginAPIModel: Codable { let username: String let password: String } struct TokenAPIModel: Codable, Equatable { let accessToken: String } struct APIError: Error { let statusCode: Int let errorResponse: APIErrorResponse } struct APIErrorResponse: Codable, Equatable { let error: String } class LoginAPI { private let session: Session init(session: Session = AF) { self.session = session } func login(username: String, pw: String) -> Future<TokenAPIModel, APIError> { let loginUser = LoginAPIModel(username: username, password: pw) let jsonEncoder = JSONEncoder() jsonEncoder.keyEncodingStrategy = .convertToSnakeCase let parameterEncoder = JSONParameterEncoder(encoder: jsonEncoder) let headers: HTTPHeaders = [.contentType("application/json"), .accept("application/json")] let jsonDecoder = JSONDecoder() jsonDecoder.keyDecodingStrategy = .convertFromSnakeCase return Future { promise in self.session .request( loginAPIURL, method: .post, parameters: loginUser, encoder: parameterEncoder, headers: headers ) .validate() .responseDecodable(of: TokenAPIModel.self, decoder: jsonDecoder) { response in switch response.result { case .success(let userToken): promise(.success(userToken)) case .failure: guard let statusCode = response.response?.statusCode else { promise(.failure(APIError( statusCode: 0, errorResponse: APIErrorResponse(error: "network error") ))) return } guard let errorResponse = try? jsonDecoder.decode(UserAPIErrorResponse.self, from: response.data!) else { promise(.failure(APIError( statusCode: statusCode, errorResponse: APIErrorResponse(error: "json decode error") ))) return } promise(.failure(APIError( statusCode: statusCode, errorResponse: errorResponse ))) } } } } } テストコードは以下になります。 import XCTest import Combine import Alamofire final class LoginAPITests: XCTestCase { private var loginAPI: LoginAPI! private var cancellables: Set<AnyCancellable> = [] // テストのセットアップで通信処理をMockに差し替え override func setUpWithError() throws { let configuration = URLSessionConfiguration.af.default configuration.protocolClasses[0] = [LoginAPIMockURLProtocol.self] self.loginAPI = LoginAPI(session: Session(configuration: configuration)) } override func tearDownWithError() throws { } func testLoginAPI() throws { let expectation = XCTestExpectation() expectation.expectedFulfillmentCount = 2 loginAPI.login(username: "username", pw: "200") .sink(receiveCompletion: { completion in switch completion { case .finished: break case .failure: XCTFail("LoginAPI 200 Test Fail") } }, receiveValue: { token in XCTAssertEqual( token, TokenAPIModel(accessToken: "accessToken"), "LoginAPI 200 Test is not Expected") expectation.fulfill() }).store(in: &cancellables) loginAPI.login(username: "username", pw: "401") .sink(receiveCompletion: { completion in switch completion { case .finished: break case let .failure(error): XCTAssertEqual( error, APIError( statusCode: 401, errorResponse: APIErrorResponse(error: "401 error") ), "LoginAPI 401 Test is not Expected" ) expectation.fulfill() } }, receiveValue: { _ in XCTFail("LoginAPI 401 Test Fail") }).store(in: &cancellables) wait(for: [expectation], timeout: 1) } } おわりに 実際に、Mockを簡単に実装できました。状況に応じて、Mockを細かく実装できるのが嬉しいですね。簡単にできるので、利用してみてください。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは。キャリア採用で入社した入社１年目の西村です。 キャリア採用者は入社直後は、社内ルールや業務知識など、多くの情報を短期間で吸収しなければなりません。 企業ミッションや社内ルールは、キャリア採用者向けのプログラムや社内資料で理解を深められますが、技術面での対応は不足している部分を把握し、積極的に学習を進める必要があります。 学習リソースの活用 オープンな情報については、書籍、IT系勉強会、学習系ウェブサイト、動画など様々なリソースが活用できます。 新たな分野の学習では、専門家がまとめた資料を理解することで、体系的な知識を効率的に得られます。 自己啓発支援プログラム ニフティには自己成長を促す福利厚生があります。一例として下記があります。 書籍購入支援 特定資格の取得者への報奨金・手当支給 社内勉強会・LT大会の開催 Udemyの提供 これらの制度は継続的な学習と成長をサポートしてくれます。 上記以外の自己啓発に関するプログラムや働き方に関する福利厚生については、 下記をご参照ください。 福利厚生 | 採用情報 | ニフティ株式会社 (nifty.co.jp) AWS資格取得への挑戦 私の場合、オープンな技術においてAWSの関連知識が不足していると認識し、効率的な学習方法としてAWS認定資格の取得を目指しました。 「資格取得支援制度」と「Udemy」のAWS関連教材を活用し、計画的に学習を進めました。 資格取得のメリット 資格取得の最大のメリットは、最新情報を得る機会になることです。 IT分野の資格は定期的に内容が更新されるため、比較的新しい技術動向を学ぶことができます。 資格取得を通じて体系的な学習と知識の確認ができます。 まとめ 技術面での学習は入社半年で下記2つのAWS認定資格を取得し、知識の再構築ができました。 また目的であった業務への理解が深まり、新たな学習のモチベーションにもつながりました。 AWS Certified Solutions Architect (SAA) AWS Certified Cloud Practitioner (CLF) 資格取得以外にも、ハンズオンやチュートリアルを利用して実際に手を動かす事や、Todoアプリのような簡易的なシステムを作ってみる方法など、様々な学習方法があります。 状況に合った方法で、新たな知識を深めていきましょう！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは。ニフティ株式会社の佐々木です。 今回はTipsとして、VSCodeでGitHub Copilotを使い複数ファイルを認識させる方法についてご紹介します。 前提 GitHub CopilotとGitHub Copilot Chatの違い GitHub Copilotは、コード補完やコード生成を支援するAIツールです。一方、GitHub Copilot Chatは、チャット形式でユーザーと対話しながら、よりインタラクティブにコーディング支援を行うツールです。両者の主な違いは、ユーザーインターフェースと対話の方法にあります。 GitHub Copilotについての詳しい説明は こちら をご参照ください GitHub Copilotの仕様 認識範囲について GitHub Copilotは、基本的にアクティブなファイルのみを認識します。しかし、実際にVSCodeで開発していると、単一のファイルだけでなく複数のファイルを認識して欲しい場合がよくあります。 複数のファイルにまたがるコードの依存関係や構造をCopilotに認識してもらうことで、より適切な提案をしてもらえるので、結果的に、より質の高い回答を得ることにつながると思います。 複数ファイルを認識させる方法 では、GitHub Copilotで複数ファイルを認識させるにはどうすればよいでしょうか？ 結論から言うと、 #file: や @workspace を付与して複数ファイルを認識してもらった上で、通常通りチャットで質問を投げる形でOKです。 #file:の活用 一例として、TypeScriptをベースにしたプロジェクトで、複数ファイルを認識させた上で、改善点を出力してもらうための質問を投げかけてみます。 #file:index.tsx #file:README.md #file:_variables.scss #file:Header.tsx #file:utils.ts これらのファイルをすべて含めてみた時の改善点を教えて下さい このように「参照済みのファイル」として複数ファイルにまたがるコード内を検索し、適切な回答が返ってきました。 @workspaceの活用 代表的な例として、 @workspace を付与することで、特定のファイルに限定せずともワークスペース全体を読み込んだ上で質問を投げることもできるようです。 例えば、コードの構造を把握するために以下のような質問文を投げてみます。 @workspace ワークスペース全体のコードの構成について教えて下さい このように、主要なディレクトリやファイルごとに大まかな構成の説明が返ってきました。 また、やや曖昧な表現で質問しても、ワークスペース内の必要なファイルを辿りつつ、具体的なコードの説明や修正までいい感じにやってくれました。 @workspace ワークスペース全体のCSSを確認し、必要があればリファクタリングしてください その他のコマンドについて 今回ご紹介しきれなかったもの以外にも、GitHub Copilotには「コードの提案、コードの説明、単体テストの生成、コマンドラインに関する質問」など様々なケースを想定したコマンドが用意されています。 質問の投げ方や詳しいコマンドの仕様については以下の公式ドキュメントから確認できるので、良く使いそうな機能について押さえておくと良いかもしれません。 https://docs.github.com/en/copilot/using-github-copilot/prompt-engineering-for-github-copilot https://docs.github.com/en/copilot/using-github-copilot/asking-github-copilot-questions-in-your-ide まとめ 今回はGitHub Copilotに複数ファイルを認識させる方法をTipsとして紹介しました。 GitHub Copilotは非常に便利で強力ですが、こちらが期待した動作をしない場合もあり、まだ痒いところに手が届かないことも多いのかなと思います。 今後、AIによるコード支援はさらに進化していくと予想されるので、ぜひ、この記事で紹介した方法を試して自分なりのGitHub Copilotの活用法を見つけてください。 また、この記事を書くにあたって以下の記事を参考にさせていただきました。 【C#】Visual Studio で GitHub Copilot に複数のファイルやコードを認識させる方法 – Qiita We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も受け付けています！ カジュアル面談 Tech TalkやMeetUpも開催しております！ こちらもお気軽にご応募ください！ Event – NIFTY engineering ニフティ株式会社 – connpass

参加登録はこちらから (connpass)7月 30 AWS GameDay入賞者が語るAWS Summit JapanとGameDayでの学びとは？ イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ テーマ 2024年6月20日、21日にAWS社の大規模イベント AWS Summit Japan 2024 が開催されました。AWS Summit Japan（以前はTokyo）には毎年ニフティのエンジニアが多く参加しています。 NIFTY Tech Talk #20では、AWS Summit Japan内で行われた実践的なチーム学習演習イベントであるAWS GameDayの入賞チームメンバーから、AWS GameDayの楽しさや学び、あるいは攻略法について語ってもらいます。 ご参考 AWS GameDay @ AWS Summit Japan 2024 結果発表！！ ※ AWS GameDayはその性質上内容のネタバレは厳禁とされてますため、ネタバレを避けた範囲でのトークとなります。ご承知おきください 開催概要 ※オンライン配信のみです 日程：7月30日（火）12:00〜13:00 YouTube Liveで配信 こんな方におすすめ AWS GameDayに興味があるが参加したことがない方 AWSを使っているがAWS Summit Japanに参加したことがまだない方 参加したことはあるが、楽しみ方をより知りたいという方 タイムテーブル 時間 コンテンツ 12:00 – 12:10 オープニング 12:10 – 12:50 対談セッション： AWS GameDay参加による学びと120％楽しむためには 12:50 – 13:00 クロージング 登壇者プロフィール @rubihiko (浅見 則彦)（登壇者） ニフティ株式会社　会員システムグループ / N1! SRE Web系のサービスの開発・運用。社内でSREを広める活動しています。 いかりがわ（登壇者） ニフティ株式会社 会員システムグループ 第１開発チーム 新卒4年目。ニフティのポータルサイトの開発運用を担当しています。 普段はNext.jsやGoをCopilotさんと一緒に書いてます。 ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています！ ニフティエンジニアのX(旧Twitter)アカウント NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 Tweets by NIFTYDevelopers アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現（外見の性）、性指向 年齢、障がい、容姿、体格 人種、民族、宗教（無宗教を含む） 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生（性的な画像など） 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductとして公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に派生しています。 ※本文章はCreative Commons Zero ライセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されています。

こんにちは、NIFTY engineering編集部です。 ニフティのエンジニアが InnerSource Gathering Tokyo 2024 というイベントに運営として参加すると聞き、InnerSourceという言葉も知らなかった編集部員はエンジニアたちにインタビューしてInnerSourceとはなにか、なぜInnerSourceに取り組んでイベントの運営に参加したのかを聞いてみました！ InnerSource（インナーソース）とはなにか ――そもそもInnerSourceとはなんでしょうか？私もIT業界にいた人間ですが、恥ずかしながら初めて聞いた言葉でした。 芦川 InnerSourceの定義は、「組織という限られた環境において、ソフトウェア開発におけるオープンソースの原則とプラクティスを活用すること」です。 簡単に言ってしまうと壁がありがちな部門間の開発のコラボレーションを促進し、また、エンジニア自体が開発する楽しさを享受し、称賛しあう社内の文化形成までを含んでいます。浸透していくと、専門知識やアイデアが部門の枠を超えて共有され、プロダクトの質や開発リードタイムの減少によりプロダクト成長のスピードが向上します。さらに、開発者は楽しさ以外に他のプロジェクトに参加することで新たなドメイン知識、テックスキルを習得し、自己成長を実現できます。 具体的な導入方法については、 InnerSource Commons （インナーソースの実践者の世界最大のコミュニティ） にノウハウが溜まっています。 ニフティ内でのInnerSourceへの取り組みと楽しさ ――どんなきっかけがあってニフティ内でInnerSourceを始めることになったのでしょうか？ 小松 最初に導入した経緯は、いわゆるプラットフォームチームで管理しているプロダクトへの開発が集中してしまうと、スピードのボトルネックになってしまうな、という未来の懸念があって、なにかいい方法はないかと調べていったところ、インナーソース、というワードを知ったのがきっかけです。取り組み自体のプロセスについては、以下の記事が詳しいです。 NIFTY engineering – ニフティ株式会社のエンジニアたちのいまを伝えます#インナーソースを導入してみた その① お試し導入編 – NIFTY engineering ​ NIFTY engineering – ニフティ株式会社のエンジニアたちのいまを伝えますインナーソースを導入してみた その② 土台作り編 – NIFTY engineering ​ ――社内のInnerSource活動を運営・推進されているわけですが、どんなところに楽しみや充実感があるのでしょうか？ 日本でも実践例が少ないため、やっている感があります。今後も取り組みをどんどん発信していき、１つのユースケースとして広めていきたいと思います。そして、他の方が導入に悩んでいるところの解消の一助に、果ては日本企業の中での開発者体験の向上、サイロ化の解消への一助になりたいと考えています InnerSource Commons Japanコミュニティにも参加してます。他社の方とふれあい、お互いの悩みやアドバイスが共有でき、とにかく楽しいです。スクラムマスターやテックリード、部長クラスの方など「組織を変えたい」と強く思っている方が多く、かつエンジニアとしてのレベルが超絶高いのでとても刺激的で勉強になります InnerSource Gathering Tokyo 2024とはなにか ――今回、運営スタッフとして参加しているイベントが来月開催されるとのことですが、どんなイベントなのでしょうか？ 芦川 組織の未来を切り拓く鍵が探せるイベントです。 InnerSource Gathering 自体は世界各地で行われてますが、日本で行われたことはありませんでした。 今回の InnerSource Gathering は日本初開催となります。 各登壇者の方からインナーソースの文化をどう企業に広めたのか、その取り組みの紹介やお楽しみ企画、懇親会などのコンテンツもあります！ ニフティのエンジニアの小松も登壇いたします。 運営参加の理由 ――イベントの運営、それも日本で初開催となるとなかなか大変だと思うのですが、運営に参加しようと思ったのはなぜでしょう？ 小松 冒頭にあった、 インナーソースを導入してみた その① お試し導入編 の記事をInnerSource Commons Vice Presidentの服部さんに拾っていただき、途中、 Commonsでの登壇 もしながら、コミュニティの方へ積極的に参加するようになっていきました。その中で、今度日本初のInnserSourceイベントをやるんですがどうですか？というお声がけを頂き、超面白そう！ということで運営参加させていただくことになりました。 ーー イベント運営に参加する楽しさを教えてください！ 登壇者の選定からできることになり、各有名エンジニアと直接お話できるところとか貴重な体験をさせていただいています 社外コミュニティに参加＆イベント運営自体がはじめてだったので最初は不安でしたが、コミュニティのタスク（サムネイル作成ツイート文面作成など）をやるうちに、だんだんとこうしたらいいんじゃないかみたいな自我を出せるようになってきました。自分がよいとおもってやったことを称賛されるのはうれしいし、楽しいですね！ サイト作成で協力させていただいたりもしていますが、イベント内容が固まっていくのに従ってサイトの内容も拡充されていくので、進み具合を目で感じられるのも新鮮な感覚でした イベントの見どころ ーー試行錯誤しながらもモチベーション高くイベント運営を進めているようですね。そんなInnerSource Gathering Tokyo 2024の見どころを教えてください 田澤 まずは、登壇者の方々が超絶豪華になります。 InnerSource CommonsのファウンダーであるDanese Cooperさんのビデオメッセージからはじまり、「世界一流エンジニアの思考法」著者 牛尾さんによる組織内で感謝を含めたフィードバックをし合うメンタルモデル・組織文化の醸成、「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」訳者 ryuzeesさんによるチームトポロジーとインナーソースの関係の深堀り、スポンサーセッションとしては、The Linux Foundation 日本代表 福安さんによる組織間コラボレーションを通して価値を創出する上でのキーポイントを具体的実例や手法など紹介いただきます。また、各社様からはインナーソーシング活動の実際の具体例をいただき、これからインナーソースを導入しようとしている企業様、また導入したが文化の醸成までは至っていない企業様へのヒントとなること間違いなしです。 中盤の休憩では、日本におけるインナーソースの認知を広めようと、現在、コミュニティの方で作っている歌を紹介するコーナーがありますので、こちらも乞うご期待！（先日も歌詞作りなどに参加させていただいて、これはこれでものすごい楽しいです。） 後半はインナーソースにおける悩み共有の場、もっと深く話せる場として、OST(Open Space Technology)を企画しています。 イベントはリアル開催のみですでに定員に達しておりますが、後日、セッションについては動画公開予定ですのでお楽しみに！ （※ InnerSource Gathering Tokyo 2024のイベント詳細は connpassのページ をご覧ください） 読者のみなさまへ @InnerSourceJP をぜひフォローしてみてください。InnerSource Gathering Tokyo 2024を含めたInnerSource Commons Japanコミュニティの活動の様子がわかります。 また @NIFTYDevelopers では、ニフティのエンジニアによる技術記事やイベント情報を発信していますので、こちらもフォローお願いいたします。 ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに こんにちは！NIFTY Engineering運営のいかりがわです！ 今回はニフティのエンジニアに色々アンケートを取ってみたので紹介します！ 以前開催されたNIFTY Tech Day 2023にて、実際に現場で活躍しているエンジニアからアンケートを取る企画を実施したので、改めてブログで紹介させていただきます！ 今回は全エンジニアおよそ150名のうち、64名の方に回答いただきました。回答ありがとうございます！ 基本情報 まずは基本情報についてです。 在籍年数は？ 在籍年数はこんな感じになりました。 ニフティは昔からある会社ではありますが、在籍年数を聞いてみると在籍年数が比較的浅い人が多いですね！ おそらく新卒採用の方々でしょうか？ 毎年10人程度エンジニアを採用しているので若手社員も毎年増えています！ 採用形態は？ 採用形態についてです。 先ほど新卒採用でエンジニアを採用していると説明しましたが、キャリア採用も年々増えています！ 休日は何をしていますか？ 休日はゲームや動画鑑賞をしている方が多いですね！ 筋トレ、ウォーキングなど運動をしている方々もいます。 エンジニアはデスクワークで運動不足になりがちなので、健康に気を遣っている方は多いように感じます！ プログラミング言語・クラウドサービスについて 業務でよく使う言語は？ 表で表すとこんな感じです！ 順位 言語 % 1 Python 29.5 2 ShellScript 17.4 3 Java 11.4 4 JavaScript 9.4 5 TypeScript 8.1 とても面白い結果になりましたね！ 最も多く使用されている言語はPythonで、29.5%を占めています。 Pythonは汎用性や書きやすさから世界的に人気な言語ですが、社内でも人気な言語となっています！ 次の項目で紹介する好きな言語でも1位となっています！ 続いてShellScriptが17.4%と高い割合を示しています。 サーバーの運用やタスク自動化などでは必ず必要となってきますので、重要な言語だと思います！ Javaは11.4%で3番目に多く使用されていますね！ ニフティのサービスの基盤となるシステムで動いている言語にJavaは多く使われている印象を受けますね。 JavaScriptとTypeScriptは合わせると17.5%です！ 特にTypeScript（8.1%）の採用が進んでいるので、社内のフロントエンド界隈でも型安全性を重視する傾向になってきていますね。 その他、Go言語（5.4%）やGoogle Apps Script（GAS、4.7%）、Ruby（2.7%）なども使用されており、さまざまな言語を現場のエンジニアが採用することができます！ ニフティのエンジニアは、自分自身でさまざまな言語やツールを柔軟に活用して日々開発しています！ 好きな言語は？ やはりPythonが圧倒的な人気を誇っています！ 業務での使用率（29.5%）をさらに上回る32.4%のエンジニアがPythonを好んでいます。 やっぱりPythonは書きやすいですよね〜。私も最初に自分から勉強した言語はPythonでした。 初心者でも扱いやすく、とても書きやすい言語だと思います！ 2位のGoは業務での使用率（5.4%）を大きく上回る11.7%となっています！ パフォーマンスの高さや並行処理の扱いやすさが魅力的ですよね。 現在の業務での使用頻度は部署によりますが、全社的には広く普及していない印象ですが、今後増える可能性はありそうですね！ 3位のShellScriptは業務での使用率（17.4%）よりは低いものの、高い人気を保っています。 日々の業務で欠かせないツールとして、多くのエンジニアに愛されているんだと思います！ TypeScriptは4位にランクインし、JavaScriptよりも高いです！ 型安全性を重視する傾向が好みにも表れていますね。 私が所属しているチームのみでの話になりますが、本番環境で動いている主要なフロントエンドのシステムはほぼ全てTypeScriptで記述していますね。 Javaは5位となり、業務での使用率（11.4%）よりもやや低い結果となりました。 しかし、多くのエンジニアに支持されている言語であることに変わりはないと感じています！ 最新のトレンドにも敏感なエンジニアが比較的多く、最近だと Rust勉強会 が開催されていました！ この結果から、ニフティのエンジニアは業務で使用する言語に留まらず、幅広い言語や技術に興味を持ち、常に新しいことにチャレンジする姿勢を持っていることがうかがえます！ 業務でよく使うクラウドサービスは？ AWSが圧倒的な支持を得ていることがわかります。73.4%のエンジニアが業務でAWSを利用しています！ アンケート結果にはないですが、最近だとAWSに限らず、AzureやGoogle Cloudも積極的に使っていこうという動きが出てきています。 ニフティのエンジニアたちは、最新のクラウド技術を積極的に活用しつつ、幅広い開発に取り組んでいます！ 今後は、AWS一強から、より多様なクラウドサービスを使いこなすマルチクラウド環境へと移行していきます。 クラウド技術の進化に合わせて、エンジニアたちのスキルセットがどのように変化していくのか、そしてそれがニフティのサービスにどのような影響を与えていくのか、非常に楽しみですね！ ニフティについて 最後に、ニフティについてです。 ニフティの良いところは？ 社員の人柄や雰囲気が良いと言っている方が1/4近くいますね！ 次にワークライフバランスや、成長できる環境が続いています。 このアンケート結果から、ニフティは従業員の快適な職場環境と個人の成長を重視している環境であると言えますね！ ニフティのエンジニアの強みは？ 続いてエンジニアの強みです。 先ほど、社員の人柄が良いとありましたが、こちらでも優しさや思いやりが上位に来ています。 また、チャレンジ精神、熱心さも上位です。 成長できる環境であるからこそ、いろいろなことにチャレンジをすることができると思っています。また、チャレンジの一環でどんどんアウトプットしていくことで、チャレンジしたい人が自然と集まってくる。良い循環が生まれているような気がします！ 終わりに 今回はNIFTY Tech Day 2023にて実施したアンケートを紹介させていただきました。 この機会にニフティのエンジニアについてより知っていただければ幸いです！ ありがとうございました！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

この記事は、リレーブログ企画「24新卒リレーブログ」の記事です。 はじめに こんにちは。はじめまして新卒1年目の藤岡です。 これから24新卒リレーブログをしていきます！ そんな私は現在ジョブローテ第一期にてISPオペレーションサブチームに配属され未知の情報の荒波にもまれています。 今回はRcloneでローカルPCからAWS S3にファイルを転送しようとした際にアクセス権限の付与で苦しんだお話をしていこうと思います。 やろうとしていること rcloneでローカルPCからs3にアクセス サーバー内のファイルをs3バケットにアップロード s3バケットにあるファイルを読み取る したいことだけ見ると詰まるところがなさそうに思えます。 ということで早速ネットで同じことをしている人がいないか調べていきます。 Rcloneでs3をローカルPCにマウントしてみる | DevelopersIO RCloneでAW3 S3 バケットにファイル転送してみた 「rclone s3」と検索したところ、もう組み合わせるだけでいけそうな記事がありました。 早速記事通りに作業を進めていきます。 IAMユーザー しばらく進めるとrclone configの設定で IAMユーザー の「アクセスキー」、「シークレットキー」の入力が求められます。 「IAMユーザーってなんぞや」 AWS初心者の私はこうなるわけです。調べましょう。 IAM（アイエム）ユーザーは、AWSのIdentity and Access Management（アイデンティティとアクセス管理）の機能の一つです。IAMユーザーは、AWSリソースへのアクセスや操作を行うために使用されるアカウントです。 引用： https://zenn.dev/sudoukky/articles/b418490a38fdc6 なるほどAWSのリソースにアクセスするためにそれ専用のアカウントを作成しなければならないということですね。 ということでIAMユーザーを作成していきます。 が、作成しようとすると 許可のオプション という設定を求められます。 「許可ってなんや、ポリシーってなんや」 また出ました。調べましょう。 IAM でのポリシーとアクセス許可 AWS でのアクセスを管理するには、ポリシーを作成し、IAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) または AWS リソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、IAM プリンシパル (ユーザーまたはロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。 引用： https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html なるほどリソースにアクセスするためのアカウントが「何に対して、何ができるか」とかの権限ということですね。 「何ができるか」については全てActionとして指定することで権限を付与することができるそうです。 では今回はs3のバケットに対してファイルのアップロードと読み取りをできるようにすればいいので PutObject と GetObject の2つ付与すればいけそうです。 ということでポリシーを作成してユーザーにアタッチ。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::バケット名/*", "arn:aws:s3:::作成したバケット名/フォルダ名/*" ] } ] } これで無事にIAMユーザーが作成できました。 そして肝心のアクセスキーとシークレットキーもユーザーページから発行できました。 ついに上の記事の作業が進みます。 その後は特に詰まることなくrcloneでローカルPCからs3にアクセスする設定が完了しました。 いざ rclone copy コマンド実行！ rclone copy C:\Users\xxxxx\xxxxx\xxxxx s3:作成したバケット名/フォルダ名 #実行結果 2024/xx/xx xx:xx:xx Failed to copy: Forbidden: Forbidden status code: 403, request id: xxxxxxxxxxxxxxxx, host id: xxxxAVBHF/hihccgvXxxxxxxFTFZOh/xx-GUKLvxxxxxxxxxxxxxxxxx 「 Forbidden 」 アクセス拒否！？どこが間違ってるんや。と思いながら記事を見直すもどこも間違っているようには見えません。 どうやらアクセス権限がないと言われているようです。 PutObject GetObject 以外にも必要なアクションがあるということですね。 最小権限の原則 他にどんなアクションがあるのか調べ中、「すべてのアクションの許可を付与する」みたいなフルアクセスというものがあるじゃないですか。 早速ポリシーをs3に対するフルアクセスに変えて実行。 そりゃできます。 最初からフルアクセスにしとけばよかったんや。なんて考えているとトレーナーの方から 「最小権限の原則というものがあってね」 セキュリティの観点から権限というものは必要なもの以外は付与しないことが望ましいというものらしい。そうしないと万が一アカウントが乗っ取られたりしたときに内部から侵略されてしまう。 ということで今回の処理における最小権限はどれなのかの調査が始まりました。 しかし、どれだけ調べても出てくるのは 「ファイルの書き込みに必要な権限は PutObject 、読み取りに必要なのは GetObject 。」 それに加えてs3に対するアクションの総数がまあまあな数あります。とてもじゃないですが1つ1つどんなアクションなのか調べるのは無理があります。 頭を抱えながら調べていると「 AWS Cloud Trail 」というサービスの存在を見つけました。 Cloud Trail ログインなどのユーザアクティビティとAPI操作をログに記録するサービスです。AWS CloudTrailを利用することで、AWSアカウントのガバナンス、コンプライアンス、リスク監査などを行うことができます。そのため「いつ」「誰が」「何を」したのかをすぐさま確認することが可能です。 引用： https://www.skyarch.net/column/aws-cloudtrail/ これでフルアクセスの時にs3に対してどんなアクションを起こしているのか調べれば足りないアクションが分かりそうです。 いざログ確認。 CreateBucket ！？ なんと CreateBucket というアクションが実行されていました。 どうやら rclone copy では毎回同名のバケットを作り直しているそうです。 早速ポリシーに追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket" ], "Resource": [ "arn:aws:s3:::*" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::作成したバケット名", "arn:aws:s3:::作成したバケット名/フォルダ名/*" ] } ] } いざ rclone copy ！ rclone copy C:\Users\xxxxx\xxxxx\xxxxx s3:作成したバケット名/フォルダ名 #実行結果 2024/xx/xx xx:xx:xx Failed to copy: Forbidden: Forbidden status code: 403, request id: xxxxxxxxxxxxxxxx, host id: xxxxAVBHF/hihccgvXxxxxxxFTFZOh/xx-GUKLvxxxxxxxxxxxxxxxxx 「 Forbidden 」 まだか。しかし CreateBucket が実行されていることから学んだことがあります。 実行するコマンドの処理について考えることが大切なのではないかということです。 実際にRcloneの公式ドキュメントには rclone sync コマンドを実行する際の最低限必要な権限が記載されています。 Amazon S3 ここにも記載されているようにフォルダの同期を行う sync コマンドではファイルの削除も行うため DeleteObject などのアクションが必要になってきます。 では rclone copy はどんな処理をするコマンドなのでしょうか？ rclone copy 同期元と同期先で同じファイルはスキップするようコピーする。この時、同期元で削除したファイルは同期先で削除されないため、同期先の容量はどんどん膨らんでいることに注意 引用： https://www.phi.phys.nagoya-u.ac.jp/~fujiie/memo/rclone.html copy では同期元と同名のファイルが同期先にあるときはファイルの更新を行い、同期先にないときにはファイルを新しく同期先に作成しています。 ということはフォルダの中のオブジェクトの全てを一度参照していることになります。 現在のポリシーにはオブジェクトの一覧を参照できるアクションの権限はありませんのでアクション一覧から探します。 ListBucket ：バケット内のオブジェクトの一覧を取得する これが使えそうです。ポリシーに追加していきましょう。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket" ], "Resource": [ "arn:aws:s3:::*" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::作成したバケット名", "arn:aws:s3:::作成したバケット名/フォルダ名/*" ] } ] } 満を持して rclone copy ！ rclone copy C:\Users\xxxxx\xxxxx\xxxxx s3:作成したバケット名/フォルダ名 #実行結果 ついにエラーなく実行できました。 AWSのコンソールにてs3バケットを確認するとローカルのファイルがs3バケット内にコピーされてると思います。 これでついにrcloneでローカルPCからs3にアクセスできたといえます。 お疲れさまでした。 おわりに 今回はAWSも触ったことがない、Rcloneとはなんぞやといった何もわからない状態で作業し始めたためIAMポリシーの規則などで詰まってしまいました。 AWS初心者の私はまずAWSリソース間でのアクセスに必要な権限で躓いてしまい、さらに外部アプリケーションを介することでさらに必要となる権限があるということの2点躓くポイントがありました。 前者の問題は色々な記事があるためネットで検索すると情報が出てきます。 しかし後者の問題は今回のように全く同じことをしている人が少ないことが多いです。 そこで実行したいコマンドがどういった処理をしているものなのかや、ログをたどることで対策できることもあると分かりました。 実際rcloneは実行するコマンドによって必須の権限があるため注意が必要ということが分かりました。 特に今回の rclone copy では GetObject PutObject ListBucket CreateBucket の４つは必須です。 今回の経験を活かして今後も実行したいものがどういった処理を行うものなのか考えながら業務に励んでいきたいと思います。 以上、新卒1年目がRcloneでAWSへアクセスするときの権限で苦しんだ話でした。 ありがとうございました。 次回は、keylium さんです。 ここから24新卒リレーブログ企画スタートです！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

こんにちは。NIFTY engineeringブログ運用チームです。 ブログ運用チームでは、ニフティのエンジニアについての情報を世の中に広めるための活動をしています。 その活動の一環として、リレーブログを実施しています。 【リレーブログ企画第一弾】チーム紹介リレーブログをやります！ 現在、リレーブログ第一弾を実施中ですが、第二弾も並行して実施します！ リレーブログ第二弾のテーマは「24新卒リレーブログ」です。 本記事に、24新卒社員のブログ記事のリンクをまとめていきますので、ぜひチェックしてください。 24新卒リレーブログは以下のスケジュールで投稿予定です。お楽しみに！ 投稿予定 執筆者 記事タイトル 2024年7月22日 藤岡さん RcloneでAWS S3へアクセスするときにIAMの権限で苦しんだ話 2024年8月2日 keyliumさん .inputrc を設定してshell入力を高速化する 2024年8月9日 山本さん roboflow体験記 ～ 画像認識AIモデルを活用する 2024年8月12日 塚崎さん 未定 2024年8月23日 けにさん 未定 2024年9月5日 佐藤さん 未定 2024年9月6日 後藤さん 未定 2024年9月6日 滝川さん 未定 2024年9月6日 緑川さん SvelteKit関連(仮) ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

「社内向けのインナーソースガイドラインってどう作るんだろう…」 「インナーソースポータル（カタログ）をどう構築しよう…」 「ボトムアップでインナーソースの土台作りをどう進めればいいんだろう…」 ✔記事の内容 これまでの記事 社内向けインナーソースガイドラインを作成 ニフティのインナーソースガイドラインの目次 「3．社内のインナーソース情報を得るには」の内容 「4．コントリビューターとして参加するには」 の内容 「5．担当しているリポジトリをインナーソースにするには」の内容 「6．質問・相談」の内容 「7．さらにインナーソースの理解を深めるには」の内容 インナーソースポータルを構築 エンジニア全体会で、インナーソースガイドラインを公開！ 次の記事に続く… 【告知】InnerSource Gathering Tokyo 2024 に登壇します！ こんにちは！社内でインナーソース普及活動もやっている小松です！ 今回は実際に社内のメンバーがインナーソースに取り組むための土台作りになる、ガイドラインやインナーソースポータルのご紹介をしたいと思います！ これまでの記事 前回の記事は、ニフティでインナーソースお試し導入をしてみた様子と、エンジニアのアンケート結果を公開しました。 アンケート結果からインナーソースの導入に 反対する人が0% ということがわかり、社内展開に向けて動き始めました。 インナーソースを導入してみた その① お試し導入編 ちなみに、この記事をきっかけに、InnerSource Commonsのイベントに事例紹介として登壇させていただきました！ 質疑応答でディープな質問にも答えてもらったので、ご興味のある方は以下の記事をご覧ください！ ボトムアップで始める事例紹介と悩み相談【 InnerSource Commons #11に登壇】 今回は社内展開に向けたガイドライン作成、インナーソースポータルの構築、商用システムリポジトリをインナーソースにしてみるなど、土台作りの部分を共有します。 社内向けインナーソースガイドラインを作成 社内のNotionページに公開して、誰でも閲覧できるようになっています。 実際にインナーソース活動をやってもらうためにも、ガイドラインがないと何から手を付ければいいかわからずハードルが上がってしまいます。 ただリポジトリを公開するだけでは、コントリビュートの仕方がよくわからず、コントリビューターの負荷も増え、ホストチームもコミュニケーションコストが発生するので、CONTIBUTING.mdの書き方や、品質のためにも、テスト、lint環境を整備してもらうなど、手順を書きました。 ガイドラインの一部をご紹介しようと思います。 現時点での目次は以下です。 ニフティのインナーソースガイドラインの目次 1．インナーソースとは 概要 このガイドラインは何か？ 2．役職と責任範囲 ホスト ゲスト 3．社内のインナーソース情報を得るには 4．コントリビューターとして参加するには 5．担当しているリポジトリをインナーソースにするには 6．質問・相談 7．さらにインナーソースの理解を深めるには 「1. インナーソースとは」「2. 役職と責任範囲」については、インナーソースの一般的な説明になるので割愛します。 「3．社内のインナーソース情報を得るには」の内容 ここは以下のリンク集になっています。 ドキュメント Slackチャンネル インナーソースポータル FAQ 活動評価 「4．コントリビューターとして参加するには」 の内容 こちらはせっかく興味を持ってくれた方が、なるべく途中離脱しないように以下のような詳細なステップを書いています。 インナーソースポータルの紹介 CONTRIBUTING.mdの紹介 上長に許可をもらう 評価時に他社貢献、スキルアップのアピールとなるためにも 非同期でのコミュニケーションとなるため、コメントを詳細に残す 仕事表の付け方 細かいルールは各リポジトリごとCONTIBUTING.mdに従ってもらいます。 「5．担当しているリポジトリをインナーソースにするには」の内容 こちらも詳細な手順を書きました。 以下のような流れになっています。 プロダクトオーナーにリポジトリをインナーソースにする旨を共有 InnerSourceCommonsが公開しているラーニングパス に出てくるプロダクトオーナーは、技術の前提知識があるように読み取れます。 ニフティでは、ビジネス職の方がプロダクトオーナーになっている場合が多いです。 そのためトラステッドコミッターにインナーソースにおけるプロダクトオーナーの役割と権限を委任してもらう形にしています。 トラステッドコミッターを決める リポジトリの設定 インナーソースポータルに追加するクローラーに拾ってもらうようにDescriptionのTopicsに inner-source を追加。 現在は社内事情により、Forkでなく権限を付与してコントリビュートしてもらうので、権限の設定等。 ブランチ保護ルールなどは各リポジトリに任せます。 テスト・lintなどローカル開発環境の準備 違う開発文化を持った人も関わることがあるので、品質の観点からテストとlintは導入してもらうことにしています。 README.mdを用意 README.mdについては、 InnerSourcePatternsが紹介しているテンプレート があったので、そちらを参考に作った例を載せています。 コントリビュートについては、別途CONTIBUTING.mdを参照するように書いています。 CONTRIBUTING.mdを用意 コントリビューションするための詳細な手順を書きます。 CONTRIBUTING.mdについても、 InnerSourcePatternsが紹介しているテンプレート があったので、そちらを参考に作った例を載せています。 異なる開発文化の人でも理解ができるようにしておきます。 詳細にしておくことで、コミュニケーションコストも減らせます。 例えば、ブランチ名、コミットメッセージなどのフォーマットを決めておいたり、テスト実行方法など説明しておきます。 Slackなどで宣伝 「6．質問・相談」の内容 NotionにFAQのデータベースを公開しているので、リンクを張っています。 誰でも編集できるようになっています。 またインナーソースのSlackチャンネルに気軽に問い合わせもらうようにしています。 ハードルが低いおかげか、Slackチャンネルでの質問が多いです。 「7．さらにインナーソースの理解を深めるには」の内容 インナーソースの学習に使えそうなリンク集です。 InnerSource Commons JapanのYouTubeチャンネル 日本向けのチャンネルなので、最初はここを見てみるのがいいかもしれません。 InnerSource Commonsが公開しているラーニングパス 一番最初に読むには難しいかもしれません。 InnerSource CommonsのSlackチャンネル 日本チャンネルもあるので、 #jp_general に気軽に入ってみてください。 InnerSource Commons Japanのconnpass InnerSource Commons Japanのイベントに参加してみたい方向け。 堅苦しくない雰囲気なので、まずは気になるイベントを参加してみるのをおすすめです！ インナーソースポータルを構築 ※リポジトリ名などは黒塗りしています。 社内のインナーソースになっているリポジトリを探すためのツールです。 インナーソースパターンブックでも紹介 されています。 参考実装のリポジトリ が公開されているので、まずは利用させてもらいました。 ニフティでは、 社内リポジトリはGitHubの1つのOrganizationで管理 しているため、実装はほぼそのまま社内サーバーに構築しました。 インナーソースリポジトリを自動で拾ってくれるクローラーは、 zkoppert/innersource-crawler のリポジトリを使わせてもらいました。 リポジトリのTopicsに inner-souce を追加すると、インナーソースポータルに追加してくれます。 後ほどインナーソースポータル自体もインナーソースにしてみました。 すると、新人が学習の一貫として、Next.jsに移行するコントリビュートをしてくれました！ さらに他のメンバーも加わり、私がなかなか時間を取れず進められなかった、インフラ周りの整備、社内ドメイン取得など、エンジニア同士がコンラボレーションしながら、進めてくれました。 まさにインナーソースの良さを感じました！ エンジニア全体会で、インナーソースガイドラインを公開！ ニフティでは、月に1回エンジニアが全員参加する全体会があります。 社内のトピックを共有したり、最後には謎解きコーナーがあったり！？する会なのですが、LTさせてもらえる時間があるので、そこでインナーソースガイドラインの公開も兼ねて発表しました。 発表内容は、インナーソース実験の結果、アンケート結果、インナーソースガイドラインの紹介でした。 インナーソース実験の結果とアンケート結果は その①の ブログ 記事 で公開しています。 エンジニアからの反応はポジティブなものが多く、 「実際に〇〇リポジトリをインナーソースにしてほしい！」 「担当業務以外の環境に触れる貴重な機会」 などコメントをもらいました。 実際にこのLTをきっかけに、新人が作っていた便利ツールをインナーソースにしてもらいました。 インナーソースの文化を作っていくにあたり、比較的時間に余裕がある若い世代にどんどん実践してもらい、徐々に広めていくのは効果的だなと思いました。 次の記事に続く… 続きはその③の記事で公開予定です。 いろいろネタは溜まってきているので、随時公開していきたいです。 「インナーソースオフィス立ち上げ」 「インナーソース導入後の効果」 「非エンジニアもインナーソース!?」 「InnerSource Commons Japanとのつながり」 「成熟度モデル導入はまだ難しかった」 「社内の創意工夫賞金賞受賞!?」 「商用システムリポジトリをインナーソース」 【告知】InnerSource Gathering Tokyo 2024 に登壇します！ InnerSource Gathering Tokyo 2024 にニフティの事例紹介として登壇します！ 日本初となるインナーソースカンファレンスです！ またニフティからはイベント運営自体にも数人協力しています！ 興味のある方は、イベント参加は以下のからお願いします！ https://innersourcecommons.connpass.com/event/317995/ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する

はじめに 宮永です。2024年7月のJANOG54 meeting（以下JANOG54）に参加してきました。 感想などを書いていきます。 JANOG Meetingとは JANOGとはJApan Network Operators’ Groupを意味し、 インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより 日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。 https://www.janog.gr.jp/information/ 　より引用 年に2回meetingが開かれ、日本全国から様々なバックグラウンドを持つ人が集まります。インターネットに関する技術やノウハウについての発表や議論が行われます。 どうして参加したのか？ 私は社内の「ISPオペレーションサブチーム」に所属しており、日々ニフティのお客様が快適にインターネットを使えるようにするための業務を担当しています。現在の業務にぴったりのコミュニティであると思い、参加しました。 参加にあたっての社内説得方法 私「参加したいです」 上司「いいですよ」 これだけです。いやぁ、ニフティっていい会社ですねぇ（ダイレクトマーケティング）（ここで採用ページのリンクを貼る） https://recruit.nifty.co.jp/ JANOG54現地 今回参加したJANOG54 meeting（以下JANOG54）は奈良県にある奈良県コンベンションセンターで開催されました。木のいい香りがしました。奈良県でのJANOG meeting開催は初だそうです。 会場の雰囲気会場には40~50代のオジサンしかいない……と勝手に想像（失礼）していましたが、全くそんなことはありませんでした。高校生からベテランまで幅広い層が参加していました。 というのも、初参加が44%ほどいるそうです。若くなくても初参加だったり、20代で6回目だったり、いろいろな人がいました。 参加者の所属企業も様々で、私のようなISP事業者だけではなくネットワーク機器メーカー、コンテンツ事業者などなど、様々な人が集まっています。 キッチンカーも来ておりお祭りムードです。 JANOGでは「カンファレンス」ではなく「ミーティング」と呼ぶことを大切にしているようです。発表時間に対して質疑応答の時間が長く、積極的な議論が歓迎されている雰囲気を感じました。発表後は年齢問わず活発な議論が行われ、時間終了後に場外戦が繰り広げられる場面も見かけました（そのための「替え玉エリア」が各会場の外に用意されていました）。 プログラム 200~400人ほどが入りそうな大きな会場3か所で様々な発表が行われます。楽しそうな発表ばかりで、どこに行くか迷います。人気のプログラムはすぐに席が埋まってしまうので、絶対に聞きたい発表があれば早めに会場に行くことをおすすめします。 BoF プログラムとは別に、選考が行われない自由な発表、議論の場であるBoFがあります。こちらも3部屋ありますが、50人程度の比較的小さい会場です。発表というより議論のほうが雰囲気としては近く、BoFの主催者が提示した議題に対していろいろな人が意見を出していました。 参加したBoFでは意見を出してみました。学会のような緊張感ある質疑ではなく、ワイワイと同じ目標に向かってアイデアを出していく雰囲気に近かったです。 NOCツアー 3日間開かれる会場には十分すぎるほどのWi-Fi環境が構築されており、会場のどこに行ってもAPが見えます。AP70台に約2000同時接続だそうです。そんなネットワークの裏側の見学会がありました。3日間のために複数ASとピアリングし、約100本のケーブルを会場に敷設し、監視体制まで整えていました。本当にすごいです。 公開してよさそうな写真を1枚。NTPサーバまで自前で立てているそうです。 反省点 もっと積極的にコミュニケーションをとればよかった とくに初日では場の温度感が分からず、積極的に動けていなかった部分がありました。単なるカンファレンスではなく話し合いを大切にする場なので、もっと積極的に色々な人とコミュニケーションを取りたかったです。 懇親会争奪戦に勝ちたかった 懇親会は大人気で、申し込み開始後数時間で売り切れになってしまうそうです。それを知らず、申し込み時は売り切れになっていました。次回こそは参加したいです。 上着をもってくればよかった （皆さん涼しいサーバルームにお住まいの方が多いからか）会場が寒いと感じる事が多かったです。　真夏の開催でも羽織るものを持っていると良かったです。 まとめ 何も分からない初心者が一人で参加しましたが、様々な知見を得たり、似た業務をしている人たちとコミュニケーションを取れたりなど、普段の仕事中ではなかなかできない経験ができました。 次回は2025年1月に京都で開催されるそうです。みなさんもぜひ参加してみてください！ ニフティでは、 さまざまなプロダクトへ挑戦する エンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトより お気軽にご連絡ください！ ニフティ株式会社採用情報 カジュアル面談も随時受付中！ ニフティに興味をお持ちの方は キャリア登録をぜひお願いいたします！ キャリア登録 connpassでニフティグループに 参加いただくと イベントの お知らせが届きます！ connpassで ニフティグループに参加する