ユビレジのMeetupを開催しました
こんにちは！今日はとっても寒くてびっくりです。
Ubiregi Advent Calendar 2018 10日目の記事です。
先日、ユビレジのオフィスでとあるMeetupが開催されました。
今日はその様子をお伝えしたいと思います。
明日会社楽しみすぎる
— かとりえ (@katorie) 2018年12月3日
前日、私はわくわくしすぎてました。
なぜならMeetupのメンバーがとにかく豪華すぎたからです！！
こちらがその紹介スライドになります。（弊社 @watson1978 作成）
お昼過ぎにお集まりいただきましたので、ドーナツとコーヒーでゆるりとはじまりました。
事前に特にお題などは決めていなかったのですが、みなさん素敵なお仕事をされている方ばかりですので、最近のお仕事の話などをうかがっているだけでどんどん盛り上がりました。
合同会社フィヨルドの町田さんからご紹介いただいたのは、株式会社永和システムマネジメントの新サービスLinkup
ホワイトボード機能などを実際に触ってみました！
楽しい！
今後開発される予定の機能を聞いちゃってテンションあがるユビレジ開発チーム。
esaはグッズも可愛いですよね！
途中、pplogの話もしたり…
弊社の研修でも愛用させていただいております、ご存知「わかばちゃんと学ぶ Git使い方入門」の著者、湊川あいさんからは esa + GitHub でブログを更新していらっしゃる話をうかがいました。
しかもMeetup当日にブログ記事も投稿してくださいました…！！
さすが、お仕事はやい！！
角谷さんは「アジャイルサムライ−達人開発者への道−」を監訳されたり、RubyKaigiのシニアオーガナイザーをされたりしている、とにかく凄い人（語彙すみません）
私もRubyを勉強はじめたときに参考図書を相談させてもらったりと大変お世話になりましたし、今でも時折ハッとさせられるアドバイスをご教示くださる師匠のような存在です。
そして、弊社のサービスのひとつ FlickOrder のデザインを担当してくださった前田さん。
開発スタートする前の出会いの話をうかがったり、現在お勤めの株式会社Misocaさんでの開発スタイルの話をうかがったり、個人的にはうかがってみたかった話が聞けてとてもおもしろかったです！
他にも話は尽きなかったのですが…
最後に湊川さんにちゃっかりサインをいただいて、会はおひらきになりました。
たまにこんな素敵な方々が遊びにいらっしゃる株式会社ユビレジに興味をもたれたら、ぜひご連絡ください！
第1回ユビテック「ユビレジアプリの起動処理のリファクタリング」
Ubiregi Advent Calendar 2018 4日目です。
今日は社内でユビテックという勉強会を開催した報告記事です。
ユビテックとは
初日の「ユビレジ開発チームのご紹介」で登場していましたが、
古参メンバーから新規メンバーへ伝授したい技術的内容や、最近仕入れた新しい技術の話など、話したい人が話す時間を2週間に1回設けることにしました。
定例開催するにあたり、「名前何がいいかな 🤔」といったら
リライアビリティチーム 八十嶋 「ユビテックとかどうですか」
スクラムチーム Watson「ユビテックでいいんじゃない」
ということで、そのまま決めました 🎉
記念すべき第1回はユビレジiOS開発の重鎮 八十嶋による「ユビレジアプリの起動処理のリファクタリング」でした。
背景
ユビレジアプリは機能豊富でとっても便利なPOSレジですが、開発開始から7年ほど経っており、それなりに問題も抱えています。
開発あるあるだと思うのですが、長く開発を続けているとどうしてもコードが複雑化したり、依存関係が出てきます。
そこで、この秋くらいから八十嶋は起動処理のリファクタリングに取り組んでいていたのですが、
PRをレビューできる人が少ないという問題があり、開発部全体で知見を共有し、レビューできる人を増やそうということになりました。
問題の共有
ユビレジアプリが起動したときに一番初めに表示される RootViewController がいわゆる Fat View Controller になっていて、様々な処理が書かれています。
RootViewController の `viewDidAppear` に起動処理がつめこまれているので、この部分のリファクタリングが必要であるということでした。
ちなみに私は「起動処理を`viewDidAppear` でやるべきなんですか」という質問をしましたが、八十嶋は「やらざるを得ない」という説明を丁寧にしてくれました。
（もっと混みいった内容については本人の記事へつながるはず…！！）
今後の展望
まずは ViewController に書かれているロジック部分を別のクラスに移動して、
ステートマシンで状態管理ができるようにしたい、とのことです。
状態管理については、八十嶋謹製の FlowGraph を使う予定です。
詳しくは iOSDC 2018 で八十嶋が発表した「Swiftのコードから状態遷移図を自動で生成し、継続的にメンテナンスしやすくする」のスライドをご覧ください！
ユビレジアプリの既存コードはほとんどが Objective-C で書かれていますが、このリファクタリングは Swift で書かれています。
このリファクタリングによって、より安全に機能拡張のしやすいコードになり、新機能開発が爆速になること間違いなしですね 💪
ユビレジ開発チームのご紹介
こんにちは！ @katorie です。
これは Ubiregi Advent Calendar 2018 1日目の記事です。
初日はかんたんに、株式会社ユビレジの開発チームってどんな編成でどんなことしているのかな？というのをお伝えしたいなと思っています。
ユビレジでは現在、主に3つのプロダクトを開発・運用していますが、組織のなかでは開発部門はひとつで、開発部全員で全プロダクトをみています。
開発部は4つのチームに分かれています
（2018年12月現在）
- スクラムチーム
- リライアビリティチーム
- 新規サービス（仮）チーム
- コーポレートエンジニアリングチーム
業務内容は新機能の開発や、各プロダクトの運用・保守など多岐にわたります。
2週間スプリントのスクラム開発を行なっています。
CSからエスカレされる事項（インシデントと呼んでいます）の対応も主にスクラムチームで行います。
リライアビリティチームは
いわゆる「SRE（Site Reliability Engineering）」に取り組んだり、
コードのリファクタリングに取り組んだり、
ユビレジ全体の品質を向上していくための取り組みについて考えるチームです。
新規サービス（仮）チームはまだ新規サービスの名前が公表できないので（仮）としています！
年明けのリリースに向けて鋭意製作中で、技術的にもいろいろとチャレンジしているので、そういったことも今後公開していけるといいなと考えています。
コーポレートエンジニアリングチームは社内システムの開発・運用をしています。
一応、目的に合わせてチームを編成し、チームごとにOKRがありますが、
2つのチームを掛け持ちしているメンバーもいたりします。
チームを横断した取り組み
現在は全体でも20人に満たない規模ですが、だんだんメンバー全員が何をしているのか把握しづらくなってきたので、いろんな工夫をしながらコミュニケーションをはかっています。
- デイリースタンドアップ
いわゆる朝会は今のところ全員参加しています。
インシデントの内容や対応の現状を共有したり、
勤怠などのアナウンス、
昨日のデイリー後から今日のデイリー前までにやったことの共有などをしています。
必要があればチームに分かれて、さらにコミュニケーションをとりますが、
基本的には15分くらいで終わるようにしています。
- ユビテック
これはまだ始まったばかりの取り組みなのですが、
古参メンバーから新規メンバーへ伝授したい技術的内容や
最近仕入れた新しい技術の話など
話したい人が話す時間を2週間に1回設けることにしました。
第1回は「ユビレジアプリの起動処理のリファクタリングについて」だったので、その内容も別記事で公開したいと思っています！
次回は「ServerSide Swift」の予感… 楽しみです！！
- スプリントSUSHI
毎スプリント必ずやっているわけではないのですが…
スプリントの終わりに「お疲れ様！」という気持ちでみんなで乾杯する会です。
SUSHI は概念であり、寿司に限っておらず、毎回みんなが食べたいものをみんなで食べます。（メニューを決める人の好みに走りがち）
夜に開催されることもありますが、ランチの時間を利用して開催されることもあります。
まとめ
ユビレジの開発チームってどんなことしているのか、雰囲気が伝わるAdvent Calendarにしたいなと思っています。
なのでまずはじめに開発チームがどんな編成なのか概要を書いてみました。
「ここをもっと詳しく知りたい！」とか「こんな時どうしているの？」などツッコミ歓迎です。
今日は技術的な内容がなくてすみません。。
2日目の記事は @watson1978 なので期待！！
2018年第1回 よちよち(の心をずっと忘れない).rb
雑なメモ（私個人の主観が混じっています）
- よちよち.rb を再開したい声があがって既存メンバーが集まった
- おいしいごはんとビールを飲みながら、私たちにできることは何か、私たちがしたいことは何か、語り合った
- 初心者にとってのコミュニティについて考えた
- 心理的安全性について考えた
- 私が感じているよちよち.rb への感謝の気持ちとかコミュニティの素晴らしさとか、同じ思いでいる人たちが集まっていることを再確認した
- 平日夜のミートアップを再開していこうという方向に固まった（やり方は然るべき場所から然るべき方法で告知されるのでここでは割愛）
- 私は平日夜のミートアップに定期的に参加するのは難しいので、スピンオフ的に何かしようと思った（できる時に、できる範囲で、できることをする）
- よちよち.rb に通っていたときのこと、プログラミングを勉強し始めたときのことを思い出して背筋がのびた
Ikejiri.rb 活動報告
2017年3月より、 @risacan と Ikejiri.rb として週に1度のペースで1時間ほど読書会をしていて、先日の第14回をもって「オブジェクト指向設計実践ガイド」を読み終えました。
Ikejiri.rb
現在育休中で、なかなかPCを触る時間が作れず毎日が過ぎ去っていきます。
出産後すぐは、昼夜関係なく子供の様子に気を配り世話をしているうちにあっという間に1日が終わる、の繰り返しに、
それまでの生活からの変化があまりにも大きくて、ずーっと焦りを抱えていました。
そんなときRailsGirlsで知り合った @risacan が近所でお仕事していると知り、コンタクトをとりました。
「なんかしたい！けど昼間しか動けない！」という私のわがままから、
週に一度ランチの時間を利用して読書会をすることになりました。
基本的に金曜日が活動日です。
進め方
1回ごとに GitHub Issue をたてて、読む範囲を決め、
ミートアップ開始までに読み終わった宣言や気になったところをコメントしておきます。
1冊目は「オブジェクト指向設計実践ガイド」
オブジェクト指向設計実践ガイド ?Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
- 作者: Sandi Metz
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/02
- メディア: Kindle版
- この商品を含むブログ (6件) を見る
だいたい1回につき1章くらいのペースを目標にしていましたが、
つまづいたところはもう1週追加したり、最後の第9章はあらかじめ分割したり、
その都度ふたりで相談して進めていました。
よいところ
あらかじめ気になったところをコメントしておくので、すんなり始められるし、相談できる。
ランチでエネルギーを補給してから話すので、元気。（たまにランチが来るまでの間に集中してしまうこともあったけど）
ふたりなのでコミュニケーションコストが抑えられる。
わるいかもしれないところ
ふたりなので、読んだことについて考えたことが偏っているかもしれない。
→なるべくコメント欄にのこして、他の人の目に触れるようにしておく。Twitterで発言する。
…他に思いつきません。
これから
来週から2冊目（「なっとく！アルゴリズム」になった）に入るのでこの調子でどんどん読む！
あと1冊目の感想とかをちゃんとまとめておきたい。
わたしとRails Girls
これはRails Girls Japan Advent Calendar 2016 の2日目の記事です。
1日目はattsumiさんでした。
Tokyo 7th 開催予告がされていましたね！すごく楽しみです。
思い出話をします
こんにちは、katorie といいます。
私は Rails Girls Tokyo 2nd の卒業生です。
Tokyo 2nd は 2013年3月1・2日に開催されたので、もう3年と9ヶ月も前の話です。
#railsgirlstokyo RailsGirlsTokyo 2nd に参加しました - プログラミングお勉強記録
私の人生は、Rails Girls に参加したことで大きく方向転換しました。
この話は、たまにどこかで話していたことなのでご存知の方もいらっしゃいますが、あらためてブログに残しておきたいと思います。
（Advent Calendar の2日目にふさわしい内容なのかはさておき）
現在の話をすると、2015年1月より株式会社ユビレジ にソフトウェアエンジニアとして所属しています。（正確には出産を控えており、休職中）
その前は6年9ヶ月ほど、医療機器メーカーで事務をしていました。
それでは、私の思い出話におつきあいください。
参加する前
上述のとおり、私は医療機器メーカーで外回りをしている営業さんたちのサポート業務をしていました。
10名くらいいた本社の営業さんたちのスケジュールを把握したり、電話連絡を取り次いだり、展示会や勉強会という名の営業活動の準備（資料やお弁当など）をしたり、まぁ、何でも屋さんでした。
使用するツールは電話と、メールと、Microsoft Office。
属人的な仕事が多かったことに不満をもっていました。
あるとき、毎朝手作業で行っていたスケジュール表の作成や営業さんへ送信するメール作成に嫌気が差し、どうにかならんものかと思っていたところ、
自分でプログラムを組んで自動化するという魔法のような解決策があることを知りました。
いろいろググってプログラミング言語が複数存在することを知りましたが、最初に読んだ本がこれだったので、はじめて書いた言語は Ruby でした。
- 作者: Chris Pine,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/09/21
- メディア: 大型本
- 購入: 5人 クリック: 311回
- この商品を含むブログ (18件) を見る
やがて Ruby を書くことをお仕事にしている方々がいることを知り、Twitter で生態研究をしているうちに、Rails Girls の存在を知りました。
ひとりで書籍と格闘していた私は、仲間ができることを期待して、参加することにしました。
たしか応募動機とかに「さみしいので仲間がほしい」とか書いた気がします。
当日の出会い
Rails Girls の内容としては（各回それぞれ若干違いはあるかもしれませんが）、
初日の夜にインストール・デイがあって環境構築をして、翌日はグループに分かれてチュートリアルに挑戦します。
このグループ分けは事前にオーガナイザーが済ませていて、事前アンケートから知り得るだいたいの経験値や当日使用するOSなどで分かれていたようです。
初めて触れる「プログラマの世界」にドキドキしながら、指定されたグループの席に着きました。
私の参加したグループは、Girls 4人に対し、コーチが2人ついていて、「無料のイベントなのに手厚いなー」と思ったのを覚えています。
その時のコーチが @a_matsuda さん 、そして一緒のグループに @Yuryu さん がいました。
他のグループのコーチたちもそうそうたるメンバーだし、途中、@_ko1 さん による解説（たしかローカル変数とインスタンス変数についてだった気がする）もあったりして、すごい豪華な一日だったのですが、正直言うと当時はそこまで凄さがわかっていなく、「皆さんやさしくわかるまで教えてくれるとても優しい人たち」くらいの認識でした。すみません。
あるいはそれまで生態研究をしていたアカウントの皆様の実在確認をしていたというか…すみません、すみません。
その後
そんな豪華な出会いがあったわけですが、私としては当時この Rails Girls で実在確認をしたアカウントの皆様だけが「私の知っている Rubyist」でしたので、
皆様の発信する情報だけを頼りに、大江戸Ruby会議や RubyKaigi などに参加していました。
少しずつ慣れてきて、いろんな勉強会やmeetupに参加できるようになり、いくつか大変お世話になったコミュニティがあります。
そのひとつが、Rails Girls, more! という卒業生（と本編に参加できなかった方）のための勉強会。
右も左もわからない、けど作りたいものはある、みたいな私のような困った人を、毎回コーチが一人ついて丁寧に教えてくださいました。
（現在の活動については Facebook グループで確認いただくとよさそう）
それから、同じく Rails Girls Tokyo 2nd の卒業生 @yucao24hours さん がオーガナイザーのよちよち.rb。
そして「実際にプロダクションとして動いているコードを見てみたい！」という動機で参加させていただいた、合同会社フィヨルドさん のインターンシップ。
他にもたくさんの方々にお世話になりながらプログラミングを続けていくうちに、現在所属しているユビレジを知りました。
@Yuryu さんに誘われて参加した GitHub Drinkup で、 @a_matsuda さんが @soutaro さんを紹介してくださったのです。
（実際にユビレジに入社することになったのは、この Drinkup のずーっと後でしたが）
よちよち.rb 第111回 #yochiyochirb
ちょっと間があいてしまったのですが、思い出しながら参加記録をつけます。
最近のよちよち.rbは、Railsをつかったチーム開発をしています。
2年前くらいに有志で作成したアプリ「Kajaeru」の開発です。
ミートアップではissueからひとつ選んで、エクストリームフィッシュボール形式で開発を進める、という流れ。
この日はこちらのissueに取り組みました。
bootstrapをいれたことでヘッダーにサインイン状態などが表示されるようになったのですが、
依然としてbodyにサインイン名（サインインしていればサインアウトへのリンク）やそれに関連するメッセージが表示されたままでした。
というわけで重複している項目を削除していく、というのが主な作業となります。
実装しはじめたとき、視点が「サインアウトへのリンク」にいってしまったため、
ブランチ名が delete-signout-link となっていたのですが、よくよく見るとサインアウトへのリンク以外にも削除するべきところはありそう。
なのでブランチ名はひとまず置いておいて、「このissueに対応するブランチ」として作業をすすめて、
ひとつのプルリクエストとして完了させたほうがいいということになりました。
こういうことっておそらく実際の業務の中でもあって（少なくとも私は）
ひとつの問題を修正するときに、いきなり思いつくところから作業にはいると、
途中で「あーもっとこうするべきだったー」と思い直して手戻りしたりするので、
ゴールとそこにたどり着くまでの道筋を立ててから作業に入ると、
ブランチ名のつけ方やコミットの粒度などに困らないのだろうなぁと思います。
いい勉強になりました。
