kintone のテストを JUnit 5 に移行した話 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、kintone 開発チームの @hikoma です。kintone のテストを JUnit 4 から JUnit 5 に移行した話を公開したいと思います。 背景 2017 年に JUnit 5 がリリースされてから約 4 年半、みなさんは既に JUnit 5 を利用していることかと思います。 kintone では JUnit 5 への移行がなかなか進みませんでした。テストのボリュームがそれなりにあり（Java の単体テストが約 6500、REST API のテストが約 4000、Selenium のテストが約 3000）、E2E テストで並列実行やリトライのために JUnit 4 の仕組みを利用していたので、目に見える問題が起きていない状況では優先度も上がりませんでした。 しかし、このような状況ではテストの改善に着手しにくく、持続的な開発のリスクも感じていたため、何度目かの移行
Docker Compose V2で変わったdocker-compose.ymlの書き方
概要 2021年の後半にDocker Compose V2がリリースされました Docker Compose V2はCompose Spec[1]に準拠しているため、docker-compose.ymlもその仕様に則った書き方ができるようになっています services: app1: image: awesome/webapp configs: - my_config secrets: - server-certificate app2: image: awesome/database extends: service: app1 configs: my_config: file: ./my_config.txt secrets: server-certificate: file: ./server.cert services: app1: configs: - source: my_co
個人開発のコストはDB次第 - laiso
個人でWebサービスを継続的に運用するのは金がかかってかなわんという問題がある 「個人開発」だと定義が曖昧なので自己資金かつ赤字のプロジェクト(Webサービス)ということにする。 そういうプロジェクトではプロダクトオーナー=自分、開発者=自分、予算管理者=自分というロールになるので予算管理者としてコストを図る必要がある(ここでいうコストはWebサービスを実現するアプリケーションのランニングコストのこと)。 通常はみんな自分の人件費を0として計算していると思う(逆にいうとそれが負債という考え方もできると思う)。 ただしメンテナンス時間とコストのトレードオフもあるので、人件費0ではあるけど有限の時間は別軸として管理しているのが普通だと思う。極端な例だと「コスト削減できるけどメンテナンス時間10倍になる」というのは避けられる。 仮に個人開発のプロジェクトの予算を月数千円から高くても1万円ぐらいか
abseil / Software Engineering at Google
Software Engineering at Google In March, 2020, we published a book titled “Software Engineering at Google” curated by Titus Winters, Tom Manshreck and Hyrum Wright. The Software Engineering at Google book (“SWE Book”) is not about programming, per se, but about the engineering practices utilized at Google to make their codebase sustainable and healthy. (These practices are paramount for common inf
Announcing Compose V2 General Availability | Docker
Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build Cloud Speed up your image buildsTestcontainers Desktop Local testing with real dependenciesTestcontainers Cloud Test without limits in the cloud See our product roadmapMORE resources for developers
未踏ジュニアにおけるよい提案資料の書き方、もしくはアイデアの伝え方と評価について｜Yoshifumi Seki
こんにちは、関です。 本エントリでは未踏ジュニアの応募書類を僕がどのように見ているかということについて書きます。本エントリの内容は未踏ジュニアという枠にとどまらず、なにかアイデアを整理したり、誰かに伝える方法論としても役立つないようなのかなと勝手に思っています。 このエントリ、本当は未踏ジュニア2019の応募開始に寄せて書き始めたんですけど、書ききれずに眠っていました。 はじめに先日未踏ジュニアの2022年度の応募が開始されました。私は2017年度からメンターを務めております。 未踏ジュニアはU-18のジュニア世代のクリエイターに対して、開発資金50万円とメンタリングを提供し、クリエイターのものづくり支援を行うプロジェクトです。 ここ数年、応募総数は100件を超えています。近年採択者やOBOGがどんどん活躍の場を広げていることから未踏ジュニアの知名度があがっており、今年も厳しい選考になると
April 2022 outage update
As of Apr 18, 2022, 23:57 UTC, all customers impacted by the outage have been restored. On Monday, April 4th, 2022 PT approximately 400 Atlassian Cloud customers experienced a full outage across their Atlassian products. As of April 18th, 2022, we have now restored our customers impacted by the outage and have reached out to key contacts for each affected site. Our support teams are working with i
寿司食いてえ(+包丁の話)
ネタとシャリの間にわさびが入ってる程度の寿司をたらふく食べたい。 いわゆる100円寿司各社がわさびを別添にするようになってどれほど経っただろう。 あれもそんなに嫌ってもないのだが、しかしわさびはネタとシャリの間にいてほしいし、ネタとシャリは横倒しにしても分離しない程度に握り固められていてほしいものである。 このささやかな願いに同調してくれる人は決して少なくないと信じているが、しかしこれを叶えることは存外容易でないものである。 百円寿司で一旦ネタを剥がしてわさびをつける戦略は思いの外満足度が低かった。 回らない寿司は週2で通えるものではないので考慮しなかった。 上記が叶う程度の回転寿司は採算がアレなのかコスパが良くなく、何よりレーンの中に板前が居たりしてコロナ禍において通いづらかった。 宅配寿司は1人前をなんとなく頼みづらかった。 持ち帰り寿司は最も理想に近かったが、ヘビロテすると飽きが来た
“HTTPSレコード”って知ってる？今知るべき4つの注意点 | IIJ Engineers Blog
[注] この記事はすぐに陳腐化するはずの内容について扱っています。何年か経ってからこの記事を参照する場合、2022年3月に書かれた内容であることを留意の上お読みください。 はじめに IIJ DNSプラットフォームサービスにて、先日大きなアップデートと小さなアップデートがありました。大きなアップデートというのは、これまでのマネージドDNSサービスに加えてもうひとつ、IIJ DNSトラフィックマネージメントサービスという新たなサービスが追加されたこと。サーバの死活監視結果に応じて動的にDNSの応答を変えることができます。小さなアップデートは、従来のマネージドDNSサービスへの機能追加。HTTPSレコードに対応しました。 サービスの宣伝という意味では大きなアップデートの方を紹介した方がいいんでしょうけれど、ヘソ曲がりなのでここでは小さなアップデート、HTTPSレコードの方に焦点をあてます。 そも
セキュリティツールの評価は難しい - knqyf263's blog
前から思ってたことをちょっと書かずにいられなくなったのでポエムを書きました。 背景 問題 検知している方が正しいように見えがち 条件を揃えるのが難しい 環境の再現が難しい 検知数が多い方が良さそうに見える 正解かどうかの判断が難しい カバー範囲の正確な見極めが難しい 検知されないほうが嬉しい まとめ 背景 お前誰だよってなるかもしれないので書いておくと、Trivyという脆弱性スキャナーのメンテナをやっています。 github.com とある有名な方による以下のツイートがありました。 I just discovered, during @cloudflare #SecurityWeek no less, that Trivy (the vuln scanner) doesn't detect known issues in Alpine images. Including a critica
IPOをあきらめかけたことがある、という話｜山本 正喜 / kubell CEO
2022年3月1日で、Chatworkは11周年を迎えることができました。 この流れの速いインターネット業界において、10年以上続くサービスというのもあまりなく、Chatworkが社内システムからはじまったことを思えば感慨深いものがあります。 Chatworkは約11年前の2011年3月1日に正式リリースされ、2015年4月27日にはじめて外部の資金調達を実施しスタートアップの道へ。そこから2019年9月24日に東証マザーズへとIPOを果たしました。 リリースしてから8年半でのIPO、というのはスタートアップとしては遅い方？なんですかね。 VCのファンド償還期限が一般的には10年ですから、もしChatworkにプロダクトローンチ前のシード期から投資していたら、ギリギリ間に合ったかなというぐらいでしょうか。 Chatworkは外から見ると、とても順調にIPOまで行ったように見えると言われたこ
「0回目のポストモーテム」としてのプレモーテムのすすめ - スタディサプリ Product Team Blog
こんにちは。SREの@kyontanです。スタディサプリのSREチームにジョインしてから初のブログ記事となります。 つい先日、スタディサプリ 中学講座が大幅リニューアルされました。*1 今回は、そのリリースを自信を持ってユーザーの皆様へお届けするために実施した、プレモーテムという取り組みについてご紹介したいと思います。 背景 今回のスタディサプリ 中学講座のリニューアルは、バックエンド、フロントエンド(Web/iOS/Android)の開発をフルスクラッチで行ったため、大規模なリリースとなりました。 すでにユーザーへ提供しているサービスを、段階的にリニューアルされたものへ切り替えていく複雑なリリースということもあり、リリースにあたっては予期しないトラブルが起きる可能性が推測できます。 通常、さまざまなトラブル(障害)が起きた際には、私たちはあらかじめ定めた障害対応フローに沿って対応を行い、
メルカリShopsでのDesign Docs運用について | メルカリエンジニアリング
こんにちは! ソウゾウのSoftware Engineerの@ogataka50です。連載：メルカリShops 開発の裏側 Vol.2の9日目を担当させていただきます。 9日目はメルカリShopsを開発する中でのDesign Docsの運用について紹介させて頂きます。 Design Docsとは Design DocsとはGoogleなどで取り入れられているシステム設計ドキュメント手法です。開発をする前にプロジェクトの背景や目的、設計、検討した代案などをdocument化します。そしてそれを持って関係者との共有、議論を行うことによって事前に全体を考察し、精度を高め開発後の手戻りを減らすなどが主な目的になります。 例として、GoogleでのDesign Docsについては下記にまとめられています。 Design Docs at Google メルカリShopsでのDesign Docsのte
GraphQLを導入する時に考えておいたほうが良いこと | メルカリエンジニアリング
はじめに こんにちは、ソウゾウSoftware Engineerの@sue71です。連載：メルカリShops 開発の裏側 Vol.2の13日目を担当させていただきます。 以前メルカリメルカリShopsの技術スタックと、その選定理由でBFFの実装にGraphQLを採用していることをお伝えしました。メルカリShopsをリリースしてから約半年たった今、これまでを振り返ってGraphQLサーバーを実装する上での課題やあらかじめ考えておくと良い項目をまとめてみました。また、本記事ではメルカリShopsでGraphQLの実装としてApolloを採用しているため、Apolloの利用が前提の話もいくつか混在しています。予めご容赦ください。 GraphQLの説明や、メルカリShopsの実装方法に関しては以前こちらの記事で紹介しています。こちらも是非ご覧ください。 パフォーマンス課題 GraphQLは、アプリ
リクルート『スタディサプリ』のデータ分析基盤を支える技術と活用事例──RECRUIT TECH MEET UP #3 - TECH PLAY Magazine
200万人近い利用者を要する、リクルートのオンライン学習サービス『スタディサプリ』。そのデータ基盤が約2年の期間を経て、BigQueryを中心としたGCP環境に移管された。従来の基盤における技術的負債や課題をどう解決したのか。リリースに至るまでに開発チームがどのように取り組み、どう成長したのかを紹介する。 ■登壇者プロフィール 株式会社リクルート プロダクト統括本部 まなびデータプラットフォームグループ データエンジニア マネージャー 戸井田 明俊氏 新卒でオンラインゲーム会社に入社し、広告事業やデータ基盤のエンジニアを担当。2017年リクルートに中途入社。データエンジニアマネージャーとして、データ基盤の開発・運用やデータプロダクトの開発に従事。 株式会社リクルート プロダクト統括本部 まなびデータプラットフォームグループ データエンジニア 橘高 允伸氏 2019年リクルート新卒入社。デー
仮想カメラを使った高解像度・高フレームレートのテスト方法 | さくらのナレッジ
こんにちは、テリーです。フルリモートワークになり、会社の機材を借りてテストすることが気軽にできなくなりました。特定の機種でしか発症しないバグや、機種固有の機能を実機で試す場合、わざわざ電車に乗って取りに行くのも面倒だと感じる機会がたびたびあります。 そんな中、高解像度カメラ、高解像度ディスプレイ、高速Wi-Fi、USB-Cの普及により、高解像度配信のための要素技術がこの数年で全て廉価に手軽になりました。そこで4K 60FPSの映像をそのままライブ配信したくなりますが、廉価なWebカメラでは4Kの場合に最大30FPSとなる商品もあります。進化の激しい映像業界で、最新の高性能カメラを毎回買い続けて手元に置いておくのはコスト面で大変です。今回はこのケース、高解像度・高フレームレートの映像配信を、本物のカメラがない状況で手軽にシミュレーションする方法をご紹介します。 仮想カメラとは パソコン用のW
エンジニアを分類する、3つのタイプ｜山本 正喜 / Chatwork CEO
エンジニアのタイプは、技術が好きか、プロダクトが好きか、組織が好きかの3つに大きく分類できる。技術の人は技術の本質を追求しテックリード/アーキテクト、プロダクトの人は技術を手段と割り切りフルスタックエンジニア/PdM、組織の人は開発生産性を高めようとEM/PMOを目指すことが多い — 山本 正喜 / Chatwork CEO (@cwmasaki) February 9, 2022 思っていた以上の反響をいただいて、いろいろと「このケースはどうなんだろ」というコメントも多数いただくので、この分類にいたった背景や考察などを、しっかり記事にしてみようと思います。140文字だと伝えきれない・・！ エンジニアとしての志向性を技術・プロダクト・組織のどれが好きかで分類すると、目指すキャリアパスを考えやすいよねという話で、私がよくエンジニアの若手に話している内容をツイートしたものでした。 3つのタイプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Monitor your hybrid mobile applications with Datadog
目次 - 自由派音楽理論 - SoundQuest
GitHubセキュリティ Organization運用のベストプラクティス
