ミック @copinemickmack 米国人にタスク見積もりさせるとメールの確認みたいな日本人なら入れない細かいタスクをビッチリ入れてくるので、それはいちいち計上しなくていいのでは？ と指摘したら「情報共有のコストがタダだと思うな」という返事だった。日本人すぐ色んな人に共有メールとか送りたがるんで、教訓的だなと思った 2024-05-12 07:47:12 ミック @copinemickmack DBエンジニア改めアソシエイト・シリコンバレー出羽守。note.com/mickmack 著書：『SQL実践入門』『DB設計徹底指南書』『SQL徹底指南書』。訳書：J.セルコ『プログラマのためのSQL 第4版』。 mickindex.sakura.ne.jp

Amazon Web Services ブログ 【開催報告 & 資料公開】AWS 春の Observability 祭り 2024 こんにちは。ソリューションアーキテクト (以下 SA) の高野です。 2024 年 4 月 25 日に「AWS 春の Observability 祭り 2024 〜Observability 獲得までの旅〜」と題したイベントを開催しました。昨年秋に実施させていただいた AWS 秋のObservability 祭り以来の Observability をテーマにしたイベントになります。ご参加いただきました皆様には、改めて御礼申し上げます。昨年の開催報告ブログはこちら。 本ブログでは、その内容を簡単にご紹介しつつ、発表資料を公開致します。今回は、Observability の獲得プロセスをテーマに様々なセッションを行いました。Observability 獲得の全体像

日本のIT（情報技術）エンジニア人材が逼迫し大きな問題となるなか、IT業界は賃上げのニュースに沸いている。日経クロステックが複数のシステムインテグレーター（SIer）に2024年春の賃上げ状況を聞き取ったところ、妥結済みまたは交渉中の賃上げ率（総額）は、5%を超えている。改善の兆しは明白だ。だが、本当にITエンジニアは、自身が生む価値に見合う給与を手にしているのだろうか。安月給に甘んじ、実は「

All-in-one markdown editor, collaborative canvas, and diagram-as-code builder

a keynote at DavOpsDays Tokyo 2024 https://www.devopsdaystokyo.org/

はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、

コロナ禍をきっかけにリモートワークが推奨され、同時にペーパーレス化や各種デジタル化も進んだ。 いままで遅々として進まなかったデジタル化が一気に広まり、「やればできるじゃん」と多くの人がSNSにポストしていた記憶がある。 巷ではすっかり、アナログ＝非効率で減らすべきもの、デジタル＝効率的で推し進めるべきもの、という認識になっているようだ。 ただわたしは、「効率化のためにデジタルを導入すべき」という主張には、まったく共感できない。 なぜなら、デジタル化したせいで余計な作業が増えている場面が、たくさんあるからだ。 デジタル化を受け入れる人と反対する人の溝 先日、マダムユキさんによる『非効率大好き「現金主義者」に明日はない』という記事が公開された。 記事は、とある商店街の組合で、いままで集金だったものを振込に変更した話からはじまる。以下は、振込になったことを喜ぶヘアサロンのオーナーの言葉の引用だ。

TL;DR TiDBにおけるパフォーマンス検証をどうやって行ったか パフォーマンス検証を行ったときにつまづいた問題とその対応策 TiDBの仕様やアーキテクチャなどの話はありません 前提 対象のDBはAmazon Auroraで稼働中 DBエンジンはMySQL TiDBに移行できないかPoCを実施 DB周りにいろんな課題があり、TiDBで解決できないか検証 TiDB Cloudで検証 本番運用を想定してTiDB Dedicatedを利用 先にお伝えしたいこと TiDB導入したいとか言う前に、今使っているRDBで発生しているスロークエリとかIndex設計を見直した方が良いです笑 理由はこの記事を見てもらえるとわかると思いますｗ パフォーマンス検証の進め方 1. パフォーマンス検証に利用するクエリを洗い出す 観点としては以下の2つ 実行される頻度が高いSQL 実行速度が遅いSQL（スロークエリ）

構造化ログのプラクティスをあちこちで調べていたら、logfmtを推奨する記事を見つけたので調べてみました。 先に結論を言うと、JSON linesを使っておくのが良さそうです。 logfmt について logfmtとはスペース区切りで key=value を並べたフォーマットです。文字列にはクォートとエスケープによってスペースや改行を含められます。 at=info method=GET path=/ host=mutelight.org fwd="124.133.52.161" dyno=web.2 connect=4ms service=8ms status=200 bytes=1653 (logfmt から引用) あちこちで logfmt のリファレンスとして紹介されているのはこの記事です。 https://brandur.org/logfmt 発明されたのはどこか分かりませんが、流行

Transformer 深層学習モデル以前の言語モデルの課題 言語モデルでやりたいことは、「今まで生成した単語列を元に、次の単語を予測する」ことで、その単語は今まで生成した単語列を条件とし、次にある単語がくる条件付き確率を求め、その確率が最大のものを選ぶということだった。（LLM資料p.8参照） ただ、これだと単語列が長くなったときや、類義語の処理に課題が生じてしまっていた。 ニューラル言語モデル しかし、計算したい条件付き確率をNNで推定することにより、対処できた。 Encoder-Decoder型のRNN（Recurrent Neural Network)が最も基本的なモデルにはなるが、これでは長文に対応できなかった。（勾配消失＆単語間の長距離依存性の把握が困難） RNNが勾配消失するのは、活性化関数のtanhが1未満の値を取るため、BPTT時に掛け算されるとだんだん値が小さくなってし

マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB/Developers Summit 2024 TiDB Sponsor Session

www.infoworld.com 『Insider's Guide to Cloud Computing』（asin:B0BYHX7LF6）の著書もあるクラウド分野のベテランである David Linthicum が、「企業のクラウド離れ」についての記事を書いている。 最新の調査で、英国の企業の25％が、クラウドベースのワークロードの半分以上をオンプレミスのインフラに戻しているそうな。IT リーダーにした質問への回答を見ると、その大多数がクラウドからオンプレに回帰するプロジェクトに関わったことがあるという。なぜか？ 理由には、セキュリティの問題やプロジェクトへの期待の高さが挙げられている。そして、クラウドが「期待に応えられなかった」という回答も多い。予想外のコスト、パフォーマンスの問題、互換性の問題、サービスのダウンタイムも挙げられている。 オンプレ回帰の一番の理由は、やはりコストの問題

2024/02/05にリリースされた AWS CloudFormation IaC generator (Infrastructure as Code generator) を使い、手で作った環境をCloudFormationまたはCDKで管理するためのファーストステップガイドです。操作イメージのスクリーンショットも付いています。 まず操作感をイメージしていただくための資料であって、諸条件を網羅したものではありませんのでご注意ください。 詳細は以下のサイトもご覧ください。 AWS CloudFormation にアプリケーション全体をインポート https://aws.amazon.com/jp/blogs/news/import-entire-applications-into-aws-cloudformation/ Announcing CDK Migrate: A single co

20230712に実施されたシステム管理者感謝の会/システム管理者アワード特別講演で使用した資料です。前半はGPT全般の話や展望、後半はGPTシステムを作る上で注意する管理面の内容について触れています。 更に詳しく知りたい方はこちらも参照してください。 https://speakerdeck.com/hirosatogamo/0421dsxie-hui-chatgptniyotutemiao-kareruwei-lai-toaikai-fa-nobian-qian

Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌‍‌​‌‍​‌‌‌​‌‍‌‍​‌‍‌‌​​‍‍‌‍​‌‍‌‍‌​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍‌‍‍​‌‌​‌‌​‌​​‌​​‍‍​‍​‍‌‍‍​‌‍​‌‌​‌‍‍​‌‍‍‌‌‍​‌‍‌​‍‌​​​‍‍‌‍​‌‌‍‌​‌‍‌‌‍‍‌‌‍‍​‍‍‌‍‌​‌‍​‌‌‌​‌‍‌‍​‌‍‌‌​​‍‍‌‍​‌‍‌‍‌​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​‌

はじめまして。Gaudiyでエンジニアをしているあんどう（@Andoobomber）です。 クラウドネイティブ全盛の世の波に乗り、この度 Gaudiy では Cloud Run から Google Kubernetes Engine (GKE) への移行を行いました。 この記事では、その移行プロセスの全体像を共有し、得られた教訓と今後の展望を探ってみたいと思います。 1. Before After: 移行の概観 1-1. Before 1-2. After 2. なぜGKE環境に移行したのか 3. 移行のプロセス 3-1. Kubernetesを学ぶ (1週間: 2023/10/01~) 3-2. Dev on GKE環境作成 (2-3週間) 3-3. Staging on GKE環境作成 (2日) 3-4. Private Clusterへの移行 (1-2週間) 3-5. Prod on

コンサルタントをやっていた時、「できない理由」を並べ立てる人々に数多く出会った。 彼らの習性として「新しい何か」には、ほぼ「忙しい」と反対する。 また、リスクばかりを強調し、その打開策は探そうとしない。 例えば、こんな具合だ。 企画「今年の方針発表にもあった通り、お客さんにサービスの満足度についてヒアリングをしたいのですが。」 営業「いや、今すぐは忙しくて無理ですよ」 企画「社長からは「すぐに」と言う話だったと思いますが……、なぜですか？」 営業「ただでさえ目標がキツイので。目標達成に影響が出ます。」 企画「そうですか。では、我々が動くので。営業の方は何もしなくていいですよ。」 営業「いや、それも困ります。」 企画「なぜですか？」 営業「お客さんを混乱させてしまうかもしれないからです。」 企画「具体的には？クレームが来る、という事でしょうか？」 営業「まあ、そうかもしれません。」 企画「か

rtakenaka @rtakenakatky 放射線治療医です。粘りと勢いのあるがん治療を心掛けています。せっかくなのでリンクからblogも読んでいっていただけると嬉しいです。 saturday-2530.jugem.jp rtakenaka @rtakenakatky これすごい。小学生の中学受験の問題で、気づけば秒で解ける問題だけど(60分12問の最後の1問)。灘の数学教師って、学生の方が賢いし教えるのが上手い訳でもないのに作問のセンスだけヤバい。将棋強い訳でもないし将棋教えるの上手い訳でもないけど詰将棋の問題作るのがやたらヤバい、みたいな感じ。 pic.twitter.com/eUi4s0Sh12 2024-01-27 00:19:54