こんにちは。インフラエンジニアの綿引です。 早速ですが、今回はMySQLのテーブル圧縮について記載したいと思います。 但し、MySQL 5.7から実装された透過性ページ圧縮でなく、 MySQL 5.1のInnoDB Plugin時代からある圧縮です！ 個人で運用しているMySQLが5.6なのですが、 ストレージが逼迫して来たので、旧来の圧縮を試してみました。 MySQL 5.6以前で「ディスク容量が足りない！」という方がいらっしゃれば、 参考にして頂ければと思います。 圧縮の仕組み まずは圧縮の仕組みについて図を作ってみました。 非圧縮ページ(16KB) と記載してあるものが通常のページだとお考え下さい。 今回、実施する圧縮の仕組みとしては、 通常はこの非圧縮ページがそのままストレージに保存される所を、 圧縮ページを作成しストレージに保存することによって、 ディスクの消費量を抑えられるというものです。 また select、insert などのテーブル操作も発行出来るという優れものです。 圧縮ページに操作を加える際は、バッファプール内で展開することで クライアント側からの操作を可能にしています。 「んっ？ デメリット多いんじゃない？」と思われた方、デメリットは後述致しますね。 とりあえずやってみたいと思います！ パラメータの変更 まずは以下の2つのパラメータの変更です。 innodb_file_per_table = 1 innodb_file_format = Barracuda innodb_file_per_table は 「テーブルごとに専用のテーブルスペースを作成する」 パラメータです。 有効にする”1″を設定します。 innodb_file_format は 「InnoDBのファイル形式を定義する」 パラメータです。 MySQL 5.6までのデフォルトは 「Antelope」 なのですが、 これを圧縮機能をサポートした最新の形式である 「Barracuda」 に変更します。 尚、パラメータの内容は以下です。 ファイル フォーマット 内容 Antelope 可変長カラム(VARBINARY, VARCHAR, BLOB, TEXT)の先頭768byteを B-tree ノードのインデックスレコードに格納し、 残りをオーバーフローページに格納する Barracuda 可変長カラム(VARBINARY, VARCHAR, BLOB, TEXT)の全てを 外部のオーバーフローページに格納し、クラスタインデックスレコードに そのページへのポインタ(20byte)のみを格納する Antelope では可変長カラム1つに対し 最大で768byteまでローカルページを消費するが、 Barracuda では可変長カラム1つに対し 最大で20byteしかローカルページを消費しないため、 最大行サイズの8KBに対し多く文字を格納出来る。という理解でいいかと。 因みに 「Antelope」はレイヨウ 「Barracuda」はオニカマス らしいです。 オニカマスの圧が強いですね。 上記を変更後、確認します。 mysql> show variables like 'innodb_file_per_table'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | ON | +-----------------------+-------+ mysql> show variables like 'innodb_file_format'; +--------------------+-----------+ | Variable_name | Value | +--------------------+-----------+ | innodb_file_format | Barracuda | +--------------------+-----------+ コマンド 続いて圧縮を行うコマンドを実施して行きます。 記載方法としては、 Create Table 文や、 Alter Table 文に、 ROW_FORMAT句 と KEY_BLOCK_SIZE句 を付与することで圧縮が可能となります。 例としては以下です。 mysql> ALTER TABLE test ROW_FORMAT=Compressed KEY_BLOCK_SIZE=8; ROW_FORMAT句とKEY_BLOCK_SIZE句について、 ROW_FORMAT句 については先程のファイルのフォーマットに対して、行のフォーマットです。 全部で4種類あり、指定が可能ですが圧縮機能がある COMPRESSED に関しては、 ファイルフォーマットを Barracuda にしないと使えません。 ROW_FORMAT 内容 REDUNDANT MySQL 5.0.3 よりも前で使用されていた COMPACTよりも効率性が低い COMPACT MySQL 5.0.3 以降でのデフォルト REDUNDANTよりもデータサイズが小さい DYNAMIC Barracuda とともにのみ使用可能 圧縮は行わない COMPRESSED Barracuda とともにのみ使用可能 圧縮に対応 次にKEY_BLOCK_SIZE句についてですが、 こちらは圧縮後のInnoDBのページサイズを指定するもので、 値としては 1、2、4、8、16 が設定出来ます。 InnoDBのデフォルトのページサイズは16KBのため、 例えば、8(KB)を指定した場合は容量が半分になります。 ※ 但し、対象テーブルに対する圧縮が 全て上手くいった場合 です。     圧縮する際に8KB以上となってしまう場合は、     元ページを分割した後に、それぞれ圧縮を行うためその分容量が増えてしまうので注意です。 まずは既存テーブルのバックアップを取得します。 mysql> create table test_tbl2 like test_tbl; Query OK, 0 rows affected (0.18 sec) mysql> insert into test_tbl2 select * from test_tbl; Query OK, 1048407 rows affected (9 min 41.05 sec) Records: 1048407 Duplicates: 0 Warnings: 0 因みにサイズはこのような感じです。 mysql> select table_name,engine,table_rows,avg_row_length,data_length -> from information_schema.tables -> where table_name like '%test%'; +------------+--------+------------+----------------+-------------+ | table_name | engine | table_rows | avg_row_length | data_length | +------------+--------+------------+----------------+-------------+ | test | InnoDB | 933488 | 2199 | 1958 | | test2 | InnoDB | 930930 | 2218 | 1970 | mysql> ALTER TABLE test2 ROW_FORMAT=Compressed KEY_BLOCK_SIZE=8; Query OK, 0 rows affected, 4 warnings (44 min 15.12 sec) +------------+--------+------------+----------------+-------------+ | table_name | engine | table_rows | avg_row_length | data_length | +------------+--------+------------+----------------+-------------+ | test | InnoDB | 933488 | 2199 | 1958 | | test2 | InnoDB | 832392 | 1229 | 976 | avg_row_length と data_length がほぼ半分になりました。 table_rowsも若干減っています。これはおそらく Barracuda の効果でしょうか。 OSから確認したデータファイルのサイズもしっかり変更されております。 -rw-rw---- 1 mysql mysql 2327838720 2016-07-06 18:01 test.ibd -rw-rw---- 1 mysql mysql 1031798784 2017-01-13 15:14 test2.ibd 圧縮出来ました。 因みに show table status で見るとこんな感じ。 圧縮後の確認の1つとして Row_format と Create_options を見ると確か。 mysql> show table status like 'test2'\G; *************************** 1. row *************************** Name: test2 Engine: InnoDB Version: 10 Row_format: Compressed Rows: 832392 Avg_row_length: 1229 Data_length: 1023410176 Max_data_length: 0 Index_length: 0 Data_free: 0 Auto_increment: 1113463 Create_time: 2017-01-13 15:14:41 Update_time: NULL Check_time: NULL Collation: utf8_general_ci Checksum: NULL Create_options: row_format=COMPRESSED KEY_BLOCK_SIZE=8 Comment: 1 row in set (0.08 sec) デメリット 実際にやってみて、効果があることが確認出来ました。 では冒頭で名言しなかったデメリットについて。 一つ目は負荷です。 テーブル操作を行うにあたり、必要に応じて圧縮・解凍を行うというパワーが必要となるため、 今までリソースに問題がなかったとしても、そこがネックになったりします。 二つ目はキャッシュヒット率です。 こちらは確かめたわけではないですが、 全体的なキャッシュヒット率が下がる可能性があると思います。 理由としては圧縮済みページと非圧縮ページがバッファプールに載るため 今まで運用上載っていたキャッシュがLRUにより追い出されることが想像されるためです。 まとめ 以上、検証は終了です。 個人的には効果も大きいけど、デメリットも大きいため場面を選ぶな。という印象でした。 今後はMySQL5.7の透過的ページの圧縮をやろうかなと思っております。 ご清覧頂きありがとうございました。 Wedding Parkでは一緒に技術のウエディングパークを創っていくエンジニアを募集しています。 興味のある方はぜひ一度気軽にオフィスに遊びにきてください。

こんにちは、岩橋聡吾です。 やってみよう！AWSでWEBサーバー環境構築、好評の 第一回 に続きまして、待望の第二回をやっていきたいと思います。今回は前回作成したVPCとEC2を拡張し、少しづつ耐障害性を意識した実用的な構成を作っていきます。まずはAMIを使って前回作ったEC2のコピーを作るところから始めましょう！ AMIを設定する これから複数の各種サーバーを設定するに先立って、AMI (Amazon Machine Image) の設定を行いましょう。EC2インスタンスをローンチする度に同じような設定を毎回行うのは煩雑ですが、 これを使ってEC2インスタンスの設定状態をスナップショットとして保存しておくことができます。後で同じEC2が必要になった時にすぐに複製が手に入ります。それでは前回作ったEC2のAMIを作成します。 EC2インスタンスの一覧画面を表示して、複製元を選んで右クリック 設定についてはこのままで、イメージを作成します AMIの作成には少し時間がかかります。作成が終わるまで待ちましょう。 Apacheを設定する ウェブアプリの構築の要となるウェブサーバーを設定するので、さっき作成したAMIからEC2インスタンスを作成します。 AMIの一覧を表示して、右クリック -> 作成 を選びます。状態がavailableであることを確かめてください。 インスタンスタイプは「t2.micro」を選びます。 インスタンスの詳細を設定していきます。 IPに設定する内容は選択したネットワーク・サブネットに依存します。 以前作成したAZ・サブネットのIPが10.0.0. 0 /24 でしたので、4つ目の数字を自由に選ぶことができます（ 第一回参照 ）。ここにIPを設定しておくことで、このインスタンスに設定されるプライベートIPを固定できます。 自動割当パブリックIP: 有効 プライマリIP: 10.0.0.10 サブネットにどんなIPを設定していたか忘れてしまったら、VPCダッシュボードからサブネットを選んで確認しましょう。 インスタンスの名前を設定します。 セキュリティーグループ（インスタンスの仮想ファイアウォールなるもの）はとりあえずデフォルトを選んでおきます。もちろん後で正しい設定をします。 前回使用したキーペアを使ってインスタンスを立ち上げます。 サーバーにSSHログインして最低限のApacheの設定を行います。 コマンドを打ち込んでも何も表示されず、アクセス出来ない場合はセキュリティーグループの設定が悪い場合が考えられます…「22番ポートが開いていない」「アクセスIPを絞っている」等々。 $ ssh -i iwa-sg610.pem ec2-user@52.198.133.68 Last login: Sat Nov 5 05:37:54 2016 from softbank219207110185.bbtec.net __| __|_ ) _| ( / Amazon Linux AMI ___|\___|___| https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/ 13 package(s) needed for security, out of 21 available Run “sudo yum update” to apply all updates. [ec2-user@ip-10-0-0-10 ~]$ [ec2-user@ip-10-0-0-10 ~]$ sudo yum install httpd Loaded plugins: priorities, update-motd, upgrade-helper Resolving Dependencies –> Running transaction check —> Package httpd.x86_64 0:2.2.31-1.8.amzn1 will be installed –> Processing Dependency: httpd-tools = 2.2.31-1.8.amzn1 for package: httpd-2.2.31-1.8.amzn1.x86_64 –> Processing Dependency: apr-util-ldap for package: httpd-2.2.31-1.8.amzn1.x86_64 –> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.2.31-1.8.amzn1.x86_64 –> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.2.31-1.8.amzn1.x86_64 –> Running transaction check —> Package apr.x86_64 0:1.5.1-1.12.amzn1 will be installed —> Package apr-util.x86_64 0:1.4.1-4.17.amzn1 will be installed —> Package apr-util-ldap.x86_64 0:1.4.1-4.17.amzn1 will be installed —> Package httpd-tools.x86_64 0:2.2.31-1.8.amzn1 will be installed –> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: httpd x86_64 2.2.31-1.8.amzn1 amzn-main 1.2 M Installing for dependencies: apr x86_64 1.5.1-1.12.amzn1 amzn-main 116 k apr-util x86_64 1.4.1-4.17.amzn1 amzn-main 87 k apr-util-ldap x86_64 1.4.1-4.17.amzn1 amzn-main 17 k httpd-tools x86_64 2.2.31-1.8.amzn1 amzn-main 80 k Transaction Summary ================================================================================ Install 1 Package (+4 Dependent packages) Total download size: 1.5 M Installed size: 3.6 M Is this ok [y/d/N]: y Downloading packages: (1/5): apr-1.5.1-1.12.amzn1.x86_64.rpm | 116 kB 00:00 (2/5): apr-util-1.4.1-4.17.amzn1.x86_64.rpm | 87 kB 00:00 (3/5): apr-util-ldap-1.4.1-4.17.amzn1.x86_64.rpm | 17 kB 00:00 (4/5): httpd-2.2.31-1.8.amzn1.x86_64.rpm | 1.2 MB 00:00 (5/5): httpd-tools-2.2.31-1.8.amzn1.x86_64.rpm | 80 kB 00:00 ——————————————————————————– Total 9.3 MB/s | 1.5 MB 00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : apr-1.5.1-1.12.amzn1.x86_64 1/5 Installing : apr-util-1.4.1-4.17.amzn1.x86_64 2/5 Installing : httpd-tools-2.2.31-1.8.amzn1.x86_64 3/5 Installing : apr-util-ldap-1.4.1-4.17.amzn1.x86_64 4/5 Installing : httpd-2.2.31-1.8.amzn1.x86_64 5/5 Verifying : httpd-tools-2.2.31-1.8.amzn1.x86_64 1/5 Verifying : apr-1.5.1-1.12.amzn1.x86_64 2/5 Verifying : httpd-2.2.31-1.8.amzn1.x86_64 3/5 Verifying : apr-util-ldap-1.4.1-4.17.amzn1.x86_64 4/5 Verifying : apr-util-1.4.1-4.17.amzn1.x86_64 5/5 Installed: httpd.x86_64 0:2.2.31-1.8.amzn1 Dependency Installed: apr.x86_64 0:1.5.1-1.12.amzn1 apr-util.x86_64 0:1.4.1-4.17.amzn1 apr-util-ldap.x86_64 0:1.4.1-4.17.amzn1 httpd-tools.x86_64 0:2.2.31-1.8.amzn1 Complete! 設定したApacheのhttpd.confファイルのDocumentRootは「/var/www/html/」としました。 今回はサーバーを立ち上げることが目的なので、最低限のHTMLファイルを作成しましょう。 [ec2-user@ip-10-0-0-10 ~]$ cd /var/www/html/ [ec2-user@ip-10-0-0-10 html]$ sudo touch index.html health.html [ec2-user@ip-10-0-0-10 html]$ sudo chown ec2-user *.html [ec2-user@ip-10-0-0-10 html]$ vi index.html 後述するロードバランサーの使用に必要なファイルも作成します。 [ec2-user@ip-10-0-0-10 html]$ vi health.html さぁ、サーバーを立ち上げてみましょう。 [ec2-user@ip-10-0-0-10 ~]$ sudo service httpd start Starting httpd: [ OK ] 上手くいきました。 これでIPアドレスを直接ブラウザで叩けば上記ファイルが見れるようになります。 ウェブサーバーを多重化する準備 堅牢なウェブアプリの構築にはロードバランサーと呼ばれる仕組みが活躍します。 Webアプリのパフォーマンスを上げる手段の１つとして、Webサーバー台数を増やすことがあります。その時に、複数のWebサーバーの負荷状況を見ながら、サイト訪問者をどのWebサーバーに案内すべきかを判断してくれるのがロードバランサーになります。レストランのウェイターのように、お客を一番最初に接客し空いているテーブルに案内してくれるイメージです。 ちなみに、サーバーの台数を増やすことをスケールアウト、反対に減らすことをスケールインと呼びます。また、サーバーのスペック(１台あたりの性能)を増やすことをスケールアップ、減らすことをスケールダウンと呼びます。 早速、AWSでロードバランサー（Elastic Load Balancing）を設置してサーバーの多重化が出来る構成にしてみましょう。 高機能版のロードバランサーが最近登場しましたが、今回はClassic Load Balancerを選択します。 ELBの名前・ELBが待受けるポート番号と使用するサブネットを設定します。 セキュリティーグループ。今回HTTP-port:80(HTTPS-port:443)以外は使用しません。 ヘルスチェックを設定します。ヘルスチェックにはいくつか種類がありますが、今回はHTTP経由でチェックしたいと思います。ELBは予め設定されたファイルの存否とその内容を一定期間毎にチェックします。ファイルが無かったり内容が決められたものでなければチェックNGとして、そのインスタンスをELBの管理下から切り離します。逆に、切り離されたインスタンスが問題無いことを一定回数分確認できたら、そのインスタンスを再びELB管理下に戻します。pingパスには先ほど作成した「health.html」を指定します。 ELBにぶら下げるインスタンスを設定します。 タグ付けをしてELBを作成します。 ウェブ用セキュリティーグループを再設定します。 せっかくELBを設定したので、これを経由しないWebサーバーへの接続は控えて欲しいですよね。新しくセキュリティーグループを作成・設定しましょう。 EC2（Webサーバー） インバウンド設定例 HTTP – TCP – port:80 – 10.0.0.0/16（同サブネット内（ex.作成したELB）からのアクセスのみ許可） HTTPS – TCP – port:443 – 10.0.0.0/16（同サブネット内（ex.作成したELB）からのアクセスのみ許可） SSH – TCP – port:22 – 10.0.0.0/16（同サブネット内からのアクセスのみ許可） ELB（ロードバランサー） インバウンド設定例（前述で設定済） HTTP – TCP – port:80 – 0.0.0.0/0（どこからでもOK） HTTPS – TCP – port:443 – 0.0.0.0/0（どこからでもOK） 作成したセキュリティーグループを割り当てます。 セキュリティーグループの設定が終わってしばらくすると、ELBの配下に「In Service」となったインスタンスが表示されます。 「Out Of Service」のまま変わらない場合はヘルスチェックに失敗しています…セキュリティーグループ（アクセス元の絞り方が正しいか）やELBヘルスチェック（pingパスが正しいか）の設定を見直しましょう。 ヘルスチェックはデフォルトで30秒ごとに行われ、10回連続で成功すると「In Service」扱いとなります。 終わるまで待てなければ設定でこれを短縮することも出来ます。 「In Service」なインスタンスがELBに1つ以上あることが確認できたら、ELB経由でWebサーバーにアクセスしてみましょう。 ELBのDNS名をコピーして、Webブラウザのアドレス欄にペーストします。 ここまでの設定で、ELBを経由したWebサーバーへのアクセスが出来るようになりました。 今の時点でWebサーバーを増設しても良いのですが、次回の記事で最後の設定が完了してからWeb01を複製し、ELBにぶら下げます。 SSH踏み台 VPCネットワーク内（のサーバー）に接続するための踏み台サーバーを準備します。この役割は、家の敷地内へ誰でも好き勝手に入ってこられないように、塀を作り・裏口を設けそこに警備員を立たせるようなイメージです。 Apacheの設定で既に使っていましたが、普段あまりインフラに馴染みが無い方でも、時々サーバーにログインして謎の呪文のような文字列を打ち込むことがあるかもしれません。このような場合によく使われるSSH (Secure SHell) というソフトウェアを使って遠隔地に存在するサーバーをメンテナンスすることが出来るのですが、無関係の第三者からアクセスされないように対策されていることは大変重要です。加えてSSHの接続元IPも、会社オフィスや自分の自宅に限定することでサーバーが攻撃に遭う確率を減らすことができます。 AMIからインスタンスを作成します。今回は自動割当パブリックIPは無効にします。 インスタンス名を設定します。 余談ですが、AWS Certificate試験ではSSHの踏み台インスタンスをbastion（【名詞】【可算名詞】1【築城】 稜堡(りようほ).2要塞.3とりで(と見なされるもの[人，場所])）と呼ぶようです。 セキュリティーグループを設定します。特定のIPアドレス（会社オフィスや自分の自宅）からのアクセスのみを受け付けます。 Elastic IP 上記手順でSSH踏み台サーバーを設定しましたが、インスタンスにグローバルIPが設定されていないため、このままでは外部からの接続を受け入れることができません。[自動割当パブリックIP]なる設定があるのですがあり、グローバルIPは割当されるのですが再起動時にそのIPアドレスが変わってしまうという落とし穴があるため実用的ではありません。このままSSH踏み台サーバーを運用するのは不便ですので何とかしましょう。 そこで、Elastic IPの登場です。 Elastic IPの画面を表示し、新しくIPアドレスをゲットしましょう。 ゲットしたElastic IPをSSH踏み台インスタンスに関連付けます。設定時にインスタンスIDが必要になります。 インスタンスIDが分からない場合はEC2の画面からコピペしましょう。 Elastic IPの設定が出来ました。右下のElastic IPの欄に紐付けたIPが表示されていることを確認します。「52.199.203.168」 実際にElastic IPを使った疎通確認と、Webサーバー個別にSSH接続が出来なくなっていることも確認します。 Route53（DNS） ELBにアクセスさせる際に、先述のような長大なアドレスではとても覚えきれませんし、メモするのも一苦労です。またシステムやウェブサイトのブランディングには名前も大変重要ですね！ このステップでは独自のドメイン名をAWS上で使用できるように設定します。 IPアドレスとドメイン名を紐付ける仕組みとしてDNSサーバーがあります。DNSサーバーへドメインを伺うとそのIPや別のドメインが返ってきて名前解決してくれます。AWSにおいてもDNSを簡単に構築できるようにRoute53が用意されていますが、そもそも「IPアドレスとドメイン名」「ドメイン名とドメイン名」はどのようにして紐付けられるのでしょうか？ アドレスというのは「ルートドメイン」と「サブドメイン」というものに分解できます。 ルートドメイン名の所有者は、サブドメインという形で好きなドメイン名を払い出すことが出来ます。 例えば、yattemiyou-aws.club というルートドメインがあるとします。このドメインの所有者は、 www.yattemiyou-aws.club や、mail.yattemiyou-aws.club などといったサブドメインを自由に払い出して、それぞれにIPを紐付けすることができるというわけです。 このとき、ドメインがIPアドレスに紐付いているものを Aレコード （ドメイン => xxx.xxx.xxx.xxx）。あるドメイン名がそのまた別のドメイン名に紐付いているものを CNAME （ドメイン => ドメイン）などと呼びます。それでは少し前置きが長くなりましたが実際に設定を行いたいと思います。 Route53はレジストラとしての機能も備えているため、ドメイン取得を含めた作業を一貫してAWSで完結させることが可能です。ただしドメイン取得に多少の費用が掛かりますので、今回は予め別で取得しておいたドメインをAWSに紐付けるようにしたいと思います。 また、本記事の内容を試す目的でドメインが必要な方に向けて、無料で取得できるドメイン (2016/12/04現在) Dot tk をご紹介します。 ※ 万一、リンク先サイトの利用につき問題が生じた場合、その責任はリンク先サイトが負っていますので利用者ご自身の責任で対処してくださるようお願いいたします。 Route53でyattemiyou-aws.club のHosted Zoneを作成する 取得したドメインの管理画面で、AWSから与えられたDNSサーバーを設定します。 作成したホストゾーンに関連づいたネームサーバーを控えておきます。 ドメイン取得業者 (以下の例はお名前.comです) のドメイン設定でネームサーバーを設定します。 この時、控えておいた４つのサーバーをコピペで打ち込みましょう。 この手順で取得したドメインをAWSの管理下に置くことをレジストラに伝えます。 それでは、今取得したドメインとELBを紐付けましょう。 先ずは CNAME でELBに仕向けるレコードを作成します。TTLは300秒位と短めに。 www.yattemiyou-aws.club -> iwa-elb-01-731894849.ap-northeast-1.elb.amazonaws.com を紐付けることが出来ました。（CNAMEの設定ではサブドメインが必要になるため、ルートドメインでのアクセス設定をする場合はAレコードで行います。） 次に Aレコード の設定します。 前述で、ドメインとIPアドレスを紐付けるものをAレコードと呼んでいました。が、Route53に限り、IPアドレスの代わりにAWSで使われるAliasを設定する、エイリアスリソースレコードタイプ（AレコードのAWS亜種版なるもの）と呼ばれる独自の設定があります（外からは通常のAレコードとして見られます）。実現したいインフラ構成によってはELBへのアクセスにCNAMEが使えない場合がありますので、Aレコードの設定は是非覚えておいてください。 www.yattemiyou-aws.club -> （グローバル）IPアドレス も紐付けることが出来ました。 では、設定したドメインを使ってELBへアクセスしてみましょう。 上手くいきました。 これで、Rote53（DNSサーバー） -> ELB（ロードバランサー） -> EC2（Webサーバー） までのパケットの流れを正しく設定することができました。 第2回目の最後に 徐々にWebシステムのインフラらしくなってきましたが、DBサーバーやKVSが設定されていませんので、システムとしてこれを利用するにはまだ力不足です、次回このインフラにデータベースなどの各種ミドルウェアを追加していきます。 ご清覧頂きありがとうございました。 Wedding Parkでは一緒に技術のウエディングパークを創っていくエンジニアを募集しています。 興味のある方はぜひ一度気軽にオフィスに遊びにきてください。 ◉シリーズ ・やってみよう！AWSでWEBサーバー環境構築（シリーズ第1回） ・やってみよう！AWSでWEBサーバー環境構築（シリーズ第3回） ・やってみよう！AWSでWEBサーバー環境構築（Lambda|API Gateway|シリーズ第4回） ◉筆者のおすすめ記事 ・【DB設計入門|ER図|MySQL】コンビニレシートから学ぶ！データモデリング手法 ・【機械学習入門|Python|scikit-learn】結局何ができる？cheat-sheetから解説してみる篇

こんにちは、岩橋聡吾です。最近のAWSは、次から次に新たなサービスを展開し、その勢いは留まることを知リません。今やITと切っても切れない関係と言っても過言ではないでしょう。 そこでこの度、複数回に渡ってAWS上でのWebアプリ向けのサーバー環境構築について記事にしてみたいと思います。 今回構築するサーバー環境は、 ◉VPC（Virtual Private Cloud：土地全体）の構築 ◉AZ（Availability Zone：建造物エリア）、サブネット（：建造物を設置するための基礎）の構築 ◉WEBサーバーの設置（EC2） ◉ロードバランサー（ELB：玄関）の設置 ◉ステップサーバー（EC2：裏口玄関）の設置 ◉DNSの設定（Route53：住所登録） ◉データベースの設置（RDS） ◉KVSの設置（ElastiCache） 　…etc を想定しており、最終的には以下のようなイメージになります。 第１回では、後述するVPCとAvailability Zone (以下AZ)と呼ばれる設定とその動作確認までを行います。何事も下準備が大切です。 VPCを作成してみる まず最初にVPCを作成するのですが、そもそもVPCとは何でしょうか？ VPCとはAWSアカウント上に複数作成することが出来るプライベートなネットワークの単位です。一軒家を建てる為の土地全体といったところでしょうか。 VPCの配下には、AZがあり、その配下にはサブネットがあります。またAZは１つ以上のサブネットを保持することができます。AWS上で初めてネットワークを構築するときは最低でも１つのVPC、１つのAZ、１つのサブネットを作成する必要がします。 AZは建造物エリア、サブネットは建造物を設置するための基礎といったイメージです。 AZは互いに影響を受けないように場所やネットワークが分離されており、これらが専用の高速回線で相互接続されています。サブネットを複数個作成してそれぞれが別々のAZを使用する設定を行うことで、１つのAZがダウンしてもサービスの継続性には問題が生じない設計にすることができます。 一方のAZ内に建てられた家が火事になっても、もう一方のAZ内の家には影響がないという訳です。 また、特別な設定をしない限りは複数のVPC間での通信は出来ませんが、サブネット間の通信は必要に応じて通過させることができます。 それでは、以下の手順でVPCとAZをそれぞれ１つずつ作成してみましょう。 ※ AWSコンソールのデザインが最近変わりましたが、今回は以前のインターフェースを使って行きたいと思います。 VPCウィザードを開始しましょう。 最上位の「１個のパブリックサブネットを持つVPC」を選択します。この設定で作成したVPCはElasticIPを直接割り当てることでインターネットに接続することになります。より厳格に通信をコントロール可能なインフラを構築する場合は、１つ下の「パブリックとプライベートサブネットを持つVPC」を使用することになると思います。 次の画面で、作成するVPCの詳細設定をします。 先ずは、IP CIDR（サイダー）ブロックを設定します。ここでは適当に「/16」の大きさを確保することにします。 CIDRとは… 先ずはプライベートIPについておさらいしましょう。 IPアドレスは、「 ネットワーク部 」と「 ホスト部 」から成ります。ネットワーク部が短いほど・ホスト部分が長いほど大きなネットワークの構築が可能です。またネットワーク部とホスト部の構成には規格（クラス）があります。 クラスA： 10.0.0.0/8 = 10（ネットワーク部）+ 0.0.0（ホスト部） 　　　　 大きいネットワークを作る場合（最大16,777,216個のアドレス配布が可能） クラスB： 172.16.0.0/16 = 172.16（ネットワーク部）+ 0.0（ホスト部） 　　　　 中くらいのネットワークを作る場合（65,536個のアドレス配布が可能） クラスC： 192.168.1.0/24 = 192.168.1（ネットワーク部）+ 0（ホスト部） 　　　　 小さいネットワークを作る場合（256個のアドレス配布が可能） 上記クラスのIPアドレスのお尻に着く「/8」「/16」「/24」はCIDR表記と呼ばれ、ネットワーク部の長さを示す値で、IPアドレスを２進数表記にした場合の先頭から桁数になります。例えば「10.0.0.0（/8）」を２進数表記すると「00001010.00000000.00000000.01111001（/8）」になります。ネットワーク部はこの数字の羅列の先頭から「 8 」桁まで、つまり「00001010」を指します。このようなプライベートIPを「 クラスフル 」と呼びます。 さて本題のCIDRですが、これは「Classless Inter-Domain Routing」の略です。つまり「 クラスレス 」なので上のような規格に当てはめることなく自由なサイズのネットワークの構築が可能になります。仮に、257個のアドレスが必要なネットワークを構築したい場合、「クラスフル」だとクラスB、CIDR表記で「/16」のネットワークサイズ（最大65,536個のアドレス）を選択することになり、無駄が多くなります。一方「クラスレス」ですと、CIDR表記で「/23」のネットワークサイズ（最大512個のアドレス）を選択できるので無駄の少ないネットワークサイズ構築が可能になります。 上記のような、自由なサイズのネットワークの構築をする仕組みをCIDRと呼びます。 VPC名には半角英数字でお好みで設定しましょう！ 次にパブリックサブネットを設定します。 ここでは、IP CIDRブロックで確保した大きなIPアドレスの塊を使いやすいように分割します。サブネットで分割されたネットワークは必ず１つのAZに属します。 分割の粒度はインフラの設計要項によっても異なってくるのですが、ここでは分かりやすく「/24」で分割することにします（最大256個のアドレスの配布が可能）。 以下の設定はデフォルトのままVPCを作成します。 VPCの作成と、それに付随した設定が自動的に行われます。 VPCが正常に作成完了しました。このウィザードを完了した結果、VPCの他にサブネット・ルートテーブル・インターネットゲートウェイ・DHCPオプションセットも自動的に作成されました。 EC2インスタンスを立ち上げてみる では作成したVPC上にEC2インスタンスを配置して、VPCが正常に設定できたか確認してみましょう。 画面中央の「インスタンスを作成」ボタンを押してインスタンス作成ウィザードを始めます。 最も一般的なAmazon Linuxを選択します。 インスタンスタイプを選択します。今回は無料利用枠対象である t2.micro を選択し、次の手順に進みましょう。 ローンチするインスタンスの詳細設定を行います。 立ち上げるインスタンス数が１つ。使用するVPC・サブネットが先程作成したものであることを確認し、自動割当パブリックIPが有効であることを確認します。自動割当がされない場合は、Elastic IPを割り当てることでインターネットアクセスを確保する必要があるのですが、今回は確認用のため自動割当で済ませます。 問題なければ次の手順に進みます。 ストレージが8GB確保されていることを確認して次の手順に進みます。 これから立ち上げるインスタンスを区別できる名前を付け、次の手順に進みます。 セキュリティーグループを設定します。ここで特定のネットワークトラフィックのみを通過させるようにすることで不正アクセスのリスクを低減させます。今回はHTTPとHTTPSは全許可とし、SSHは自宅からのみを許可する設定としました。 設定が終わったら「確認と作成」を押します。 これまでの設定内容が確認画面に表示されますので、内容に問題がなければ「作成」ボタンを押します。 これから作成するインスタンスにアクセスするためのキーファイルを紐付けます。 今回の記事作成向けに新しくキーファイルを作成します。（次回以降にインスタンス作成する際は、このキーファイルを再利用します） 「新しくキーペアを作成する」を選び、キーペア名を入力したらキーペアをダウンロードします。ダウンロードするのを忘れてしまうとこのインスタンスにアクセスすることはできませんのでご注意を。。 ダウンロードが確認できたら「インスタンスの作成」を押しましょう。 EC2インスタンス一覧画面を覗いてみましょう。先程作成したインスタンスがリストアップされていますので、SSH経由で接続してみましょう (Windows環境の場合は接続手順が異なりますのでご注意ください)。 まずはインスタンスのIPアドレスを控えておきます。 ターミナルを起動し、以下のようなコマンドを入力しましょう。 以下のように表示されたら ec2-user ユーザーのログインに成功していることが確認できます。 $ chmod 600 [ダウンロードしたキーファイルのパス] $ ssh -i [ダウンロードしたキーファイルのパス] ec2-user@[IPアドレス] The authenticity of host ‘52.199.68.44 (52.199.68.44)’ can’t be established. RSA key fingerprint is 72:83:d2:19:b2:fb:bf:08:5b:9b:4f:6b:3d:5c:63:63. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘52.199.68.44’ (RSA) to the list of known hosts. __| __|_ ) _| ( / Amazon Linux AMI ___|\___|___| https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/ [ec2-user@ip-10-0-0-23 ~]$ 第1回目の最後に 今回は記事都合上ウィザードを使用する形となりましたが、AWS上で基本的なVPCとAZの設定を行いました。立ち上げるだけであればあっさりと設定できてしまうので、ネットワークに苦手意識があるような方でも詰まることなく設定出来るのではと思います。 しかし今回ご紹介した内容だけではまだまだ実用的なインフラとは言えませんので、次回以降このインフラの設定を詰めて行きたいと思います。 ご清覧頂きありがとうございました。 Wedding Parkでは一緒に技術のウエディングパークを創っていくエンジニアを募集しています。 興味のある方はぜひ一度気軽にオフィスに遊びにきてください。 ◉シリーズ ・やってみよう！AWSでWEBサーバー環境構築（シリーズ第2回） ・やってみよう！AWSでWEBサーバー環境構築（シリーズ第3回） ・やってみよう！AWSでWEBサーバー環境構築（Lambda|API Gateway|シリーズ第4回） ◉筆者のおすすめ記事 ・【DB設計入門|ER図|MySQL】コンビニレシートから学ぶ！データモデリング手法 ・【機械学習入門|Python|scikit-learn】結局何ができる？cheat-sheetから解説してみる篇

こんにちは。サーバーサイドエンジニアの武田(@takedajs)です。 会社の誕生日プレゼントで頂いたプッシュアップバーと腹筋ローラーを使って筋力アップに励んでいます！ 筋トレは健康に良いし、ストレス発散にもなりますので、運動不足になりがちなエンジニアの方にオススメです！ さて本題です。 1日中オフィスで仕事していることが多いので、気分転換も兼ねてランチをできるだけ外で食べるようにしています。 そこで今回は、弊社がある表参道で普段僕が行っているランチのお店を５件紹介します！ お店の条件 オフィスから徒歩５~10分以内で着くお店に行くようにしています。 12時にオフィスを出るとお店が混んでランチ難民になってしまうので、11:50にオフィスを出て12時までにお店に着くようにしています。 お店の紹介 ディップマハル 青山店 (カレー) いつもカレー2種類とタンドリーチキンがついたスペシャルセットを食べています！ 複数のカレーから2種類選ぶのですが、ホウレンソウで作られたサグチキンカレーがおすすめです！ かなり通っているので、顔といつも頼むメニューを覚えられてます笑 鳥良 青山店 (定食) チキン南蛮や唐揚げなど、鶏好きの僕としては堪らないお店です！ 店内の照明が少し暗めで落ち着いた雰囲気なので、まったりとランチを食べれます。 会社の締め飲み会でも利用させて頂いたこともあります。 ティーヌン 青山店 (アジア料理) ちょっと気分を変えてアジア料理が食べたくなったら行きます！ メインのメニューを頼むと、サイドメニューが食べ放題なので、いつも食べすぎてしまいます笑 サイドメニューはどれも美味しいのですが、特にグリーンカレーが絶品です！ 旨味 游 (定食) 揚げ物が美味しいので、ミックスフライをよく食べています！ 他にも肉と豆腐を卵に付けて食べる「肉豆腐」が絶品で、ご飯が何杯でも進みます笑 焼き魚などのメニューも沢山あるので、これから色んなものを食べてみたいと思います。 鉢屋 (定食) 日替わり定食の１つしかないのですが、小鉢などが沢山ついてコスパが凄いです！ 日替わりしかないのでお店に行かないとメニューが分からないですが、揚げ物や煮物などどれもとても美味しいです！ 毎日行列ができています笑 まとめ 表参道周辺はイタリアンやフレンチのお店しかないと思っていたのですが、探してみると定食屋や中華など様々なジャンルのお店があります！ 値段的には大体1000円くらいが相場かなと思います。 表参道以外でも、弊社には エンジニア・デザイナー専用のサテライトオフィス が外苑前にあるので、外苑前でランチを食べてからそのままサテライトオフィスに行くことも可能です。 まだまだ紹介したい美味しいお店が沢山あります！ この記事が好評であれば、また別の機会に記事を書きたいと思います笑

初めまして、システムエンジニア新卒1年目の菅原です。 今回は初めてredisを触ってみたので紹介します。 Redisに触れてみた背景 今年の9月半ばに職場の先輩たちと isucon6 に参加しました。 残念ながら敗退してしまいましたが、これまでパフォーマンスをここまで意識したことはなく、参加チームの通過者や本戦出場者の中でもMysqlのデータをRedisに移行してパフォーマンスを速くしているチームが多い印象でした。 少し調べてみるとRDBMSのような複雑な処理にはRedisのキーバリューストア（KVS）型は向かないが、すべてのデータセットをメモリ内に読み込むため、とても高速で高いパフォーマンスをすることができることが分かりました。 パフォーマンスに問題があった場合Redisを使えることがパフォーマンスチューニングにおいては大切なことなのでそんなRedisを触らないわけにはいかないということで初めて触ってみました。 Redisの特徴 RedisとはREmote DIctionary Serverの略語であり、イタリアのSalvatore Sanfilippo氏が開発を創始したKey-Value型のNoSQLであります。 インメモリベース すべてのデータがメモリ上に保持されるため，更新・参照が非常に高速です。 永続化 インメモリの高速性を持ちながら，同時にディスクベース・データストアの永続性をも備えているのが特徴です。Redisの永続化機構は，定期的に（または更新回数などの条件により）メモリ上のデータセットのスナップショットをファイル（.rdb）にダンプし，再起動時にはこのスナップショットの内容をメモリに読み込むことにより，前回ダンプした状態までデータセットを復元します。 多彩なデータ構造 String(文字列) List(連結リスト） Set(重複のない集合) Sorted Set(ソート済みのSET) Hash(連想配列) 複数の文字列要素からなるデータ構造をバリューとして持つことができ，通常の文字列型のバリューと同じようにキーで参照することができます。 引用元： http://gihyo.jp/dev/feature/01/redis/0001 Redisのインストール 今回の環境 mac OS さくらVPS php5.3.3 使った環境はさくらVPS上でインストールしていきました。 ではインストールからしてみましょう。 $ wget http://redis.googlecode.com/files/redis-3.2.4.tar.gz $ tar zxvf redis-3.2.4.tar.gz $ cd redis-3.2.4 $ make $ sudo make install 上記コマンドでredisがインストールすることができました。 動作確認 では動作確認 $ redis-server 以下のような画面が出てサーバーが立ち上がったことが確認できます。 別のターミナルにてredis-cliが使えるか確認 $ redis 127.0.0.1:6379> ping PONG pingと打てばPONGと返ってきます。これでサーバーが立ち上がっていることがわかります。 redis.conf 設定 $ sudo mkdir /etc/redis $ sudo cp redis-3.2.4/redis.conf /etc/redis/redis.conf このときバックアップを念のためにとっておきましょう このconfファイルを編集していきます。 sudo vim /etc/redis/redis.conf デーモンの設定を有効にします。 #daemonize no ↓ daemonize yes ログファイルの出力先を変更します。 #logfile stdout ↓ logfile /var/log/redis.log サーバのログの情報量を設定します。 #loglevel verbose ↓ loglevel notice サーバのログの情報量を設定します。 #loglevel verbose ↓ loglevel notice メモリのダンプファイルを保存する場所を変更します。 dir ./ ↓ /usr/local/redis/ これでredisの設定ができましたので次は自動起動スクリプトを以下のように記述していきましょう sudo vim /etc/init.d/redis #!/bin/sh # chkconfig: - 85 15 # description: redis-server # processname: redis # # Simple Redis init.d script conceived to work on Linux systems # as it does use of the /proc filesystem. REDISPORT=6379 EXEC=/usr/local/bin/redis-server CLIEXEC=/usr/local/bin/redis-cli PIDFILE=/var/run/redis_${REDISPORT}.pid CONF="/etc/redis/${REDISPORT}.conf" case "$1" in start) if [ -f $PIDFILE ] then echo "$PIDFILE exists, process is already running or crashed" else echo "Starting Redis server..." $EXEC $CONF fi ;; stop) if [ ! -f $PIDFILE ] then echo "$PIDFILE does not exist, process is not running" else PID=$(cat $PIDFILE) echo "Stopping ..." $CLIEXEC -p $REDISPORT shutdown while [ -x /proc/${PID} ] do echo "Waiting for Redis to shutdown ..." sleep 1 done echo "Redis stopped" fi ;; *) echo "Please use start or stop as first argument" ;; esac 以下コマンドで設定を反映します。 $ sudo chkconfig --add redis $ sudo chkconfig redis on 下記のようなレスポンスが返って来ると成功しています。 $ /sbin/chkconfig --list | grep redis redis 0:off 1:off 2:on 3:on 4:on 5:on 6:off これでredisを扱う環境と簡単な設定ができました。 php 側から redis 動作確認 ではphp側から実際に軽く使ってみましょう php側からredisを扱うことができるライブラリをインストール $ sudo yum -y install php-pecl-redis --enablerepo=epel $ sudo service httpd restart これでphp側からredisを扱うことができます。 では以下コードでちゃんと返答があることを確認してみましょう。 index.php <?php $redis = new Redis(); $redis->connect("127.0.0.1",6379); // 値をセットする $redis->set('title', 'Redis触ってみました'); // 値を取得する $value = $redis->get('title'); // 表示 echo $value; ちゃんと返ってきていることがわかりました。 まとめ Redisの環境構築と簡単な取り出しまでですが簡単に設定することが出来ました。 ただデータ構造が複雑でどの場面でどの構造を使うことができるかを知ることが大切であると感じました。 しかし、Redisを使うことができるとかなり高速なパフォーマンスを出すことができるので実際に多くのデータを使って試してみることが慣れるために必要だと思いました。 次回は実際にmysqlとの比較などをしてパフォーマンスの検証をしてみたいと思います。

こんにちは、エンジニアの榎本です。 チーム開発において、ファイル数やクラスが増えてくると、新しいメンバーに説明をする際など、ドキュメントがないと説明が難しくなってくることがあります しかし実際のところ、ドキュメントを作成する工数を確保できず、せっかく作ったドキュメントがあってもどんどん陳腐化している現場も多いのではないでしょうか そのため、今回は phpDocumentor を用いて PHP のコードから自動でドキュメントを生成する方法を紹介したいと思います 作業環境 CentOS 7.2 PHP 7.0.12 Composer 1.2.2 phpDocumentor のインストール まずは新規にディレクトリを作成し、Composer で phpDocumentor をインストールします $ mkdir dev $ cd dev $ composer require --dev phpdocumentor/phpdocumentor Using version ^2.9 for phpdocumentor/phpdocumentor ./composer.json has been created Loading composer repositories with package information Updating dependencies (including require-dev) ...（略） Writing lock file Generating autoload files これでインストールが完了です Composer でインストールすることができるのでとても簡単ですね（開発環境でのみ使用すると思いますので --dev オプションを忘れないように気をつけてください） それでは、インストールが完了したのでバージョンを確認してみます $ composer show | grep phpdocumentor/phpdocumentor phpdocumentor/phpdocumentor v2.9.0 Documentation Generator for PHP Composer で phpDocumentor が問題なくインストールされたことが確認できたので、ドキュメントの生成元のコードを簡単に書いてみたいと思います app/util/tax.php <?php namespace App\Util; class Tax { /** * 税率 * * @var float */ const RATE = 0.08; /** * 税込金額を返す * * @param int $price * @return int */ public static function getIncluded(int $price) { return floor($price * (1 + self::RATE)); } /** * 税抜金額を返す * * @param int $price * @return int */ public static function getExcluded(int $price) { return ceil($price / (1 + self::RATE)); } } app/controllers/product.php <?php namespace App\Controllers; use App\Util; class Product { /** * 商品詳細ページ * * @param int $id * @param int $price * @return void */ public function showAction(int $id, int $price) { $product = $this->getProduct($id, $price); $this->view->product = $product; } /** * 商品情報を返す * * @param int $id * @param int $price * @return array */ private function getProduct(int $id, int $price): array { return [ 'id' => $id, 'price' => Util::getIncluded($price), ]; } } たった2ファイルの簡単な PHP のコードですが、上記のコードから早速ドキュメントを自動生成してみたいと思います ドキュメントの自動生成 ドキュメントの生成には phpdoc run コマンドを使用します（今回は phpdoc コマンドは Composer でインストールしたものを使用しているので注意してください） $ vendor/bin/phpdoc run -d app -t public/doc Collecting files .. OK Initializing parser .. OK Parsing files ...（略） Analyze results and write report to log .. 0.000s phpdoc run コマンドのオプションですが、 d オプションでコードが置かれているディレクトリを指定し、 t オプションでドキュメントの生成先ディレクトリを指定します。 今回は public/doc に自動生成されたドキュメントを配置するように指定しました。 それではドキュメントが生成されたのでブラウザで確認してみます。 たった2ファイルしかなかったので、中身が少ないですが、このようにクラスのメソッドの一覧や、メソッドの引数の一覧などがブラウザ上から確認できるようになりました クラスの階層構造を可視化する phpDocumentor はドキュメントの自動生成時にクラスの階層構造を図式で可視化することもできるので、どのような図式ができるのか試してみます まずは、必要なライブラリを yum でインストールします。 $ sudo yum install graphviz graphviz-gd インストールが完了したら、もう一度 phpdoc run コマンドでドキュメントを作成してみます。 このような図が表示されたら OK です！ まとめ phpDocumentor を使用して、PHP のコードから自動でドキュメントを生成してみました クラスの階層構造を可視化することもできるので、新しいメンバーがプロジェクトの全体像を把握することもブラウザ上で簡単に行うことができ、プロジェクトの説明を行う際などにも役立つと思います Composer でとても簡単にインストールすることができ、導入への障壁がかなり低いので、ぜひ皆さんのプロジェクトにも導入してみてはいかがでしょうか

こんにちは。サーバーサイドエンジニアの栗山です。 毎年恒例となりました、学生向けの冬のインターン、 WeddingPark Winter TechCamp 。 今年も開催いたします！ 概要 ウエディングパークが運営する、日本最大級のフォトウエディングスタジオ検索サイト「 Photorait 」の、サービス企画・開発を行っていただきます。 参加している学生同士でチームを組み、4日間で企画・設計・開発・テストまでの一連の流れを行っていただき、実際のウエディングパークのサービス開発フローを体感していただきます！ Photorait 担当エンジニア紹介 武田 翔平 メディア開発本部　システムエンジニア 2014年新卒入社。 Go言語の検証・導入のプロジェクトを担当後、現在、今回インターンで企画・開発して頂く「 Photorait 」の主担当エンジニアとして、開発に携わっています。 栗山 茜 メディア開発本部　システムエンジニア 2013年新卒入社。 Google Adwords APIを用いた広告契約管理システムの開発プロジェクトを担当後、現在、婚約・結婚指輪のクチコミサイト「 Ringraph 」の開発に携わっています。 インターンの様子 1日目 初日はオリエンテーション、チーム決めから始まります。 チーム決めの後、開発テーマを発表しますので、テーマもとにチームで話し合いをしながら、 開発する機能について企画をしていただきます。 2～3日目 開発する機能が決定した後は、設計をし、現役エンジニア・デザイナーからのレビューを行います。 レビューが終わった後は、それぞれチームに分かれ、開発がスタート！ 開発中のエンジニア・デザイナーへの質問はいつでもOKです！ 技術的な質問や、UIUXに関する議論などをしながら、機能のブラッシュアップをしていただきます。 開発は、ウエディングパークオフィス、または エンジニア・デザイナのための集中スペース 「Cスタ」 で行う予定です。 開発後にはエンジニア・デザイナーからのコードレビューも行います。 4日目 最終日は、開発した機能についてウエディングパークの経営幹部・社員の前でチーム毎にプレゼンテーションを行っていただきます。 プレゼンテーション終了後、経営幹部で議論をし、優勝チームを決定致します！ インターン後の様子 毎年、インターン終了時には、学生同士とても仲良くなっています。 4日間、同年代の仲間と一緒に、切磋琢磨しながら開発ができます！ 昨年のインターン生と インターン参加者の声 職場の雰囲気を知ることができた。苦手意識のある開発も、楽しく学びながらやれた。 システム開発の流れを実際のシステムを用いて体験できた。 チームで企画し設計・開発まで行うことを通して、チームで活動する大切さを知った。 インターン後入社した社員の声 久保 雄登 2016年新卒入社 インターンでは、ウエディングパークでの企画から開発までの一連の流れを学ぶことができます。 様々な社員と交流でき、またフィードバックの場が多いため、ウエディングパークならではの、 暖かくフラットで切磋琢磨できる環境を肌で感じることができました。 この会社で働きたいと強く思うようになったきっかけがこのインターンでした。 入社後の現在もギャップを感じることなく楽しく働いています。 社員の手厚いサポートを受けながら、チームで新しいサービスの提案をしてみませんか。 最後に 今年の WeddingPark Winter TechCamp 2018 の参加者を、絶賛募集中です！ 応募はこちらから　　 Wantedly 　/　 リクナビ

みなさま、こんにちは！エンジニアの東です。 このたび、ウエディングパークでは、エンジニア・デザイナのための、モノづくりのための集中スペースとして利用できるサテライトオフィスが開設されました。 今回、こちらについて紹介したいと思います！ サテライトオフィスについて サテライトオフィス名：Wedding Park CREATORS STUDIO（通称：Cスタ) コンセプト 「未来を創造するクリエイターのための開発スタジオ」 新しい価値を創造する場所という思いが込められています。 いかがでしょうか！ブライダルが伝わる弊社のロゴより、クリエイターらしさを感じるロゴですよね。 利用について 本社から徒歩圏内にあり、エンジニア・デザイナが個人の技術力向上のための勉強やモノづくりを集中して利用できる場所です。非常に静かな場所に位置していますので、非常に作業に集中できると、利用者に非常に好評です！ Cスタは、勤務時間中は業務の集中のために利用できます。そして、勤務時間外や休日にも開放され、個人の技術力向上のために利用できます。 土日にもエンジニアが絶えず居て、それぞれが、もくもくと自分のやりたいことに集中しています。社内エンジニアには、家でというより外出してコーディングするノマドなエンジニアが多く、快適なスペースで作業できるCスタは土日の利用率も高いです！ それでは内装について紹介していきます。 内装紹介 内装全体はこのようになってます。 天井をうちっぱなしにすることで、スペースを窮屈に感じず、シンプルでカッコいい、かつ弊社らしさを併せ持った内装です。 素敵な内装です！ ゾーン このCスタは、大きく3パターンの作業スペースがあります。 1.壁向かい席 – 目の前は壁とディスプレイ！視界は作業に一点集中できます。そして、体にフィットするすわり心地のかなり良いチェアで長時間の作業も快適です！ 2.スタンディングデスク – やる気がわかない、そんなときは短期集中！立ってコーディングです。 3.ロゴテーブル – 気分転換＆リラックスで集中！ – 弊社のロゴを象ったロゴテーブルと他のスペースとは異なるイスで、気分を変えてリラックスして作業ができます そして、BluetoothでつながるBoseのスピーカもあり、グループで作業する際にも快適です！ Cスタではこのようにいろんな集中のための工夫がありますが、実はそれだけはないんです！ ギークなガジェット スマホで簡単プログラミングのIoTガジェット：MESH プログラマブルな掃除機：Cocorobo スマホでVR：Galaxy Gear 360度カメラ: Theta 最近流行のガジェットに触れることは、日頃webサイトを実装しているエンジニア・デザイナにとっては新しい刺激！これからの未来を創造するためにも今の流行を追っていかないとですね。 Cスタ、いかがだったでしょうか。 Cスタがオープンされてからまだ間もないですが、これからどんどん、いろんな活用をしていき、エンジニア・デザイナと一緒に、より良くこのCスタもLEVEL UPしていきます！ そして、ウエディングパークでは、技術のウエディングパークを創っていく、未来の仲間を募集しています。興味のある方は、まずはお気軽にオフィスに遊びにきてください。 IT×ブライダルで業界を変える！プロフェッショナルなWEBエンジニア募集！

はじめまして。メディア開発本部エンジニアの久保です。 2016年8月に公開された、Windows 10 Anniversary Update では Bash on Ubuntu on Windows の提供が始まりました。 Windows でもネイティブな Bash 環境が整ったわけですが、まだまだ Windows 7 や 8.1 を使われている方もいるかと思います（私もその一人です！）。 そんな Windows 8.1 以前の環境でも GNU コマンドが使用したい！と思い、Windows に Unix ライクな環境を構築してみました。 MSYS2 とは MSYS2(Minimal SYStem2) は Windows 上で Unix ライクなシェル環境を提供するもので、 ターミナルに mintty シェルに Bash パッケージマネージャに pacman で構成されています。 Windows で Git を使っている方は、Git Bash でおなじみかと思います。 今回は MSYS2 をインストールして、Windows で GNU ツールを使えるようにしたいと思います。 MSYS2 のインストールと設定 検証環境 Windows 7 Professional SP1 64-bit MSYS2 のインストール MSYS2 installer より、インストーラをダウンロードします。 今回は 64-bit の Windows なので、 msys2-x86_64-*.exe をダウンロードし、実行します。 インストールは特別な指定なく進められるかと思います。 インストール先は、標準の C:\msys64 としました。 MSYS2 の設定 インストールが完了したら、スタートメニューから MinGW-w64 Win64 Shell を起動します。 公式ドキュメント に沿って進めていきます。 まずは、アップデートをしましょう。パッケージマネージャの pacman のバージョンを確認します。 $ pacman --version .--. Pacman v4.2.1-463-g28da-dirty - libalpm v10.0.0 / _.-' .-. .-. .-. Copyright (C) 2006-2016 Pacman Development Team \ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet '--' This program may be freely redistributed under the terms of the GNU General Public License. バージョンは 4.2.1 でした。 pacman のバージョンによって、アップデートコマンドが異なるので注意が必要です。 次に、core の update をします。 $ update-core ==> Update package databases... :: パッケージデータベースの同期中... mingw32 296.0 KiB 517K/s 00:01 [#####################] 100% mingw32.sig 96.0 B 0.00B/s 00:00 [#####################] 100% mingw64 295.7 KiB 2039K/s 00:00 [#####################] 100% mingw64.sig 96.0 B 0.00B/s 00:00 [#####################] 100% msys 135.8 KiB 924K/s 00:00 [#####################] 100% msys.sig 96.0 B 0.00B/s 00:00 [#####################] 100% ==> Checking if there are critical packages to upgrade. bash 4.3.042-4 -> 4.3.046-1 pacman 5.0.0.6348.cc5a8f1-1 -> 5.0.1-1 msys2-runtime 2.4.1.16860.40c26fc-1 -> 2.6.0-1 ==> Core packages require updating. ==> Please close all other MSYS2 derived windows (e.g. terminal ==> windows, Bash sessions, etc) before proceeding. ==> 警告: When the update has completed, you MUST close this MSYS2 window ==> 警告: (use Alt-F4 or red [ X ], etc.), rather than 'exit'!!! Press [Enter] key when ready to start update... ==> Updating core packages... 依存関係を解決しています... 衝突するパッケージがないか確認しています... パッケージ (4) bash-4.3.046-1 msys2-runtime-2.6.0-1 msys2-runtime-devel-2.6.0-1 pacman-5.0.1-1 合計ダウンロード容量: 14.42 MiB 合計インストール容量: 72.88 MiB 最終的なアップグレード容量: 21.44 MiB :: インストールを行いますか？ [Y/n] :: パッケージを取得します ... msys2-runtime-2.6.0... 2.2 MiB 1273K/s 00:02 [#####################] 100% bash-4.3.046-1-x86_64 1876.6 KiB 1414K/s 00:01 [#####################] 100% pacman-5.0.1-1-x86_64 6.8 MiB 1354K/s 00:05 [#####################] 100% msys2-runtime-devel... 3.6 MiB 1458K/s 00:03 [#####################] 100% (4/4) キーリングのキーを確認 [#####################] 100% (4/4) パッケージの整合性をチェック [#####################] 100% (4/4) パッケージファイルのロード [#####################] 100% (4/4) ファイルの衝突をチェック [#####################] 100% (4/4) 空き容量を確認 [#####################] 100% :: パッケージの変更を処理しています... (1/4) 更新 msys2-runtime [#####################] 100% (2/4) 更新 bash [#####################] 100% (3/4) 更新 pacman [#####################] 100% (4/4) インストール msys2-runtime-devel [#####################] 100% Please close this window. メッセージにもありますが、アップデートが完了したら、ターミナルウィンドウを閉じます。 今回は、 close コマンドではなく、 [x]ボタンや Alt + F4 で閉じてください。 再度、スタートメニューから MinGW-w64 Win64 Shell を起動します。 続いて、パッケージのアップデートをしましょう。 $ pacman -Syuu :: Starting core system upgrade... 警告: terminate other MSYS2 programs before proceeding 依存関係を解決しています... 衝突するパッケージがないか確認しています... パッケージ (2) filesystem-2016.07-2 mintty-1~2.5.0-1 合計ダウンロード容量: 0.18 MiB 合計インストール容量: 0.39 MiB 最終的なアップグレード容量: 0.02 MiB :: インストールを行いますか？ [Y/n] y :: パッケージを取得します... filesystem-2016.07-... 37.4 KiB 18.2M/s 00:00 [#####################] 100% mintty-1~2.5.0-1-x86_64 151.2 KiB 445K/s 00:00 [#####################] 100% (2/2) キーリングのキーを確認 [#####################] 100% (2/2) パッケージの整合性をチェック [#####################] 100% (2/2) パッケージファイルのロード [#####################] 100% (2/2) ファイルの衝突をチェック [#####################] 100% (2/2) 空き容量を確認 [#####################] 100% :: パッケージの変更を処理しています... (1/2) 更新 filesystem [#####################] 100% WARNING: the shell starting scripts have been unified. Please update your shortcuts to the following targets, otherwise they will STOP WORKING: * MSYS2_ROOT\msys2_shell.cmd -mingw32 * MSYS2_ROOT\msys2_shell.cmd -mingw64 * MSYS2_ROOT\msys2_shell.cmd -msys (2/2) 更新 mintty [#####################] 100% 警告: terminate MSYS2 without returning to shell and check for updates again 警告: for example close your terminal window instead of calling exit アップデートが完了したらターミナルウィンドウを閉じましょう。 メッセージに書かれているように、起動スクリプトが変更されています。 起動スクリプトを次のように変更をしました。 ■ MinGW-w64 Win32 Shell C:\Windows\System32\cmd.exe /A /Q /K C:\msys64\mingw32_shell.bat ↓ C:\Windows\System32\cmd.exe /A /Q /C C:\msys64\msys2_shell.cmd -mingw32 ■ MinGW-w64 Win64 Shell C:\Windows\System32\cmd.exe /A /Q /K C:\msys64\mingw64_shell.bat ↓ C:\Windows\System32\cmd.exe /A /Q /C C:\msys64\msys2_shell.cmd -mingw64 ■ MSYS2 Shell C:\Windows\System32\cmd.exe /A /Q /K C:\msys64\msys2_shell.bat ↓ C:\Windows\System32\cmd.exe /A /Q /C C:\msys64\msys2_shell.cmd -msys もう一度ターミナル（ MinGW-w64 Win64 Shell ）を起動して、アップデートがないか確認しておきましょう。 $ pacman -Syuu :: パッケージデータベースの同期中... mingw32 は最新です mingw64 は最新です msys は最新です :: Starting core system upgrade... 何も行うことがありません :: システム全体の更新を開始... :: repman-git を msys/pactoys-git に置き換えますか？ [Y/n] y 依存関係を解決しています... 衝突するパッケージがないか確認しています... パッケージ (42) bash-completion-2.3-1 bsdcpio-3.2.1-1 bsdtar-3.2.1-1 coreutils-8.25-1 crypt-1.3-1 curl-7.50.1-1 file-5.25-1 flex-2.6.1-1 gawk-4.1.4-1 gcc-libs-5.3.0-3 gettext-0.19.7-3 gmp-6.1.0-2 gnupg-1.4.20-1 grep-2.22-3 gzip-1.7-1 heimdal-libs-1.5.3-9 info-6.1-1 libarchive-3.2.1-1 libasprintf-0.19.7-3 libassuan-2.4.2-1 libcrypt-1.3-1 libcurl-7.50.1-1 libexpat-2.1.1-1 libgettextpo-0.19.7-3 libgpg-error-1.23-1 libgpgme-1.6.0-1 libidn-1.33-1 libintl-0.19.7-3 liblzma-5.2.2-1 libnettle-3.2-1 libopenssl-1.0.2.h-1 libssh2-1.7.0-1 libtasn1-4.9-1 mpfr-3.1.4-1 msys2-launcher-git-0.3.32.56c2ba7-2 ncurses-6.0.20160220-1 openssl-1.0.2.h-1 pactoys-git-r2.07ca37f-1 rebase-4.4.2-1 repman-git-r23.87bf865-1 [削除] wget-1.17.1-3 xz-5.2.2-1 合計ダウンロード容量: 0.90 MiB 合計インストール容量: 87.40 MiB 最終的なアップグレード容量: 6.47 MiB :: インストールを行いますか？ [Y/n] y 以上でインストールが完了しました。 続いて、設定を行いましょう。 MSYS2 の設定 現在だと最低限のツールしかインストールされていないため、よく使われるパッケージをインストールします。 ターミナル（ MinGW-w64 Win64 Shell ）を起動します。 base-devel パッケージをインストールします。 $ pacman -S base-devel :: 54 のパッケージがグループ base-devel にあります: :: リポジトリ msys 1) asciidoc 2) autoconf 3) autoconf2.13 4) autogen 5) automake-wrapper 6) automake1.10 7) automake1.11 8) automake1.12 9) automake1.13 10) automake1.14 11) automake1.15 12) automake1.6 13) automake1.7 14) automake1.8 15) automake1.9 16) bison 17) diffstat 18) diffutils 19) dos2unix 20) file 21) flex 22) gawk 23) gdb 24) gettext 25) gettext-devel 26) gperf 27) grep 28) groff 29) help2man 30) intltool 31) lemon 32) libtool 33) libunrar 34) m4 35) make 36) man-db 37) pacman 38) pactoys-git 39) patch 40) patchutils 41) perl 42) pkg-config 43) pkgfile 44) quilt 45) rcs 46) scons 47) sed 48) swig 49) texinfo 50) texinfo-tex 51) ttyrec 52) unrar 53) wget 54) xmlto 選択して下さい (デフォルト=all): 依存関係を解決しています... 衝突するパッケージがないか確認しています... パッケージ (76) db-5.3.28-2 docbook-xml-4.5-2 docbook-xsl-1.78.1-3 expat-2.1.1-1 gdbm-1.11-3 glib2-2.48.0-1 libgc-7.2.d-1 libgcrypt-1.6.4-1 libgdbm-1.11-3 libguile-2.0.11-3 libiconv-devel-1.14-2 libltdl-2.4.6-2 libpipeline-1.4.0-1 libunistring-0.9.6-1 libxslt-1.1.28-7 perl-Locale-Gettext-1.05-4 perl-Module-Build-0.4212-1 perl-Test-Pod-1.50-1 perl-XML-Parser-2.44-1 perl-YAML-Syck-1.29-1 python2-2.7.11-1 tar-1.29-1 asciidoc-8.6.9-4 autoconf-2.69-3 autoconf2.13-2.13-2 autogen-5.18.4-2 automake-wrapper-10-1 automake1.10-1.10.3-3 automake1.11-1.11.6-3 automake1.12-1.12.6-3 automake1.13-1.13.4-4 automake1.14-1.14.1-3 automake1.15-1.15-2 automake1.6-1.6.3-2 automake1.7-1.7.9-2 automake1.8-1.8.5-3 automake1.9-1.9.6-2 bison-3.0.4-1 diffstat-1.58-1 diffutils-3.3-3 dos2unix-7.3.4-1 file-5.25-1 flex-2.6.1-1 gawk-4.1.4-1 gdb-7.9-2 gettext-0.19.7-3 gettext-devel-0.19.7-3 gperf-3.0.4-3 grep-2.22-3 groff-1.22.3-1 help2man-1.47.3-1 intltool-0.51.0-2 lemon-3.8.7.0-1 libtool-2.4.6-2 libunrar-5.3.7-1 m4-1.4.17-4 make-4.2.1-1 man-db-2.7.4-1 pacman-5.0.1-1 pactoys-git-r2.07ca37f-1 patch-2.7.5-1 patchutils-0.3.3-2 perl-5.22.1-1 pkg-config-0.29.1-1 pkgfile-15-1 quilt-0.64-1 rcs-5.9.4-1 scons-2.5.0-1 sed-4.2.2-2 swig-3.0.10-1 texinfo-6.1-1 texinfo-tex-6.1-1 ttyrec-1.0.8-1 unrar-5.3.7-1 wget-1.17.1-3 xmlto-0.0.28-1 合計ダウンロード容量: 50.00 MiB 合計インストール容量: 282.87 MiB 最終的なアップグレード容量: 227.11 MiB :: インストールを行いますか？ [Y/n] y 現状だと、Windows の PATH が参照されないため、Windows にインストールされているプログラムを実行できません。 そこで、これを参照するようにします。 C:\msys64\msys2_shell.cmd を以下のように変更します。 rem set MSYS2_PATH_TYPE=inherit ↓ set MSYS2_PATH_TYPE=inherit 以上で設定が完了しました。 使ってみましょう ホームディレクトリは、 /home/username で、実体は、 C:\msys64\home\username です。 ssh をインストールしてみます。パッケージのインストールは、 pacman -S パッケージ名 で行えます。 pacman -S openssh インストール可能なパッケージは、次のコマンドで確認できます。 pacman -Sl おわりに 今回は、Windows に Unix ライクな環境を構築することを目的に、MSYS2 を用いて Bash 環境を構築しました。 Mac や Linux と同一の環境とまではいきませんが、ローカル環境でちょっとコマンドを実行したいとき、Mac で作成したスクリプトを Windows でも実行したいときなどに、大いに役立てられるのではないでしょうか。 そして、ウエディングパークでは、技術のウエディングパークを創っていく、未来の仲間を募集しています。 興味のある方は、まずはお気軽にオフィスに遊びにきてください。 IT×ブライダルで業界を変える！プロフェッショナルなWEBエンジニア募集！

こんにちは。結婚写真を撮影できるスタジオ検索サイト「 Photorait 」を担当している、エンジニアの武田(@takedajs)です。 先日ウエディングパークで行われた合同LT会について報告致します。 今回合同で開催させて頂いた会社は、僕が大学院時代にエンジニアインターンとして働かさせてもらっていた、ベーシック(basic)さんです。 前に書きました「 社内LT会の取り組みについて 」の記事をベーシックCTOの桜庭さんに見ていただいたのがきっかけで、今回の合同LT会を開催することになりました！ 発表内容 以下、発表内容です。 各社3人ずつ合計6名に質疑応答合わせて10分の発表をしてもらいました！ WeddingPark 久保 「Wedding Parkについて」 ベーシック 桜庭さん 「ベーシックの夜明け」 WeddingPark 菅原 「一週間でGoやってみた go × SlackAPI」 ベーシック 森さん 「ferretレコメンド」 WeddingPark 東 「Chrome extensionで作業効率アップ！」 ベーシック 五島さん 「DockerをCIでドッカンドッカン」 1: 「Wedding Parkについて」 WeddingPark 久保 新卒1年目の久保です。ウエパの技術やサービスについて発表してもらいました。外部とのLT会で初の発表でしたが、トップバッターで堂々と発表していて良かったです！ 2: 「ベーシックの夜明け」 ベーシック 桜庭さん 50枚以上のスライドでベーシックのこれまでの技術の歴史を発表して頂きました。内容が濃く、テンポの良い発表は、とても勉強になりました！(自分のTwitterアイコンTシャツ、僕も欲しいです笑) 3: 「一週間でGoやってみた go × slackAPI」 WeddingPark 菅原 新卒1年目の菅原です。今回の発表を行うために、初めてGo言語を触ったみたいです！Go言語を勉強し始めてからSlackに天気予報をつぶやくボット作成までを発表してもらいました。 4: 「ferretレコメンド」 ベーシック 森さん WEBマーケティングのポータルサイトであるferretを担当されている森さんに、ferretのレコメンドについて発表して頂きました。TensorFlowや機械学習など、今ホットなワードが多く出てきて、勉強になることが多かったです！ 5: 「Chrome extensionで作業効率アップ！」 WeddingPark 東 普段業務で不便だと思っていたところをChrome extensionを使い改善したことについて発表してもらいました。Chrome extension は作ったことがなかったので、勉強になりました！ 6: 「DockerをCIでドッカンドッカン」 ベーシック 五島さん LT会の司会として事前に発表タイトルを聞いたときに、かなりツボってしまいました笑当日の発表内容でも多くの笑いポイントがあり、Dockerのことも知れたので、トリにふさわしい発表でした！ LT会の雰囲気 いつもと同様に、ピザ x 寿司 x ビール を飲んだり食べたりしながら、リラックスした雰囲気でのLT会です！最後は、ウエパ合同LTの恒例となっている相手の会社の頭文字ポーズをしての集合写真です笑 最後に 外部のエンジニアの方と交流ができ、今回も良い刺激を受け、技術に対して更なるモチベーションアップになりました！ また、僕自身としても、インターン時代にお世話になった方とこういった交流ができ、嬉しかったです！ ベーシックの皆様、合同LT会を開催して頂き本当にありがとうございました！！

こんにちは。サーバーサイドエンジニアの栗山です。 少し時間が経ってしまいましたが、先日、ウエディングパークで「女子エンジニアLT夏祭り」を開催致しました！ 今回は、社内外の女子エンジニアの10名の方に発表いただき、大変盛り上がりました！ その様子についてレポートさせていただきます。 発表テーマ 今回のLT夏祭りのテーマは、「エンジニアライフスタイル」。 普段興味があることや、最近気になる技術トピックス、勉強会レポートなどを発表いただきました！ LT夏祭りの様子 会場は、ウエディングパークのオフィス。 エントランスには夏らしいポスター。 会場に入ると、かわいいお料理に、カフェラテ。 これにテンションがあがらない女子がいるでしょうか。 こんなLT会はじめてでした！ テンション最高潮のまま、LT会スタート！ ※ 以下、タイトルの○○部分は、個人名やプロダクト名のため変更して紹介しております。 ※ 順番は、発表順となります。 1. はじめまして、○○です。 女子エンジニアの、リアルなライフスタイルについて。 普段好きでよく行く場所、プライベートで勉強しているプログラミング言語などについてゆるく盛り上がりました！ おしゃれなパン屋さん、行きたい。 2. 3D楽しいよって話 最近流行っている映画やゲームなど、身近なところにある3Dの例を挙げながら、ご自身が感じる3Dの魅力についてお話しいただきました！ リアルな偽物が表現できるところ、絵が描けなくても表現に関われるところなどが魅力的とのこと。 3Dに関する資格も取得されているそうです！かっこいい。 3. ○○家を支える技術 結婚準備の際のお話でした。結婚式は「プロジェクト」であり、プロジェクトを円滑に進めるために、Redmineなどのツールを使って準備を進められたそうです。 Redmineは開発に使うもの、と思っておりましたが、こんな使い方があるとは！ 結婚式準備はたくさんあると思いますが、誰のタスクで、期限はいつまでなのか、明確になりますね！ 4. Linda and Rails Girls 女性を対象としたプログラミングのワークショップ「Rails Girls」に参加されたことがあるそうで、 創始者のリンダさんと会った際のこと、実際に参加してみた感想を発表してくださいました。 リンダさんは、Rails Girlsの活動の他にも、「Hello Ruby」という、プログラミング言語のRubyの基礎を楽しく学べる絵本が発売されていたりとかなり有名な方ですよね！！ 私もRails Girlsに参加してみたいです。 5. 女性の働き方について 結婚、子育てと、仕事の両立について、ご自身の経験を含めて発表してくださいました。 会社の今の制度では足りなく、本当に必要だと思うものについては、自分で声をあげて作っていくことが必要だと話してくださいました。 私も大変気になる部分だったので、興味深かったです！ 6. わたしが女子を忘れないための10の理由 テストをするときは可愛い画像を使う、周りの男性が髪型やネイルの変化に気づいてくれる、などがありました！ 女子力は、周りの男性によって支えられているそうです。 7. Processingで遊んでみた Processingをつかっての、会場の音に反応してスライドの絵がリアルタイムで変わるデモを実演してくださいました。 音の大きさで動きが変わったりして、会場が大変盛り上がりました。 動画を載せられないのが残念です・・・！ 8. ○○と開発手法と私 普段、プロダクトの開発をより効果的・効率的にするための開発手法を研究されているそうです。 プロダクトを改善するだけでなく、チームが楽しく充実した開発ができる環境を創っていく、という考えが、とても素敵です。 9. GitHub Tips GitHubのTipsをスピーディにご紹介くださいました！ IssueやPull requestsのテンプレートの追加方法など、具体的で役立つTipsでした。 そしてかなりスピード感のあるLTでした。 私はIssueなど書くとき、どう書けばわかりやすいかと悩むことが結構あるので、テンプレートを追加できるのは便利だと思いました！！ 10. インフラエンジニアライフ ネットワーク機器を最新の機器へリプレースした際のお話をしてくださいました！ リプレースしたことで、サーバーラックの使用U数（サーバーラックの１区画の高さの単位）を削減したり、費用を削減できたそうです。 会場の様子 約2時間半のLT夏祭りでしたが、発表中に多数笑いあり、わきあいあいとした雰囲気でとっても盛り上がりました！ アットホームな雰囲気が本当よかったです。 最後に 参加された総勢約20名の女子エンジニア全員で記念写真♪ 皆様、お疲れ様でした♪

アメリカ シリコンバレーで開催された　Velocity に参加してきました 　こんにちは。エンジニアの西脇（@yasuhiro1711）です。少し前ですが、毎年アメリカで行なわれているVelocityという技術カンファレンスに参加してきましたのでその報告をさせて頂きます。Velocityとは、オライリー主催のパフォーマンスに関する技術カンファレンスです。Velocityという名前の通りパフォーマンスにフォーカスした技術カンファレンスでしたが、近年はこのテーマに加えて、監視やモニタリング、サーバ運用、DevOps、SREといったキーワードが盛り込まれて、より幅広い技術を包括した技術カンファレンスとなっています。このレポートでは、日本ではまだ馴染みが薄いVelocityの魅力をお伝えしたいと思います。 　また、今回のVelocity参加に合わせて、シリコンバレーやサンフランシスコにも近いことから、現地企業を訪問や現地サービスの利用などを通じて現地のIT業界のプレーヤーを見てくる良い機会となりました。こちらの話は別記事にて書きたいと思います。 会場までの道のり 　さて、今回のVelocityは、アメリカ カリフォルニア州のサンタクララ（Santa Clara）で行われました。サンタクララはサンフランシスコの南に位置して、サウスベイのエリアにある都市です。そのため、サンタクララはもちろんシリコンバレーの1エリアとなります。一番近い空港だとサンノゼ空港、近隣ですとサンフランシスコ空港が利用しやすいです。両方の空港ともに日本から直行便が出ているのでアクセスも良いです。今回は、サンフランシスコから移動したため、サンフランシスコ市内から会場近くまではカルトレイン (Caltrain) を利用しました。サンフランシスコ市内にあるサンフランシスコ駅が始発で、サンノゼ周辺までは約1.5時間ほどかかります。会場の近くまでなら別の鉄道もありました。 　カルトレインはこんな2階立てのこんな列車でした。頑丈そうです。ローカル電車でもあるので色んな人が通勤の足として使っています。（サンフランシスコからサンノゼに行く途中治安も悪いところもあるので、途中下車の場合は気をつけたほうがいいそうです。） 　会場はこちらのホテルに併設のコンベンションセンターでした。もちろんシリコンバレーですし、会場から徒歩圏内には、Dellの研究拠点や、ファイアウォールで有名なPaloalto、Intel、Citrix、Abbottなどがありました。 　ちなみに、 Intelミュージアム も徒歩圏内（ギリギリ徒歩圏です。歩いている方はほぼいません。）にあり、エンジニアにはオススメスポットです。ムーアの法則や半導体に関する展示から、Intelオリジナルグッズまで販売されています。入場料も無料なので近くに訪れる際には是非立ち寄って頂きたいスポットです。 Velocityについて 　カンファレンスは、メインは3日間、全体では5日間のイベントです。 　チェックインは自動カウンターで受付します。事前にメールでもらっているバーコードをかざせば、プラスティックカードに印字されてネームプレートになり首から下げて参加証になります。これでチェックイン完了です。楽でした。 　カンファレンスは大きく以下のようなコンテンツに分かれています。 キーノートセッション 　大ホールにおいて、著名なエンジニアやエバンジェリスト、技術あるスタートアップによるキーノートセッションが行われます。これらは、インターネット放送で生中継されてますし、イベントが終了した現在は、Youtubeで見ることができます。キーノートには参加者も一同に集まるので、写真のように参加者でいっぱいになります。 　VelocityのProgram chairsである、John Allspaw氏、Courtney Nash氏、Steve Souders氏のトークもありました。長年Program chairsをやられている彼らは本当にすごい方だと思いました。また、来年からProgram chairsが入れ替わることも発表されました。 各種セッション 　各セミナールームにて様々な種類のセッションも行われます。これに関しては、別記事でまとめたいと思います。記事が出ましたらリンクを更新したいと思います。 Ignite Velocity 　Velocityでは、毎年Ignite talkが行われます。Ignite talkとは、20スライドを1枚15秒で、合計５分間のトーク（プレゼン）をするというルールのイベントです。Ignite talk自体、世界各国で行われているものですが、ここVelocityでも行われています。実は今回、私もここで発表しようと応募したのですが残念ながら選考で落ちました（涙）。次回機会があれば、是非発表したいと思います。また、このignite talk 面白そうなので日本でも開催したいなと思っています。東京での開催どうかと思っているので、興味ある方いらっしゃったら連絡ください。 　Ignite talkはこんな感じで行なわれました。この写真は大好きなサービスDatadogの方のトークです。私も真ん中に座っています。写真はみんな静かそうですが、トークは笑いの渦でした！！ 　今年のIgniteセッションは以下のプログラムとなります。詳細はVelocityのプログラムの こちら をご覧ください。 Brooks’s law and open source: Is community-driven software doomed? (Jason Yee) Tips for the other end of the table (Jamesha Fisher) The cloud will not save you (Jonah Horowitz) Why every developer needs to get better at Ops (Cindy Sridharan) How to not lead a team (Ulrich Dangel) One woman’s journey to becoming a software engineer (Alena Kruchkova) How to peel a banana (the right way) (Colin Bendell) How Bruce Lee made me a better software developer (David Hodge) Stop pretending you’re smarter than code (Matt Brender) How Mars made me a poet (Kate Greene) A brief history of timekeeping (Luke Francl) 　現在、このTalkのビデオは公開はされておらず、Igniteが何なのか分かりにくいかもしれませんが、 Igniteの公式サイト で世界中のイベントのトークビデオがあるので是非参考に見てみてください。 　ちなみに、2013年のVelocityでは、日本人エンジニアも発表しています。 うらやましいです！ Velocity 2013 に参加 & LT してきました！！ · takus’s blog Exhibit Hall 　Velocityでは、スポンサーを中心とした企業が出店している企業ブーススペースとなるExhibit Hallがあります。日本でもInteropや各種イベントで見かけるアレです。本イベントのテーマに類する企業が集まっており、どの企業もアピールを盛大にしていました。各企業の出店ブースの話は各サービスの話にまとまると思いますのでここではしませんが、日本にはまだ進出していない非常に興味深いサービスもいくつかありました。何社かは日本でもサービス展開を始めると話していました。また余談ですが、抽選でAmazon Echoのプレゼントをしている企業もあって真剣に、真剣に、真剣に狙いましたが貰えませんでした。実はとても欲しかったです（笑） 　もちろん「オライリー本ブース」も設けられておりました。原書になるのですべて英語書籍ですが、一部は無料で配布されていました。また、日本ではInteropなどで有料で発売していた「オライリーぬり絵」も配布されていたのはめずらしかったです。私が日本語版で関わりました 「パフォーマンス向上のためのデザイン設計」 の原書もありました。 Birds of a Feather 　ランチの時間には、Birds of a Feather というイベントが開催されています。このイベントは、ランチ時間を利用して、トークしたい技術テーマに自由に集まって、集まったメンバーでランチを食べながらそのテーマのトークしようというものです。写真にあるように、テーマごとにテーブルが区切られています。 　今回は以下のテーマがありました。自分は、「Web Performance」のところに少しの時間だけ加われ少しですが、日本の事例を話すこともできました。 DevOps Culture Web Performance Configuration Management/Infrastructure as Code ChatOps DevOps and Security Cutting-Edge Tools Container Orchestration: Swarm, Kubernetes, Mesos, Nomad HTTP/2 Site Reliability Engineering Internet of Things Diversity レセプション や オライリー本著者によるサイン会 　レセプションも毎日のように開かれました。ホテルのプールサードガーデンを利用してビュッフェやバーが提供されます。レセプションはネットワーキングにもってこいの場となります。私にはこの時間が結構有意義でした。日本人はほとんどいないですが、興味ある分野の参加者を見つけて話したりできました。純粋にチームで飲んでこの時間を楽しんでいる参加者もいたりして、良い時間でした。 　また、私にとってとてもうれしかったのが、オライリー本著者たちによるサイン会です。サイン会はイベント期間中各所で行われます。私も、Velocityのホストの一人であり、「ハイパフォーマンスWebサイト」の著者である Steve Soudersさんにサインを頂き、直接話ができましたし、最近日本でも発売している、 「マイクロサービスアーキテクチャ」 の著者もサイン会をしてたのは興奮しまくりでした。 　写真は、 「Using WebPageTest」 の著者 Rick Viscomi氏です。 全体を通じて 　かねてから参加したいと思っていたVelocityに参加してみて、改めて勉強になり、大きな情熱も貰うことが出来ました。技術内容に関するアップデートはもちろんですし、世界規模の技術イベントの真髄が見れたのも良かったです。またProgram chairsたちによる技術カンファレンスの運営も驚きの一つでした。また全体を通じて、海外のエンジニアの言動を見聞きしていると、日本人は真面目なんだなと改めて感じました。シリコンバレーでもアジア系のエンジニアが活躍していますが、その理由もなんとなく分かります。日本人エンジニアは、知らない言語環境（ここでは英語）でも堂々と振る舞える自己表現力さえ身につければ、こちらのエンジニアと渡り合えると思いました。ただしもちろん、英語は必須条件ですが。そして、Velocityのようなイベントが定期的に行なわれていることが素晴らしいと思います。ユーザにとって一番大切な指標であるパフォーマンスを、サービスに関わる全員で考える機会が定期的にあることは本当に良いことですね。 　最後になりますが、ウエディングパークでは、海外カンファレンスに積極的に参加して、自社サービスを創っていくエンジニアを熱く募集しています。興味があれば個人的にもWantedlyからでも声をかけてください。是非まずはオフィスに遊びに来てください。 IT×ブライダルで業界を変える！プロフェッショナルなWEBエンジニア募集！ ※ 本記事の写真の一部はVelocity公式Flickrより引用させて頂いております。

　こんにちは。初めまして！メディア開発本部 エンジニアの東です。2年目のサーバサイドのエンジニアで、サイトのパフォーマンスチューニングをやっています。本日はWebページのパフォーマンスを知る一つの手段である、ページの表示完了までのウォーターフォール図についてその見方を紹介したいと思います。 Webページが表示されるまで Webページは、ブラウザから表示完了までにサーバへリクエストを送り、ページを構成するための要素（CSS, javascriptファイル, 画像など）をリクエストし、場合によっては更にリクエストを送りレスポンスを待ち、それが完了して初めてページの読み込みが完了します。 リクエストを送ってから完了するまでをモニタする手軽なツールとしては、 FirebugのNet panelやChromeのDeveloper ToolのNetworkパネルが挙げられますね。 これらは、ページにて行われたリクエストとそのレスポンスを表すエントリのリストで構成されてます。 今回はFirebugのNet Panelを例に紹介したいと思います。 Firebug NetPanelを使って対象となるページをモニタすると、下図のようなウォータフォール図が表示されるかと思います。 ウォータフォールの見方 ここで画面の内容について簡単に説明していきます。 左から順に、 URL リクエストしたURL ステータス リクエストの結果（ステータスコード） ドメイン リクエスト先のドメイン サイズ リクエストした結果に対するサイズ IPアドレス 接続先のIP タイムライン リクエストがどの順序、タイミングで行われ、プロセスにどれくらいかかったかがわかります。 になります。 ちなみに、タイムラインにひかれている青い線と赤い線はそれぞれ、 青い線・・・DOMContentLoadedイベントの発火時間 赤い線・・・loadイベントの発火時間 を示しています。 そして、下部に表示されているのは、このページが読み込まれ完了するまでに全体結果になります。 それぞれ、 51件のリクエスト(図の場合) このページが完了されるまでに発生したリクエスト数 580.4 KB トータルのファイルサイズ 4.93s (onload: 3.85s) 5.99s(onload: 4.26s) 全てのリクエストが完了するまでにかかった時間が4.26秒 loadイベントがまでの時間が5.99秒 となります。 ※ DOMContentLoadedイベントは、初期のHTMLドキュメントの読み込みと解析が完了したタイミングで発火します。 しかし、Stylesheetや画像などの読み込みは除きます。※同期して取得するjavascriptはDOM解析を待たせることになります。 そして、loadイベントは、リクエストしたページのリソースとそれに属したリソースの取得が終了したタイミングで発火します。 つまり、ユーザがページをリクエストDOM解析を可能な限り速くするためには、出来る場合、非同期でJavascriptを取得するようにし、スタイルシートの読み込みを最適にするのが基本ですね。 リクエストに実際にかかった時間 下図に示すように各リクエストエントリーのタイムラインにカーソルを合わせるとどのタイミングでどれくらい時間がかかって行われたかがわかります。例だと接続に時間がかかっていますね。 Blocking(ブロッキング) リクエストが、ブラウザのネットワーク接続を待つ、キュー（待ち行列）にあった時間(SSL接続の場合、ハンドシェイクやバリデーションもここに含まれます。) DNS Lookup(DNSルックアップ) DNS解決に要した時間 Connecting(接続) TCP接続を作るのにかかった経過時間 Sending(送信) リクエストヘッダーを送っています Waiting(待機) サーバからのレスポンスを待っている Receiving(受信) サーバからのレスポンスを受け取っている より詳細な情報 さらに詳細を知りたい場合、各エントリーをクリックすればレスポンスヘッダやリクエストヘッダ、渡されたパラメータやレスポンス、Cookie情報などが確認できます。 ここで、セキュアかどうかを確認もできますし、パフォーマンス向上のために出来ることがされているかどうかも確認できます。たとえば、HTTPヘッダに Accept-Encoding:gzip をつけてリクエストを投げることで、リクエストが圧縮された状態で送られ、クライアント側で展開するのでリクエストサイズが小さくなるため、通信にかかるコストが小さくなり、パフォーマンスが向上することがあります。 最後に いかがだったでしょうか。 最近のブラウザですと、Firebug以外でも開発者用ツールがあるものがほとんどで、Firebug同様な機能をもっています。 サイトパフォーマンスはユーザがより快適にサイトを利用するために重要です。 ブラウザでのパフォーマンスチェックは直接ユーザ視点で行えますし、 何より手軽なため、まずはここから始めていきましょう！

みなさま、こんにちは！エンジニアの東です。 フロントエンドの開発は不慣れな私はCSSの扱いもまだまだ未熟です。 というのも、私は、自身の業務では、CSSはなかなか触る機会がないです。 それもあって、私はCSSには苦手意識がありまして・・・特にfloatの扱いがうまくできないんですよね・・・！floatを使ってコンテンツを配置しようとすると大体レイアウトが崩れて、混乱します。 そんな私でも、floatの代替として使える非常に便利なものがありましたのでそちらを紹介したいと思います。 それは、 CSS3 Flexbox ！ 今回、こちらについて紹介したいと思います。 CSS3 Flexbox CSS3のFlexboxとは、Flexible Box Layout Moduleとよばれ、 水平方向あるいは垂直方向に配置される要素のポジションニングを行うための方法です。 ちなみに、CSS3のFlexboxが使えるブラウザは、 http://caniuse.com/#search=flexbox にて、確認できます。 日本ではIE11が16.76%ものシェアとなっており、部分的サポートのため、バグもあるとのこと。 PCで安心して使うためにはもう少し待つ必要がありそうですね… ですが、Flexboxは非常に扱いやすいです。 弊社のディレクターは、社内勉強会にて、HTMLとCSSで簡単なサイトページを自ら作るという研修があったので、 その時に、私がサポートした方には、紹介したのですが、初心者でも、ポイントさえ押さえれば非常に使ってが良く、レイアウトが簡単にうまくできちゃいます。 CSS3 Flexbox 1 2 3 4 5 6 .list { width: 200px; } .item { height: 40px; width: 40px; border-radius: 5px; margin-right: 10px; margin-bottom: 10px; text-align: center; } .item:nth-child(1) { background:chocolate;} .item:nth-child(2) { background:tomato; } .item:nth-child(3) { background:slategray; } .item:nth-child(4) { background:pink; } .item:nth-child(5) { background:skyblue; } .item:nth-child(6) { background:limegreen; } 上記のソースでの表示は、 縦にただならんだだけになっていますが、 ここでcssをうまく指定してあげるだけで、 .list { width: 200px; display: flex; flex-direction: row; flex-wrap: wrap; } 綺麗に整列させられます。 ポイントは親要素と子要素 要素をFlexboxにするポイントは、親要素と子要素にCSSをちょちょっと設定してあげることです。 親要素は子要素がどのような配置になってほしいか、そして、子要素は、子要素自身が並びや自身の大きさ、位置がどういう具合で配置されたいかを指定してあげるだけです。 （今回はベンダープレフィックスは省いて紹介します。） 親要素 Flexboxにする大事な指定 display: flex | inline-flex 子要素がどう並ぶかを決める flex-flow: <flex-direction> || <flex-wrap> flex-direction : raw | column | raw-reverse | column-reverse flex-wrap : nowrap | wrap | wrap-reverse 配置方向の要素への指定 justy-content : flex-start | flex-end | center | space-between | space-around 配置方向とは垂直の要素への指定 align-items : flex-start | flex-end | center | baseline | stretch 子要素全体のまとまりをどういう配置にするか align-content : flex-start | flex-end | center | space-between | space-around | stretch 子要素 並び順 order: <integer> 自身の大きさ (grow: 他のアイテムとの大きさの比率、shrink: 許容縮小サイズ、basis: 基準のサイズ、) flex: <flex-grow> || <flex-shrink> || <flex-basis> flex-grow : <number> flex-shrink : <number> flex-basis : <number> 自身の配置 align-self : auto | flex-start | flex-end | center | baseline | stretch 参考(https://www.w3.org/TR/2016/CR-css-flexbox-1-20160526/) Flexboxを使えば配置が簡単！！ そして、よくあるPCサイトの作りである、 ヘッダー、フッター、左サイドメニュー、右サイドメニューの配置も、 flexboxをつかえば簡単に実現可能です！ CSS3 Flexbox Carousel header contents left side right side footer .container { display: flex; flex-flow: row wrap; font-weight: bold; text-align: center; } .header { background: chocolate; flex: 1 100%; height: 50px; } .left { height: 300px; background: pink; width: 50px; order: 1; } .main { background: slategray; order: 2; flex: 2 0px; height: 300px; } .right { width: 50px; height: 300px; background: skyblue; order: 3; } .footer { background: tomato; flex: 1 100%; order: 4; height: 30px; } 最後に いかがだったでしょうか。float使わずでも簡単にレイアウトが組めました。 親と子に対してflexのルールに沿った指定をしてあげるだけなので簡単です。 特に子の要素が増えたり減ったりするコンテンツに使えると思います！ 是非、試してみてください！ Wedding Parkでは一緒に技術のウエディングパークを創っていくエンジニアを募集しています。 興味のある方はぜひ一度気軽にオフィスに遊びにきてください。 IT×ブライダルで業界を変える！プロフェッショナルなWEBエンジニア募集！

こんにちは。Go言語が好きなエンジニアの武田(@takedajs)です。 動けるエンジニアを目指して週1のペースでジムに通ってます。筋トレは筋力アップはもちろんですが、集中力アップにも効果的なので、エンジニアのみなさんにもオススメです。 さて、本題です。 今回は弊社が行っている社内LT会の取り組みについて、お話ししたいと思います。 社内LT会について 去年の4月ごろから。毎月1回月末の定時後18時~19時に、エンジニアとデザイナー向けのLT会を開催しています。 １人につき発表7分、質疑応答3分で1回のLTにつき4~5人に発表してもらいます。 テーマは特に決めておらず、技術に関することであれば、最新技術、インフラ、デザイン、ツール、何でも良いというスタンスで行っています。 基本は社内だけで行っているのですが、数ヶ月に一度、他社との合同LT会を開催しています。 始めた理由 現在行っている社内LT会を始める前は、社内で技術的なアウトプットを行う場がありませんでした。 そのため、一緒に働いているエンジニアやデザイナーが、どんな技術に興味があるか、どんなことを行っているか、また、業界ではどんな技術が流行っているかなど、社内での情報共有があまり行われていませんでした。 僕自身、YAPC::Asia Tokyoなどの大きなカンファレンスや技術勉強会に参加して、技術の情報共有の大切さを実感していたので、技術的なアウトプットを行う取り組みを以前から社内で行いたいと思っていました。 そこで、社内LT会であれば情報共有ができ、プレゼンの練習にもなり一石二鳥だと思い始めました。 第1回目開催時の写真です。こんな感じで和気あいあいと開催してます笑 開催して良かったこと、苦労したこと これまで1年間司会と運営者として携わってきた視点での、社内LT会を開催して良かったことと苦労したことです。 良かったこと 参加ハードルの低いアウトプットする場 外部の勉強会だと知らない人ばかりで参加して発表するハードルが高いですが、社内LT会であれば顔見知りしか参加していないので、発表するハードルがかなり低くなります。 N1(弊社の新規事業創出プログラム)などエンジニアでも全社の前でプレゼン発表する機会があるので、社内LT会が良い発表練習の場になっています。 技術をインプットする良いきっかけ コンスタントに開催することで、社内LT会で発表するために何か勉強しようという良い流れができています。 ただ単にインプットする場合と違い、誰かに発表することを前提として行うため、インプットの質が高まります。 社外エンジニアとの交流の場 社内LT会の運営が慣れてきたところで、他社との合同LT会を何度か開催いたしました。 LT会が他社と交流するきっかけになり、社外のエンジニアからとても良い刺激を受けることができました。 最近行った合同LT会の様子です。もちろんピザ、寿司、お酒もしっかり用意しました笑 ウエディングパーク × CAリワード で合同LT会を開催しました 苦労したこと 社内LT会は複数メンバーで運営するべき 最近まで運営から司会まで１人で行ってきましたが、自分の業務が忙しいと運営が疎かになってしまったり、今後どういう風に運営していけばより良くなるかを考えるのに限界がありました。 今では複数のメンバーで運営することで、そういった問題も解決でき、当事者意識をもって取り組んでくれるメンバーが増えました。 司会の仕切りが大切 LT会が良いものになるかどうかは、当日の司会によって決まるということを実感してきました。 特に時間管理が重要で、発表時間や全体の終了時間がオーバーしてしまうと、全体がダレてしまい、締りがなくなってしまいます。 司会がしっかり仕切り、発表者の方には時間厳守を徹底してもらうことが大事です。 時間管理のために、社内LT会専用タイマーをArduinoで作成して利用したことがありますが、一度だけしか利用されませんでした笑 発表者が固定化してしまう 初めの頃は色んな方が発表してくれたのですが、次第に発表者が固定してきました。 僕としては任意参加で行っているので発表を強制したくはないですが、可能であれば色々な方に発表していただくのがベストです。 これに関してはまだ良い解決方法が見つかっていないため、他社の社内LT会ではどうしているか気になります。。。 最後に 社内LT会は、参加者が身近な人だけなので、発表するハードルが低く絶好のプレゼン発表の場であると同時に、良い技術の情報共有の場になっています。 業務で学んだこと、日々勉強した技術をアウトプットするのが当たり前の文化になっていけるように、継続して社内LT会をメンバーで運営していきたいと思います。 また、社内だけに限らず、外部のエンジニアの方との交流として他社との合同LT会も引き続き定期的に開催していきます。 個人として将来的に、数百人規模のテックカンファレンスをウエディングパークだけで行うということも目標に、社内のエンジニア、デザイナーのアウトプット力を高めていきたいと思います。 Wedding Parkでは一緒に技術のウエディングパークを創っていくエンジニアを募集しています。 興味のある方はぜひ一度気軽にオフィスに遊びにきてください。 IT×ブライダルで業界を変える！プロフェッショナルなWEBエンジニア募集！

こんにちは。Go言語が好きなエンジニアの武田(@takedajs)です。 最近はGo言語の外部勉強会が多く開催されて嬉しいのですが、定員オーバーで参加できないことが多いですね。前に行われたGoカンファレンス参加したかったです・・・ さて、本題です。 今回は普段僕が行っているポモドーロテクニックについてと、それに利用するポモドーロタイマーを作成しましたのでお話します。 ポモドーロテクニックとは 25分の集中した時間を1ポモドーロとし、1ポモドーロが終わるたびに5分の休憩します。 そして、4ポモドーロが終わったら、15分程度の休憩を入れるというのを繰り返して行う作業効率アップのテクニックです。 今、このブログもポモドーロ・テクニックを利用して書いています。 海外のエンジニアから人気の洋書で、最近日本語訳が発売されたエンジニアのライフハック本でも取り上げられていました。実際に試して効果を実感している方も多いと思います。 実際に行ってみて 僕自身、大学の頃からこのテクニックを利用しています。 長時間作業して気が向いたら休憩するのとは違い、25分作業して強制的に休憩することで、高い集中力を保って作業ができます。 また、25分という制限を1日何度も行うことで、この25分中には〜を終わらせる！という締め切り効果も生まれます。 ポモドーロテクニックを行うと細かい休憩を多く挟むので、実践している人の中では、休憩時間に何をするか？という悩みがあると思います。 僕はポモドーロ間の5分休憩を以下のように過ごしています。 【5分休憩】 席を立ち歩く お茶をいれに行く お菓子を食べる トイレに行く 上司に報連相する また、15分休憩のタイミングで、気分を変えるために作業する場所を変えています。 エンジニアは1日中社内にいるので、同じ場所にずっとは辛いですよね。 スタンディングデスク (景色が良いです。スタンディングで作業すれば更に集中できます。) ソファー (リラックスして作業できます。) テラス (まだ一度もここでは作業したことがありません笑) ポモドーロタイマー 普通のタイマーアプリでもポモドーロテクニックを行うことができます。 ただ、専用タイマー(25分と5分を交互に自動で計ってくれる)を用意した方がよりスムーズに作業が行えます。 そこで、弊社が利用しているhipchatとGo言語を利用してシンプルなポモドーロタイマーを実装しました。ターミナル上で動作します。 タイマーの使い方 1: hipchatにポモドーロ専用のルームを作成します。 2: ターミナル上で以下のオプション付きのコマンドを叩きタイマーを実行します。 go run main.go -t 【hipchatのAPI Auth Token】 -r 【作成したルーム名】 -u 【メッセージの宛名】 3: タイマーが実行されると、作業開始や休憩開始を選択したルームに通知します。 4: タイマー起動中は、ターミナル上で指定のキーを入力するとポモドーロのリスタートと終了を行います。 [r] リスタート [f] 終了(スタートから終了までの達成したポモドーロの回数を通知します。) デモ デモのため一時的に設定を変更して、ポップアップ通知が来る間隔を早くしています。 (画像をクリックして拡大表示すると見やすいです。) hipchatを見ていなくてもポップアップ通知が来るので、休憩するタイミングなどが分かります。 作業が乗ってきたときは、休憩の通知を無視することが多々ありますが・・・笑 実装コード package main import ( "flag" "fmt" "log" "time" "github.com/andybons/hipchat" "github.com/tlorens/go-ibgetkey" ) var pom_time int var token *string var room_name *string var user_name *string func main() { token = flag.String("t", "", "hipchat access token") room_name = flag.String("r", "", "send message room name") user_name = flag.String("u", "", "send message user name") flag.Parse() kill := make(chan bool) finished := make(chan bool) restart__key := "r" t := int(restart__key[0]) finish_key := "f" f := int(finish_key[0]) go pomTimerGoroutine(kill, finished) loop: for { input := keyboard.ReadKey() select { case まとめ ポモドーロ・テクニックはタイマー1つで行える作業効率アップテクニックです。 簡単に行えますが、実際に試してみるとその効果の大きさを実感できると思いますので、是非試してみてください。 引き続き、社内でも作業効率アップのナレッジを共有し合い、生産性を上げていきたいと思います。 自分がやって効果があった作業効率アップの仕組みを発表し合う社内LT会を開催するのも良いかもしれませんね。 Wedding Parkでは一緒に技術のウエディングパークを創っていくエンジニアを募集しています。 興味のある方はぜひ一度気軽にオフィスに遊びにきてください。 IT×ブライダルで業界を変える！プロフェッショナルなWEBエンジニア募集！

こんにちは、サーバサイドエンジニアの榎本です。 IBM が OSS として開発している Swift の Kitura を触ってみました Vagrant で Kitura を起動する Kitura の README の手順通りにインストールします ※ 私は Vagrant を使用しますが、Docker でもインストールできるようです まずは、 git clone しましょう $ git clone git@github.com:IBM-Swift/Kitura.git 次に、 vagrant up で Vagrant を起動します $ cd Kitura $ vagrant up ホスト側の /path/to/Kitura と VM 側の /vagrant は共有されているので、VM 側でプロジェクトを作成するときは、 /vagrant 配下であればホスト側でもファイルを編集できるので、 /vagrant 配下にプロジェクトを作成していきたいと思います VM 側でプロジェクトを作成するので、 vagrant ssh します $ vagrant ssh ここから先は VM 上での作業になります $ cd /vagrant $ mkdir TestApp $ cd TestApp Swift の新規プロジェクトとして初期化します $ swift build --init Creating executable package: TestApp Creating Package.swift Creating .gitignore Creating Sources/ Creating Sources/main.swift Creating Tests/ ディレクトリ内はこんな感じになっています TestApp ├── Package.swift ├── Sources │   └── main.swift └── Tests Package.swift に Kitura を追記します Package.swift import PackageDescription let package = Package( name: "TestApp", dependencies: [ .Package(url: "https://github.com/IBM-Swift/Kitura.git", majorVersion: 0, minor: 17) ]) Sources/main.swift にはルーティングの設定と、サーバの起動設定を記述します Sources/main.swift import Kitura let router = Router() router.get("/") { request, response, next in response.send("Hello, World!") next() } Kitura.addHTTPServer(onPort: 8090, with: router) Kitura.run() ファイルの編集が終わったら、コンパイルしていきます $ swift build -Xcc -fblocks ...（略） Linking CHttpParser Compile Swift Module 'KituraSys' (3 sources) Compile Swift Module 'KituraNet' (12 sources) Compile Swift Module 'Kitura' (30 sources) Compile Swift Module 'TestApp' (1 sources) Linking .build/debug/TestApp それでは、実行してみます $ .build/debug/TestApp 特に何もレスポンスはありませんが、起動できているようなので、ブラウザで確認してみます 無事、ブラウザでも確認できました！ まとめ まだまだ機能があまりない Kitura ですが日々めまぐるしくアップデートされているので、これからに期待大です。 Wedding Parkでは一緒に技術のウエディングパークを創っていくエンジニアを募集しています。 IT×ブライダルで業界を変える！プロフェッショナルなWEBエンジニア募集！

こんにちは、エンジニアの西脇です。先日ウエディングパークで行われた合同LT会についての報告を致します。今回は合同で、CAリワード（CA Reward）さんとLT会を実施しました。賑やかで内容盛りだくさんな会となりました。お酒を飲みながら、ピザを食べながらの楽しい会でもありました。 発表内容 以下敬称略です。 1, 「サービス紹介 + Monitで小回りの効く監視作り」 　　　　　　　　 WeddingPark 西脇 2, 「プロダクト全体説明」 　　　　　　　　 CAリワード 山本 3, 「言語の検証と導入」 　　　　　　　　 WeddingPark 武田 4, 「GCPを利用したデータ分析プラットフォームについて」 　　　　　　　　 CAリワード 阿部 5, 「Sentryを利用したエラー集約プラットフォーム」 　　　　　　　　 WeddingPark 榎本 6, 「CA Reward x Go言語」 　　　　　　　　 CAリワード 山塚 7, 「AI Lab の取り組みについて」 　　　　　　　　 サイバーエージェント　アドテク本部 馬場 こやって眺めるだけでも、盛りだくさんです！CAリワード、アドテクスタジオ側の発表内容についてはCAリワード 公式エンジニアブログに掲載しているのでそちらをご覧ください。最後のリンクを参照ください。本記事では、WeddingPark側の発表を中心にお届けします。 1, 「サービス紹介 + Monitで小回りの効く監視作り」 WeddingPark 西脇 私の方から、Monitを使ってみた件を共有させていただきました。Monitのキャラがリアルすぎてキツいというリアルな意見も寄せられました。 2, 「プロダクト全体説明」　 CAリワード 山本 山本本部長からは、CAリワードのプロダクトを紹介頂きました。プロダクト名を、「BOSATU」や「MYOUO」など仏の名前で統一している仏シリーズの話は興味深かったです。 　　 3, 「言語の検証と導入」　 WeddingPark 武田 言語を比較検証してみた結果についてです。性能の違いがどこで出るのかが良くわかりました。 4, 「GCPを利用したデータ分析プラットフォームについて」 CAリワード 阿部 GCPを各プロダクトと組み合わせて利用しているという発表でした。GCPはAWSよりも使いやすいという意見も上がりましたね。何よりも阿部さんの研究内容に驚かされました！ 　 発表資料は CAリワード Techブログ にございます。 　 5, 「Sentryを利用したエラー集約プラットフォーム」 WeddingPark 榎本 様々な種類のエラーを検知できるSentryの事例紹介です。これの導入によりエンジニアの品質意識が大きく変わりました。それが一番嬉しいことですね！！ 6, 「CA Reward x Go言語」 CAリワード 山塚 Go言語の取り組みはエンジニア一同熱心に聞き入っていました。やはり使える言語だということを再認識できましたし、なんたって、Gopherくんがかわいいのなんの！ 発表資料は CAリワード Techブログ にございます。 　　 「AI Lab の取り組みについて」 サイバーエージェント　アドテク本部 馬場 最後は馬場さんによるAI Labの取り組みについてです。AI Labに至るまでのお話をして頂き刺激をもらいました。 　　 LT会風景 会場では、ピザとドリンクで終始ワイワイと楽しくLT会を進めることができました。 みんなで乾杯♪ LT会の夜にオフィスから見えた東京の夜景 まとめ 盛んに質問や交流を進められた良い会となりました。 最後に記念写真を。ウエパメンバーはCAリワードさんのRサインを、CAリワードさんはウエパのWサインで記念写真を撮りました。皆様お疲れ様でした！ ウエディングパークでは、LT会でワイワイ盛り上がりたいエンジニアを募集しております。 詳細は こちら まで。 CAリワード 公式エンジニアブログ 本イベントは、CAリワード公式エンジニアブログでも取り上げています。ぜひご覧ください！ CAリワード Techブログ

はじめてのエントリーとなります。システム部門統括の西です。 今回はエンジニアとクリエイターによる社内制度創出コンテストである『せどつく』を実施し、そこから生まれた新しい制度をご紹介します。 「Let’s 5 out!(レッツゴーアウト)」 「Let’s 5 out!」という制度名には、技術力向上のためのインプットや勉強会などの社外活動である、「out(=外部)」の活動を、費用面(「go(=5)」)で支援し、具体的には、勉強会の参加費用を上限5千円まで、該当資格の合格で5万円が支給されるなど、技術力向上のための動きを支援いたします。 （ プレスリリース より抜粋） 目的としては技術部門の1人1人のレベルの向上を促進する為の制度ですが、開発メンバーにとって自社サービスの開発というのはどうしても社内で完結しがちな環境ですので、出来るだけ外部の高いレベルに接したり自発的に普段使っていない技術領域にもチャレンジして欲しいという考えから制度として取り入れました。 またあわせて社内でクリエーターが切磋琢磨出来る環境作りの一環として、 「C1選手権」 の開催準備に入りました。 これはコンテスト形式でバナーなどのクリエイティブで一定期間ABテストを実施し、効果が一番高かったクリエーターが優勝という取り組みです。自らエントリーして皆が注目する中で楽しく競い合える様な形にしたいと考えていますので、また開催後にここでご報告出来ればと思います。 そして最後に 技術者の海外カンファレンス派遣 も積極的に行う事にしました。 これは適宜必要に応じて最新の情報を取得しに行く事で、ウエディング業界のITプレイヤーとして常にトップランナーでいられるようにという思いと、こういった取り組みが当たり前の状態にしたかったというのがあります。 最初の派遣先としては早速来月にVelocity 2016へインフラチームのリーダーに行ってもらう事にしています。 いよいよ「技術のウエディングパークを創る」という大きな目標に向かって、制度を新設したり、より具体的な取り組みを始めましたのでご興味ある方は是非ご連絡下さい。

こんにちは。エンジニアの西脇です。 桜の開花宣言がされましたが、花粉症の人も辛そうにし始めました。 これから長い戦いが始まりそうです。 さて、本日は3/17に弊社で行われました CyberZ さんとの合同LT会の様子をお届けします。2社で計4本のLT発表でした。とても盛り上がった会になりましたよー 内容 以下敬称略です。 「おすすめしたいScala」CyberZ 鈴木 「Data Visualizationしてみた」 WeddingPark 東 「JavaScriptは闇の深いアセンブラなのか」CyberZ 重村 「ひよっこエンジニア奮闘記」 WeddingPark 成田 CyberZさん側の発表内容については最後にリンクがございます。 ではウエディングパーク側の発表内容です。 2. 「Data Visualizationしてみた」 東 d3.jsを使ってデータ表示をしてみています。意外とDOMの操作部分が面倒だという意見も。c3.jsもいいよなんて盛り上がりました。 4. 「ひよっこエンジニア奮闘記」 成田 「あー、わかるー」とか、「phpだからこれはできないんだよね！」などみんなで奮闘記について語り合いました〜。みんなツマヅキを乗り越えてきたんですよね！ CyberZさん側の発表内容 「おすすめしたいScala」CyberZ 鈴木 「JavaScriptは闇の深いアセンブラなのか」CyberZ 重村 こちらの資料については、CyberZさんの技術ブログ「 CyberZ公式エンジニアブログ 」の記事をご覧ください。 まとめ CyberZさんとの合同LT会をしてみて、エンジニア同士でガヤガヤ話をして、大いに刺激になりました。これからも他社との勉強会LT会をどんどんやっていきたくなりました！　一緒にやりましょうという会社様ぜひお声がけを！ 記念写真♪