思った事とか勉強したことをまとめて書き出したり表現したりする、つまりアウトプットを、なかなか書けない時とするする書ける時というのがある。その違いは何なのかとか、アウトプットがうまくいかないときに、それを妨げている心理的障害は何なのかを掘り下げていくうちに、これ自体が一つのアウトプットになった。つまり今回は成功だ。 だいたい僕はアウトラインの途中らへんまでを構成して、そしてそれを半分くらい文章として肉付けしているあたりで厭になって辞めてしまうことが多いのだった。ブログの下書きにはそういった文書が積み重なっていて圧巻だ。 なんで途中で辞めてしまうのか。それはやはり劣等感と遠くでつながっている話であるようだった。僕はまず辞めてしまうタイミングに着目して、その時どういうふうに感じているか、自分と向き合ってみた。すると、僕がアウトプットの中途で書くのをやめてしまうのは、「大したことをやっているように

こんにちは。Mackerel開発チームディレクターの id:daiksy です。 Mackerelチームでは、開発プロセスにおけるプラクティスや、チームをうまく機能させるための様々な取り組みに対して、普段から定期的なカイゼンを行っています。 世の中は新年度を迎え、いろいろと新しい取り組みにチャレンジしやすい時期でもありますし、Mackerelチームで行った最近のカイゼンの様子を簡単にまとめてみようと思います。 振り返りでKPTをやめた Mackerelチームではスクラムをベースとした開発サイクルを採用しており、1スプリント2週間というペースで開発イベントが計画されています。スプリント最終日に振り返りを実施し、2週間の間に起きた出来事や課題などを議論して、次のスプリントでカイゼンをする、というルーチンです。 チームではこれまで長い間、KPTという振り返りのフレームワークを採用していました。K

概要 netstatやssコマンドにより、あるホストと他のホストとのコネクションを一覧表示できる。しかし、Webシステムの場合、クライアントが並行接続するため、 同一ホストから複数のポートを介してコネクションを確立しているケースが多い。コネクション数が大きい場合は、1万以上のコネクションが表示され、ホスト間のコネクション状況を人間の目で概観することが難しかった。 そこで、同一ホストとのコネクションを集約表示し、コネクション状況を概観する 「lstf」 (「えるえすてぃーえふ」)コマンドをつくった。 github.com lstfの特徴は以下の通り。 コマンド実行ホストを起点に、active openコネクションかpassive openコネクションを判定する。つまり、接続をする側かされる側かを判定する。 各ホストフローごとにコネクション数を表示する Goで実装されているポータビリティ。i3

先日ジャストシステム様主催のJustTechTalk#11で CRE について発表しました。 JustTechTalk#11 エンジニアの新しいキャリア Customer Reliability Engineer (CRE) - 株式会社ジャストシステム | Doorkeeper speakerdeck.com このエントリでは、イベントの様子や登壇の補足をします。 CREへの期待とイベントの様子 CRE ははてなさんを皮切りに、私の所属する XFLAG スタジオ、最近はメルカリさんも設立したことで注目を浴び始めています。 これまでエンジニアリングリソースは、新機能の開発やプロモーション施策といった KPI に直結する、いわば経営陣から見えやすい部分に対し集中されてきました。 CS というお客様に近い場所で長くエンジニアとして携わってきた私は、そのことにずっと疑問を抱きつつも、CS こそ今

今月15日・16日と二日間に渡って開催された、「デブサミ」こと Developers Summit 2018 にて登壇、発表をしてきました。タイトルは、「自分」をまるごと活かす！私が“CRE”というキャリアを選んだ理由 。 みなさまご静聴いただきありがとうございました！！さきほどの資料を公開しましたー！ https://t.co/ul2uQMSAFb #devsumi #devsumia— a-know | Daisuke Inoue (@a_know) 2018年2月16日 資料は以下です。 speakerdeck.com 今回の発表で「伝えたい」「これを機に改めて考えてみてほしいな」と思っていたことは、以下のようなこと。 「自分を活かす」とは言うけれど、そもそも「自分」ってどんな存在なんだろうね。考えてみよう 僕が "CRE" という仕事を選び、今もなおその仕事をしている理由は、○○だ

前職ではスクラムマスター的な立ち回りをしていたり、今でもたまにファシリテーターを頼まれることがあったりするので、そのときに気をつけてることをちょっとメモしてみる。どちらかというと経験則に近いかんじ。 その場にいる、できるだけ多くの人に話をしてもらえるようにする ある事象について、「それを知ってそうな・知らなそうな人」「その場にいた人・いなかった人」に意識をフォーカスして掘り下げる 「なぜ・どうして」や「どのようにして」、そして「どうあるべきか」にフォーカスする （そもそもの話）できるだけ当事者じゃない人がファシリテートするのがよい なんかもっとある気がするので思い出したら追記します。 その場にいる、できるだけ多くの人に話をしてもらえるようにする チームの大小あると思うけど、できるだけ多くの人に話をしてもらえるようにする。理想的にはその場にいる全員に一度は発言の機会はあって欲しいし、それがで

若手エンジニアを不幸にしないための開発の「べからず」集　組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい

今からどうでもいい話をします。 私の人生は、割と大きなレベルで、忍者ハットリくんによって変わりました。 忍者ハットリくんといっても、アニメ版や原作ではありません。 ハドソンから発売されていた、ファミコン版の「忍者ハットリくん 忍者は修行でござるの巻」の話です。 皆さんご存知ですか？ファミコン版の忍者ハットリくん。 ハットリくんを操作して、ひたすらゴールへと突き進む横スクロールアクションゲーム。 世間的には、ハットリくんのお父さんであるジンゾウが、ゴールにたどり着いて喜んでいるハットリくんに対して、大量のチクワに混ざって容赦なく鉄アレイを投げまくってくるゲームとして著名だと思います。 落ちてきた鉄アレイに直撃しても一瞬動けなくなるだけで済むハットリくんの耐久力半端じゃないとか、 そもそもチクワが好きなのはハットリくんじゃなくて獅子丸だろなんでハットリくんがチクワ与えられてるんだよとか、 ハッ

表題についてそーだいなる見解を書き残します。 今年の夏に id:koemu さんにbuilderconの懇親会で下記のような話をいただいていました。 懇親会で、DB側ばかりでなくプログラム側でも適切なドメインモデルの設計ができていれば、リファクタリング時の影響範囲がさらに小さくできるのでは？という話をしたところ、この辺りはアンサーブログを書いてくれるかもしれないってことなので期待しています！！！ www.koemu.com 忘れてないんですよ！しっかり覚えています。 結論 仰る通りだと思うし、適切なドメインモデルはRDBに限らずデータストア層のリファクタリングの負担を大きく減らすと思います。 ここから先は僕なりの考え方を書きます。 実は似たような話を PHPの現場 っていうポッドキャストでも触れています。 php-genba.shin1x1.com システムの柔軟性 勿論、コードの綺麗さや

もともと数ヶ月前から、Go言語によるWebアプリケーション開発 を読みながら Go での Webアプリケーション開発の勉強をしていた。 Go言語によるWebアプリケーション開発 作者: Mat Ryer,鵜飼文敏,牧野聡出版社/メーカー: オライリージャパン発売日: 2016/01/22メディア: 大型本この商品を含むブログ (3件) を見る 「実際に動くもの」を、「手を動かして作りながら学ぶ」のが僕は好きで、今回も同様、それを楽しんでやっていたのだけど、思いの外それっぽいものができあがってしまって。これをそのままローカルで動かすだけじゃおもしろくないな、もったいないな、と思ったので、それをサービス化して公開するところまでやってみた。 かんじんのアプリケーションは↓これ。Yukizuri と書いて「ゆきずり」と読む。 https://yukizuri.moshimo.worksyukizu

無駄に長い前置き　これは、PostgreSQL Advent Calendar 2017の16日目の記事です。　昨日はnuko_yokohamaさんの記事でした。 PostgreSQL10では9.6で実装されたパラレルクエリが強化されており、集計・分析業務への適合性が高まっております。 また、ある程度増減するとはいえ、CPUやメモリの価格も時の流れとともにどんどん安くなっています。　数百GBくらいのデータであれば、データを全てメモリに乗せてしまって、マルチコアでパラレルクエリをぶん回してしまえば、大抵の場合はどうにかなってしまうのではないか……と、昔から考えております。　当然、数十TBやPB級は難しいでしょうし、PostgreSQLはインメモリDBでもなければ列指向型DBでもありませんので、高速に集計をすることを前提に作られたDBMSと比較すると効率は良くないでしょう。 ただ、記事執筆時点

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の24日目です。 qiita.com soudai.hatenablog.com それでは24日目は mackerel-plugin-json です。 mackerel-plugin-jsonはその名のとおり、JSONを可視化するプラグインです。 github.com 2020/12/02 追記 めちゃめちゃ便利なmackerel-plugin-jsonも進化していて、下記に出てくる多くの問題点が解決しています。 インストール カウンター値の計算 header付与によるセキュリティ これらを解決した機能の説明についてはこちらをご参照ください。 cohalz.co インストールと設定手順 mackerel-plugin-jsonのインストールですがmackerel-plugin-jsonは公式パッケージに同梱されてい

この記事は、法務系 Advent Calendar 2017 の参加エントリです。 はじめに はじめまして。@h_kitaokaさんからバトンを受け取りました。 社会人3年目、法務も3年目のまごうことなき若手（？）です。これまではとても書く側には回れないと読者に徹していたのですが、お祭りに参加してみたい一心から、勢いで登録してしまいました。期日までには書くことも思いつくだろうと楽観していたのに、頭を捻っても叩いても何も思いつかず、日頃いかに自分が140字以上のことを考えていないかを思い知らされた次第です。この点を反省できただけでも、自分のためには参加した意義があったと思います。 ということで、今後はもっと問題意識とやる気をもって業務に取り組んで参ります。この度はありがとうございました。～完～ としたいところなのですがさすがにそういうわけにもいかないので、普段から他力本願な自分の頭を占めがち

Mackerel Advent Calendar 2017 - Qiita の12/20の記事です 以前、【増枠】紅白 Milkcocoa 合戦！【祭り】 Milkcocoa Meetup vol12 - connpassでLTしたこれを 20160720_わたしとmilkcocoaの20日間 from Keiko Nishioka （要約：３時間で勝手にエアコンが切れるアパートで、 ハムスターのために温度が一定以上になったらラズパイでエアコンつけて夏を乗り切りました） いろいろと事情が変わったので、今回はMackerelを使って改造してみました！ 前回より 変わったこと 実は当時のアパートから引っ越ししたので事情がとても変わりました エアコンが勝手に切れない！！ ハムスターたちとエアコンが遠いので、ハムスターのそばで温度を取ると赤外線が届かない もしかして実はもう必要ないのでは... 当

この記事はMackerel Advent Calendar 2017の15日目の記事です。 昨日は @mattn さんの Mackerel で Oracle のパフォーマンスを監視する という素晴らしい記事でした！ はじめに Mackerel を 利用し始めて半年ほど経ったので、自分が担当しているサービスで監視がどのように変わったか、 自分の監視に対するポジションやスタンスがどう変わったか、というのを書いてみようと思います。 Mackerelに関しては高度な活用記事が多いのですが、こういう「普通に監視しています」という記事があっても良いのではないかな、と思って書き始めたものであり、個人の見解です。 所属する組織を代表するものではありません。 祝！ Mackerel を 導入 2017.5～ トライアル開始 ということで、正式利用を開始してから大体半年経過することになります。 この半年の間に

ssmjp 201712 はたのさん祭での「運用自動化、不都合な真実」の発表資料です。 詳細: https://www.opslab.jp/publish/20171212-ssmjp-automation.html (運用設計ラボ合同会社 波田野裕一)

この記事は Mackerel Advent Calendar 2017 の 12/14 の記事です。 はじめに Mackerel はサーバの監視を行うサービスです。サーバの負荷だけでなくあらゆるリソースの値をメトリクスとして収集し、グラフによる見える化、監視、アラーム送信といったインテグレーションを行うサービスです。Mackerel にメトリクスを送信する mackerel-agent はプラグイン方式を採用しており、色々なメトリクスを Mackerel に送信する事が出来ます。提供されているプラグインには既に色々な物が用意されていて、導入するだけで直ぐに監視を行う事が出来る様になっています。尚、今年は @soudai1025 さんが25日まるまる mackerel plugin だけの Advent Calendar を書いています。各プラグインの README だけでは伝わりづらい色々

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の9日目です。 qiita.com soudai.hatenablog.com それでは9日目は check-tcp です。 check-tcpはTCP Socketを監視してくれるプラグインです。 github.com インストールと設定手順 至れり尽くせりなので公式ドキュメントに手順が書いてあるのじゃ！！ mackerel.io 使い方 至れり尽くせりなので公式ドキュメントに使い方が書いてあるのじゃ！！ mackerel.io オプション一覧 README.mdにあるけど表記しました。 # check-tcp -h Usage: check-tcp [OPTIONS] Application Options: --service= Service name. e.g. ftp, smtp, pop, imap

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の11日目です。 qiita.com soudai.hatenablog.com それでは11日目は mackerel-plugin-multicore です。 mackerel-plugin-multicoreはマルチコアのCPUを監視するためのプラグインです。 Mackerelではmackerel-agentが送るシステムメトリックスでもCPUの使用率を見れます。 しかし、個々のCPUの利用状況を見ることができません。そこでmulticoreプラグインの出番なのです！ github.com インストールと設定手順 multicoreのプラグインは /proc/stat の中身を可視化してくれるプラグインです。 本プラグインはプラグイン集として提供しているパッケージの mackerel-agent-plugins

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の8日目です。 qiita.com soudai.hatenablog.com それでは8日目は check-procs です。 check-procsはプロセスを監視してくれるプラグインです。 github.com インストールと設定手順 至れり尽くせりなので公式ドキュメントに手順が書いてあるのじゃ！！ mackerel.io 使い方 至れり尽くせりなので公式ドキュメントに使い方が書いてあるのじゃ！！ mackerel.io オプション一覧 公式ドキュメントに無いので追加しました。 # check-procs -h Usage: check-procs [OPTIONS] Application Options: -w, --warning-over=N Trigger a warning if over a n