ドキュメントベースの型安全なモバイルアプリ行動ログ基盤の構築 - クックパッド開発者ブログ
こんにちは。PlayStation 5が一向に買えない@giginetです。普段はモバイル基盤部というところでiOSの基盤開発をしています。 皆さん、行動していますか？我々は日々Webサービス上で様々な行動をしています。サービス開発において、改善に活かすための効率的な行動ログの収集方法はしばしば課題になります。 今回は、サービス開発者がモバイルアプリ上で簡単にログを定義し、分析を行えるログ基盤を導入した事例について紹介します。 行動ログとは何か モバイルアプリの行動ログとは、ユーザーのアプリ上の操作や利用状況を取得、集積するためのものです。 例えば、特定の画面を表示したり、特定のボタンをタップしたり、といったユーザー操作を起点として送信されています。 集められたログは、サービス開発のための分析や実態把握に役立てられます。 最近はFirebase Analyticsなど、PaaSの形態で提供
gRPCを用いたマイクロサービスのAPI仕様の記述 - Mercari Engineering Blog
この記事はMERPAY TECH OPENNESS MONTHの10日目の記事です。 こんにちは、メルペイのバックエンドエンジニアの柴田（@yoshiki_shibata）です。 メルペイのバックエンドは、Google Cloud Platform上でGoogle Kubernetes Engineを使用して、マイクロサービスアーキテクチャを採用した多数のマイクロサービスから構成されています。モノリシックなサービス実装では複数層のライブラリ（あるいはコンポーネント）から構成されるのに対して、マイクロサービスアーキテクチャでは複数層のマイクロサービスから構成されます。 どちらのアーキテクチャにおいても、偶発的プログラミング（Programming by Coincidence）1を避ける2ために、注意を払って作成する必要があるのが、境界部分のAPI（Application Programmi
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 - エンジニアHub｜Webエンジニアのキャリアを考える！
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴（Yugui）さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント（=ソースコードに書かれている注釈やメモ）です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴（Yugui）さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴（そのだ・
効果的にバグを報告するには
作者：Simon Tatham, 職業プログラマ兼、フリーソフトウェアのプログラマ [ English | Português | 简体中文 | Česky | Dansk | Deutsch | Español | Français | Magyar | Italiano | 日本語 | Nederlands | Polski | Русский | 繁體中文 ] はじめに おおやけに利用されるソフトウェアを書いたことがある人なら、おそらく一通は質の悪いバグ報告を受け取ったことがあるだろう。何も言わんとしない報告(「動きません!」)、意味をなさない報告、十分な情報を供さない報告、誤った情報を含む報告などだ。なかには、使用法の誤り、他のプログラムの欠陥、ネットワークの障害などに起因する問題の報告まである。 技術サポートがぞっとする仕事とみなされるには理由があり、その理由こそが質の悪いバグ報
TomDoc for Ruby - Version 1.0.0-rc1
TomDoc for Ruby - Version 1.0.0-rc1 Purpose TomDoc is a code documentation specification that helps you write precise documentation that is nice to read in plain text, yet structured enough to be automatically extracted and processed by a machine. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to
データベースドキュメント管理システム dmemo のご案内 - クックパッド開発者ブログ
こんにちは、みんなのウェディングに出向中の小室 (id:hogelog) です。 今回はクックパッドとみんなのウェディングで利用しているデータベースドキュメント管理システム dmemo を紹介します。 https://github.com/hogelog/dmemo dmemo を作成し導入した経緯 私は2016年3月頃からみんなのウェディングで Redshift, bricolage, embulk, re:dash 等を利用したデータ分析基盤の構築を進めています。 (みんなのウェディングのデータ分析基盤の現状 - みんなのウェディングエンジニアリングブログ) 社内の誰でも扱えるデータベース、データの集約・計算・加工、ダッシュボードの作成、クエリの共有などは上記ブログ記事でも書いたように Redshift, bricolage, embulk, re:dash 等を組み合わせることで実現
公式ドキュメントを読もう — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 最近、若手のエンジニアと話をする機会が多くあります。そういった場で、ここが重要ですよと伝えたい話のうちのひとつがこの話になります。別のところに書いていたものですが、すこし手を入れた上で再掲します。 ハッカーの世界には昔から「RTFM」という言葉があります（参照）。ようするに「マニュアルを読め」という言葉なのですが、これはとても重要な言葉です。 色々な人によってブログにメモやノウハウが記載され、簡単に検索でみつかる世の中ではあります。また、そのためのサービスや技術的な質疑的な質問をすることのできるサービスも沢山あります。 しかし、検索サービスは、その内容が正しいことまで保証してくれません。見つかった記事の著者が誤解している場合もあれば、理解していない場合もあります。そして、ほとんどの場合は最新の情報ではありません。 マニュアルや公式ドキュメントであれば、それ
プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
API Blueprint | API Blueprint
API Blueprint. A powerful high-level API description language for web APIs. API Blueprint is simple and accessible to everybody involved in the API lifecycle. Its syntax is concise yet expressive. With API Blueprint you can quickly design and prototype APIs to be created or document and test already deployed mission-critical APIs. Tutorial Tools section Focused on Collaboration API Blueprint is bu
sora_h の名言がかっこよすぎたのでインターネットに放流 - 宇宙行きたい
id:sora_h の発言が社内ブログにあって、その言葉があまりにもカッコイイし、ドキュメント書かないエンジニアは反省すべきだ（俺含む）！と思ったので許可とって転載 まず一回でいいので、どこかの日に時間を決めて、集中してドキュメントを改善してみませんか。 継続していかなければならないとか、どういう風にすべきか、という議論もあるけれど、まずは取り組みを0から1にするところからはじめませんか。 マジカッコイイ……こういうこと言える大人になりたい
REST APIドキュメント生成パターン - ✘╹◡╹✘
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
REST APIドキュメント作成ツールはapiary.ioが決定版かもしれない - Qiita
背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h
Apiary - r7kamura per second
API(とそれに携わる開発者)の規模が拡大してくると、ドキュメントの整備や、仕様と実装の一貫性の維持、 クライアントとの知識の共有など、考慮すべき問題が沢山出てくる。 これらの問題に対する現実的な解決策を探るため、 ApiaryというAPI開発支援用のサービスを簡単に俯瞰することにした。 ここでは紹介しないが、他に RAML、 JSON Schema、 Swagger、 WADL、 Autodoc などが関連するものとして挙げられる。 Apiary http://apiary.io/ Apiaryは、API Blueprintと呼ばれる言語でAPIのインターフェース仕様書を記述する、という開発方法を提唱している。 API BlueprintはMarkdownを拡張した言語で、特殊な記述を用いて幾つかのメタ情報を付与出来る形になっている。 Markdownを採用することで人間にとって読み書き
Omniref
Omniref is Closed As of January 2017, we've shut down Omniref.com. Thank you for your support over the years. I've preserved the most popular blog posts that I wrote for the site: Ruby Garbage Collection: Still Not Ready for Production What's the most popular Ruby library? Writing Extensions for Firefox is Barely Worth the Trouble Programmers are hipster librarians Making Ruby Faster Matz at RubyC
PiculetでAWSのセキュリティグループをマイグレーションする | DevelopersIO
ども、大瀧です。 AWSのセキュリティグループの設定はちょっとした間違いがサービス停止に直結するクリティカルなものなので、本番環境への適用にはかなり気を使うと思います。今回は、そんなセキュリティグループの設定を強力にサポートするPiculetというツールをご紹介します。 概要 Piculetは、弊社ブログで以前ご紹介したRoadworkerと同じGenki Sugawaraさんが開発する、セキュリティグループの設定をRuby DSLで管理できるコマンドラインツールです。 プロジェクトURL : winebarrel / Piculet — Bitbucket Ruby DSLでセキュリティグループを記述できるので、日々のセキュリティグループの運用をgitなどと組み合わせてコードベースで管理できることが特徴です。なお、今回はバージョン0.1.4で検証しています。 セキュリティグループのマイグ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
esaを使って暗黙知を減らす取り組み
Real World PlantUML
GitHub - smartlogic/raddocs: Rspec Api Documentation Browser
GitHub - r7kamura/autodoc: Generate documentation from your rack application & request-spec.
Middleman: Hand-crafted frontend development