オブザーバビリティの最前線 OpenTelemetryで下げる認知負荷~活用事例4選~ - Findy Tools
公開日 2024/05/29更新日 2024/05/29オブザーバビリティの最前線 OpenTelemetryで下げる認知負荷~活用事例4選~ 近年マイクロサービスアーキテクチャの普及やクラウドネイティブの普及が進み、システムの複雑性は増す一方です。システムの動作を正確に把握することはますます困難になっており、そのような状況の中で、オブザーバビリティはシステムを安定的に運用するために必要不可欠な要素になってきています。 そして、オブザーバビリティの重要性の認知が高まるにつれて、多くの企業でオブザーバビリティに関するツールの導入も進み始めています。 そのような潮流の中、オブザーバビリティ分野でさらなる大きな可能性を持つプロジェクトがOpenTelemetryになります。 本記事では、OpenTelemetryとは一体どんなものなのか、そして実際にOpenTelemetryの導入・活用に成功し
DataOpsとは何か #dataops - 下町柚子黄昏記 by @yuzutas0
本稿は、コンテンツの保存を目的として、2018年8月10日にR-Techブログに寄稿した記事を転記し、一部表現を修正したものです。 https://blog.recruit.co.jp/rtc/2018/08/10/developers_summit_summer2018/ 本稿の筆者は DataKitchen の記事でも紹介されており、事実上「日本におけるDataOpsの第一人者」だと自認しています。 https://medium.com/data-ops/dataops-goes-global-9d6e67dcaf30 本稿の内容は筆者の個人的な見解であり、当時の所属を代表するものではありません。 また、DataOpsという用語についてグローバルスタンダードの定義を説明したものでもありません。 本稿の内容を参考にして「DataOpsとは何か」を業務で説明する場合、一般論ではなく「この記
ClickHouse (クリックハウス) Meetup Tokyo, 2024年6月5日(水) 18:00 | Meetup
ClickHouseコミュニティミートアップを東京で開催することをお知らせいたします。ClickHouseの魅力に触れる貴重な機会をお見逃しなく！English Follows ClickHouseは、高性能な分析を実現するために設計された、オープンソースの高速カラム型データベース管理システムです。本イベントでは、ClickHouse APAC関係者との交流もお楽しみいただけます。 当日のアジェンダ： 18:00 - 18:30: 受付とネットワーキング 18:30 - 18:50: ClickHouse ソリューションアーキテクト, ジョニー ミルザ 「ClickHouseとは？」- 逐次通訳あり 18:50 - 18:55: アマゾン ウェブ サービス ジャパン合同会社 テクノロジーパートナー本部 本部長, 竹部智実「AWS Marketplaceによるデジタル調達」 18:55 -
結果的にスクラムになってる！なのがいいと思う！ #RSGT2017
Regional Scrum Gathering Tokyo 2017
意義から考えるObservability入門 #srenext
Road to SRE NEXT@福岡(ハイブリッド開催) でLTした時の資料です。
エアコンは６・10・14畳しか買ってはいけない!? 失敗しないエアコンの選び方｜jimosumu（ジモスム）
冷房だけでなく、暖房機器としての市民権をすっかり得たエアコンですが、正しく深い情報はほとんど知られていません。今後エアコンを買う際、ムダな出費と効かないというリスクを減らすために有用な情報を一級建築士でエコハウスのエキスパートの松尾和也さんに教えていただきました。※雑誌「だん09」から流用私は、約10年前から様々なところで「エアコンを畳数通りに買ってはいけない」と言い続けてきましたが、その根拠も含め、エアコン選びに必要な知識を正しく理解している人はほとんどいません。最終的には、最適なエアコンの機種を計算で導き出せるようになってほしいのですが、ここでは初級編として、失敗しない選び方の基本をお伝えします。 なぜ畳数で選んではダメなのか？ そもそも、「〇畳用」という表示は1964年にJIS規格で制定されました。その際の基準になったのが、無断熱の木造平屋建て（Ｑ値だと20くらい！）。驚くべきことに
Zodスキーマでプロンプト生成を行い構造化データを自由自在に扱えて、LLMプロダクト開発が圧倒的に効率化した話 - Algomatic Tech Blog
最近はAIエンジニアを名乗ってるerukitiです。フロントエンドもバックエンドも、LLMを触るあれこれもやってるので、「AIエンジニア」くらいを名乗るとちょうどよさそうだなと思ってます。いずれLLM自体の開発なんかもやってるかもしれません。 LLMプロダクトを開発していると、構造化データを作りたいのに、Anthropic ClaudeのAPIにはJSONモードが無いことや、なんならJSONモードやfunction callingを使っても、データが正しい形式に従ってることは保証しがたい、みたいな自体に遭遇することがあります。 JSONが出力できたとしても、構造化データをうまく吐き出させるのは難しいものです。文字列を出力させたいけど、複数あるときは、配列なのか、それともカンマ区切りなのか？項目がオプショナルの場合はどうするか？項目が存在しない、空文字や 0 や undefined や nu
Keeper of the Seven Keys 〜Four Keysとあと3つ〜
Mutation Testingを活用して テスト品質を考える /introduction to mutation testing
HBase Deprecation at Pinterest
Alberto Ordonez Pereira | Senior Staff Software Engineer; Lianghong Xu | Senior Manager, Engineering; This blog marks the first of a three-part series describing our journey at Pinterest transition from managing multiple online storage services supported by HBase to a brand new serving architecture with a new datastore and a unified storage service. In this introductory post, we will provide an ov
Statically Typed Functional Programming with Python 3.12
Lately I’ve been messing around with Python 3.12, discovering new features around typing and pattern matching. Combined with dataclasses, they provide support for a style of programming that I’ve employed in Kotlin and Typescript at work. That style in turn is based on what I’d do in OCaml or Haskell, like modelling data with algebraic data types. However, the more advanced concepts from Haskell —
2024-03-16 社員30人 → 300人のフェーズを経験し見えてきた、 エンジニアとして成長するための考え方
2024/03/16に開催された技育祭での登壇資料 https://talent.supporterz.jp/geeksai/2024spring/
「プロダクトエンジニア」という役割を定義しましたというお話 - hacomono TECH BLOG
こんにちは、hacomonoのプロダクト開発本部のたつ（X）です。 前回は「hacomonoの機能開発チームのたつです」と自己紹介したのですが、組織も大きくなりまして「部」なんて言葉を使うようになりました。 さて本日のお話は、2024年に入って「プロダクトエンジニア」という役割を社内で定義・言語化しましたのでそのお話をしたいと思います。 以前にもこじこじが「プロダクトエンジニア」について記事を書いてくれています。 本日はその第2弾としてhacomonoの「プロダクトエンジニア」の定義とその誕生の経緯についてお話したいと思います。 と言っても何も新しい役割を定義しましたという話ではなく、今までも社内で活躍してくれていた人の特徴を言語化・再定義したというお話です。 なぜ「プロダクトエンジニア」という言葉を定義したのか？ 理由は4つあります。 組織が大きくなるにつれて、プロダクト開発エンジニアの
40代からのキャリアを楽しむコツについて｜とくさん｜MYCOPING
経験の価値を再定義する重要性日本は世界一の高齢化社会なのに、40代以降は「キャリアの墓場」的なネガティヴな論調をいまだに見るし、それが世間のイメージになってるのは良くないなと感じる。 年金をもらえるのは65歳からなので、冷静に考えると、40代というのはまだ折返し地点を過ぎただけ。まだ最低20年はキャリアが続くわけで、新卒からの時間と同じくらいの長さが残っているというのは、なかなか迫力のある事実。 ということで、40代以降を「黄昏」的に捉えるのはもったいないなと感じる。実際のところ、日本も労働市場は流動化してきているし、培った専門性や経験が活かせる場面も多い。多様な生き方に「開いていく」機会は増えているので。 最近新たなバズワードになりつつある「中高年のリスキリング」の文脈でも、おじさんが慣れないデジタルツールの使い方を学ぶ、みたいなカルチャースクール的なものが多いのが気になるところ。それよ
Disagree and Commit
← all episodes Listen now “Consensus is cozy, but broad agreement is not our aim. The right decision is. Which is why we take the time to think, debate, persuade, listen and reconsider and then, someone, decides. If you disagree, that’s fine, but once the decision is made, it’s time to commit and support it completely.” Tune in as Kimberly leads a chat with Jason Fried and David Heinemeier Hansson
どちらが得？ 「ボーナスはあるが月給は低い」と「月給は高いがボーナスはない」
ここまでは、給与や賞与から控除されるものを比較してきました。ここからは、社会保険の給付の面でも比較してみます。社会保険にはさまざま給付がありますが、今回は、将来の年金額にどのような影響があるか試算してみます。 年金額の算出には厚生年金加入期間の給与と賞与を平均化した平均標準報酬が必要となります。加入期間は40年以上にもなり、その間には給与と賞与の金額が変動することが考えられますが、そのようなシミュレーションは難しいので、今回は40年間全く同じ、給与、賞与であったとして老齢厚生年金の報酬比例部分を試算しました。 結果としては、年収が少ないと賞与の有無によって年金額に差異は少なく、年収が高くなると賞与がある方が年金額が多くなりました。これは、年収の高い人が給与だけで受け取ると標準報酬月額が上限額となるので、実際の年収より平均標準報酬額が低くなることで発生する差異となります。 年収（万） 賞与月
Unleash Mercari Tech! vol.4 〜メルペイ立ち上げ当時に戻ったら？〜：メルカリ技術書典部
本書は「今の知識を持ったまま、メルペイ立ち上げ当時に戻るとしたらどうしてたか？」をテーマとして社内でインタビューを行い、それをまとめた部誌です。 技術選定の話やメルペイ立ち上げ当時の話など、それぞれがとても濃い内容となっているので、非常に読み応えのある本になっています。 ぜひ、楽しんで読んでもらえるとうれしいです！ - 目次 - 第1章 Payment Platform編 第2章 iOS / Android編 第3章 Engineering Manager編 第4章 Platform Engineering編 第5章 SRE編 第6章 Architect編 第7章 元メルペイCTO編 今回の表紙は猫ちゃんたちです。かわいいですね！
教育は静かに終わりを告げようとしている｜Jay＠副業する心臓の医者
最近話題のやりがい問題について、思うところがある。 猫山課長の裏note, 裏ラジオでも語られていた内容だ。 若手の方は絶対にこれらのコンテンツに触れた方が良い。 今の時代を勝ち抜くのに必要なエッセンスが凝縮されている。 僕は30代半ばで、猫山課長よりおそらく一世代若い。 僕らの世代はギリギリハードワークが許されたが、すぐ下の世代から働き方改革丸出しといった感じの世代である。 30半ばの「ようやく自立した若手」の立場から私見を述べたいと思う。 ＋＋＋＋＋＋＋＋＋＋ 最近は「ライフワークバランス」や「働き方改革」といったいわゆる労働に対するネガティブな動きが盛んだ。 今の新人にとってみればもはや上記の概念は常識になっている。 ただ、断言する。 正直、上司はうんざりしている。 自分たちの享受していない制度の、よくわからないプレッシャーに戸惑っていると言ってもよい。 僕らの業界でいえば「研修医」
Manage Your Manager
When I joined Facebook we didn’t have managers. When we are deep in the feedback period of the performance cycle we may imagine such a world as a utopia but I assure you we are wrong. I would have benefitted immensely from more management. That period of my career holds my greatest professional regrets. And when I finally was assigned a manager years later that person didn’t have any more experien
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Design Docs を活用して効果的にプロダクト改善
1on1ミーティングガイド (1on1ガイド)
