並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 96件

新着順 人気順

ciの検索結果1 - 40 件 / 96件

  • 中級 Vim 操作

    この記事は Vim 駅伝 の 06/05 の記事です。 前回の記事は thinca さんによる、 06/03 の「Meguro.vim #23 を開催しました」という記事でした。 次回は 06/07 に投稿される予定です。 はじめに 本記事は以下の記事のオマージュです。 Vim の基本操作のうち、比較的マイナーながら汎用的に使える機能や小技を集めました。プラグインや複雑な設定が必要なものは含まれておらず、いずれも Vim と Neovim の両方で使うことができます。気になったものがあれば使ってみてください。 ノーマルモード編 検索結果を次々と置き換える Vim で文字列置換を行う最も有名な方法は :substitute コマンド (短縮形: :s) ですが、ノーマルモードの cgn というイディオムも便利です。これは c オペレータと gn テキストオブジェクト (:h gn) を組み合

      中級 Vim 操作
    • 期限の制約なく無料で提供される「Free Tier」クラウドサービスまとめ、主要クラウド/PaaS編(2024年版)

      期限の制約なく無料で提供される「Free Tier」クラウドサービスまとめ、主要クラウド/PaaS編(2024年版) いくつかのクラウドサービスでは、新規ユーザーに対する1年程度の無料トライアルや一定額のクーポンなどの提供だけでなく、期限の制約なくずっと無料で提供される、いわゆる「Free Tier」や「Always Free」と呼ばれるサービスが提供されています。 こうしたサービスは評価や一時的なテスト環境、あるいはホビー用途などに適しています。 本記事では期限の制約なく無料で提供されている主なクラウドサービスを、2024年版としてまとめました。(有料サービスの追加機能として無料で提供されているものは除外しています)。 ただしこれらの無料のサービスは、提供側の都合により一時的に申し込みや利用が制限されたり、提供が終了することがあります。提供側の都合に留意しつつ、良心的な範囲でご利用いただ

        期限の制約なく無料で提供される「Free Tier」クラウドサービスまとめ、主要クラウド/PaaS編(2024年版)
      • 2ヶ月でAWS認定12冠したので攻略法を語ります - Qiita

        AWS認定 is 何? 人気のクラウドサービス「アマゾンウェブサービス」が提供している認定資格試験です。パソコンで実施するタイプの選択式テストとなります。 時流に応じて資格数は増減しています。だいたい10件ちょいです。 2023年度:12資格 2024年度:10資格(→また12に増える予定) 何をやったの? 昨年末、急に思い立って認定資格を2ヶ月でコンプ(全冠)しました。 すいません、ちょっと盛りました。登竜門の「SAA(ソリューションアーキテクト アソシエイト)」だけは3年前に取っていました。 残りは週に1〜2件のペースで取得していたことになります。 資格に挑戦した理由は? 実は私、「資格を取ること」にあまり価値を感じていませんでした。 勉強に多くの時間を使う必要があり、他のことができなくなる 机上学習やるならハンズオンに時間を割く方が実務に活きやすい 数が多すぎて、全冠なんて自分とは別

          2ヶ月でAWS認定12冠したので攻略法を語ります - Qiita
        • 【完全解説】なぜ人はアウトプットができないのか? - Qiita

          はじめに この記事ではQiitaで550本以上記事を書いてきて、アウトプットに関する理論を発信し続けている私(@Sicut_study)がこれまでに発信してきた内容を1つの記事にまとめたものです。 私はプログラミングコーチングJISOUというアウトプット中心の最速でエンジニアとして成長できる教育事業を実施しております。 その中で多くの方と面談をしてきました。これからエンジニアになる人や、一定数経験している人など100人以上の方とお話をさせていただきましたが、エンジニアとしてのキャリアに悩む多くの人が共通した悩みを抱えていました。 勉強しているのだけど身についた感じがしない 自分のサービスを1つもリリースしたことがない(作りきった経験がない) インプットばかりになってしまう(インプットばかりに気づいていない) アウトプットが大事なのはわかるがやり方がわからない つまりエンジニアとして成長でき

            【完全解説】なぜ人はアウトプットができないのか? - Qiita
          • 注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

            公開日 2024/05/27更新日 2024/05/27注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女

              注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
            • ユニットテストってもう言わない! CI/CD時代のテスト分類に最適なテストサイズという考え方

              はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか? 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って

                ユニットテストってもう言わない! CI/CD時代のテスト分類に最適なテストサイズという考え方
              • エンジニアのための十徳ナイフ「DevToys」がバージョン2になってクロスプラットフォームやCLI対応しさらに便利すぎる - Qiita

                はじめに 以前紹介させていただき、2022年Qiitaのいいねランキング18位、ストックランキング20位を記録したこちらの記事の続編です! DevToysはリリース後しばらく定期的なバージョンアップが続けられていましたが、去年の7月からぱったりとアップデートが止まっている状態でした。 リポジトリや作者のXを見るとバージョン2の開発を行っているようで、今か今かと待ち続けていましたが数日前リリース予告のポストを見つけて、今日ついにプレリリースされました! ということで早速紹介していきます! DevToysとは DevToysは「開発者のためのスイスアーミーナイフ」の紹介文の通り、開発時によく使うツールを十徳ナイフのようにまとめたアプリとなっています。 JSONの整形とかエンコードデコードetc... プログラミングや保守運用の調査でやりがちな作業をいちいち変換サイトを探したり、エディター拡張機

                  エンジニアのための十徳ナイフ「DevToys」がバージョン2になってクロスプラットフォームやCLI対応しさらに便利すぎる - Qiita
                • DB設計書の管理が楽になるDBML入門 – DBMLの書き方,dbdiagram.io, dbdocs の紹介 – | SIOS Tech. Lab

                  こんにちは!サイオステクノロジーの安藤 浩です。DB設計書の生成が容易にできるDBMLをご紹介します。DBMLの入門として、DBMLの書き方、ER図生成方法、Github actionsでCIを実行して閲覧する方法をご紹介させていただきます。 DBMLとは DBML は DataBase Markup Language の略でDB構造を定義するために設計された言語です。 DB構造に焦点を当てており、可読性の高い言語です。 dbdiagram.io や dbdocs.io などを利用することでDBドキュメントの生成が可能です。 コードベースで図を生成できる点でPlantUMLと似ていますね。 DBMLの書き方 テーブルの書き方 まずはテーブルの定義の例をもとにDBMLの記法を紹介していきます。users というテーブルを作成してみます。コードは以下のようになります。 Table users

                    DB設計書の管理が楽になるDBML入門 – DBMLの書き方,dbdiagram.io, dbdocs の紹介 – | SIOS Tech. Lab
                  • 「AIイラストって絵の勉強になる…?」取材を受けて考えたあれこれ|賢木イオ

                    こんにちは、AI絵をやってたらいつのまにか人並みに絵が描けるようになってたおじさんです。前回の記事が微妙にバズったところ、美術関係の教育者の方から「AIで絵を学ぶのってどういう感じですか?うちの学生にもできますか?」というお問い合わせを相次いで頂きまして、今日は質問にお答えする中で考えたことをAI技術の進歩の振り返りとともに記事にしてみようと思います。 前回の記事( ▲ )を書いたのが今年3月のこと。その後、美術系の大学と専門学校、予備校の方から別々にDMを頂きまして、それぞれウェブインタビューのような形で1~2時間ほどお話ししました。インタビューの内容は、おおむねどの方も「これからの世代に美術を教える上で、画像生成AIについて触れないわけにはいかない。どのような距離感で扱えばよいのか決めかねており、実際に体験しているユーザーに話を聞いてみたい」という趣旨だったかと思います。 インタビュー

                      「AIイラストって絵の勉強になる…?」取材を受けて考えたあれこれ|賢木イオ
                    • Gitのブランチの役割を考える | フューチャー技術ブログ

                      Gitのブランチ戦略にはいくつかあります。 GitフローGitHubフローGitLabフローチームの戦略を考えるときにどれかを参考にしつつカスタマイズするときにいろいろ不都合が生じてしてきて複雑になってしまうことってありますよね?社内でブランチの管理の議論をする中で、ブランチの役割を明確にした上で、どのブランチがどのような役割を持っているのかを明確にした方が混乱が少なくなるのではないか?というのを考えていました。 特に、プロジェクトごとに同じ名前でも役割が違うなー、というのとかもあり、ブランチ名=役割ではなく、ブランチの上位概念として役割を考えて、それを実際のブランチとの対応づけを行う必要があるのではないかな、と。 CI/CDと組み合わされることで、releaseブランチ==ステージング環境となってしまい、ステージング環境を使いたいリリース前のブランチと、ホットフィックスの検証のブランチの

                        Gitのブランチの役割を考える | フューチャー技術ブログ
                      • 『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ!

                        『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本? GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/

                          『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ!
                        • 「入門 継続的デリバリー」は継続的デリバリーを学ぶのに最適な教科書だった. - Lean Baseball

                          最近読んだ「入門 継続的デリバリー」がとても良かったので紹介しますね, というエントリーです. 入門継続的デリバリー良かったです. 「継続的デリバリー(Continuous Delivery)」とか「DevOps」ってどこから学ぶかわからんな!? というのは割とあるあるだと思っています, そもそもめちゃくちゃ難しい話なので(ちゃんと学ぼうとすると). そんな中, 「入門 継続的デリバリー」がよく説明できてて良かったので感想と関連する書籍を紹介できればと思っています. TL;DR 入門 継続的デリバリー 我々はなぜCDをするのか? 具体的なプラクティス 入門後に読むべき良著 Kubernetes CI/CDパイプラインの実装 継続的デリバリー チームトポロジー 結び - 我思うCDとDevOps TL;DR 「入門 継続的デリバリー」は継続的デリバリーの大切さと概念, 手法を現実にありそうな

                            「入門 継続的デリバリー」は継続的デリバリーを学ぶのに最適な教科書だった. - Lean Baseball
                          • 「システム運用の基本と戦略」についてただまとめる

                            23卒でバックエンドエンジニアをしているたかしゅんです。(@1341Shun) 先日、株式会社サイバーエージェントAI事業本部の2024年度 エンジニア新卒研修でシステム運用に関する講義を行いました。 そこで話した内容とスライドを完全公開したので、内容について解説します。 90分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 実際の資料はこちらになります↓ 自己紹介 こんにちは、たかしゅんと言います。2023年度入社で今年で2年目になります。株式会社サイバーエージェントのAIオペレーション室で新規立ち上げをやっております。 入社して最初に広告プロダクトに配属し、PipeCDの導入などのDevOps業務を中心に行なっておりました。 記事もあるのでもしよろしければ、ご覧ください。 2月中旬からAIオペレーション室に移動し、新規立ち上げのインフラ環境の構築からCI

                              「システム運用の基本と戦略」についてただまとめる
                            • 新卒で入社したサイバーエージェントを退職しました - moko-poi’s diary

                              この節目に、人生初の就職から約1年の経験を振り返り、感謝の気持ちを込めて綴りたいと思います。 自己紹介 たかしゅん/moko-poiと申します。私は主にAWSを中心としたインフラ構築やDevOpsの促進に取り組んでいます。 サイバーエージェントには新卒で入社し、バックエンドエンジニアとして配属されました。その中で、特にDevOpsやAWSなどのインフラ関連の業務に注力し、さまざまなプロジェクトに携わってきました。 サイバーエージェントでやったこと 2023年4月に新卒としてサイバーエージェントにバックエンドエンジニアとして入社しました。その前に、内定者アルバイトとして約3ヶ月間勤務していたため、合計で約1年半在籍していました。全てを詳しく話すと長くなってしまいますので、ここでは主な取り組みを簡潔にご紹介します。 広告 内定者バイトの時から、少人数チームでバックエンドの機能開発だけでなくイン

                                新卒で入社したサイバーエージェントを退職しました - moko-poi’s diary
                              • Findyの爆速開発を支えるテクニック - Findy Tech Blog

                                こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 早速ですが、これは弊社のとあるチームの1ヶ月のサイクルタイムです。 最初のコミットからマージされるまで平均3.6時間程度と、開発に着手したらその日のうちにリリースされるのがデフォルトとなっています。 今回はこの開発スピードを継続し、更に速くするために弊社で実践しているテクニックを紹介していきます。 それでは見ていきましょう! タスク分解 Pull requestの粒度 テスト CI/CD 高速化 自動化 通知 まとめ タスク分解 開発タスクをアサインされた時、まず最初にタスク分解をします。 タスク分解をすることによるメリットとしては、 工数見積もりの精度が上がる 対応方針の認識を他メンバーと合わせやすくなる 対応漏れに気づきやすくなり、手戻りの発生が少なくなる Pull requestの粒度を適切に保つことが

                                  Findyの爆速開発を支えるテクニック - Findy Tech Blog
                                • E2Eテストワークフローを高速化・安定化させる取り組み | ドクセル

                                  スライド概要 GitHub Actions Meetup Tokyo #3 https://gaugt.connpass.com/event/317178/ このプレゼンテーションでは、サイボウズ社のGaroonのE2Eテストについて、GitHub Actions self-hosted runner 上で実行していたE2Eテストを高速化・安定化させるために取り組んだこと、E2Eテストワークフローの視点の改善アイディアについて話されます。GaroonのE2Eテストにおける実行時間とFlakyが問題となっており、その改善に取り組んだ内容が紹介されています。 おすすめタグ:GitHub Actions,E2Eテスト,self-hosted runner,Garoon,テストワークフロー

                                    E2Eテストワークフローを高速化・安定化させる取り組み | ドクセル
                                  • フロントエンド開発の効率化!Nx と Playwright でビジュアルリグレッションテストを賢く実施しよう - Techtouch Developers Blog

                                    はじめに なぜ VRT が必要なのか? VRTとは? Nx と Playwright で賢く VRT を実施する どう賢く実施したか 結果 まとめ 参考資料 はじめに 「食べログ ラーメン TOKYO 百名店」の全店舗訪問を目指してラーメン巡りを続けているフロントエンドエンジニアの kenshin です。 フロントエンド開発者の皆さん、新機能を追加したり、ライブラリをアップデートした後に UI が予期せず変更されてしまった経験はありませんか?このような問題を素早く検知し、未然に防ぐ方法として、ビジュアルリグレッションテスト(以下、VRT)があります。 この記事では、Nx と Playwright を用いて VRT を効率的に行う方法をご紹介します! なぜ VRT が必要なのか? フロントエンド開発では、新機能の追加やライブラリのアップデートにより、予期せぬ UI 変更が発生することがありま

                                      フロントエンド開発の効率化!Nx と Playwright でビジュアルリグレッションテストを賢く実施しよう - Techtouch Developers Blog
                                    • GitHub Actionsにおける脅威と対策まとめ

                                      はじめに こんにちは、サイボウズ24卒の@yuasaです。 サイボウズでは開発・運用系チームに所属する予定の新卒社員が研修の一環として、2週間を1タームとして3チームの体験に行きます。新卒社員の私が生産性向上チームの体験に行った際に、チーム内でGitHub Actionsを利用する際の脅威と対策について調査を行い、ドキュメント化した上で社内への共有を行いました。本記事では、そのドキュメントの一部を公開します。 対象読者 本記事の主な対象読者としては、以下のような方を想定しています。 GitHub Actionsを組織で利用しているが、特にセキュリティ対策を実施していない方 GitHub Actionsを組織で利用しており、部分的にセキュリティ対策を実施しているが、対策が十分かどうか分からない方 本記事がGitHub Actionsのセキュリティ対策を検討する上で参考になれば幸いです。 本記

                                        GitHub Actionsにおける脅威と対策まとめ
                                      • CyberAgent AI事業本部新卒研修「MLOps」の資料を公開します | CyberAgent Developers Blog

                                        はじめに 近年、様々な分野で機械学習の利用が進む中、モデルの品質を担保し、継続的な学習を行うための施策が重要視されています。そのため、機械学習のためのDevOpsであるMLOpsの必要性が高まっており、AI事業本部でも研修内容に取り入れています。 より良いMLOpsを構築するためには、アプリケーションやインフラの知識も必要です。そのため、今年は昨年までと異なり、MLエンジニアだけでなくソフトウェアエンジニアも講義に参加しました。また、新たに実践編が加わり、より業務を意識した講義が追加されました。 Container編 基礎編 応用編 実践編 そこで、今回は研修で行われた各講義の資料を公開したいと思います。 Container編 Container編では、コンテナにまつわる技術に対しインデックスを張ることと、イメージ作成や運用時のTipsを学び実業務に役立てることを目的としています。 そのた

                                          CyberAgent AI事業本部新卒研修「MLOps」の資料を公開します | CyberAgent Developers Blog
                                        • GitHub CI/CD実践ガイド ――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用

                                          この本の概要 本書はCI/CDの設計や運用について,GitHubを使ってハンズオン形式で学ぶ書籍です。GitHub Actionsの基本構文からスタートし,テスト・静的解析・リリース・コンテナデプロイなどを実際に自動化していきます。あわせてDependabot・OpenID Connect・継続的なセキュリティ改善・GitHub Appsのような,実運用に欠かせないプラクティスも多数習得します。 実装しながら設計や運用の考え方を学ぶことで,品質の高いソフトウェアをすばやく届けるスキルが身につきます。GitHubを利用しているなら,ぜひ手元に置いておきたい一冊です。 こんな方におすすめ GitHubは使っているけれど,プルリクエストぐらいしか利用していない CI/CDというキーワードは知っているけれど,自分で設計したことはない GitHub Actionsには触れているけれど,正直雰囲気で運

                                            GitHub CI/CD実践ガイド ――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用
                                          • Software Design 2024年5月号 連載「レガシーシステム攻略のプロセス」第1回 ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計 - ZOZO TECH BLOG

                                            はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 本連載では、ZOZOTOWNリプレイスプロジェクトについて紹介します。2017年に始まったリプレイスプロジェクトにおいて、ZOZO がどのような意図で、どのように取り組んできたのか、読者のみなさんに有益な情報をお伝えしていければと思いますので、ご期待ください。第1回目のテーマは、「ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計」です。 目次 はじめに 目次 ZOZOTOWNリプレイスの背景、目的 背景 目的 柔軟なシステム 開発生産性 技術のモダン化 採用強化 ZOZOTOWNリプレイスの歴史とアーキテクチャの変遷 アーキテクチャの変遷 2004年〜2017年:オンプレミス(リプレイス前) 2017年〜20

                                              Software Design 2024年5月号 連載「レガシーシステム攻略のプロセス」第1回 ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計 - ZOZO TECH BLOG
                                            • GitHub Actions 上での Go の Docker ビルドを高速化する

                                              どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。 go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go build は Dockerfile のステップで行っており、イメージとして以下のような内容になっています。 FROM

                                                GitHub Actions 上での Go の Docker ビルドを高速化する
                                              • Rubyインタプリタのむずかしいバグを直した - STORES Product Blog

                                                STORESでフルタイムRubyコミッタをやっている遠藤(@mametter)です。 最近Rubyインタプリタのとある問題の修正に成功した(と思う)ので紹介します。といっても格好良い話ではなく、とても泥臭い話です。 問題 RubyのCIで不定期に次のようなエラーが発生していました。いわゆるflaky test。 1) Failure: TestSymbol#test_inspect_under_gc_compact_stress [.../ruby/test/ruby/test_symbol.rb:126]: ":testing" expected but was ":\"\\x00\\x00\\x00\\x00\\x00\\x00\\x00\"". 発生確率が絶妙で、しばしば起きるのですが、デバッグのために狙って再現しようとしても起きないという代物でした。 問題の分析 エラーが起きていた

                                                  Rubyインタプリタのむずかしいバグを直した - STORES Product Blog
                                                • とあるインフラ屋のプルリクエストレビュー奮闘記 - NRIネットコムBlog

                                                  本記事は 【プルリクウィーク】 2日目の記事です。 💻 1日目 ▶▶ 本記事 ▶▶ 3日目 📚 はじめに Git と インフラ屋 と IaC そもそもインフラ屋が管理するコードとは? IaC インフラ関連の設定ファイル CI/CD周りの設定ファイル PRレビューで難しいと思うこと 何を持ってOKとするか そもそも検証が難しい 網羅性が判断つかない PRレビューで意識していること 静的チェックの導入 コメントには意向を示す略語を付ける コメントがFixすればリアクションしてクローズする 対面レビューの時間を設ける リリースとの親和性が高い さいごに はじめに こんにちは、加藤です。 普段、私はインフラエンジニア(以下インフラ屋)としてシステム運用に携わっています。 最近はIaCの普及もあり、インフラチームでもプルリクエスト(以下PR)レビューを実施しているチームが多いのではないでしょうか

                                                    とあるインフラ屋のプルリクエストレビュー奮闘記 - NRIネットコムBlog
                                                  • メルカリ ハロの技術スタックとその選定理由 | メルカリエンジニアリング

                                                    こんにちは。メルカリ ハロのSoftware Engineer (Engineering Head)の@napoliです。連載:Mercari Hallo, world! -メルカリ ハロ 開発の裏側-の2回目を担当させていただきます。 2024年3月上旬にメルカリ ハロという新しいサービスが公開されました。メルカリ ハロは好きな時間に最短1時間から働ける「空き時間おしごとアプリ」です。 この記事ではメルカリ ハロを作るにあたり、どういった技術スタックやアーキテクチャを選定したのか、さらにその背景と意思決定をご紹介したいと思います。 この記事で得られること メルカリ ハロで採用されている技術スタックやアーキテクチャの全体像 その意思決定の理由とプロセス これから新規サービスを立ち上げるうえでのヒント 主な技術スタック メルカリ ハロで利用されている主な技術スタックは以下のとおりです。 バッ

                                                      メルカリ ハロの技術スタックとその選定理由 | メルカリエンジニアリング
                                                    • プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは一体なのか | Google Cloud 公式ブログ

                                                      Darren EvansEMEA Practice Solutions Lead, Application Platform ※この投稿は米国時間 2024 年 5 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。 なぜ新しいトピックに対して否定的になってしまう人がいるのか、その理由は、群盲象を評すの寓話からわかります。その人自身の視点からのみで物事を見てしまうと、その全体像を見失ってしまうということです。プラットフォーム エンジニアリングはソフトウェア デリバリーの比較的新しい手法です。現在、IT 組織やソフトウェア エンジニアのチームの多くがプラットフォーム エンジニアリングについて検討している段階にあるのですが、プラットフォーム エンジニアリングとは何なのか、プラットフォーム エンジニアリングで何ができるのか、プラットフォーム エンジニアリングを導入す

                                                        プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは一体なのか | Google Cloud 公式ブログ
                                                      • Live types in a TypeScript monorepo

                                                        EDIT: A previous version of this post recommended publishConfig, operating under the mistaken belief that it could be used to override "exports" during npm publish. As it turns out, npm only uses "publishConfig" to override certain .npmrc fields like registry and tag, whereas pnpm has expanded its use to override package metadata like "main", "types", and "exports". There are a number of reasons y

                                                          Live types in a TypeScript monorepo
                                                        • [入門]Webフロントエンド E2E テスト――PlaywrightによるWebアプリの自動テストから良いテストの書き方まで

                                                          この本の概要 E2Eテスト(End-to-End Testing)とは,システムの端から端(End-to-End)まで,全体を通して行うソフトウェアテストを指します。本書ではE2Eテストを「ユーザーの視点でWebシステムの動作を確認する自動テスト」として定義し,E2Eテストをこれからプロジェクトに導入しようとしている人,すでに導入しているがパフォーマンスや保守性で課題を感じている人を対象に,E2Eテストのフレームワークとして近年人気が急上昇しているPlaywrightをツールとして,その目的からモダンなノウハウまで,E2Eテスト初心者の方にもわかりやすくハンズオンを交えながら解説します。CIへ組み込む方法やユニットテストとの棲み分けなど,E2Eテストを実際の開発現場に投入するうえでの知見も数多く紹介します。 こんな方におすすめ E2Eテストをこれからプロジェクトに導入しようとしている人 す

                                                            [入門]Webフロントエンド E2E テスト――PlaywrightによるWebアプリの自動テストから良いテストの書き方まで
                                                          • NetworkPolicyでtrafficを制御しよう - enechain Tech Blog

                                                            はじめに こんにちは。enechainのPlatform Engineering Deskで働いているsoma00333です。 enechainではproductのdeploy先としてGKEを採用しており、Platform Engineering DeskではKubernetes Clusterの運用業務を行っています。 enechainは「エネルギーの取引所を作る」というmissionを持っており、productも増えてきています。 Platform Engineering Deskも今後ますますsecurityに力を入れていく予定です。 前回は、Platform Engineering Deskのsecurityに関する取り組みの一例として、Pod Security Admissionを紹介しました。 ※ Pod Security Admissionの紹介 今回は、引き続きsecuri

                                                              NetworkPolicyでtrafficを制御しよう - enechain Tech Blog
                                                            • “非同期な開発組織”におけるドキュメントの「強み」 時間の節約、深く理解できる、フィードバックを深く・平等にできる…

                                                              Launchable, Inc.のソフトウェアエンジニアであるこんぼい氏は、ドキュメントを大事にしている理由と、具体的にどのようなドキュメントを運用しているのか、また、ドキュメント文化醸造のための取り組みについて紹介しました。全2回。 こんぼい氏の自己紹介 こんぼい氏:よろしくお願いします。「非同期な開発体制を支えるドキュメント文化」ということで発表します。 まず自己紹介をします。矢吹遼介と申します。Launchableという会社でソフトウェアエンジニアをやっています。インターネット上ではゴリラのアイコンで「Konboi」というIDでやっています。よろしくお願いします。 Launchableについて はじめにLaunchableについて軽く紹介させてください。USに本社があって、Jenkinsの作者の川口さん(川口耕介氏)がSun(Sun Microsystems)の時の同僚のHarpre

                                                                “非同期な開発組織”におけるドキュメントの「強み」 時間の節約、深く理解できる、フィードバックを深く・平等にできる…
                                                              • マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 - Sansan Tech Blog

                                                                Sansan Engineering UnitでSansan Data Hubの開発をしている藤原です。 前回はニッチに深く潜り過ぎたので、今回は(使い古されたネタではありますが)モノレポ化についてお話ししたいと思います。 おさらい:モノレポ(mono repo)とは 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 逆に、複数のリポジトリに分けている状態をポリレポ(poly repo)と言います。 モノレポのメリットとデメリット モノレポ化することで、以下のようなメリットが得られます。 プロダクト全体で統一したい設定、たとえばCIスクリプトやlinter設定などの管理が楽になる。 検索が楽になる。GitHubの検索で事足りること

                                                                  マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 - Sansan Tech Blog
                                                                • CLIツールの管理をSPMからMintに移行した経緯とその課題 - Mirrativ Tech Blog

                                                                  はじめに お久しぶりです、iOSチームにインターンとして参加させて頂いておりますMと申します。 MirrativのiOSアプリでは、これまでSwift製のCLIツールをBuildToolsという名前のSwift Packageを作成してこれにまとめて管理していました。 しかしこの度、ある課題や利便性の観点からyonaskolb/Mintでの管理に移行しました。 今回はMintへの移行に至るまでの背景や経緯、および移行に際して起こったいくつかの課題をどのように解決したかについて書いていこうと思います。 目次 はじめに 目次 Mintへの移行に至る背景 CLIツールの利用 SPMによる管理における課題 依存関係の不整合 依存解決の時間 Mintへの移行 Mintへの移行時に発生した課題とその解決 バージョンの自動更新 バージョン更新のためのコマンドを実装 1. Mintfileのパスを取得 2

                                                                    CLIツールの管理をSPMからMintに移行した経緯とその課題 - Mirrativ Tech Blog
                                                                  • RubyKaigi 2024 のサイネージについて

                                                                    今月中旬に沖縄県那覇市で RubyKaigi 2024 を開催した。COVID-19 対応をしていた RubyKaigi Takeout 2020, RubyKaigi Takeout 2021, RubyKaigi 2022, RubyKaigi 2023 とは異なり、今回は配信を伴わないオフラインのみの開催だった。 わたしは Organizer の一人として Sponsor Relations 業などをしつつ、Wi-Fi の支度をしたり、サイネージの支度をしたりしていた。Wi-Fi の話はこれまでもいくつか書いている のでまた今度として、今回はサイネージの話をかきます。 RubyKaigi ではいくつかのサイネージの映像を用意して会場のあちこちに表示している。各セッション会場の横に添えて字幕やチャット, LT タイマーを流すサブスクリーン、お知らせやセッション案内を廊下に設置したモニタ

                                                                    • AWS Systems Manager Parameter Storeを便利に使うツール "ssmwrap" がv2になりました - KAYAC engineers' blog

                                                                      SREチームの長田です。 今回はssmwrapという拙作CLIツールのはなしです。 ssmwrapとは ssmwrapは、AWS Systems Manager Parameter Store(以下SSM Params)から値を取得し、 環境変数またはファイルに出力した上でコマンドを実行するツールです。 secret類をSSM Paramsに保存している場合、アプリケーション実行時にSSM Paramsから必要な値を取得することになります。 AWSのサービスにアクセスするという操作は、それなりに手間がかかるものですが、 ssmwrapを使えば環境変数とファイルというより簡便な入出力インターフェイスを通してSSM Paramsの値を参照できます。 実装が簡潔になるだけでなく、アプリケーションからのAWS APIへの依存を排除することにもなります。 # SSM Paramsにこんな値が保存され

                                                                        AWS Systems Manager Parameter Storeを便利に使うツール "ssmwrap" がv2になりました - KAYAC engineers' blog
                                                                      • Cleanup handling in Go / Go Conference 2024

                                                                        CI/CDがあたりまえの今の時代にAPIテスティングツールに求められていること / CI/CD Test Night #7

                                                                          Cleanup handling in Go / Go Conference 2024
                                                                        • feature flag管理にAWS AppConfigを導入した - Cluster Tech Blog

                                                                          昔のflag管理 AWS AppConfigの導入 feature flagの管理 feature flagの利用 まとめ ソフトウェアエンジニアの浦川です。 clusterではサービス開発にfeature flagが活用されており、常時10+個程度のflagが並行して使われています。 これまでflagはgoのコードとしてハードコードされていたのですが、AWS AppConfigを利用してコードを修正することなく動的に変更できるようにしました。 昔のflag管理 ハードコードされたflagは1つのstructにまとめて定義されていて // feature flagを集めたもの type FeatureFlag struct { IsAvatarXxx bool // アバターを良い感じにする IsEventXxx bool // イベントを良い感じにする // (大量のフラグ) } app

                                                                            feature flag管理にAWS AppConfigを導入した - Cluster Tech Blog
                                                                          • GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる

                                                                            GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる 2024/06/03 に GitHub Actions に Arm64 ランナーが追加されました。 現在はパブリックベータで、Team と Enterprise Cloud プランでのみ利用可能です。料金は x64 の同性能のランナーより 37% 安く、電力効率が高いため二酸化炭素排出量削減にもつながるとのことです。 この記事では、新しく追加された Arm64 ランナーを使って Docker のマルチプラットフォームイメージをビルドしてみます。 マルチプラットフォームイメージとは? マルチプラットフォームイメージとは、複数の異なる CPU アーキテクチャ(場合によっては異なる OS)のイメージを 1 つのイメージとして扱えるようにまとめたものです。マルチプラット

                                                                              GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる
                                                                            • モノレポでマージキューと必須ステータスチェックを運用するためのTips - ROUTE06 Tech Blog

                                                                              ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 GitHub のマージキュー(Merge Queue)を私のチームでの開発フローに取り入れてから数ヶ月経ちました。マージキューは非常に便利ですが、挙動の理解やセットアップに難しさがあると感じています。いくつかの課題の対処ができ安定した運用ができてきたので、この記事ではセットアップでつまづきがちな点を紹介します。 マージキューとは マージキューは 2023 年 7 月に一般公開された比較的新しい機能で、簡単に説明すると「プルリクエストのマージ前にマージ先ブランチを取り込んだ上で CI を実行し、通ることを確認してからマージする」機能です。 複数人で GitHub を利用した開発をしていると、main ブランチの取り込み漏れにより「プルリクエストでの CI は通るものの、マージ後の main ブランチの CI は失敗する

                                                                                モノレポでマージキューと必須ステータスチェックを運用するためのTips - ROUTE06 Tech Blog
                                                                              • ハマったポイントたくさんあったけどPlay3.0/Scala3.3へバージョンアップできたよ - エムスリーテックブログ

                                                                                こんにちは。エムスリーエンジニアリンググループでScalaとマミさんが好きな安江です。今回は私が所属している製薬企業向けプラットフォームチームのPlay製プロダクトのPlay/Scalaバージョンアップのお話です。当初Play2.8にバージョンアップしていたのですが、その最中にPlay2.9/Play3.0やScala LTSが出たりもしました。最終的にPlay3.0/Scala3.3にバージョンアップできて本番稼働できたサービスもあるので、そのバージョンアップの経緯をご紹介します。 Play2.8への道のり Play3.0へのバージョンアップ ハマり1:依存ライブラリがPlay2系に依存している ハマり2:ScalikeJDBCの依存関係 ハマり3:サーバーバックエンドの変更 ハマり4:sttpのバックエンドの変更 ハマり5:if式が値を返さない まとめ We are hiring !!

                                                                                  ハマったポイントたくさんあったけどPlay3.0/Scala3.3へバージョンアップできたよ - エムスリーテックブログ
                                                                                • Q by LivesenseをWordPress on EC2からHugo on Cloudflare Pagesに移行しました - LIVESENSE ENGINEER BLOG

                                                                                  はじめに 技術構成(before)と課題 技術構成(after)と選定の理由 改善したこと パフォーマンスの向上 デリバリー速度の向上 セキュリティ面でのリスク低下 大変だったこと 記事のマークダウン変換 段落分けと改行の区別 字下げ 書式の追加 Lintが必要になった 記事ごとのOGP画像周りの実装 URL変更に伴うリダイレクト設定 標準の検索機能がない おわりに はじめに 技術部の @mom0tomo , @etsxxx です。 技術部では、事業部横断的な仕事としてコーポレートサイトの運用も行っています。このたびWordPress on EC2で運用されてきた弊社のWebメディア(Q by Livesense)を、Hugo on Clouflare Pagesに移行しました。 q.livesense.co.jp 弊社のWordPress運用はやや特殊で、エンジニアがサーバーにSSHして

                                                                                    Q by LivesenseをWordPress on EC2からHugo on Cloudflare Pagesに移行しました - LIVESENSE ENGINEER BLOG