Big Sky :: Go に Fuzz testing が入った。
みなさん Fuzz testing ってご存じでしょうか。 人間が作る物は必ずといっていいほどバグが存在します。そしてそのコードをテストする人間も必ずバグを見逃します。 想定していなかった境界値テスト等、人間には先入観という物があり、それが邪魔をして簡単にバグを見逃します。昨今、この様な誰も気付かなかったバグの隙間を突く様な脆弱性が沢山見つかっています。 物によっては重大インシデントに発展する物まであります。 こういった人間では想定できない様なバグを見付けてくれるのが Fuzz testing です。Fuzz testing を実施する事で、ソフトウェアは頑丈になり安全にもなりえます。 本日、Go の master ブランチに Fuzz testing の機能が入りました。 [dev.fuzz] Merge remote-tracking branch 'origin/dev.fuzz'
1ms 以下のリアルタイムオブジェクト検出/画像処理を目指して Goの配信サーバサイドで通知ぼかしを実装してみたこと - Mirrativ Tech Blog
こんにちは ハタ です。 今回は以前iOSのクライアントサイドで実装していた通知ぼかし機能をサーバサイド(配信サーバ)上に再実装した事を書きたいなと思います 今回はかなり内容を絞りに絞ったのですが、長くなってしまいました、、 目次機能があったのでつけてみました、読み飛ばして読みやすくなった(?)かもしれません 目次 目次 通知ぼかし機能とは サーバサイド通知ぼかし プロトタイプの実装 苦労の始まり その1 画像処理速度 苦労の始まり その2 データ量 さらなる計算量の削減を求めて さらなる最適化へ Halide の世界へ 簡単な halide の紹介 苦労の始まり その3 いざ リリース リリースその後 We are hiring! 通知ぼかし機能とは 通知ぼかし機能は、ミラティブ上での配信中に写り込んでしまったiOSの通知ダイアログをダイアログの中身を見えないようにぼかし処理をしてあげる
WebAssemblyアプリ開発で最も使われている言語はRust C++、AssemblyScript、Blazor、Goが続く
調査は今年の6月に行われ、196カ国（米国21.8％、ドイツ9.1％、中国9.1％など）に分散した250人のITエンジニアが回答。 WebAssemblyアプリケーションのコードを記述するプログラミング言語として何が使われているかとの調査では、Rustが最も多く、C++、AssemblyScript、Blazor、Goの順に使われていることが示されました。 Rustは比較的容易にWebAssemblyが生成できることがWebAssemblyでの人気の理由でしょうか。4位のBlazorは少し意外ですが人気があるのですね。 WebAssemblyの利用目的では、Webアプリケーション開発（Web Development）が最も多く、続いてゲーム開発、サーバレス、コンテナ化（Containersation）、オーディオ／ビデオ処理、科学計算、IoT、AIの順となっています。
GitHub - google/wuffs: Wrangling Untrusted File Formats Safely
Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. This includes very large C/C++ projects, such as popular web browsers and operating systems (using that term to include desktop and mobile user interfaces, not just the kernel). Wuffs the Library is available as transpiled C code. Othe
モンストの新機能開発に活用、ミクシィが「Go」の採用に踏み切ったワケ
Go、Rust、Elixir――。21世紀になってから生まれた新しいプログラミング言語を採用する企業が、日本でも少しずつだが増えている。PythonやRubyなどのスクリプト言語のように手軽にアプリケーションを開発できたり、SwiftやKotlinのようにスマートフォンアプリケーションをすぐに開発できたりするわけではないが、システムを開発するプログラミングでは抜群の適性を発揮することも少なくない。本特集はそんな新世代のプログラミング言語の使いどころを、事例に基づいて解説する。第1回は「Go」だ。 Goは2009年に米Google（グーグル）が発表した比較的新しいプログラミング言語だ。C／C++の代替として開発され、コンパイルが速く、並列処理の記述が容易という特徴がある。言語仕様がシンプルなので覚えなければならないことが少ないのもメリットだ。 さらにGoは、C／C++で問題だったメモリー関連
Go の Web フレームワーク Gin にちょっとコミットしました
はじめに この記事は Go Advent Calendar 2020 18 日目の記事です。 普段 Gin をよく使用しているのですが、ふとコミットしたくなり issue を漁っていたら運良くコミットできました。 修正内容はちょっとしたものですが、私の PR がマージされるまでにどんなことをしたのかまとめたいと思います。 Gin とは Gin は最もスター数の多い Go の Web フレームワークです。 参考：Top Go Web Frameworks Django や Ruby on Rails のようなリッチなものではなく、必要最低限の機能が備わったシンプルなフレームワークとなっています。 package main import "github.com/gin-gonic/gin" func main() { r := gin.Default() r.GET("/nyan", func
Go Quiz Advent Calendar【10日目】 - iotaのカラクリ編 - 焼売飯店
こちらは Goクイズ Advent Calendar 2020 - Qiita の10日目の記事です。 問題 今回は、皆さん大好きなiotaの問題です。 package main import "fmt" const ( X = 0 A, B, C = iota, iota + 1, iota * 2 D, _, E _, F, _ G = iota + iota ) func main() { fmt.Println(D + E + F + G) } さて、答えはどれでしょう？ compile error 12 18 24 解答 https://play.golang.org/p/6c_X0VSSul4 正解 スクロールした先にあります！ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ 正解は、3の 18 です。 解説 iotaについて考える時、気にしないとい
Goのデバッグ環境 on VSCode | フューチャー技術ブログ
はじめにこんにちは。TIG/DXユニットの富山です。 私の使用するテキストエディタはVim一択でしたが、最近はVSCodeに浮気気味です。（言わずもがな Vimプラグインは入れています） 今回はVSCodeでGo言語用のデバッグ環境をテーマします！ 環境構築前提条件: VSCodeがインストール済であること Goがインストール済であること Step 1：プラグインのインストールGoogleが公開しているVSCode用のGoプラグインである、Go for Visual Studio Codeをインストールします。（2020年6月に開発管理がMicrosoftからGoogleのGo開発チームへ移管されました）。 インストールが終わったら、Goプラグインに必要な各種ツールをインストールしていきます。 コマンドパレットを開く（Windows: Ctrl + Shift + p / Mac: Com
TinyGoで始める組み込みプログラミング - スイッチサイエンス 開発者ブログ
144labの入江田です。 今回TinyGoという素敵なプロダクトを試してみました。 TinyGoとは TinyGoは本家Go言語の組み込み向けのサブセット版。 本家Go言語はPOSIX-OSに対する機能依存が大きく、リッチなランタイムを持っています。その為、本来はOSを持たない組み込み用途には不向きでした。 TinyGoはPOSIX-OSに依存する機能を簡易的な実装で代用しつつLLVM（コンパイラを作る為のフレームワーク）を使って組み込み向けアーキテクチャをサポートするGo言語のコンパイラです。 つまりサポートするCPUアーキテクチャはLLVMがサポートするものを前提にしています。 リポジトリ https://github.com/tinygo-org/tinygo ドキュメント https://tinygo.org/ サポートアーキテクチャ ARMのCortex-M0系 WebAsse
Go + gRPC でC言語プロジェクトのビルドを早くした話 - Qiita
この記事は Go2 Advent Calendar 2018 の 24 日目の記事です。 私は組込ソフトエンジニアで、職場にはレガシーな環境が多く残っています。 そして、ビルドツールが古かったりして 2MB にも満たないバイナリを作るのに数十分かかったりしています。 時間がかかる主な理由は、複数 CPU による分散コンパイルが実現されてない(場合が多い)から、です。 ということで、 Go 言語の goroutine を用いて CPU をなるべく使う形のタスクランナーを書くことが多いわけですが、最近は gRPC 経由で複数のマシンを活用する分散ビルド環境を作っているのでまとめました。 動くサンプルを紹介しつつ、徐々に分散ビルドになるように段階的に進めていきます。 分散処理のイメージ 実際に仕事で使っているプロジェクトの分散 build は以下の画像のようになります。 1 CPU で普通にビル
The Go low-level calling convention on x86-64
Note The latest version of this document can be found online at https://dr-knz.net/go-calling-convention-x86-64.html. Alternate formats: Source, PDF. Introduction This article analyzes how the Go compiler generates code for function calls, argument passing and exception handling on x86-64 targets. This expressely does not analyze how the Go compiler lays out data in memory (other than function arg
RailsコードをGoで書き直して、FFIを使ってRailsからGoの関数を実行させて実行時間を5%以下に短縮させた - Clueit Developersブログ
こんにちは、Webチームの柴山（@shikeapp0909）です。 今回は、弊社Webアプリ「mamanoko」の一部に処理高速化のためにGoを導入したので、どのように導入したかをご紹介しようと思います。 Railsで開発しているWebアプリ内にどのようにGoを取り入れたのか、実際のコード例を交えながら解説していきたいと思います。 なぜRails環境にGoを導入したのか そもそもなぜGoを導入することになったのかと疑問に思われるかと思います。 mamanokoはメディアサービスのため、ライターさんに文章を書いていただいています。複数のライターさんがおり、文章量も膨大になるため、表記揺れや誤字がどうしても出てきてしまいます。 そのため、文章校正が必要であり、以前からその機能を提供していました。 しかしこの文章校正の機能は記事の文章に対して表記揺れなどチェックしたい単語を総なめする処理をしてい
C言語でプログラミングする際の覚書（Notes on Programming in C） - YAMAGUCHI::weblog
はじめに こんにちは、Go界のシャールト・コプリーです。気がついたら最後のエントリから3ヶ月も経ってました。 Goを始めると「なんでこういう書き方になってるんだろう」とか、「そもそもなんでこういう仕様になってるんだろう」とか思うことがちらほらあると思います。これは大いにGoの作者の一人であるRob Pike氏の思想に依るところがあるのが見受けられます。彼のプログラムに対する考え方が25年前に公開され「Pike Style」として知られていますが、いまもその考え方は大きくは変わっていないと思われます。せっかくなので翻訳しました。本文はC言語に関する文章ですがその本質は言語に依らないものだと思います。 Notes on Programming in C （追記）25年前なのでコンパイラの動作に依存する部分（includeに関する記述）などは古い部分もありますが、プログラミングスタイルに関する部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
