サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
masartz.hatenablog.jp
まえがき アップデートできてませんでしたが、約1年くらいTechnical Product Manager(以降 TPM)のRoleを担当しているので、その振り返りです。 ちなみに今回はRole変更エントリではなく、まだ引続きこのRoleを続ける予定です。 What is TPM JDが公開されているので、まずはこちらを御覧ください Why TPM きっかけは 「TPMの組織を作ろうと思うので来てくれませんか?」と現在 Smartnewwsで活躍する @tairoに誘われ、「TPMってどういう仕事ですか? というかPMとの違いは?」という俺の問に対して「まさに僕みたいな人のイメージです!」と説明されて、とてもすんなり合点がいき、それならばやってみたいと思ったのがきっかけです。 When,Where TPM いつからという意味では、冒頭にも書いた通り、現在で1年とちょっと経ったくらい。 どこ
2020年1月より2月末までの丸二ヶ月間、育児休暇を取得させていただきました。 この背景にはmerci boxと呼ばれる会社の手厚い福利厚生があることと、実際にそれを用いて育休を取得した先輩パパ達が数多くいたからであり、改めて感謝しています。 ということで、恩の還元の意図も込めて、(前回経過を少し書いていたけど)今回はそのまとめです。 想定読者と前提条件 これから育休を取る(あるいは検討している)方(で一応エンジニア)に向けて うちの環境がこうだった(他では違うこともある)前提条件としては、 生後3〜4ヶ月目のできごと(生後すぐは妻の実家に里帰りしていた) 一人目の子供(上の子がいるときっとまた状況は違う気がする) 母乳育児(後述しますが、ミルク育児とは夫のできる活動に差がある) TL;DR; やってみてどうだったか ちょうど同じ時に育休を取っていた小泉進次郎が言うように、育休は全然休暇じ
TL;DR; Engineering Managerを降りることになりましたので、振り返りとまとめです。 ※会社は辞めませんので、退職エントリではございません(別チームへの異動です) 時系列 2017/10頃: SREのチーム内において会社のReport Line上にはプロットされないリーダー的なポジションをやりはじめる この時はまだManagerではない。採用や評価に対するResponsibilityがないのがマネージャとリーダーの簡単な違い 2018/04: SREのEngineering Managerに登用される 当時 Microservices PlatformはReport Line上はまだSRE内に包含されていた気がする どこかのタイミングで Report Lineとしても独立して、2チームを兼任する形で引き続き担当していた 2018/10: 2チーム兼任からMicroser
チーム内Peer Reviewを導入した話です。と言うと、チーム外Peer Reviewがあるのか?という疑問が湧くと思うので、まずその前提から。 メルカリは四半期ごとの評価タイミングでPeer Reviewを全社で実施している。 各メンバーが任意の3人を指名する 指名されたメンバーはValue軸に則って、Reviewを書く 内容は本人及び上長に開示され、評価の参考情報として使われる 簡単に説明するとこんな感じ、割とよくある評価システムだ。まずは自分がイチ個人としてこのPeer Reviewをどのように扱っているかを説明する 打ち上げ花火、下から見るか?横から見るか? 任意3人の対象に基本的に制限はない。席が隣の人から、その気になれば社長を選択することも可能だ。 この時、Reviewで何を聞くか、ということにもなるが、自分の中では「影響力のベンチマーク」として使っている。 前職のVOYAG
この前の評価の時期に整理した内容。少し遅くなってしまったが書いてみた。 評価について、特にメルカリでは360度評価的に近いPeer Reviewも実施している。その際にもValueに基づいてFeedBackするのがベースになっており、Valueについて改めて考える機会と言える。 というわけで自分なりのValueの考え方を整理してみた。 3つのValue おさらいだけど、メルカリのValueは以下の3つ Go Bold(大胆にやろう) All for One(全ては成功のために) Be Professional(プロフェッショナルであれ) 実はこれ以上の説明はない。各Valueについて敢えて細かく具体的な整理をしないのは経営の意図したものだ。 各人が各Valueはどういうものなのか考え・議論し、体現していくことによって会社のアウトプットに繋がる。 というわけで自分なりに考えてみるが、自分の中
(English follows) 前置き この記事は Engineering Manager vol.2 Advent Calendar 2018 6日目の記事です。 メルカリで Engineering Manager をしている masartzです。 今日は、先日自身が体験したことから得た、1on1の学びについて書いてみようと思います。 1on1コーチングの研修 メルカリでは、急拡大する組織に対応するため、Managerなどの中間層の教育・育成も急務となっております。Managerとしては、HR部門のサポートもあり研修プログラム等も受講する機会が与えられます。 先日 「1on1コーチング」のための時間があり、外部のプロコーチの方を相手に「コーチングを受ける側」の立場から勉強しようという機会でした。 当日、会議室に着き、挨拶と自己紹介を済ませ、いよいよ本題です。 コーチ:「最近の課題はあ
なかなか珍しい ex-mixi(会社のOB/OG)によるAdvent Calendarの一発目をかます masartz です。 ミクシィは 2ホップ前の会社、現所属はメルカリになります。 どういうスタンスで書けば良いのかわかりませんが、各方面を考えてミクシィ時代から今に至るまで継続してることを述べていきたいと思います。 大規模であるが故の技術的な対策 mixiもメルカリも大規模と言って良いレベルのサービスで、そのための負荷対策はどのエンジニアにも求められるものです。 特にクラウドなインフラ環境が今ほど整っておらず、スケーリングに緻密な設計が求められたミクシィ時代に学んだ分散手法は今も活かされています。 ミクシィエンジニアなら、下記は L1分散作業 と表現すれば、その一言で伝わることでしょう。 tech.mercari.com こういった手法はサービス初期に用いられることは少ないでしょうし、
gihyo.jp この度、id:songmu さんにお話をいただいて、WEB+DB Press vol.96 の Perl Hackers Hubに「大規模広告配信でのCPANモジュール活用」と題して寄稿しました。 内容は今勤めている fluct社のSSPサービスfluct の配信サーバー周りについてです。 fluctのPerlは広告配信という、いわゆるMVCのフレームワークでWebサイトを作るのとは違った役割を持っていておもしろい面がありますが、 スマホのクライアントアプリを受けるAPIサーバーとかだと作りが参考になる部分もありそうですし、 広告ならではの設計もあります。案件情報を取得する部分は(Perl要素薄いですが)おもしろくてオススメ読みポイントです。 初めての執筆活動 実は、本を出すことはおろか、寄稿するというのも初体験でした。 こんな貴重な機会をいただいた id:songmu
タイトルでほぼ出オチですが、2年ぶり4回目となるYAPC::Asiaでの発表をしてきました YAPC::Asia2015 from Masaru Hoshino www.slideshare.net 4回目とか言いつつ、内容はまだまだだし、発表自体も緊張しまくりでした。 前週のうちに資料作りと社内リハーサルを終えていたのに、前日とかにで結構な分量の修正してた。。 togetter.com いくつかコメントも頂いていてありがとうございます。 内容としては、現職での直近業務についてお話しするという感じでした。 はっきり言って地味な業務だし、伝わりづらい内容ではあると思いますが、何かの参考になれば幸いです。 YAPC::Asiaも10周年。 とうとう今回は2000人規模に。自分の発表した会場でさえ、一番小さいのに100人キャパ。 5トラックという並列性も過去最高。とんでもないイベントですね。 自
通常git push は git cloneしてきたリモートリポジトリに対して打つ事が多いので、 git push とか git push origin master くらいしか打ったことがありませんでした。 とある対応で、my/hoge.gitのリポジトリで作業したあと、最終的にpublic/moge.gitのリポジトリとして公開したいという 場面があり、git merge あたりを軽く眺めたんですが、結局 init commitなので手動コピー -> git add , commit , push でも いいかというアナログ手抜き対応をしちゃいました。 すかさず突っ込みを貰い、非常にシンプルな正解を教わりました。。 my/hoge.git をcloneしたディレクトリで、↓の1行で一発 git push [リポジトリ名] master ( 前述の例だと git push git@rep
blogに書くまでがYAPCです。 ここまで1個下のエントリと一緒。 結局1年間何も書かなかったということに・・・ 各トークの内容は例によってgihyoさん記事とスピーカー自身によるエントリにお任せ。 自分のスライドもSlideShare経由でYAPCのトークページに埋め込んでおきました。 トークした経緯は去年に引き続きgoccyに「喋らないんですか!?」って突っ込まれたから。 今年も人様の作業を堂々とパクる、という芸を見せてきました。 時間がギリギリだったので質問のタイミングがなく、どのように伝わったかわかりませんが 感想・ご意見などありましたらご連絡いただければと思います。 懇親会で「Perlのバージョンアップはホントにあんなすんなり行ったのー?」と聞かれました。 多少過去の出来事 && 一部のみ関わってた立場 ということもあり、把握してない苦労など あったとも思いますが、lestrr
この前の文字コード問題で、local::libで作った手元の環境だけ Encode.pmをアップデートしてテストなどしていました。 この辺は今は「 cpanm -l ~/local Encode 」でサクっと出来てステキですね。 そして、実験終了後に消そうと思って、 pm-uninstall -l ~/local Encode とやったんですが、 Encode is Core Module!! Can't be uninstall と怒られてしまい、終了。 どうやら過去の経緯からコアモジュールは削除できないようです。 確かに通常のlibの下で考えるなら気軽に消せてはマズイという事で 正しいのですが、同じようにlocalにな環境に入れる場合はないのかな、 ということで #perl-casualで相談してみたところ、即効で対応していただけました! http://search.cpan.org/
2011年にしてようやくutf8と向き合うことになりました。 と言っても、95%は「原則」を正しく読めば解決しました。 エントリとしては過去情報の焼き増しになるけど、一応メモとして残しておく。 原則 http://d.hatena.ne.jp/tokuhirom/20080408/1207619640 http://perl-users.jp/articles/advent-calendar/2009/casual/10.html 特にxaicronさんのエントリを改めて読み直したらカンペキにまとまっててすごい!Advent Calendar++ 最初に認識しておくこと 「sjisな世界、eucな世界、utf8な世界は他のレイヤーでもあるが、utf8フラグが立っている世界はperlの中にしかない」 今回困ったのは、 Cannot decode string with wide charac
あけましておめでとうございます(今年初のエントリ的な意味で) 昨日・今日と開催されたYAPC::Asia 2010でQudoについて発表してきました。 発表資料は↓にアップしました http://masartz.github.com/presentation/yapcasia_2010/start.html ということで、反省内容を列挙します、、、 思った以上に緊張した まぁ緊張するだろうとは思ってたんですが、正直手は震えるは、詰まって頭が真っ白になるは、尋常じゃなかったのが自分でも驚き。。お聞き苦しいかったろうと猛省。 ターミナル見えてなかったですよね えぇ、薄々気づいていました。準備不足ですみません。 ブラウザの文字サイズとかは気を使って発表前から微調整していたんですが、 デモは「もしかしたらするかも」程度に思っていたので、ぬかりました。 お詫びにデモスクリプト群もgithubにアップ
本日はてなよりアナウンスがあった、 Twitter のつぶやきからブクマできる連携機能 (http://hatena.g.hatena.ne.jp/hatenabookmark/20091022) に触発されて、mixiボイスからブクマするのを勢いで適当に作ってみました。 以下コード #!/usr/bin/perl use strict; use warnings; use AnyEvent::Impl::Perl; use AnyEvent; use WWW::Mixi::Scraper; use WebService::Hatena::Bookmark::Lite; use Config::Pit; use Date::Calc; my $hatena_conf = Config::Pit::pit_get('http://www.hatena.ne.jp'); my $mixi_co
4Gbpsを超えるWebサービス構築術 作者: 伊勢幸一,池邉智洋,栗原由樹,山下拓也,谷口公一,井原郁央出版社/メーカー: ソフトバンククリエイティブ発売日: 2009/08/21メディア: 単行本購入: 44人 クリック: 857回この商品を含むブログ (51件) を見る 昼休みにご飯食べながら読むという進め方だったせいもあって、かなり時間かかりましたが読み終わりました。 ライブドアが誇る技術が幅広く書かれているとの事でしたが、その内容は。 ■Chapter1 Webサービスの概要と要素技術 タイトル通り、Webサービスというものの歴史とその概要についての章。 Webエンジニアとしてはアイスブレイクと捉えられないとちょっとマズいかもしれません。 ■Chapter2 キューイング 負荷分散のよくある一つの解決策、キューイングによる後回し。 僕も普段から考えている場所だけあって、凄くすんな
一応業務の一環で来ているので、会社用にレポートを書かないといけないのだけど、 数多あるまとめサイトとスピーカー本人様達のエントリを集めればそれで十分すぎると思ったので、とりあえず私的感想から。 ◎前夜祭 yokohama.pm出張版。 ・なにより自分が喋れなくて残念。準備不足でした。次回のyokohama.pm通常版ではまた何か喋れるよう今からネタ仕込んでおかねば。 ざざっと書くと ・acotiesさん: AnyEvent的ななにか(仮) AnyEventとは何か、がホントに軽くわかった気がする。2週間くらいしか触ってないと言っていたのでスゲー ・spiritlooseさん: Schenker - DSL for quickly creating web applications in Perl 記述量の少なさが半端ない。最近思う事は他言語を知っている人は皆凄い。 ・kawanetさん:
最近社内のIRCにおいて、URLつきで投稿するとリスト化して管理してくれる botが作られてました。タグやコメントも管理出来てとてもよく出来ているので 気になったニュースとかを貼って共有するなんて感じで使っています。 ただ、情報の格納先が結局社内のサーバーに置いてしまうので、家で見ようとすると いったんブラウザで開いてはてぶする必要があります。 出来れば、適当なはてなアカウント作っておいて、 botがそのアカウントのブクマに追加する → 皆でそのアカウントのパーソナルフィードを読む みたいな感じにしたらいいかなーと妄想してました。 んで、はてぶのAPIのIFを調べたら以外になかったりしました。。。 ということで作ってみました。 http://github.com/masartz/p5-webservice-hatena-bookmark-lite/tree/master 「::Lite」を
昨日はyokohama.pm #4に参加してきました。 http://yokohama.pm.org/2009/03/yokohamapm-4.html 個人的には前回に引き続き、5分枠のスピーカーとして 喋らせてもいただき、非常に有意義でした。 http://www.slideshare.net/masartz/memcache-queue ※発表の時はspork使ったんですが、資料公開出来る 適当なサーバーがないのでパワポで作った叩きを整形してアップしました。 http://masartz.github.com/prezentation/yokohamapm-4/start.html githubでこんな使い方出来るなんで知りませんでした、、、 id:dannさんがこの形で公開していたので参考にさせていただきました。 ◎発表の反省点 ・時間短すぎ 正確な時間はわかんないんですが、ひょっ
昨日ひさびさにgithubを触り、followしている方のプロジェクトを見ていたら、ソースを落としたくなりました。 前提:単純にソースを見たい、プロジェクトを追いかけたいというだけならば、watchしてcloneすればOKです が、何を間違えたか、ついforkを押してしまい、めでたく自分のプロジェクト一覧に人様のプロジェクト(をforkしたやつ)が追加されました。。。 あわてて消そうにも、消し方わかんねー って事で一晩放置していたのですが、今見たらあっさり見つかりました。 という訳で以下手順 自分がforkしたプロジェクトのトップに移動( ex : ttp://github.com/masartz/hoge/tree/master ) グローバルメニューの「admin」をクリック Administrationの「Delete This Repository…」をクリック 「Delete R
前回なんとか1章を読みましたが、やっぱりよく理解出来てなかったのと2章に至っては「???」だったので、読めそうなところから読んで行って、一通り読み終わりました。 んで、僕のような初心者向けの読む順番として経験から一考察を。 一応目次には ========== 初心者 9章 1章、2章 ========== ========== Web系の方 4章 5章 6章 3章 ========== ========== システム管理を行っているかた 1章 5章 8章 ========== というような振り分けがなされています。 僕の感想としては、 (9章) ⇒ (「1章の6ページまで」) ⇒ (6章) ⇒ (3章→4章) ⇒ (7章→5章→8章) ⇒ (1章→2章) かなと思います。 9章 9章はホントに「Perlとは」っていうところについて。「perl≒CPAN」と取れなくもない図式のCPANについ
前回の http://coderepos.org/share/browser/lang/perl/TheSchwartz-Worker-Plugin-Manager を http://coderepos.org/share/browser/lang/perl/TheSchwartz-Worker-Plugin-Hook の形にリネームして再コミットしておきました。 んで同じものをgithubにも投入しました。 http://github.com/masartz/the-schwartz-plugin-hook/tree/master Plugin-Logの方は http://github.com/nekokak/the-schwartz-plugin-logger/tree/master こっちの方が素晴らしいので自重しました。 最近皆様絶賛移行中のgitですが、 手元のMac OS X(
http://coderepos.org/share/browser/lang/perl/TheSchwartz-Worker-Plugin-Log http://coderepos.org/share/browser/lang/perl/TheSchwartz-Worker-Plugin-Manager ◎TheSchwartz-Worker-Plugin-Log 実際に案件で使った際のログ仕様をほぼそのまま載せてしまっているのですが、 - pathとfileを指定して、任意のディレクトリにログファイルを吐く - 日付でローテーションされる 週ごとにログに吐きたいとか、そもそもDBに保存したいとかいう 要望には全く応えられない程度のシロモノです。 なので、今後の修正もその辺を念頭に考えてます。 ◎TheSchwartz-Worker-Plugin-Manager とりあえず名前訂正します
先週の金曜日はyokohama.pm #3に参加させてもらいました。 聴講者としては過去2回とも参加済みでしたが、今回は 何故かスピーカーという立場でLTをしてきました。 資料は以下に置いてあります。 http://www.slideshare.net/masartz/the-schwartz-presentation ◎反省点 ・資料がパワポ形式 id:nekokakさんを倣ってsporkを使おうと思ってましたが、どうもインストールに手こずる。 /usr/binとかにコマンドが出来ないという事象に追われ、面倒なのでパワポにしたら windowsで作る→macのopenofficeで開く→バグるorz spork問題は開催前日くらいに「コマンドファイル持ってきちゃえば?」の啓示で解決したので、 次回はそっちも使ってみようと思います。 ・内容に工夫を もうちょっとコードとか、デモとか出来たら
http://code.google.com/p/themasartz/source/browse/#svn/branches/workerbase ひとまず暫定で↑にコミットしてありますが、構成としては /test_client.pl /test_para_worker.pl /test_worker.pl /test_worker2.pl /lib/MyApp/Async/Test.pm /lib/MyApp/Async/Test2.pm /lib/MyApp/Hoge.pm /lib/TheSchwartz/Worker/Plugin/ModuleReload.pm /lib/TheSchwartz/Worker/Plugin/Parallel.pm こんな感じ。 上から順に。 ・/test_client.pl ジョブを突っ込むpl。2種類のジョブを投入 ・/test_worker.
このページを最初にブックマークしてみませんか?
『masartz->log(type=>'hatenablog')』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く