世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（後編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2

何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている

はじめまして。オプティムのR&Dに所属している新卒2年目の板垣です。 普段は、AI の学習に必要な教師データを作成するためのアノテーションツールの設計・開発・運用を行なっています。 アノテーションツール自体は Web アプリで、クライアント側は React と TypeScript、サーバー側は Go で実装しています。 さて、先日 Clean Architecture 達人に学ぶソフトウェアの構造と設計 という本が ITエンジニアに読んでほしい！技術書・ビジネス書 大賞2019 の技術書部門ベスト10にノミネートされました。 本記事を読もうと思って下さった方の中には、この本を読もうと思っている、または、もう読んだという方が結構いらっしゃるのではないでしょうか。 かくいう私も、携わっているソフトウェアのソースコードがひどくて(というより、そのアーキテクチャでは耐えられなくなってきたと言った

clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

昔ニコナレにアップロードしていたピクシブ社内勉強会資料です。

Today we’re excited to announce the availability of TypeScript 4.7! If you’re not yet familiar with TypeScript, it’s a language that builds on JavaScript and adds syntax for types. Types help describe what kinds of values you’re working with and what kinds of functions you’re calling. TypeScript can use this information to help you avoid about mistakes like typos, missing arguments, or forgetting

ProductSupercharging GitHub Actions with Job SummariesYou can now output and group custom Markdown content on the Actions run summary page. The same familiar functionality that powers pull requests, issues, and README files has come to GitHub Actions! We’re thrilled to announce GitHub Actions Job Summaries, which allow for custom Markdown content on the run summary generated by each job. Custom Ma

４/18にスペースマーケット初主催となるエンジニア向けイベント「【増席】加速するシェアリングエコノミーの技術の裏側を公開！(React.js,RoR..)」 をジモティー鈴木さん、クラウドワークス大場さん、またパネルディカションの司会にTimeTicket/Instant Teamの山本大策さんをゲストに迎え開催しました！ 本編の詳細はブログの方に執筆したので割愛するとして、ここではその舞台裏を書いてみようかと思います。 開催したスペースは？まず今回会場となったのは中野Vスタジオさん。普段は主にお笑いライブ等のイベントが行われています。そこでエンジニア向け勉強会をやってしまおうというチャレンジングな試みです。本当に大丈夫なのか。。笑 地下１階に入り口があります。ライブハウスのような雰囲気。 スタッフ控室。やはりなかなかITの勉強会でこの雰囲気の会場にお目にかかることはないのでは笑 とりあえ

鐘の音（除夜の鐘）ダイエット-30kg @kanenooto7248 公教育って「1億人に知識を与えると、数%のひとがとんでもない有効活用を始める」という類のものであって、「最初から使う人だけに知識を与えようとしてもうまくいかない」んだよね。1千万人の将棋指しの中で、たまに藤井聡太が発生するけれど、最初から藤井聡太だけに将棋を教えることはできない。 2022-05-21 19:52:49 鐘の音（除夜の鐘）ダイエット-30kg @kanenooto7248 そんで「知らない人が増えるってことは知識への参加率を減らす」ってことなので、個人だけではなく社会全体がその分野について落ち込むことになる。なかなか厳しいな。 2022-05-21 20:02:07

質問あるメールの最後に「ご返信いただけましたら幸いです」のつもりで "I’d appreciate it if you could reply to me." と書いたら、それは上から目線な言い方になっているから "I look forward to your reply." の方が良いと指摘を受けました。 "I'd appreciate it if you could..."というのは丁寧な依頼の言い方と習いましたし、"I look forward to your reply."の方が直接的で上からのような気がするのですが、これはどういうことなのでしょうか？ ガリレオ流・回答2文を比較してみないことには、ガリレオにとっても盲点となるような質問事項でしたが、考えてみれば「確かに！」と思える指摘であり、言語文化論としても重要な問題に繋がるものです。 まず、アングロ・サクソン文化（歴史的に見て

On Sunday March 6, we migrated Stripe’s largest JavaScript codebase (powering the Stripe Dashboard) from Flow to TypeScript. In a single pull request, we converted more than 3.7 million lines of code. The next day, hundreds of engineers came in to start writing TypeScript for their projects. Seriously unreal. I remember a short time ago laughing at the idea of typescript ever landing at Stripe, an

ゲンゾウ用ポストイット シェル / Bash / Linux / Kubernetes / Docker / Git / クラウドのtipsを発信。 はじめにtr コマンドは、「文字」を別の「文字」に置き換えるコマンドです。 同じようなコマンドとして、 sed コマンドの y 内部コマンドがあります。 両方のコマンドの挙動を紹介します。 検証環境$ uname -moi x86_64 x86_64 GNU/Linux $ head -n 2 /etc/os-release NAME="Ubuntu" VERSION="21.04 (Hirsute Hippo)" $ bash -version | head -n 1 GNU bash, バージョン 5.1.4(1)-release (x86_64-pc-linux-gnu)tr コマンドtr コマンドを使って、 "my name is t

年収800万円を超える「ハイパフォーマー」がポッキリ折れる背景 先程示した調査結果では、前兆なく休職するリスクの高い人を「隠れストレス負債者」と分類しています。調査によると、隠れストレス負債者の約63％が年収800万円以上のビジネスパーソンであることもわかりました。こうした「ハイパフォーマーのストレス」をどう考えたらいいでしょうか。 日本でうつになりやすい性格傾向としてよく指摘される「メランコリー親和型」の人たちです。簡単に言うと、規範意識と責任感が強い、いわゆる真面目な優等生タイプの方です。もともとドイツの精神科医が提唱したもので、本来はもう少し神経質なニュアンスが強い言葉なのですが、生真面目な日本人の気質や精神性にフィットしたのか、広く受け入れられています。 そうした「“日本的な”メランコリー親和型性格」の方によく見られる傾向として、自分の都合よりも周りを優先して、環境からの要求や他者

2022.05.21 Scrum Fest Niigata 2022 Main Hall 10:00-10:45 Proposal https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16425

wearefractal/vinyl-fs の dest(folder, [opt]) が出力先のディレクトリが無い場合でも、そのディレクトリを作ってくれないということで、自分で「ディレクトリの有無を確認して、無い場合はディレクトリを作る」という処理を作る必要がでてきました。 そこで File System Node.js v4.1.0 Manual & Documentation を見て、ディレクトリの有無を確認するのに使えそうな fs.exists() という API を見つけたのですが、「Deprecated: Use fs.stat or fs.access instead.」ということで、他の API を使うように書かれていました。 「ファイルの有無を確認する API が deprecated になるのはなぜ？」と思い、これは何かあると思って少し調べてみたのでまとめておこうと思い

職歴が多いと転職時に不利になるのではないかと心配する人や、その悩みに応える記事などはよく目にします。では逆に「今まで一度も転職経験がない」「1つの職場に長く勤めている」場合はどうでしょう。 人材派遣の営業職として10年ほど働いた筆者は、「長年勤務した会社からの初転職に不安を抱く人」も見てきました。心のどこかで「新しいチャレンジをしたい」と思いつつ、転職経験なしの経歴がマイナスに評価されるのを危惧して、最初の一歩を踏み出せないケースです。実際に企業側が「1社だけに長くいた人は柔軟性に欠けるのでは」と採用をためらうケースもあります。 しかし、「転職経験がないこと」は強みにもなり得ます。今回は応募する個人と採用する企業の両方の視点から、「初転職を強みにする・生かすポイント」を見ていきましょう。