こんにちは、nekoyaです。 システムを日々運用していく中で、その処理結果の記録や異常検知の仕組みは地味ながらも大切な存在です。 各種監視ツールからの通知や、ブラウザから利用可能なWebインタフェースなど、その形態も様々です。 今回はその中から、バッチ処理の結果通知について、我々のチームが実践している方式をご紹介します。 loggerを通して記録する まず前提として、通知する内容はプログラマ自身が出力することが基本になります。 自分はここ数年はPythonをメインに使っていて、標準のloggingモジュールを通して import logging logger = logging.getLogger(__name__) logger.info('hello!') のようにログを吐いておくと、スクリプトの終了時にそれまで出力したログがいい感じに集約されて通知されるようにしています。 ログレベ
YAPC::Asia 2015が終わってもう一週間以上。やっと自分の中で少し消化できた感があるので今更ながらエントリ。 俺とYAPC 自分にとってYAPCは「楽しいお祭」というよりは、過去を見つめ直し、未来を見据えるための厳粛な式典という趣がある。 初参加予定だった2008年（チケット買ったけど行けなかった）と最後の区切りとなる2015年の両方に、会社の買収というイベントが重なるのも感慨深いものです。渦中まっただ中という立場ではなかったにしろ、自分の生き方が確実に変わる節目が何度かあって、その年その年のYAPCで自分の立ち位置を確かめて来た感があります。 必ずしも楽しいばかりではなく、悶々とする年も少なくありませんでしたが、それもこのイベントが自身にとって大きな意味を持つ儀式であることの表れでした。 この数年で、かつては村社会的なイメージが強く（※個人の感想です）、様々な理由からあまり表に
皆が待ってたServerspec本が発売されました。オライリーから電子版で購入。 http://www.oreilly.co.jp/books/9784873117096/ 実のところServerspecはずっと気にはしつつも、横目で見るだけで使いどころを決めかねていました。 自分のサーバ管理のスタイルは、 cobblerでOS入れる Puppetで構成管理 オペレーションはfabric（以前はcapistrano） 監視にNagios, CloudForecast というもので、2007年のSofeware Designでmizzyさんの記事を読んでPuppetを使い始めて以来、構成管理はずっとPuppetです。 モジュールは全て自作で、年単位でメンテしているモジュール群を投入しつつ、必要なものをその都度追加していくスタンス。 Puppetサーバを起動するモデルではなく、--noopでd
nodeで開発はしてないけど、フロントエンドを書く時にはnpmとか必要なので何かが変わるとうろたえる情弱です。 Ubuntu12.04で用意されている標準パッケージは古いので、公式のリポジトリを追加して入れる。 https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager#ubuntu-mint-elementary-os で、新しいVMを作ってセットアップしてたらnpmのインストールでコケる症状が出たのです。 $ dpkg -l | grep nodejs ii nodejs 0.10.29-1chl1~precise1 Node.js event-based server-side javascript engine $ sudo apt-get install npm Reading packag
Ubuntuのインストール時にFQDNを書いても/etc/hostnameにはshort nameが入るし、Vagrantのconfig.vm.hostnameにFQDNを書いてもドメイン部分落とされるし、どういうことなんだろうと思ったらdebianマニュアルのホスト名の項に書いてありました。 3.2.5. The hostname The kernel maintains the system hostname. The init script in runlevel S which is symlinked to "/etc/init.d/hostname.sh" sets the system hostname at boot time (using the hostname command) to the name stored in "/etc/hostname". This f
「モジュールAをimportしたらBもCもまとめて入っちゃう」とか「importしたら俺の中の何かが変わった」みたいなのをやる方法。 お行儀のいいやり方ではないが、テストコードに限って言えばやってもいいかなと思って試してみた。 import inspect caller = inspect.getmodule(inspect.stack()[1][0]) caller.hoge = fuga callerに呼び出し元のモジュールが入るので、あとはよしなに。 ただ、これやるとpyflakes（自分はflake8使用）とかに「未定義の名前を参照してるよ！」って怒られる。うーん微妙か…
namedtupleをもっと積極的に使っていきたいと思いながらも、今ひとつやれてないので軽くベンチ取ってみた。 ユースケースとして、アプリケーションのconfigをdict, namedtuple, objectそれぞれで持った場合を想定する。 from collections import namedtuple from benchmarker import Benchmarker def convert(v): if isinstance(v, dict): return namedtuple('_', v.keys())(**{x: convert(y) for x, y in v.items()}) if isinstance(v, (list, tuple)): return [convert(x) for x in v] return v conf = { 'home': '/
Pythonからテスト用の各種サーバを起動するライブラリ、tcptestにfluentdを起動するモジュールを追加しました。 https://pypi.python.org/pypi/tcptest/0.4.0 こんな感じで使うと、server.logsに軽く整形されたログが溜まっていくのでテストがわりと楽に書けます。 import fluentd.sender import fluentd.event with tcptest.fluentd.Server() as server: fluent.sender.setup('app', port=server.port) fluent.event.Event('follow', {'foo': 'bar'}) fluent.event.Event('label', {'hoge': 'fuga'}) print server.logs #
「そもそも現役バリバリだし、前回のカンファレンスの同窓会だし」とか思ってたら、いつの間にかすごい規模の公開イベントになっていた自作サーバー同窓会におじゃましてきました。主催の@stanakaさん、ありがとうございました。ご挨拶できなかった… 弊社のインフラを支える@SatchanPの当日のスライドと振り返りがこちらにございます。 自作サーバ同窓会で話をしてきました 我々としては@SatchanPという優秀なコンテンツをインターネッツに提供できただけで満足です。 当日のトークでは物理面にフォーカスしていたので、もう少し上のレイヤにも軽く触れておきたいと思います。 調達の歴史 弊社は2009年創業で、ちょうど自作サーバカンファレンスがあった年にサービスを開始しました。2007年頃にも自作サーバでサービスを回していたこともあって、まったく抵抗なくやれたし業界的にも活気がありました。 その後、Co
TLで見かけた記事。 プログラマーを採用する際に重視すべき10の資質 2008年の記事を今更どうこう言うのも何だけど、翻訳記事の難しさを改めて感じたので。 元記事へのリンクが切れてたので、原文分からんけど海外でも「残業こそ正義」みたいな価値観もあるのかーと思ったんですね。 そしたら、@t_ichimiyaが原文拾ってきてくれました。よく見たら原文へのリンクが「.com.com」になってますね。適当だなぁ。 10 traits to look for when you're hiring a programmer Some programmers are "daycoders" -- people who write code 9 to 5, Monday through Friday, and do not think about it in the slightest outside o
毎週定例の社内勉強会でオブジェクト指向の基礎についてLTしました。資料はやや加筆しています。 昨今、オブジェクト指向というとMVCとかデザインパターンみたいな発展的なトピックが目立つような気がしていて、もっと簡単に考えればいいのになーという思いからこういう話をしました。 凝集度を高める設計指針を出来るだけ平易な言葉で語ろうというのがコンセプトでした。 サンプルがいろいろ話をはしょりすぎで、改めて見るとちょっと違和感ありますね… 開発のバイトで来てくれてる学生の子たちに、こういう概念的な話を聞いてもらう機会って積極的に作らないとなかなかないので、そういう場を作っていくのもおっさんの役割なのかなーみたいなことを思ってます。
stylelintのv8.0.0がリリースされてた。 今回のリリースでは、deprecated扱いになっていた各種ルールが正式に削除されて、古い設定を使い続けていたプロジェクトでは更新が結構ダルいかもしれない。 新たにstylelint-config-recommendedというルールセットも公式から提供されました。 https://github.com/stylelint/stylelint-config-recommended わりとゆるめの設定になっているので、こいつをベースにしておくと今後のアップデートへの追従とかもいい感じに出来そう。各ルールの設定そのものも標準的なんじゃないかなぁという印象です。 新規に導入するならstylelint-config-standardの方が幅広くカバーしているのでよさそう。 https://github.com/stylelint/stylelin
MacBookAirの液晶が割れて買い替える → 新しく作った環境でOctopressが動かない → だるい みたいなことがあって放置してましたが、改めてブログを作り直しました。 github pagesのドメイン変更への追従やら、Octopressのcanonical設定がデフォルトだとよろしくないのやら、微妙な黒歴史を捨てようかとも思ったのですが、できるだけ維持する方向で調整しました。 https://github.com/nekoya/nekoya.github.com/tree/source rstblogとかも考えたけど、まぁたいした機能いらないからPythonでふわっと書いてみたのでようやく社会復帰できますかね…
@kokorohamoeさんのエントリがとても面白かったので紹介。 プログラマの生産性は２０倍違うという表現は誤り、プログラムはピアノだと思えば良い。 猫ふんじゃったならだれでも引ける。 猫ふんじゃったならだれでも引ける。だけれども、そのレベルの人を５００人集めても、ショパンは引けない。 この例えは穏便に、かつ適切に実情を表していて、積極的に日常で使ってきたいですね。 けど、きっとこんなこと言うオッサンが出てくるんだぜ… 「1小節だけならどうにかなるだろ。500人に1小節ずつ弾かせて後で編集でつないでよ」 「難しいところも右手だけ、左手だけなら以下略」 「大丈夫、ちょっとぐらい間違えたって分かりゃしないって」 「そこだけ外注に出して弾いてもらえばいいんじゃないの。あとは猫が踏めりゃどうにかなるって」 そして、挙げ句の果てには 「天才がいないからショパンが弾けないなんて甘え。工夫すればどうに
日付を扱う処理についていろいろまとめたついでに、わりと簡単なことだけど知らないと落とし穴にハマる系のネタを。 日頃いろいろな処理を書いていて、現時刻を扱うこともは少なくないはずです。ですが、これを適当にやっていると困ることが多々あります。 実行中に「現時刻」を元にした処理が食い違う 例えばこんなコード。ログ集計とかやってるイメージです。 class Analyzer(object): def analyze(self): logfile = datetime.datetime.now().strftime('my_log_file.%H') self.save(self.analyze_logfile(logfile)) def save(self, result): now = datetime.datetime.now() self.result[now.hour] = result
Pythonでnaiveなdatetimeオブジェクトにtzinfoを付けてawareにするには、公式には 単にタイムゾーンオブジェクト tz を datetime オブジェクト dt に追加したいだけで、日付や時刻データメンバへの調整を行わないのなら、 dt.replace(tzinfo=tz) を使ってください。 こう書かれているのですが、どうもこの方法は夏時間の扱い以外にも問題があるようです。 >>> import datetime, pytz >>> jst = pytz.timezone('Asia/Tokyo') >>> datetime.datetime.now(jst) datetime.datetime(2013, 7, 5, 12, 23, 1, 962735, tzinfo=<DstTzInfo 'Asia/Tokyo' JST+9:00:00 STD>) >>> d
MySQL-python（MySQLdb）を上げたら、今まで通ってたテストでwarningが出るようになりました。 MySQLdb/times.pyで以前は def format_TIMESTAMP(d): return d.strftime("%Y-%m-%d %H:%M:%S") こうなっていたものが、 def format_TIMESTAMP(d): return d.isoformat(" ") こうなったのが原因らしいのだけど、Changelogを見てもそれらしい表記がないので少し経緯を追ってみました。 この変更で何が問題になったかというと、 >> import datetime, pytz >>> datetime.datetime.now(pytz.utc).isoformat(' ') # aware '2013-06-27 01:50:16.156481+00:00' >
日付周りの処理というのはとても難しい問題で、特にTimeZoneが絡むと基本的に大変なことになります。 Pythonは標準で用意されているdatetimeモジュールが高機能なので、それを使っておけば間違いない感があって、そういう意味では安心感があります。 とは言え、その扱いにはやはり注意が必要で、現時点でこうするのがいいかなーと思っていることをつらつらと記録したエントリがこちらです。 基本的にはMacのPython2.7.1で検証して、おやっと思ったところはCentOS5.8のPython2.6.5やUbuntu12.04のPython2.7.3で追試しています。 なお、datetime.datetimeと書くのがだるいので本文中では、 from datetime import datetime を前提としています。 naiveとaware 公式ドキュメントにそのまま載ってるけど、date
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く