たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に

人身事故が起きた全国130万件分の地点を日本地図に置き、あなたの近くに潜む危険な場所を可視化しました。各地の小さな交差点で交通事故が多発していることも明らかに。

みなさんこんにちは。@ryuzeeです。 2021年12月1日に発売した『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』ですが、おかげさまで多くの方に読んでいただき感謝しています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632 今日はこの「チームトポロジー」の元となったDevOpsトポロジーについて紹介します。 このアイデアは2013年に著者の1人であるマシュー・スケルトンが自身のブログに書いた記事をまとめたものです。 2013年頃といえばDevOpsが流行しはじめた時期だと思いますが、こ

2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が

こんにちは、ピリカの伊藤です。 先日、iOSアプリを審査に出したところ「iPadOSで起動時に通信エラーで進めない」とリジェクトされました。 これまでこのようなリジェクトを受けたことはなく、特にサーバーも問題なく動作していました。 では、なぜ審査落ちになったのでしょう。審査落ちのメッセージに添付されていたスクリーンショットを確認したところ、通信インジケーターが出ていませんでした。通常、ここにはWi-FiやCellularのアイコンが表示されているはずです。 一応この点について指摘してみましたが「このデバイスは正しくインターネットに接続している。詳しくは教えられない。」という回答があったのみでした。 iPhone/iPadに有線LANをつなぐ Wi-FiやCellularの表示がなくても接続できる状況ってあるか…？いや、そういえばEthernetがありました。 実はiOS 9.3以降で、Li

進行状況により時間は前後する可能性があります。 質問は適宜テキストで受け付け、発表後に返答させていただきます。 発表者 面谷 康平 (おもたに)「Kyashのマイクロサービスアーキテクチャ」 2020年2月入社。Kyashのサーバーサイドを広く触ってます。 どういう風にお金を使ったか見えるカテゴリー機能、複数人で口座をシェアできる共有口座機能、Kyash経由でECサイトでお買い物するとポイントが貰えるKyashリワード機能などを作ってきました！ Twitter: https://twitter.com/k_omotani Blog: https://komotani.hateblo.jp/ KyashのMicroservicesの全体像について話します。 Kyashのサーバーサイドのイケてるところ/これからイケてるようにするところを赤裸々に語っていきます！ ◯ 以下が気になる方にオススメ

Kyashの @konifar です。 2022年4月18日 (月) 19時から Kyash TechTalk #2 - Serversideのシステム構成とアーキテクチャ というMeetupをやります。 エンジニアチームで久しぶりにMeetupをやるのでしっかりめに告知します。 kyash.connpass.com なぜやるか 2022年3月に49億円の資金調達をして、これから事業がさらに加速していくことになります。その事業の成長を支えるために、エンジニアを求めています。正直に言うとめちゃくちゃ助けてほしいです。Kyashの事業やチームを知ってもらった上で、「助けてやるか」という人に来てもらいたいと考えています。 とはいえ「誰でもいいから来てほしい」という節操のない話ではありません。そもそもKyashのこれまでも現状もこれからもそんなに知らない人の方がほとんどでしょうから、まずはありのま

issueに対するエラー 数を集計 [ { … "permalink": "Sentryのエラー画面URL", "platform": "PHP", "metadata": { "value": "Fatal Error (0): Call to a member function result()....." }, … "stats": { "14d": [ [ 1541455200, // timestamp 473 // error count ], … ] }, … "title": "This is an example PHP exception" } ] • 14d制限でリクエスト • エラー内訳取得 • stats内のパラメータに日付事 のエラー数が格納 https://docs.sentry.io/api/events/list-a-projects-issues/

production code の設計についてはよく議論される一方、ユニットテストをどう書くべきかについてはあまり議論されることが少なく。とにかくカバレッジが高ければヨシみたいな感じで軽く扱われていることが多い気がする。 その結果、テストを書くときやとりわけテストを追加するときに "良くない" 方法でテストを追加/拡張してしまい、メンテナンスしにくく壊れやすい・(未来の自分でも)読んでも何を検証しているのか分からない、テストが落ちても不安だけを煽り何が問題なのか分からない、技術的負債が誕生してしまう。 詳しいことは本 ( XUnit Test Patterns など? 詳しい人は僕に紹介してください)を読んだりチームメンバーと議論するのが良いと思うが、この記事を読んでテストの書き方に対する意識を啓発できたらなと思っている。 理想を述べるのは簡単だけど現実は大変、頑張ろう introduct

JASRAC許諾第9009285055Y45038号 JASRAC許諾第9009285050Y45038号 JASRAC許諾第9009285049Y43128号 許諾番号 ID000002929 ABJマークは、この電子書店・電子書籍配信サービスが、著作権者からコンテンツ使用許諾を得た正規版配信サービスであることを示す登録商標(登録番号 第6091713号)です。