はてなブックマーク

最近読んだ「入門 継続的デリバリー」がとても良かったので紹介しますね, というエントリーです. 入門継続的デリバリー良かったです. 「継続的デリバリー（Continuous Delivery）」とか「DevOps」ってどこから学ぶかわからんな！？ というのは割とあるあるだと思っています, そもそもめちゃくちゃ難しい話なので（ちゃんと学ぼうとすると）. そんな中, 「入門 継続的デリバリー」がよく説明できてて良かったので感想と関連する書籍を紹介できればと思っています. TL;DR 入門 継続的デリバリー 我々はなぜCDをするのか? 具体的なプラクティス 入門後に読むべき良著 Kubernetes CI/CDパイプラインの実装 継続的デリバリー チームトポロジー 結び - 我思うCDとDevOps TL;DR 「入門 継続的デリバリー」は継続的デリバリーの大切さと概念, 手法を現実にありそうな

プログラミングとプロダクト作りは楽しいよ, っていう「個人開発ネタ」の話です. スポーツ観戦, 具体的には野球のデータ分析DX（Digital transformation）*1を実現しました. 記事の前半はプロダクト企画とアーキテクチャ, 後半はDash（Python）を使ったマルチページ・データ・アプリケーション開発の話となります. TL;DR SpreadsheetとPythonのアプリケーションでいつでもメジャーリーガー（全選手）のパフォーマンスを好きな条件で可視化できるようにしたら野球が面白くなりました. https://example.com/batter/ohtani-shohei/2024-03-20/2024-04-28?cache=false みたいなURLを開くと, オオタニサンのパフォーマンス（現地時間2024/4/28までの数字） 以下の成績をいい感じにグラフ・可

ざっくり言うと「TerraformとGitHub ActionsでGoogle Cloudなマイクロサービスを丸っとDeployする」という話です. Infrastructure as Code（IaC）は個人開発（趣味開発）でもやっておけ 開発〜テスト〜デプロイまで一貫性を持たせるCI/CDを設計しよう 個人開発（もしくは小規模システム）でどこまでIaCとCI/CDを作り込むかはあなた次第 なお, それなりに長いブログです&専門用語やクラウドサービスの解説は必要最小限なのでそこはご了承ください. あらすじ 突然ですが, 皆さんはどのリポジトリパターンが好きですか? 「ポリレポ（Polyrepo）」パターン - マイクロサービスを構成するアプリケーションやインフラ資材を意味がある単位*1で分割してリポジトリ化する. 「モノレポ（Monorepo）」パターン - アプリケーションもインフラも

仕事はともかくとして, 個人として趣味エンジニアリングと野球データ分析の人です. このブログは先日（2024/3/8）に開催された「第22回 酒とゲームとインフラとGCP」の発表および質疑応答から生まれたエントリーとなります. speakerdeck.com 現地も大変盛り上がりましたし, スライドも殊の外に反響を頂いて*1驚いています. この場を借りてお礼申し上げます🙏 発表後, 現地ではいくつかの質疑応答や会話, ディスカッションがありましてその中で最も印象に残った件がこちら. 何故Terraformを書いたのですか?シェルスクリプトでも良いのではないでしょうか? そうですよね, 単に個人開発（趣味）で作っているものでTerraformとGitHub ActionsでのCI/CD（この件は後日別に発表&ブログ書きます）まで頑張らなくても, shellでサクッとgcloudコマンド叩い

元・野球エンジニア*1, 現・Google Cloud Partner Top Engineer 2024*2の人です. 相変わらず仕事も趣味もGoogle Cloudで何かをやっているのですが, この年末年始に以下の絵のようなシステムを作りました（正確には「元々あった別システムを作り直しました*3」）. この記事の全体像 Baseball Savantから取得*4した投打のデータ（トラッキングデータ）のCSVをBigQueryのテーブル（事前に定義済み）に突っ込むシステムなのですが, こちらを作る過程で, Cloud RunをPub/Subのメッセージをトリガーとしたイベント駆動で動かす アプリケーション（Goで実装）を純然たるWeb APIとして実装（Pub/Sub専用のアプリではない） 上記の構成をサービスアカウントなどの権限設定含めてTerraformでIaC（Infrastruc

Google Cloud Partner Top Engineer 2024を頂いた者です. 仕事はエンジニア系のコンサルとSRE, 趣味（と前職以前の仕事）で機械学習や生成AI*1をやっとります. この記事は当ブログの名物かつ人気シリーズである, 主に技術書を中心としたオススメ書籍（元々はPython本メイン）の紹介エントリーです. ※去年の記事はこちら. 本年のこのエントリーは, 2024年の推し本4冊 CloudおよびSREな4冊 いい感じな技術書2冊 この三本立て（+私の完全なる趣味チョイスで数冊）でご紹介できればと思います. というわけで, 本年のラインナップは以下の通りです. この記事の著者 2024年の推し技術書10冊 特に推したい4冊 クラウドストラテジー 世界一流エンジニアの思考法 仕事に役立つ新・必修科目「情報Ⅰ」 キャリアづくりの教科書 CloudおよびSREな4冊

界隈で話題になっている（と私は認識している）「世界一流エンジニアの思考法」を早速読んでめちゃくちゃ良かった, とにかく人に勧めたいぞ！ という現役エンジニア（私）による書籍の感想エントリーとなります. 話題の本めちゃ良かったです. このブログを書く数日前にkindleで買って読む→めちゃいいやん！→紙版も買う←今ここ ってぐらいすごく良かったです*1. 世界一流エンジニアの思考法 (文春e-book) 作者:牛尾 剛文藝春秋Amazon 何が良かったか一言で言うと, 「強いエンジニアの習慣がここまでいい感じに言語化されている！！！」 という所ですね, 割と余すところなく詰まっていると思いますし, 一つ一つのTipsは再現性もあると思います（真似できるかどうかは別として真似は可能*2）. そんな「世界一流エンジニアの思考法」の感想を手短に書きます, 気になる方はお付き合いください. TL;D

タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です（結論） スタッフエンジニア　マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ～変化を抱擁せよ

※このエントリーは「OpenAIをいい感じに使うバックエンドをFastAPIで実装したぜ！」というエントリーです（サンプルコードはこちら）, 「OpenAIで何かを作った・人工知能を産んだ」訳では無いのでそっち方面を期待している方はそっ閉じしたほうが良いかもしれません（Web API開発に興味ある人はそのまま読んで）. 趣味は野球観戦と見せかけて, 「休日にダラダラ野球見ながら趣味のコードを書く」のが最も好きな人です. 100敗待ったなしの贔屓チームがいきなり7連勝したり*1, 昨年まで扇風機状態だった贔屓チームのフィジカルモンスターが突然覚醒して4番ライトに定着*2したりと理解が追いつかない野球を見るのはこれぐらい（コード書きながらみる）ぐらいがちょうどいいと思ってます, だってプレーオフ行けるか怪しいですもの*3. 時は遡り2020年, 私はセイバーメトリクスといくつかの機械学習の知見

最初に言っておきます. このエントリーは「いい本を読んだついでに自分のキャリアを振り返ってオススメを残す」という長文ブログです. 適当に読み流してもいいですし, 心の琴線に触れる事があれば最後までお付き合い頂けると幸いです. さて, 4月の末と言えば, GWが近づいてくると共に色々考えることがあります. 例えば社会人23年目の私は今年, GWの予定（決まっていない場合に限る） 「こどもの日」にしてあげられること キャリアの振り返りと数年先のキャリアプラン検討 この3つについて真剣に考えています. 今年でいうとGW予定（1.）は90%程度計画済み, こどもの日（2.）は甥っ子に渡すお小遣いを検討...までは決まってるのですが, 最後の（3.）はというと, GW明けって転職とか将来キャリアを考える機会になりがちじゃん?そういえば自分のキャリア(ry ...という感じで, GWは（本人が意識する

仕事がずっとコンサルワークなので, 休日のプログラミングがめちゃくちゃ楽しみになっている人です. 最初にお礼をさせてください, Developers Summit 2023の発表, なんだか好評価（高評価）だったみたいです. #devsumi 開催報告によると、私のトークの満足度は全90セッション中11位でした🎉 フィードバックコメントも多数いただき、誠にありがとうございました！ 次回作にご期待ください（多分夏ぐらいになるだろう）https://t.co/68lYY2vj25— Shinichi Nakagawa / 中川 伸一 (@shinyorke) 2023年3月2日 練習やレビューに協力いただいた皆様, そして何よりも当日私のトークを聞いていただいた皆様, 誠にありがとうございました. さて, 当日の発表では「GoでRESTful APIを作って運用しましたよ」という話をしました

昨日（2/10）の話ですが, 2020年以来3年ぶりにデブサミに参加・登壇させていただきました（前回の登壇報告はこちら）. 数あるセッションの中から私のトークにお越し頂き, 誠にありがとうございました！ また, 発表練習の機会を頂き, フィードバック・応援を頂いた所属企業*1のチームメイトおよび #pyhack（Python mini Hack-a-thon）の皆様, そして企画から本番まで伴走して頂いたデブサミの運営・スタッフの方々にもこの場を借りて改めて御礼申し上げます🙏 登壇の備忘録を兼ねて, このエントリーでは以下のラインナップを元に, 発表の振り返りと今後の話なんぞ書きたいと思います. TL;DR 登壇した理由と背景 どういう話だったか 参加者へのお土産 結び TL;DR 技術力向上, キャリア形成そして自分の趣味という観点で今後も周りが「ドン引き」する程度にエンジニアリングを

現職のコンサルっぽい仕事・インフラアーキなエンジニアな仕事も大好きですが, やっぱデータを見ると興奮するぐらいにデータ好きな人です. startpython.connpass.com 本日（2023/1/19）, ありがたいご縁がありまして, 「機械学習エンジニアが目指すキャリアパスとその実話」というお話をさせていただきました. 参加者の方々, ご清聴ありがとうございました&参加されていない方も気になるポイントあればぜひ御覧ください. 1/19の #stapy で「機械学習エンジニアが目指すキャリアパスとその実話」なるトークをすることになりました, 自画自賛ですが思ったよりいい内容に仕上がった気がします, 機械学習とかデータサイエンティストとかのキャリアでお悩みの方に届くと嬉しいです, 来てねhttps://t.co/KHxAXYY5mr pic.twitter.com/eguUyEnfb

このブログおよび, 登壇・アウトプットはゴリッゴリのエンジニア, 本職はコンサル企業のマネージャーとしてクラウドエンジニアリングのコンサルをやっている者です*1. この記事は, 当ブログの名物である, Pythonのオススメ書籍（と関連する技術書）の紹介エントリーです！ ※去年の記事はこちら. 本年のエントリーでは「今最もいい感じなPython本」の紹介に加えて, キャリアごとに読むべき技術書（と学び方）の選び方 この年末に読んで欲しい技術書（Python本とそれ以外） 「エンジニアのキャリア形成的に期待値の考え方大事だよ」という話 この三本立てでご紹介できればと思います. というわけで, 本年のラインナップは以下の通りです. 要約すると キャリアレベルを考える オススメ技術書籍2023 ジュニア🔰 メンバー マネジメント ボード 結び - キャリアごとの期待値 【番外編】私の推し書籍2

ちょっと昔まではデータ基盤の管理人・アーキテクト, 現在は思いっきりクラウドアーキを扱うコンサルタントになったマンです. 私自身の経験・スキル・このブログに書いているコンテンツの関係で, 「データ基盤って何を使って作ればいいの?」的なHow（もしくはWhere）の相談. 「Googleのビッグクエリーってやつがいいと聞いたけど何ができるの?」的な個別のサービスに対するご相談. 「ぶっちゃけおいくらかかりますか💸」というHow much?な話. 有り難くもこのようなお話をよくお受けしています. が, （仕事以外の営みにおける）個人としては毎度同じ話をするのはまあまあ疲れるので, データ基盤にありがちな「何を使って作ればよいか？」という問いに対する処方箋 というテーマで, クラウド上でデータ基盤を構築する際のサービスの選び方 （データ基盤に限らず）クラウド料金の基本的な考え方 をGoogle

ドラフト会議前に一位指名を公言するのって何かのトレンドですか?って思ってる人です.*1 今年いや, 去年からずっと野球関連のリアルなトレンドは「何かしらのオオタニサン」で間違いないと思います. 打者として規定打席到達（わかる） ついでに2年連続30本塁打以上（まあわかる）*2 投手として15勝防御率2.33, キャリア初の規定投球回*3到達（ちょwww嘘やろwww） 一人の野球選手が（ガチで）二人分の成績（それもエースピッチャーと主軸打者を兼ねる）という驚きは改めて語るまでも無い話ではありますが, 投球回伸びてるし, （雰囲気的に）見ていて安心できる投球をしてるし何か変えてきたのでは！？ と思い, 改めて「投手・大谷翔平」のデータを見てみようと思いました&実際に試したのでどうぞご覧ください. なお, オオタニサンといえば二刀流, 打者の成績も気になるところですがこちらはシーズン中に可視化し

日本で言えば同じ学年のレジェンド, アルバート・プホルスが通算700号本塁打を打って驚いている人です. ここ最近, （休んでいる間のリハビリがてら*1）PyCon JP 2022の準備および, 来年以降のMLBを楽しく見るために野球データ基盤（ちなみにメジャーリーグです）を作っていたのですが, それがいい感じに完成しました. アプリとデータ基盤をどのように作ったのか どのような処理, どのようなユースケースで動かしているのか これらをどのようなアーキテクチャで実現したのか 以上の内容をこのエントリーに書き残したいと思います. なおこのエントリーは, PyCon JP 2022のトーク「Python使いのためのスポーツデータ解析のきほん - PySparkとメジャーリーグデータを添えて（2022/10/15 16:00-16:30）」の予告編でもあります. なので, 後日のトークをお楽しみに

【2022/8/13更新】打球位置のプロット例を追加しました（解説ブログのリンクを含む） プライベートの時間はウイニングポスト9*1で自家生産の馬を育てるか, 野球データと戦っている人です. 野球のデータは見れば見るほど面白いです, どれぐらい面白いかと言うと「10年見ても飽きない*2」それぐらい面白いです（個人の感想です）. それはさておき, 私はメジャーリーグのデータを使って調べ物をしたりなにかのテーマに取り組む時, 以下のデータセットを用いています.*3 Lahman’s Baseball Database. 年度別のチーム・選手成績など, ある程度まとまった単位のデータ. GitHubから取得可能（https://github.com/chadwickbureau/baseballdatabank）. Retrosheet. 試合・打席ごとの成績データ. GitHubから取得可能（

今日のテーマ ※【2022/8/4更新】正式版がGAとなりました, ブログ記載の内容と異なる所がある可能性があるのでご注意ください&本番などで使っても大丈夫です！&別のブログも書いたのでその話も追加 仕事もプライベートもよくGoogle Cloud（GCP）を使っている人です. 最近はGoogle Cloudの資格取得, 頑張ってます*1. ちょっとしたSlack Botを作りたい ちょっとしたデータ収集クローラー（Webクローラー&スクレイピング）がほしい ちょっとした「CSVとかJSONのファイルをBigQueryに放り込む）簡単なETLがほしい なんて時に, Cloud FunctionsというGoogle Cloudのサーバレスな従量課金FaaS（Function as a Service）でシュッと関数作って運用しているのですが, つい最近そんなCloud Functionsの第

日米ともに突然の加藤球投高打低時代が戻ってきて今年の野球面白すぎでは?と思ってるマンです.*1 野球をテーマにした趣味プロジェクト・個人開発を始めてから実は10年が経とうとしているのですが, つい先日「これは最高傑作なのでは！？」っていうネタが完成し, Baseball Play Study mini（BPStudy）および, datatech-jp Casual Talks #2でお披露目させていただきました. BigQueryとPythonではじめるプロ野球選手の成績予測（もしくは成績占い） / Baseball Player Performance Prediction using BigQuery and Python - Speaker Deck どちらも反応は上々で（ちなみにdatatech-jpの方は短縮版で資料は公開していません*2）, 非常にポジティブな感想および, 私に

個人開発（趣味プロジェクト）でプロダクトを作りながら, 本職の仕事でソリューションアーキテクトっぽいことをしているマンです*1. 最近は個人開発のネタとして, プロ野球選手の成績予測プロジェクト ヘルスケア周りの自分専用プロダクト開発 この2本軸で週末エンジニアリングをしているのですが, これらの事をしているうちに, Webアプリケーション + 分析用のデータ基盤の最小セット, みたいなパターンが見えてきた クラウドにおけるサービスの選び方・スケール（=拡張）するときに気をつけるべき勘所 みたいなのがまとまってきました. せっかくなので, 言語化した上で再現性をもたせよう！という主旨でこのエントリーを書きたいと思います. なお, これだけは強く言っておきます. 参考にするのは自由です&真似ができるようなプラクティスではありますが, ベストプラクティスかどうかは（この記事を読んだ皆様の）状況

なんやかんやで, ITコンサルタント（復帰）生活から半年経ったマンです. マネジメントからアーキテクチャ, はたまた技術的なLTまでやらせてもらえて楽しく過ごしております*1. 昨年の話になりますが, コミュニティーやその他の活動で色々とお世話になってる @yuzutas0さん達が執筆しました, 「実践的データ基盤への処方箋」を頂戴いたしました. 実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ 作者:ゆずたそ,渡部 徹太郎,伊藤 徹郎技術評論社Amazon ひと言で言うと, データ活用のためにこういう本が欲しかったんや！！！ というくらい良著で, データ活用に必要な「人・組織・アーキテクチャ」をいい感じに網羅的に扱っていて良きでした（と, 読み終えた時の感想ツイートがそう言ってました）. データを扱う人すべてにおすすめしたい一冊です 読み終えた後も,

メジャーリーグの労使協定が決着ついて、「ああ、やっと球春だな⚾」って思ったマンです*1. なお, このエントリーは野球の話題では有りません. それはさておき, 私は毎朝毎夕に「血圧」「脈拍」「体重」「飲酒量」といったメトリクスを健康維持のために記録・振り返りをしているのですが, これをいい感じにするための個人的なSaaSを（本来の目的 + 技術的な検証・キャッチアップそして趣味として）作っています. 今作ってるもの（すでに運用している） Firebase上のフロントエンド（ちなみにNext.jsで作ってます）とApp Engine上のバックエンド（ちなみにFast APIで作ってます）を軸に, Google アカウント（Gmail）でのシングルサインオン（≒めっちゃ狭義な意味でのゼロトラスト認証）を実現するためにFirebase Authenticationを認証プロバイダとして使用 主に

気がつけば仕事も趣味も「クラウドなインフラで何かやる人*1」になったマンです. 個人的なプロダクト開発・運用やデータサイエンスな作業はGoogle Cloudメインでやってる私*2ですが, （そんな事情もあって）そういえばAWSのサーバレスなサービスにあまり触れてないな🤔と思い, ちょっと試しに触ってみました*3. aws.amazon.com Google CloudのApp EngineおよびCloud Runと比較されることが多いApp Runnerを試してみたのでその結果をメモとして残したいと思います. なお, 「AWSとGoogle Cloudどっちがいい?」という話ではないのでその前提でお読みください（好きな方・目的に合う方を使うのがいいですよ！） 対象読者 Webアプリケーションを作る人かつ, PythonのFlaskやDjangoあたりでWebアプリ開発をしたことがある（

心身のコンディション維持と体調管理のため, 毎日運動と血圧・体重・脈拍の計測をしているマンです*1. 新たな個人開発かつ, 趣味と実益（&学習）を兼ねて, プロダクトオーナーやりたい宣言したので, 個人開発としてプロダクト作りたい ネタどうしようかな...そうだ！ 毎日運動と血圧・体重・脈拍の計測 に役立つ何かを作るぞ！ 自分でSaaSを開発する練習もしたいので, スタートアップがやりそうなアーキテクチャでちゃんと作ろう と, 昨年末に思いつき「自分専用のヘルスケア領域SaaS」としてモノを作っているのですが, データの入力元となるフロントエンドと, 記録したデータの可視化&リコメンドに注力したい ↑の理由で, バックエンドの開発は正直な話思いっきり手を抜きたい 一番面倒くさいと言っても過言ではない認証機能（ユーザー管理）を開発ゼロでやりたい！！！ ...と思いつき, 知識と余暇の時間を総