タグ

ブックマーク / methane.hatenablog.jp (15)

  • タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ

    とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。(口頭で何時?と聞かれたら14時と答えるかもしれないけれど) つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題

    タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ
  • 構造化ログのフォーマット logfmt vs JSON lines - methaneのブログ

    構造化ログのプラクティスをあちこちで調べていたら、logfmtを推奨する記事を見つけたので調べてみました。 先に結論を言うと、JSON linesを使っておくのが良さそうです。 logfmt について logfmtとはスペース区切りで key=value を並べたフォーマットです。文字列にはクォートとエスケープによってスペースや改行を含められます。 at=info method=GET path=/ host=mutelight.org fwd="124.133.52.161" dyno=web.2 connect=4ms service=8ms status=200 bytes=1653 (logfmt から引用) あちこちで logfmt のリファレンスとして紹介されているのはこの記事です。 https://brandur.org/logfmt 発明されたのはどこか分かりませんが、流行

    構造化ログのフォーマット logfmt vs JSON lines - methaneのブログ
  • Python 3.15からデフォルトのエンコーディングがUTF-8になります - methaneのブログ

    Pythonがファイルを開くときなどに使われるエンコーディングはロケール(WindowsではANSIコードページ)依存でした。 Unixの世界ではどんどんUTF-8ロケールが一般的になっている一方、WindowsのANSIコードページはなかなかUTF-8になりません。 そのために、Unixユーザーが open(filepath) のようにエンコーディングを指定しないままUTF-8を仮定するコードを気軽に書いてしまって、Windowsユーザーがエラーで困るといった問題が発生します。 また、Windowsでもメモ帳(Notepad.exe)やVSCodeはすでにUTF-8をデフォルトのエンコーディングで使用しています。ANSIコードページがUTF-8になるのを待っていたらどんどん周りの環境から置いていかれ、レガシー化してしまいます。 Pythonがデフォルトで利用するエンコーディングをWind

    Python 3.15からデフォルトのエンコーディングがUTF-8になります - methaneのブログ
  • バグがあっても接触確認アプリをインストールしてほしい理由 - methaneのブログ

    3行サマリー: アプリではなくOSが接触履歴を取っている 今のアプリはOSの接触履歴をONにするだけ。バグがあっても使わなければ問題ない (特に東京では)今週の接触履歴が今後役に立つ可能性がある とうとう接触確認アプリが公開されました。これで今までよりも圧倒的に効率的に、陽性者の接触者に検査を受けてもらうことができるようになるかもしれません。ワクチンが開発されるまでの間、コロナと戦うための最大の武器になるかもしれません。 www.mhlw.go.jp しかし、Bluetooth が有効になってないと起動しない、利用規約に同意しないでアプリを終了しても同意したことになってる、などのリリース前の準備が明らかに不足してるであろう問題が報告され、炎上しています。 大前提として、これらのバグの責任はもちろんリリースした厚生労働省とその委託先の会社、そしてリリースを急がせた政府にあり、ベースとなったO

    バグがあっても接触確認アプリをインストールしてほしい理由 - methaneのブログ
  • len が関数になっている理由 - methaneのブログ

    http://d.hatena.ne.jp/pashango_p/20090702/1246550203 len()がリストのメソッドでないのも同じ理由です。 オブジェクト指向的に考えれば、リストのメソッドであるべきなのに、わざわざビルトイン関数にしたんです。 「オブジェクト指向的に考えれば、リストのメソッドであるべき」って感じで、オブジェクト信者はそれが正義みたいに考えちゃうんだろうね・・・ Pythonは合理主義。「オブジェクト指向的に○○」よりも、一貫した少なくて明確なルールを重視する。 len() が .length() メソッドだったらどうなるか。あるコンテナは .length() の代わりに、 .len() や .size() という名前を使ってしまうかもしれない。「サイズを取るメソッドは.length()」という 暗黙のルールができてしまい、そのルールが頭に入っていない人が一

    len が関数になっている理由 - methaneのブログ
    yuiseki
    yuiseki 2014/05/26
  • 次世代標準非同期I/Oフレームワーク asyncio (Tulip) - methaneのブログ

    Python Advent Calendar 2013 の4日目です。 Python 3.4 で標準ライブラリに追加される asyncio を触ってみます。 なお、 Tulip とは asyncio のリファレンス実装のプロジェクト名です。 背景 Python はよく非同期 I/O プログラミングに使われます。 Twisted, Tornado, gevent, eventlet, pyuv などのフレームワークがあります。 これらのフレームワークの問題点として、ライブラリの再利用性の低さが挙げられます。 たとえば Twisted 用に書かれた XMPP ライブラリは、そのままでは Tornado で 利用することができません。 この問題の解決策として、良くイベントループの乗り入れが行われます。 GUIアプリケーションに組み込む場合などを考えて、多くのフレームワークが最初から イベントルー

    次世代標準非同期I/Oフレームワーク asyncio (Tulip) - methaneのブログ
    yuiseki
    yuiseki 2013/12/04
  • Python で TDD してみる - methaneのブログ

    RSpec の入門とその一歩先へ がとてもよい記事だったので、 Python で写経させてもらいました。 https://github.com/methane/pytest-tut Ruby コミュニティと Python コミュニティの考え方の違いも見えて面白いと思います。 環境は Python 3.3 で、実行には py.test コマンドを使いましたが、 py.test の機能は特に使っていないので nose でもなんでも大丈夫です。 ファイルの作成 まずは空の実装とテストを作ります。 message_filter.py class MessageFilter: pass message_filter_test.py 最初のテストを書く py.test は .should といったメソッドを勝手に生やしたりはしません。普通に assert 文を書きましょう。 --- a/messege

    Python で TDD してみる - methaneのブログ
  • vagrant で ansible を試す - methaneのブログ

    Vagrant 1.2 から ansible がサポートされたということで、気になって試してみた。 まだ自作モジュールとかは作ってなくて、単に vagrant で使えるところまで。 vagrant-ansible vagrant plugin install ansible で vagrant の provision 機能として ansible が使えるようになる。 これを使うと vagrant に完結するのだが、これがメリットにもデメリットにもなる。 なにか playbook を作って vagrant 上で試そうと思ったら、 ansible-playbook コマンドが使えず、 Vagrantfile で指定した playbook に include してやらないといけない。 しかも ansible に渡せるオプションは vagrant-ansible がサポートしているものだけだ。 な

    vagrant で ansible を試す - methaneのブログ
  • テストコードがないコードだけが技術的負債じゃないよ - methaneのブログ

    私は「レガシーコード改善ガイド」を読んだことがないのですが、世間的に「テストコードがないコードが技術的負債」という認識が広まっているようです。 レガシーコード改善ガイドを批判するつもりは全くありませんが、たんにそのの中で使われている「レガシーコード」の定義に一致する物だけが技術的負債だという考えには反対します。 技術的負債とは、将来必要とされるメンテナンスコストの期待値だと思います。全てのコードは、メンテナンスを放棄するまでは技術的負債です。一方、メンテナンスコストを差し引いた上でそのコードが将来生み出す利益の期待値が、そのコードの資産価値だと思います。テストコードがないコードでも、利益を出すなら正の資産になります。 もちろん、資産価値をより大きくするために、技術的負債を減らすことは良いことです。技術的負債を下げる=メンテナンスコストを下げることで、テストはその有力な手段の一つです。他に

    テストコードがないコードだけが技術的負債じゃないよ - methaneのブログ
  • Chef-solo の代わりに fabric を使う - methaneのブログ

    Fabric は ssh 経由でリモートをゴニョゴニョするツールなので、デプロイツールとして見られがちですが、 cuisine など冪等な操作をサポートするライブラリを組み合わせれば手軽な構成管理ツールになります。 chef-solo に比べてターゲットとなるマシンへのインストールが不要なので vagrant と EC2 の Amazon AMI で同じように home ディレクトリを構築するようなスクリプトを書くことも可能です。 また fabtools を使えば、簡単に vagrant を対象にすることができます。 インストール: $ pip install fabric fabtool cuisine fabfile.py を作ります (サンプル): 使い方: $ fab vagrant package_upgrade setup_devtools # 開発マシンにいつもインストールし

    Chef-solo の代わりに fabric を使う - methaneのブログ
  • Flaskの闇 - methaneのブログ

    Merry, Xmas. Python advent calendar 2012 (#python_adv) 24日目の記事を、ミクパの再放送をBGMにお送りします。 今日は Flask のイケてないところとのつきあいかたを紹介します。 循環 import 問題 app.py 1ファイルだけの構成から成長してファイルを分け始めるときに突き当たるのが循環import問題です。 今まで1モジュールだった app.py を myapp/__init__.py にして、 view 関数を myapp/views.py の中で定義していきたいとします。 #myapp/__init__.py from flask import Flask app = Flask(__name__) import myapp.views #myapp/views.py from myapp import app @ap

    Flaskの闇 - methaneのブログ
    yuiseki
    yuiseki 2012/12/25
  • Pythonプログラムがメモリを大量に使っているとき - methaneのブログ

    もし想定以上のメモリを Python プログラムが消費しているのであれば、ループの中で循環参照が生まれていることや、回収不能オブジェクト(循環参照なうえに __del__ メソッドが存在するためにgcがどこから循環を切っていいのか判らないオブジェクト)が存在しないかを疑う。 import gc gc.set_debug(gc.DEBUG_LEAK) gc.disable() # 問題の処理 gc.collect() # 回収された循環参照や回収不能オブジェクトが表示される

    Pythonプログラムがメモリを大量に使っているとき - methaneのブログ
  • [python] 優れた Python プログラマを見分ける10+1の質問 - methaneのブログ

    お詫びと追記 この記事は 「優れたPerlプログラマを見分ける27の質問」の日語訳 - Islands in the byte stream を見て書いたものですが、僕が Perl について無知なのとタイトルに釣られたために、で元の問題の意図を汲み取れていませんでした。 その言語に取って重要な基事項を理解しているかのチェックリストとしては、以下の質問は不適切です。 お詫びに、真面目に Python の基事項に対するチェックリストをつくろうと思います。 質問 一般 バージョン管理をしているか テストを書いているか 1つ以上のオープンソースプロジェクトのコミッタであるか Python言語について list, tuple, dict, deque, heapq, bisect がどういう場面に適しているか説明しなさい ジェネレータの利点を説明しなさい Python 2 プロジェクトの Py

    [python] 優れた Python プログラマを見分ける10+1の質問 - methaneのブログ
    yuiseki
    yuiseki 2011/03/02
  • DebianでPythonを自分でビルドするときに入れておいた方が良い lib***-dev パッケージ - methaneのブログ

    libbz2-dev libbdb-dev libgdbm-dev libncurses5-dev libreadline5-dev libsqlite3-dev libssl-dev libz-dev これだけあれば、まず使わないようなものをのぞいて、標準ライブラリがビルドできるはず。

    DebianでPythonを自分でビルドするときに入れておいた方が良い lib***-dev パッケージ - methaneのブログ
    yuiseki
    yuiseki 2010/04/19
  • hgsvn - methaneのブログ

    subversionで管理されたオープンソースソフトのソースを持ってきて、修正&ローカルバージョン管理したい。svkが一般的なんだろうけど、リポジトリのコピーをローカルに作ってbrunch作ってってなんだか面倒くさそう。 そもそも複数のバージョン管理ソフトの使い方をいちいち覚えたくない。ローカルでは使い慣れたMercurialでバージョン管理しつつ、リモートのSubversionとも整合性を取りたい。そう思ってたらhgsvnってツールを見つけた。 hgimportsvnでsubversionリポジトリからcheckout、hgpullsvnでupdateできる。残念ながら今のところhgpushsvnでcommitはできないらしいけど、まぁ今触ってるソースはリポジトリへのコミット権無いし、パッチ作ってMLに投げるだけだから十分。

    hgsvn - methaneのブログ
    yuiseki
    yuiseki 2009/04/28
  • 1