はてなブックマーク

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

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

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

INDEX コーディングスタイル ファイル操作 日付・時刻 その他 その他 .pycを作りたくない 環境変数PYTHONDONTWRITEBYTECODEを設定すると、.pycおよび.pyoファイルが作成されなくなる。値は何でもいいので、 export PYTHONDONTWRITEBYTECODE=1 などと書いておけばよい。 辞書（dict）のソート キー（key）の順に取り出す >>> score = {'Jack':300, 'Mike':200, 'Jane':100} >>> for (k, v) in sorted(score.items()): ... k, v ... ('Jack', 300) ('Jane', 100) ('Mike', 200) 値（value）の順に取り出す >>> for (k, v) in sorted(score.items(), key=l

毎週水曜にやっている社内勉強会で、テストに関する基本的なことについてLTしました。 About test from Ryo Miyake 主にバイトの子たちに普段何気なく書いてるテストコードについて、改めて概念的なところのおさらいをしてもらえればなーという感じの話でした。 xUTPの話をしたけどわりとハードル高そうだったので、会社の本棚に置いてるレガシーコード改善ガイドも軽く紹介しておきました。 毎週、ネタがある人に適当な時間でトークしてもらうというので1時間ぐらい何となく回してて、3ヶ月ぐらい途切れることなくやれてるのでわりといい感じ。

@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' >

「Pythonの日付処理とTimeZone」を書いた後、Twitterで指摘をもらっていたのを遅ればせながら検証したので、改めてエントリを起こしてみました。 Pythonの日付処理とTimeZone http://t.co/KK1B5Fot0V datetime を tzinfo 付きで生成する場合は pytz.tzinfo.normalize しないと DST 境界を超えるところで存在しない時刻を作りますよ — Jun Omae⁽⁶⁶ʲ⁵⁾ (@jun66j5) June 22, 2013 @jun66j5さんありがとうございました。 このへんの背景はpytzのサイトにありますが、そもそもサマータイムに馴染みがないのでどうあるべきかがしっくりきません。 標準時と夏時間の切り替わり ここでは、ニューヨークが属するTimeZoneを例に話を進めます。まずは基本的な用語の整理から。 DST …

日付周りの処理というのはとても難しい問題で、特に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

「%Y%m%d」をstrptimeで処理すると曖昧になることを今更ながらに知りました。 社内で「201312」を渡すとキモいという話が出て、 Pythonでdatetime.datetime.strptime('201312', '%Y%m%d')がエラーにならず1月2日として成立するの具合悪いと思うの — nekoya (@nekoya) June 7, 2013 ってPostしたら@hirataraさんが「2013129と2013130もキモいぞ」と教えてくれました。 普段は%Y-%-%dを使うんだけど、URLに日付を埋め込む場合はデリミタ無しの方が自然だなーと思ったらご覧の有様だよ。 Python2.7.1 >> datetime.strptime('201312', '%Y%m%d') datetime.datetime(2013, 1, 2, 0, 0) >> datetime.

PerlでいうところのTest::TCP相当のことをPythonでやるライブラリをPyPIに上げました。ようやくPyPIデビューです。 https://github.com/nekoya/python-tcptest https://pypi.python.org/pypi/tcptest Test::TCPはPerlでテスト時に一時的にサーバを起動したりする処理の基盤となるライブラリです。同等のことをPythonでやるのに適当なものが見当たらなかったので自分で書いたという経緯です。 社内では以前からこの仕組みを使ってテストを書いていたのですが、自社のconfig系のライブラリとの結合を排除して、再構成したものになります。今回こうして公開するにあたって、関数名をオリジナルのPerl版に近付けたり、TestServerの実装を全面的に見直したりしました。 tcptestパッケージにはTest

「恐怖」を知ること 35歳が目前に迫りつつある中、ぼちぼちスピリチュアルなことも書いていこうかと思う今日この頃です。 これまで十数年、小さな会社やフリーランス、大企業（はすぐ辞めたけど）を渡り歩いてきて改めてベンチャーの面白さを実感しています。 様々な要素がありますが、その最たる物は「エンジニアが会社の命運を握っている」という紛れもない事実です。自社でプロダクトを開発しているベンチャーにおいて、どんなに立派な経営理念やビジネスモデルも動かないシステムの前ではクソの役にも立ちません。 そして、それはそのままエンジニアの過ちが会社を危機に陥れるリスクを意味します。言ってしまえば「ワンクリックデプロイ」が「ワンクリック倒産」へと直結するかもしれないのです。省力化そのものは目指すべきですが、自分の行為が内包するリスクは忘れてはならないのです。 「何か」が起きてしまった時に上長の責任だ、確認ミスだと

UML、最近はあまり名前を聞くこともなくなってきた感があります。 「UMLなんていらない」なんてスレもあったりして、どうにも廃れた物と見る向きもあるようです。 「UML」タグではてブの人気エントリを探しても、2005〜2007年ぐらいのものが目立つので、注目度という意味では流行ではないのは確かなのかなぁとは思います。 が、このところ有用性を改めて実感することが多いので「UMLいいよ」というエントリを書きます。 上記のスレは賛否両論併せてなかなかいい具合に意見が出ていて面白いのですが、以下を抑えていれば認識としてはいいのではないかと思います。 UMLは設計の技法ではない 頭の中を整理するため、あるいは人と共有する際の表現技法である 弊社では、新しく入社したメンバーにプロダクトの設計を共有したり、新機能の開発をする際の社内レビューなどの際に、シーケンス図っぽいものやクラス図っぽいものを使うこと

さくらのVPSは初期設定はCentOS6だけど、Ubuntu入れるのも簡単でいいですね。 ただ、インストール直後は本当にOSを入れただけの無防備な状態で非常に危険です。 最低限の設定を定型化しておかないと怖いので、以下メモ。 手順はUbuntu12.04LTSを前提にしていますが、特別なことはしていないので多少の違いは問題ないはず。 OSインストール直後の安全確保 インストール自体はマニュアルに沿ってやればOK。 ただし、パスワードは万が一抜かれてもいいように、普段使っていない捨てパスワードを使う。 起動したら急いでufwを使ってiptablesの設定を入れる。まずは全部閉じる。

ここ数年はPerlで暗号を扱う時はMcryptを使っていますが、少し前の時代だとCrypt::CBCを使ったりしてました。世間の流れは知らないけど、Mcrypt使っておけば他のシステムとデータをやりとりする時にお互いやりやすいよねという。 Crypt::CBCで作られた暗号文字列をPythonで復号するケースがあったのですが、そのまま素直にやるとうまくいきません。 padding周りかなと思ったけど、どうやらkeyがそのままでは使えないらしい。stackoverflowにズバリそのままUsing PyCrypto to decrypt Perl encrypted passwordがあったのでメモ。 {% gist 5088592 publish_hex_key.pl %} こんな具合にして変換したkeyをPythonのコードに埋め込みます。 {% gist 5088592 decrypt

皆様におかれましては、WEB+DB PRESSの最新号のRedis特集は既にご覧頂いたかと存じます。 弊社では1年ほど前から広告配信に関する様々な部分でRedisを使っています。まだ2.4系なので、2.6の新機能とか新鮮でした。 本番環境でRedisを運用する上で、強く訴えたい注意点は「RDBが壊れることがある」ということです。 「RDBがあるからインスタンスが落ちても平気だぜ」とか思ってると、RDBが壊れてリストア失敗→データ消失ということになりかねません。ファイルにdumpされるからと安心していると痛い目に遭うかも知れません。 （2013/02/27追記）今のところ壊れたのはハード障害が怪しい場面のみです。「RDB壊れるとかRedis使えねー」とかそういう話ではまったくありません。誤解無きよう。壊れる時はRedisじゃなくても壊れます。自分のユースケースではTokyo Cabinet/

先のエントリで以下のように述べた伏線の回収エントリとなります。 そして、get_user()という名前はサンプルコードにはありがちだが、この名前も闇が深いと思っている。これについてはまた別途取り上げたい。 このメソッドを構成する単語であるget, userともに問題があると考えており、それぞれについて見ていきます。 Userとは具体的に何か これはよくある話で、まず自問すべきは「そのUserの定義を教えてください」である。 多くの業務システムではユーザ（アクタ）が複数存在しており、単に「ユーザ」と言った場合に指す対象が文脈によって異なることが多い。 これに対しては、Employee, Staff, Administrator, Visitor, Sponsorなど別の具体的な単語に置き換えられないかを検討することになる。 「ユーザ」が一意なシステムであればUserと名付けるのも妥当だろう（

id:Yamashiro0217さんのcheck_xxx がなんでダメなのか - Yamashiro0217の日記が面白かったので、少し掘り下げてみる。 第一印象は「いくら何でも例が恣意的すぎ。check_XXX言うな言いたいだけちゃうんか」だったが、現実は非情であり、こういうコードを押し付けられたこともあるので決して大袈裟ではなかった。 こういう名前が付く場合というのは、往々にしてメソッドの目的が定まっていないことが多い。そこに、is_valid_XXXのような名前を持ち込んで戻り値の型を規定してしまうことは有効なアプローチである。やる人は名前に関わらずどこでもexitするが、それは個別に教育していくしかない。 そんな訳でcheck_XXXは確かに避けたい名前だが、is_valid_x_stateやis_valid_user_about_xもやはりよろしくない。check_user_x_

この記事は「全くもってAdvent Calendarじゃない」と評判のUnoh Advent Calendarに参加しています。一日遅れたけど… こういう話は内輪の酒の席でいいじゃないのかと思うけど、「ZyngaJapanが閉鎖されるかも（現時点でそのような公式アナウンスはありません）」という話題が持ち上がった時に、目に付いた「ウノウもこれで終わりか」とか「ウノウの人たちどうなるの」みたいな論調には違和感が強いので、あえて過去を振り返ってみることにしました。 ウノウとZyngaJapanは別の会社だし、そもそもウノウという会社も時期によって大きく姿を変えてきたんだということを、勝手気ままに振り返ってみようというのがこのエントリの趣旨です。 第一期 創業から2006年ぐらいのイメージ。 「映画生活」「フォト蔵」のふたつを柱に、エンジニアが何でもかんでもやってたっぽい時期。自分はこの時の中のこ

kazeburoさんがCentOS6.2での事例を紹介されていますが、CentOS5系でもkernelを上げればRPS/RFSが使えるようになって、NICの負荷状況が劇的に改善します。 やり方は意外に簡単で、ELRepoからkernel-ml-2.6.35-14.2.el5.elrepo.x86_64.rpmを落としてきてインストール。 あとは、/boot/grub/menu.lstの設定をdefault=0にしてrebootすればOK。 $ uname -r 2.6.35-14.2.el5.elrepo ELRepoはNICのドライバなんかもいろいろ提供してくれるし、古いバージョンのRPMをarchiveで提供してくれて非常にいいですね（kernelの過去RPMはないのかな）。 RPS/RFSを有効にする設定はCentOS6と同様です。 # echo "f" > /sys/class/n

アドテク関係の人はあまりこういった各言語のコミュニティには姿を現さないイメージが強く、自分もわりとそういう流れに乗るような感じで、ここしばらくあまりオープンとは言えない日々を過ごしていました。 そんな中、YAPCで@myfinderさんが「平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用」と題してYAPCでトークして、しかもベストトーク賞3位というかっこいいことをやってのけてくれたことは大変な刺激になりました。 自分が憧れたのはこういう世界だったなーということを思い返している間に、ここ数年のことが思い出されてこういうスライドが出来上がりました。 東京に出てきてからの、この5年間でソーシャルゲーム（主にインフラ）や旅行代理店のサイト（デザインから開発・インフラまで）などもやってきましたが広告というのはなかなかに面白い分野です。 技術的には特異な要素も確かにありますが、と