TypeScript Origins: The Documentary
TypeScript Origins: The Documentary is brought to you by OfferZen - the community-first developer jobs platform. The documentary features core contributors and community members like Anders Hejlsberg, Steve Lucco, Luke Hoban, Daniel Rosenwasser, Ryan Cavanaugh, Amanda Silver, Matt Pocock, Josh Goldberg & many more! It also covers adoption stories and insights from JetBrains, Xata, AG_Grid, Deno,
CI for performance: Reliable benchmarking in noisy environments
CI for performance: Reliable benchmarking in noisy environments by Itamar Turner-Trauring Last updated 23 Oct 2022, originally created 02 Dec 2020 You have some code—whether it’s Python, Rust, Java, or some other language—whose speed you want to measure over time. Ideally you want it to get faster, but at the very least you don’t want to get any slower. So you write a benchmark, and now you need t
git logの内容を検索する-Sと-Gの違い - $shibayu36->blog;
ずっとgit logの内容を検索するときに-Sオプションを使っていたが、実は近いオプションに-Gオプションもあり、探したい内容によっては使い分けないとダメということを初めて知った... 詳しくはhttps://git-scm.com/docs/git-logの-Sと-Gのドキュメントを見てほしい。簡単にまとめると -Sは指定した文字列の出現回数が変わるdiffがあるcommitを検索する -Gは指定した正規表現がマッチする文字列がdiffにあるcommitを検索する ドキュメントの事例部分が結構わかりやすくて、以下のようなdiffがあった場合 + return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0); -S frotzで検索をかけると、frontsの出現回数は変わってないのでマッチしない
ソフトウェアを完成させるのは誰か
C2Cサービス開発からキャリアが始まり、その後開発基盤組織というものに長年従事して、その中でマネジメントも経験して、また普通のC2Cなサービス開発エンジニアに戻って、それも1年が経ちました。 開発基盤組織に長年従事してサービス開発にいざ戻ると「はたして自分はサービス開発をやっていけるのだろうか？」というような漠然とした不安が発生したりします。いまとなっては杞憂な話でしたが、それに驕らず危機感を持ち続けながら日々仕事をしています。 この不安というのは面白い事に、非常にポジティブです。日々の業務の中でただ「良いコードを書く」「より内部品質・外部品質の高いソフトウェアを開発をする」「よりxxxなチームビルディングに貢献する」だけであればそこに何の不安や迷いはないわけですが、長年ソフトウェアエンジニアをやってきた人間がいつまでもその目線でいて良いのか？という疑問があって、それに対して「良くないんじ
Grafana Pyroscope を用いて Go のアプリケーションで継続的プロファイルしてみた
■ はじめに こんにちは 👋 みなさんプロファイルしてますか？ プロファイルはオブザーバビリティの主要なテレメトリーの一つです。（主要なテレメトリーはログ・トレース・メトリクスだけではないですよ！） この記事では Go のサンプルアプリケーションを用いてプロファイルを計測し、アプリケーションの性能改善を行う方法を紹介します。稼働中のサービスを継続的にプロファイルすることで、CPU 使用率やメモリ割り当てなどの情報を収集し、自分のサービスのパフォーマンスに関する理解を深めることができとても有用です。 プロファイルの分析にはオープンソースの継続的プロファイルツールである Grafana Pyroscope （最近 v1.0.0 がリリースされました 🎉 ）を用い、これらを Kubernetes 上に展開していきます。 また本記事は、CNDF2023 の @ymotongpoo さんの "継
GoでSQLにトレーシングコメントを埋め込んで実行する | おそらくはそれさえも平凡な日々
アプリケーションが発行するSQLにコメントが埋め込めると便利です。例えば、 /* path/to/logic.go:334 */ SELECT ... のようにSQLに発行元の情報をコメントとして埋め込んでからExecすれば、DB側のログ(general log等)にも記録されるため、SREやDREサイドからも、負荷の高いSQLがアプリケーションのどこから発行されているかが分かりやすくなります。 Goには github.com/shogo82148/go-sql-proxy という、SQL実行をトレースし、フック処理を差し込める便利なライブラリがありますが、今回それにpull requestを送って、SQL実行前にクエリの書き換えができるようにしました。 https://github.com/shogo82148/go-sql-proxy/pull/61 https://github.co
Vimmer から見た Emacs ファジーファインダーの歴史について
始めに Emacs ファジーファインダーフレームワークの歴史 私はこれまでいくつかのファジーファインダーを開発してきました。それは Emacs のプラグイン anything.el にとても影響を受けています。 anything.el が存在しなければ私がプラグイン開発をすることもなかった。そういえるほどです。 anything.el のリリースからとても長い月日が経ちました。Vim 界でのファジーファインダーのトレンドが急速に移り変わっているように、Emacs 界隈でもファジーファインダーのトレンドが移り変わっています。ここは私の視点で Emacs 界隈のその歴史を振り返ってみることにしましょう。 anything.el 2007 年頃開発開始 ファジーファインダーの歴史は明確に anything.el 以前と anything.el 以後に分かれます。 現在のテキストエディタではファジ
Goの//lineコメントを君は知っているか？ - Qiita
コメントディレクティブ どうもナレッジワークのtenntennです。 Goには、//go:noescapeや//go:linknameなどのコメントでコンパイラへの指示を記述するコメントディレクティブがあります。一応、ドキュメントには記載がありますが、多くのGoエンジニアはあまり機会はないでしょう。 ドキュメントを読むと//lineで始まるコメントは特別な意味を持つことが分かります。ここではこのlineディレクティブについて解説します。 lineディレクティブ ドキュメントには、以下のように記述した場合に、lineディレクティブとして認識されるようです。行コメントだけはなく、ブロックコメントも対象となります。//や/*の後ろにスペースを含んでは行けなかったり、:が必ず含まれていなければならなかったりと、細かなルールがあります。 //line :line //line :line:col /
Goにおける静的解析のモジュール化について - Mercari Engineering Blog
Mercari Advent Calendar 2018 の16日目はメルペイ エキスパートチームの@tenntenn お送りします。 この記事では、Goの静的解析の新しいムーブメントであるgolang.org/x/tools/go/analysisを使ったモジュール化について解説したいと思います。 「静的解析は関係ないや」と思って、タイトルを見てブラウザのタブを閉じようと思ったかもしれませんが、ほとんどのGopherには無関係ではないと思いますので、ぐっと我慢してしばらく間お付き合いください。 静的解析のモジュール化とは Goにはgo vetやgolintなど静的解析ツールが多数あります。 静的解析ツールを用いることで、プログラムを実行せずにバグになりうる箇所を検出することができます。 実際に、コードレビューを行う際にCIで静的解析ツールを実行している方も多いかと思います。 Goは標準で
SQLite のおもしろ仕様 (1) : データ型 - kawasin73のブログ
型は型、どうもかわしんです。SQLite では型は絶対ではなく、あくまでも尊重です。信用しすぎると裏切られます。 最近 Rust で SQLite をフルスクラッチで再実装しています。 github.com なるべく本家の SQLite と compatible にするために SQLite のドキュメントやコードを読んで挙動を理解しながら作っています。これを作ることになった経緯はこの記事で紹介していますが、その過程でいろいろ知らなかった面白い仕様や実装があったので紹介していきたいと思います。今回はその第一弾です。 kawasin73.hatenablog.com データ型と Type Affinity SQLite のドキュメントの中で、今の所一番面白いのがこれです。 www.sqlite.org まず、SQLite の内部的には 5 つのデータ型しかありません。 NULL INTEGER
Goの構造体のバイナリエンコーディングを速くしたい - HRBrain Blog
この記事は HRBrain Advent Calendar 2021 2日目の記事です。 qiita.com はじめに Goで構造体をバイナリエンコーディングする際、大抵は encoding/json か encoding/gob を使うと思います。 以下の記事を読んで、標準の encoding/binary パッケージを使えば任意の構造体のエンコード・デコード処理を自前で書けることを知りました。 zenn.dev 構造体のエンコード・デコード処理を自前で書くとどれくらい速くなるのか気になったので試してみました。 単純にreflectionを使わない分速くなりそうです。自前で書いたエンコード・デコードのパフォーマンスを、 encoding/json encoding/gob と比較してみます。 ※最初に言っておきますが実用性は殆ど無いと思います。 型ごとのエンコード・デコード方法 int
Bun1.0がもうすぐリリースされるぞ！
超高速でNode.jsと互換性の高い JavaScript と TypeScript ランタイムである Bun 初の安定版が 1.0 としてついにリリースされます！ リリース予定時刻は 2023-09-09 00:00 JST (太平洋時間では 2023-09-08 07:00 PST) です。 リリースに向けて早速 YouTube に Bun のこれまでの機能や追加される機能についての紹介動画が公開されています。 追記: 公式のリリース記事が公開されました！ Bun 1.0 | Bun Blog 🌱 これまでのおさらい Bun 超高速な JavaScript ランタイムです 組み込みで TypeScript のサポートがされており特に設定を何もせず TypeScript を実行できる環境が手に入ります Node.js との高い互換性があり Node.js アプリケーションの多くはそのま
structのメモリ割り当て - Carpe Diem
概要 Goにおけるstructのメモリ構造を知ることでフィールド順序に対する意識が変わったり、なぜunsafe.Sizeof(string)が16bytesでunsafe.Sizeof(slice)が24bytesになるかが理解できます。 環境 Go 1.15.6 darwin 20.1.0 x86_64 各型のメモリ割り当て unsafe.Sizeof()を使うとその変数がどれくらいメモリを割り振るかが分かります。 ※変数の分確保するメモリであり、参照先のメモリは含みません 型 unsafe.Sizeof() bool 1 int32 4 int 8 float64 8 string 16 []T 24 The Go Playground structのフィールドにそれぞれの型を付けると、その分メモリが割り振られます structのメモリ割り当て 例えばbool, float64, in
UPMパッケージのテストワークフロー事例 - やらなイカ？
自作UPM （Unity Package Manager）パッケージをGitHub Actions上でテストするためのワークフローが確立できたので紹介します。 前提とするのは、リポジトリのルートがパッケージのルートディレクトリである（package.jsonがある）構成です。 Unityプロジェクトの一部をUPMパッケージとして公開している構成でも、パスを書き換えるなどすることで応用できるはずです*1。 また、テストアセンブリの名前末尾が .Tests であることを前提としています*2。 実現していることは次のとおりです。 先行ジョブのキャンセル 複数Unityバージョンでのテスト実行（互換性） テスト実行用Unityプロジェクトの生成 テスト実行のための依存関係の解決 テスト実行 コードカバレッジの集計 Slack通知 以下、処理順に説明します。 記事の最後に、実際に動作しているリポジト
爆速開発し続けるために3ヶ月でテストカバレッジを大幅改善させた話｜のりたま | LayerX
LayerXでエンジニアをしている @noritama です。現在はバクラク請求書の開発に携わっています。 2022年3月に入社して、いつの間にか9ヶ月ほど経過していました。 今回は、2022年2Q(7〜9月期)にバクラク請求書チームのOKRの1つの Key Results としてテストカバレッジを掲げたことと、実際に取り組んだ内容についてご紹介します。 OKRの運用LayerXでは今年の4月から、組織及び個人の目標管理としてOKRの運用が開始されています。 事業部OKR -> チームOKR -> 個人OKR というブレイクダウン形式で目標を設定するため、メンバー間で目線を合わせ、納得感のある目標に落とし込める点が個人的には気に入っています。 テストカバレッジを目標に掲げた理由品質起因による開発速度低下が顕在化し始めていたバクラクのプロダクトはおよそ2週間に1度、アップデートのためのリリー
sqlc plugin を書こう - 薄いブログ
背景 https://github.com/orisano/sqlc-gen-ts-d1 というプラグインを作成していて生成コードの好みが人によって大きく異なると感じることがありました。 一つのプラグインで生成コードをカスタマイズできるアプローチには保守性的な意味でも限界があるだろうと思いました。 気軽にプラグインが作れるようになることで自分の好みのコードが生成できるし、好みが似通ったコミュニティにメンテンスされているプラグインが一つでもあれば幸せな人も増えるかなと思ったため記事を書くことにしました。 とはいえ sqlc を使い始めるとき最初にプラグインを書くことはまずないし、デフォルトの生成コードが好みでなかったりそもそも対応してない場合は選択肢から外れるだけだと思います。 なので sqlc を使いたいという情熱のある人やプラグインを作りたいという人の役に立てばと幸いです。 plugin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Performance stability of GitHub Actions | Andrey Akinshin
Valgrind in macOS with Docker
Goのスコープについて考えてみよう #golang - Qiita
