サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
satoshihirose.hateblo.jp
はじめに 特にエンジニアリングに必須ではない図書20冊 仕事編 さいごに はじめに 前回の続きで、リストアップしていた会社で働いていくなかで役に立ちそうな残りの20冊を紹介する。 satoshihirose.hateblo.jp 特にエンジニアリングに必須ではない図書20冊 仕事編 最高を超える 作者:フランク・スルートマンダイヤモンド社Amazon Snowflake、ServiceNowを率いてきたフランク・スルートマンのとても経営哲学本。プロ経営者としてIT業界の一線を走り続けてきた著者の哲学が経験を元に明快に説明されている。テック業界に居る人なら読んで損はない名著。 HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか 作者:ベン ホロウィッツ日経BPAmazon 著名VC、マーク・アンドリーセン・ホロウィッツのベン・ホロウィッツが過去の経験を赤裸々に語っていてその
こちら trocco® Advent Calendar 2023 のシリーズ2の11日目の記事です。 qiita.com データエンジニアからプロダクトマネージャーへのキャリアパス? 自分がそうだったという、かなりポジショントークと希望的観測込みの考えではあるが、データエンジニアからプロダクトマネージャーは割と有りなキャリアパスなんじゃないかという気が最近している。 データエンジニアとして満足していたりその専門性をまだまだ突き詰めて行きたいと思っている人はこんなことを考える余地はないかもしれないが、誰かのキャリア検討の一助になれば、とそう思う理由について言語化してみる。ちなみに、ここではSaaSとかインターネットサービスを提供している企業におけるプロダクトマネージャーを想定している。 理由1: データリテラシーが高く技術に強い データリテラシー、技術に強いことは、プロダクトマネジメントする
サマリー dbt-trino アダプターを使って dbt を TD で使えるか試したら動いた。 これで dbt のエコシステムを使っていろいろ出来そう 背景 以前 dbt の presto アダプターである dbt-presto を試したが、コードに修正をしないと動かないことが分かった。 satoshihirose.hateblo.jp その後は特に何もしてなかったが、久しぶりに dbt 周りのコードを眺めていたときに dbt-presto がアーカイブされていることを発見し、と同時にその代替の trino アダプターである dbt-trino だと動きそうなことが分かったので試してみた。 あーdbt-trinoはauto-commitしかサポートしないっぽくてtransactionの実装落としたっぽいからTDでも動きそうだな。Drop transaction queries by hov
はじめに 特にエンジニアリングに必須ではない図書20冊 Sci-Fi 投資・金融・経済 生活 まとめ はじめに ITエンジニア必読本10選、みたいな記事は定期的に生まれ、バズる。 みんな興味があり自分の体験や意見がそれぞれあるからかなと思う。現代ではIT技術職の仕事も多岐にわたるので全てのひとのお眼鏡に適うのは難しい。 先週はエンジニアリングの必須図書40冊という記事が盛り上がっていた。 zenn.dev 選書は個性が出るから面白い。また、その人と背景が似通っているほど刺さりやすい。 一方、日頃からアンテナを張っていないと、自分に合った良い本を知る機会はあまり無い。 ということで、自分と似た背景を持つ人(30代テック・スタートアップ業界関係者)向けにあまりエンジニアリングに関連しない書籍をおすすめする記事があっても良いなとふと思ったので、自分が過去に読んできた中で面白いと思った本を並べる。
はじめに 最近、ビジネスダッシュボードの設計・実装ガイドブックという書籍が出版された。今まであまりなかった視点から書かれたデータに関する本で面白く読んだ。 ビジネスダッシュボード 設計・実装ガイドブック 成果を生み出すデータと分析のデザイン 作者:トレジャーデータ,池田 俊介,藤井 温子,櫻井 将允,花岡 明翔泳社Amazon 作ったダッシュボードの利用が進まず、虚しさを覚えた経験がある人は多いと思う。どうしてそうなってしまうのか、自分の経験を元にまとめたいなと思ったのでまとめる。 なぜ使われないダッシュボードが作られるか なぜ作られたダッシュボードが使われないかと言うと、基本的にはそのダッシュボードがそんなに必要なものではないからだ(社内周知がうまくない、ツールの使い方がわからない人が多いなどの理由もあったりするがここでは無視する)。 必要のないダッシュボードが作られてしまう状況に関して
はじめに Steampipe とは何か dbt-steampipe を動かしてみる aws プラグインを使って aws のコストデータを取得する さいごに はじめに たまたま steampipe のサポートプラグインを見たら、結構充実していた。ちょっと調べたら dbt-steampipe プラグインも作られており、これを使ってクラウドサービス関連のデータ収集が dbt 上で管理できれば便利なんじゃないかと思ったので検証してみた。 Steampipe とは何か Steampipe はいろんなクラウドサービスの API をラップして SQL でデータ取得できるインターフェイスを用意してくれる OSS。SQL のインターフェイスは PostgreSQL を立てることで提供している。 Steampipe is the universal interface to APIs. Use SQL to
これはなに ここ3-4年、散発的にSF小説を読むにつれSF小説好きとしての自認が徐々に強くなってきた。そこで、大した冊数もない自分の既読本の中から、特に面白いと思ったものを挙げて自分の考えをまとめる。 このリストの中で一番古い作品は1949年の一九八四年で、一番新しい作品は2019年の息吹だ。基本的には SF は新しいものが良い。科学技術の発展とともに生活様式や社会が変わり、想像力の土台となる常識が更新されていくからだ。一方で、それと同時に普遍的なテーマを取り扱った SF は古びれない。70年以上前に書かれた一九八四年やファウンデーションは今読んでも傑作である。特に銀河を旅するような遠未来を描くハードSFは、舞台が現代社会から時空間共に離れているため普遍的なテーマを選ばざるを得ず、その傑作は30年後読んでも今と変わらず面白いだろう。自分がハードSFを好んで読む理由と今回のリストにハードSF
先週、Data Engineering Study という勉強会でざっくりとモダンデータスタックの話をした。 イベント参加登録者は400人超で最大同時接続数は180くらいだったそうな。 forkwell.connpass.com こちら第14回 #DataEngineeringStudy の発表資料です。Overview of The Modern Data Stack / モダンデータスタック概論 - Speaker Deck https://t.co/k4GK5QQcBq— 🐘 (@satoshihirose) June 7, 2022 感想 発表のために調査して自分も色々勉強になった。良い反響もいただけて、準備したかいがあったと感じられた。 本当は、プロダクトの紹介のみならず、実際の使用感や活用事例を含めて紹介できれば良かったのだが、そこまで調べ切ることはできなかった。 今回紹介し
背景 この前、Openness というカルチャーに関する記事を書いた。 Openness について - satoshihirose.log 組織のカルチャーについてこれまで思いを馳せることも多く、何となく考えを文章にしてすっきりしたくなったので記事にする。 組織のカルチャーとはどういうものか 自分が想定する「組織のカルチャー」ってのは、ざっくり「組織にとって好ましい振る舞いを規定することで生産性を向上させるためのもの」だ。人によってそうでない捉え方をする人もいるかもしれないが、ここでは無視する。 カルチャーは、その個別の内容に関わらず、メンバーに共通の価値観を与えることで共通のプロトコルを用意し、コミュニケーションをスムーズにするという効果がある。 組織内の多様性が求められる昨今においても、まあ人間が自分と似た人を好きになるのは避けられないので、ますますカルチャーを作って維持する重要性は大
"不必要なコミュニケーションを制限する" チームトポロジーを読んでいる。 一環して、逆コンウェイの法則に従うように、つまり理想のシステムアーキテクチャに沿うように組織設計をしようと主張する本である。 チャプター2 で、不必要なコミュニケーションを制限する という節がある。 コンウェイの法則の示す重要な点は、すべてのコミュニケーションとコラボレーションがよいとは限らないということだ。したがって「チームインターフェイス」を定義し、どんな仕事には強力なコラボレーションが必要で、どんな仕事には必要ないのかという期待値を設定することが重要になる。多くの組織はいつでもコミュニケーションは多いほうがよいと考えるが、実際にはそうではない。 必要とされるのは、特定のチーム間における集中的なコミュニケーションだ。予期せぬコミュニケーションを探し、その原因に取り組むことが必要なのだ。 ソフトウェアエンジニアとし
What's this? Customer Reliability Engineering の方法論について考えたことをまとめる。 CREing Google の提唱した CRE 職の新規性は、SRE の発想を自社プラットフォームのみならずその上で動く顧客アプリケーションにも適用したことにある。 基本的にはその発想に従えば良い。 SRE の方法論は、ざっくり言うと、SLA やエラーバジェットなるもので信頼性を定量的に定義しそれをモニタリングしながら改善可能性を探っていく、みたいなものだ。 それを顧客アプリケーションにも適用するのが CRE だと思えば良いだろう。 つまり、例えば現職の Treasure Data のプラットフォームには、それを取り巻く様々な顧客アプリケーションが存在する(Scheduled Query, Workflow, Source などなど)が、それらコンポーネントに
はじめに Modern Data Stack ? Modern Data Stack の特徴やメリット、関連するトレンド データインフラのクラウドサービス化 / Data infrastructure as a service データ連携サービスの発展 ELT! ELT! ELT! Reverse ETL テンプレート化された SQL and YAML などによるデータの管理 セマンティックレイヤーの凋落と Headless BI 計算フレームワーク (Computation Frameworks) 分析プロセスの民主化、データガバナンスとデータメッシュの試み プロダクト組み込み用データサービス リアルタイム Analytics Engineer の登場 各社ファウンダーが考える Modern Data Stack さいごに Further Readings はじめに Modern Dat
転職して一年経過した CREとしてTDに転職して、一年経過したので今の所感とどんなことやったのかをまとめる。 一人目ロールのCRE 前々職ではAWSインフラに詳しくなって、前職でデータ基盤の開発・運用をした。データ基盤の開発運用は基本的には保守的な活動である。次の職では、会社のKPI改善をより直接サポートできるような領域をやっていきたいと思い、これまでの知見を生かしてデータ基盤の上のレイヤーの活用領域を出来れば良いなと思っていた。TDで募集していたCRE職は、サポートチーム内の一人目ロールで自由度が高く、期待されることも希望に近かったためちょうど良かった。Pre IPOのグローバルSaaS企業の求人はそんなに多くはない。 とりあえずの基本方針として、ICであり特に指示できるメンバーもいないため、各チームのニーズを受けて自分の動ける範囲で手を動かし、まずは短期的に結果が出るタスクに注力した。
サマリー dbt が Treasure Data で動くか試してみた。 結果としては dbt-presto の修正が必要そうで現状のままでは動作しないことが確認できた。 果たして dbt-presto に Treasure Data に合うようなモードを追加するのが良いか、 dbt-athena のように別なプラグインとして提供するのが良いか。 dbt on Presto 以前の記事で少し触れたように dbt は Presto 用のプラグイン dbt-presto を用意しており、現時点では一部機能のみ使用することが可能である。 Due to the nature of Presto, not all core dbt functionality is supported. The following features of dbt are not implemented on Prest
はじめに リバース ETL という概念が提起されて、そのための SaaS も生まれており、面白いと思うので所感をまとめる。 Reverse ETL ? 自分が最初に Reverse ETL という言葉に触れたのは、Redpoint Ventures の Astasia Myers が 2021-02-23 に書いたこの記事だった。 Reverse ETL — A Primer. Data infrastructure has gone through an… | by Astasia Myers | Memory Leak | Medium 彼女はどんなものをリバース ETL と呼んでいるかというと Now teams are adopting yet another new approach, called “reverse ETL,” the process of moving dat
条件 現職で管理している現行のデータパイプラインである Treasure Workflow(managed digdag on TD)+ Presto に適用できること ウェブでメタデータのドキュメントが公開でき、社内に共有できること Data Lineage 的なデータの依存関係がわかること dbt dbt は構築したプロジェクトとその内部のクエリを元にドキュメントを自動で生成してくれる。データの依存関係のDAGを可視化してくれるようで、良さそう。dbt docs serve というドキュメントサイトをホストする機能も提供しているが、現時点では本番稼働を想定していないものらしい。その代わりに dbt Cloud を使う、生成したドキュメントを S3 でホストするなどの方法を推奨している。 The dbt docs serve command is only intended for lo
Customer Reliability Engineering とは 現在の自分は B2B SaaS の技術サポートを提供するチームの中で Customer Reliability Engineer (CRE)として働いている。 Customer Reliability Engineering は 2016 年に Google が提唱し始めた職務領域で、Google 社内で蓄積した Site Reliability Engineering のノウハウを Google Cloud ユーザーのアプリケーション(サイト)にも適用してコミットしていこうというアプローチだ。つまり、Google が提唱する CRE は Customer('s Site) Reliability Engineering のようなものと言える。 そのミッションは、 Drive Customer Anxiety -> 0
訳者まえがき 原著者の Robert Chang の許可を得て以下の記事を翻訳・公開しました。 medium.com 第一部の翻訳はこちら。 satoshihirose.hateblo.jp 以下から翻訳内容です。 データエンジニアリングビギナーズガイド 第二部 データモデリング、データパーティショニング、Airflow、ETLのベストプラクティス イメージクレジット:マドリード(CortesíadeIñaquiCarnicero Arquitectura)のHangar 16で改装された現代の倉庫 復習 データエンジニアリングビギナーズガイド 第一部では、組織の分析能力はレイヤー状に構築されることを説明しました。そして、生データの収集とデータウェアハウスの構築から機械学習の適用まで、これらの分野すべてでデータエンジニアリングが重要な役割を果たす理由を知りました。 データエンジニアの最も強
はじめに 自分は Martin Kleppmann が言うデータ指向アプリケーションやそれを実現する周辺の技術領域が好きで、業務としてそのような領域のエンジニアリングを引き続きやっていけたらなと思っています。 世の中には関連する職種の求人が多々ありますが、同じ名前のロールでも職務内容がコンテキストによって異なることが多かったりします。 ここではそれぞれの職種の違いについて自分の観点からまとめます。 1. データエンジニア 求人を眺めていると、データエンジニアは企業によって割と役割がぶれるので分けて説明します。 1-1. 小さめの事業会社のデータエンジニア まずは、小さめの事業会社のデータ分析基盤の構築・運用をするロールです。 ここでは ETL 処理の実装・運用のほかに、各種ツールを使ったデータ基盤の構築・運用知識やクラウド上のアプリケーション構築の知識などが求められることが多いです。 さら
訳者まえがき 原著者の Chris Riccomini の許可を得て以下の記事を翻訳・公開しました。 riccomini.name 下記より記事翻訳本文です。 データエンジニアリングの未来 私は最近、近頃のデータエンジニアリングがこれまで来た道について、また、この分野の仕事の将来について考えてきました。考えのほとんどは、私たちのチームが WePay で実践していることを背景にしています。その一方、以下に述べる考えは普遍的で、共有する価値があるものと思っています。 データエンジニアリングの仕事は、組織におけるデータの移動と処理を支援することです。これには、一般的に、データパイプラインとデータウェアハウスという2つの異なるシステムが必要です。データパイプラインはデータの移動を担当し、データウェアハウスはデータの処理を担当します。これは、やや過度に単純化しています。バッチ処理とストリーム処理では
What's this? 去年の8月に現職に就いた際に、組織目標をOKRで管理していることを知りました。 OKRについてのインターネット上の情報などを調べていくうちに、「シンプルかつ具体的で少数の重要な目標に絞る」「野心的な目標を挙げることで成果をストレッチさせる」などのコンセプトが気に入り、その詳細な思想や運用について興味が湧きました。 そこで、クリスティーナ・ウォドキー「OKR」とジョン・ドーア「Measure What Matters」の二冊を読んだので、学んだ点をまとめます。 OKRそのものの概要は以下の記事などを参照してください。 【保存版】Googleも採用する目標管理「OKR」を徹底解説!導入事例や運用ツールも紹介 | SELECK [セレック] OKR (目標と主な結果) – 前田ヒロ Google re:Work - ガイド: OKRを設定する OKRの本買って読み始めた
訳者まえがき 原著者の Robert Chang の許可を得て以下の記事を翻訳・公開しました。 medium.com 原著者は、Airbnb で Data Scientist をしています。 以下から翻訳内容です。 データエンジニアリングビギナーズガイド 第一部 データエンジニアリング: データサイエンスの似た従兄弟 イメージクレジット:IñaquiCarniceroが建築したマタデロマドリードの美しい元屠殺場/倉庫 記事を書いた動機 データサイエンティストとしての経験を経るほど、データエンジニアリングはデータサイエンティストのツールキットの中で最も重要かつ基礎的なスキルの1つであると確信しています。この考えは、プロジェクトや就職機会に対する評価、そして個人の職務領域の広がりの両方に当てはまります。 以前の記事では、データを価値のあるものに変換するデータサイエンティストの能力は、自社のデー
訳者まえがき 下記の翻訳記事と対になる、データエンジニアの役割についての記事を翻訳しました。 satoshihirose.hateblo.jp オリジナルの記事は下記のリンク先のもので、原著者は上記記事と同様に、Apache Airflow や Apache Superset のクリエーターで現在は Lyft で Data Engineer をしている Maxime Beauchemin です。 medium.com 以下から、翻訳記事の内容です。 データエンジニアの没落(翻訳) この記事では、データエンジニアリングを定義しようとした最近のブログ記事である「The Rise of the Data Engineer」(訳者注: 拙訳「データエンジニアの始まり」)をフォローアップし、この新しい役割がデータ空間において歴史的、現代的な役割にどのように関係しているかを説明します。 この記事では、
基本 まずはkumagi-sanのスライドを読む 分散システムについて語らせてくれ from Kumazaki Hiroki www.slideshare.net 合意アルゴリズムとアプリケーション 2PC (Two Phase Commit), 3PC (Three Phase Commit) アルゴリズムは単純 2PCはFail-Recovery発生時にバグる 2PCではCoordinatorからのリクエストにCohortが返答しない限りブロックが発生してしまうので、ノンブロッキングな3PCが考えられた 3PCでは時間制限を設け、タイムアウトが発生した場合に異なるフェーズに移行する Paxos, Raftなど分散合意プロトコルを概観する(1) - 備忘録 blog 余談: 翻訳: スターバックスは2フェーズコミットを使わない|Ouobpo Paxos Google Chubby Goo
訳者まえがき 原著者 Maxime Beauchemin の許可を得て以下の記事を翻訳・公開しました。 medium.freecodecamp.org 原著者は、Apache Airflow や Apache Superset のクリエーターで、現在は Lyft で Data Engineer をしています。 データエンジニアの始まり(翻訳) 私は 2011 年にBIエンジニアとしてFacebookに入社しました。2013年に退職するときには、私はデータエンジニアでした。 昇進もしくは新しい役割に就いたわけではありません。そうではなく、Facebookは、私たちが行っていた仕事が伝統的なBIを超えていたことに気づいたのです。私たち自身のために作り出した役割は、まったく新しい専門分野でした。 私のチームはこの変革の最前線にいました。私たちは新しいスキル、新しいやりかた、新しいツール開発し、そ
一年でビール何銘柄程度飲めるか 二年位前からビールが好きになったので、去年は100銘柄ビールを飲もうという目標を立てました。 年始は張り切って人を誘ってビアバー巡ってましたが、年の後半はお金も使いたくないので食事誘われたらビアバーを提案するくらいのペースに落としました。 ビールが好きだと言っているとお誘いやお土産の引き合いがあってそれはそれで楽しい一年でした。 以下の一覧では写し疲れたので100で辞めましたが、記録していない銘柄もあるのでだいたいユニーク銘柄数は120-130位でしょうか。 銘柄被りや居酒屋で飲む日本のラガーを合わせれば3倍くらい飲んでそうなので、一杯平均して350mlだとすると大体100Lくらい飲んだ計算になるでしょうか。 ちなみに東京人の平均ビール消費量は35L程度だそうです。 1人あたりのビールの消費量の都道府県ランキング - 都道府県格付研究所 美味しかったビール
ビルド(Java) ./gradlew gem ビルド(Ruby) rake build pkgの下にgemファイルができるので、 embulk gem install pkg/xxx.gem する。 @satoshihirose こんにちは、git cloneして、javaなら./gradlew gem ; rubyならrake buildです。pkgの下にgemファイルができるので、embulk gem install pkg/xxx.gemとすれば良いです。— hiroyuki sato (@hiroysato) April 22, 2016 @hiroysato @satoshihirose 手前味噌ですが、 https://t.co/9qDNGlNQ0O という方法もあります。— joker1007に宜しく (@joker1007) April 22, 2016
概要 ScalaMatsuri 2016に参加した感想です。 scalamatsuri.org DAY 1 Refactoring in Scala 僕のスライドこちらです。スクリーンが見づらい場合はお手元でご確認ください https://t.co/MtTi7m7DE5 #ScalaMatsuri #sm_a— がくぞ (@gakuzzzz) January 30, 2016 Tagged Type便利そう。 IsoやPrismの概念、関数型っぽい。 確かにLong型よりもUserId型(Value Type)を定義すると分かりやすかったりbugの埋め込みを減らせる気もするけれども、それが原因でDBとの境界に気を使ってコード量を増やしたりパフォーマンスに気を使ったする箇所を増やしたりするのトレードオフだなって感じだった。 なぜリアクティブは重要か 本日の資料です。毎度ながら詰め込み過ぎなの
次のページ
このページを最初にブックマークしてみませんか?
『satoshihirose.log』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く