RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのエンジニアブログ

イベント詳細についてはこちらをクリック

【参加レポート】「PHPerKaigi 2019」に参加しました!

こんにちは MasaKu です。

先日、ブログでもご紹介しましたが、弊社もスポンサーとして協賛している PHPerKaigi 2019 に参加してきました。

phperkaigi.jp

tech-blog.rakus.co.jp

発表が大変素晴らしかったことはもちろん、イベントの様々な趣向が面白く、充実したイベントでしたので是非とも参加レポートを書かせていただきたいと思いました。

各発表のスライドは以下の記事で大変丁寧にまとめられております。

qiita.com

f:id:MasaKu:20190404085253j:plain
PHPerKaigi 2019

全体を通して感じたこと

普段、業務ではPHPで開発を行っておりますが、社外のエンジニアの方でPHPを利用されている方にあまりお会いすることがなかったので、会場のいたるところでPHPの話で盛り上がっている光景がすごく新鮮でした。

技術系イベントでは twitterハッシュタグが用意されていることが多いイメージですが、このイベントでは発表会場ごとにハッシュタグが用意されていました。

メインのハッシュタグ ・・・ #phperkaigi

A会場のハッシュタグ ・・・ #phperkaigi #a

B会場のハッシュタグ ・・・ #phperkaigi #b

そのため、発表を聞きながらつぶやいた内容をほかの参加者の方が拾って下さったり、何気なく疑問に思ったことをつぶやいたところ、発表後に発表者の方からご回答いただいたりすることもありました。

PHPerKaigi2019のサイトができるまで」という発表では、PHPerKaigi 2019 のサイトを制作された企業様のアートディレクターの方が発表されていたのですが、サイトのコンセプトを「参加者、スポーカーはもちろん、スタッフ、スポンサーも大いに楽しむ場」とされていました。

speakerdeck.com

イベント会場内に用意されたフリースペースでは、アンカンファレンスが開催されたり、参加者の方々が発表者の方と交流されていたりして和気あいあいとした雰囲気があり、まさにコンセプト通りのイベントだったと思います。

f:id:MasaKu:20190407140557j:plain
アンカンファレンスの予定ボード
f:id:MasaKu:20190407140623j:plain
LT会場 想像以上に広い会場でした

印象に残った発表

様々な発表を聴講させていただいた中で、特に印象的だったものをいくつかご紹介させていただきます。

設計力を上げるバリエーションの見極め術

speakerdeck.com

サービスを運用していると、当初は想定していなかったような新しい機能の追加などが発生します。

そのため、「変化」に強いプログラムを作ることが重要です。

いま開発している機能が「今後の機能追加を考慮すると、こう作るべきだろうか?」という想像力を働かせながらプログラミングする能力が必要だと思いました。

発表の中でもおっしゃられていましたが、上記のような想像力は、業務知識をつけなければ身につかないものなので、コーディング力だけでなく、サービスに対する理解も重要だと改めて思った発表でした。

マニュアルにない引数を与えるとどうなる?php-srcへのバグ報告をした時の話

speakerdeck.com

PHPのバグを報告されたという発表でしたが、バグの報告のために必要な要点をまとめられていた内容が大変参考になりました。

PHPの公式から出ているバグ報告時のルールとして以下のようにまとめられていました。

  • 英語で報告してください
  • 1つのバグは1つの報告にしてください
  • どういう目的のため何をしてどうなったのか報告してください
  • 必要十分な情報量で報告してください
  • 過去のバージョンのバグは報告しないでください
  • 既に報告済みのバグがないか調査してください
  • エラーメッセージの内容をちゃんと読んだ上で報告してください

OSSにコントリビュートするということに対して、途方もなく高いハードルを感じていましたが、バグ報告については、開発時のトラブルの報告と似ていると思いました。

それと同時に、普段のトラブル報告の内容でも上記の観点に気をつけながら報告しなければならないと思いました。

バグが見つかった際は「何をすればバグが再現するのか」ということと「関係の無い情報は混同させない」ということを意識していきたいです。

【アンカンファレンス】 STEPUP プログラミング高速化!~「君、プログラミング早いね」といわれるために

speakerdeck.com

プログラミングを早くするための施策を4つのステップでご説明されていました。

  • STEP1: 書いて覚える
  • STEP2: 綺麗に書く
  • STEP3: 書き方を覚える
  • STEP4: プログラミングをするプログラムを書く

特に重要だと思ったのはSTEP2の「綺麗に書く」だと思いました。

綺麗な書き方というのはプロジェクトによって様々です。

例えば、使用しているフレームワークが違ったりコーティングルールがあったりと、そのプロジェクトにおける最適な書き方がそれぞれ存在するため、ケースバイケースで書き方を調整していかなければいけません。

書き方に慣れていない時に急いで雑に書いたプログラムは簡単なミスが紛れ込んだり、バグが発生した際に修正コストが大きくなるプログラムになってしまいます。

しかし、プログラムを書き上げるまでに時間がかかったとしても、綺麗に書く事を気をつけておけば、もしバグが見つかったとしても修正箇所が見つけやすく素早く修正できます。

また、綺麗に書くことに慣れてくると、その書き方で素早く書き上げることができるようになってくるので、結果的にバグが少なく、読みやすいコードが短い時間で書けるようになります。

この観点は新しい書き方が増えるたびに更新していかなければならない内容なので、「できるようになった」と思っても気を抜かず、継続的に意識しておかなればならない内容だと思いました。

まとめ

何となく知っているキーワードを頼りに発表を聞くだけでも、「そういうことだったんだ!」といった気づきを得られ、そこから新しい興味も湧いてくるため、こうしたイベントへ参加することは本当にいい経験になると改めて思いました。

イベント自体も発表者と参加者が一緒に楽しめる趣向が盛りだくさんだったので、オーディエンスとしての参加ではありましたが、決して取り残されている感覚にはならないイベントだと思いました。

今後のPHP関係のカンファレンスは以下のとおりです。

残念ながら関西での開催は今のところありませんが、機会があればどこかにまた参加してみたいと思いました。

qiita.com

参考サイト

PHPerKaigi 2019

PHPerKaigi 2019 に協賛します - RAKUS Developers Blog | ラクス エンジニアブログ

PHPerKaigi2019 スライドまとめ - Qiita

PHPerKaigi2019のサイトができるまで - Speaker Deck

設計力を上げる!バリエーションの見極め術 - Speaker Deck

PHPのマニュアルにないことをしてphp-srcへバグ報告をした - Speaker Deck

STEP UP プログラミング高速化 「君、プログラミング早いね」と言われるために / Step up! fast programming - Speaker Deck

2019年に開催される全国のPHPカンファレンスのまとめ - Qiita

「AWS 認定ソリューションアーキテクト - アソシエイト」の学び方(合格体験記)

こんにちわ、@kawanamiyuu です。先週、AWS 認定ソリューションアーキテクト - アソシエイト 試験(以下、SAA 試験)を受験してきましたので、勉強方法などを共有したいと思います。ちなみに、試験結果は 893 点 (/1000) で合格でした ε-(´∀`*)ホッ

f:id:kawanamiyuu:20190402080322j:plain

筆者の AWS スキル感

  • AWS での基本的な冗長構成(ELB + Auto Scaling + RDS Multi-AZ)とか、Well-Architected フレームワーク レベルのことはこれまでのエンジニア経験の中で知識としては知っている
  • 以前このブログで紹介したかみせんプロジェクトなどの技術検証系のプロジェクトで ECS などの流行りのサービスをちょこちょこ触ったことがある
  • AWS でインフラを 0 から構築した経験はない
  • 本番環境での AWS 運用経験はない
    • AWS を利用したサービスの開発に携わったことはありますが、インフラレイヤは当時ノータッチ

受験のモチベーション

  • 現在開発を担当している新規事業(HR x Tech)で AWS を利用することが確定しており、いつまでも「知ったかぶり」ではツライ(笑)ので、AWS の基本について一度ちゃんと理解しておきたかった
  • 社内に AWS に詳しいエンジニアが少ないので、今後のキャラ立ちを狙って
続きを読む

【平成最後】大阪・梅田エンジニアもくもく勉強会の様子と次回告知

4月1日にパパになった 福岡@楽楽労務開発課 です。 めちゃめちゃカワイイです♪

さてさて、娘自慢はこれくらいにして、
参加者様から好評をいただいております弊社のもくもく勉強会、4月開催の告知も兼ねて3月の模様をお伝えしようと思います。

2月の模様はこちらから ↓ tech-blog.rakus.co.jp

3月実施の模様

2月実施会の振り返りから、今回は次のような改善を実施しました。

  • BGMの音を途切れないようにする
  • お菓子をとりやすい空気をつくる

■BGMの音を途切れないようにする

もくもく勉強会のBGMは、ラズパイからラジオを流していました。

しかし、少し前からラズパイの処理的な問題なのかBGMが途切れ途切れになってしまっていたため、 スマホから音楽を流すようにしました。

f:id:noriharu3:20190402140543j:plain

結果、途切れることはなく、より集中して学習する場になったのではと思います。

■お菓子をとりやすい空気をつくる

事前にブログで周知した効果なのか、ガンガン減っていきました。

開始30分でほぼ半分にw f:id:noriharu3:20190402135640j:plain

本来の目的としては、お菓子を取りに行った際にコミュニケーションが発生すればいいなーという思いから設定しておりました。

誰かがお菓子をとることで、お菓子をとりやすい空気&食べながら交流するという空気が出来上がっていたように思います。

次回も皆さんガンガン消費して、ガンガン交流していただければと思います。

次回告知

次回は4月9日に開催予定です。木曜日ではなく火曜日ですので、ご注意ください!
既にconnpassに公開中ですので、興味を持たれた方は是非お越しください。

rakus.connpass.com

PHPerKaigi 2019 に協賛します

こんにちわ @kawanamiyuu です。株式会社ラクスは、今週末に開催される PHPerKaigi 2019 に Silver スポンサーとして協賛しています。ちなみに、CfP も弊社から 3 名のエンジニアが応募しました。が、残念ながら不採択でした...

当日はスポンサー枠で弊社のエンジニアが 1 名参戦しますので、参加者のみなさまと一緒にイベントを楽しめればと思います!

イベント概要

phperkaigi.jp

「PHPer チャレンジ」企画

今回の PHPerKaigi では期間中の3日間「PHPerチャレンジ」という企画が開催されます。

PHP チャレンジ とは・・・

PHPerチャレンジは会場内外に隠された「PHPerトークン」を探しだし、イベントサイトに入力して得られたスコアを競う企画です。 PHPerトークンは「記号の# + 任意の文字列」の形をしています。

PHPer トークンはイベント公式のものに加えて、スポンサーから提供されるものもあります。

ラクスの PHPer トークンはコチラです! → #RAKUSMeetup

PHP新機能まとめ(v7.1~v7.3)

こんにちは。 新卒1年目のbadaikiです。

はじめに

まもなく入社して1年、配属されて9カ月、PHP歴9カ月になります。PHPの記法にもつまることなくコーディングできるようになったので、そろそろステップアップを目指していきます。
そこで今回は v7.1 ~ v7.3 で追加された新機能の一部を紹介し、今後に活かしていきます。

公式サポート期限

昨年 2018年12月 をもって v5.6 が EOL (End Of Life) を迎えました。

バージョン 初回リリース日 最新リリース 最新リリース日 アクティブサポート セキュリティサポート
7.3 2018/12/06 7.3.1 2019/01/10 2020/12/06 2021/12/06
7.2 2017/11/30 7.2.14 2019/01/10 2019/11/30 2020/11/30
7.1 2016/12/01 7.1.26 2019/01/10 2018/12/01 (終了) 2019/12/01
7.0 2015/12/03 7.0.33 2018/12/06 2017/12/03 (終了) 2018/12/03 (終了)
5.6 2014/08/28 5.6.40 2019/01/10 2017/01/19 (終了) 2018/12/31 (終了)

上記に従い、現在セキュリティサポートありのv7.1~v7.3を対象としました。

新機能

v7.1

nullableな型

パラメータや返り値の型宣言で nullable 指定ができるようになりました。 v7.0 で取り入れられた型変換の型の前にクエスチョンマークをつけると、nullable であることを指定できます。 nullable 指定をすると、指定した型だけでなく NULL も渡せるようになります。

<?php
function returnString() :?string {
    return "Hello!";
}

function returnNull() :?string {
    return null;
}

function dumpParam(?string $str) {
    var_dump($str);
}

var_dump(returnString());
var_dump(returnNull());
dumpParam("Hello!!!");
dumpParam(null);

出力結果

string(6) "Hello!"
NULL
string(8) "Hello!!!"
NULL
void関数

戻り値の型として void が導入されました。戻り値の型を void と宣言した関数は、関数内での return 文を省略するか、あるいは空の return を使う必要があります。 void 関数から NULL を返すことはできません。何か値を返そうとするとエラーになります。

<?php
function dumpParam(): void {
    var_dump("Hello!!!");
}

dumpParam();

出力結果

string(8) "Hello!!!"
対称的な配列の分解

配列の短縮構文 ( [ ] ) を使って、 代入用に配列の値を取り出せるようになりました (foreach でも使えます)。 これは、list() の代替として使えます (list() もまだ使えます)。

<?php
$colors = [
    ['apple', 'red'],
    ['banana', 'yellow']
];

echo "list形式\n";
foreach($colors as list($fruits, $color)) {
    echo $fruits . "'s color is " . $color . ".\n";
}

echo "[]形式\n";
foreach($colors as [$fruits, $color]) {
    echo $fruits . "'s color is " . $color . ".\n";
}

出力結果

list形式
apple's color is red.
banana's color is yellow.
[]形式
apple's color is red.
banana's color is yellow.
クラス定数のアクセス範囲指定

クラス定数のアクセス範囲を指定できるようになりました。

<?php
class ConstDemo
{
    const PUBLIC_CONST_1 = 1;
    public const PUBLIC_CONST_2 = 2;
    protected const PROTECTED_CONST = 3;
    private const PRIVATE_CONST = 4;
}

v7.2

object型

object型が新たに導入されました。 任意のオブジェクトに対する (反変) パラメータの型付けや (共変) 返り値の型付けで使えます。

<?php

function test(object $obj) : object
{
    return new SplQueue();
}

test(new StdClass());
抽象メソッドのオーバーライド

ある抽象クラスが別の抽象クラスを継承しているときに、 継承元クラスの抽象メソッドをオーバーライドできるようになりました。

<?php
abstract class Animal {
    abstract function call($str);
}

abstract class Dog extends Animal {
    abstract function call($s);
}

v7.3

フレキシブルな HereDoc 構文と NowDoc 構文

v7.2 以前の HereDoc 構文と NowDoc 構文

<?php
//HereDoc 構文
echo <<<HERE
abc\n
HERE;

//NowDoc 構文
echo <<<'NOW'
def
NOW;

v7.2 の HereDoc 構文と NowDoc 構文では以下の記法により制限されていました。

  • 終端 ID はインデントのものにします。
  • 終端 ID のある行にはスペースやタブなどの文字を含めることはできません。
  • 終端 ID の前の最初の文字は改行にします。
  • 終端 ID の後に改行します。

v7.3 以降では記法が改善されます。

  1. 終端 ID のインデント、行頭スペースの削除が可能になる
  2. 終端 ID の改行要件が削除される

よって以下のように書くことで同じ結果が得られます。

v7.2

<?php
$values = <<<END
a
b
c
END
. ' d e';

v7.3

<?php
$values = <<<END
    a
    b
    c
    END . ' d e';
array_key_first(), array_key_last()

v7.2 以前では reset()、end() および key() 関数を使用して配列の最初と最後のキーを取り出すことができます。ただし、配列の内部ポインタを先頭や末尾に移動させてしまうため、コードの可読性とパフォーマンスが低下してしまいます。
v7.3 では array_key_first(), array_key_last() を追加しました。この関数は配列の内部ポインタに影響を与えずに先頭、末尾のキーを取得することができます。

おわりに

今回、v7.1 ~ v7.3 のバージョンアップで追加された新機能について一部を紹介しました。知っていれば取り入れられたなと思うものやどのように使えばよいのかわからないもありましたが、今後もバージョンアップにもアンテナを張り、追加された新機能や関数を使いこなしていきたいと思います。

エンジニアリングマネジメント:開発の文化

株式会社ラクスでエンジニアリングマネージャをしているmzwkunです。

先月開催されたDevelopers Summit 2019にて、AWSの方が『イノベーションを支えるアマゾン文化』というテーマを発表されていたので、普段行っている自分たちの開発スタイルと比較して、特に気になったところをピックアップしていきます。

多彩で使いやすいサービスを提供されているAWSさんと比較して学べればと思っています。

AWSイノベーションの文化

  • 顧客に徹底的にこだわる、顧客を起点に行動する
  • 長期的視点での継続した投資
  • ビジョンにはこだわるが、詳細なことは柔軟に対応
  • もし創造的でありたいなら失敗を恐れない

ラクスにはリーダーシッププリンシプルがあり、少し表現は違いますが以下と合致しそうだと感じました。

「やるべきことを実行する」「小さく試して大きく育てる」「誠意をもって人と接する」「失敗を許容する」

自分のやりたい事ではなく、顧客視点や失敗を恐れないでチャレンジする点はイノベーションの起点ですね。

AWSイノベーションのための組織づくり

  • 新サービス開発を行う際にまずはプレスリリースとFAQを作る
  • FAQは顧客とステークホルダー(社内関係者)の両面を含める
  • 会議でプレゼンツールはあまり使わず見た目に委ねないようにする(見栄えで騙されないように)
  • 6pagerと呼ばれるレポートを作り事前に読んでおく(ナラティブ【物語】とも呼ばれている)

目的や効果を定めるために真っ先にプレスリリースを作るのは興味深い行動ですね。

私達の開発では「要求仕様書」というドキュメントを企画と開発、関連部署で作成して意識を合わせるようにしています。 そこには要求概要や機能要求など定めるべき当然なものから、保守・品質・性能・運用・サポートといったサービス全体に必要と思われるものが記載されています。 プレスリリースは作れていませんが、ステークホルダーの視点は全て集約できるようにし、レビューによって多様な立場からの意見を受け入れるようにしています。

AWSアーキテクチャ

  • 単一目的のサービス
  • HTTPSAPIのみによる通信
  • お互いのサービスはブラックボックス
  • DevOpsを推進(テストを重視、自動化を重視)

マイクロサービスを前提にテストや自動化の重視と奇をてらうこと無く基本に忠実でした。 ラクスでもDevOpsは外部に任せず内製で力をつけながら進めています。

AWSのカルチャー

  • 5 whys (いわゆる、なぜなぜ)
  • ドアデスクがある 創業時にドア用の板を簡素な机にしていた ※倹約を忘れないように!
  • スピード 過剰な分析、過剰な議論よりもプロトタイプを作ってみる
  • ベストを尽くす 高い目標、メンタリング、ピアフィードバック

QCD、ロジカル、インタラクションというキーワードになりそうです。 ロジカルはラクスでも古くからの重要な文化であり、インタラクションも最近重要視されていて、1on1ミーティングやコーチングというワードが飛び交っています。 そこからどのような行動に移しているかは今後ご紹介したいと思います。

AWSの組織

  • 2-Pizza Teams 必ず目が行き届くように
  • QA、障害対応、運用はすべて自チーム内でやる
  • 早く経験し、繰り返す
  • レビュー待ち状態は厳禁!

やはり10人以下のチーム構成による、きめ細やかなコミュニケーションを土台としたチーム開発が重要そうです。 ラクスでもメンバーを増やすだけではなく、リーダーやマネージャも積極的に育成や採用をして不自然な構成にならないよう努めています。 自チーム内でやるというのも、全てを内製で進めているラクスと似ています。 レビュー待ち厳禁は少し耳の痛い言葉ですが、リーダーの皆さんが頑張って効率性を守ってくれています。

Every day is still Day One.

  • 毎日が常に「Day One」である
  • 最初の一歩を踏み出す日
  • 新たな挑戦を心待ちにする日
  • そして今日が、皆様にとっての「Day One」

素晴らしい考え方ですね。素直に参考としたいです。

いろいろと見ていきましたが、共通となりそうな点も多く、自分たちのやっていることにさらに自信が持てそうです。

JJUG CCC 2018 Fall 【参加レポート】

f:id:sts-250rr:20190317152347p:plain

はじめに

こんにちは。

年末にJJUG CCC 2018 Fallに参加してきましたので、少し期間が空いてしまいましたが、聴講したセッションについて投稿します。

当日のタイムテーブル、資料は下記をご覧ください。

https://docs.google.com/spreadsheets/d/1cyNPjk8doq26FgjhLVwA0Pw2grGFwxqo4yVXqJgQCTE/edit#gid=413114967

qiita.com

参加セッション

  1. IBM CloudとKubernetesでSpring Bootのマイクロサービスを簡単に!

  2. エムスリーでのKotlinへの取り組み

  3. Java を活用したマイクロサービスのための Kubernetes 活用

セッション感想

IBM CloudとKubernetesでSpring Bootのマイクロサービスを簡単に!

IBMクラウド上にKubernetesクラスタを作成して、DBの構築、事前にDockerイメージとして作っておいたSpring BootのJavaアプリケーションをデプロイしてサービスを構築していくセッションとなっていました。 先日からDocker周りに興味が湧いているところなので、次はKubernetesに手を出すいいきっかけになりそう。

エムスリーでのKotlinへの取り組み

f:id:sts-250rr:20190321221448j:plain

運用中のJavaアプリケーションをKotlinに移行する話。
移行の方法としては3通りほど考えられていましたが、今回は「全部まとめて書き換える」方法を取られていました。
コンバート中は完全に機能開発を止めて、移行をすることに集中、余計なことはしない、短期間に完了する。
移行作業のノウハウを学ぶことができ、システムをAからBに移行するぞとなった時の参考になりそうです。

Java を活用したマイクロサービスのための Kubernetes 活用

f:id:sts-250rr:20190321221522p:plain

かなり内容の濃いセッションになっていて、k8sにまだ触れていない私は少々パンク気味でしたが、今後自身でK8sを触る時の参考になるTips紹介が多かったです。

Docker関連

  • Dockerイメージの取得時、いつのバージョンかわからなくなるのでlatestは使わないこと!
  • 小さなサイズのイメージをつくるように!
  • DockerHubのイメージは安全か?
    • 信頼されてないイメージは脆弱性が含まれている可能性はある。
    • 本番利用するならセキュリティチェック・検証はしましょう。

k8s関連

  • 利用用途によって、向き不向きあるので何でもかんでもk8sでというのはやめましょう。
  • k8sは色々できるけど、全ての機能を使う必要はない!
  • 後々のメンテナンスのことも考えてシンプルな構成にしておくのがおすすめ。
  • k8sのバージョンアップには要注意!
    • 今まで動いていたyamlでは動かなくなる可能性がある。
    • 新しくクラスタを作成して、動くことがわかってからルーティングを変えて対処しましょう

Docker、k8sに関してはまだまだ初学者であるため、触り程度でしかわかっていない部分がありますが、今後触っていく際の有益な情報になりました。

何でもかんでもk8sでというのはやめましょう。
私もよく言われていて耳が痛いですが、手段ベースでものを選んではいけないの典型ですね。

終わりに

JJUGには昨年度から参加していますが、昨年よりも内容がわかるようになっている自分を感じることができました。
同じテーマで複数の発表があれば今のトレンドの技術はこれなのかな?といった業界の流れのようなものも少し感じられた点も昨年から参加していた成果かと思います。

若手にとって、はじめての勉強会やカンファレンスへの参加は足が重い人が多いかもしれませんが、大きめのカンファレンスは参加のハードルも低いので、1ヶ月後に入社する新メンバーにもオススメしてあげたいです。

Copyright © RAKUS Co., Ltd. All rights reserved.