はじめに 印象に残ったセッション U30エンジニアとしての技術的投資戦略 Androidからサーバーサイドまで！プログラミング言語 Kotlinの魅力 ID連携を用いたサービス間連携とQR決済サービスPayPay 大規模プロジェクトの制作裏話〜改善から成し遂げるまでのプロセス〜 課外活動で勉強会を主催していたら会社の事業になった話 おわりに はじめに こんにちは、 @rs_tukki です。 先日、30歳以下エンジニアのための技術カンファレンス「Developers Boost」に参加してきました。 event.shoeisha.jp 登壇者も参加者もU30限定という中で、業務改善を行った話、最新技術の紹介をする話、エンジニアとしての生き方を考える話など興味深いセッションが多く、あまり知識のない私でも最後まで楽しむことが出来ました。(そういう人を狙ったセッションが多かったのかも…？) というわけで、今回は参加報告も兼ねて印象に残ったセッションを簡単にまとめていこうと思います。 印象に残ったセッション U30エンジニアとしての技術的投資戦略 ペッパーのプログラムを組み人間との 漫才コンビ で M-1 に出場したという異色の経歴を持つ安野 貴博さんのセッションです。 30歳以下の若手エンジニアとして、私たちにはどのような武器があるのか、そしてどのように生きていくべきか、という最初からとても考えさせられるセッションでした。 若手エンジニアの武器は2つ。 リスクを取りやすい 時間的リソースを投入しやすい そのため、成長している領域に対して勉強を重ね、勝負していける。失敗してもやり直しがきく。 そして、その「成長している領域」が何かを知るために、未来を予測し、備え、出てきた選択肢を 定量 比較した上でベットしていく… エンジニアは常に勉強しなければ生き残れないとはよく言いますが、ただ闇雲に進むのではなく、どんな未来に賭けるかを意識しよう、という話自体が非常に勉強になりました。 Android からサーバーサイドまで！ プログラミング言語 Kotlinの魅力 日本Kotlinユーザグループの代表を務められている、 長澤 太郎さん のセッションです。 こちらは、スライドが公開されていました。 speakerdeck.com Android の開発の現場でKotlinという言語はよく聞きますが、発表が2011年、安定版は2016年のリリースということで、想像以上に最近出てきたばかりの言語なんだと実感しました。 Java と同じ静的型付け オブジェクト指向言語 で、 Java との相互運用性がありながら、 Java より記述が容易だったり、 演算子 を オーバーロード 出来たりと、かなり便利に扱えるなと感じました。(感覚的には C# に近いかも？ とも思いました) あとWebアプリケーションにも使えるのがちょっと意外でした。 ID連携を用いたサービス間連携と QR 決済サービスPayPay こちらもスライド公開済み。 ヤフーの本間 洋光さんによる、今話題のPayPayの仕組みに関するセッションです。 ID連携を用いたサービス間連携と QR決済サービスPayPay #devBoostA from Yahoo!デベロッパーネットワーク www.slideshare.net 丁度他の勉強会でOAuthについて学ぶ機会があったのですが、その時はまだ完全に理解しきれていないところがありました。 今回のセッションではPayPayのシステムを例に、(OAuthを拡張した)OpenIDConnectという仕様を使った連携フローについて説明 いただいたので、より理解が進んだ気がします。 ちなみにヤフーには連携のためのIDに関わる開発専門の部隊が存在するそうです。流石... 大規模プロジェクトの制作裏話〜改善から成し遂げるまでのプロセス〜 ディライトワークス株式会社の畠山 彰秀さんのセッションです。 大規模な開発プロジェクトの中で、他の人のサポートという「見えないタスク」への対処でスケジュールが押されないよう、画面仕様や導入資料などの様々なドキュメントを作成していった、という話でした。 弊社でも私たち若手メンバーを交えて既存の資料を改善していく努力はしていますが、 「大事なのは誰かを待つのではなく、まずやってみること」 という言葉が胸に刺さりました。 今後新たなメンバーが アサイ ンしてきたときにドキュメントが整備されているか否以下の差は大きいので、気づいたらやる、という点は徹底していきたいです。 課外活動で勉強会を主催していたら会社の事業になった話 IoTLT という勉強会の主催である 菅原 のびすけ さんのセッションです。 主催していた勉強会のモチベーションが下がっていたところに社長を呼んでみたら、とんとん拍子で事業化まで事が運んでしまった… という話でしたが、何より 「モチベーションがなくても続ければ価値になる」 という言葉が響きました。 ひたすらアウトプットを続けていくことで、いずれそれに価値を見出せることができるということで、来年からは積極的にブログなどの技術発信を続けていこうと感じました。 おわりに 通常のカンファレンスや勉強会では、登壇者も年上の方が多いのですが、今回はU30という関係上、非常に近い立場の方の話を聴くことが出来ました。(私と同い年で登壇されている方も！) 社内に限らず、こういった社外での勉強会や交流の場で学べることはとても多いので、皆さんもぜひ参加してみてはいかがでしょうか？ #devboost 懇親会も含め、Developers Boostすべて終了しました！ ご来場いただいた皆さま、ありがとうございました！！！ pic.twitter.com/navawUkBjZ — Developers Boost（デブスト）12/11オンライン開催｜参加登録の受付開始！ (@developersboost) 2018年12月15日

id:radiocat です。今回はモブプログラミング Advent Calendar 2018の12日目の記事として投稿させて頂きます。久々の スクラム 事例です。 qiita.com 私達のチームでは スクラム 開発の中で毎週モブプログラミング（以下モブプロ）をする時間を設けています。その名も「ボーナスステージ・モブプロ」です。 実践に至る経緯 まずは現在のモブプロのスタイルを実践するに至った経緯をご紹介します。 チームの知識共有 我々が開発を担当している楽楽精算はチームで開発を進めていくうえで以下の2点が課題となります。 経理 業務の知識 レガシーかつ 経理 業務に合わせた独特なシステム設計 例えば、今年リリースした iPhoneアプリ は精算時に使う領収書を撮影して保存することができますが、領収書を電子化して保存する 経理 業務の背後には「 電子帳簿保存法 」という法律があります。操作性や アーキテクチャ の側面だけでなくお客様の 経理 業務への効果や影響も意識してシステムを実現する必要があるためチームの知識共有がとても重要になります。 メンバーの半分がチームにJOINして1年未満 体制の変更もあって経験と立場がそれぞれ違うメンバー構成となり、それまでのように知識豊富な一部のメンバーがリードして進めるスタイルの限界を感じていました。 スプリントにモブプロを取り入れてふりかえりで改善 モブプロには以前から実験的に取り組んでいましたが、これらの課題が明確になってきてからは思い切ってスプリントの一部に組み込むようになりました。はじめはスプリント計画時にモブプロでやったほうが良い開発タスクを決めてモブプロの時間を設けていました。しかし、モブプロのために全員のスケジュールが合う時間を調整しなければならずスプリントを進めるうえでの負担になってしまいました。ふりかえりでこのような課題を議論した結果、スプリントで計画するのではなくスプリントが終わってからモブプロするほうが取り組みやすいという結論になりました。 スプリント最終日の午後はモブプロタイム！ 1週間スプリントの木曜は朝からスプリントレビューなので前日の水曜日は15時に開発が完了することを目標に計画していました。計画通りに終わればそれ以降は直前に開発した機能のPOレビューや翌日のスプリントレビューの準備、次のスプリントの準備の時間に充てます。計画より早く終われば改善などにも取り組むことができるので、この時間をボーナスステージと呼んでいます。モブプロに取り組むようになって試行錯誤の結果、このスケジュールをさらに繰り上げて開発完了目標を水曜午前中までとして、モブプロをボーナスステージに組み込むことにしました。 実装やコードレビューの中で「ここがわからない」「ここの知識が共有できていない」と気づいた部分は「今週のモブプロのお題にしよう！」と決めてリストアップしておき、ボーナスステージでテストコードを強化したり リファクタリング したりしながらモブプロするようにしています。 スプリント中にモブプロすることを禁止しているわけではないですが、開発中はスプリントの完了を優先させて取り組み、ボーナスステージに突入してから落ち着いてモブプロに取り組むスタイルが定着しています。チームで決めた トレードオフ スライダーの最上位が「納期」であることもこのスタイルが定着する要因のひとつと言えるかもしれません。 実践のポイント モブプロを実践する中でチームで合意している取り決めがいくつかあります。 モブプロはあくまでボーナス 開発中にトラブルが起きて計画どおりに進められなかった場合、ボーナスステージは無くなります。その時は無理にモブプロをすることはしません。チームの最優先は「納期」なのでまた次のスプリントで頑張ってボーナスステージに突入できるように改善していくだけです。 知識の共有をメインにする 我々のチームのモブプロの目的は今のところ知識の共有なので、それ以外の目的でモブプロすることはしません。ボーナスステージに突入しても特に共有が必要なテーマがなければ無理にモブプロはしていません。逆に知識の共有が必要なことであればプログラミングに限らずモブの時間を取るようにしています。最近ではコードレビューふりかえりと呼んで、プログラミングの観点だけに絞ったふりかえりの時間を設けてより良いコードの書き方やコードレビュー観点などを議論する時間を取ってみたりもしています。 環境の共 通化 我々のチームでは各自のノートPCを持ち寄ってモブプロしていますが、モブプロあるあるの課題としてドライバーを交代した時に他人の設定している環境が使いづらいという問題があります。そのため、チームで話し合ってモブプロのときに使用する最低限の IDE の設定などをいくつか決めています。個人で開発している時に設定を変えるのは自由ですが、モブプロの時にはみんな同じ設定で作業します。人によっては普段より効率が落ちるケースがあるかもしれませんが、事前にチームで話し合って決めたルールなのでモブプロの時は合わせてもらいます。事前に決めておくことで、モブプロの時に突然設定が変わって戸惑うことも少ないですし、事前に設定して慣れておくこともできます。 メリット このようなモブプロの実践についてメリットを考えてみました。 生産性の話をしなくていい モブプロを実践するうえで最も議論になるのが生産性の話です。1つのプログラムをチーム全員でプログラミングするのは効率が悪いのではないか？というヤツです。 しかし我々のやり方の場合、スプリントの開発は既に終わっています。やるべき事をやったので、もっと良くするために知識を共有する目的でモブプロをやっているだけなので少なくとも開発チーム内で生産性の議論をする必要がありません。生産性の議論をしなくて良いのはモブプロを実践するうえで非常に取り組みやすい状況です。 安心して開発に集中できる 「知識の共有」と言うのは簡単ですが、知らない事を知るという意味では言うほど簡単な事ではありません。1週間という短いスプリントの中でメンバー間の知識差に気づいた時には、時間的にも精神的にもそれほど猶予はない状態なので、「じゃあちょっとモブプロでもしようか」とはならないのです。「ここはひとまずこのまま進めておいて、あとでみんなでモブプロしながら リファクタリング しよう」と言えるのはチームにとって非常に強力な手段となります。 ボーナスステージへのモチベーションが上がる なんだかんだ言ってみんなで集まってワイガヤしながらプログラミングするのは楽しいです。1週間のスプリントを無事に終えてリラックスしながら、成果物をさらに良くしていくというのはスプリントを早く終わらせてモブプロしようというモチベーションにも繋がります。 デメリット モブプロ自体のデメリットではありませんが、ボーナスステージで実践することにはいくつかリスクがあります。意識して取り組めば回避可能なので紹介しておきます。 デグレード のリスクがある スプリントの最後にモブプロで リファクタリング するということは完成したものに手を加えるということなので デグレード を起こすリスクがあります。翌日は朝からスプリントレビューなので、完成したはずの機能が万が一動かなくなっていたらスプリントでやってきたことが全て水の泡です。そこまで大事には至らなかったものの、実際に我々も デグレード を起こしてしまったことがあります。そのため我々はモブプロを行ったあとに一通りの機能を再度テストをして終わるようにしています。 予定が立てにくい ボーナスステージというのはうまくいけば訪れるものなので、事前に計画することができません。モブプロしようと思ったら全員が集まれる場所が確保できなかったということも起こりえます。デイリー スクラム で日々の状況をうかがいながら先回りして予定を確保する必要があります。 もっとできるのにがんばらないリスク スプリント終わりにモブプロをするのを「ありき」にしてしまうと、その分の余裕をみて計画を立ててしまいます。しかしそれではチームのパフォーマンスは上がっていきません。あくまでスプリントで出来ることを出来るだけこなしたうえで、余裕があればモブプロを実行するのが理想です。POやステークホルダがもっとたくさん作って欲しいと思っているのに開発チームがスプリントを早めに切り上げてモブプロしているような状態になってしまうとモブプロの意義も疑われてしまいます。これは スクラム マスターがしっかり状況を判断してコン トロール しなければなりません。 まとめ 我々のチームでは知識の共有を目的としてモブプロを実践することでチーム力を強化してきました。最近ではスプリント計画時にもこれからモブプロをするかのように、みんなでプログラムを見ながら「ここをこうするんだ」と議論して計画を立てるようになりました。新たに若手のメンバーも迎え入れてチームを強化している最中で、学習をテーマにしたモブプロも実践してみたいと話をしています。 このように我々はチームを前進させるために目的を決めてモブプロを取り入れています。モブプロには他にも様々な効果があると思いますが、目的を絞って取り組んでみると改善点も明確になるのでチームに定着させやすいと感じています。 お知らせ 楽楽精算開発チームでは1年前から スクラム 開発を取り入れて実践してきました。これらの取り組みを2月に行われる Scrum Fest Osaka 2019 ご紹介できればと思い応募していますので、よろしければ投票お願いします。 https://confengine.com/scrum-fest-osaka-2019/proposal/8554/- confengine.com

sts -250rrです。 今回は ラクス Advent Calendar 2018 に投稿した記事、「 開発環境を作るためにDockerを使った話 」の続きになります。 qiita.com はじめに Dockerネットワークを作成してコンテナ間通信 開発環境（Go）・PostgreSQLコンテナの起動 docker-compose.yml Dockerfile 1_createdb.sql main.go 今回のポイント Goのパッケージインポート PostgreSQLコンテナで初期DB構築を行う 実は・・・ まとめ はじめに 前回の記事 ではDockerで開発環境を作ってみました。 が、このままではあまりにもチープな構成に感じます。。。 今回は コンテナ間通信 を使って別コンテナに作成したDBのデータを取得できるような構成を作っていくことを目標とします。 目標とする形は以下のようなイメージです。 Dockerネットワークを作成してコンテナ間通信 コンテナ間通信を実現するために、Dockerネットワークを作成します。 Dockerネットワークはコンテナ名を指定することでアプリ用（開発環境用）のコンテナからDBコンテナに接続することができるようになります。 まずはDockerネットワークを作っていきます。 $ docker network create my-network cbe89848f313a1b7766780903f79da2ff3a83bbe962f930c1f3caf9136fbac6f $ docker network ls NETWORK ID NAME DRIVER SCOPE 39d283374d44 bridge bridge local a3d0faef3da4 host host local cbe89848f313 my-network bridge local 7b1a7347c6b9 none null local 以下のコマンドでDockerネットワークの詳細を確認することができます。 $ docker network inspect my-network [ { "Name": "my-network", "Id": "cbe89848f313a1b7766780903f79da2ff3a83bbe962f930c1f3caf9136fbac6f", "Created": "2018-12-09T02:41:41.8124636Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.21.0.0/16", "Gateway": "172.21.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": {}, "Options": {}, "Labels": {} } ] 作成したてのDockerネットワークなので何も登録されておらず、Containers部分が空っぽです。 コンテナ起動時にこのDockerネットワークを指定することで、同一のネットワークにコンテナが作成されるため、コンテナ間通信ができるようになります。 ※細かい部分は詰められていません。 開発環境（Go）・ PostgreSQL コンテナの起動 コンテナを起動して、開発環境コンテナのGoプログラムから PostgreSQL コンテナのDBに接続出来るような環境構築を行なっていきます。 今回もdocker-composeを利用していくので ディレクト リ構成・ファイルを以下のように作成します。 <任意のディレクトリ> |-- init | |-- 1_createdb.sql |-- Dockerfile |-- docker-compose.yml |-- main.go 今回、 main.go から PostgreSQL コンテナのDBに接続するために各設定ファイルやDBの初期構築が必要になります。 各ファイルは以下のように作成します。 docker-compose.yml version: '3' services: postgres: image: postgres environment: POSTGRES_USER: postgres # user POSTGRES_PASSWORD: postgres # pass ports: - "5432:5432" volumes: - ./db:/docker-entrypoint-initdb.d networks: - my-network app: build: . ports: - "8080:8080" networks: - my-network volumes: test_db: external: false networks: my-network: external: true Dockerfile #ベースのDockerイメージをgolangで指定 FROM golang:latest EXPOSE 5000 #ワークディレクトリを設定する WORKDIR /go #ホストのディレクトリを/go配下にコピー ADD . /go #GOPATHの設定 ENV GOPATH $GOPATH:$HOME/go RUN go get github.com/jinzhu/gorm RUN go get github.com/lib/pq #main.goを実行 CMD ["go", "run", "main.go"] 1_createdb. sql create database testdb; main.go main.goはこちらを参考にさせていただきました。 実行するとDBに登録されているIDと名前を出力します。 https://qiita.com/rky_1011/items/9772d92b5fe8cb3b82b0 qiita.com package main import ( "fmt" "github.com/jinzhu/gorm" _ "github.com/lib/pq" ) type User struct { ID int64 `gorm:"primary_key" json:"id"` Name string `json:"name"` } type Users []User func main() { db, err := gorm.Open("postgres", "host=172.24.0.3 user=postgres port=5432 password=postgres dbname=testdb sslmode=disable") if err != nil { panic(err) } defer db.Close() db.AutoMigrate(User{}) var user = User{Name: "testname"} db.NewRecord(user) db.Create(&user) db.Save(&user) var users = Users{} db.Find(&users) fmt.Println(users) } さて、ファイルが揃ったら、 docker-compose build 、 docker-compose up を実行すれば、 main.go の実行結果が得られます。 (略) postgres_1 | 2018-12-09 06:32:23.787 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" postgres_1 | 2018-12-09 06:32:23.829 UTC [58] LOG: database system was shut down at 2018-12-09 06:32:23 UTC postgres_1 | 2018-12-09 06:32:23.851 UTC [1] LOG: database system is ready to accept connections app_1 | [{1 testname}] app_app_1 exited with code 0 postgres_1 | や app_1 | といった形でコンテナごとの出力結果が得られています。 app_1 | [{1 testname}] と出力されているのでなんだかいけてそうな気がします。 これだけではピンとこないので PostgreSQL コンテナに入ってDBを確認してみると、 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f9a9ed9b3fc8 postgres "docker-entrypoint.s…" 2 minutes ago Up 2 minutes 0.0.0.0:5432->5432/tcp app_postgres_1 $ docker exec -it app_postgres_1 bash root@f9a9ed9b3fc8:/# psql -U postgres testdb psql (11.1 (Debian 11.1-1.pgdg90+1)) Type "help" for help. testdb=# select * from users; id | name ----+---------- 1 | testname (1 rows) PostgreSQL コンテナの内容と開発環境コンテナのmain.go実行時の内容が一致するので正しく値を取得できているようです。 最後にDockerネットワークの状態を確認します。 docker network inspect my-network [ { "Name": "my-network", "Id": "e77a834d8aff49e316e7ab153666232eab35f7fe4350b18be19da1d608125c4b", "Created": "2018-12-09T06:25:02.1986525Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.24.0.0/16", "Gateway": "172.24.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "f9a9ed9b3fc8b67232edb76ec4202e0b66ec776dbd0665db7f9ee11341088571": { "Name": "app_postgres_1", "EndpointID": "6dfd276d55c4352668364de97a588ca5072bf5ee647b8b9dbe5cbdc04d8603f1", "MacAddress": "02:42:ac:18:00:03", "IPv4Address": "172.24.0.3/16", "IPv6Address": "" } }, "Options": {}, "Labels": {} } ] Go側のコンテナは実行完了と同時に停止してしまうので、 Containers には表示されていませんが、Postgresコンテナが my-network 内に含まれていることがわかります。 色々複雑でしたが、コンテナ間通信ができる開発環境、無事完成です。 今回のポイント Goのパッケージインポート ローカルでGoを書く時にも必要なことですが、軽く詰まりました。 main.goの中で Github からパッケージをインポートしていますが、事前にGOPATHを設定したり、go getでGitリモー トリポジ トリをダウンロードしておかなければならなかったようです。 Dockerコンテナでもこれは同様なのでDockerfile上でENVやRUNで必要な事前処理を行っていますが、詰まったのはRUNでgo getを実行する部分です。 はじめはCMDで実行していましたが、main.go実行時にこうなります。 app_1 | main.go:6:4: cannot find package "github.com/jinzhu/gorm" in any of: app_1 | /usr/local/go/src/github.com/jinzhu/gorm (from $GOROOT) app_1 | /go/src/github.com/jinzhu/gorm (from $GOPATH) app_1 | /go/src/src/github.com/jinzhu/gorm app_1 | main.go:7:4: cannot find package "github.com/lib/pq" in any of: app_1 | /usr/local/go/src/github.com/lib/pq (from $GOROOT) app_1 | /go/src/github.com/lib/pq (from $GOPATH) app_1 | /go/src/src/github.com/lib/pq app_app_1 exited with code 1 パッケージ見つからないよ。という旨のエラーですね。 調べてみたらRUNとCMDでこんな違いがありました。 qiita.com 深くまで追えていませんがイメージ作成時に実行しておかないとmain.goの実行時にはDLが完了できないとかなんでしょうか？ PostgreSQL コンテナで初期DB構築を行う PostgreSQL コンテナをただ作るのみではもちろんDBの作成はしていないので、接続に失敗します。かといって毎回コンテナを起動するたびに手動で作成するのはDockerの利点を潰してしまっていますよね。 そんなことをしなくて良いようにDockerhubの公式のイメージには便利機能がありました。 If you would like to do additional initialization in an image derived from this one, add one or more . sql , . sql .gz, or *.sh scripts under /docker-entrypoint-initdb.d (creating the directory if necessary). /docker-entrypoint-initdb.d という ディレクト リに .sql や .sh のファイルを配置しておけば起動時に実行してくれるみたいです。 ということで、 docker-compose.yml の volumes: で init 以下の 1_createdb.sql を docker-entrypoint-initdb.d に配置し、 createdb を実行していました。 実は・・・ 必要なファイルが揃えば、さも簡単に実行できるかのように書いていますが、1度目の実行は ほぼ必ず 失敗します。 というのも1度目の実行ではDockerネットワーク上の PostgreSQL コンテナに割り振られるIPがわからないためです。。。 main.goの中で接続先のDBのあるIPを指定しているので、その部分でコケます。 多分何かしらいい方法があるんだと思いますが、現時点では見つからず。。。 良い方法があれば教えていただきたいです。。。 まとめ 今回はDockerネットワークを使ってGoアプリとDBを接続してみました。 アプリのコンテナとDBを分けることができ、なんだかそれらしくなってきたような気がします。 Dockerやdocker-composeがよしなにやってくれる分、上手くいかなかった時にはどこに問題があるのかを見つけるのが大変です。 その分出来上がってしまえば作り直しや複製が簡単にできてしまうので、便利であることに変わりはないですね。 個人的には、「実は・・・」でお伝えした部分はなんとか解決したいものです。。。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

id:radiocat です。以前 ご案内 したとおり11/27に大阪オフィス初のMeetupを開催しました。 今回はMeetupのご報告とともに、運営で得た知見などを少しだけご紹介します。 大阪開発チームのチャレンジ紹介 今回は次の3つのチャレンジをご紹介しました。 チャットディーラーの高速開発を支えるLaravel 今年夏に登壇させて頂いた PHPカンファレンス関西 2018 の内容 をベースに、Laravel導入のチャレンジとそこで得た知見をお伝えしました。Vue.jsと格闘したエピソードでは前回登壇時には無かった開発メンバーの生の声を加えることで、大阪開発チームらしさもお伝えできたと思います。 speakerdeck.com Why Mob Programming? - モブプロという働き方 - モブプロに取り組み始めた経緯、はじめ方、やってみて良かったこと、悪かったことなど、 アジャイル を推進する開発現場のモブプロへのチャレンジと得た知見を余すことなくお伝えしました。本編のスライドに使用されている写真は移転前のオフィスで撮影されたものでしたが、唯一、新オフィスで撮影した一番最後のスライドの「俺たちの戦いはこれからだ！」っぽい雰囲気もまたチャレンジ感をお伝えできたのではないかと思います。 speakerdeck.com トウダン・ジャーニー 1つ目の発表にある PHPカンファレンス 関西 2018への登壇に向けて開発組織を横断した登壇推進チームを結成して取り組んだチャレンジについてお伝えしました。既に次の登壇も決まっており、社内チャットにさりげなく釣り針を落とすことから始まった登壇へのジャーニーは今後もまだまだ続きます。 speakerdeck.com Meetupへのチャレンジ 今回、私自身はMeetupの運営にチャレンジしました。運営のチャレンジで特に大切だったことは次の2つです。 イベントのテーマを何にするか？ Meetupのテーマを何にするかは運営にとって最初の大きな課題でした。そもそもテーマを絞る必要があるのか？という疑問もありました。しかし、せっかく仕事終わりの時間を使って多くのかたに集まってもらうので、我々がどんなイベントにしようとしてるのかをイメージしてもらえる程度にテーマを絞るべきと考えました。特定の技術テーマに絞ることも考えましたが、初めてということもあるのでまずは大阪オフィスと開発チームの雰囲気を知ってもらうのが良いだろうと考えました。 「チャレンジ」というのはチャレンジそのものではなく、チャレンジを実践して結果を出したその場に価値があると思います。つまり、チャレンジというキーワードを通して「開発の現場」を知ってもらうことが大事だと考えました。そして、社内のビアバッシュで「Meetupをはじめよう」というLTを行ってこの思いを開発チームのメンバーに共有しました（ その模様は『 大阪開発ビアバッシュ～11月「新機能特集」 』で投稿していますのでご確認ください）。 今回、登壇を引き受けてくれたメンバーはその思いを汲み取ってそれぞれの視点でエンジニアの現場のエッセンスを発表に盛り込んで伝えてもらえたと思います。 LTをやりたい！ イベントの運営を引き受けるうえで、もうひとつ大切にしたかったのが次の2つを軸とした交流です。 大阪の梅田という地域性 エンジニアの楽しみ ここ数年で大阪でもたくさんの勉強会イベントが日々開催されるようになり、我々も一緒に大阪のコミュニティを盛り上げたいという思いがあります。また、社内外のエンジニアの交流を深めることで、エンジニアが楽しみながら成長していける場にしていけたらという思いもあります。社外の勉強会には私もよく参加させて頂いてたくさん情報交換させて頂いていますが、逆の立場で自社でもイベントを開催し、社外と社内が混ざり合って交流することで2つの軸はさらに強くなると思います。 そこで、LTを募集して参加者の方々にもイベントの一部に加わって頂くことで、この2つを軸とした交流をさらに深めたいと考えました。ただ、弊社が主催するイベントということもあり、本編のセッションと繋げてしまうとLTして頂く側からするとやりにくさもありそうなので、本編のセッションが終わったところで一区切り入れて交流会の中でLTして頂くことにしました。 交流会をスタートしてからLTに入るタイミングや進め方などはまだまだ改善の余地があると感じていますが、運営側の願いどおりの楽しみながら交流できるLTセッションにして頂けました。LTに応募して頂いた皆様、本当にありがとうございました。 おわりに 運営のチャレンジは始まったばかりで課題もたくさんありますが、フィードバックもたくさん頂きましたので得られたものも大きいです。今後につなげて継続的に開催していきたいと思います。 次回は2月頃に開催を予定 詳細が決まり次第、connpassに公開します。 もくもく勉強会も計画中 1月から月1回程度のペースでもくもく勉強会の開催も計画しています。こちらも決まり次第、connpassに公開します。 rakus.connpass.com 今後もこのようなイベントを企画してエンジニアを楽しくするための交流の場をつくっていければと思います。ぜひご参加をお待ちしております。 お知らせ ラク ス Advent Calendar 2018を実施中！ 毎年恒例の アドベントカレンダー が今年も始まっています。 ラク スのメンバーがこの1年間で集めたそれぞれのネタをつないでリレーしていますのでぜひご覧ください！ qiita.com Scrum Fest Osaka 2019に応募しています 大阪では2月に Scrum Fest Osaka 2019 という大きなイベントが開催される予定で、現在セッション公募が行われています。私も楽楽精算開発チームの スクラム の取り組みをご紹介できればと思い応募していますので、よろしければ投票お願いします。 https://confengine.com/scrum-fest-osaka-2019/proposal/8554/- confengine.com

はじめに こんにちは、 @rs_tukki です。 以前 id:radiocat さんが記事にされていましたが、効率よくプロジェクトを進めるにあたって、「振り返り」を行うことは非常に大切です。 今回は、その「振り返り」の手法のひとつ、 KPT 法について話したいと思います。 tech-blog.rakus.co.jp はじめに 振り返りとは なぜ振り返りが大切なのか？ KPT法 K ~Keep:継続すべきこと~ P ~Problem:問題だと思うこと~ T ~Try:改善していくこと~ KPT法のメリット 実践例 おわりに 参考 振り返りとは 振り返る 読み方：ふりかえる (1)身体を翻して後方を見る、後ろ側を向く、などの意味の表現。 (2)過去の物事を顧みる、思い起こすこと。回顧すること。 (3)これまで行われてきた物事の一連の流れを総括すること。 引用: 振り返る(ふりかえる)の意味や定義 わかりやすく解説 Weblio辞書 今回扱う、プロジェクトを進めるにあたっての「振り返り」は、このうちの(3)にあたります。 ここまで実施したことの内容と結果、それを通じて学んだことをメンバー全員で確認することで、これから実施することを見直し、改善していく作業のことを指します。 特に アジャイル 開発を採用したプロジェクトだとスプリントごとに行うことが多いですが、開発現場に限らずとも、複数人で何かを進めていく場では、よりよい方向を目指すために役立ちます。 なぜ振り返りが大切なのか？ 「振り返り」という言葉だけでは、「反省」と勘違いされることがあります。 しかし、反省が、過去の失敗がなぜ起こったのか、という原因の追及を行うのに対して、振り返りは、 目標にしていたことが達成できたか 、 達成できたのなら次の目標はどうするか 、 達成できなかったのならどうすれば達成できるようになるのか 、という考え方のもとに進めていきます。 次の仕事をより効率よく改善していくためには、単なる「反省」ではなく、「振り返り」を実施することが大切なのです。 KPT 法 KPT 法とは、振り返りの手法として用いられている枠組みの1つです。 今までの仕事の中で感じたことを、 一人ずつ「Keep」「Problem」の二つに分けて挙げてもらい、議題とします。その中から次の改善案となる取り組みを「Try」として選び実施していきます。 元々はAlistair Cockburn氏が2004年の著書で提唱した理論を、平鍋 健児氏が KPT と呼んだのが始まりのようです。既に15年近くも使われている伝統の手法みたいですね。 tbpgr.hatenablog.com K ~Keep:継続すべきこと~ K には、実施してよかったこと、今後も継続して実施していきたいことが入ります。 例えば、新機能の開発を行うとき、複雑なコードをモブプログラミングで実装したとします。その機能が大きなバグもなく、スムーズにリリースできたというKeepがあれば、モブプログラミングの実施は効果があった、という判断ができ、またそれを提案した人が達成感を覚える機会にもなります。 P ~Problem:問題だと思うこと~ 一方で P には、失敗したこと、これから改善していきたいことが入ります。 例えば、バグの修正を行うとき、影響範囲がどこなのか、よく調べずに取り組んでしまったとします。 結果、修正に余計な時間がかかってしまった、別のところにバグが発生してしまった、というProblemがあれば、その問題を共有するとともに、改善へ向けた意識付けができます。 ここで問題なのは、先ほど書いたように 原因の追及をしない ということです。 起こってしまった問題に対して個人を攻撃するのではなく、どうすれば改善できるか、を考えることが大事です。 T ~Try:改善していくこと~ 最後に T は、今まで挙がった内容を踏まえて、次の機会にどのように実施していくかのまとめが入ります。 上記の例で言えばモブプログラミングによる効率を上げるために、より多くの機能でモブプログラミングを実践する、 あるいはバグ修正の手戻りをなくすために、修正方針をレビューしてもらう、といった形です。 そして次回の KPT では、今回Tryに挙げたことがまたKやPに入り、更なる改善を目指していくのです。 KPT 法のメリット 振り返りの手法には、有名なもので PDCA *1 がありますが、こちらではそれぞれの中で具体的にどのようなことをすればいいのかが曖昧です。 KPT 法では、 PDCA の中の CA に絞った手法を具体的に示しているので、初めて振り返りをする場合でも、何を確認して何を話し合えばいいのか分かりやすいのがメリットと言えます。 実践例 以下の画像は、私たちのチームで毎年実施しているとあるプロジェクトの KPT です。 特別な道具を用いる必要はなく、一つの Excel ファイルへメンバーが一人ひとり自由に記載してもらっています。 ここで重要なことは、 意見の被りを気にしない ことと、 プロジェクトを実施するたびに行う ことです。意見が被るということは、それだけ多くの人が同じことを感じているということですので、それだけ継続、あるいは改善の優先度が高まります。Problemの全てをTryにするのが難しい場合でも、意見の数を参考にTryにすること、しないことを判断できるのです。 また、 KPT は1回で終えるのではなく、都度繰り返し実施することで、よりよいプロジェクトになっていくのではないかと思います。 おわりに 今回は、チームのプロジェクトを進めるにあたって振り返りが必要なこと、またその手法の一つとして KPT 法を紹介いたしました。 実施したことを適切に振り返り、改善していけば、効率が格段にアップするはずですので、ぜひ一度試してみてください。 参考 Alistair.Cockburn.us | Reflection workshop 「振り返り」をするかしないか、で変わること。振り返りは、未来の自分へのアドバイス…？｜社員研修・人材育成コラム｜FCEトレーニング・カンパニー “振り返り”に役立つ5つのフレームワーク。振り返りシートの書き方や方法を押さえよう｜ferret KPTとは？ふりかえりのフレームワーク・進め方・成功のコツ・ポイント | BOXIL Magazine エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : 計画[Plan]、実行[Do]、評価[Check]、改善[Action]を繰り返していく手法のこと。

こんにちは、fuj_takです。 今回は ラク スのサークル活動について紹介します！ サークル活動について サークル活動は、 ラク スで働くにあたって、モチベーション向上や信頼関係を築くこと、 ワークライフバランス を充実させることを目的としています。 また、サークル活動に対して会社からの補助を受ける事ができます。 業務に近い内容だけでなく、趣味を通じて交流を図るサークルなど様々で 好きなテク ノロ ジー を開発 カメラ撮影 フットサル ガンプラ などです。 その他にも多数のサークルがあります。 ボードゲーム サークル 私が参加しているサークルは「 ボードゲーム サークル」です。 平日の業務時間後、課／部署問わず色々なメンバーが参加しています。 ボードゲーム といっても、広く知られている人生ゲームや モノポリー ではなく、 カタン カルカソンヌ ドミニオン といったもので、今まで名前を聞いた事がないものばかりでした。 始めはルールに混乱するのですが、一度やってみると大体ルールを理解できるようになりました。 どれも奥が深く、日頃パソコンや スマホ にばかり目を向けている自分にはとても新鮮で楽しいです。 日頃なかなかコミュニケーションを取りづらいメンバーとも ボードゲーム を通じて交流を図れるので、社内の交流の幅も広がるし、リフレッシュにもなるんですよね。 私のおすすめは ドミニオン です！ ゲームのルールを様々なバリエーションで組み合わせられるので、毎回違った面白さがあるんですよ。 こんな名前のカードがあって、なんか心をくすぐられます。 地下貯蔵庫 宰相 海の妖婆 策士 わが子が成長したら一緒にやろうともくろんでいます。 まだ1歳と3歳なので今は一緒にできませんが（笑）。 社内に広いリフレッシュスペースも備えているため、 ボードゲーム だけでなく様々な活動で社内の環境を活用できるようになっています。 www.wantedly.com ラク スでは業務だけでなく、サークル活動などの ワークライフバランス も意識しています。 業務もサークルも楽しみながら、楽しいエンジニアライフを送っていきたいと思います！

こんにちは。エンジニアのmickey-STRANGEです。 はじめに 今回は先日、大阪オフィスで開催された11月ビアバッシュをご紹介いたします。 前回のビアバッシュ記事はこちら↓ tech-blog.rakus.co.jp はじめに テーマ発表 Mail Dealer 配配メール 楽楽精算 Chat Dealer 働くDB LT発表 街ブラUIレビュー CIフレンドリなDBドキュメント生成ツールでドキュメントの最新を維持し続ける Meetupをはじめよう おわりに テーマ発表 11月のビアバッシュのテーマは新機能特集でした。 ラク スの各製品の開発者にこんな機能作った、ここがんばったよ、ここ苦労した、というお話をしていただきました。 また、テーマ発表の後にはLT発表もあり、内容たっぷりのビアバッシュでした。 Mail Dealer 今後リリース予定の機能についての発表でした。 いきなりですが、未リリース機能なので、内容は社外秘。本ブログでお伝えすることは出来ません… ですが、求められる要件と実装面の課題との狭間での激しい闘いのお話を聞くことが出来ました。 配配メール 今年7月にリリースした配配メールv5.0の機能についての発表でした。 配配メールv5.0ではデザイン変更、複数ユーザ対応を実施したそうですが、デザイン変更は全画面ですし、複数ユーザ対応も権限など全機能に関わる部分があり、圧倒的なタスク量だったとのことです。 改修対象ソースの洗い出しや、全画面の現状確認+テストに苦労したというお話を聞くことが出来ました。 楽楽精算 楽楽精算では、ユーザ操作を自動化する機能を開発しており、その中でも iOS アプリについての発表でした。 iOS アプリは、領収書明細の自動入力を実現しています。※ 電子帳簿保存法 オプション必須の機能 図メインのスライドになると何故か右から左の資料になっている点が気になりました。 Chat Dealer 既存機能のチャットボットを強化する新機能として開発された「ボットレポート」についての発表でした。 使用中のチャットボットの設定をブラッシュアップするために使用される機能で、実際にデモを交えて解説していただきました。 チャットボットの設定画面がそこはかとなく働くDBの自動処理設定に似ている気がしたのは私だけではありませんでした。 働くDB 自動処理ジャンプパーツについての発表でした。 オプション機能ですが、ジャンプパーツを使用することによって、条件分岐後に同じ処理をする場合の設定がきれいになるそうです。 before-afterを例で挙げていただきましたが、たしかにパーツ数が減って見やすくなっている気がします。 LT発表 LT発表は3人の発表者が登壇してくださいました。 内容は自由で、テーマに関係なく、思うままに発表していただきました。 街ブラUIレビュー 以前にも街中のBAD UIを発表して下さった方が、その続編ともいえる内容での発表でした。 言い回しのおかしい説明や、何かを目立たせるための強引な注意書きは定番の内容ですが、発表の中で気になったのが下の写真です。「電光 掲示 板を見たあと絶対に時計を確認しますよね」と聞いたときのアハ体験がとても印象的でした。 CIフレンドリなDBドキュメント生成ツールでドキュメントの最新を維持し続ける 外部スライドを使用してのツール紹介の発表でした。 tbls というツールの紹介でしたが、肥大化したDBに対して、後付けでテーブル定義をすぐに作成できるというのは非常に魅力的なツールだと感じました。 speakerdeck.com github.com Meetupをはじめよう 先日開催されました、 Rakus Meetup Osaka #1 についての発表でした。 なぜ開催するのか、開催すると何が嬉しいのか、から始まり、開催するにあたっての心構えまでをまとめて発表していただきました。 おわりに 11月のビアバッシュをダイジェストでお送りいたしましたが、いかがでしたでしょうか。 各製品の新機能/オプションについて気になった方は、 ・ご利用中のお客様は、サポート窓口もしくは各製品のサポートサイト ・新規でご検討のお客様は、製品ページからのお問い合わせ にて詳細をご確認くださいませ。

最近、自宅で Laravel を使ったアプリを作成しています。 せっかく作ったアプリなので、公開しようとしたのですが、あくまで趣味の範囲であり、有料の環境を使おうとは思えず、Heroku へデプロイすることにしました。 今回は、Heroku でLaravel アプリをデプロイするための手順を簡単に説明します。 前準備 Profile の作成 .envファイルについて Heroku アプリ作成 Heroku へ push する メールの送信設定 その他 参考サイト 前準備 Heroku のアカウント作成と、Heroku CLI のインストールは事前に済ませてください。 Profile の作成 Heroku アプリの設定値を書き込む Profile を Laravel プロジェクトの直下に作成し、以下の内容を書き込みます。 これにより、Webサーバに Apache を使用し、Laravel の public ディレクト リをドキュメントルートにすることができます。 web: vendor/bin/heroku-php-apache2 public/ ファイルを作成次第、master ブランチに Profile を commit します。 .envファイルについて Laravel の .env ファイルでは、ローカルの 環境変数 を設定できます。 Heroku へのデプロイは、Git を用いて リポジトリ を Heroku へ push することで行うため、 git の管理外である .env ファイルを Heroku へ設置できません。 そのため、config ディレクト リ内の 環境変数 を Heroku 環境で使用したい値に変更しておきます。 Heroku アプリ作成 Laravelアプリの ディレクト リに移動し、 heroku login コマンドでメールアドレスとパスワードを入力し、Heroku にログインします。 その後、Heroku へ PHP アプリを作成するために、 heroku create コマンドを実行します。 > heroku login heroku: Enter your login credentials Email [xxxx.xx.xx@xxx.xx]: Password: ******* Logged in as xxxx.xx.xx@xxx.xx > heroku create my-app 実行できたら、 heroku apps コマンドを実行することで、Heroku にアプリケーションが増えていることがわかります。 Heroku へ push する Heroku へアプリが追加出来たら、作成したプロジェクトを Heroku へデプロイします。 デプロイと言えど、やることは Heroku へ master ブランチを push するだけです。 > git push heroku master 少し時間がかかりますが、push ができればデプロイ完了です。 メールの送信設定 作成していたアプリでは、メールを送信する必要がありました。しかし、Heroku から直接メールを送信することはできないので、他の方法を考える必要があります。 今回は、 Gmail に対して SMTP 接続を行い、メールを Gmail を用いて送信するようにしました。 手順としては、 Google アカウントにて、 Gmail の SMTP 接続を許可したうえで、config/mail. php の 環境変数 を以下のように変更します。 'driver' => env('MAIL_DRIVER', 'smtp'), 'host' => env('MAIL_HOST', 'smtp.gmail.com'), 'port' => env('MAIL_PORT', 465), 'from' => [ 'address' => env('MAIL_FROM_ADDRESS', 'my.gmail@gmail.com'), 'name' => env('MAIL_FROM_NAME', 'Fromの名前'), ], 'encryption' => env('MAIL_ENCRYPTION', 'ssl'), 'username' => env('MAIL_USERNAME', 'my.gmail@gmail.com'), 'password' => env('MAIL_PASSWORD', 'xxxxxxxxxxxxxxxx'), // Gmail設定時のパスワード文字列 これにより、Laravel アプリからメールを送信することができるようになります。 その他 その他、Heroku ではカスタム次第でいろいろな機能が使えます。 ちょっとしたアプリ作成や、実装の練習成果を公開する場合は、非常に便利ですね。 参考サイト qiita.com

はじめに 開発エンジニアのamdaba_sk（ ペンネ ーム未定）です。 前々回 、 前回 と弊社エンジニアへのなんちゃってインタビューで記事を書いてきましたが、今回は久々に調べものをした結果をまとめてみようかと思います。 目次 はじめに 目次 経緯 ラインエディタ ed の概要 edの機能 コマンドライン モード コマンド一覧 行指定 指定された行の操作 その他 ed を実際に使ってみた 同じedでも環境によって違うこともある おわりに 参考 経緯 実は私は自宅では非常に貧弱な性能のマシンしか持っていません。でもやっぱり家でも趣味の開発はしたいわけですが、まずエディタ選びが悩ましい。 Eclipse は動くには動くけどどうももっさりしてて使ってられない。 Atom エディタも同じ感じ。 Visual Studio Code やGeanyという軽量エディタはわりとマシだったものの、時間が経つにつれてだんだん重くなっていく…。 結果ターミナルで vim という選択肢に行き着いたわけですが、やはりあまり使いこなせない。何とか使いこなせるようになろうと vim の操作を調べるうちに、ラインエディタというものの存在を知りました。 ラインエディタ vi( vim )はスクリーンエディタというものに分類されるそうです。 テキストエディタ といえば、画面上に編集するテキストを表示し、その上でカーソルを移動させて編集を行なうものを連想しますが、そういったエディタがスクリーンエディタと呼ばれます。 対してラインエディタでは、画面上への表示は最小限です。スクリーンエディタと異なり内容の閲覧/編集はそれぞれ独立した機能であり、目的の行を抽出、編集、更新というサイクルで編集を行います。 最初期の テキストエディタ の形であり、スクリーンエディタの開発以前は主にこれが使用されていたようです。 ed の概要 ed はラインエディタの一つであり、初期の頃から存在する UNIX 上の標準的な テキストエディタ の一つです。今も事実上全てのバージョンの UNIX と Linux に装備されています。 ただ最近では vi や Emacs 、その他のスクリーンエディタにとって代わられ ed を対話的に使用することは滅多に無いようです。ただ問題が発生したときには ed が使用可能な唯一のエディタである場合もあり、そのような場合に限って ed は対話的に使用されます。 またエディタコマンドは標準入力で受け取られるので、 シェルスクリプト 内で使用することが出来、そういった用途で使われることはあるようです。 edの機能 コマンドライン ed を起動するには端末で以下のようにタイプします。オプションとファイル名を引数として指定できます。 ed [options] [file] 代表的なオプションは以下のものがあります。 オプション 長い書き方 説明 -h --help 使用法を表示して終了 -V --version バージョン情報を表示して終了 -l --loose-exit-status コマンド実行に失敗しても終了ステータス 0 を返す -p STRING --prompt=STRING プロンプトとして STRING を指定 モード ed には、コマンドモードと入力モードがあります。 コマンドモードではエディタを操作するためのコマンドを入力してテキストの編集や置換、行の削除などを行っていきます。存在しないコマンドなどを入力したなどのエラー時は、 ? と表示されます。 入力モードでは、コマンドを実行することはできません。標準入力から入力されたデータは、 直接エディタバッファへと書き込みとされます。ピリオド1つだけの行を入力すると、入力モードを終了します。 コマンド一覧 行指定 ed では常に操作の対象となる行を指定する必要があります。 ed は現在行を管理しており、コマンドに行番号が指定されない場合は、現在行がデフォルト行として用いられます。ファイルが最初に読み出された直後は、現在行はファイルの最後の行となります。一般的に、現在行はコマンドが操作した最後の行となります。 なお行番号は1始まりです。 コマンド 内容 . 現在行 n n 行目 + n 現在行より n 行後の行 + 現在行の１行後の行。 +1 と同じ - n 現在行より n 行前の行 - 現在行より１行前の行。 -1 と同じ $ ファイルの最終行 m , n m 行目から n 行目の範囲。 m , n は数字または単一行指定コマンドを使用可能。e.g., 5行目から10行目を指定する場合は 5,10 、ファイル全体を指定する場合は 1,$ , ファイル全体。 1,$ と同じ ; 現在行から最終行までの範囲。 .,$ と同じ 指定された行の操作 テキストの編集や置換、行の削除などは、行指定とコマンドを組み合わせて行います。以下の表では括弧書きした部分が行指定で、省略時のデフォルト動作を示しています。 コマンド 内容 (.) i 指定した行の前にテキストを追加。編集モードになる (.) a 指定した行の後ろにテキストを追加。編集モードになる (.,.) c 指定した範囲の行を削除して、そこにテキストを追加。編集モードになる (.,.) d 指定した範囲の行を削除 (.,.) y 指定した範囲の行をカットバッファにコピー（yank） (.) x カットバッファの内容を指定した行の後ろにペースト (.,.) m (.) 左辺で指定した範囲の行を右辺で指定した行の後ろに移動。右辺には 0 を指定できる (.,.+1) j 指定した範囲の行を連結 (.,.) p 指定した範囲の行を表示 (.,.) n 指定した範囲の行を行番号つきで表示 (1,$) g/ reg / cmd 指定した範囲の行のうち、 正規表現 で reg と一致した文字列のある行に対し、 cmd を実行 (.,.) s/ reg / rep /n 指定した範囲の行のうち、 正規表現 で reg と n 番目に一致した文字列を rep に置き換える (.,.) s/ reg / rep / 指定した範囲の行のうち、 正規表現 で reg と1番目に一致した文字列を rep に置き換える。 s/ reg / rep /1 と同じ (.,.) s/ reg / rep /g 指定した範囲の行のうち、 正規表現 で reg と一致した文字列をすべて rep に置き換える ($) = 指定された行の行番号を表示 その他 コマンド 内容 u 直前のコマンド実行をアンドゥ。 u コマンド自体もアンドゥできる P コマンドモード時に、行頭にプロンプト文字列を表示。 コマンドライン 引数で文字列が指定されていない時は、 * が使用される。 ! cmd cmd で指定したコマンドを、 sh を用いて実行 w [ file ] file に編集内容を書き込み q エディタを終了。編集内容が未保存の場合はエラー Q エディタを終了。編集内容が未保存でも強制的に終了 ed を実際に使ってみた edコマンドの使用例として、実際にファイルの編集を行ってみました。 とりあえず ed のバージョンを確認。1.1のようです。 $ ed --version GNU Ed 1.1 Copyright (C) 1994 Andrew L. Moore, 2008 Antonio Diaz Diaz. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. 適当な ディレクト リに移動します。 $ cd /some/path $ ls -a ./ ../ ファイルが何もないですが、せっかくなので ed で作ることにしましょう。 $ ed P *i hoge hoge hoge . *= 1 *a fuga fuga fuga moge moge moge piyo piyo piyo . *= 4 *w test 60 *q 最初に P コマンドを使用してプロンプトを出すようにしています。 i や a で行を追加。 = で現在行の番号を確認しています。最後は w コマンドで"test"という名前でファイルに保存しました。 確認してみると、 $ ls test $ cat test hoge hoge hoge fuga fuga fuga moge moge moge piyo piyo piyo 思った通りにファイルが作成されていました。 起動時にファイル名を指定するとエラーが表示されるのですが、最後の保存時に名前を指定しなくてもよくなるようです。 $ ed test2 test2: そのようなファイルやディレクトリはありません P *i hoge . *w 5 *q $ ls test test2 次に作成したファイルを編集してみます。 $ ed test 60 P *,n 1 hoge hoge hoge 2 fuga fuga fuga 3 moge moge moge 4 piyo piyo piyo *2c foo bar baz spam ham egg . *,n 1 hoge hoge hoge 2 foo bar baz 3 spam ham egg 4 moge moge moge 5 piyo piyo piyo *,s/moge/toto/g *,n 1 hoge hoge hoge 2 foo bar baz 3 spam ham egg 4 toto toto toto 5 piyo piyo piyo *wq 70 最初に行番号付きで現在のファイル内容を確認しました。その後 c コマンドで2行目を変更し、ついでに新しい行を続けて入力しています。再度行番号付きで現在のファイル内容を確認すると、確かに2行目が変更され、その下に行が追加されていました。手入力で行の中の一部分を変更することはできないので、仮に同じ部分があったとしてもその行は全部書き直しです。 最後の保存と終了は同時に出来るみたいです。vi も同じですね！ ed 終了後にファイルの中身を確認すると、きちんと変更されていました。 $ cat test hoge hoge hoge foo bar baz spam ham egg toto toto toto piyo piyo piyo 同じedでも環境によって違うこともある Windows にインストールした BusyBox 1.22.1に含まれる ed は、上でまとめたものとはオプションやコマンドが若干異なるようでした。 コマンドライン オプションが使えない デフォルトでプロンプトが表示されている プロンプト文字列は : P コマンドがない 他にも違いはあるかも おわりに 古くからあるがゆえに逆に知らなかったエディタ ed について調べてみました。 実際使ってみましたが、ファイル内が今どんな状態なのかがすぐにわからないのが少し不安に思いました。いくら軽量だとは言え普段使いするならやっぱりスクリーンエディタかな、というのが正直な感想です。ただ シェルスクリプト で使うこともあるかも…。 なお今回まとめたのは ed のコマンドの中でも一部にすぎません。もっと詳しく知りたいなら参考に挙げたページや、manやinfoを見てくださいね。 参考 テキストエディタ - Wikipedia Man page of ED ED - Wikipedia edを使ってみる http://www.uetyi.com/server-const/entry-271.html ラインエディタ体感ツアー――vi/vimの「動作モード」なるものの謎に迫る - 新・日々録 by TRASH BOX@Eel おすすめのLinuxフリーテキストエディタ12選！ 5-1 どんな環境でも使えるライン・エディタ - edエディタ - エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

スクラム とは こんにちは。strongWhiteです。今回は スクラム に関する解説記事です。 スクラム とは、変化の激しいソフトウェア開発の問題に対応するための開発手法です。 ソフトウェアは建築物などの三次元的な物体とは異なり、認識しにくく不透明な存在であるため、 潜在的 な問題（バグなど）を早期に察知するのが難しい性質を持っています。また、問題を認識できたとしても修正などの後戻りが難しい場合があります。このようなソフトウェア開発の問題を解決するのが スクラム です。 スクラム では、あらかじめ定めた期間内に一定の成果物を作成（開発）し、徐々にソフトウェアを構築するというアプローチを取ります。ソフトウェアに「透明性」を見出し、 潜在的 な問題を認識しやすくするのです。 今回の記事では スクラム を用いた開発を始める方向けの前提知識として、 スクラム 開発の関係者（ スクラムチーム ）と スクラム 開発中で発生するイベント（ スクラムイベント ）について解説します。 スクラムとは スクラムチーム プロダクトオーナー 開発チーム スクラムマスター まとめ（1） スクラムイベント スプリント スプリントプランニング デイリースクラム スプリントレビュー スプリントレトロスペクティブ まとめ（2） スクラム チーム スクラム 開発は、以下の役割を担う人（たち）が相互に作用し合って進捗していきます。 プロダクトオーナー 開発チーム スクラム マスター 各役割とその使命については後述します。これらの役割を担い、 スクラム 開発を進める人たちを スクラムチーム と呼びます。 プロダクトオーナー プロダクトオーナー は開発しようとしているプロダクトのオーナーであり、プロダクトの最終責任者です。 プロダクトオーナーは「プロダクトのビジネス的価値」に着目し、プロダクトで実現したいことに優先順位をつけてリスト化した プロダクトバックログ を作成・更新・管理する役割を担います。プロダクトオーナーは 開発チーム にプロダクト バックログ を公開することで、なぜそのプロダクトを作るのかというビジョンと優先順位を理解してもらうよう努めます。 開発チーム 開発チーム はプロダクトオーナーが決定した要件を成果物として実現するメンバーの集まりです。 プロダクトの開発責任を担うのが開発チームであり、プロダクトに不具合がある場合や、プロダクトオーナーの定める品質基準に達しない場合にそれらの問題解決に努めます。 スクラム マスター スクラムマスター はプロダクトオーナーと開発チームが スクラム を実行する手助けを行います。 スクラム マスターは現場の スクラム のルールを熟知し、 スクラム チームが最高のパフォーマンスを発揮できるように働きかけます。開発チームが技術的困難に遭遇している場合は解決策を提示し、プロダクトオーナーがプロダクト バックログ の更新に問題を抱えている場合はアド バイス します。また、 スクラム チームの進捗に影響を及ぼす要因の排除や、 スクラム の理解が不足しているメンバーに対して コーチン グするなど、その役割は多種多様です。 まとめ（1） スクラム 開発における各役割とその関係の理解が少しでも進めば幸いです。 「要するにプロダクトの責任者と開発チームがいて、それらのサポーターを通して開発を進めるってこと？」 ...今は恐らくこれぐらいの認識ではないでしょうか。実際に スクラム を導入されるとそれぞれの役割の重要性が見えてくるかと思います。 「役割はなんとなく理解できたけど、どのように「 スクラム を実行する」の？開発以外のイベントって何？」 それでは次章以降、 スクラム 開発で発生するイベント（ スクラムイベント ）について解説します。 スクラム イベント スクラム 開発では、単に開発を進めるだけでなく、ソフトウェアの「透明性」を見出すためのアプローチを取る必要があります。そのために規則的に行われる5つのイベントがあり、これらを スクラムイベント と呼びます。 スプリント スプリントプランニング デイリー スクラム スプリントレビュー スプリントレトロスペクティブ スクラム イベントは定期的なミーティングとは違い、自分たちの スクラム のあり方に問題があれば解決し、より良い状況を作るために行います。このようにフィードバックを織り込んだイベントを実施することで開発を円滑に進めます。 スプリント スプリント は開発の イテレーション のことです。 スクラム チーム内で適当な期間を定めますが、通常は1週間〜3週間が多いです。 決められたサイクルで開発を進めることで、 スクラム チームで完了できる仕事量を把握します。 スプリントプランニング スプリントプランニング はスプリント開始時に行われる最初の スクラム イベントです。 「スプリント期間内で何ができるか（何をするか）」を明らかにするミーティングであり、 スクラム チーム全員が参加します。プロダクト バックログ で優先順位の高いものから順に完了できそうなものを選び、選んだ項目について具体的なタスク量を明確化するために適当な単位でタスクを分割してリスト化した スプリントバックログ を作成します。 デイリー スクラム デイリースクラム はいわゆる「朝会」であり、昨日したこと、今日やること、課題を共有する場です。 主に開発チームが行う スクラム イベントであり、スプリント期間中は決まった時間に毎日行います。そのスプリントのゴールが達成できそうかと、日々の仕事の進捗を把握します。また、デイリー スクラム には スクラム マスターも参加します。 スプリントレビュー スプリントレビュー はスプリントの成果物を披露し、プロダクトについてフィードバックを得るためのミーティングです。 スクラム チーム全員が参加します。 スクラム チームの他に ステークホルダー （ スクラム チームに所属しない会社の経営陣、あるいは顧客など）を招待する場合もあります。開発チームはスプリント期間内に達成できたことと、達成できなかったことを伝え、次回以降何をどう作っていけばいいか議論します。 スプリントレトロスペクティブ スプリントレトロスペクティブ はスプリント終了時に行われる最後の スクラム イベントです。 スクラム チーム全員が参加します。 いわゆる「振り返り」であり、 スクラム チームの現状を見直し、次回以降のスプリントでより良い仕事を行うための改善策を出していく場です。開発チームと スクラム マスターが中心になって進め、次回のスプリントに向けてのアクションプランを出します。 まとめ（2） スクラム 開発の進め方が理解できたでしょうか。本当はもう少し細かい話もあるのでが、ざっくりとまとめると 計画→開発→お披露目→振り返り→（以下、繰り返し） となります。 イテレーション が設定されているおかげで問題に気付きやすくなり、改善や後戻りしやすいシステムになっています。これこそが スクラム 開発の醍醐味であり強みでもあります。これから スクラム を始める人にとって、今回の記事が少しでも参考になれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

id:radiocat です。このたび大阪Meetupの運営委員に任命されました！ 9月に東京でMeetupを開催しましたが、大阪でもやります！ rakus.connpass.com 新しくなった大阪オフィスは本当に良い環境で、広くなった セミ ナールームを早く活用したい！ということで移転直後から準備を進めてきました。 そんな大阪オフィスの様子は↓コチラをご覧ください。 www.wantedly.com テーマは『大阪開発チームのチャレンジ』です せっかくの大阪初開催ですので、大阪所属のエンジニアで トーク セッションを固めました。東京を中心として盛んに行われているITエンジニアの勉強会ですが、最近は大阪でも活発に行われていて私もよく同業他社の勉強会に参加させて頂いています。せっかく、梅田駅から徒歩5分という立地で セミ ナールームを拡充して環境も整ってきたので、我々も一緒に大阪のIT業界を盛り上げていきたいと思っています。今後はコミュニティへの会場提供もしていきたいので、この機会に新しいオフィスを覗いてみていただければと思います。 当日の トーク セッションは以下を予定しています。なお、 トーク 内容と順番は仮のものですので当日までに変更の可能性がありますがご了承ください。 チャットディーラーの高速開発を支えるLaravel 吉元和仁（よしもとかずひと） 今年夏に開催された PHPカンファレンス 関西 2018 の登壇内容をベースにお話しします。10年以上 PHP でノン フレームワーク により開発・運用されてきた主力サービス（メールディーラー）の開発チームが、新規に姉妹サービス（チャットディーラー）を立ち上げる際に Laravel を選択しました。 開発期間半年というスピードが求められる中で、Laravel での新規サービス立ち上げのチャレンジをご紹介します。 Why Mob Programming? - モブプロという働き方 - 大平直宏（おおひらなおひろ） 大阪の楽楽精算の開発チームでは、 スクラム 開発を取り入れて新機能の開発に取り組んでいます。急成長するサービスの開発を支えるためこの1年間で4人のメンバーが増えており、メンバー同士の知識共有が課題となっています。 アジャイル な開発を推進するために取り入れているモブプログラミングのチャレンジをご紹介します。 トウダン・ジャーニー 川並裕（かわなみゆう） 今年の夏に開催された PHP カンファレンス関西 2018 で、会社として初めて技術イベントに協賛し、2 名のエンジニアが登壇しました。開発組織を横断した登壇推進チームが業務として登壇プロジェクトを推進したチャレンジをご紹介します。 大阪のエンジニア同士で交流しましょう！ 今回は参加者のみなさまの中からもLTを募集いたします。テーマは同じく「チャレンジ」です。みなさまが普段チャレンジしていることを共有していただければと思います。そして トーク セッション後には交流会も開催します。弊社のエンジニアも含めて参加者同士で情報を交換し合い、エンジニア同士の交流を深めていければと思っています。 会場の場所や参加方法については以下のconnpassに掲載していますのでご確認のうえお申し込みください。みなさまのご参加をお待ちしております！ rakus.connpass.com

はじめに こんにちは、strongWhiteです。 ラク スでは毎月1回、開発チーム主催の ビアバッシュ を開催しています。 ビアバッシュとはビールや軽食をいただきながら技術内容について楽しく語り合う交流会です。 今回は10月に大阪で開催したビアバッシュの内容を記事にしたいと思います（過去の開催も記事になっていますので、よろしければ下記をご覧ください）。 tech-blog.rakus.co.jp 今回は「行ってきた特集」 大阪のビアバッシュは決められたテーマに沿って発表する「 テーマ枠 」と、自由なテーマで発表する「 自由枠 」の2セッションを設けて発表を進めます。 また、「自由枠」は質疑応答ありで15分間の発表と質疑応答なしで5分間の発表（LT枠）に分かれます。 10月のテーマは「 行ってきた特集 」であり、各々がこれまで参加した勉強会や セミ ナーの様子と、そこで得た学びを共有していただきました。 今回の記事では主に「テーマ枠」の発表の様子をご紹介いたします。 はじめに 今回は「行ってきた特集」 行ってきた特集（テーマ枠） 京都アジャイル勉強会に行ってきた ハッカソンあるある 今回から新オフィスで発表 おわりに 参考 行ってきた特集（テーマ枠） 京都 アジャイル 勉強会に行ってきた 筆者が「 京都アジャイル勉強会 」に赴き、 スクラム について学んだことを発表いたしました。 スクラム とは「ソフトウェアに変更はつきもの」という前提から、要求や仕様変更に柔軟に対応するために生まれたソフトウェア開発手法です。 もともと私の所属するチームでは スクラム による開発を推進しており、私自身の スクラム に対する知識理解の向上を目的に勉強会に出席しました。 この勉強会はディスカッション形式で、会場には スクラム を実践する人たちが集まります。特にタイムボックスはなく、開始時間になると各々が日頃から スクラム について感じている課題や疑問を議論し合います。同じ苦難や困難に立ち向かう者同士、お互いに スクラム に対する理解を深め合うのがこの勉強会の目的です。 筆者は個人的に「スプリント バックログ の作成に時間がかかる問題」を抱えており、問題解決のヒントを得るため勉強会へと足を運びました。現在は、勉強会で得た知見をもとに自身の スクラム に対する姿勢の見直しを行なっています。 ハッカソン あるある ハッカソン に参加しているとこういう場面絶対にある！という「 ハッカソンあるある 」を発表していただきました。 ハッカソン によく行かれる方は、↓と同じようなことを感じられたことがあるのではないでしょうか？ 名刺は切れる 名刺を交換すると世の中は狭いことがわかる ハードウェアがわかるとありがたがられる ネットワークはもっとありがたがられる etc... ハッカソン の場合、（テーマにもよりますが） プログラマー よりハードウェアやネットワーク面に強い方がいると心強いと思います。 突発的なネットワーク障害に遭遇した場合に、すぐに原因を究明して修正してくれると勉強会もスムーズに進行するかと思います。 筆者は ハッカソン に参加した経験はないですが、「名刺を交換すると世の中は狭いことがわかる」はよくわかります。 最近も、プログラミングの外部勉強会に参加したのですが、そこで大学時代の同期に出会いました。以前にエンジニアになったとは聞いていたのですが、世の中は狭いものです...「あるある」は共感するものがあるととても面白いです。 今回から新オフィスで発表 ラク スは9月末に大阪オフィスを毎日インテシオから 梅田ゲートタワー へ移転しました。今回のビアバッシュは引っ越し後初のビアバッシュとなりました。 年々新卒をはじめ、社員の増加に伴ってビアバッシュの参加者も増加してきたため、旧オフィスでは開催スペースの圧迫化が問題だったのですが、新オフィスでは広々とした開催スペースとなり、より新鮮な気持ちでビアバッシュを楽しむことができました。 おわりに いかがでしたでしょうか。今後も定期的にビアバッシュの様子をお伝えしていこうと思います。次回のテーマは「 新機能特集 」を予定しています。 最近の弊社商品のリリース機能を紹介できたらと思います。どのような発表になるか楽しみです。 参考 京都アジャイル勉強会 スクラム ハッカソン

はじめに こんにちは、開発エンジニアのnorth_mkyです。 先日業務にて負荷検証を JMeter で行うことになり、弊社エンジニアが書いた下記の記事を読みつつ複数のシナリオ作成を行いました。 tech-blog.rakus.co.jp ですが最初の1シナリオの作成で全然想定している動作にならず、予想よりも3倍ほど時間がかかってしまいました。。。 シナリオ作成にあたって必要な知識として、もちろんシナリオを作成する対象の画面の仕様理解も必要ですが、 思った以上に小さな設定ミスが多い です。 この記事では原因箇所に気づくまでのプチ・ベストプ ラク ティスをご紹介したいと思います。 はじめに 対象読者 シナリオ作成トラブルシューティングガイド Step0. 準備 Step1. jmeter.logを確認する Step2. リクエストパラメータの値が正しいか確認する Step3. シナリオ実行がどこのリクエストで落ちたか実行順に見て特定する おわりに 対象読者 シナリオを作成している 方には有益な記事になっていると思います。 特に少し複雑なシナリオを作成しようとしている方にはぜひ一度みていただけたらと思います。 JMeter のシナリオ実行はしたことがあるけどシナリオ作成は初めて/始めたばっかりの方 シナリオ開始から終了までの間の画面遷移が多い( サンプラー が多い) 特定のリク エス トパラメータの値を外部ファイル( CSV )から読み込んでセットするようにしている リク エス トパラメータが動的に変わる画面遷移がある CSRF トーク ン シナリオ作成 トラブルシューティング ガイド ミスの原因調査が簡単なものから除々に特定が難しい原因調査へとステップを踏むと効率的 ですのでそのような構成にしました。シナリオ デバッグ をしていると最初は直しても直しても違うエラーがでてくる...と思わせてくるところがあるのですが、多くは簡単な設定ミスなので、気にせず淡々と確認していきましょう！ Step0. 準備 まず最初に デバッグ ができるようにする設定が必要です。 テスト計画 の直下に以下2点の コンポーネント を追加します。設定を適切に行うと 実際に実行したときのリク エス ト・レスポンスの情報がすべて見れるようになります 。注意なのですが、 デバッグ 用に追加するので 実際に負荷検証を流すときには必ず無効にしてください。 正しく計測ができない可能性があります。 リスナー > シンプルデータライタ 実行結果をファイル出力する コンポーネント 。以下のような xml ファイル形式に設定する リスナー > 結果をツリーで表示 1.で出力したファイルを読み込んでリク エス ト・レスポンスをわかりやすい形で表示する コンポーネント 失敗したリク エス トは赤字にしてくれる 1 まちがっていそうなパラメータを赤字にしてくれる URL エンコード されたパラメータをデコードして表示してくれる Step1. jmeter .logを確認する ポイント 外部ファイルが正しく読み込まれているか パスの指定が誤っていないか 外部ファイルの書き方とシナリオで設定したカラムの順番、情報に誤りがないか いざテスト実行してみたものの、本来ならもっと実行に時間がかかるところが一瞬で実行が終わってしまった...という場合はそもそもシナリオを実行するための準備に不足がある可能性が高いです。そのときはまず jmeter .logを確認します。 jmeter .logは実行ログとなっており、外部ファイルの読み込みがうまく行っていない場合はエラーとして記録を残してくれます。 jmeter .logをみて原因箇所が推測できたら、 設定エレメント > CSV Data Set Config の設定内容であったり指定したファイルの形式があっているか確認し適宜修正してください。 Step2. リク エス トパラメータの値が正しいか確認する Step0 で設定した リスナー > 結果をツリーで表示 を見て実際にアクセスしたときのリク エス トパラメータを見ていきます。 このパラメータの設定のミスが割と多いので下記ポイント4つを順番に見ていくと良いと思います。 ポイント 変数名がそのまま出ていないか 適切にURL エンコード をしているか 前画面の値を取得する 後処理 > 正規表現抽出 で設定した変数名をパラメータにセットし忘れていないか 受け渡している変数パラメータの値が前画面から正しく取得されているか 1. 変数名がそのまま出ていないか リク エス トパラメータの値を見ればすぐに見つけられます。( ${hoge} ) 大抵原因は 「 サンプラー に設定した変数名が定義した変数名と違う」 「 後処理 > 正規表現抽出 の 正規表現 が誤っていて抽出結果が空」 の いづれ かになります。 2. 適切にURL エンコード をしているか マルチバイト文字であったりURLでメタ文字や利用できない文字が含まれるパラメータをURL エンコード しないでリク エス トを投げているか、逆にすでにURL エンコード しているところに誤って二重でURL エンコード を行ってしまっている場合があります。「URL Encode?」 チェックボックス を確認してみてください。 HTTPプロキシをたててリク エス トを記録した場合、よしなに JMeter がつけてくれている場合が多いですが、 正規表現 を組んだりしていくうちにチェックが外れてしまった/ついてしまったことがでてくるかもしれません。緻密な作業でミスが起きやすいので自分を責めず、そしてめげずに進めていきましょう...( 経験談 ) 3. 前画面の値を取得する 後処理 > 正規表現抽出 で設定した変数名をパラメータにセットし忘れていないか リク エス トを記録した場合、その記録していた値のままになっているかもしれません。もう一度変数の設定漏れがないか確認してみてください。 4. 受け渡している変数パラメータの値が前画面から正しく取得されているか 1.で書いた原因に似ていますが、 正規表現 抽出で前画面から抽出自体はできていても余計な文字も拾ってきていてエラーになっている可能性があります。 リスナー > 結果をツリーで表示 ではレスポンスのbodyに対して文字列検索ができるため、リク エス トパラメータにセットした値が前画面のレスポンス内で引っかかるか確認してみてください。 Step3. シナリオ実行がどこのリク エス トで落ちたか実行順に見て特定する ポイント リク エス ト/レスポンスごとに想定の挙動になっているか確認する webサーバ/アプリログなど 画面 Step1,2を確認しても解消しない場合はいよいよシナリオをしらみつぶしに確認する作業になります。複数箇所でエラーが出ている場合は、だいたい上のエラーが引き継がれてエラーがでることが多いので焦る気持ちを抑えて上から順番に見ていきます。 レスポンスでエラー画面やエラー文言があれば、そこからコケた原因を考えられるかと思います。 アサーション を適切に設定していないとエラーなのに見た目は成功を表すグリーンのアイコンになるのでより原因特定が難しくなりますよね。後世のために原因がわかったら アサーション を追加して次もし引っかかったときは失敗を表すレッドのアイコンになるようにすると良いと思います。 おわりに いかがでしたでしょうか。長いシナリオだったりパラメータの多い画面の遷移となるとシナリオに小さいミスが起きやすくなる割に原因特定に時間がかかり気味になります。 そんなときにこの記事をみていただいて皆さんのもやもやや苦痛が少しでも和らげば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com 失敗かかどうかはアプリケーションに依存するので サンプラー > アサーション で適宜エラーを定義する必要があります ↩

id:radiocat です。 スクラム は 銀の弾丸 ではないので、いつもうまくいくとは限りません。今回は私たちのチームの失敗事例をご紹介します。 以前の投稿 でも紹介しましたが、私たちのチームは1週間スプリントを採用しています。以下のように木曜に計画を立ててスタートし、翌週木曜にレビューを行う流れです。 ご覧のように開発に注力できる期間は実質4日しかありません。油断するとすぐにレビューの日を迎えるので緊張感があります。そして、その緊張感にさらに拍車をかける要素がスプリント期間中の「休日」です。 連休の狭間の期間は スクラム を進めるべきか？ ご存知の通り、2018年の9月は2週続けて月曜が休日となる期間がありました。このままだと開発が実質3日しかないスプリントが2回続きます。 さらに、この連休期間を利用して2人の主力メンバーが休暇を取ることになりました。5人チームなので開発力は半減します。チームはこの期間をどう過ごすべきでしょうか？ 連休の狭間もスプリントを進める選択 ご察しのとおり、我々はこのままスプリントを進めました。とはいえ、さすがに丸腰でこの状況に立ち向かうほどの度胸はないので、我々なりに対策を立てて取り組もうとしました。まずはその対策をご紹介します。 連休期間の スクラム イベントは中止する 全員揃っていない状態なのでスプリントレビューは1週間スキップすることにしました。ただ、連休前の金曜から着手したスプリントを中断するのはもったいないので以下のように進めることにしました。 個々の開発は進めて良い 中途半端に作業を中断して別の事をやるのも気持ちが悪いので、出社しているメンバーは出来る範囲で開発は進めておくことにしました。ただし主力不在で開発チーム内でのフォローやレビューは手薄になるので、無理せず出来る範囲で作業を進めて、主力メンバーのレビューが必要な作業などは連休明けまで保留するようにしました。 狭間の4日間で1日分の実績を目標にする 主力2人の休暇でチーム全体のパフォーマンスは低下しますが、残りのメンバーだけでも4日あれば普段の1日分ぐらいの実績は充分達成出来るだろうと考えました。そうすることで結果的に2週間の合計が4日分の実績となるので、いつも進めている1週間スプリントと同じぐらいのベロシティを目指すことになり、感覚的にもわかりやすい目標になります。主力不在とはいえ4日で1日分なので、出勤しているメンバーにも負担がかからないはずです。 プランニングと共有をいつも以上にしっかり行う 念のため、休暇の前日に改めて主力メンバーが考えているスプリント中のタスクの進め方をチームのメンバーへしっかり共有して引き継いでもらいました。 下がりきらなかったバーンダウンチャート 結果的にこのスプリントでは、残タスク量を示すバーンダウンチャートの実績が次のようになりました。 微妙な結果です。大負けというほどでもなく、微妙な感じが逆に気持ち悪いくらいです。しかし、このスプリントのふりかえりはチームに疲弊感が漂い、私も含めてみんなモヤっとした状態で改善アクションもうまくまとめられないままスプリントは終了しました。 なぜ計画どおりにスプリントが終わらなかったのか？ いったい何が問題だったのか、後日 スクラム コーチに相談してみると3つの課題が見えてきました。 スプリントを進めるのに十分な体制ではなかった 私たちのチームのメンバー構成を改めて整理すると次のようになっています。 現在進めているプロジェクトの在籍期間が1年以上のメンバーが誰もいない状況で、目に見える人数以上にチームの体制は弱くなっています。さらに実はこのスプリントの前半の主力メンバーが休暇に入る直前まで、チームを助けるべき スクラム マスターは出張先からリモートでチームの活動に参加しており、開発チームの状況を詳細まで把握出来ない状況にありました。いつも以上にしっかり共有してから休暇に入るという事前の対策は開発チーム内の個々のメンバーの感覚に託されており、客観的にみても対策できているといえる状態かどうかは誰もわからない状況になっていました。 バックログ がReadyではなかった さて、上記のバーンダウンチャートは狭間の4日間を1日の実績としてまとめていますが、これをそれぞれの日ごとの実績に分けてみると次のような実績になっていました。 主力メンバーが休暇に入った初日から実績が上がらず、残タスクが全く減っていません。すでに危険な状況に突入していることがわかります。実はこのとき、プランニング時点の想定が覆ってそのままではタスクを進められないことがわかりました。 スクラム マスターはチームの状況を察知し、いったんタスクの終了条件を見直したりスプリントのゴールを見直すなどの調整を行い、一度は残タスクが減りましたが、すぐにまた別の問題が発生して逆に残タスクが増えてしまいました。 結果的にこの時着手していた バックログ は最初からReadyではなかったのです。つまりこのスプリントは前半時点ですでにコールド負けが決まっていました。 しかし、1つ目の原因にあるとおり、チームの体制が不十分で、前半時点ではこの状況を正しく判断できるメンバーがいませんでした。 スクラム マスターはチームの状況を正確に判断出来るだけの情報をキャッチできていなかったため場当たり的な対策を取ってしまい、結果的にはコールド負けしたチームにそのまま試合続行を促すことになってしまいました。 仕掛りがたまっていて手当てが追いつかず チームはそれでもなんとかスプリントのゴールを目指そうと取り組みました。休暇が明けてから、主力メンバーの頑張りによってなんとか持ち直しますが、計画していたゴールには到達できませんでした。 バーンダウンチャートを見るとスプリントの最後で残タスクの消化が少なくなっています。実はこのとき、仕掛中のタスクがたくさ増えすぎて経験のある主力メンバーでも残りの期間で全てを手当することは出来なくなっていました。スプリント前半に発生した問題をなんとかしようとして計画時の想定とは違う進め方をしたり、いったん保留して他のタスクに手を出した結果、想定以上に仕掛り中のタスクが増えてしまったのです。 コールド負けしない鉄則 実はこれらの原因は既に スクラム コーチの吉羽さんが別の場で示されているものでした。 slide.meguro.ryuzee.com この資料の中で アジャイル 開発でコールド負けしないための5つのポイントが挙げられています。 十分条件 で開始する Readyなプロダクト バックログ 項目だけ着手する 同時の仕掛りを少なくする フィードバックサイクルを回し続ける 技術に投資し続ける 我々は5つのポイントのうち3つを犯してしまっていました。コールド負けしてしまっても仕方ないですね。スプリントを進めるにあたり、改めてこれらの3つのポイントが重要であることを痛感しました。 開始するのに十分な条件か？ バックログ はReadyになっているか？ 仕掛りが増えすぎる進め方をしていないか？ それでも、我々はこの1回のスプリントでとても大きな学びを得たとも思っています。今後はこれらをしっかり意識してチームで取り組もうとしています。 REGIONAL SCRUM GATHERING TOKYO 2019 のCfPを出しました！ 2019年1月9日〜11日に大崎ブライトコアホールで1年に1度の スクラム のビックイベント「REGIONAL SCRUM GATHERING TOKYO 2019」が開催されます。 2019.scrumgatheringtokyo.org 私たちの スクラム の取り組みを多くの方に知っていただき、そして私たち自身が学びを得るためにプロポーザルに応募しました。下記のリンクをご確認いただき、ご興味のあるかたは是非likeをお願いします（締切が10月末ですのでご注意ください）。 https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/7956/- confengine.com REGIONAL SCRUM GATHERING TOKYOでは毎回たくさんの素晴らしいセッションが行われますので、 スクラム に興味のあるかたはぜひチケットを入手してご参加いただければと思います。

初めに こんにちは！エンジニアの id:FM_Harmony です。 前回はgitのfetchコマンドについて、記事を投稿しました。 tech-blog.rakus.co.jp 今回は postgreSQL の対話型ターミナル、 psql のオプションについて紹介したいと思います。 普段の業務でも、 psql コマンドの -f オプションや -c オプションを利用してクエリを発行する機会が多いのですが、 psql には他にも便利なオプションが備わっています。 多くのオプションが存在しますが、今回はその中でも個人的に便利だと思う4つのオプションについて紹介します。 初めに -a：発行したクエリ、コメントも出力する -t：抽出結果のみ出力 -A：位置揃えを行わない -F：区切り文字を指定する 利用例：抽出結果からcsvファイルを作成する 終わりに 参考 -a：発行したクエリ、コメントも出力する psql コマンドを利用して SQL ファイルやクエリの発行を行った場合、実行結果のみ出力されます。 sample.sql --this is comment SELECT columnA, columnB FROM some_table; $ psql -U postgres -d some_db -f sample.sql columnA | columnB ---------+--------- A | B (1行) この時、 psql コマンドに -a オプションを指定することで、発行したクエリや SQL ファイルに記載したコメントも出力することができます。 $ psql -U postgres -d some_db -f sample.sql -a --this is comment SELECT columnA, columnB FROM some_table; columnA | columnB ---------+--------- A | B (1行) このオプションを使うことで、例えば SQL ファイルの実行結果ログをレビューしてもらう際など、レビュー者が SQL ファイルの実行コマンドを把握しやすくなります。 -t：抽出結果のみ出力 通常、 psql コマンドを用いて抽出結果を出力する場合、列名や出力した行を出力結果に含めます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" columnA | columnB ---------+--------- A | B (1行) psql コマンドに -t オプションを指定することで、抽出結果から列名や行数表示を除いて出力することができます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -t A | B 例えば、 psql で抽出した結果を基にして何らかの繰り返し処理を行う スクリプト を作成する際など、抽出結果に列名や行数表示は必要ない場合があります。 そこで、このオプションを使うことでそれらを除いた出力結果を取得することができます。 -A：位置揃えを行わない psql コマンドを利用した際の抽出結果は、表形式に整形されて出力されます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" columnA | columnB ---------+--------- A | B (1行) この時、 psql コマンドに -A オプションを利用することで、位置揃えなしの区切り文字を | とした形式で抽出結果を出力することができます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -A columnA|columnB A|B (1行) 主にこのオプションは、次の -F オプションと組み合わせて抽出結果の出力形式を変更する際に利用します。 -F：区切り文字を指定する 前述の -A オプションと共に利用することで、抽出結果の出力形式を変更することができます。 -F オプションの後に指定した文字を、抽出結果の区切り文字に指定します。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -A -F : columnA:columnB A:B (1行) 利用例：抽出結果から csv ファイルを作成する 今回紹介したオプションの利用例として、データベースの抽出結果から csv ファイルを作成する方法をご紹介します。 この場合、 -A 、 -F オプションが有効です。 2つのオプションを組み合わせて区切り文字を カンマ にすることで、抽出結果を csv ファイルの形式で出力することができます。 $ psql -U some_user -d some_db -c "SELECT columnA, columnB FROM some_table;" -A -F , columnA,columnB A,B (1行) あとは、出力結果に対してリダイレクトなどを用いることで、抽出結果から csv ファイルを作成することができます。 また、列名は CSV ファイルに含めるが、行数は含めたくないという場合、 grep コマンド などと組み合わせて行数表示を出力結果から除くと良いでしょう。 # 行数表示を削除する一例 $ psql -U some_user -d some_db -A -F , -c "SELECT * FROM some_table;" | grep -v "行" columnA,columnB A,B 終わりに psql のオプションをいくつか紹介してみましたが、いかがでしたでしょうか。 今回紹介したオプションは抽出結果に影響を与えるものばかりですが、もちろんデータの追加や更新時に利用できるオプションも存在します。 ただ、 psql コマンドを利用する目的として多いのは、やはりデータ抽出だと思います。 なので、今回紹介したオプションを利用できる機会というのは、ほかのオプションに比べて多いように感じます。 皆さまも psql コマンドを利用される際は、今回紹介したオプションの利用を検討してみてはいかがでしょうか。 参考 psql - PostgreSQL 9.6.5文書 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

大阪オフィスの移転 を機に、生活リズムも絶賛見直し中の @kawanamiyuu です。 今回は昨年度から取り組んでいる、通称「かみせんプロジェクト」の今期の成果（の一部）についてご紹介します。 かみせんプロジェクトとは ミッション 目標 社内システムのマイクロサービス化 社内システムの概要 かみせんプロジェクト開始前 2018 年 9 月現在 マイクロサービスの結果整合性 課題感 検証内容 検証結果（得られた知見） サービスの分割は難しい 結果整合性の担保は難しい 最後に かみせんプロジェクトとは かみせんプロジェクトとは「開発の未来に先手を打つプロジェクト」の略称で、2017 年度に取り組みが始まりました。 ミッション 『継続的に新しいことに取り組み、組織要望に対して迅速にトレンド技術で応えることができるようになる』 目標 具体的には以下の実現のための技術検証や知見獲得を、社内システムのマイクロサービス化を題材に行っています。 ソフトウェア規模に比例した開発効率低下の軽減 無停止デプロイ、不具合発生率低下などの高可用性の実現 現行ソフトウェアからの段階的な移行の実現 社内システムのマイクロサービス化 社内システムの概要 LAMP ( PHP ) で構築されたモノリシックな Web アプリケーション エンジニア、 経理 担当者などが、社内からのみアクセスして利用する プロジェクト管理機能、開発稼働集計機能などを提供する かみせんプロジェクト開始前 すべての機能がモノリシックなアプリケーションとして提供されている 2018 年 9 月現在 モノリシックなアプリケーションから、一部の機能をマイクロサービスとして切り出した マイクロサービスは AWS 上でコンテナとして動作している マイクロサービスの結果整合性 マイクロサービス化を進めるとバックエンドで複数のサービスが協調して動作することになり、これまではデータベースの トランザクション 機能により担保されていたデータの一貫性について別のアプローチが必要になります。 かみせんプロジェクトの今期の取り組みの 1 つとして、マイクロサービスの結果整合性について調査や技術検証を行いました。 課題感 複数に分割されたサービス間のデータの一貫性をどのように保てばよいか データ不整合が生じた場合、どのように リカバリ ーすればよいか 検証内容 ある機能を 2 つのサービス (図中の project-service と function-service ) として切り出す モノリシックなアプリケーションを、複数（社内での利用実績がない、あるいは少ない）の言語や フレームワーク を利用して分割することも技術検証の一環 あるリソースを新規登録する際に、従来 1 トランザクション で行っていた処理 ( SQL ) の一部を、今回切り出したサービスの API 呼び出しに置き換える データの整合性はリトライ処理で担保する 検証結果（得られた知見） サービスの分割は難しい 大前提としてサービスをまたぐ トランザクション が発生しないようにサービスを分割すべき 今回のように同一 トランザクション でデータ更新をしたい処理であれば、サービス同士が 疎結合 ではないということであり、そもそもサービス分割の粒度が正しくない可能性が高い ドメイン の知識が乏しい状態では適切な ドメイン 境界を認識することはきわめて難しい ドメイン の知識が増えた中盤になってから分割し直すことも、別の意味で難易度が高そう 自動テストなど品質担保の仕組みや、作り直しに対する組織の理解の度合いで実現可能性が大きく変わる 結果整合性の担保は難しい 今回のようにリトライ（有限回数）で整合性を担保する場合、すべて失敗する可能性もゼロではなく、最終的にログなどから手動 リカバリ ーできる仕組みを考えておく必要がある 今回は時間の都合で検証していないが、メッセージキューを利用したイベントソーシングな アーキテクチャ も検討したい 分散 トランザクション （二相コミットなど）の手法を使う選択肢もあるが、システムの複雑さや難易度が一気に増加しそうで現実的ではなさそう 最後に マイクロサービスの分割や結果整合性に関する知見は、情報としては世の中にありますが、実際に自分の手を動かして検証することで、改めてその課題感を実感するとともに、現実のサービス開発にマイクロサービス アーキテクチャ を適用する難しさも明らかになりました ラク スでは現在、 HR（人事労務）領域を対象した新サービスの開発 に取り組んでおり、この「かみせんプロジェクト」で得られた知見が現実のプロジェクトで活かされようとしています。例えば ラク スが提供する クラウド サービスとしては初めて全面的に クラウド ネイティブな アーキテクチャ を採用することが決定しました マイクロサービス アーキテクチャ の採用についても検討しましたが、今回経験したサービス分割の難しさから、まずはモノリシックな アーキテクチャ で最速でマーケットに参入するという選択をしました ラク スでは現状に満足せず開発の未来に先手を打っていける仲間、HRTech に興味があるエンジニアを募集しています！ www.wantedly.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 新卒2年目エンジニアのkasuke18です。 つい先日iOS12がリリースされました。リリースされた内容は数多くありますが、その中でも気になったのが「ショートカット」というアプリです。このアプリをうまく使えば iPhone 単体で API の実行が可能になります。実際に試してみましたので、紹介します。 もくじ はじめに 「ショートカット」アプリについて 作成したショートカット 内容 作成例 実行結果 おわりに 参考文献 付録：今回使用したアクション 「ショートカット」アプリについて リリースノート Shortcuts 2.0 release notes を見ると、「ショートカット」アプリはiOS12の以前に「Workflow」アプリとして公開されていたようです。 「ショートカット」アプリでは、 ビジュアルプログラミング言語 のように アクション と呼ばれる構成要素を組み合わせて1つのショートカットを作成します。アクションには iPhone端末の設定変更 や 他アプリの操作・データの受け渡し といったものが用意されているほか、変数・条件分岐・繰り返し（for, foreach）といった制御を行うものも用意されています。 作成したショートカット 内容 クリップボード に保存されている画像のリンクに対して OCR の API を実行し、画像内の文字をテキストに変換して出力する、ということをやってみました。今回使用した OCR の API は Free OCR API | OCR.space です。POSTパラメータやレスポンスの JSON 構成はリンク先でご確認ください。 作成例 まずはPOSTリク エス トを送信する部分です。 図1. POSTリク エス トの送信 今回POSTパラメータとして必要な情報は APIキー ・ 画像内の文字の言語 ・ base64エンコードされた画像 の３つです。このうち 画像内の文字の言語 は日本語で固定としているので、残り２つを取得する処理はサブルーチンとして別ショートカットに切り出し、それらを呼び出す方式をとっています。ではそれぞれのショートカットを見ていきます。   APIキー の取得処理です。 API キーは 環境変数 に持っておきたいのですが、さすがにそこまではできないようなので、今回は リマインダー アプリに保持・読み出すようにしています。 図2. API キーの取得 内容は API キーを保持している リマインダー を検索し、その中から今回使用する OCR.space というタイトルの項目から API キーを取得しています。 ショートカットの最後では、メインのショートカットに値を渡すため、変数から値を取り出して終了しています。   次に base64エンコードされた画像 の取得処理です。このパラメータに設定する値は data:image/[フォーマット],[base64エンコードされた画像] ですので、実際は 拡張子 と 画像をbase64エンコードしたテキスト の２つが必要になります。 まずは拡張子の取得処理です。 図3. 拡張子の取得 大きな流れとしては、まず クリップボード の内容がURL形式どうか確認し、URL形式ならその内容を取得します。さらにその内容がイメージであれば拡張子を、そうでなければ none というテキストを返却する、という処理を行っています。この none というテキストは、ショートカットを実行する側の処理で none を受け取り、エラーとして処理を終了するために利用します。 次が 画像をbase64エンコードしたテキスト の取得処理です。 図3. 画像を base64 エンコード したテキストの取得 これは 拡張子 の時とほぼ同じ処理の流れをしていて、 拡張子 を取得していたところを 画像をbase64エンコードしたテキスト を取得するように変更しただけです。   最後にメインのショートカットで 他のショートカットを実行する＆その結果を受け取る 処理と、 レスポンスJSONをパースする 処理を行います。 まずは 他のショートカットを実行＆その結果受け取る 処理です。 図4. 別ショートカットの実行 処理の流れは画像の通りです。ショートカットを実行し、その結果が拡張子ではないときは中断されたことを通知しショートカットを終了します。 続いて レスポンスJSONをパースする 処理です。 図5. レスポンス JSON のパース 「ショートカット」アプリ内では JSON は 辞書 という単語で扱われています。アクションとしては 辞書の値を取得 というもので、これは組み合わせればネストされた JSON のパースも可能です。また今回は結果出力のため、最後にメモに書きだすようにしています。 実行結果 以上のサンプルを、前回私が書いた記事の画像に対して実行した結果が以下となります。 図6. OCR で認識する画像 図7. 実行結果 おわりに 今まではちょっと API を試してみたいだけでもPCを用意する必要がありましたが、この「ショートカット」アプリを使用すれば iPhone 単体で簡単にできます。また今回は紹介していませんが、テキストに対して 正規表現 を用いたマッチングもできるので、 スクレイピング も可能です。 iPhone ユーザの方は試してみてはいかがでしょうか。 最後までご覧いただきありがとうございます。 参考文献 Shortcuts 2.0 release notes https://support.apple.com/en-us/HT209087 Free OCR API | OCR .space https://ocr.space/ocrapi 付録：今回使用したアクション アクション名とその使い方を以下にまとめました。 API 実行 URL URLを次のアクションに渡す URLの内容を取得 受け取ったURLをリス エス トし、レスポンスを次のアクションに渡す クリップボード をリク エス ト用に加工 クリップボード を取得 クリップボード の内容を次のアクションに渡す 種類を取得 受け取った値のデータ種類（イメージ・URLなど）のテキストを次のアクションに渡す Base64 エンコード 受け取った値を Base64 形式で エンコード ・デコードした値を次のアクションに渡す ファイルの詳細を取得 受け取った値（ファイル）の詳細（拡張子・サイズなど）を次のアクションに渡す JSON のパース 辞書の値を取得 受け取った JSON から指定したキーの値を次のアクションに渡す 制御 変数を設定 受け取った値を変数に代入する 受け取った値をそのまま次のアクションに渡す 変数に追加 受け取った値を変数に追加する（Listにappendするようなイメージ） 受け取った値をそのまま次のアクションに渡す 変数を取得 変数から値を取り出し、次のアクションに渡す 次の場合（if~else文） 受け取った値と指定した値を比較する（次と等しい・次を含む・より大きい・より小さい） それぞれで繰り返す（foreach文） 受け取ったリスト形式の値に対して１つずつ処理を行う ショートカットを実行 受け取った値を特定のショートカットに渡し、その実行結果を次のアクションに渡す（メソッドのようなイメージ） API キーを取得する リマインダーを検索 条件に合致するリマインダーを検索し、その結果を次のアクションに渡す リマインダーの詳細を取得 受け取った値（リマインダー）の詳細（メモ・タイトルなど）を次のアクションに渡す その他 テキスト 指定したテキストを次のアクションに渡す 通知を表示 タイトル・メッセージを指定し、その内容を通知として表示する メモを作成 受け取った値をメモに新規登録する "ショートカット"を終了 現在のショートカットを終了する 現在のショートカットに含まれる後続のアクションは実行しない エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは。 ラク スエンジニアのstrongWhiteです。今回は8月に 京都アジャイル勉強会 に行ってきましたのでレポートしようと思います。 アジャイル とは、要求仕様の決定や変更に対して、柔軟に対応するためのソフトウェア開発手法のことです。昨今有名になりつつある アジャイル ですが私としても興味がありましたので今回勉強会に参加してみました。 ※この記事では アジャイル に関する詳細な説明は省きます。 アジャイル ・ スクラム を初めて聞く方は馴染みのない用語が出てきますがご了承ください。 京都 アジャイル 勉強会とは アジャイル ・ スクラム を実践しようとしている（もしくは実践中の）人を対象とした勉強会で、自身（あるいは自社）が抱えている アジャイル ・ スクラム に関する疑問、不安などをざっくばらんに議論し、お互いに理解を深め合う会です。ちなみに私が行ってきたのは以下の勉強会です。 connpass.com 私の所属するチームでは アジャイル ・ スクラム を取り入れた開発をしているので、今回は アジャイル ・ スクラム を実践する中で私が抱えている疑問や不安を勉強会に参加されている皆さんにぶつけてみることにしました。 学んだこと ディスカッション形式の勉強会は初めてだったので新鮮でした。また、 アジャイル ・ スクラム に対する理解も少しながら進んだ気がしました。私としては日々 スクラム ・ アジャイル を実践する中で プロダクトバックログからスプリントバックログを出すまでに時間がかかり次のスプリントが始められない という課題を抱えていたのですが、今回の勉強会でとある方から「見切り発進的に次のスプリントを始めるのはよくないので、時間がかかってもいいから全てのスプリント バックログ を出してから次のスプリントをスタートすべき」という助言をいただき、少し勇気をもらえました。 終わりに 今回のようなディスカッション形式の勉強会は講義形式のお堅い感じは全くないので私としてもリラックスして受講できました。機会があればまた アジャイル ・ スクラム 系の勉強会に参加したいと思います。チームとしても私としてもまだまだ アジャイル ・ スクラム を始めたばかりなので、また疑問が出てきたらこういう勉強会の場で解消していこうと思います。 参考 アジャイル開発 京アジャ

こんにちは、MasaKuです。 ビッグデータ という言葉をよく目にしますが、その背後にある技術についてはあまり理解していませんでした。 そこで、 ビッグデータ を支える技術のひとつであるNoSQLについて興味が生まれたので、今回の記事では、NoSQLについて勉強した結果についてまとめようと思います。 （本記事の執筆には以下の書籍を参考にさせていただきました） NOSQLの基礎知識 ビッグデータを活かすデータベース技術 はじめに NoSQLとは RDBとの違い NoSQLに期待すること NoSQLのデータモデル キーバリュー型 カラム指向型 ドキュメント指向型 グラフ型 おわりに 参考文献 はじめに 現在、 Twitter は、１日あたり１０テラバイトを超えるデータを扱っているそうです。 10テラバイトというと、書籍一冊のデータ量（５０万文字）とすると書籍１０００万冊分に相当します。 モバイルデ バイス からも簡単にアクセスして写真や動画コンテンツを発信できる Webサービス が普及してきたことが ビッグデータ の発生の起因のひとつになったと言えるでしょう。 ビッグデータ の対応には3Vという以下のような特徴があります。 Volume（膨大な量） Velocity（速さ） Variery（多種多様） 今後、更にリッチな情報を扱う Webサービス が普及してくると、 ビッグデータ を処理する技術がますます重要になることから、NoSQLの技術発展が期待されます。 NoSQLとは PostgreSQL や MySQL などの RDB では対処しづらいような ビッグデータ に対応すべく生み出された技術で、 SQL を使用しないということが特徴です。 「Not Only SQL 」の略であり、「 SQL だけでなく、新しいデータベースの技術も利用する必要があるというムーブメントのことである」と多くの方に認識されています。 しかし、「NoSQLとはズバリこういうこと！」という定義についてはまだ明確化していないようです。 NoSQLとして代表的なものには、 Google の BigTable 、アマゾンの Amazon DynamoDB などがあります。 RDB との違い NoSQLと RDB との違いについて以下にまとめました。 機能は豊富ではない データの整合性が緩い 結果整合性でよいという考え NoSQLでは、 RDB で当たり前に利用できるJOIN（結合）が通常はサポートされていません。 また、同時実行制御（ 排他制御 ）を成立させる トランザクション の機能が緩められており、データの整合性よりも、大量のデータを素早く処理することを優先しているという特徴があります。 NoSQLと RDB の特性の違いを説明する上で重要な「 CAP定理 」という定理があります。 分散型データベースシステムにおける三大要件として以下が存在します。 Consistency（整合性）…常に同一のデータを参照する Availability（可用性）… 常に読み出しと書き込みができる Partition Tolerance（分断耐性）…ネットワークが分断されても間違った結果を引き起こさない 分散型データベースシステムでは、上記の3つのうち最大２つしか満たすことができない、というのがCAP定理です。 CAP定理 RDB にはACIDという特性が存在し、 トランザクション が信頼性をもって実行されるための必要条件を定義されています。 一方、BASEというものも存在し「アプリケーションは常時稼働し、常に整合性を保つ必要はないが結果的に整合性がとれる状態に至るという特性を備えているべき」という考え方があります。 CAP定理の提唱者であるEricBrewer氏は以下のように説明してます。 システムに整合性（C)と分断耐性（P）が求められる場合には、AICD特性を完備しなければならない。 だが、整合性（C）よりも可用性（A）と分断耐性（P）が求められるのであれば、そのシステムはBASEの特性を持つべきである。 RDB はCA（整合性と可用性）に分類され、ほとんどのNoSQLデータベースがCP（整合性と分断耐性）かAP（可用性と分断耐性）に分類されます。 RDB とNoSQLでは期待している性能が異なることから、NoSQLが RDB を完全に代替するものではないことがわかります。 NoSQLに期待すること NoSQL全般には以下のような要件を満たすことが期待されています。 一台のサーバには収容できないほど膨大なデータを扱う データを複数のサーバに分割して割り当てる 高価なハードウェア等ではなく、安価な汎用ハードウェアの上で稼働する データに紛失がなく、データは安全な状態に格納されている システム全体としては、いつでも使える状態にある 障害が発生しても短時間で復旧できる リアルタイムに近い応答性能を備えている また、データを高速に処理する上で、高度なデータベースチューニングの技術を必要としないことも特徴です。 データのサイズや形式が頻繁に変化するようなアプリケーションを RDB でデータを高速で処理し続けるためには、データベース設計に対する高い技術力を持ったエンジニアが常時対応しなければなりません。 これまでの RDB では十分な性能が得られなかったり、 RDB で実現しようとすると、構造が複雑になり、コストがかかりすぎるという問題を回避するための手段としてNoSQLが選択肢の一つとなりうることが期待されます。 NoSQLのデータモデル NoSQLには様々なデータモデルが存在します。 キーバリュー型 キーバリュー型 RDB のようなテーブルや関係性を定義せず、キーとバリューという組み合わせからなるシンプルなデータモデルです。 データが増えるにつれて表が縦の方向に伸びていくイメージです。 データモデルが単純であることからデータを容易に分割可能なことから、スケールアウトに最適なのが特徴です。 カラム指向型 カラム指向型 上記のキーバリュー型にカラムの概念を持たせたデータモデルです。 行に付与されたキーが複数のカラムを持つことができます。 カラム数は RDB のように固定ではなく、動的に追加していくことができます。 RDB を利用していると異質に思えるかもしれませんが、ほかの行には存在しないカラムを持つ行を作ることができます。 ドキュメント指向型 ドキュメント指向型 JSON や XML 形式で記述されたドキュメントの形でデータを管理することができます 各ドキュメントは階層構造を持たず、相互の関係を横並びに管理します。 RDB のように固定されたデータ設計が不要なことから「 スキーマ レスである」と言われます。 私はドキュメント指向型の説明を読んだ際、上記のカラム指向型との違いを明確に認識することができていませんでしたが、以下のようなものなのだと理解しました。 ドキュメント指向型の例 ブログの投稿履歴とメールの送信履歴をドキュメント指向型データベースに記録したとします。 これらは全く異なる性質のデータですが「投稿日と送信日が2018/9/18のデータ」と指定することで、関係するデータが取得できます。 このようなデータの性質が異なるものや、これまで取得していたデータの形式が唐突に変わってしまうような対象でも、ドキュメントの形式でデータベースに格納し、データを処理できるようにするのが オブジェクト指向 型のデータベースの特徴なのだと思いました。 グラフ型 グラフ型 データとデータ感のつながりを管理できるデータモデルです。 グラフ型のデータベースには以下の構成で表現されます。 ノード リレーションシップ プロパティ 例えば、 FaceBook の友達関係をグラフ型で表現すると以下のようになります。 Aさんというアカウントが存在します（ノード） AさんはBさんと関係があります（リレーションシップ） AさんとBさんは友達同士です（プロパティ） この基本構造を拡張していくと「Aさんの友達であるBさんの友達」や「Aさんと友達になってから3年以上経過したアカウント」といった検索も可能になります。 おわりに いかがでしたでしょうか。 筆者も、MongoDBというドキュメント指向型NoSQLを利用して簡単なWebアプリケーションを作ってみましたが、NoSQLについて調べて見ると様々なデータモデルが存在することがわかりました。 それぞれのデータモデルごとの強みが光るようなWebアプリケーションの特性についても今後調べていきたいと思いました。 参考文献 NOSQLの基礎知識ビッグデータを活かすデータベース技術 NoSQL - Wikipedia ブリュワーのCAP定理～データストレージの選定基準 - 浜村拓夫の世界 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

id:radiocat です。9/13に東京オフィスで開催したMeetupに登壇し「終わらない スクラム 」というタイトルで発表しました。今回のイベントを通じて、私たちが継続して スクラム に取り組んでいくうえでの様々な気づきを得ることができたので、それらを5つの学びとして記事にまとめてみました。ご参加頂いたみなさま、ありがとうございました。 rakus.connpass.com 発表の概要 発表の前半は私たちのチームが取り入れた アジャイル 開発のプ ラク ティスの説明で、今年3月の社内イベントで発表した内容がベースとなっています。それらの概要は以前のブログ記事にまとめていますのでご参照ください。 tech-blog.rakus.co.jp 発表の中盤からは開発を少しずつ アジャイル にし、やがて スクラム にチャレンジしていくために私たちが参考にした書籍やネット上の情報を紹介しました。そして後半部分では、現在のプロジェクトでも引き続き スクラム で開発を進めている中で新たに取り組んでいることを紹介しました。 speakerdeck.com 5つの学び 発表後の懇親会では参加者の方々からたくさんフィードバックを頂いて、それぞれの現場で実践している スクラム の取り組みなども教えていただき、とても有意義なイベントにすることができました。頂いたフィードバックも交えて、5つの学びをご紹介します。 1. 役割に徹することができる体制で スクラム を始める 私たちの スクラム チームではプロダクトオーナー（以下PO）をデザイン部門のメンバーが担っています。 その理由は大きく2つです。 開発チームは大阪、POのデザイン部門と ステークホルダー の事業部門は東京が拠点 BtoBのサービスであるため、デザイン部門はデザインの作り込みよりもUI/UXをしっかり検討することが求められる この話をした時に、「（上記の体制を書いた）スライドを見た時にそうだと思った」というフィードバックを頂きました。 スクラム チームの中で誰がPOや スクラム マスター（以下SM）を担当するかは スクラム に取り組むうえでの最初の難題の1つです。チームの中で誰がその役割を担えばその役割に徹することができるのかをしっかり問いかけて決める必要があります。 役割に徹することができない体制で スクラム を始めていたら恐らく失敗していました。世の中的に複数拠点やリモートワークを絡めたメンバー構成は当たり前となっていますし、それぞれの現場に合わせて最適な体制を考える必要があります。 ちなみに、今回の体制の場合は開発部門におけるリーダーという立場の私がSMを担うことがもう1つの課題になりました。 開発チームが機能するために組織としての役職が邪魔になることもあれば、うまく活用してチームを支援できることもあり、それらをうまく使い分けることも役割に徹するために必要なことです。 2. スプリントの期間は1週間がおすすめ 今回の発表で取り上げた開発プロジェクトでは2週間のスプリントで スクラム を始めましたが、現在はスプリントの期間を1週間にしています。 同様に1週間でスプリントを回している人から「1週間じゃないとスプリントを回すのは無理」というフィードバックをもらいました。大きな理由は以下の2点です。 スプリントの最初に2週間分のタスクを洗い出してプランニングするのが大変 2週間先の見込みを見極めるのが大変 私たちも慣れた今となっては1週間が最もやりやすく感じています。 チームの事情にもよりますが、スプリントの期間をどのくらいの長さにするかもまた スクラム に取り組む上での課題の1つです。私たちが最初にスプリントの期間を決めた当時は他のプロジェクトに稼働を使うメンバーもいたため2週間ぐらいがちょうど良いと判断しました。また、当時は1つのタスクの粒度を小さくする事に慣れておらず、1週間スプリントで大きな粒度のタスクの実行に想定外の時間がかかってしまうとあっという間にスプリントの終わりを迎えてしまう恐れも感じていました。しかし、今となっては1週間スプリントならうまくいかなくても改善して次に活かせば良いという感覚のほうが大きいです。 3. リファインメントと技術的スパイクの大切さと難しさ 次のスプリントに向けて バックログ を準備するリファインメントや技術的スパイクの活動は スクラム イベントとしては定義されていませんが、非常に重要でかつチームでルールを決めるのが難しい活動です。私達のチームではリファインメント会議をイベント化して強制的に時間を取るようにしています。 これについても同様にルールを決めて時間を取っているチームもあるというフィードバックを頂きました。やりかたはチームによっていろいろあるようでしたが、いずれにしてもプランニングまでに バックログ をきちんと準備できていなければ、スプリントはうまく回らないというのが共通の理解です。 ちなみに、現在私たちのチームでは1スプリントに2種類のリファインメント会議を実施しています。 開発チーム内リファインメント会議：技術的スパイクの状況確認や認識合わせが中心 スクラム チーム全体リファインメント会議： バックログ の整理と内容の認識合わせが中心 その理由は主に以下の3点です。 現在取り組んでいるプロジェクトの特性として技術面での不確定要素が多い 開発チームの人数が増えてきたため全体共有や認識合わせの場があったほうが進めやすい POと開発チームの拠点が別れているため時間を決めて実施したほうが進めやすい いずれも私たちのチームの事情によるものですが、これらを踏まえてリファインメントや技術的スパイクはそれぞれのチームでやりかたを考えて取り組む必要がある活動だと感じています。 4. チームの人数が増えるにつれて スクラム は難しくなる 私達のチームはメンバーが10人を超えたためスケールアウトを検討し始めています。 これに関連してチームのメンバーが9人いるという人からもフィードバックをもらいましたが、デイリー スクラム を時間どおりに終わらせるだけでも難しく、人数が増えると スクラム は難しくなると感じています。私たちのチームでも、スライドに書いてあるとおり スクラム ・オブ・ スクラム 、LeSS、 Nexus といった大規模 スクラム の事例を調査して検討をしていますが、事例自体があまり多くないのでまだ具体的な判断は下せていません。 ただ、スライドの下に書いてある「若手メンバーのミニ スクラム 」を試す期間で、一時的にメインのプロジェクトのメンバーを5人にしたところベロシティが上がってスプリントを以前よりうまく回せるようになったので、やはり5人ぐらいがちょうど良いという感覚も得ています。 5. チームの育成と成長は熱意を持って根気強く 上記の「若手メンバーのミニ スクラム 」や、以前このブログでも紹介した「 スクラム クイズ」に関しては良いフィードバックを頂きました。 チームのメンバーひとり一人がきちんと スクラム に向き合わなければ スクラム をうまく回すことが難しくなります。フィードバックの中でその点に課題を持っているチームの話もいくつか聞くことができましたが、チームの中で熱意をもって進められるメンバーがいないと スクラム を続けていくのは難しいと感じました。 我々もまだまだ試行錯誤しながら様々な取り組みを行っているところですが、そのためにも他のチームの事例や課題はとても参考になります。そういう意味で、今回のイベントではたくさんのフィードバックを頂き、私たち自身の新たな学びを得ることができました。 この学びをまたチームに持ち帰ってさらに スクラム を前進させていきたいです。 スクラム の習得はまだまだ終わりそうにありません。 今回のイベントをきっかけに当ブログに「終わらない スクラム 」というカテゴリを作りました。今後も スクラム の取り組みで得たことを随時発信していきたいと考えていますので、引き続きチェックして頂けますと幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com