Goでのサービスロケータパターン - Qiita
ネストの深いプログラムを書くとき、 プログラム全体で共有したいオブジェクトをどうやって引き回すかというのはいつも悩む問題です。 グローバル変数 小さなプログラムの場合は雑にグローバル変数に入れてしまうのも悪くはないですが、 プログラムが大きくなるにつれ、このやりかたはつらくなります。 シングルトン シングルトンは基本的にはグローバル変数と同じことです。 ただしファクトリ関数をうまく使えばグローバル変数をそのままつかうより柔軟な取り回しが可能になるかもしれませんが。 グローバル変数にせよシングルトンにせよプログラム全体で状態を共有しますが、 そうではなく関数ごとに引数としてサービスを渡していく方がテスタビリティも高いし好ましいと思います。 コンテキスト APIサーバをたてるときによくやってしまいますよね。 リクエスト処理全体で共有したいような変数をミドルウェア経由でコンテキストにセットすると
今さらProtocol Buffersと、手に馴染む道具の話 - Qiita
Protocol Buffersは別に新しい技術ではない。同時にそれは、未だ知られざる、未だに可能性を秘めた先端のソフトウェア技術基盤である。 新しくないのは事実で、GoogleがProtocol Buffersをオープンソース化したのは2008年のことだし、オープンソース化前に社内で使われ出したのは更に昔に遡るだろう。たぶん。 デザイン的にもJSON対応は後付けで、将来JSONが隆盛を極めることなんか全然想定していなかったのが透けて見えて古くさい。 しかし、同時にどうも情報に聡い人であってもなかなかその真価を実感し得ておらず、ある意味で未知の技術であるらしい。ならば、Protobuf (Protocol Buffersの略)を解説した文書は幾多あれども、それに1を加えるのもやぶさかではない。 Protocol Buffersとは Protobufはスキーマ言語だ! 一般的にはProtob
AnsibleとDockerによる1000台同時SSHオペレーション環境 - ゆううきブログ
1000台同時SSHオペレーション環境を構築するにあたって、手元のローカル環境の性能限界の問題を解決するために、オペレーションサーバをSSHクライアントとすることによりSSH実行を高速化した。実行環境としてDocker、レジストリとしてAmazon ECR(EC2 Container Registry)を用いて、ローカル環境とオペレーションサーバ環境を統一することにより、オペレーションサーバの構成管理の手間を削減した。 はじめに システム構成 実装上の工夫 オペレーションサーバ越しのroot権限実行 rawモジュールとscriptモジュールのみの利用 Ansibleの実行ログのGit保存 まとめと今後の課題 はじめに 3年前に Ansible + Mackerel APIによる1000台規模のサーバオペレーション - ゆううきブログ という記事を書いた。 この記事では、ホストインベントリと
Ethereum のローカル開発環境 Ganache を使ってみる - Qiita
2017年11月15日に Truffle チームがリリースしたばかりの Ethereum 開発環境 Ganache を使ってみました。 Testrpc が消えた？ 現在、testrpc の github リポジトリにアクセスすると、ganache-cli というリポジトリにリダイレクトされます。 README.md には下記のように書かれています。 Looking for TestRPC? If you came here expecting to find the TestRPC, you're in the right place! Truffle has taken the TestRPC under its wing and made it part of the Truffle suite of tools. From now on you can expect better s
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
初心者向けにMongoDBの基本を解説しています。 この資料は2014/3/1のOSC 2014 Tokyo/Springで発表しました 。 2015/3/3最新の情報で一部アップデートしました。 2015/7/15MongoDB ver3.0ようにちょっと修正しました。 This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python ba
RDSのMySQL/MariaDBでログをCloudWatch Logsへ出力可能になりました
ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程RDSのMySQL/MariaDBのログファイルをCloudWatch Logsへ出力できる機能がリリースされましたのでレポートします。 Monitor Amazon RDS for MySQL and MariaDB logs with Amazon CloudWatch Now Publish Log Files from Amazon RDS for MySQL and MariaDB to Amazon CloudWatch Logs CloudWatch Logsへのログファイル出力 RDS for MySQL/MariaDBでは以下の4種類のログを出力することができました。 Audit Log Error Log General Log Slow Query Log 出力先はテーブルかファイルとなり、テーブルの場合はDB
Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開
Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開 Container Structure Testは、コンテナ内部でコマンドを実行することで正しい出力やエラーが帰ってくるかどうかや、コンテナ内部のファイルが正しく格納されているかなどの検証を実行できるフレームワークです。 具体的には下記のテストをサポートしていると説明されています。 Command Tests コンテナイメージ内部でコマンドを実行し、正しい出力やエラーが返ってくるかを検証する。 File Existence Tests コンテナイメージ内部に、あるファイルがファイルシステム内の適切な位置に存在しているかどうかを検証する。 File Content Tests コンテナイメージ内のファイルシステムにあるファイルのコンテンツとメタデータ
ActiveRecordでINの中が一万個とかにならないようにする - かみぽわーる
この記事は MySQL Casual Advent Calendar 2017 の23日目の記事です。 みなさんORマッパーは使っていますか？ 僕は仕事とか趣味でActiveRecordというORマッパーを使っているんですけど、こいつ例えば Team.preload(players: :high_score).to_a みたいなことをするとすぐ SELECT `scores`.* FROM `scores` FROM `scores`.`id` IN (a, b, c, ...数千個続く...) みたいなクエリを生成しよるんですけど、MySQL 5.7に上げたときに range_optimizer_max_mem_size の制限で実行計画がテーブルスキャンに落ちてえらい目にあったことがありました。MySQL側で range_optimizer_max_mem_size = 0 することで
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
I/O負荷の正確な状況はiowaitでは分かりません - Qiita
さくらインターネットのアドベントカレンダー9日目として、サーバ屋らしく、運用に関するコマンドの使い方を紹介します。 サーバの負荷が高まってきたときに、vmstatやtopなどのコマンドで調査する事が出来ますが、I/O負荷をwa(iowait)によって判断する人も多いと思います。 ただ、結論から言うと、iowaitは正確にI/Oの負荷を表しているわけではありません。 これらを、実際に演習をしながら見ていきたいと思います。 iowaitとidle iowaitとはあくまでも、CPUが空いているのにI/Oがボトルネックになっているプロセスを示しているだけで、CPUの利用率が高いときにはI/Oがボトルネックになっていてもiowaitが上がりません。 同様に勘違いされがちなのが、id(idle)はCPUの空きを示しているというものですが、idleは必ずしもCPUの空き時間を示しているものではありませ
マスターデータ管理を優しくExcelから解き放つ (ドリコムアドベントカレンダー9日目)
ドリコムアドベントカレンダー9日目前日は@onkさんの「ドリコムの Gemfile 記述スタイル」です。 自己紹介 奈良阪です。こんなアイコン 株式会社ドリコムに新卒で入って3年目、スマホゲームサーバーのRailsとか、新規サービスのTypeScriptとか、Elixirとか、少しPythonとか、なんかよくわかんない組み合わせですがどれも並行してざくざく書いてます。 なお弊社最近JavaScript開発知見がなかったのでむしろしがらみがなく、趣味でやってた自分好みのTypeScript開発体制をスッと入れられてほくほくしています。有識者目指していく。最近github.com/Narazakaの上の方に上がってきたswagger云々とかのTypeScriptのプロジェクトは、仕事で環境整備しているのの切れ端だったりします。 趣味では伺かというデスクトップマスコットのWeb移植版を作ってたけ
Visual Studio Code で編集中のテストコードを実行する - はこべにっき ♨
TL;DR Visual Studio Codeではエディタからのコマンド実行がTasksという仕組みでできてとても便利。 背景 最近エディタをVisual Studio Codeに変えた。エディタのこだわりはそんなになくて、Vim → Emacs → Atom といった順番で2年に一度くらい乗り換えている。だいたいどのエディタにもVimキーバーインドエクステンションがあるのでなんとかなる。 Visual Studio CodeはAtomと同じElectronベースだけど、なぜかAtomよりサクサク動くので気に入っている。Microsoftのリソースパワーに感謝するしかない。 テストの話に移ると、テストを書くのはもちろんソフトウェア品質の担保やリグレッションの防止が目的だけれども、TDD的な文脈では開発のリズムを作るのも目的の一つだ。リズムよくテスト実行しつつ開発するには、エディタで開いて
CodeBuildのビルド結果をSlackで通知する - Qiita
2017-06-22のアップデートでCodeBuildのビルド結果をCloudWatchEventsで捕捉できるようになりました。 そのままSNSで通知してもいいのですが、LambdaからIncoming Webhookを使ってSlackに通知してみようと思います。 事前準備 以下のことはすでに済んでいる前提で話を進めます。 CodeBuildのプロジェクト作成 SlackのIncoming Webhookの設定(URL発行) 実装 さくっと済ませたいのでServerlessフレームワークを使います。 serverless.yml設定 まあこいつを見てもらおうか service: notify-build-result provider: name: aws runtime: nodejs6.10 timeout: 180 stage: ${opt:stage, self:custom.d
AWS CodeBuildでElectronをビルドしてGitHubにReleaseを作る - Qiita
tagをGitHubにpushしたらAWS CodeBuildでElectronのビルドが走ってGitHubのReleaseにzipをアップロードするところまでを自動化してみた。GitHubとCodeBuildをどうインテグレーションするのがいいかよくわからなかったのでAPI GatewayとLambdaでつないだ。 コードはここに。 Electronのビルド まずはElectronをビルドするビルドスクリプトを書く。 #!/bin/sh set -e OUT_DIR=./dist rm -rf $OUT_DIR ./node_modules/.bin/electron-packager . Test \ --platform=darwin \ --arch=x64 \ --overwrite \ --app-version=$BUILD_VERSION \ --build-version
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
t.run
fix BinaryExpr execution method by ToQoz · Pull Request #34 · ToQoz/gopwt
加速するフロントエンドとPWA
AppVeyor
Pleroma / pleroma · GitLab
