Go が他の多くの言語での非同期プログラミングよりも優れている理由 - Qiita
はじめに 非同期プログラミングと呼んでいるのは、ノンブロッキングIOと select, poll, epoll, kqueue のようなIO多重化を利用したネットワークアプリケーションを書くことです。 node.js で websocket 使ったチャットを書くとかそういうのです。 「他の多くの言語」とは、 Python (asyncio), node.js, C# などを想定しています。 Erlang や GHC なんかは Go に近いかも知れません。 async / await がない言語では、「コールバック地獄」や「deferred地獄」のような問題もありますがこの記事では扱っていません。 async / await のメリットを解説した他の記事を参照してください。 あとこの記事は主にランタイムに関する部分を扱っているので、「それは言語じゃなくて処理系の問題だ！」等の頓珍漢な揚げ足取
[翻訳] Why Go? - Qiita
(この記事は Dave Cheney さんの Why Go? の翻訳です。) 数週間前、友人に「Goに注目に値するのはなんで？」と聞かれました。 彼は私がGoに情熱を注いでいることを知っていましたが、なぜ私が他の人もGoを気にするべきだと思っているのかを知りたいようでした。 この記事は、私がGoを重要なプログラミング言語だと考える、3つの大きな理由を紹介します。 メモリ安全 個人としては、私もあなたもC言語でメモリリークも危険なメモリの再利用もしないプログラムを書く事ができるでしょう。しかし、40年以上の経験から、集団としてのプログラマーはC言語で信頼できるプログラムを書けない事がはっきりしています。 コードの静的解析、 valgrind, tsan (訳注: たぶん ThreadSanitizer), -Werror といったツールは10年以上前から使えますが、それらのツールが広く認知さ
![[翻訳] Why Go? - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d313f26f571d157c7c29164447df12a9a57ac14b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwV2h5JTIwR28lM0YlMjAmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWIzZTExMGY2MzBiNjk3YWJiOTc5NWMzMTY5YmE5ZWEy%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBtZXRoYW5lJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1lY2ZlNjYzN2FhMDBlNGVlNzYxMjk5ZmIyNTYyN2I5Yg%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gS0xhYiDmoKrlvI_kvJrnpL4%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Dccf027fbd87fba51b162b7132f21cfb9)
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 と呼んだほうが実態を表している
FAQ: 数値の比較を is ですると一貫性がないのはなぜ？ - Qiita
x と y は別々に作られた、別々のリストオブジェクトです。なので、 x is y は False になりますし、 x を変更しても y には影響しません。 一方、 z は x と同一のオブジェクトを参照しています。なので x is z は True になりますし、 x (が参照しているリストオブジェクト)を変更すると当然 z も同じように変化します。 整数型は immutable オブジェクトが示す値が、オブジェクトを生成したときに決まり、その後変化しないようなオブジェクトを immutable といいます。 整数は immutable です。次のサンプルコードを見てください。 y = x した直後は、 x と y は同じ 42 を表すオブジェクトを示しているので x is y は True でした。 x += 1 すると、 x には 43 を表す別のオブジェクトが代入されます。なので
Github issue で質問してはいけない - Qiita
この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。 英語版はこちらです Why you must not ask questions on Github issues 現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。 2023-06-14 追記 TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。 背景 Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでデ
Python のリファクタリングでイケてないコードを別に美しいオブジェクト指向設計ではない普通のコードにする方法 - Qiita
Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その１ その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
コネクションプールのチューニング - Qiita
TL;DR 負荷の変動が激しい環境でコネクションプールの設定のチューニングをさぼるためによくやるハックを紹介します。 問題 Go から https や mysql など外部のリソースにアクセスする場合、一般的にコネクションプールを使うことになります。 コネクションプールは、利用が終わった (idle) コネクションをプールしておき、次に使いたい時に再利用するものです。 (idle コネクションのプールを以後 free pool と呼びます。) ほとんどのコネクションプールの実装には、 idle なコネクションの最大数を制限するオプションがあります。 また、利用中の (active) コネクションと idle なコネクションを合計した全体を制限するオプションを持つものもあります。 例えば net/http パッケージの Transport は MaxIdleConnsPerHost というフ
loggingについて話そう - Qiita
この記事は Let’s talk about logging の翻訳です。 Nate Finch による Go Forum への投稿で始まったスレッド を見てこの記事を書くことにしました。 この記事は Go を対象にしていますが、あなたのいままでのやり方を振り返ってみたら、同じ考え方がより広く適用できると思います。 なんでこんなに足りないの？ 訳注: "Why no Love?" を、「（愛されてないから）機能が足りない」というニュアンスで解釈しましたが、自信が無いです。 Go の log パッケージ はレベル付きのロギングを提供していません。なので手動で debug, info, warn, error のようなプレフィックスを書く必要があります。 また、 Go はパッケージごとにログの出力レベルを制御する方法も提供していません。 比較対象としてサードパーティーのロギングライブラリを見て
Go の expvar パッケージを使ってアプリケーションのメトリクスを公開する - Qiita
expvar パッケージは手軽にメトリクスを公開するのに使えて便利なのですが、複数の値を公開するための例があまり公開されてなくて分かりにくかったので書いておきます。 expvar.Map を使う mychat というチャットアプリを作ってると仮定して、送受信メッセージ数と、同時接続数を公開してみます。 /debug/vars を見た時に、次のような形でメトリクスを公開します。 ... mychat: { "conns": 42, "msg_recv": 10480, "msg_sent": 88946 }, ... package metrics import ( "expvar" ) var ( Map = expvar.NewMap("mychat") // expvar.NewXxx() は直接公開するメトリクスを作成する。 Conns = new(expvar.Int) // Ma
作業マシンとしてのGCEプリエンプティブインスタンスとAWSスポットインスタンスの比較 - Qiita
ベンチマークや重いソフトウェアのビルドなど、ノートPCには適していない作業をするマシンとして、いままで AWS のスポットインスタンスを使っていました。 しかし5月に GCE のプリエンプティブインスタンスが出て、試してみたところ予想以上に快適でした。 こういったスポットでの作業環境としてのプリエンプティブインスタンスのメリットを紹介していきます。 起動が早い スポットインスタンスは、入札してから実際にマシンが起動するまでのタイムラグが5分程度ありました。 プリエンプティブインスタンスは、通常の Compute Engine のインスタンスのオプションという扱いなので、入札という手順が存在せず、1分程度で起動できます。 設定が簡単 AWS だと新しいインスタンスを使おうとすると VPC の設定が必要だったり、セキュリティグループの設定をしないと起動した２台のマシン間での通信すらできなかった
エラーを検査する - Qiita
NOTE: この記事は Inspecting Errors を翻訳したものです。 原文に従い、 Creative Commons ライセンスで公開します。 error インターフェイス型の値を返す関数の一般的な契約は、呼び出し側はその error をチェックする前にそれ以外のいかなる戻り値も利用してはいけないというものです。 多くのケースにおいて、関数が返した error 値は呼び出し元にとって不透明であるべきです。 error が nil かどうかチェックすることで呼び出しが成功したかどうかを知ることができ、そしてそれ以上のことはしません。 少ないケースにおいて、主にネットワークなどプロセス外の世界とやりとりする場合に、呼び出し側がエラーの種別を調べて、操作をリトライするべきかどうかを決める必要があります。 パッケージ作者に対して、呼び出し側がエラーの型を判別して利用できるように返すエラ
Python 3 で少しだけ便利になった datetime の新機能 - Qiita
datetime モジュールは Python の標準ライブラリの中でも、使用頻度が高い割に罠が多かったり使い方が難しかったりする、あまりイケてないモジュールだと個人的に思っています。 そんな datetime モジュールですが、 Python 2 のプロジェクトを Python 3 に移行した時に大分コードを整理できてちょっと感動したので紹介しておきます。 unixtime との相互変換 unixtime から datetime.datetime への変換は、 ローカルタイムなら.fromtimestamp() で、 UTC なら .utcfromtimestamp() 関数で行います。 >>> import time >>> from datetime import datetime >>> now = time.time() >>> now 1415542873.099776 >>>
Go の Prepared Statement は Connection を気にせず使える - Qiita
コネクションプールと prepared statement database/sql は、トランザクションを除いて基本的にコネクションをユーザーに見せず、全ての操作をコネクションプール sql.DB を通して行う設計になっています。 コネクションプールと言えば、 prepared statement の実装が気になります。 prepared statement は基本的にコネクションに紐付いていて、 プレースホルダ付きのクエリを投げてコネクションローカルの「ハンドル」を貰う 「ハンドル」にパラメータを送ってクエリを実行する 「ハンドル」を閉じる（あるいはコネクション自体を閉じる） という流れになるので、コネクションプールと組み合わせて使う場合には、 毎回ハンドルを取得＆開放する (１クエリに３回通信が発生) ハンドルを開放しない (DBサーバー側のリソースを食いつぶす) コネクションごとに
Python の logging を設定するときは disable_existing_loggers に注意 - Qiita
ロギングの環境設定 という公式ドキュメントにも警告があったのですが、思いっきりハマってしまったので記事にしておきます。 Python の logging モジュールは、 addHandler() などのメソッドを呼び出して構成する以外に、 ini 形式の設定ファイルを元に構成する logging.config.fileConfig() や、 dict 型の設定情報を元に構成する logging.config.dictConfig() を使って構成することができます。 import logging.config logging.config.dictConfig({ 'version': 1, 'handlers': { 'default': { 'class': 'logging.StreamHandler', 'level': 'DEBUG', 'stream': 'ext://sys.
最速最強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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
