タグ

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

  • タイムスタンプの精度を落とすときは切り捨てろ - 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のブログ
    yugui
    yugui 2024/04/21
  • 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のブログ
    yugui
    yugui 2013/03/20
  • Python の GIL 排除のために Software Transactional Memory が注目されている理由 - methaneのブログ

    あるいは、Pythonは参照カウント方式だからGILを排除できないという誤解に対する回答。 参照カウントってアトミックなインクリメント・デクリメントさえあればセマフォとか使わないでも並列化できるんで、パフォーマンスが滅茶苦茶落ちるということはない。参照カウントに対する修正が頻発するんで、同じオブジェクトを複数のスレッドが頻繁に操作したらコア同士で1次キャッシュの取り合いになって性能上がらないけど、現状よりはだいぶマシだ。 Python で GIL の除去が難しいのは、PythonJava よりも高級なアトミック性をもつ言語だからだ。例えば、 # d1, d2 は両方ローカル変数にある辞書. d1.update(d2) これは、Python VMレベルでは、 d1 の参照、 update メソッドの参照、 d2 の参照、メソッドの呼び出し、という処理になるんだけど、このうち dict.

    Python の GIL 排除のために Software Transactional Memory が注目されている理由 - methaneのブログ
  • ','.join() がなぜキモイのか - methaneのブログ

    Ruby厨とPython厨が平行線の議論をしていたので、まとめてみる。 オブジェクト指向的にキモイ? str.join() 処理での登場人物は2人いる。連結文字(区切り文字=separator)、連結される文字列の列だ。 この二つを比べると、「連結される文字列の列」が情報的に重要な場合がほとんどだろう。それを元に文字列の列が主役で連結文字はオマケと考えると、「joinが主役でない連結文字側のメソッドになる何てキモチワルイ」となる。 でも、別の視点で「連結する側とされる側」というように分類すると、「区切り文字 join 連結される文字」が素直な能動態で、「連結される文字列 (is) join(ed by) 連結される文字」だと無理やりな受動態になるので、''.join() の方が素直だ。 Rubyの場合は「配列が要素をjoinする」と配列が主体となっているので、後者の考え方はしにくい。なので

    ','.join() がなぜキモイのか - methaneのブログ
  • 技術力vsコミュニケーション能力 - methaneのブログ

    http://blog.gcd.org/archives/50605536.html 「システムを開発する技術者は、コンサルタントを目指すべし」くらいの勢いで主張されるかたも多いし、日経BP 等の Web ページを見ていると、技術者にとって必要なスキルはコミュニケーション能力だ、という主張ばかりが目立つ。確かにコミュニケーション能力は重要ではあるが、技術者の分はあくまで「技術力」であって、それをないがしろにしていいわけがない。 激しく同意。なんか、アンケートで「コミュニケーション能力」ってよく上位を占めてるけど、技術があるけどコミュニケーション能力が不足してるってあまりいない。*1 経営者、管理者の求めるコミュニケーション能力って、「嘘でも適当でも良いから判った気にさせてくれる説明をできる能力」?そんなのなんの役に立つの?管理者は、自分よりも担当者の方がよく判っている分野に対してでも自分

    技術力vsコミュニケーション能力 - methaneのブログ
  • 1