タグ

ブックマーク / songmu.jp (9)

  • 退職 | おそらくはそれさえも平凡な日々

    12月末でLaunchableを退職します。実際には11月30日が業務最終日で12月は求職活動をしていました。幸い12月中に転職先を決めることができ、1月から次の会社で働きます。次の会社は年明けにお知らせします。 求職活動中は多くの方や会社から連絡をいただき当にありがたかったです。全てにお返事をすることができず申し訳ありませんが、直接お知らせできなかった方にはこちらでお知らせとなることをご了承ください。 以上でお知らせは終わりで、以降は単なる中年男性のしょうもない独白です。 退職は非常に残念で、Launchableでまだまだやりたいことはあり、これからというところでもあったのですが、言ってしまえば西海岸外資の洗礼を受けたということです。 今回の僕の挑戦はあっけなく終りを迎え、ほろ苦い体験となりました。とはいえ間違いなく良い経験にはなりました。Launchableの事業は引き続き応援してい

    退職 | おそらくはそれさえも平凡な日々
    seiunsky
    seiunsky 2022/12/31
    くー、正座して読みました
  • Redisアプリケーションパターン | おそらくはそれさえも平凡な日々

    この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい

    Redisアプリケーションパターン | おそらくはそれさえも平凡な日々
  • Webアプリケーションエンジニアにこそ薦めたい「ITインフラ監視[実践]入門」 | おそらくはそれさえも平凡な日々

    ソフトウェアエンジニアのための ITインフラ監視[実践]入門 技術評論社様よりご恵贈頂きました。著者のkoemuさん、ありがとうございます。 この当に監視入門にふさわしく、以下のように網羅的かつ、そして何より陳腐化しない、普遍的な監視に対する心構えや考え方に対して非常によくまとまっていました。 レイヤリングと状況分析、システムの把握 監視システムをどのように設計、構築し育てていくか 監視の人員体制と業務設計 実際の障害の際の心構えと対応方法 自動化を見据えた話 監視に対する心構えや、「監視システムをどのように運用していくか、閾値をどのように決めていくか」、そして、なかなか無い観点として「監視体制の業務設計」といった話が印象深かったです。 モデルケースとして、Linuxサーバー上のApache、MySQL、Tomcatの監視などが取り上げられており、実際に Mackerel!!!を使っ

  • horensoというcronやコマンドラッパー用のツールを書いた | おそらくはそれさえも平凡な日々

    リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per

    horensoというcronやコマンドラッパー用のツールを書いた | おそらくはそれさえも平凡な日々
  • 株式会社はてなに入社しました | おそらくはそれさえも平凡な日々

    日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日語の会社じゃねーか!」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう

    株式会社はてなに入社しました | おそらくはそれさえも平凡な日々
    seiunsky
    seiunsky 2014/09/01
    ワイワイ
  • クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々

    デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒

    クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
  • Linuxサーバーのアカウント管理について | おそらくはそれさえも平凡な日々

    少人数でサービス開発をしていると、サーバーのアカウント管理を疎かにしてしまいがちです。良くないことだとわかっていながらも、共用ユーザーのログイン情報を数人で共有していたりだとか、rootばかり使っているなんてこともあるのではないでしょうか。 それだとオペレーターが増えたり、退職者がでたりした時に困ることになるので、最初からルールと仕組みを決めておいた方がトータルで楽になります。 前提 パスワードやログイン鍵の共用、ダメ!絶対! rootを常用するの(・A・)イクナイ!! パスワードやログイン鍵を共用していると、人数が増えた時に誰が作業しているのか把握するのが大変になりますし、退職者が出た時に一斉変更をせざるを得なくなって混乱してしまいます。逆に一部のスタッフを別扱いして権限を制限したユーザーをアドホックに作ったりしてしまうのも管理が煩雑になります。じゃあどうすればよいかというと、個人ごとに

    Linuxサーバーのアカウント管理について | おそらくはそれさえも平凡な日々
  • WEB+DB PRESS Vol.79 Perl Hackers Hubにcron関連の記事を寄稿しました | おそらくはそれさえも平凡な日々

    日見誌を受け取りました。感激しております。ありがとうございます。 縁あって、2/22 発売の WEB+DB PRESS Vol.79 に記事を書かせてもらえることになり「cron周りのベストプラクティス」というPerlにあまり関係ない記事を書かせてもらいました。 WEB+DB PRESS Vol.79 安定しつつも扱いづらいcronをどのようにWebアプリケーションプロジェクトで安定的に利用・活用するかについて書いています。cronだけで9ページという驚きの充実の内容です。とは言え、まだ書き足りない部分もあり、例えば比較対象としてJenkinsについても取り上げたかったのですが、泣く泣く削っております。 個人的にイノベーティブなプロダクトである、App::RunCronについても2ページを割いて取り上げております。 これであなたも、cronのログを捨ててしまったり、逆に溢れさせてしまっ

  • おそらくはそれさえも平凡な日々: 3分でpull request

    サクッとpull requestを送るために。 tl;dr % git config —global push.default simple しておく ブラウザでfork押して、そのリポジトリをcloneする % git checkout -b feature/hogehoge ってやってbranch作る 変更してコミットする % git push —set-upstream origin feature/hogehoge として修正をpushする ブラウザからpull request あらすじ ikachanを導入しようとした所、AnySanがssl未対応だったのでpullreq送ろうとしたらすでに同僚のmix3先生がpullreqしていて、mix3++であった。しかし、masterブランチからpullreq送るのは良くないよねってことで練習のためにtopicランチを切ってpullre

    seiunsky
    seiunsky 2013/05/12
  • 1