100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
1リリース6,108行から18行へ。ビッグバンリリースを改善した話 - CARTA TECH BLOG
CCI の小坂です。 担当プロダクトの中で、以前からの課題だった ビッグバンリリースを改善したことについて書きます。 開発システムの概要 やってることはCCI の社内システムの開発で、媒体社から提供された媒体資料をもとに、原稿規定を データベース化しています。 データベースをもとに、原稿素材の規定チェックから管理までを行うことができるツールです。 技術スタックとしては バックエンドがJava,Spring Bootフロントが Vue.js,Nuxt.js を使ってます。 これまでの開発フローと課題感 リリースは2-3ヶ月ごとのリードタイムがあった 開発周りのお話です。以前の開発フローは以下です。 - ユーザー要望を issue に起票 - 1-2 ヶ月で開発を行い、ステージング環境で動作確認 - その後にリリース判定 - ビジネスサイドにリリース時期を共有し調整 - リリース この流れを
チームでフレームワークのバージョンアップに立ち向かうための考え方 - CARTA TECH BLOG
こんにちは、こんちゃん(@konchanSS)です。 Zucks アドネットワークでは広告配信プラットフォームの開発をしています。その中で、マイクロサービス的にいくつものサービスに分割されて運用されています。 techblog.cartaholdings.co.jp Zucksが大切にしているエンジニア文化はこちら 今回は、管理画面サービスで行ったフレームワークのバージョンアップについて書いていこうと思います。特に、進め方、考え方について伝えます。 今回バージョンアップを行ったのは、SymfonyというPHPのフレームワークです。 目次 バージョンアップにおける考え方 バージョンを上げて終わりではない。いかに上げやすく作っておけるかが大事 人の手による作業をできるだけ発生させない ユニットテストとE2Eで動作を担保する バージョンアップする際にビッグバンリリースをしない バージョンアッププ
仕事でバックエンド開発するときに考えていること: 実践編 - CARTA TECH BLOG
はじめに こんにちは、fluctでエンジニアをやっているyanyanです。 この記事は、仕事でバックエンド開発をするときに考えていること の続きです。 前回のスライドでは、私がバックエンド開発をするときに大事にしている考え方や思想の話をしました。今回は、じゃあそうした思想の下で実際にどういうものを私が作ったかという話をしようと思います。なので、この記事を読む前にスライドの方を読むことをおすすめします。 speakerdeck.com 何を作ったの？ すごいざっくりいうと、顧客向けWebサービスのバックエンド部分を0からつくりました。 0からと言っても、インフラ部分に関してはすでにあるECSサービスにタスクを追加するだけという形を取りましたが、アプリケーション開発というスコープでいうと技術選定からやり始めました。 どんなサービスなのか fluctが広告配信をしたり、運用支援をしている媒体社が
今さら聞けないオークション理論とDSP入札ロジック - CARTA TECH BLOG
こんにちは。DSP(Demand-Side Platform)配信ロジックの開発に携わる新卒2年目の若手エンジニアohyan(@ohyan)です。 DSPはその名の通り、広告主や広告代理店など広告を配信したい側が使うインターネット広告配信プラットフォームです。媒体社(メディア)の広告枠を持つプラットフォームも存在していてSSP(Supply-Side Platform)と呼ばれます。DSPとSSPはRTB(Real-time Bidding; リアルタイム入札)で広告枠と広告のエクスチェンジを行っています。 この記事は、RTBの土台であるオークション理論および当社のDSPの入札ロジックについて説明します。 目次 目次 RTBについて オークション理論 財の価値 オークションタイプ RTB入札戦略・ロジック セカンドプライスオークション ファーストプライスオークション 入札ロジックの開発 ま
動的解析を利用し、実働6日でレガシーコードを1/3削った話(Perl編) - CARTA TECH BLOG
こんにちは！株式会社VOYAGE MARKETINGで働くエンジニアの yopidax です。 約20年ほど続くサービス、ECナビの技術的負債の返済に取り組んでいます。 ecnavi.jp 今回は直近で、レガシーコードを大量に削除したので、そのアプローチをご紹介したいと思います。 目次 目次 解析の対象と抱える課題 アプローチ 実行されるファイルを洗い出す ログを出力するモジュール 実行 ログのサンプル いざ、大量削除 Perlファイルをgrepする リリース単位を細かくする 結果 工数 実績 まとめ 合わせて読みたい 解析の対象と抱える課題 ECナビを長年支える、Perlで書かれたバッチが対象です。コードはGitLabのリポジトリで管理されていて、規模をまとめるとこんな感じです。 ファイルの数 バッチ関連全体 : 3,315 うち、Perlファイル(.pm, .pl) : 1,111 P
面接時に見ているポイント - CARTA TECH BLOG
こんにちは、CTO歴も丸9年以上になりました @makoga です。 Podcastや勉強会で話をしたときに好評だったので、今回は私が面接時に見ているポイントを書きます。 ※この文章の元ネタは2016年1月に社内に公開したものです。 面接時に見ているポイント 3行まとめ 事実と意見を分けて説明できるか 実際の課題を解決しようとしているか 技術をどう理解しているか この文章の目的 30分から1時間の面接で一緒に働きたいかを判断するのは難しいことです。私も経験を積んで学んできました。 まだ経験が浅い面接官に私が実践していることを伝えることでVOYAGE GROUP全体の判断の精度を上げていくのが目的です。 事実と意見を分けて説明できるか 圧倒的にこれは重要。これができない人はかなり厳しい。 関わったプロジェクトのなかで、自身が一番活躍できたと思うプロジェクトについて聞く 学生の場合は1人で個人
デブサミ2019講演「レガシーとのいい感じの付き合い方」の資料を公開します。 - CARTA TECH BLOG
ポイントメディア事業本部の福田です。 Developers Summit 2019にて、「レガシーとのいい感じの付き合い方」と題して、ECナビの4年に渡る改善事例を発表しました。 講演資料を公開します。 セッション詳細 event.shoeisha.jp 公開資料 当日の反響(togetter) togetter.com 発表を終えて ネタが地味目なので、当日どれくらい来ていただけるのか少し不安でしたが、満員＋立ち見の盛況でした。 当日ご参加いただいた方、ありがとうございました。 アイスブレイクとして、会場のみなさんには「何年もののレガシーシステムに取り組んでいるか？」について質問させていただいたところ、「10年以上」という方が半数超え(※壇上からの主観です）で、レガシーシステムの問題は顕在化していることを実感しました。 目立たずに水面下でじわじわと苦しめられてる問題だと思うので、私達のよ
大量データの転送にEmbulkを使ってみたら本当に楽だった - CARTA TECH BLOG
はじめまして。Zucks Affiliateでエンジニアをしている宗岡です。 今回は、リアルタイム性は求めないけど、簡単に大量のデータをどこか別の場所に転送したい。 という要望に答えてくれるEmbulkを紹介したいと思います。 実際に導入に至ったきっかけや、運用上よくある課題なども触れていきたいと思います。 同じ境遇の人が「簡単そうだしEmbulk使ってみようかな」となっていただければ幸いです。 目次 目次 背景 Embulk以外にも出てきた案 実際のEmbulkの導入と使い方 1. Embulkのインストールとセットアップ 2. 必要なプラグインのインストール 3. 設定ファイルを書く 実務でcodecommitを使った例 設定ファイルの書き方 4. まずはpreviewで問題なさそうか確認 5. 問題なさそうなのでrunして実行 Embulkの運用上、よくぶつかる課題 1. 重複に気付
チーム状態をスムーズに変えて障害対応のコストと精神的負荷を抑える - CARTA TECH BLOG
こんにちは。 @at_grandpa です。普段はバッチを書いたりメンテナンスをしています。 今回は、先日起きた障害対応の時、チームの状態をスムーズに変えることで対応コストと精神的負荷を抑えられた、ということを書きます。 目次 目次 障害発生 普段の対応 今回の対応 原因究明と現状把握 関係者が会議室に集まる 対応用Slackチャンネルを開設 ペアワークで実対応 落ち着いたら自席&Slackコミュニケーションへ移る 対応完了の確認と報告・チケットまとめ まとめ 障害発生 先日の朝に「レポートの数値がおかしい」という連絡がきて確認したところ、とあることが原因で、バッチの自動実行が約半日行われていないことがわかりました。 普段の対応 普段の対応は以下のような形です。 エラー発生をSlackの全体チャンネルで報告 バッチ系チャンネルにて、考えや現状を垂れ流す わからないことがあれば有識者にメンシ
GitHubにおけるPull RequestのAssign/Mergeを自動化して開発を加速させる - CARTA TECH BLOG
皆さんこんにちは. 現在はfluctにてfluct DRという広告配信システムの開発を行っております, 大関です. GitHub上でのチーム開発では, レビューの依頼や, CIが通ったことを確認した上でのPull Requestのマージといった複数の作業が発生しますが, これらはGitHubのUIを複数回クリックする必要があり, 非常にストレスフルな作業です. 本稿では, こうした定形作業を自動化するbotとしてpopukoを開発・導入することで, 我々開発者のストレスを軽減するとともに, より堅牢かつフィードバックの多い開発が実施できるようになった事例を紹介します. GitHubでの開発はとてもクリック操作が多い 前段でも述べたように, GitHubを用いたチーム開発においては, 数多くの定形作業が存在します. コードレビューの可能な人を探してレビューを依頼する, 依頼の度に対象者をAs
バッチ処理の通知・アラート管理 - CARTA TECH BLOG
こんにちは、nekoyaです。 システムを日々運用していく中で、その処理結果の記録や異常検知の仕組みは地味ながらも大切な存在です。 各種監視ツールからの通知や、ブラウザから利用可能なWebインタフェースなど、その形態も様々です。 今回はその中から、バッチ処理の結果通知について、我々のチームが実践している方式をご紹介します。 loggerを通して記録する まず前提として、通知する内容はプログラマ自身が出力することが基本になります。 自分はここ数年はPythonをメインに使っていて、標準のloggingモジュールを通して import logging logger = logging.getLogger(__name__) logger.info('hello!') のようにログを吐いておくと、スクリプトの終了時にそれまで出力したログがいい感じに集約されて通知されるようにしています。 ログレベ
毎週のように依存パッケージを上げ続ける努力 - CARTA TECH BLOG
皆さんこんにちは。fluctにてfluct SSPという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 依存パッケージの更新、どうしてますか？ 今や数多くの言語でパッケージマネージャが提供されており、みなさんも日常的にコミュニティによるパッケージエコシステムを活用していることと思います。 ですが、この依存パッケージの更新については、どのようにしていますか？ セキュリティfixなどを除き、以下のようなことになっていることが多いのではないでしょうか？ チームの「いい人」が頑張って更新し続ける その人の謎の情熱が消えると更新されなくなってしまう たまに気がついたら頑張る 「いい人」が頑張るタイプの亜種 気が付かなかったら更新されない 更新はリスクなので塩漬けにする プロダクトは定期的に作り直す前提 CIでテストを回し続けているのに更新しないなんて……とモヤ
本当に実用的なたったひとつのソートアルゴリズム - CARTA TECH BLOG
コンテンツメディア事業本部の新卒エンジニア坂本がお送りいたします。 突然ですが、皆さんの好きなソートアルゴリズムはなんですか？ 私は基数ソートのスマートでストイックな雰囲気に惹かれます。 とはいえ、普段の開発では「どのソートアルゴリズムを使うか」を意識することは少ないのではないでしょうか。 むしろ現実世界で「トランプが全部揃ってるか」を手作業で確認するときとかのほうが、実はソートアルゴリズムが必要なのかもしれません。 ということで（？）、そのような現実的な場面で、本当に実用的なソートアルゴリズムを決める戦いが始まりました。 選手紹介 今回試したソートアルゴリズムは、独断と偏見で選んだ以下の5種類。 1 挿入ソート シンプル・イズ・ベスト！正直言ってベンチマークの噛ませ犬！ 2 クイックソート 「クイック」の名前はダテじゃない！王者の貫禄を見せてやれ！ 3 マージソート 安定感のある隠れた実
RubyとRailsとMySQLの時刻について - CARTA TECH BLOG
こんにちは！ VOYAGE MARKETINGの @sayadroid です。 最近は、自社の長寿メディアを丸っとリニューアルするプロジェクトに携わっています。 元来PHP, symfony(1.x(小声))で書かれているそのメディアが、 Ruby on Railsで生まれ変わる予定です。 弊社では様々なメディアが、様々な言語で動いているため、 言語の組み込みクラスの仕様をうろ覚えで書くと、 細かな挙動を勘違いしてしまうことなどもあります。 そんな中で、最近ハマったRuby関連の、罠小ネタを一つ紹介します。 前提 Ruby on Rails 4.2.0 server timezone = JST MySQL5.6 timezone = UTC 「質問」テーブル * body: 質問文 * opened_at: 掲載開始日時 * closed_at: 掲載終了日時 要件 opened_at「
Web広告配信における多腕バンディット問題、Mortal Multi-Armed Bandits Problemとアルゴリズム - CARTA TECH BLOG
こんにちは@hagino3000です。Zucks Ad Networkという広告配信サービスの開発をしています。最近はアドネットワークの広告配信最適化に利用できるアルゴリズムの調査もしています。 本稿では調査で読んだ論文の一つ、オンライン広告配信を想定した多腕バンディット問題である、Mortal Multi-Armed Banditsを紹介します。多腕バンディット問題になじみがある読者を想定しています。 papers.nips.cc オンライン広告と多腕バンディット問題 ここでは簡単のために、クリック課金型のディスプレイ広告を前提に説明します。オンライン広告配信システムにおける問題として「最初はどの広告がどれだけクリックされるかわからないが、なるべくクリックされる広告を多く配信したい。」という物があります。これは多腕バンディット問題として知られており、探索はCTRが推定できるまで配信する事
VOYAGE GROUP Engineer's BlogはHatena Blogに移行しました！ - CARTA TECH BLOG
ブログ移行しました！ こんにちは。システム本部 三浦@hironomiuです。 VOYAGE GROUP Engineer's Blogは2010年5月からlivedoor blogでhttp://tech.voyagegroup.com/から発信していました。 約5年続いたブログですが、今回Hatena Blogに移行しVOYAGE GROUP techlogとして出航します！今後更に有意義な技術エントリーを発信出来ればと思っています。 なぜ移行したの？ 常にあるテーマなのですが現場で実践＆適用している技術情報やノウハウ、エンジニアリングの雰囲気を様々な手段で今以上に発信していきたいと考えています。 その中でブログの改善も一つの手段としてあると考え、ブログ移行も選択肢としてあがってきました。 これまで利用していたlivedoor blogに大きく困ることは無かったのですが、Hatena
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
