You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Easy to use and install. No dependencies or external files are needed — just the binary you can download further down the page. Multiple cursors. Common keybindings (Ctrl-s, Ctrl-c, Ctrl-v, Ctrl-z, …). Keybindings can be rebound to your liking. Sane defaults. You shouldn't have to configure much out of the box (and it is extremely easy to configure). Splits and tabs. nano-like menu to help you rem
Go書いててなんとなく見えてきた Goでやっちゃいけないパターン WAF導入してらくらくWebアプリ WAF自体が現在群雄割拠状態。 WAF毎にハンドラインターフェースが違うので既存コードつなぐにはラッパーが必要。 どのWAFもLL言語に比べるとまだまだフィーチャーの網羅範囲が狭い。 なのでもちろんLL言語ほど楽には書けないことが多い。 リフレクション使いまくりでトータル性能はLL言語並みに遅いのもある。 Go1.7のcontextパッケージの導入で標準のHTTPハンドラが復権する可能性があり更に荒れる予想。 追記: 楽できるのを期待してWAFを導入するの「やっちゃいけない」とまでは言い過ぎだったかもしれないけれど例のsqlでPrepareを正しく使えていないで性能出なかった件とか、当面WAFを使うなら自分で概ね中身を理解して使う覚悟が必要。 構造体メソッドにロジックを詰め込む Goの思想
クラウドとオンプレミスを活用した 月間500億件を処理する 広告配信システムの裏側とは? - BI-Direct Access for AWS 事例 - ...
こんにちは。開発部の平田です。 今回は、PHP製のWeb APIをGoに移植するプロジェクトでアプリケーションの情報やエラーを出力する為のLoggerを検討した際に、uber-go/zapというライブラリが公表しているパフォーマンスがその他ライブラリと比べて大分良かったので、どこでパフォーマンスの差を出しているのか、そのアプローチを簡単に紹介したいと思います。 Zap 初めに、簡単にzapの紹介をしておくと今年の2月にUberから公開されたまだ比較的新しいプロダクトです。その為開発ステータスはBetaの段階で出力もJSONしか対応していませんが、Github上で800以上のスターが付いており注目されているプロジェクトとなっています。 「Fast, structured, leveled logging in Go」とあるように、構造化されたログを出力するためのライブラリで、標準のlogのよ
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである. 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドがon-CPUで時間を消費しているかoff-CPUで時間を消費しているかを理解するところから始まる.on-CPUの場合はそれがuserモードかkernelモードかを特定し,さらにCPUプロファイリングによってどのcode pathがCPUを消費しているのかの分析に向かう.off-CPUの場合はI/OやLock,pagingといった問題の分析に向かう. Flame Graphはon-CPUでのパフォーマンスの問題が発覚した時に行うCPUプロファイリングを助ける.どのcode pathがボトルネックになっているのかを1つのグラフ上で理解できる.本記事ではFlame Graphとは何か? なぜ必要なのか? を解
You can find (just about) anything on Medium — apparently even a page that doesn’t exist. Maybe these stories will take you somewhere new?
Goらしいコードの書き方(ミニ) Go 1.6 Release Party 17 February 2016 鵜飼文敏 Fumitoshi Ukai Google Software Engineer - Chrome Infra team 巻末付録「Goらしいコードの書き方」を書きました。 Ebook is now available! 2 Go 1.6 言語仕様の変更 -> なし! Goらしいコードの書き方は基本的にかわっていない。 golang.org/doc/effective_go.html github.com/golang/go/wiki/CodeReviewComments 3 Effective Go Go is a new language. Although it borrows ideas from existing languages, it has unusual
Welkom bij Pelletkachels.nl, jouw ultieme bron voor alles wat met pelletkachels te maken heeft! Maar we zijn meer dan alleen een platform voor het bespreken van warmtebronnen. Bij Pelletkachels.nl geloven we dat het delen van kennis en ervaringen over bedrijven en gebeurtenissen ook essentieel is voor het creëren van een betrokken en geïnformeerde gemeenschap. In dit blog duiken we dieper in de we
GoCon 2015 Winterでは、社内での取り組みとしてExcelのパースの時間のロスを避けるために、簡易データ構造を使ってMessagePack + LZ4で圧縮して高速化したことを紹介しました。それでも十分速くはなったのですが、LTで発表のあったシリアライズ系のライブラリのベンチマーク比較でFlatbuffersが最速だったので、ちょっと試してみました。 ↑のグラフは、こちらのベンチマークの結果をExcelでグラフにしてみたものです。Gobがダントツ遅かったのでそちらは振りきっています(Gobに合わせると他のものの比較がしにくくなるので範囲を狭めた)。GoConで発表した通り、今MessagePackを使っているのはデータのキャッシュです。作成に多少がかかっても、後の読み出しが速い方がトータルとしてはうれしい領域なので、Unmarshalが最速のFlatbuffersに俄然興味を
Let’s Encrypt TL;DR Let’s EncryptのベースのプロトコルであるACMEを理解する. まずACMEをベースとしたCAであるboulderをローカルで動かす.次にACMEのGo言語クライアントライブラリであるericchiang/letsencrypt(非公式)を使い実際にboulderと喋りながら証明書発行を行い,コードとともにACMEが具体的にどのようなものなのかを追う. はじめに 証明書というのは面倒なもの,少なくともカジュアルなものではない,というイメージが強い.それは有料であることや自動化しにくいなどといったことに起因している(と思う).そのようなイメージに反して近年登場する最新の技術/プロトコルはTLSを前提にしているものが少なくない(e.g., HTTP2). このような背景の中で登場したのがLet’s Encryptと呼ばれるCAである.Let’s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く