GitHub - ko-build/ko: Build and deploy Go applicationsYou 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
Goのインターフェース抽象度を美しく保つ為の思考 - 好奇心に殺される。
Go Goのインターフェース抽象度を美しく保つ為の思考 Goで抽象化を適切に、そして美しく保つ為の自分の考えやTipsを紹介します。 Overview とある場面でGoのinterfaceが持つ振る舞いの抽象度について議論があり、今回はそれをアウトプットしておきます。Go初心者でinterfaceを使った設計に苦手意識を持つ人向けです。 目次 今回の目次です！下記について自分の考えをお話しします！ 振る舞いの抽象化の度合いを意識する 抽象度をどこまであげるか 引数や返り値から発生する「抽象化の漏れ」 抽象度をあげる為の統合 Getter/Setterと抽象度 それではいってみましょう！ 振る舞いの抽象化の度合いを意識する 振る舞いをinterfaceとして定義していくのがGoの抽象化ですが、そもそも 抽象化は度合いのある概念です 。この度合いを意識しないと適切なinterfaceの設計は困
Goの正規表現が遅いって言う人がいたから、（速い）正規表現エンジンを作ったよ
はじめに 「Goの正規表現は遅い」 そんなふうによく言われていました。（最近はあまり聞かなくなりましたが） たとえば、↓の記事ではPythonの正規表現と比較して1.5倍くらい遅いという結果になっています： この話には「Goの正規表現は最悪時間が短くなるように安定したアルゴリズムを採用しているから」という回答があります： ↑の記事の比較では、GoがPerlに対して約10倍以上高速という結果が出ているので、「Goの正規表現は遅くない！はい、論破ー！」というわけですね。 なんでこうなるのかも↑の記事で説明されているとおりですが、Perl（などのバックトラック型エンジン）が入力長に対して指数関数的に実行時間が伸びていくのに対し、Goの正規表現エンジンは入力長に対して線形時間で実行時間が伸びていくアルゴリズムを採用しているため、入力が長くなると急激にGoのほうが有利になるからです： 一方で、入力が
Regexp::AssembleのGo実装 rassemble-go を作りました - プログラムモグモグ
PerlにはRegexp::Assembleという便利なライブラリがあります。 複数の正規表現を受け取り、それらのいずれかにマッチする正規表現を構築するためのライブラリです。 my $ra = Regexp::Assemble->new; $ra->add( 'ab+c' ); $ra->add( 'ab+\\d*\\s+c' ); $ra->add( 'a\\w+\\d+' ); $ra->add( 'a\\d+' ); print $ra->re; # prints (?:a(?:b+(?:\d*\s+)?c|(?:\w+)?\d+)) このライブラリのGo実装を金曜日の夜から書き始めて、ようやく形になってきたので公開しました。 package main import ( "fmt" "log" "github.com/itchyny/rassemble-go" ) func main
Big Sky :: Go に go:embed が入った。
Go 言語はシングルバイナリをウリにしたプログラミング言語です。バイナリファイルを1つポンと scp で転送すれば動くのでとても便利です。シングルバイナリとなると当然、画像や HTML といったアセットをバイナリに埋め込みたくなります。 Go 言語ではこれまで go-assets や go-bindata、statik というツールを使う事でファイルのコンテンツをバイナリ化し、変数からアクセスする様にしてきました。 しかしそれらには色々な流儀や OS 間でのまばらな動作など、ユーザにとって納得のいかない物がありました。昨日、Go 言語ではオフィシャルとしてこのファイル埋め込みをサポートする様になりました。Go 1.16 から使える様になります。 cmd/go: add //go:embed support · golang/go@25d28ec · GitHub +3 −3 src/cmd
RustのgRPCがGoよりも遅い？
夏のある日、GoのgRPCが、Rustよりも2倍早いという記事を見つけました。「おいおい、測定ミスだろ」と強がっていましたが、日々、不安は高まっていきます。真実の愛であれば、疑うことは許されませんが、エンジニアの言語への愛など、所詮、状況に応じて使い分けるような打算的な愛。確認してみました。 性能測定結果上記の記事と同じく、gRPCのサーバソフトウェアは、Goはgrpc-go、Rustはtonicのgreeterの性能を、gRPCのクライアントソフトウェアghzを使って、測定しました。ハードウェアは、AWSを利用し、サーバはc5a.8xlarge(32 vCPU/64 GiB)インスタンス、クライアントはc5a.16xlarge(64 vCPU/128 GiB)インスタンスを使いました。 1台のクライアントインスタンスは、同時に3,000個のgRPCクライアントを立ち上げ、合計で6,000
encodeURIComponentが世界基準だと誤解してた話
URLをいじくるプログラムをいじっていて、仕様がよくわからなくて悩んだのでまとめます。 2/23: 追試部分を追記 2018/7/14: JavaScriptのURLSearchParamsと、GoのPathEscapeについて追記 ことの経緯 HTTPとはなんぞやとか、GETとPOSTがどうの、それぞれでパラメータがどういう経緯でウェブアプリケーション(とかCGI)に渡って来るのかぐらいは知っていました。で、ウェブでXHRでGETリクエストを送る場合にはJavaScriptのencodeURIComponent()で各パラメータをエンコードして、&でくっつけて、URLの末尾に?で付与すればいいんだよね？と思っていました。こんな感じに。 これを受け取る側は、JavaScript(node.js)ならdecodeURIComponent()を使っているはずだ。ウェブの世界ではJavaScri
GoのWebアプリでクライアントIPを検出するrealipモジュール | おそらくはそれさえも平凡な日々
github.com/natureglobal/realip これはngx_http_realip_moduleと同様の挙動を、Goのhttpハンドラをラップするミドルウェアレイヤで実現するものです。 アプリケーションが信頼できるNginx等のproxy配下にあれば、X-Real-IP ヘッダなどをそのままクライアントIPとして採用すればよいのですが、クラウドのロードバランサー、例えばALBなどに直接Goのアプリケーションをぶら下げている場合、ALBはX-Real-IPを付けてくれないので、アプリケーション側でクライアントのIP検出をおこなう必要があります。そういったときにこのモジュールが有用です。 X-Forwarded-Forを見れば良いという話ではあるのですが、HTTPヘッダは簡単に偽装できますし、CDNを使っているなど多段になっているケースでも判別は地味に厄介です。ヘッダを付けてき
正しさとGo - Qiita
はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上
gRPC-WEB がもたらす我々の生活への変化 - tokuhirom's blog
gRPC-WEB がもたらす我々の生活への変化 gRPC-WEB が GA となった。これが我々の生活にどのような変化をもたらすのかについて考える。 従来の gRPC の課題 gRPC は google が公開している RPC 方式であり、java, golang などの言語で利用可能になっている。 gRPC は protocol buffers over HTTP/2 を基本としているため、通信が multiplexing されるし、schema 定義がきっちりされるのでクライアント側とのコミュニケーションがしやすい。 一方、protocol buffers はbinary であるためにbinaryの取扱が苦手な Browser JavaScript からのアクセスが難しいという問題があった。 grpc-gateway grpc-gateway という実装があって、これを利用すれば Br
Webスクレイピングマスターが教える「スクレイピング対策」@09/16追記 - Qiita
はじめに こんな記事書いてる人です。 Python Webスクレイピング テクニック集「取得できない値は無い」JavaScript対応@追記あり2/28 Python Webスクレイピング 実践入門 【毎秒1万リクエスト!?】Go言語で始める爆速Webスクレイピング【Golang】 スクレイピングが大好きで、スクレイピングするためにAWSやVPS、Docker、サーバーレスなどなど1から勉強したりする人です。（もちろん遊びの範囲で） 今回はそんな毎日スクレイピングしている自分がされたら嫌だなぁって思う現実的なスクレイピング対策を教えます。(Flash使えばいいじゃんとか極論はNG) ※この記事はスクレイピングの対策であって、SEO的に不利になったりすることもあります。ご注意を 趣味で一つのVPS環境で複数のドメイン・サイトを管理できるCMSを作ったりもしてます。 1 サイトマップ・RSSフ
今となって後悔しているkamiのこと - Qiita
クリスマス期間になると喜ぶ人もいれば悲しむ人もいる。そんな極端な季節の中で、自分が作ったguregu/kamiというWAFについて真面目に考えた。contextの正しい使い方や、kamiのAPIで後悔していることを晒そう。 kamiを作ったきっかけ まずはkamiの歴史について簡単に説明する。GunosyでアプリのAPIサーバーをRailsからGoに少しずつ書き直していたが、モノリシックだったmodelsとhandlersパッケージが大きくなりすぎて分かりにくくなってしまった。大きいパッケージを複数の小さなパッケージに分けようと思った。しかしユーザーのセッション情報などは様々なパッケージにどう共有したらいいでしょう？ 当時使っていたGojiというWAFでは、リクエストごとにEnvというmap[string]interface{}が付いていた。 これを使えば、どんなパッケジーにHTTPハンド
yoya-thumberのOSS公開に寄せて - SmartNews Engineering Blog
yoya-thumberとは SmartNewsは本日、yoya-thumberをOSSとして公開しました。yoya-thumberはSmartNews社内で利用されているサムネイル画像生成プロキシです。HTTPサーバーとして動作し、画像URLをリクエストとして受け取って縮小した画像を返します。 yoya-thumberが解決する課題 スマートニュースに対して頂くご意見の1つに、通信量が多すぎる、というものがあります。実際、私も1ユーザとして、通信量多すぎだろ、常識的に考えて……という感想を持っていました。 これにはいくつかの原因が挙げられますが、記事中の画像がスマホ向けに最適化されていない（場合がある）、というのも大きな問題の1つでした。例えば、見かけ上は小さな1枚の画像を表示するために、実は2MBの転送量を使ってしまっている、といったケースが存在していました。yoya-thumberを
ヒカルのGo 資料 Webアプリケーションの作り方
11. net/httpでWebサーバをたてる package main ! import ( "fmt" "net/http" "log" ) ! func hello(w http.ResponseWriter, r *http.Request) { //fmt.Fprintfでwに入るものがクライアントに出力される fmt.Fprintf(w, "Hello World!") } ! func main() { // アクセスのルーティングを設定する http.HandleFunc("/", hello) // portを指定して起動 err := http.ListenAndServe(":9090", nil) if err != nil { log.Fatal("ListenAndServe: ", err) } } 12. net/httpでWebサーバをたてる packag
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
