クラウドソーシングで最大手のクラウドワークスでマネージャーをしてます。@ouraです。 みなさん毎日グラフをみてますでしょうか？ エクセルや Google スプレッドシート直接開いてみるのも良いですが、せっかくチャットを使っているのなら活用しましょう！ということでこのエントリです。 定期的にグラフをチャットで見えるようにすることで、こんなメリットがあります。 目標へ向かう意識の強化 現在位置の見える化 関わるメンバーの一体感醸成 前提条件 かなり限定的ですが、私の観測範囲では割りと同じ環境の会社さんが多いかと思われます。 Slack を利用している Google スプレッドシートでグラフをみている セキュリティ上の理由で Google スプレッドシートの公開範囲が組織内に制限されている 手順 GAS(Google Apps Script) を利用してポストします。 そして利用する Slac

こんにちは！ 去年の４月に新卒入社してからお酒ばかり飲んでいるエンジニアのd4teです。 4月から11月まではUX改善チームにてお仕事検索画面のフロントエンド開発を担当しておりましたが、11月からはリファクタリングチームにてcrowdworks.jpのリファクタリングをしています。 現在のcrowdworks.jpの状況 過去の記事にもあるように、crowdworks.jpはサービスインから約8年が経過し、30万行を超えるモノリシックなRailsアプリケーションになってきていて、コード行数の増加量やファイル変更数の推移は年々鈍化してきています。 内部には開発生産性を低下させる技術的負債が溜まってきており、技術的な投資がしづらくなってきているという課題があります。 自分が所属しているチームは、外部から見た動作を変えずに内部のコードを整理するリファクタリングで技術的負債を解消し、開発生産性の向

はじめに SREチームの @minamijoyo です。 先日 CrowdWorks (crowdworks.jp) の本番環境のRailsアプリケーションを Docker (AWS ECS: Elastic Container Service) に移行しました。 CrowdWorksは2012年にサービスを開始し、2019年10月現在、ユーザ数は300万人、月間で数億円規模のお仕事がやりとりされる、国内最大級のクラウドソーシングプラットフォームにまで成長しました。 サービスの規模拡大に合わせて、ソースコードも数十万行規模に成長し、 決して小さくはない規模のRailsアプリケーションに成長しました。 CrowdWorksの開発環境にDockerが導入されたのはもうかれこれ3年半前の2016年の4月頃、2017年1月頃にはCrowdWorks本体から切り出された一部の機能で本番環境に投入され

エンジニアの @suusan2go です。2017年の10月まではクラウドワークスに社員として参画していましたが、現在はフリーランスのエンジニアとして、主にフロントエンド環境の改善・支援を行ったり、ちょっとだけRailsのアップグレードを手伝ったりしています。 Railsのアップグレードを手伝っている様子 Sprocketsを2=>3にあげると数倍メモリ消費増えるのなんなんだろな— すーさん二号 次に夜飲みにいけるのは8月ごろになります (@suusan2go) 2019年5月7日 Sprocketsがメモリを大量に消費する問題、結局よくわからんかったので、馬鹿でかいjsを生成する js.erb をなんとかした— すーさん二号 次に夜飲みにいけるのは8月ごろになります (@suusan2go) 2019年5月17日 今回は、わかるエンジニアがいなくなり無人化してしまいメンテナンス不能になっ

⠀人 / ⁰⊖⁰ \ オカメインコエンジニアの五十嵐(@ganta0087)です。 CrowdWorksでは、サービスのCI環境としてCirlceCIを利用しています。 今回、CircleCI 1.0から2.0に移行すると同時に、新機能のキャッシュをフル活用したことで、コストを増加させることなくCI実行時間を半分にすることができました。 今回の記事では、CirlceCI 2.0のメリットや、どのようなチューニングを行ったのかをご紹介します。 CircleCI 2.0について CircleCI 2.0は現在ベータ版となっており、「CircleCI 2.0: Beta Access - CircleCI」から申し込むことができます。(試してみたところ個人のリポジトリではすぐに利用できるようです。) 申請したOrganizationのすべてのプロジェクトで突然バージョンが切り替わるわけではなく、

最近機動戦士ガンダム0083スターダストメモリーを一気見したエンジニアの那須（@nasum）です。好きなガンダムはExSガンダムです。リフレクターインコムかっこいいですよね（アイスブレーク）。 普段働いているとPCを使う以上様々なソフトウェアやサービスを使うと思います。DropboxやEvernote、Google Driveにスプレッドシート、エクセルからパワーポイントまで様々です。 そんなとき、「社内で使われているこのサービス、目的を果たすにはちょっと面倒だな」なんて思ったことはないでしょうか？ 自分が目的を果たすために、フラストレーションを感じてしまうのであればなんとかしたいものです。そういうとき無料のサービスを利用することや、オープンソースのソフトウェアを導入することをまず考えると思います。しかしなかなか自分の要件にフィットするサービスは意外にもなかったりします。 そういうときは勢

ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ

こんにちは、AdventCalenderでノリで書いた記事が思わぬバズりを見せてしまい戸惑いを隠し切れない野村です。 当社では、今年の1月から週2回ペースでエンジニアブログを更新し続けています。 実はブログの開設自体は2014年8月と、今から1年半も前のできごとなのですが、色々なやんごとなき事情（「面倒くさい」「忙しい」「ネタがない」）によりあまり更新できていませんでした（2015年12月までで合計17記事、月1回ペース）。 更新する人も限られており、「これではいかん！」ということで、色々と体制を整えました。 その結果、現在は2016年1月だけで12記事の更新と、まずまずうまく行っていますので、やったことを公開したいと思います。 その1. 当番制にした はい、いきなり身もふたもないですが、これ重要です。 いくつかの目的のためにブログ更新強化を決めたとはいえ、「みんな他にやることあるし、強制

心はプログラマ、仕事はマネジメントのつもりの安西です。 技術的なお話は他の皆様に任せて、今日はクラウドワークスのエンジニアチームのお話をしてみようと思います。サービス開発（というかソフトウェア開発自体も）は、複雑でしかも100%明確な答えが見えにくい世界です。日々答えの無い中の選択で、苦しくもあれば楽しくもあります（笑）。 そんな中で、どんな環境で進めているかを一部ご紹介してみます。 許可を求めるな謝罪せよ。 推奨している価値観です。どんどんやる。何か課題があればどんどん変える。 学習を推奨する：ポインヨ制度 個人があるいはチームが向上したり、やったことが無いことに挑戦するには、インプットを続ける必要があります。そこで、例えば勉強会開催、参加、講師などを行うことを点数（ポインヨ制度）化して見える化しています。 ところでポインヨって…？ チーム開発（スクラム） チームで開発しており、開発プロ