月100時間の残業で心身が衰弱して人生を見つめなおした話 - ブログあしみの
過去に月100時間の残業を経験しました。そのときの心と体の変化を思いだして書きます。今は過重労働に晒されていないので、なんとか元気です。 学生のときの友人と仕事の話をしていて「残業100時間」って言うと本気でドン引きされて本気で心配されたことが何回かあり、残業100時間の異常さを痛感しました（新卒で入った会社が己に与える影響は計り知れない）。 月に残業100時間というのは、 すべての平日で４時間残業（4h×20日=80h） 土曜日は３回出社（8h×3日=24h） 休日は、土曜１＋日曜４＝月５日だけ これで時間外労働が100時間ぐらいになります。平日は毎日9時-22時で働きます。家に着くのは22時45分です。職業はプログラマ。 寝られない 帰宅して、夕飯を軽く食べて風呂入って寝るんですが、寝られないんですよ。目が冴えるというか、脳がギンギンに冴えている状態なんですね。12時間もパソコンで知的
Webオペレーションエンジニアのアウトプットと開発力 - 人間とウェブの未来
という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、３行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い
ブラウザ拡張を用いた業務改善手法 - クックパッド開発者ブログ
買物情報事業部の根岸(@negipo)です。今回はブラウザ拡張を日常業務でどう使っているかについて紹介します。 ブラウザ拡張とは ブラウザ拡張は、ブラウザによるウェブとのインターフェースをJavaScriptやCSSを用いて自分好みにカスタマイズする機能です。Google Chromeを利用していればChromeウェブストアなどで公開されている拡張をインストールできるでしょう。一方で、開発したブラウザ拡張を自分で使うために、Chromeウェブストアによる公開と言うプロセスを踏むのは面倒です。日常的にウェブのインターフェースを改変する道具としてブラウザ拡張を使うためにはいくつかの手法がありますが、僕はGithubのdefunktさんが作ったdotjsを使っています。詳細は省きますが、今開いているページでalertを出すぐらいの機能であれば10秒で開発作業を終えることができると思います。 また
Vimでの作業をKibanaで可視化してみた - Qiita
はじめに 皆さんが有用な情報をどんどん世界に発信している中、このような無駄以外の何物でもない記事を書いてしまったこと、深く反省しています。 しかし無駄は楽しい。 無駄とわかっていても、やってみたらどうなるだろうという興味に負けてしまいました。 可視化結果 まずは結果から。グラフ化されるとちょっと気持ちいい。 ダッシュボードは適当に作ったもので、どのレポジトリでいつどれだけ作業したのか、どのファイルを特に更新しているのか、また更新した行数などを出せるようにしています。 何となく自分で 俺少しは作業したわー 感が味わえればそれで良かろうなのです。 これ以降は手法などの解説なので、興味のある方だけどうぞ。 可視化の方法 やったことはとても単純で、以下の通りです。 autocmd を使って発生したイベント毎に情報を収集 収集したデータを Elasticsearch に記録 Kibana で可視化
Slackboard〜Slackプロキシサーバ in Go〜 - Qiita
昨年末の話だけどSlackへの通知をプロキシするサーバをGoで書きました。如何せん1〜2時間で書いたので一部洗練されてない箇所があるかもしれませんが、 今年のはじめからすでに実運用をはじめています。 Slackboardの役割 SlackboardはSlackへのプロキシサーバであるslackboardとそのためのクライアントであるslackboard-cliの2つから構成されています。↓の図のようにSlackへの通知をクライアントが行うのではなく、クライアントからのリクエストを受け取ったプロキシサーバであるslackboardが行うという仕組みです。 このようにSlackへの通知を直接ではなくプロキシを介して行うのには以下のメリットがあります。 Slackへの通知設定をプロキシサーバで一元管理できる Slackへの通知リクエストをロギングできる 各サーバに散らばったSlackへの通知プロ
fluentdで本番環境を再現する - Qiita
toyama0919/fluent-plugin-http_shadowというShadow Proxyっぽいことを簡単にやるプラグインを作りました。 production環境で半年くらい動かしてたのでメモしときます。 「Fluentd Meetup 2015 夏」で実際のユースケースを発表しました。 Shadow Proxyサーバとは Shadow Proxyサーバについては以下がわかりやすいです。 気軽なMySQLバージョンアップ - まめ畑 Go言語を含む複数種類の言語により実装されたソフトウェアのベンチマーク - Qiita 実装としては以下のようなものが公開されています。 cookpad/kage lestrrat/p5-Geest kentaro/delta 本番のリクエストをそのままバックエンドにあるサーバーに複製して送信するのですが、アプリケーションの規模が大きくなればなるほ
Mappingのすばらしいリファクタリング（日本語訳）
※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプとフィールドのマッピングに関する多義性です。 この多義性は、インデックス時の例外やクエリ時の例外、 正しくない結果、リクエストからリクエストへ変化する結果、 また、インデックスの故障やデータのロスを結果として引き起こします。 Elasticsearchをより強固で予測可能な振る舞いをするようにする作業において、 フィールドやタイプのマッピングをより厳格でより信頼性を高くするかといったことに 多くの変更を費やしました。 多くのケースで、Elasticsearch v2.0で新しいインデックスを作るときにのみ、 新しいルールを強制し、これまでのインデックスに関しては後方互換性を保つようにします。 しかし、幾
エンジニアに必要な説明能力 - Konifar's WIP
最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
運用を楽にするためのアプリケーションコードを書くということ : sonots:blog