shin ( @nagatashinyalan )です。
先日、BASEさん、ReBuildさん、ランサーズ で、「レガシーコード改革！UT/CIでWebサービスの技術的負債を解消する取り組み」 というイベントを開催し、そこで登壇しましたので資料を公開します。
エンジニアのshinです。
ランサーズでは4月から、ゲストを招いてランチを食べながら話をするランサーズ開発ランチ(Lunchers)という取り組みを実施しています。
5/16に実施した第3回の内容をご紹介します。
合同会社ねこもりの高橋邦彦(@kunit)さんをゲストに迎えて、PHPのバージョンアップの話をして頂きました。
昨年のPHPカンファレンス福岡で弊社の金澤が登壇することになり、事前にPHPバージョンアップの意気込みをブログにアップしました。
その際に多くの有識者の方々からありがたいコメントを頂いたのですが、その中で一番するどいコメントだったのが高橋さんでした。それがきっかけで弊社主催のCakePHP勉強会に参加頂いたりして情報交換するようになりました。
そして今回、ランサーズ開発ランチのゲストとしてお声がけしたところ快く引き受けてくださったという経緯です。
ここからがお話し頂いた内容になり、そのときのスライドがこちらです。
具体的なお話として、PHPバージョンアップを進めているBASE株式会社さんの発表スライドを使って、パフォーマンスがどの程度改善したかのグラフを紹介していただきました。
(高橋さんはBASE株式会社さんのPHPバージョンアップ作業に関われています)
こちらに記載がありますが、PHP5.3→5.6に上げた際のパフォーマンス改善が顕著に表れたそうです(P38)。
PHP5.5以上ではOPcacheというキャッシュ機構の恩恵を受けることができたことが大きく、その他の施策も含めると、処理時間が約4割減になったそうです！驚異的。
PHP7に上げたときもさらにパフォーマンスが改善して、サポートメンバーからも体感的にも速くなったと言われたそうです。
実は自分たちが書いたコードは意外に素直なので、それほど書き換えは多くなく、フレームワークやライブラリの影響で書き換える方が多かったそうです。
注意点としては、PHPマニュアルの付録にあるバージョンごとの変更点は熟読しておくべきとのこと。
使っているエクステンションがどのバージョンまで対応しているかも確認しておく。memcacheとmemcachedのように移行が必要になるものもあるそうです。
PHPのバージョン間の互換性は想像以上に高いことがわかったが、それで一気にあげようとすると対処する項目が積み重なってくるので、日々追従していくほうがおすすめ。
php7ccやPHP Compatibilityのような互換性チェックツールをかけて動く状態を作っておく。
最後におっしゃっていた、「自分たちの都合に合わせてフレームワークを持っていく」という名言が印象的でした。
最新のバージョンに上げることで、エンジニアがPHPやフレームワークに対してPRを送るようになり、モチベーションが上がるという良いサイクルができそうです。
開発ランチ後に社内の参加メンバーにアンケートを取ってみたところかなり好評でした。
BASEさんのPHPバージョンアップについては、開発チームブログの方もご参照ください。
http://devblog.thebase.in/entry/2018/03/20/170050
ランサーズ開発ランチは、始めたばかりの取り組みですが、一緒に会話してランチをして頂けるゲストの方を募集しております。ご興味がある方はお気軽にご連絡ください。
ランサーズ Advent Calendar 2017の17日目担当のshinです。
今年は新しいことに取り組む機会も多かったので、身の回りの環境など変えて効果があったものを紹介したいと思います。
引っ越しという具体的な行動を起こすことから始まり、様々な変化につながっていったように思います。
自分を変えながら成長していくと共に、lancers.jpというプラットフォームも変わりながらより良いものへと成長していきます。
来年もさらなるチャレンジをしていきます！
こんにちは、エンジニアのshinです。
最近使ったAWSの機能が便利だと思ったので紹介します。
ランサーズでは、Amazon S3の静的ウェブサイトホスティングの仕組みを使ってコンテンツを公開しています。
まずこれが便利で、静的ページをカンタンに公開できるというメリットがあります。
一方で、便利がゆえにとりあえずアップして、
その後不要になったコンテンツが残り続けてしまうというデメリットも出てきました。
今回、lancers.jpのトップページリニューアルのタイミングで情報設計の見直しを行い、
ある静的ページのURLを変更したいという要望が出てきました。
旧URLへの導線は全て変更したものの、送信済みメールからのアクセスなど
網羅性を担保するためにはリダイレクト設定する必要があります。
これまでは、静的ページにリダイレクト設定したい場合、meta refreshやJavaScriptを使う方法にしていましたが、
S3ではバケット単位でのリダイレクト設定以外にウェブページリダイレクトというページ単位での設定が可能であることがわかりました。
しかも、マネージメントコンソールからカンタンに設定できます。
例として、S3にホスティング済みの「a.html」を「http://www.lancers.jp/」にリダイレクト設定する手順を以下に記載します。
おわり。
注意点としては、301リダイレクトのみ対応(2017/7/6時点)していますので、
302リダイレクトをやりたい場合は別の方法を検討する必要があります。
今回のブログ記事を書くにあたり、下記サイトの情報を大変参考にさせて頂きました。
ウェブページリダイレクトの設定 – Amazon Simple Storage Service
Amazon S3 でリダイレクトを扱う ｜ Developers.IO
こんにちは、エンジニアのshinです。
アジャイル開発を良いマラソンランナーに例えるなど、開発をマラソンに例えることはよくあります。
私自身も以前から、開発とマラソンには共通点があると感じており、
今回は、ランサーズで実施しているスクラム開発をハーフマラソンに取り入れてみるという逆のアプローチを試みましたので紹介します。
マラソンは、計画的な練習など準備が大きな割合を占めます。
特に1週間前～前日の過ごし方が重要になりますので、
タスクリストを作って実行していきます。
前日までにやること(例)
また、マラソンレースの当日は朝早いことが多いので、
慌てることがないようにやることをタスク化しておきます。
当日やること(例)
1キロのあたりの目標タイムを設定します。
ポイントとしては、過去の結果からベロシティを推測して
最初から無理な目標は立てないようにします。
私の場合、ベストタイムは1時間45分なのですが、
3年前の記録になるので、半年前に走った記録1時間52分を加味して、
ベストを5分/km、ベターを5分10秒/km、マストを5分20秒/km
に設定します。
この目標タイムはバーンダウンチャートをイメージすると
走っている途中でも頭の中で把握できてわかりやすいです。
「持続可能なペース」を保てているか？を問いながら、
1キロごとのタイムと調子を見ながら目標を都度設定し直します。
これらの準備を整えてスタートしたのですが、さっそく問題が起きました。
1キロごとにあると思っていたキロ看板が見当たりません。
どうやらこのレースでは5キロごとにあるようです。
これは焦ります。
ただ、開発プロジェクトでもそうですが、
いくら綿密に計画を立てても想定外のことは起きます。
大事なのは、
ことなんじゃないかと思います。
ペースが遅いんじゃないか、逆にオーバーペースなんじゃないか
など不安にはなりましたが、
1キロごとで設定したタイムを5キロごとに変換して、
自分を信じて最初の5キロを走りきりました。
そして、最初のイテレーション(～5キロ)の振り返りをKPTでやります。
K 設定目標のベストを上回るペース。
「持続可能なペース」を保てているか？
イエスなので、このままのペースで
P とは言え、オーバーペース気味なのでこれ以上は上げないように
T 他の人のペースに引っ張られないようまわりを無視してマイペースで走り、
次の5～10キロの結果をもって、10～15キロの目標を設定する
10キロ、15キロと同じぐらいのペースで進めることができたので、
このまま流れで行ってもベストタイムは達成する感触がありました。
ただ、目標を達成できそうとなると次の目標をという欲が出てくるもので、
最後の力を振り絞ってラストスパートした結果、1時間43分をギリギリ切ることができました。
数秒ではありますが、最後の最後までこだわりを持つことで
より良いアウトプットが出て次にもつなげられたと思います。
ハーフマラソンの自己べスト更新というのは、
年初に立てた目標の1つで、残り1か月で達成できました。
マラソンも開発も引き続き目標達成していきます！
