サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
engineer.blog.lancers.jp
ランサーズPdMの市川です。 PdMのキャリアとしては1年目の新米です。日々職歴の長い方々から色々なことを学んでいますが、特に、1on1をしてもらう中での気づきは自分にとって成長の糧になっていると感じます。今回は、その1on1で扱うテーマと、得られていることについて紹介します。 1on1をしてもらっている人 私が1on1をしてもらっている人は、先輩PdMの2名です。 1名は、同じプロダクト開発チームに所属している、メンターに当たる人です。日々の業務でも密にコミュニケーションをとっています。メンターとは毎週2回程度1on1を行い、主に日々の業務の中で発生する課題を解決することに重きを置きながらやっています。 もう1名は、1年目から定期的にコミュニケーションをとってきたPdMの先輩です。月に1回1on1をしています。数日、毎週単位でやり取りするメンターと異なり、1か月単位でキャッチアップや振り
どうも、サーバーサイドエンジニアの @koji9412 です。 最近、色々と話題になっているTwitterですが、ランサーズでもTwitterからXへ表記を変更しても良いのではないかと話が上がりましたので、調査したことや検討したことを報告したいと思います。 同じような悩みを抱えている社内エンジニア、デザイナー、WEB担当者の方が少しでも参考になれば幸いです。 TwitterからXへ Twitter社がX社に吸収合併されて、既にTwitter社が存在しないと世間に発表されたのは2023年月4月11日のことです。当時から「TwitterはXになってしまうのか」と話はあがっていましたがTwitter→Xについてイーロン・マスクが変更を言及したのは2023年7月23日のことです。 And soon we shall bid adieu to the twitter brand and, gradu
こんにちは、フロントエンドエンジニアの谷(@high_g_engineer)です。 本記事では、オブジェクト指向UIデザインの書籍紹介をさせていただきます。 オブジェクト指向UIデザインとは? 2020年6月5日発売の書籍で、アプリケーション開発に関わるすべての人が読むべき、オススメの一冊です。 オブジェクト指向UIデザインは、オブジェクト(モノ、名詞)を起点にしたUI設計手法です。 使いやすく、心地よいユーザー体験のアプリーケーションを実現する為に力を発揮します。 多くの人が行うデザインの手順と問題点 アプリ開発において、ユーザーの要望ベースで改善を進める場合、以下の手順で取り組むことが多々あります。 ユーザの要望を叶えるタスクを考える 上記のタスクに応じたUIを考える 蔵書アプリの場合、以下の様なタスクが考えられます。 本のタイトル、著者、出版社、出版日を登録する 本を検索してすでに持
どうも、ランサーズでProductivity Teamをやっているいさな(@isanasan_)です。 この記事は、Lancers(ランサーズ) Advent Calendar 2022 の10日目の記事であり、開発生産性 Advent Calendar 2022の10日目の記事です。 昨日は@isanasan_さんによるエンジニアである僕が自炊をするときに意識していることと @s977043さんによるEMが気にしている生産性の指標についてでした。 モチベーション 2022年10月に、ついに弊社にもDeveloper Productivity Engineering(DPE)にフォーカスする組織としてProducrivity Teamが発足しました。(詳しくはこちら) 2019年にGradle社が下記のドキュメントによって体系化したDeveloper Productivity Engine
こんにちは、フロントエンドチームの 谷(@high_g_engineer)です。 今週のフロントエンド定例の内容を記載します。 フロントエンド定例について、以前の記事(ランサーズのフロントエンドチームが取り組んでいること)でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。 以下、今週の内容です。 モチベーション Astroの雰囲気を理解する。 概要 2022/8/9 Astro v1.0 がリリースされました。 https://astro.build/blog/astro-1/ 以下、公式からの掲載 Astroとは? Astroは、コンテンツにフォーカスした高速なWebサイトを構築するためのオールインワンWebフレームワークです。 主な特長 サーバーファーストのAPI設計: ユーザーのデバイスから高コストのハ
こんにちは、フロントエンドチームの @syo_igarashi です。 今週のフロントエンド定例の内容を記載します。 フロントエンド定例について、以前の記事(ランサーズのフロントエンドチームが取り組んでいること)でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。 以下、今週の内容です。 フロントエンド定例 2022/5/13 上記の定例以前からデザインシステムでreg-suitを使用したビジュアルリグレッションの実行をしていましたがLokiに変更しました。 理由としてはリグレッションのためにAWS S3などのホスティングなしでGitHubに差分があるスクリーンショットをコミットすれば同様にPRで差分検知できるためLokiに変更しました。 GitHubなのでコミット履歴ごとでの差分を追うことも可能なのもいいです
こんにちは、フロントエンドチームの谷(@high_g_engineer)です。 今週のフロントエンド定例の内容を記載します。 フロントエンド定例について、以前の記事(ランサーズのフロントエンドチームが取り組んでいること)でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。 以下、今週の内容です。 本日から7月ということで上半期が終わりました。2022年も半分が終わりです。 光陰矢の如し、時間が過ぎ去るのは早いですね。 2022年も残り半分ということで、良い区切りなので、 今年に入ってから今まで何をやっていたかを振り返ろうと思います。 1月 年末年始で新プロジェクトでNext.js導入を行う為、技術調査を行う 調査期間が超短期間だった為、諸々の調整がつかずにNext.jsの導入は見送り CakePHPを中心とした
Lancers Engineer Blog をご覧のみなさんこんにちは。開発部/技術基盤 SREの安達(@adachin0817)です。以下前回のブログから3ヶ月経ちましたが、ついにLancersのBatch、AppサーバーをEC2からECS/Fargateに移行完了しました。 そして長年自前で運用していたデプロイシステムを廃止して、CI/CDはCircleCIに完全統一しました。これにて、Lancersの全サービスをコンテナに移行完了となりました。 ※見ていない方はぜひ一読してもらえると幸いです。 ・LancersをAmazon Linux2へログ基盤のリニューアルと管理画面をECS/Fargateに移行しました 旧開発環境、EC2での運用課題 Ansibleコンテナによる開発環境の統一により工数がかかる 本番コンテナ化以前は、EC2で利用しているAnsibleの管理を開発環境にも適用す
Lancers Engineer Blog をご覧のみなさんこんにちは。開発部/技術基盤 SREの安達(@adachin0817)です。最近埼玉で激安マンションを購入しまして、快適な環境でバシバシとフルリモートワークを行っております。今年の目標はより健康的に、ジョギングは毎週続いているので筋トレを取り入れたいと思っております。 さて、ようやくLancers本家の各サーバーをAmazon Linux2化、管理画面をECS/Fargate化、ログ基盤リニューアルを半年で実現できまして、一旦落ち着くことができました。苦労したところなど振り返ってみようと思います。 ※去年12月に以下今期SREチームの取り組みについて書きましたが、見ていない方はぜひ一読してもらえると幸いです。 ・今期SREチームの取り組みについて Lancers本体をAmazon Linux2化するにあたって ・2018年 ランサ
ランサーズ Advent Calendar 2021 10日目の記事です。 Lancers Engineer Blog をご覧のみなさんこんにちは。開発部/技術基盤 SREの安達(@adachin0817)です。今年2月からダイエットを始めていまして、ジョギングを週2~3日習慣付けられるようになりました。15キロ減量しましたが、まだまだ落とせると日々舞い上がっております。他にもCakePHPで個人開発したり、サーバーサイドやフロントにもチャレンジしています。 早朝は極寒だった 5.02キロジョギングしました👟 — adachin👾SRE (@adachin0817) December 9, 2021 さて、直近のSREチームの大きなイベントとしてはランサーズ本体のインフラを改善している最中でございます。まずは上期SREチームで取り組んだことをエンジニアブログを元にまとめていき、最後には
QAチームのいさな(@isanasan_)です。今回は筆者のお気に入りのツールをご紹介します。 モチベーション 先週コードレビューについての記事を書きました。 ジョインから1ヶ月経ちコードレビューで気を付けていることをまとめた こちらの記事の中でrebaseを使ってコミットログを整形することがレビューコストの低下に繋がると書きました。 しかし筆者はgitをcli上で使いこなすのはそれなりに難しいものだと感じており、特にinteractive rebaseは初学者にとって非常にとっつきにくい機能だと思っています。 そこで、今回は筆者が愛用しているgitのクライアントツールであるlazygitを紹介します。本稿ではハンズオン形式でgitの歴史改変の操作を説明していきます。尚、ハンズオンの題材に使ったコードは動作確認などはしていません。本題とは関係ないので細かいツッコミは無しでお願いします。 #
SREチームの安達(@adachin0817)です。以前エンジニアブログにてこんなことを言っていたのを皆様覚えておりますでしょうか。 それ以外のプロジェクトであるLancers Creative、Prosheet、Lancers Agent、MENTAはECS/Fargateに移行しているので、すべてTerraformでコード管理しています。また、CircleCIでTerraform CI(validate,plan)を実行しているということもあり、今後terraform applyもCircleCIで行う予定なので、Deployサーバーでの運用は廃止していく予定です。 今までのTerraform管理方法 そうです。以下のようにTerraformでの運用について課題がありました。 わざわざサーバーを用意したくないのと運用コストが上がる Deployサーバーで管理するのはやめましょうといって
8/11に開催したイベント「[Lancers × VOYAGE GROUP]エンジニア評価制度についての公開雑・相談」では、ランサーズVPoEの倉林とVOYAGE GROUP(CARTA HOLDINGS)CTOの小賀さんによる、リアルな雑談・相談の様子をライブ公開しました。 テーマのエンジニア評価制度は多くのエンジニア組織がぶつかる課題です。 ランサーズではLancers Open & Flat Recruitingというプロジェクトを発足し、エンジニア組織・採用の改革を行っており、その中でも評価制度は避けては通れない課題です。そんな中で独自の技術評価制度を実施し、また10年以上に渡って改善を繰り返しているVOYAGE GROUP(CARTA HOLDINGS)の取り組みを聞きながら、自社に合った評価制度の形を探すために実施したのが本イベントです。 今回の記事では、当日の雑談・相談の内容
SREチームの安達(@adachin0817)です。今回はMENTA、Lancers Creative、Lancers Agencyでマスキングした本番環境のデータをStgや開発環境のMySQLコンテナへ毎週リストアする仕組みを実装しました。実際にここらへんは運用をしていく中で一苦労されている方も多いのではないでしょうか。それではまず背景と、実装するに当たっての活動含めてご紹介できればと思います。 背景 今回はMENTAを例にしています。各サービスの開発環境はDockerを利用しており、本番とStg環境はTerraformで管理しています。カラム追加ではマイグレーションを実行することでサンプルのスキーマファイルを投入して開発をしているのですが、たまに開発環境で動いていたソースがStgや本番で動かないといったことで開発効率が下がることが見受けられます。開発メンバーにとってはより本番環境に近い
SREチームの金澤(@yakitori009)です。 社内開発用にSendGrid用のMailモックコンテナを作りました。 開発環境の構成 検証AWS環境の構成 今回、その経緯と内容について書きたいと思います。 Mailモックコンテナについて 開発環境におけるメール送信テストで最も気を付けるべきことはメールの誤送信です。 メールの誤送信は、最も発生件数の多いセキュリティインシデントの1つで、 開発中のメール誤送信も対策が必要で、最低限、以下の処理を行っておく必要があるでしょう。 DBデータのマスク処理 メールアドレスを存在しないメールアドレスにマスクする メール送信処理をモック化する 実際のSMTPサーバーに飛ばさず、ダミーのSMTPサーバーに吸収させる ダミーのSMTPサーバーとしては、MailTrap等のサービスが有名ですが、最近では、メールモックのDockerコンテナを使う事例も増え
SREチームの安達(@adachin0817)です。最近ではランサーズ本家のインフラをコンテナに移行しまくっております。今回ランサーズとMENTAで運用しているEC2/分析基盤サーバー(Digdag + Embulk)をECS/Fargateに移行完了しました。では早速概要と苦労した点、今後の展望などを振り返っていきたいと思います。 分析基盤の紹介 > ランサーズの分析基盤(capybara)と運用について紹介 > MENTAをAWSに移行しました ちなみに私が入社して3年経つのですが、運用して変わったことは3年前よりデータの量が膨大になっていることと、現在、社内の分析チームにとって欠かせないシステムとなっております。その中でDigdagによるスケジューラーとEmbulkによるマルチソースバルクデータローダーである分析基盤専用のEC2サーバーがあり、毎日夜中にデータをBigQuryにシンク
SREチームの安達(@adachin0817)です。今回WordPressサーバーであるEC2からECS/Fargateに移行しましたが、紆余曲折を得て、苦労したところ、技術的な部分、最終的には複数のリポジトリを一つにまとめたことなどを紹介したいと思います。まずはプロジェクトとサーバーの構成から説明していきましょう。 ランサーズのWordPressとECS時代のサーバー構成 https://engineer.blog.lancers.jp https://info.lancers.jp https://l-ap.jp https://connect.lohai.jp https://lohai.jp https://tips.lancers.jp https://www.lancers.co.jp https://www.lancers.jp/assistant/cases https:/
SREチームの安達 (@adachin0817)です。ランサーズやグループ会社ではTerraform v0.12.29を利用して、AWSのインフラコード化をしています。ようやくグループ会社すべてAWSに移行が完了となり、次なるチャレンジとしてはTerraformのバージョンアップを対応することとなりました。また、以下4/15にv0.15.0もリリースされたということもあり、非常に良い機会となりました。 まずは各プロジェクトについて簡単に説明をしていきたいと思います! Terraform 0.15 is out, which can also be considered a pre-release for 1.0 if all goes well. ✨ It’s finally happening! Great quality of life improvements around Wind
皆さんこんにちは。SREチームの安達(@adachin0817)です。去年10月にMENTAがランサーズにグループジョインされて、本日AWSへ移行が完了しました。この5ヶ月間どのような取り組みをしたか、改めて振り返ってみようと思います。 AWSへ移行する前 移行前の環境 ・https://menta.work ・さくらのクラウド ・PHP 7.2 / Laravel 5.5 ・Nginx / MariaDB /Redis ・SendGrid ・開発環境 ・Docker ・リリース方法 ・SSHによるシェルスクリプト ・移行プロジェクトメンバー 元々MENTAは2018年にリリースしてからさくらのクラウドで運用していました。また、ランサーズにグループジョインする前は私が副業でサーバー保守していたということもあり、本番環境、Staging環境、Redash環境の3つで管理していましたが、デプロ
SREチーム、QAチームの金澤です。 昨年より、CakePHP2→CakePHP3の段階的バージョンアップに取り組んできましたが、 バージョンアップ対象をCakePHP3からCakePHP4に変更しました。 CakePHP2→CakePHP4にターゲットを変更する CakePHP3へのバージョンアップを開始したのは、2019/8です。 ※バージョンアップ開始時のブログはこちら。 この時はまだCakePHP4は正式にリリースされていませんでしたが、 CakePHP2→CakePHP4へのジャンプアップできるか調査したところ、 PHPUnitのバージョンが合わず、見送っていました。 CakePHP2で利用できるPHPUnitの最新バージョンはPHPUnit5.7です。 CakePHP3では、PHPUnit5.7が共存できたのですが、 CakePHP4で利用できるPHPUnitの最低バージョンは
皆さん元気ですか!?SREチームの@adachin0817です。去年から行っていた移行プロジェクトで、グループ会社である、シクロマーケティング株式会社の「ミギウデ」をさくらVPSからAWSへ移行しました。今回、移行背景やECS/Fargateでのコンテナ運用について簡単にご紹介と振り返りを行ってみたいと思います。 なぜAWSへ移行するのか AWSへ移行すると冗長性の担保などが挙げられますが、一番は開発環境やインフラなど、すべてランサーズに統一させるということが第一の目的です。それに伴い、ミギウデ自体のサービスがシンプルなインフラ構成ということもあり、インフラ運用の手間をなくしたいということから、ECS/Fargateで初の外部サービスとしてコンテナ運用にチャレンジしてみようとなりました。 目的とコンテナ化にするメリット ・内部統制対応 ・S3、RDSを利用したバックアップ ・CloudWa
こんにちは!QA (Quality Assurance) チームの まみー です。入社してもうすぐ3ヶ月。早いものです。 ところでみなさん急ですが… スロークエリ見てますか? インデックス貼ってますか? そのインデックス、本当に使われてる? お話しすること 複合インデックスを作成したのに、別の複合インデックスが使われてしまう。 Why…なぜに… その理由を知ることができる オプティマイザトレースの使い方 をお話しいたします。 すぐに使い方を読みたいというかたは コチラ からご覧ください。 こんなことありませんか? 実際に以下の現象が発生していました。 1テーブルだけの JOINが遅い 解決のために インデックス貼った インデックス貼ったのに 解決しなかった 実行計画(EXPLAIN)を見たら 違うインデックスが使われていた スライド紹介 2月に開催した Lancers x ROBOT PA
CakePHP Advent Calender 2019 最終日の記事です。 SREチームの金澤です。 2019/12/16にCakePHP4がリリースされました。 ランサーズでは、CakePHP2.10の現システムをCakePHP3に移行中ですが、 同時に、管理画面のソースを別リポジトリに分割し、 CakePHP4で新規構築するプロジェクトも進めています。 CakePHP3で開発をしていたのですが、 CakePHP4が正式リリースされたので、CakePHP4にmigrateしました。 今回、その手順を記録しておきたいと思います。 composer.jsonのCakePHP4対応 CakePHP4.0にアップグレードするためにcomposer.jsonを修正します。 案の定ですが、単純に "cakephp/cakephp": "^4.0", として、composer updateしても依存
SREチームの金澤です。 ランサーズのサムネイル生成をAPI Gateway + Lambdaのシステムにリニューアルしました。 今回、その内容について書きたいと思います。 以前のサムネイル生成処理 今までのサムネイル生成処理は、Appサーバー内でImageMagickを起動して行っていました。 img.lancers.jpのURLにアクセスしたタイミングで以下の処理を実行していました。 S3から元画像をダウンロード ImageMagickのconvertコマンドでサムネイルを生成して表示 その結果をCloudFrontにキャッシュ ※これらの処理については以前のブログに詳しく書いています。 以前のサムネイル生成処理が引き起こしていた問題 このImageMagickによるサムネイル生成処理は、サービスリリース直後に実装されたもので、ほとんど手が入らないまま10年以上運用されていました。 し
SREチームの金澤です。 PHP5.6→7.3バージョンアップが完了しました。 PHP5.3→5.6バージョンアップが完了してから約2カ月での移行となりました。 今回、その対応内容と結果を報告したいと思います。 バージョンアップ準備 PHP7化については、有用な記事が数多くありましたので、まずはそれらを参考にさせていただきました。 CakePHP2.10化 PHP5.6化後のライブラリアップデートのタイミングでCakePHP 2.8から2.10にバージョンアップしました。 CakePHP2.9のタイミングでObjectクラスが非推奨になったため、CakeObjectに名前変更しました。 ※PHP7ではObjectが予約語になります。 廃止、非推奨となる関数の対応 対応が必要だったのは主に以下の関数です。 __autoload ereg_* eregi each mysql_* split
SREチームの金澤です。 PHP5.3→5.6バージョンアップが完了しましたので報告いたします。 CakePHP1.3→2.8バージョンアップが完了してから約2カ月での移行となりました。 2019/03/20にコネヒトさんで開催されたPHP勉強会で、その詳細について発表させていただきました。 (このときは管理画面、バッチサーバーまで移行完了していました) PHPのバージョンアップ自体は3月中に完了していましたが、その後関連ライブラリのバージョンアップも併せて行いました。 バージョンアップに向けたCI改善 2019/2/5にCakePHP1.3→2.8バージョンアップが完了し、その後すぐにCI周りの改善に取り掛かりました。 その詳細をPHP5.6化に向けたCircleCIのアップデートにまとめています。 目的は以下の2点です。 PHP5.6の文法に対応する @PSR2を設定 @PHP56Mi
SREチームの金澤です。 CakePHP2.8移行が終了し、次のステップとしてPHP5.6化を進めています。 今回はPHP5.6化に向けて行ったCircleCI周りのアップデートについてお話させていただきます。 ※実際のソースは公開したPHP、CakePHPバージョンアップのリポジトリで参照できるようにしています。 導入背景 以前の記事「PHPバージョンアップに向けて現状のソースの品質を担保・向上していく」で コーディング規約の遵守 syntaxの先取り修正 複雑度悪化への歯止め UTの継続実施 の4つを継続的に実施するためにCircleCIを本格的に導入しました。 今回は、PHP5.6バージョンアップに向けて コーディング規約の遵守 UTの継続実施 のアップデートを行いました。 現在のCircleCIの設定 現在はCircleCIをパスしないとソースをマージできないようにしています。 そ
SREチームの金澤です。 1年以上かけて取り組んできた、CakePHP1.3→2.8バージョンアップが完了しましたので報告いたします。 ランサーズ社のCakePHPの取り組み ランサーズは現在11年目ですが、永らくバージョンアップをしておらず、PHP 5.3 + CakePHP1.3の環境で稼働していました。 2017/2に全社的にバージョンアップを決断し、その後の取り組みをまとめたものが以下になります。 2017.05.26 PHP、CakePHPバージョンアップの決断 2017.06.12 PHPカンファレンス福岡 2017に登壇しました 2017.06.27 PHP, CakePHPバージョンアップに向けてCIで品質を担保・向上していく 2017.09.05 ランサーズのNginx+PHP-FPM化 2017.10.10 PHPカンファレンス2017 に登壇してきました 2017.1
CREチームの保坂です。 Lancers(ランサーズ) Advent Calendar 2018 11日目の記事になります。 ランサーズでは今年からCREというチームを発足しました。 SREチームの発足については以前の記事で紹介されています。 CREはCustomer Reliability Engineeringの略でエンジニアリングで顧客信頼性向上させるチームとなります。 成り立ち もともとは一人でお問い合わせの調査や改修対応をしていましたが、フォローのためメンバーが集結されCREチームとなりました。 さらにエンジニアだけでなく関わりとしてカスタマーサポート(CS)メンバーやデザイナーも協力いただき進められています。 最近ではインターン生も二人参加していただいています。 チーム体制になったことにより、それまで後回しになってしまっていた仕様や機能の改善も進められるようになりました。 CR
次のページ
このページを最初にブックマークしてみませんか?
『ランサーズ(Lancers)エンジニアブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く