ここ3年ほど仕事でやっていること - wyukawa's diary
僕は2018年から仕事で技術的にあまり新しいことには取り組んでなくて、新技術にもあまり興味が持てなくなってきてて、もしかしたら軽いミドルエイジクライシス的なものかもなあと思ってますが、2020年からマネジメントっぽいことをやってるのでそれについて書いてみたいと思います。 2018年からエンジニアリングマネージャーを1年ほどやり、その後組織改変があってマネージャーから外れて、2021年から再度マネージャーをやっとりますが、まあそんな大層なことはしてなくてそれよりもどちらかというと今僕がやっているのはTechnical Program Manager (TPM) に近いような気がしますが、項目を分けて書いてみます。 ピープルマネジメント 僕の理解ではエンジニアリングマネージャーと他のプロダクトマネージャー、プロジェクトマネージャー、Tech Lead、Individual Contributo
Workflow Engines Meetup #1でAzkabanの発表をしてきました。 - wyukawa's diary
Workflow Engines Meetup #1 - connpass 関係者の皆様おつかれさまでした。ありがとうございました。 スライドはこちら Azkaban from wyukawa Azkabanの紹介とうちのログ解析基盤でのユースケースを話しました。 Azkabanの開発がもっと活発になってほしいなあという話をしたら、oza_x86さんに「開発を活発にするには、今まで実行したジョブの数をMLに送るといい。開発者がテンション上げてくれる可能性がある」と言われたのでMLに投げときました。 https://groups.google.com/forum/?fromgroups#!topic/azkaban-dev/-LRHvS_GjQw
英語の勉強を始めて2年経った - wyukawa's diary
会社で英語の補助が出ると聞いて英語の勉強を始めてから2年経ったので振り返っておく。 2015/3から始めたのでちょうど2年です。 どれぐらい上達したかを言うのに、以前は英語を聞くと冷や汗がでたけど今はなんとか大丈夫みたいな定性的な評価だとよくわからんと思うので、定量的な数字で言うとTOEICの点数は555 から695になりVersantは32から43になりました。2年やってその程度かよってのはありますが、まあ事実なのでしょうがない。 海外発表の機会もあってロンドンとベルリンに行って発表してきました。 Prometheus London meetupでLTしてきました。 - wyukawa’s blog PromCon 2016に行って発表してきました。 - wyukawa’s blog 英語プレゼンは事前準備ができるので、できたからといって全くすごくないです。 質疑応答も自分が喋った内容に
OSSプロダクトとのつきあい方 - wyukawa's diary
僕は様々なOSSプロダクトを使ってシステムを構築しているけれど、自分なりにぼんやりと考えているOSSプロダクトとのつきあい方について書いてみる。 どのようなシステムを作るにせよ、それが一定以上の規模になるのであればOSSプロダクトを使わずに全部自前で実装するのはもはや現実的ではないです。例えばDBが必要だからってDB実装しますか？ ただこれがHTTPクライアントライブラリぐらいになるとちょっと微妙になってきて既存のライブラリが使いにくいから自作するってケースはもしかしたらあるかもしれないです。僕はそんなスキルないので自作しないですけどね。ただ既存ライブラリをラップして使いやすいAPIを提供するとかならあるかも。 商用製品だったり内製プロダクトだとぐぐれないし、ドキュメントとかソースが無くて情報共有しづらいことが多いし、またそれを使って学んで他に役立つか微妙なのでエンジニアのモチベーションも
商用と内製とOSSと自作のメリット、デメリット - wyukawa's diary
使用するソフトウェアを選択するときに、商用製品（例：Oracle）を使うのか、自分じゃない人が作った内製ソフト（例：SIerの内製フレームワーク、Web系の独自サーバー管理ツール）を使うのか、世に出回っているOSSソフト（例：Hadoop, Spring, Presto）を使うのか、それとも自分で自作するかという主に四択になります。 この辺はどのレイヤーのソフトなのかでも話が違ってきて、ビジネスロジックがからむものだったら当然自作なわけです。ビジネスロジックがからまないある程度汎用性のあるものが商用製品なりOSSソフトなりの形で出てくる訳でそれをどう取捨選択するかという話です。 商用製品のメリットは機能の多さだと思います。あとはサポートかな。デメリットは有償であることと、マニュアルが膨大にある割にはどこに何が書いてあるか分かりにくかったり、なにか操作してエラーが出た時のエラーメッセージが「
疎結合っていいよね - wyukawa's diary
今までの経験でいろんなレイヤーで依存性べったりで密結合なシステムを見てきてそれをちょっとだけ改善してきて思うところを書いてみる。 小さなシステムであれば多少は密結合でも何とかなるかもしれない、というか扱うファイル数、Gitプロジェクト数が1つでむしろやりやすいかもしれないけどシステムが大きくなるにだんだん拡張しにくくなる。かといって最初からあまりにも小さなシステムに分割するとそれはそれでやりづらい。完璧な答えは無いけれど僕が見てきたシステムの話をしよう。 その前にまず依存性といってもいろんなレイヤーがあると思うので、ここでは以下の３つの話をしよう。 アプリケーション内のコンポーネント間の依存性 システム間の依存性 バッチ内の各ジョブ間の依存性 1番目のアプリケーション内のコンポーネント間の依存性の例をあげるとMVCである。 SpringでWebアプリケーションを組んだ場合にModelがあっ
大量データを扱う際に気にするといい（かもしれない）チェックポイント - wyukawa's diary
いままで教えてもらったことを忘れないうちに軽くメモっておく。MB単位のデータだったら気にする必要はそんなに無いと思うけどGB以上になってくるといろいろ考えること増えるのよね。 シングルスレッドで処理するのではなくマルチスレッドでの処理を検討する。 シングルプロセスで処理するのではなくマルチプロセスでの処理を検討する。例：fluentdの複数実行 - wyukawa’s blog シングルプロセスで処理するのではなくMapReduceでの処理を検討する。 ただしMapReduceの処理で状態を持つとOutOfMemoryになる危険性があるので必要に応じてflushすることを検討する。例：入力データの性質によってはOutOfMemoryになってしまうHBaseへのデータ投入用のReduceタスクをどうすべきか？ - wyukawa’s blog ひとつひとつ処理するのではなくまとめて処理するこ
EclipseでWebアプリを作っていて別プロジェクトを参照している場合の注意点 - wyukawa's diary
長いタイトルの割には伝わりづらいw ええと、Webアプリsample-webを作っているんだけど、ユーティリティ関連は別プロジェクトとしてsample-commonに切り出している。 で、sample-webはsample-commonを参照しているという状況です。かなりありがちだと思います。DBアクセスも外だししてバッチとWebで共有したりするでしょう。 sample-common側のソースは下記で package common; public class Greet { public static String greet() { return "hello"; } } sample-web側はこんな感じ。 package hello; import java.io.IOException; import java.io.PrintWriter; import javax.servle
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
