こんにちは！スマートキャンプエンジニアの井上（エース）です！ 皆さんは自社プロダクトに対してどのようにデータ分析をされていますか？ データ分析基盤は構築されているものの、少なからず課題を抱えている企業も多いかと思います。 今回は弊社のBOXIL SaaSに新しいデータ分析基盤を導入することになったので、その背景や導入にあたって課題だったこと、その対策などを書いていこうと思います。同じようにデータ分析基盤を導入しようとしている方の参考になれば幸いです。 元の基盤の課題 クエリの乱立とデータ定義のバラつき クエリ作成依頼についてのエンジニアの対応コストが高い データ分析ツールの統一 パフォーマンス 新しいデータ分析（BI）ツールに求められたもの Lookerの選定理由 LookMLによる統一的な管理 ドキュメントの充実度 プルリクベースでの開発 実際のアーキテクチャの紹介 導入にあたって課題だ
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
最近脆弱性の話とか本業と一切関係ないことを書いていたので、今回は本業に関する話です。 前提 所感 楽しい やりがいがある 実績になる 得意な形でアウトプットできる 勉強になる 深く特定領域を学べる 得た知見を公の場で共有しにくい 広く触れない（可能性がある） なぜ会社としてOSSをやるのか？ということを真剣に考えられる 市場の熟成 有料化のしやすさ 品質の向上 カンファレンスでの発表 ファンを作る 会社の売上に貢献できる方が精神的に楽 ユーザからのフィードバックが助かる メンテナンスコストが高くなる 方針を決められなくなる 宣伝は必要 まとめ 2019/08/01にOpen Source Engineerという肩書になってから既に1年が経過しました。そういうポジションの人はまだ日本では少ないんじゃないのかなと思ったので何か参考になればと所感を書いておきます。ちなみに最初の頃Open Sou
今日はPHP製のデプロイツールの紹介です。デプロイツールとはCapistranoみたいなツールのことです。コマンド一発でデプロイが完了するようにするツールです。 PHP製のツールもいくつかありますが、Deployerは非常にシンプルなツールで、最近3.0がリリースされました（最新版は3.0.4）。 https://github.com/deployphp/deployer/releases/tag/v3.0.0 より。 インストールが簡単 公式サイト http://deployer.org/ へアクセスし、deployer.pharをダウンロードするだけです。 公式には/usr/local/bin/depにインストールすると書いてありますが、プロジェクトのフォルダに突っ込んでも問題ありません。 私はプロジェクトのルートにdeployというフォルダを作成し、そこに関連するファイルをまとめるこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
