はてなブックマーク

どうも、サーバーサイドエンジニアの @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

ランサーズ Advent Calendar 2017 4日目の記事です。 インフラエンジニアの金澤です。 少し古いネタになりますが、CloudFrontでサムネイルをキャッシュした手順を記録として残しておきたいと思います。 サムネイルの生成処理について ランサーズは、2012年5月にAWSに移行しました。 ランサーズでは、プロフィール画像や提案画像をサムネイル処理しています。 例えば、ランサーズのコンペの閲覧一覧で閲覧できるロゴ等の提案画像は、圧縮、縮小されたサムネイル画像です。 （オリジナル画像はS3にあり、仕事を依頼したクライアントしか見ることができません） これらのサムネイル画像は、オリジナル画像をImageMagickで圧縮、縮小して表示します。 この処理は大きな負荷がかかるため、一度作成したサムネイルはNFSに保管しキャッシュしていました。 サムネイル生成とキャッシュ ランサーズ

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チームの金澤です。 CakePHP2.8移行が終了し、次のステップとしてPHP5.6化を進めています。 今回はPHP5.6化に向けて行ったCircleCI周りのアップデートについてお話させていただきます。 ※実際のソースは公開したPHP、CakePHPバージョンアップのリポジトリで参照できるようにしています。 導入背景 以前の記事「PHPバージョンアップに向けて現状のソースの品質を担保・向上していく」で コーディング規約の遵守 syntaxの先取り修正 複雑度悪化への歯止め UTの継続実施 の4つを継続的に実施するためにCircleCIを本格的に導入しました。 今回は、PHP5.6バージョンアップに向けて コーディング規約の遵守 UTの継続実施 のアップデートを行いました。 現在のCircleCIの設定 現在はCircleCIをパスしないとソースをマージできないようにしています。 そ