タグ

ブックマーク / qiita.com/methane (12)

  • __init__.py を省略してはいけない - Qiita

    Python 3.3 から __init__.py を省略して良いと思っている人が多いですが、 省略しないでください。 なぜ勘違いが起こったのか Python 3.3 から、 PEP 420 で Implicit namespace package が追加されました。 Namespace package とは普通の package ではありません。 特殊な用途のもので、ほとんどの人にとっては 知る必要すらない ものです。 どうしても知りたければ、上の PEP 420 と packaging guide を読んでください。 __init__.py を省略する弊害 普通の package で Implicit namespace package を乱用すると弊害があります。 import が遅くなる 通常の package とは違うので import が package 内のモジュールを探すの

    __init__.py を省略してはいけない - Qiita
  • MySQLで大量のシンプルなクエリを高速化する - Qiita

    どんなに軽いクエリでも、たとえばWebサーバーとMySQLの間のRTTが5msあって20クエリを実行したらRTTだけで100msかかってしまいます。 たくさんのデータをinsertするときは bulk insert (VALUES の後に複数の行を書くクエリ) を使うテクニックは有名です。しかしこのテクニックは次のような場合に使えません。 複数のテーブルに1行ずつINSERTしたい 複数のUPDATEやSELECTをまとめたい たとえば弊社のある案件で次のような場面がありました。 新規ユーザー作成時に大量のテーブルにINSERTしたい ログイン時に大量のテーブルにSELECTしたい こういった場面を高速化するために multiple statements と multiple result sets を利用しました。 Multiple Statements 複数のクエリを ; で区切って一

    MySQLで大量のシンプルなクエリを高速化する - Qiita
  • ログを gzip で圧縮しているなら zstd を導入しよう - Qiita

    はじめに zstd コマンド(zstdless, zstdcat, unzstd なども)は gzip にも対応しています。特にデコードは拡張子を見て自動で gzip と zstd を切り替えてくれるので、 gzip 圧縮されたログと zstd 圧縮されたログが混在している環境でも透過的に扱うことができます。 なので gzip から zstd への切り替えは次のように段階的に進めることができます。 zstd コマンドツール群のインストール 圧縮されたログを扱うときに zstd を使い始める 圧縮フォーマットを zstd に切り替える 性能比較 Debian 9.3 で gzip 1.6 (aptでインストールしたもの) と zstd (1.4.0) を比べてみます。 対象となるファイルは ltsv でゴチャゴチャとアプリの情報を混ぜた重めの apache のアクセスログです。 (5,367

    ログを gzip で圧縮しているなら zstd を導入しよう - Qiita
  • http.ListenAndServe() をインターネットに公開してはいけない - Qiita

    http.ListenAndServe() を使ったサーバーをプロダクションに投入していたのですが、海外からのアクセスが多くなったころにリソースリークが発覚しました。 ListenAndServeのドキュメント ListenAndServeのソースを見るとこうなっています。 func ListenAndServe(addr string, handler Handler) error { server := &Server{Addr: addr, Handler: handler} return server.ListenAndServe() } addr, handler 以外は http.Server のnil値がそのまま使われている事がわかります。この構造体にはいくつかのタイムアウト値がありまが、nil値で初期化されるとタイムアウトなしの状態になってしまいます。 Server型のドキ

    http.ListenAndServe() をインターネットに公開してはいけない - Qiita
  • Python 開発者は -W default オプションを使おう - Qiita

    Python はデフォルトで多くの警告を表示しません。これはPython開発者ではないエンドユーザーが警告を見た時に混乱するのを防ぐためです。 デフォルトで ignore される Warning は次のとおりです。 (ref: https://docs.python.org/3/library/warnings.html#default-warning-filters) DeprecationWarning PendingDeprecationWarning ImportWarning BytesWarning ResourceWarning これらの warning を Python 開発者が表示しないと、せっかく使っているライブラリが長期間 Deprecation 期間を設けていてもその Warning に気づかないとかいう事が起きます。 また、 warning システムは同じ場所から

    Python 開発者は -W default オプションを使おう - Qiita
  • Rubyist が pyenv を使うときに知っておいてほしいこと - Qiita

    はじめに 機械学習ブームなどにより、 Python を触り始める Rubyist が増えてきたと思います。その際に問題になりやすいのが環境構築です。Rubyだと rbenv がデファクトスタンダードになっているのに、なぜか Python には pyenv に否定的な意見が多いんですよね。 私は pyenv を使っていますし、便利だと思っています。また、 Ruby は殆ど使わないのですが、RubyPythonのツールスタックの違いについても調べました。 (参考: gem, bundler と pip, venv の比較) その視点から、 Rubyユーザーが自分でpyenvの使い方を自分で決める上で知っておいた方が良いだろうなと思う RubyPython の環境の違いをまとめてみます。 tl;dr 丁寧に解説しても、「Python使うにはこんな長い記事を読まないといけないの」とすぐに否

    Rubyist が pyenv を使うときに知っておいてほしいこと - Qiita
  • Go が他の多くの言語での非同期プログラミングよりも優れている理由 - Qiita

    はじめに 非同期プログラミングと呼んでいるのは、ノンブロッキングIOと select, poll, epoll, kqueue のようなIO多重化を利用したネットワークアプリケーションを書くことです。 node.js で websocket 使ったチャットを書くとかそういうのです。 「他の多くの言語」とは、 Python (asyncio), node.js, C# などを想定しています。 Erlang や GHC なんかは Go に近いかも知れません。 async / await がない言語では、「コールバック地獄」や「deferred地獄」のような問題もありますがこの記事では扱っていません。 async / await のメリットを解説した他の記事を参照してください。 あとこの記事は主にランタイムに関する部分を扱っているので、「それは言語じゃなくて処理系の問題だ!」等の頓珍漢な揚げ足取

    Go が他の多くの言語での非同期プログラミングよりも優れている理由 - Qiita
  • [翻訳] Why Go? - Qiita

    (この記事は Dave Cheney さんの Why Go? の翻訳です。) 数週間前、友人に「Goに注目に値するのはなんで?」と聞かれました。 彼は私がGoに情熱を注いでいることを知っていましたが、なぜ私が他の人もGoを気にするべきだと思っているのかを知りたいようでした。 この記事は、私がGoを重要なプログラミング言語だと考える、3つの大きな理由を紹介します。 メモリ安全 個人としては、私もあなたもC言語でメモリリークも危険なメモリの再利用もしないプログラムを書く事ができるでしょう。しかし、40年以上の経験から、集団としてのプログラマーはC言語で信頼できるプログラムを書けない事がはっきりしています。 コードの静的解析、 valgrind, tsan (訳注: たぶん ThreadSanitizer), -Werror といったツールは10年以上前から使えますが、それらのツールが広く認知さ

    [翻訳] Why Go? - Qiita
  • Python 3の各種エンコーディングについて - Qiita

    Python 2 に比べるとずっと楽になったものの、環境によっては Python 3 で予期せぬ UnicodeError に遭遇することがあります。 Python 3.6 時点での、 Python の各種エンコーディングの扱いを整理してみます。 Python のエンコーディング filesystem encoding (sys.getfilesystemencoding()) 主にファイルパスに使うエンコーディングですが、コマンドライン引数にも使われます。 (そうでないとファイルパスをコマンドライン引数に渡したときに困る) また locale が関連するので、実際にはそれ以外にも glibc とかと連携するときに使われます。 Python 2 時代の名残りでしょうが、今では filesystem encoding というより system encoding と呼んだほうが実態を表している

    Python 3の各種エンコーディングについて - Qiita
  • Python のリファクタリングでイケてないコードを別に美しいオブジェクト指向設計ではない普通のコードにする方法 - Qiita

    Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その1 その2 その3 これを Python でやってみます 元のコード 元の Ruby 版をできるだけ真似してみます。テストは py.test を使います。 #ordersreport.py from collections import namedtuple Order = namedtuple("Order", "amount placed_at") class OrdersReport: def __init__(self, orders, start_date, end_date): self.orders = orders self.start_date = start_date self.end_date = end_date def total_sales_within

    Python のリファクタリングでイケてないコードを別に美しいオブジェクト指向設計ではない普通のコードにする方法 - Qiita
  • エラーを検査する - Qiita

    NOTE: この記事は Inspecting Errors を翻訳したものです。 原文に従い、 Creative Commons ライセンスで公開します。 error インターフェイス型の値を返す関数の一般的な契約は、呼び出し側はその error をチェックする前にそれ以外のいかなる戻り値も利用してはいけないというものです。 多くのケースにおいて、関数が返した error 値は呼び出し元にとって不透明であるべきです。 error が nil かどうかチェックすることで呼び出しが成功したかどうかを知ることができ、そしてそれ以上のことはしません。 少ないケースにおいて、主にネットワークなどプロセス外の世界とやりとりする場合に、呼び出し側がエラーの種別を調べて、操作をリトライするべきかどうかを決める必要があります。 パッケージ作者に対して、呼び出し側がエラーの型を判別して利用できるように返すエラ

    エラーを検査する - Qiita
  • 最速最強Webサーバーアーキテクチャ - Qiita

    POST /post HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar 1行目は request-line で、 method URI HTTP-version の形をしています。URIはホストを含めた絶対URIの場合と、ホストを含めない絶対パスの場合がありますが、絶対パスの方が一般的です。 2行目から空行までが request-header です。各行は field-name: field-value の形をしています。 field-name は大文字小文字を区別しません。 request-line から request-header とそれに続く空行まで、改行は CR LF になってます。Windowsでよく見る改行コードですね。 meth

    最速最強Webサーバーアーキテクチャ - Qiita
  • 1