まずは、GoDocと、その他ツール周りのアップデートの紹介です。 Docコメントの更新以前、Qiitaの方に、チョットできるGoプログラマーになるための詳解GoDocという記事を掲載しました。 https://qiita.com/shibukawa/items/8c70fdd1972fad76a5ce GoDocの書き方の詳細ですが、以前は空行をあけて段落、インデントをしてフォーマット済みテキスト、URLがあればリンク、という程度のマークアップしかなく、とてもシンプルでした。GitHub FlavorなMarkdownとまでもいかなくても、もうちょっとマークアップが高機能になってほしい、せめてリストだけでも・・・と思っていた日本全国1億2000万のGoプログラマーにとって待望のアップデートが1.19で入りました。 セクションタイトル リンク リスト また、gofmtが改善され、Docコメン
はじめにTIG真野です。失敗談をテーマにした連載で、ちょうどプロダクト開発的に良い区切りのタイミングでもあるため、振り返りがてら、DynamoDB,Go,AWS Lambdaの技術要素について自分自身の理解・見込みの甘さについて反省します。 DynamoDBのシステム項目created_atとかupdated_atのタイムゾーンはJSTにすれば良かったDynamoDBは日付型を直接サポートしておらず、文字列型で保存することになります。 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes.String データサイズや諸々の理由でUnixTime 勢力もあるかもしれませんが、アプリケーションから直接参照
この記事はPySpa Advent Calendar 2021の14日目のエントリーとして書かれました。昨日のエントリーは冷凍食品でウキウキ引きこもり生活 でした。ちなみに私も70ℓの冷凍庫を購入しましたが本当にライフチェンジングでした。 総論: なぜログが必要か 可観測性 たとえ目的は自明でも、その動作までが自明なアプリケーションというものはほぼ存在しません。現実の世界のアプリケーションというものは、動作パラメータだったり実行環境だったり、起動時点でのさまざまな要因によって挙動を変えるものだからです。そして、そうしたアプリケーションにはライフサイクルというものがあります。ここでいうライフサイクルは、アプリケーションの処理が実行されるにつれ、アプリケーションの内外との情報のやりとりで生じる大局的な状態の変化のことです。アプリケーションが並行処理を行うようなものであれば、個々の並行処理の単位
TIGの辻です。GoのORマッパー連載8日目です。本記事では sqlc を紹介します。早速ですが、結論から行きましょう。 sqlc まとめ SQLファイルからデータベースにアクセスできる型安全なGoのコードを生成するライブラリ 構造体のモデルの手書き実装不要 複数テーブルをJOINしたときのマッパー実装不要 生成されるコードは不要なリフレクションなし SQLをがんがん書きたい、でも面倒なマッパー構造体は書きたくない、という開発者にとっては大きな味方になります。 sqlc の紹介 sqlc はSQLファイルからGoのアプリケーションコードを生成するライブラリです。2020/2に v1.0.0 をリリースし、着々とスターを伸ばしています。2021/08現在は v1.8.0 をリリースしています。本資料で生成しているコードも v1.8.0 を用いています。 https://star-histor
また毎回恒例のGo 1.17リリースパーティも開催予定です。ぜひご参加ください。 コンパイラ関数呼び出しが5％高速化1.16の時に予告されていたレジスタベースの関数呼び出しが入りました。呼び出し速度が5％、バイナリサイズが2％改善されました。特にコードの変更なく恩恵に授かれます。 あとはpanic時のスタックトレースの表示が改善され、今まで16進数で表示されていたのが改善されたらしいのですが、よくわかりませんでした。16進数は出なくなりましたが、試したが、…となるだけでした。 クロージャを含む関数がインライン展開されるようにもなりました。これもコード修正必要なく、パフォーマンスアップにつながる可能性があります。 なお、unsafeで怪しく引数を触ったりするとトラブルが発生する可能性がありますが、通常のGoの使用方法では問題になることはなさそうです。 build constraintのコメン
はじめにTIG DXユニット真野です。GoのORマッパー連載 の1本目です。 テーマはorm-ishなデータベースアクセスレイヤーライブラリであるREL(go-rel/rel)です。他のメジャーなO/Rマッパライブラリに比べるとまだまだGitHub Stars数は少なくマイナーかもしれませんが、いくつか興味深い点があったので最後までお付き合いいただければです。 LICENSEはMIT、2021.07.23でv0.17.0までリリースされています。この記事はv0.17.0時点で記事を書いています。 REL概要ドキュメントサイトも用意されていてこちらです。 RELの特徴はエレガントなAPI（チェーンでSQLクエリを組み立てるDSL）を提供しながら、テスタビリティを追求しているところが最大のポイントかと思います。他にも豊富な機能が謳われています。 Eager loading ネストしたトランザク
(2021.09.18追記)おまけとして、筒井さんがさらに寄稿してくれました。 lib/pq から jackc/pgx への移行 O/RマッパとクエリビルダーO/Rマッパは Object Relational Mapperの略で、通常はGoの構造体とRDBのレコードを紐付ける処理のことを指します。O/Rマッパーと呼ぶことが多いですが、略してORMとも呼びます。名前から見るとSQL検索結果を構造体にマッピングすること（Goだとsqlx相当の処理）かなと思いますが、実際はSQLを組み立てるDSLを提供するライブラリが多いです。 クエリビルダーは、広い意味のO/Rマッパ機能のうち、SQLクエリを組み立てるライブラリのことです。調べると goquとかがまさにそれにあたります。 細かくはgoquを連載テーマにした伊藤真彦さんに譲るとして、簡単ではありますがここでサンプルコードも出しちゃいます。 ds
はじめに こんにちは！エンジニアの柿森です。新規プロジェクトを担当しております。 ANDPADではマイクロサービス開発を推進しており、新規プロジェクトは個別に技術選定を行い、既存システムとAPI経由で連携します。 また、マイクロサービス基盤はk8sで構築されており、死活監視やログ収集もよしなにやってくれる環境が整っております。 新規プロジェクトを立ち上げで、k8s上に乗せることを前提に技術選定を行いました。 技術選定を行うにあたって検討したポイントと、採用した技術について話していきたいと思います。(あくまで筆者個人の考えです。) 採用した技術スタックの概要 フロントエンドはBlitz-jsを参考にNext.jsを採用。 バックエンドはGo + gRPCを採用。 技術選定の方針 大きな方針としては一般的な考えを踏襲しています。 ドキュメントがしっかりしており、GitHubのStarがそれなり
大きくは外部ストレージサービス利用と、アプリケーションにバンドルしてしまう方式と2つにわかれます。バンドルはデータだけ更新ができないデメリットはありますが、お手軽です。Lambdaはレイヤーを使えば実行プログラムに対して後から追加とかできますが、容量制限が厳しめです。 オブジェクトストレージは比較的お手軽ですが、読み込みしたいライブラリがローカルのファイルシステム前提の場合は使えません。サーバーレスの方式によっては、一度ローカルのファイルシステムに書き出してから利用とかも可能ではありますが、Cloud Runでは8GB（ただし、おそらくtmpfsで書けば書くほどメモリを消費)、Lambdaでは500MBと容量に制限があります。 より巨大な学習済みデータを扱う場合はマネージドNFSサービス系のものを使うのが最終形でしょう。ファイルのサイズ制限もほぼ限界値ですし、ローカルファイルになるのでどん
Goで構造体を設計する場合、オブジェクト指向的な「型ごとの責務の分担」以外に、「どのように使われるものか」を考える必要があります。 ポインタで扱うのか？ 値として扱うのか？ 両方許可するのか？ 値として扱える場合にimmutable（変更不可能）なオブジェクトとするのか、mutable（変更可能）なオブジェクトとするのか 値として扱える場合にゼロ値での動作を補償するかどうか 他の言語で言うと、C#の構造体とクラスの違い、C++のデフォルトコンストラクタあたりに頭を悩ませたことがある人にはおなじみかもしれませんが、Goでもいくつか考慮が必要になります。 ポインタ型として扱う必要があるケースまず最初に決断できる方針としては、ポインタ型でのみ扱うかどうかです。 内部にスライスやmap、ポインタなどの参照型な要素を持っていれば、基本的にポインタ型でのみ扱う構造体になります。これらの要素を持っていた
CPUはなんとARMのCPUを採用しています。(そのおかげでLLVMのターゲットに指定できる) ゲームボーイとの違い CPU 最大の違いはCPUです。ゲームボーイ(以降、GB)ではZ80を独自カスタムしたLR35902というCPUを使っていますが、このCPUは8bitで動作するCPUです。つまり命令のサイズが8bit(1byte)しかありません！ しかも、LR35902は掛け算命令など現代のCPUでサポートしている基本的な命令をサポートしていません。 これに比べてGBAに搭載されているARM7TDMIは32bit CPUです。つまり命令のサイズが4byteとGBの命令の4倍の大きさになります！ このおかげでCPUの命令セットがさまざまな命令をサポートできるようになりました。(まあ後述の理由で実質16bit CPUですが...) またクロック数もGBの4MHzから16MHzに伸びました。 B
Trivyのv0.17.0をリリースしました。 github.com 長い道のりでしたが、ようやくこれでGoバイナリの脆弱性検知に対応できました。夜中0時ぐらいからリリース作業を初めて気付いたら朝5時でした。 概要 Go言語で書かれたプログラムをビルドすると依存しているモジュールがバイナリに含まれます。現代のソフトウェア開発において利用しているOSSのライブラリが0ということはまれなので、何かしらのOSSライブラリが作成されたバイナリに同梱されます。これらのOSSの古いバージョンには既知の脆弱性が含まれる可能性があります。これを手動で調べて追うのは手間なので最近では脆弱性スキャナを用いて検知するのが普通です。自分が開発したTrivyというOSSの脆弱性スキャナではコンテナイメージやファイルシステム上のGoバイナリに含まれるモジュールを特定し脆弱性を検知します。 Goのバイナリからどうやって
こんにちは。BASE BANK株式会社 Dev Divisionにて、 Software Developerをしている永野 (@glassmonkey) です。 今回は弊社でブロンズスポンサーとして協賛しました。 PHPをメイン言語として使用しているBASE社と異なり、BASE BANK社ではGoをメイン言語として使っているので、今回は初めてBASE BANK社としてスポンサードさせていただきました。色々至らぬこともありましたが、この場を借りてお礼を申し上げます。 登壇の内容に関してですが、業務ではなく趣味で触ってるFlutterネタです。勢いでProporsalに出したら通していただいたので、趣味全開な形になりました。 GoConference2021 Springについて gocon.jp https://gocon.jp/ Go Conferenceは半年に1回行われるプログラミング
TIGの伊藤真彦です。 渋川さんが投稿された Go 1.16のembedとchiとSingle Page Application Go 1.16のgo:embedとNext.jsの相性が悪い問題と戦う に近い研究記事です。 やりたいこと 私の最近の仕事はgo-swaggerによるバックエンドAPI開発です。本流はバックエンドですが、必要に応じてクラウドインフラを弄ったり、ちょっとしたフロントエンドアプリケーションを作ったりといった動き方で働いています。 ある時、go-swaggerで作ったバックエンドAPIの資産を使って、ちょっとした開発者向けアプリケーションを作りたくなりました。 ローカル環境でサーバーとフロントエンドアプリケーションを両方起動すると、サーバーがlocalhost:3000 フロントエンドがlocalhost:8080を占拠してしまいます。また、フロントエンドとバックエン
前エントリーのGo 1.16のembedとchiとSingle Page Applicationでは、Vue.jsで生成したファイルをバンドルしました。Vue.jsや、Parcel V2でビルドしたコンテンツを配信するにはこれで問題ありません。しかし、React（Next.js）は要注意です。 フロントエンドの環境整備をどうやって行うかはいつも悩みの種ですが、そんな中、僕が3年ほど前から他の人にお勧めしていたのがNext.jsでした。ほとんどの最低限必要なツール群は整備済みで、最近のバージョンであればTypeScriptを使うのも簡単。Linter(npm exec eslint –init)とFormatter(npm install prettierと環境整備)ぐらいでコードを書き始められます。 しかし、環境構築が簡単なNext.js製のウェブアプリケーションのビルド済みのフロントエン
シングルページアプリケーションは、一つのHTMLファイルであらゆるページを表現します。history APIを使ってそのようなページが実際にあるかのように振る舞います。 一方で、画面がリロードされたとき、メールでSNSでシェアされたときにその該当ページをきちんと再現するためには、サーバー側でハンドリングを行う必要があります。具体的には、存在しないページがリクエストされたら、アプリケーションのルートとなるHTMLファイルの内容をそのURLから配信するというものです。 https://angular.jp/guide/deployment#server-configuration それにより、どのURLでもJavaScriptが動作し、そのURLで表示すべきコンテンツが表示されます。もし想定していないパスの場合は、ウェブサーバーではなく、JavaScriptがエラーを出します。 Goでウェブサ
テックカンパニーをテックカンパニーたらしめているものはなにか？技術か、人か、それともチームなのか。 連載「Technology Company Internals」では、テックカンパニーの内側で働くエンジニアに、技術に精通したエキスパートが対面で話を聞き、テックカンパニーとは何か？を探るだけでなく、テックカンパニーを目指す企業の指針となることを目指します。 マネーフォワードのCTOとVPoEに話を聞く 白石: 本日はよろしくお願いします。自己紹介からお願いできますでしょうか？ 中出: 中出 匠哉と申します。マネーフォワードのCTOとして企業経営に関わり、経営にテクノロジー視点を導入していくのが主な役割です。他には技術面での方向性の決定や、エンジニアの人事制度の立案などもやっていますね。あとはサービスがどんどん大規模化していく中でも、技術的負債に優先順位を付けて、体制を作って解消していくのも
こんにちは、TIGの辻です。Go 1.16連載の3記事目です。 Go1.16でアップデートがあった io/ioutil パッケージが "deprecated" になる話題のまとめです。 サマリ Go1.16から io/ioutil パッケージの機能が os と io パッケージに移行した これから新しく実装するコードは io や os パッケージの新しい関数を使うことが推奨される io/ioutil パッケージが "deprecated" になるが "deprecated" といっても将来壊れる、ということではない 既存のコードは動作し続ける go fix コマンドは未対応 内容Go1.16から io/ioutil パッケージに含まれる関数が "deprecated" になります。関連するプロポーザルは #40025 と #42026 です。Package names で良くないパッケージ
VSCodeも1.53でInsiderでない安定板もM1対応になりますし、GoLandもネイティブ版がリリースされました。Rosetta2でも快適だった環境はますます快適になっています。 それ以外だとlinux/riscv64対応が改良されていて、個人的には気になっています。 ランタイムの変化runtime/metricsパッケージが導入されました。runtimeとかdebugとかさまざまな場所に散っていったメトリックス収集機能が集約されました。今サポートしているのはGC関連のメトリックスと、メモリ関連のメトリックス、goroutine数ですね。 あとは、GODEBUG環境変数にinittrace=1を設定すると、各パッケージのinitで消費している時間やメモリの情報が標準出力に表示されます。Google App EngineやらCloud RunやらCloud FunctionsやらAW
この記事は Go Advent Calendar 2020 24日目の記事です。 はじめに 皆さんは「モブログ」ってご存じでしょうか。 モブログとは、携帯電話などの携帯通信端末からインターネットに接続して閲覧・投稿ができるブログ（ウェブログ）のことである。 携帯電話などを利用して書き留められた短い文章や、あるいはカメラ機能で撮影された写真などが記事の主な内容となる。常に携帯するものなので、ふと思いついた所感を臨場感が損なわれないうちに記すこと、あるいは街角で見かけた面白い光景や偶然出会った有名人などを逃さず撮影することなどが可能となる。1日のうち特定の時間にパソコンの前に構えて書かれる通常のブログよりも一層、リアルタイム性が色濃く、独特の臨場感や軽快さがある。 ちなみに、モブログはモバイル（mobile）とブログ（blog）が組み合わされた造語である。和製英語ではないので、英語圏でもmob
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く