こんにちは。実は ラク ス大阪ビアバッシュ実行委員の、Y-Kanohです。 先日、毎月恒例のビアバッシュ@大阪を行いました。 今回のテーマは、「 他部署のお仕事紹介 」。 いつもは技術系の発表ばかりのビアバッシュに、他部署の方をお招きし、それぞれのお仕事内容を発表していただく、毎年恒例の人気企画です。 今回も内容をダイジェストでご紹介いたします。 営業のお仕事 まず、配配メールの営業担当に発表頂きました！ ネット申し込みなどが普及し、システムを売るために、人手が必ずしも必要でない中における、営業の存在意義を教えていただきました。 お客様の困っていることを解決するためにも、 人それぞれに違うシステムに対する価値観を、いかに高めて紹介するかが腕の見せ所だそうです。 また、営業担当としてプレゼン時に心がけているテクニックも教えていただきました。 ネットワーク純情派 つぎに、365日インフラを守っているインフラ部隊、「ネットワークチーム」からの発表です。 ログ調査から障害対応まで、幅広い業務内容についての話から、 日々取り組んでいる、サービス品質向上のために行っているプロジェクト活動についての話などを伺いました。 （表紙のデザインがシブいですね。） 情シスの業務紹介 多数の業務内容を抱えている情報システム部からも発表頂きました。 業務内容は多岐にわたり、比較的馴染みのあるPC管理や、問い合わせ対応から、 あまり表に見えない、社内システムの基盤整理、セキュリティ対策、新しいITサービスの導入などについてお話しいただきました。 また、実際に最近社内へ導入された、業務効率化のための Bot システムの紹介もしていただきました。 これからも、 ラク スグループで働く人（： ラク ト）のために、より良いIT環境をサポートして下さるそうです。 サポートお仕事紹介 楽楽精算の顧客サポートを行っている、大阪サポート課からの発表です。 顧客サポートの中でも、導入支援を専門に行っているチームです。 せっかく導入したシステムを最大限利用してもらうため、2か月間の専属サポートを行い、 できるだけ長く使っていただけるよう工夫しているそうです。 技術発表 いつも通りの技術系発表も行いました。 OSS の開発にJOINした話 OSS の開発にJOINした経験から、仕事や開発における積極的な行動の意義を教えていただきました。 フェリー ハッカソン 参加報告 先日、 こちらの記事 で紹介された、フェリー ハッカソン のレポートです。 記事には載らなかった内容まで、写真を交えて発表していただきました。 また、最後にはLTでの発表も行いました。 いつもはエンジニアばかりのビアバッシュですが、今回はエンジニア以外の方も巻き込んで、いつもとは違うビアバッシュを行うことができました。 毎年行っている企画ですが、毎回新しい発見や知らなかった情報が出てくるため、ぜひ今後も続けたいです。 以上、大阪開発ビアバッシュレポートでした。

いろ いろ なところでネタになっている開発エンジニアの坂田です。 以前の投稿 で周知されました通り、先日開催されたLaravel JP Conference 2019に登壇してまいりました。これも以前の投稿で触れていましたが、株式会社 ラク スは BRONZE スポンサーとしてイベントに協賛しました。 イベント概要 日時 : 2019 年 2 月 16 日 (土) 会場 : グランパークカンファレンス 公式 HP : https://conference2019.laravel.jp/ ハッシュタグ ： #laraveljpcon conference2019.laravel.jp 登壇 チャットディーラーの高速開発を支える Laravel（30分セッション） speakerdeck.com 昨年の PHP カンファレンス関西 2018 で発表 した内容から資料を修正して再演しました。 感想 個人的にはあまり満足のいく発表が出来なかったなというのが正直な感想です。 マイクを持ってしゃべればよかった 発表中、聞いてくれている人たちをあまり見れていなかった（話に興味を持ってくれているか不安になった） 時間を余らせてしまった 登壇力が足りない ただ良かったこともありました。 「Mustache Injectionという言葉を流行らせたいので覚えて帰ってください」がちょっとうけてた Mustache Injectionについてつぶやいてくれている人がいた mustache injectionという言葉を覚えて帰ってください。 #laraveljpcon #laraveljpcon3F — なずな🌱 (@akaa07_pg) 2019年2月16日 mustache injection 簡単に起こせますな！！怖い。。。 #laraveljpcon #laraveljpcon3F — KamiyaKizuku (@kizu19911020) 2019年2月16日 mustache injection こわい #laraveljpcon #laraveljpcon3F — 青ごへいもち (@blue_goheimochi) 2019年2月16日 これからLaravel＋Vueで開発する予定だったから XSS 対策の話聞けてよかった。知らなかったらやっちゃう、mustache injection。 #laraveljpcon3f — よだか (@engineerYodaka) 2019年2月16日 やはり 脆弱性 に関する話題は関心をひきやすいのだなという印象です。 Mustache Injectionに関して参考 Mustache Injectionに興味を持ってくださった方向けに参考情報を載せておきます。 https://laravel-news.com/laravel-5-6-9 https://medium.com/@taylorotwell/js-frameworks-server-side-rendering-and-xss-722805009892 https://github.com/dotboris/vuejs-serverside-template-xss

Y-Kanohです。 先日、弊社がスポンサーとなっている、Laravel JP Conference 2019 のライトニング トーク に登壇してきました。 イベント概要 こちらの記事で紹介いただいたイベントです。 tech-blog.rakus.co.jp 日時 : 2019 年 2 月 16 日 (土) 会場 : グランパークカンファレンス 公式 HP : https://conference2019.laravel.jp/ Laravel JP Conference は、今回が初めての開催です。 （このような登壇イベントでの発表は初めてでしたが、まさかのトリの発表でした...） 発表資料 発表時の資料はこちらです。 speakerdeck.com 資料作成前は、基本機能の紹介等をクイズ形式で面白おかしくできたらと思いましたが、 実際はもろもろの事情により GitHub のコードから非常にコアな問題を出題することにしました。 感想 思ったより受け入れられて、とても楽しかったです。少しネタ寄りの発表でしたが、 コードを読まないとわからない内容だったため、聞き手の方もクイズを楽しんでいただけたようで、 発表後の懇親会では「Laravel クイズの発表者です」というと、「1問しか正解できませんでした」とか、「Laravel の内部って面白いですね」など、様々な反響をいただけました。 ちょうど、他のセッションで「何らかの形で少しでもアウトプットを行うことが成長への近道」といった話がありました。 私も、今回の登壇を機に、ブログや登壇といったアウトプットの機会を増やせればと思います。

初めまして、新卒エンジニアのEngawaです。 今回は iphoneアプリ 作成で使っている Monaca についてかなり簡単に紹介させていただきます。 Monacaとは 統合開発環境(IDE) デバッガー おわりに Monaca とは アシアル株式会社様が提供しているハイブリッドアプリ作成の開発プラットフォームです。 統合開発環境 ( IDE )とデバッガーなどの機能を提供しています。 統合開発環境 ( IDE ) Monaca では クラウドIDE という IDE が用意されています。 名前の通り クラウド 上のあるためローカルで面倒な環境設定を行わなくても、会員登録さえすればどの端末でもブラウザ経由ですぐに開発ができます。 実際の編集画面はこんな感じです。 普段から eclipse を使っており、 Monaca の開発画面の見た目はほとんど同じだったので大まかな扱い方はすぐに理解できました。 実行結果も上図の右側の部分にあるのですぐに確認できます。 また、 Monaca が提供しているデバッガーを使用すれば スマートフォン でも実行結果を確認することもできます。 デバッガー 上にも記載したのですが、動作確認する時は Monacaデバッガー という デバッグ 用のツールを使えば スマートフォン で動作の確認をすることができます。 アプリ自体は普通に App Store 、 Google play で無料でインストールできます。 アプリのインストールが完了したら、アプリを立ち上げてログインし、作成したプロジェクトを選択するだけで簡単に確認することができます。 デバッガーの画面はこんな感じです。(作成したプロジェクト一覧(左)と実行結果(右)をくっつけてます) おわりに 今回は、 Monaca についてかなり簡単に紹介させていただきました。 面倒な環境設定をしなくて済む上、様々なテンプレートが用意されているので手軽に アプリ開発 を行いたい方にはオススメします。 Monaca に関しての詳しい記事は こちら にもあります。 参考サイト： https://www.asial.co.jp/business/mobile/ https://ja.monaca.io/features/

メールディーラー開発エンジニアの@neroblubrosです。「フェリー ハッカソン に行ってくる」というブログを前回書きましたが、実際に行ってきたことを書きます。 前回書いたブログの記事 tech-blog.rakus.co.jp 若手社員と一緒に参加しました 前回のフェリー ハッカソン には私ひとりで参加しましたが、今回はなんと若手社員のふたりも参加することになり、 ラク スからは合計3名でフェリーに乗り込みました！ 若手社員が書いた参加レポートはこちら MasaKu tech-blog.rakus.co.jp Y-Kanoh tech-blog.rakus.co.jp フェリー ハッカソン に限らず、私はいままでいくつかの ハッカソン に参加してきましたが、今回のフェリー ハッカソン はプレイヤーではなく、スタッフとして参加しました。 スタッフの中でもプレイヤーのみなさんをサポートする「メンター」です。 どこまでサポートするか？で迷いました メンターのお仕事は前述のとおりプレーヤーのサポートです。具体的には下記のとおりです。 各チームのア イデア をどうやって実現すればいいか？の提案 API の使い方などのサポート 時間が足りない！ときの助っ人 実際のところ、1と2はあまりありませんでしたが、2日目に進捗が遅れているチームが発生したので、そのチームに助っ人に入ってサポートをしました。 チームの助っ人を始めると「どこまで手伝うか？口出しをするか」ということに苦慮しました。 チームそれぞれの思いや考えがあるため、コンセプトといった成果の根幹に関わる部分に口出しはできません。そういう意味でメンターは受け身です。 その反面、チームメンバーは猫の手も借りたい状態なので「もっと手伝ってほしい」「いろいろ意見を言ってほしい」とメンターに求める気持ちも理解できます。 また、私自身「こうしたらいいのに」「こっちのほうが絶対いい！」という意見もあり、それをチームに伝えるか伝えないかで迷いましたし、「メンターが言うのだから」とある意味チームメンバーの方が気を使うことも恐れました。 この点がメンターをするにあたり難しいと感じたことです。 他のメンターと相談しながらサポートし、結果的にお願いされたこと以上のことはしない、聞かれたこと以外のことは答えないことにしました。 ですので、恐らくサポートしたチームメンバーの方々は物足りなく感じたと思います。 ハッカソン は自分ができることと足りないことを教えてくれる 最後に、私が ハッカソン に参加する目的について書いてこの記事を終わりにします。 私が ハッカソン に参加するのは「自分ができることと足りないこと」がわかるからです。 技術的な知識やスキルももちろん大切なのですが、 ハッカソン はごくわずかな時間の中で成果を出す必要があるので チームのタスクを効率よく処理するにはどうすればいいか 突発的に発生した問題にどう対処すればいいか 成果を審査員に理解してもらうにはどういう発表をすればいいか と言ったモノの考え方やチームの進め方がより大事だと私は考えています。 そして「自分のやり方は正しかったか？」「考え方は間違っていなかったか？」ということを ハッカソン 終了後に自問自答することで、自分が通用したところ、しなかったところ再確認できる。 だから私は ハッカソン に参加しています。 こういったことは一方通行の セミ ナーでは体験することができません( セミ ナーがダメだと言っているのではありません)。 今回は迷うところがありましたが、フェリー ハッカソン にメンターとして参加したことはとても勉強になりました。 みなさんも ハッカソン に参加しませんか？ ＃そうだ ハッカソン に行こう！

はじめまして、新卒1年目のエンジニアの id:aa_crying です。 今回はブログ運営でも使っている Google アナリティクスと、 UTMパラメータについて調べてみましたので、紹介させていただきます。 Googleアナリティクスとは UTMパラメータとは 実際にパラメータ付きURLを作成する アクセスして、結果を確認する まとめ Google アナリティクスとは Google アナリティクスとは、 Google アカウントの作成後、「 Google アナリティクスに申し込み」を行うだけで利用できるフリーの アクセス解析 ツールです。 申し込みをすると「新しいアカウント」作成画面に遷移するので、必要項目の入力後、ト ラッキング IDを取得できます。 このト ラッキング IDをサイトに埋め込むことで、 Google アナリティクスでサイトのアクセス計測が可能になります。 UTMパラメータとは UTMパラメータとは、プロモーション広告やバナー広告、メルマガなどの効果を計測するために設定するパラメータのことです。 Google アナリティクスでは カスタムキャンペーン と呼ばれています。 UTMパラメータには、以下のような種類があります。 パラメータ 説明 utm_source プロパティに トラフィック を誘導した広告主、サイト、出版物、その他を識別します utm_medium 広告メディアや マーケティング メディアを識別します utm_campaign 商品のキャンペーン名、テーマ、プロモーションコードなどを指定します utm_term 有料検索向けキーワードを特定します utm_content 似通ったコンテンツや同じ広告内のリンクを区別するために使用します *1 よく使われるのは utm_source , utm_medium です。 utm_source の部分を サイト名 にすることで、どこのサイトから 流入 したかを簡単に区別することができます。 実際にパラメータ付きURLを作成する パラメータ付きURLは以下のサイトで簡単に作成ができます。 https://ga-dev-tools.appspot.com/campaign-url-builder/ 今回は、 utm_source=mattermost , utm_medium=social でURLを作成します。 計測対象のURLと、それらの情報を入力すると、下の Share the generated campaign URL の欄にURLが作成されます。 UTMパラメータの作成 アクセスして、結果を確認する 実際に作成したURLからアクセスしてみます。 https://aa-crying.hatenablog.com/entry/20190206/tameshi1?utm_source=mattermost&utm_medium=social その結果を Google アナリティクスから確認します。 結果は、 リアルタイム > トラフィック から確認することができます。 Google アナリティクスでの確認結果 先ほど設定した utm_source の内容が ソース に、 utm_medium の内容が メディア に表示されていれば正しく計測が出来ています。 まとめ 今回は、 Google アナリティクスの初歩である、UTMパラメータ(カスタムキャンペーン)の扱いについてご紹介しました。 今回お見せした部分は Google アナリティクスの機能のほんの一部であり、他にも様々な機能があります。 誰でも気軽に、簡単にアクセス計測が出来ますので、興味のある方はぜひ活用してみてください。 参考サイト https://support.google.com/analytics/answer/1033863#parameters https://seolaboratory.jp/59695/#p01c エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : たとえば、メールのメッセージに行動を促すフレーズのリンクが 2 つある場合は、utm_content を使用して別々の値を設定し、どちらが効果的か判断できます。

id:radiocat です。年度末（弊社は3月です）が近づいてきました。私の所属するチームにとって2018年度は本格的に スクラム に取り組んだ1年でした。その締めくくりとして大きなイベントに登壇させて頂くことになりました。せっかく頂いた機会なのでしっかり振り返って我々の取り組みをお伝えしたいと思います。ぜひご参加ください。 Scrum Fest Osaka 2019（2/22〜23） www.scrumosaka.org 『あきらめない スクラム 』というタイトルで2/23に登壇予定です。 https://confengine.com/scrum-fest-osaka-2019/proposal/8554/- confengine.com 残念ながら採択されなかった Regional Scrum Gathering® Tokyo 2019 向けの発表テーマでしたが、大阪でも新たにScrum Festというイベントが立ち上がると聞いて改めてCfPに応募し採択して頂きました。もともと私たちは大阪拠点の開発チームなので、大阪開催のイベントで大阪のチームの取り組みを紹介できるのは非常に嬉しいことです。 この1年を大きく3段階の取り組みに分けてご紹介します。 はじめる闘い つづける闘い あきらめない闘い これらの闘いの中で「我々は何を学んだのか？」をお話できればと思っています。 当日はチームのメンバーもオーディエンスとして参加します。Scrum Festではセッションの発表を聞くだけでなく、ワークショップやCoffee/Tea Breakなどで参加者同士の交流の時間も設けられていますので、チケットをお持ちのかたはぜひ会場でお声がけください。 RAKUS Meetup Osaka #2 アジャイル Night（2/26） rakus.connpass.com 楽楽精算開発2課のメンバーがそれぞれの立場から スクラム 1年目を語ります。私たちはチームでの スクラム の取り組みをアウトプットするために、半年前からこのイベントに向けて準備してきました。 以下のそれぞれの立場でメンバーが発表する予定です。 主力エンジニアの場合 中途入社エンジニアの場合 若手エンジニアの場合 スクラム マスターの場合 メンバーの入れ替わりなどもあり、私たちはそれぞれの立場で様々な課題に向き合ってきました。それらは開発の現場ではよくあることかもしれませんが、同じ課題を抱えるエンジニアの皆様にお伝えすることで何かの気づきになれば幸いです。 LT枠も募集していますので、それぞれの現場での アジャイル な取り組みを共有しあえればと思います。ご参加お待ちしております。

Y-Kanohです。先日開催された、「フェリー ハッカソン 2019」に他数人のエンジニアと参加してきました。 ハッカソン イベントには初めての参加でしたが、チームにも恵まれて楽しく終えることができました。 眠かった。 イベント概要 詳しくは、参加前に@neroblubrosさんが投稿している記事をご覧ください。 http://tech-blog.rakus.co.jp/entry/20190125/interaction/engineer-learning/hackathon/ 日時：2019年1月25日～27日（二泊三日） 公式Webサイト ： http://ferryhack.code4.osaka/ 簡単に説明すると、「大阪港 - 別府間のフェリーに乗りながら、 ハッカソン を行うイベント」です。 公式Webサイト の「日程」からもわかりますが、 アイディアソン開始が21:30 、 ハッカソン 開始が24:00 という素晴らしいスケジュールです。 テーマ説明時にも不穏なスライドが！ 全体の流れ 一日目 作成するサービスのテーマ説明会 アイディアソン（作成するサービスの案出し） ハッカソン スタート（サービス作成開始） 二日目 別府会場にて ハッカソン / 発表資料作成 三日目 発表会 フェリーについて 今回はフェリーに乗りながらプログラムを書くという、非日常な体験をしてきました。 フェリー内には、運営チームのインフラ部隊が Wi-Fi 環境を整えてくださり、プログラムできる環境が用意されています。 そのため、船内のいたるところに Wi-Fi 機器が取り付けられていました。 ハッカソン について 私のチームでは、 QRコード を読み取ってサーバとやり取りを行うシステムを作成しました。 QRコード 読み取り機器などのハード側のプログラムや、読み取った後に接続するWebアプリケーションの作成、さらには表示する画面のデザインなど、やることは多岐にわたるため、チームメンバの方々と役割分担して進めました。私も微力ながら、読み取った QRコード の情報を判別する API の実装を担当しました。 復路のフェリー内では、アプリケーションの結合を行う傍ら、発表資料を作成し、最終日には発表も担当させていただきました。 惜しくも最優秀賞は逃しましたが、協賛企業の さくらインターネット 様による、「 さくらインターネット 賞」をいただきました。 デモ風景 所感 初めての ハッカソン イベント参加ということもあり、一番印象に残ったことは、 社外エンジニアのスキルを感じられる点 でした。 社内で使われていない技術や、自分が使ったことがない技術でも、社外では一般的なことや、技術に対する温度感を身近に感じることができ、自身の知識の低さや、認識の間違いに気づかされることもありました。 また、チームで作業をする中で、他社の業態や必要とされる技術など、実際の現場でのお話もお聞きできるため、勉強会やカンファレンスより深く知見が広がる印象でした。 参加前から過酷なイベントだと聞いていましたが 、終わってみると、とても楽しく、また得るものも多いイベントだっだと感じました。 フェリーというあまり自由が利かない環境の中で、社外のエンジニアの方と作業することはとても新鮮で、勉強になりました。

はじめに こんにちはMasaKuです。 先日、ブログでも告知させていただきました「フェリー ハッカソン 2019」に参加しました。 tech-blog.rakus.co.jp ハッカソン への参加が初めてだったこともあり、参加前は非常に緊張しました。 しかし、社外のエンジニアの方とチームを組んで開発したり、普段使ったことが無い技術を組み合わせて新しいサービスを考えることができ、総じて貴重な経験ができました。 今回はフェリー ハッカソン 2019に参加してみて「 良かったこと 」と「 悔しかったこと 」について書いていきたいと思います。 はじめに フェリーハッカソンの流れ 作成したWebアプリ フェリーハッカソンに参加して良かったこと 社外のエンジニアの方と一緒に開発する経験ができた 自分のすべきことを全うしようという意識ができた 新たな技術習得に対するモチベーションが向上した 悔しかったこと 時間内に全ての機能が実装できなかった 開発環境をしっかり整えておけばよかった まとめ おまけ 参考サイト フェリー ハッカソン の流れ フェリー ハッカソン は３日間で行う ハッカソン です。 まずは、フェリー ハッカソン の流れについてご説明したいと思います。 ３～４人程度のグループで船や旅に対するイメージを ブレインストーミング 出てきた案を元にして船旅が楽しくなるようなサービスを考える 各サービスを参加者全員で評価 評価が良かったサービスを開発するためのチームを作成 開発開始 発表会 私は「旅先で見つけたお土産を船上で食べるグルメパー ティー 」を提案しましたが、全然刺さっていない様子でした・・・。 作成したWebアプリ 私はその後、ほかの方が考えた「大阪から大分までの移動時間約10時間を最大限暇つぶしできるWebアプリの作成」をテーマにした、乗船客が白組と黒組に分かれて対戦する50×50マスの リバーシ を作成するチームに参加しました。 50×50マスの リバーシ （対戦中盤から1手で変わる石の数が想像以上に多く爽快感があります） 私はサーバサイドを担当し、 PHP を用いてゲームの進行状況を管理する機能の実装を行いました。 ホワイトボードを利用したシステム設計 フェリー ハッカソン に参加して良かったこと フェリー ハッカソン に参加して良かったことはいくつもありましたが、その中でも特に印象に残ったものをご紹介したいと思います。 社外のエンジニアの方と一緒に開発する経験ができた 社内のMeetup やプライベートでエンジニアの方と交流することはありますが、一緒に作業した経験はありませんでした。 そのため、 ハッカソン で同じチームになったメンバーと技術領域が違った場合の作業の進め方についてまったく想像ができず、少し不安な気持ちがありました。 しかし、参加してみると、サーバサイドとフロントエンド、インフラなど、各メンバーが不足点を補いながらチーム全体として最大の効率を発揮できる担当割り振りができました。 技術領域が違っているからこそ、気を掛け合わなければならない点について意識するようになり、各機能の結合時には積極的にコミュニケーションを取りながら作業を進めることができました。 他のメンバーとは異なるユニークなスキルを持っていれば、できることの可能性も広がっていくと思ったので、自分の興味のある内容については 知名度 を気にせず、どんどん挑戦していきたいと思いました。 自分のすべきことを全うしようという意識ができた 自分の担当作業において、他のメンバーが扱ったことがない技術や プログラミング言語 を選択している場合は、メンバーに協力を依頼できない場合があります。 そのため、開発中にトラブルが発生し実装が予定よりも遅れたとしても、自分の力で解決しなければならない状態になる場合があります。 しかし、そういったプレッシャーのかかる状況だからこそ、自分の担当機能がほかのメンバーが開発した機能と結合できた際の達成感は大きかったです。 自分に任された作業をしっかりとやり遂げるために、自分の技術を磨くこととトラブル時の状況説明を明確にすることの大切さを改めて実感することができました。 新たな技術習得に対するモチベーションが向上した 普段の業務で利用している技術については、どのように利用できるかが明確なので、今回作成したWebアプリの開発においても、自分がどのようにチームに貢献できそうかも想像できました。 しかし、外部のエンジニアの方はそれぞれの技術領域での解決方法を知っており、アド バイス を頂いた際に「そういう方法もあるんだ！」といった気づきを得ることもできました。 自分の技術領域を広げていくことで、「自分ならこうして実現するな」であったり「あの技術を組み合わせたらこんなこともできるな」といった発想力を持つことができるようになると思いました。 自分の枠にとらわれず、積極的にいろいろな技術に触れて柔軟な思考ができるようになりたいと思います。 棋譜 をレシートとして出力したメンバーもいました 悔しかったこと 自分としてはうまくできると思っていたところも、かなり苦戦してしまった場面もいくつかありました。 反省点の振り返りも兼ねて2点ご紹介したいと思います。 時間内に全ての機能が実装できなかった 開発開始当初に実装しよう思っていた機能のうち、一部の機能が時間内に実装することができませんでした。 結果的に、ほかのメンバーが開発した機能とうまく連携できなかったものもありました。 Webアプリとして、より面白いものを作りたいという気持ちと、時間内に実現できそうなラインの見極めが重要だと思いました。 開発環境をしっかり整えておけばよかった 普段の業務ではマルチモニターにしたり、その他周辺機器を利用して開発を行っています。 今回、 ハッカソン に参加するにあたって、荷物の関係上あまり多くの周辺機器は持ち込めないと思ったので、特にツール等は持ち込まず、普段あまり使わない タブレットPC に最低限の準備だけをして参加しました。 案の定、小さなモニターと タッチパッド 操作に慣れず、実装中に操作面で足を引っ張られた場面が何度かありました。 開発環境を整えておくことで、開発の効率も変わってくると改めて実感したので、より効率よく作業をするために、今一度業務で利用している開発環境も見直すべきかと思いました。 まとめ ハッカソン 初参加ではありましたが、大変実りのある経験ができたと思います。 今回は３日間という短い期間でのチームでしたが、通常業務でのチーム開発にも通ずる経験ができたと思ったので、今回学んだ内容を反映させていきたいと思います。 開発チームという枠組みで個性を発揮しつつも、チーム開発で最大の効率が出せるようなチームメンバーになっていきたいですね。 おまけ 開発の休憩時間を利用して、別府観光にも行きました。 楽しく開発しつつ観光も楽しめる素敵なイベントになりました。 白池地獄 とり天定食 参考サイト フェリーハッカソン2019 - connpass Facebook 無効なURLです フェリーハッカソン2019のまとめ - Togetter

はじめに こんにちは、 id:FM_Harmony です。 今回は先週開催された東京オフィスのビアバッシュについて、紹介記事を書きました。 なお、東京オフィスでのビアバッシュについては、下記の記事にて詳しく紹介されています。 tech-blog.rakus.co.jp はじめに 発表内容 iOSアプリ開発でオススメのライブラリ ゼロから始めるPython入門講座に参加してきました 新規メンバーのための「TKG」と「過去問」のススメ おまけ おわりに 発表内容 大阪オフィスのビアバッシュとは異なり、東京のビアバッシュでは今のところ自由なテーマでの発表のみ行っています。 iOS アプリ開発 でオススメのライブラリ 簡単に使えておしゃれなUIが作れる iOS アプリのライブラリに関する紹介です。 ウォークスルー *1 や、読み込み中のアニメーションなどが簡単に実装できるライブラリが紹介されていました。 iOS アプリを利用していて、よく見かけるUIと同じものが紹介されていたので、それらが簡単に実装できるのは iOS アプリ開発 をする上で有用だと思いました。 ゼロから始める Python 入門講座に参加してきました 私、 id:FM_Harmony が Python 勉強会に参加した事について発表しました。 発表内容の紹介が、入門講座に参加した際の個人的な感想になりますが、非エンジニアと思われる方も参加されていたのが印象的でした。 講座内で「 Python はプログラミング入門に適している」というお話もあったのですが、個人的にはそのことが要因なのかと感じています。 新規メンバーのための「TKG」と「過去問」のススメ 若手メンバーがプロダクトについて理解するために取り組んでいることについての発表です。 東京の楽楽精算開発チームでは、若手メンバーの活動として以下の２つを行っているとのことでした。 過去問 過去にリリースした機能を題材とした学習、若手メンバーが既存機能の実装や開発手法を理解することを目的にしている。 定例業務改善グループ （通称 TKG ） 属人的な作業の引継ぎや、作業内容の改善を行っている。 今でも私は思いますが、楽楽精算は機能も多く実装内容の全容を理解することが大変で、実際の開発に入る前に覚えなければいけない知識も多いです。なので、それらへの理解を助ける上記の活動はチームに参加したばかりのメンバーにとってとても有用だと思います。 おまけ ラク スのサークル活動や今度の2/19(火)に行われるRakus Meetup Tokyoの宣伝発表もありました。 Rakus Meetup Tokyoについては、以下のリンクから参加登録可能です。参加枠の倍近く予約があり、増席予定とのことでした。 rakus.connpass.com おわりに 東京オフィスの1月ビアバッシュについてお送りしましたが、いかがでしたでしょうか。大阪側のように、今後は東京の社内イベントも定期的に紹介記事を書いていけたらと思います。 *1 : スワイプしながらアプリの説明をするような画面のこと

はじめに はじまして、新卒1年目エンジニアのyk_itgです。 今回は初めて参加したカンファレンス、 JJUG で知った プログラミング言語 、Kotlinについて調べてみました。 www.java-users.jp はじめに Kotlinとは なにができるの？ 実行してみた FizzBuzz Null安全 nullを許容しない変数と許容する変数 nullチェック まとめ Kotlinとは Kotlin(コトリン) は Java と同じ 静的型付けの オブジェクト指向言語 です。 開発したのは 統合開発環境 IntelliJ IDEAを構築している JetBrains で、 Java をもっと簡潔・安全になるように改良した産業利用向け汎用言語として開発されました。 また、 JVM 上で動作する のでほとんどの環境で実行が可能です。 なにができるの？ 利用用途は幅広く、Webアプリケーションや Android アプリなどの開発をすることができます。 また、2017年に Android の公式言語 になったので、安心して Android アプリの開発に使えます！ 実行してみた Kotlin公式サイトでお手軽に実行できます。 Kotlin Programming Language kotlinlang.org FizzBuzz 試しによくある FizzBuzz を書いてみました。 fun main() { for (i in 1..100) { val ret = fizzBuzz(i) print("$ret,") } } fun fizzBuzz(num: Int): String { return when { (num % 15 == 0) -> "FizzBuzz" (num % 3 == 0) -> "Fizz" (num % 5 == 0) -> "Buzz" else -> num.toString() } } 1,2,Fizz,4,Buzz,Fizz,7,8,Fizz,Buzz,11,Fizz,13,14,FizzBuzz,16,17… 書き方は元となった Java とは大きく違う ことがわかります。 Null安全 記事のタイトルの通り、KotlinはNull安全な プログラミング言語 です。 Null安全とは、ざっくり言えば NullPointerException が起きない ということです。 ですが、nullが使えないわけではありません。 nullを許容しない変数と許容する変数 Kotlinにはnullの代入を 許容しない変数 と 許容する変数 が存在します。 変えるのは簡単で型宣言の後に「 ? 」を付ければ、nullを許容する変数にすることができます。 fun main() { //nullを許容しない変数 var num1:Int //nullを許容する変数 var num2:Int? num1 = null num2 = null } num1 はnullを 許容しない変数 なのでnullを代入しようとすると コンパイル 時エラー になります。 num1 = null; //コンパイル時エラー num2 はnullを 許容する変数 なのでエラーが出ません。 num2 = null; //エラーにならない nullチェック nullを許容すると NullPointerException が起こってしまいそうですが、そんなことはありません。 nullを許容する変数を参照する場合、 nullチェックをしていないと コンパイル 時エラー になるからです。 fun main() { //nullの代入を許容しない val num1:Int = 1 //nullを代入を許容する val num2:Int? = 2 println(sum(num1, num2)) //num2にnullチェックを行っていないのでエラー } fun sum(num1: Int, num2: Int): Int { return num1 + num2 } なので、参照する場合には必ずnullチェックを行わなくてはいけません。 fun main() { //nullの代入を許容しない val num1:Int = 1 //nullを代入を許容する val num2:Int? = 2 if (num2 != null){ println(sum(num1, num2)) //これならOK } } このようにKotlinはnullを参照することがない、 nullチェックを コンパイラ が強制する仕組み を持っているNull安全な プログラミング言語 なのです。 まとめ Null安全な プログラミング言語 「Kotlin」についてご紹介してきましたが、いかがでしたでしょうか。 今回紹介した以外にも、 型推論 や Java のソースをKotlinに変換できる といった特徴もあります。 まだまだ特徴はあるので興味を持った方は是非調べてみてください。 参考サイト Kotlin - Wikipedia https://eigoninaritai.com/about_kotlin_of_official_language_on_android/ Kotlinとは――読み方、メリット、「Java」とのコード比較、実行までのチュートリアル (1/3)：Android Studioで始めるKotlin入門（1） - ＠IT Null安全がすごい - 騒音のない世界 BLOG

はじめに 今回は大阪オフィスで開催された1月ビアバッシュをご紹介します。 前回のビアバッシュ記事はこちら↓ tech-blog.rakus.co.jp はじめに テーマ発表 Chat Dealer 配配メール Mail Dealer 楽楽精算 働くDB 自由発表 Githubでタスク管理 CfP を書く技術 LT発表 コードの好みを知りたい おわりに テーマ発表 業務 カイゼン ジャーニー 新年最初のビアバッシュのテーマは業務 カイゼン ジャーニーでした。 ラク スの各製品の開発者にこんな業務 カイゼン をやったよ、というお話をしていただきました。 また、テーマ発表の後にはテーマ自由の発表やLT発表もあり、ボリュームのあるビアバッシュとなりました。 Chat Dealer リリース作業をAnsible化して 工数 削減が実現できたというお話でした。 Chat Dealerの発表内容 Chat Dealerはリリース頻度が高く、リリース作業が大きなコストになっていたそうです。Ansible化したことで作業手順がどのように変わったのか、どのあたりが楽になったのか、ということをお話いただきました。 お話しいただいた内容で私が開発に携わっている製品でも活用できないかと考えましたが、リリース作業を担当したことがなく実感がないので、まずは大変さを知るためにもリリース作業をやってみることから始めないとな、と思いました。 配配メール チームのタスク管理として最近始められたカンバン運用の振り返りについてのお話でした。 配配メールの発表内容 各メンバーが一日分のタスクを分割して付箋に書いて張り出し、遅れているタスクがないかチーム全員で 見える化 したそうです。 私もタスク管理が大雑把になっているので、個人的にカンバンのように 見える化 して カイゼン できないか試してみます。。。 また、今回の発表が一般的な業務改善の進め方と対比して振り返りを行うという形式でしたので、 カイゼン 活動を進める際の参考例として活用できるかなと個人的に思っています。 Mail Dealer ベトナム で行っているオフショア開発の カイゼン についてお話しいただきました。 品質が低いという課題とその対策の話も興味深かったのですが、特に気になったのは ベトナム メンバーの ヒアリ ングから分かった「日本メンバーが怖い」という課題があったことです。近くでコミュニケーションが取れない分、ミーティングの際は ビデオチャット で顔を映して、とにかく笑顔を意識するなど、細かなことから気を付けて カイゼン したという話が印象的でした。 Mail Dealerの発表内容 私自身も現在2年目ですでに後輩がいますし、来年度にはさらに増えますので、良好なコミュニケーションをとれるよう同じようなことを意識します。。。 楽楽精算 以前に取り組んでいたモブプログラミングを実際に業務プロセスの一部として盛り込んでみた、というお話でした。モブプログラミング自体の取り組みついてはMeetupの記事をご参照ください。 tech-blog.rakus.co.jp 今回は業務に組み込むうえで気を付けたこと、やってみた結果の振り返りをお話いただきました。 楽楽精算の発表内容 モブプログラミングの題材がリファクタだったので、どのようなソースがイケてないかという共通認識の形成に役立ったそうです。私の所属するチームでも、この「イケてない」という感覚を新人にどうすれば共有できるかという話が出たことがあるので、モブプログラミングをしてみるということは選択肢の一つとしてアリだなと感じました。 働くDB 開発規約に準拠したコードを作成し、さらにそれをテンプレートとして新規コードを起こす際に自動生成するツールも作成したというお話でした。 働くDBの発表内容 このチームでは明文化された開発規約が最近できたばかりだったので、規約に準拠したコードがほぼ無く、新しくチームに入った人が混乱してしまうことがあったそうです。 私が新しくチームに参加したらということを考えると、規約に準拠したコードがあればコーディングの細かな部分に悩まずに済みますし、自動生成ツールがあればなおさら楽に進められそうですね。 自由発表 Github でタスク管理 タスクをIssueをとして登録することで、 Github でタスク管理をするという話でした。 他のタスク管理ツールと比較をすると、プルリク エス トなどの開発関連作業含めて1つのアプリケーション内で完結することが利点だそうです。 Github でタスク管理 CfP を書く技術 CfPを書く際に意識したところを、実例を交えて解説していただきました。 ※CfPとはCall for Paperの略称で、カンファレンスのスピーカーとして応募する際に必要なものです。 トーク の内容や必要性などを記載し、主催者はこれを見て トーク を採択するか判断します。 CfPを書く技術 画像内の各色は、赤色が 推し ・オレンジ色が ニーズ ・ピンク色が エモ を意識して作成されたフレーズだそうです。 またこちらの内容については来月開催される Laravel JP Conference 2019 で登壇し発表します。 tech-blog.rakus.co.jp LT発表 コードの好みを知りたい ビアバッシュ参加者の方に対して「どっちのコードが好み？」というアンケート的な発表をしていただきました。今回は4つ事例がありましたが、参加者の好みが分かれるもの、偏るもの様々でした。 コードの好みを知りたい どっちが好み？は答えられますが、なぜ好むのかまでは改めて考えたことがありません。それを自分の中で明確にできると書くコードにも一貫性が出せそうなので、一度考えてみようと思います。 おわりに 1月のビアバッシュをダイジェストでお送りしました。 各チームとも課題を解決すべく様々な カイゼン 活動を行っていました。課題があることは成長できる余地があるということなので、引き続き カイゼン 活動を行っていきます。

ラク スでメールディーラーの開発に携わっている@neroblubrosです。 今回は本日の夕方から始まるフェリー ハッカソン について書きます。 フェリーの中で ハッカソン ！ その名の通りフェリーの中で ハッカソン を行うというもの。なぜフェリーなのか？ってことですが、実はフェリー ハッカソン は今回で2回目の開催です。 第1回目は2017年に開催されました。2017年は大阪港開港150周年の年で、その記念イベントとしてCode 4 Osakaが主催、フェリーを運行している「さんふらわぁ」の協力のもと、 大阪市 や 別府市 が後援し開催されました。 開港イベントだったので一回限りの ハッカソン の予定だったみたいですが、思っていたより好評だったので、第2回目も開催されました。 ラク スが協賛しています 前回のフェリー ハッカソン が好評だったことや、社内で参加希望者が数名いることから、今回は ラク スが協賛企業としてお手伝いをしています。 また私以外で2名参加します。彼らも参加レポートのブログを書く予定ですのでお楽しみに！ 関連サイト 前回のフェリー ハッカソン の様子はこちらをご覧ください。 http://036-yakudachi-info.com/blog/hackathon/ferry-hackathon フェリー ハッカソン サイト http://ferryhack.code4.osaka/ Facebook ページ https://www.facebook.com/events/1167433570099385/ Twitter https://twitter.com/ferry_hack

はじめに こんにちは、MasaKuです。 プライベートの時間を利用して、ニュース記事などで見つけた面白そうな技術を使ってみたり、「こんなのあったら便利かも？」と思ったものを作ったりしています。 そこで、最近流行のゲームである、対戦相手を攻撃して画面外にふっとばすゲームの対戦記録を残せたら便利じゃないかな？と思い、簡単なWebアプリを作ってみました。 「 とりあえず動く 」を目標に作成していたため、使い心地などは一切考慮せずに作っていましたが、そもそも簡単なアプリなので、そこまで工夫できるポイントもないかと思っていました。 しかし、既存アプリの調査をしてみると ちょっとした工夫でユーザの操作を楽にできる ことに気づいたので、自分の反省のためにも記載していきたいと思います。 はじめに アプリ概要 使いづらい点 無駄な送信ボタン キャラクターの選択操作 まとめ 参考サイト アプリ概要 まず、今回作成しようと思ったWebアプリで実現したかったことは以下です。 twitter のOAuthによるユーザ登録とログイン機能 使用キャ ラク ターの利用回数の記録 使用キャ ラク ターの勝率の表示 対戦情報をより詳細に記録できるようにしたかったのですが、ひとまずの目標は対戦回数と勝率が出せたらいいかと思い、このような形になりました。 また、上記程度であれば、実装イメージも湧きやすかったというのもあります。（個人開発のモチベーション維持には実は大事） 作成したWebアプリの画面は以下のようになりました。 トップページ データベースに入力値を登録するだけの簡単なフォームですが、必要な要件はクリアしています。 使いづらい点 上記機能がすべて利用可能な既存アプリと比較して、 今回作成したWebアプリの使いにくい点 について、特に気になったポイントをご紹介したいと思います。 無駄な送信ボタン 私の作成したWebアプリでは、以下の操作が必要です。 使用したキャ ラク ターをプルダウンから選択 勝敗をプルダウンから選択 送信ボタンを押下する 上記のうち必要が無い操作だと気づいたのは「3. 送信ボタンを押下する」です。 通常、送信ボタンを押す前にフォームに必要な情報が全て正しく入力できているかをユーザに確認させる必要かあります。 しかし、今回のWebアプリのような簡単な入力画面では必ずしも確認するフェーズは必要ではないのではないかと思いました。 入力間違いが許されないような画面については、送信前に確認させる意味合いも込めて、送信ボタンを押させる必要があるかと思います。 しかし、今回のような場合は少ない操作で登録できて、後から簡単に修正できるようにするのも良いかと思いました。 つまり、この操作は以下のように修正することができます。 使用したキャ ラク ターをプルダウンから選択 勝敗ボタンを押下 送信ボタンを削除 確認ダイアログが何度も表示される画面などと似たケースにはまっていたのかもしれません。 キャ ラク ターの選択操作 私の作成したWebアプリで使用したキャ ラク ターを選択する場合は、プルダウンから選択する必要があります。 そのため、日本語化されたキャ ラク ター名を探して、該当項目を選択しなければいけません。 しかし、既存アプリの場合は、キャ ラク ターのサムネイルを選択するという方式になっていました。 キャ ラク ターの選択方法 対象ユーザはゲームを遊んでいる人なので、キャ ラク ターの名前と、キャ ラク ターのサムネイルではどちらの方が馴染み深いかは言うまでもありません。 キャ ラク ターの名前を忘れてしまうことがあっても、キャ ラク ターそのものを識別できなくなることはほとんど無いでしょう。 選択肢がある入力フォームではプルダウンが採用されるという固定概念ができてしまっていたと感じました。 まとめ 今回は、以下の二点について勉強になりました。 必要がない操作の削減 探しやすい選択項目の表示方法 Webデザインにおける認知負荷では以下に気をつけなければならないようです。 操作負荷 … マウスやキーボードといった機器の操作 視覚負荷 … 目の前にみえる情報に気を止めたり、気付いたりすること 知覚負荷 … 考えたり、記憶したり、 スキーマ と関連付けさせること 今回の場合は、操作負荷と視覚負荷を高めてしまった形になるかと思いました。 普段の開発業務では、モックや詳細設計書の画面イメージを元に開発を行います。 そのため、使いやすい画面とはどういう作りになっているか、ということについて、あまり意識していませんでした。 開発に携わるものとして、デザイン上の アンチパターン についてはしっかりと認識しておかなければならないと思いました。 参考サイト builder.japan.zdnet.com

id:radiocat です。1月17日に大阪オフィスで初の「もくもく勉強会」を開催しましたので、今回はその模様をご報告します。 rakus.connpass.com 経緯 大阪の開発部門では毎週木曜日にもくもく勉強会を開催しています。以前のエントリーでもその様子を少しご紹介しています。 tech-blog.rakus.co.jp 2018年9月に大阪オフィスが移転して、広い セミ ナールームが確保できたことから、もくもく勉強会を社外向けにも開放してみてはどうかという声が上がるようになりました。そして私の所属する楽楽精算開発2課のメンバー数名と協力して最低限の運営方法などを整備してこのたび開催することになりました。 みんなで楽しむもくもく勉強会 まだ試行錯誤的な取り組みですが、せっかく社外の方にも参加していただくので何らかの接点を持って今後に繋げていただきたい思いがあります。もちろん「もくもく勉強会」と言うからにはエンジニアの自主学習の場であることが第一優先ですが、その中でこの場をさらに少しでも有意義な場にするために何かできることはないかと考えました。 もくもくすることを共有する もくもくすることを共有できる「一言共有ボード」を準備しました。受付が終わると、まずその日にもくもくする事を一言で付箋に書いてホワイトボードに貼って頂きます。そして参加者が揃う19時ごろに付箋を見ながら自己紹介も兼ねた一言共有会を実施しました。 その日やったことを参加者同士で共有し合うことで学習のモチベーションに繋がりますし、お互いが取り組んでいる技術などを知ることでエンジニア同士の交流にも繋がります。なお、付箋の記入と共有は希望者のみ実施していただくことにしていますので、共有しないと参加できないわけではありません。 もくもくのついでに交流もできる 参加者同士の交流は自由に行っていただけます。直接は会話しづらいこともあるかもしれないので、その場での連絡や情報交換を気軽にできるツールとしてSlackのチャンネルも準備しています。もちろんSlackへの参加する／しないも自由です。 また、今回は20時終了としていましたが運営メンバーで振り返りを行った結果、次回は21時を最終退出期限として自由時間を確保することにしました。もくもく勉強した後で交流時間に使っていただくも良し、もう少しキリの良いところまで自習していただくも良し、という予備時間です。もちろん、基本的に入退室は自由ですので都合のつく範囲で参加していただき、いつでも帰宅していただけます。 次回告知 次回は2月14日に開催予定です。既にconnpassに公開していますのでご覧下さい。 rakus.connpass.com まだまだ試行錯誤中ですが、参加していただいた皆様と楽しみながらこの場を育てていきたいと思っています。興味を持たれた方は是非ご参加いただけましたら幸いです。

こんにちわ @kawanamiyuu です。来月開催される Laravel JP Conference 2019 に弊社から 2 名のエンジニアが登壇することになりましたのでお知らせします。また、株式会社 ラク スは BRONZE スポンサーとしてイベントに協賛しています。 イベント概要 日時 : 2019 年 2 月 16 日 (土) 会場 : グランパークカンファレンス 公式 HP : https://conference2019.laravel.jp/ ハッシュタグ ： #laraveljpcon conference2019.laravel.jp 登壇情報 タイムテーブルは コチラ チャットディーラーの高速開発を支える Laravel レギュラー トーク （14:40 〜 15:10） 発表者：坂田晃平 10年以上 PHP でノン フレームワーク で開発・運用されてきた主力サービス（メールディーラー）の開発チームが、新規に姉妹サービス（チャットディーラー）を立ち上げる際にLaravelを選択をしました。 開発期間半年というスピードが求められる中で、チームがLaravelに抱いた理想と現実、また、Laravel(Blade)とVue.jsの組み合わせによる 脆弱性 への対応など、Laravelでの新規サービス立ち上げの経験を具体的にお伝えします。 昨年の PHP カンファレンス関西 2018 で発表 した内容の再演です。 電撃：Laravel API クイズ ライトニング トーク 発表者：加納悠史 「Laravel は便利」「Laravel で開発速度が上がる」とは、よく聞くセリフですが、我々はどこまで Laravel を使いこなせているのでしょうか。 Laravel ビギナーがドキュメントを読み漁って掘り当てた、Laravel のニッチな便利機能/便利関数をクイズ形式で紹介します。目指せ！全問正解！！ どんなニッチな機能を掘り当ててくるのか楽しみです！ まとめ 昨年夏の PHPカンファレンス関西 2018 、先月の PHPカンファレンス 2018 に続いて PHP のイベントへの登壇が立て続けに決まって非常に嬉しいです。株式会社 ラク スは今後も PHP コミュニティへのコミットを推し進めていきます。

はじめに id:d_shr です。 MailDealer開発チームでコードレビューを担当しています。 去年の４月からコードレビュー担当になり１年が経とうとしているので、若手(新卒2年目)がコードレビューをやって良かったこと、難しかったことなどを振り返ってみようと思います。 はじめに コードレビューとは コードレビュー担当をしていて良かったこと ① コードを読む力がつく ② レビュワーの観点がつく ③ 指摘が自分に返ってくる ④ 他の人が書くコードが読める ⑤ いろんな機能の仕様、中身を把握できる コードレビュー担当をしていて難しかったこと ① 指摘を出す ② ついでに直して欲しいを指摘で返してはいけない ③ コード規約に載っていない暗黙のルール まとめ 若手のコードレビューはオススメ コードレビュワーが指摘するときに気をつけるべきこと 最後に コードレビューとは 一言で言えば、書いたコードを他の人にレビューしてもらうこと。 主に以下について確認します。 コード 規約違反 がないか？ 保守性の低いコード、冗長なコードになっていないか？ コードミスがないか？ 仕様通りのコードになっているか？ コードレビュー担当をしていて良かったこと ① コードを読む力がつく 元々コードを読むことには自信がありましたが、ここ１年でかなりのコードを見たので、さらに自信がついたかなと思っています。 いろんな人が書くコードを読むので、読む力はかなりつきます。 ② レビュワーの観点がつく コードを書くときに、良いコードを書かなきゃと可読性を意識しますよね。 コードレビューをするようになってから実装をするときに、「このコードを自分がレビューするとしたら…」という視点が持てている実感あり、良いコードが書きやすくなっている自覚があります。 レビュワーとして指摘しているようなミスはできないし、書いた段階で気づけるので、効率よくコードが書けるようになった気がします。 ③ 指摘が自分に返ってくる ②と繋がる話ですが、指摘した内容が自分に刺さることは少なくありません。 「偉そうに指摘したけど、人のこと言えないなぁ…自分がコード書くときは気をつけないと。」 みたいな感じです。 このようなことも含めて自分の成長に繋がっています。 ④ 他の人が書くコードが読める 他の人のコードを読むことはすごく参考になります。 自分よりもエンジニア歴が長い人たちのコードが読めるので、「こういう書き方もあるんだ」と参考になることが多いです。 ⑤ いろんな機能の仕様、中身を把握できる コードレビューを行うためには最低限仕様を把握している必要があります。 開発中の機能の3〜4割程度のコードレビューを担当していますが、その分だけ仕様を把握することができています。 開発中によくわからないエラーに直面したときはいろんな機能を把握できているおかげで解決が早い事が多いです。 コードレビュー担当をしていて難しかったこと ① 指摘を出す ベトナム の開発メンバーが書いたコードをレビューすることがほとんどです。 顔を合わせて話ができない、日本語で説明できない相手に指摘をすることになります。 指摘を返すときに、理由を明確にして相手が納得できるような指摘を返すことを心がけていますが、言語の壁があったり、指摘したことに実は意図があったりと最初は難しかったです。 ② ついでに直して欲しいを指摘で返してはいけない 修正したことに関連して既存でイケてないコードがあると、ついでに直して欲しいと思うことがあります。 修正すべきなので良かれと思って指摘として伝えると、コードを書く人は不満を持ってしまうことがありました。 指摘ではないけど修正してほしいという意図をしっかり伝えて、コードを書く人に不満を持たせないように心がけています。 ③ コード規約に載っていない暗黙のルール コード規約や正しく書いていることを確認するチェックリストなどのドキュメントはありますが どこにも書かれていないけど、こういうコードは良くないみたいな観点はあると思います。 「こういう書き方はしてほしくない」、「この場合はこういう書き方をしてほしい」、「この関数はこういう使い方をしてほしい」…etc そういったことを明確なルールにしていくことが難しいと思いました。 ルールになっていなかったものや、指摘が多かったことをまとめたドキュメントを作成してメンバーに展開しました。 まとめ 若手のコードレビューはオススメ コードを読む力、読むことで参考になること、コードを書くときに活かせるなど メリットがたくさんあり、成長に繋がることが多かったと思います。 出した指摘から自分の意識と高めることができたり、レビュワーの視点が身についたり良かったことが多かったです。 コードが読めて、ある程度実装ができるなら、どんどんコードレビューを積むことは良いことではないかと思いました。 コードレビュワーが指摘するときに気をつけるべきこと 難しいと思ったことから簡単にまとめると… 問題を明確にする 理由を明確にする 修正方法を明確にする どういう観点なのか？ 参照すべきドキュメントがあるなら記載する 指摘ではなくついでに直して欲しいことは明確に 怪しいコードを見つけたら書いたコードの意図を聞いてみる 最後に 今後もコードレビュー担当を通して、成長できればと思っています。 品質向上にも貢献できるようにコードレビュー担当の観点でできることをやっていきたいと思います。

kuwa_38です。先日 SQLite を使った Android アプリを作成していたのですが、表示データが多くなると画面外に表示されるため対策が必要だなと考えていました。 この記事では ScrollView を使って特定領域内をスクロール可能にする方法をご紹介します。 今回作成するアプリと過去の記事 ScrollViewを導入して特定領域内をスクロール可能にする （注意１）画面のレイアウトが崩れる 注意１の解決方法 （注意２）複数要素を指定したい場合 注意２の解決方法 おわりに 今回作成するアプリと過去の記事 今回 ScrollView によりスクロールを導入するアプリを紹介します。簡単に言うと SQLite を用いてDB内のデータを表示するアプリです。今回はそのアプリで表示するViewにスクロール機能をつけることがゴールです。 qiita.com scroll ScrollViewを導入して特定領域内をスクロール可能にする 画面レイアウト用の xml において、スクロールをさせたい範囲を ScrollView で囲むと、その範囲をスクロールさせることができます。 <ScrollView android : layout_width = "match_parent" android : layout_height = "match_parent" android : layout_marginTop = "200dp" android : id = "@+id/scrollView" > <!-- スクロールさせたいTextView --> <TextView android : id = "@+id/text_view" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "「表示」を押すとDBのデータを全件表示します" /> </ScrollView> （注意１）画面のレイアウトが崩れる 「 ScrollView で要素を囲む」。これだけでいいのですが、注意点があります。１つは画面のレイアウトが崩れることがあることです。文字入力しようとするとキーボードが出てきた際にレイアウトが崩れてしまいます。 レイアウト崩れ 注意１の解決方法 ScrollView に android:isScrollContainer="false" を追加することで解決できます。下記のサイトによると isScrollContainer は IME が表示されたときにスペースを空けるためにViewをリサイズするかどうかを指定するものだそうです。 <ScrollView android : layout_width = "match_parent" android : layout_height = "match_parent" android : layout_marginTop = "200dp" android : isScrollContainer = "false" android : id = "@+id/scrollView" > <!-- スクロールさせたいTextView --> <TextView android : id = "@+id/text_view" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "「表示」を押すとDBのデータを全件表示します" /> </ScrollView> retrocatsoft.blogspot.com （注意２）複数要素を指定したい場合 2つ目は ScrollView は１つの要素しか指定できないことです。 実際、下記のように要素を追加すると、エラーが発生します。 <ScrollView android : layout_width = "match_parent" android : layout_height = "match_parent" android : layout_marginTop = "200dp" android : isScrollContainer = "false" android : id = "@+id/scrollView" > <TextView android : id = "@+id/text_view" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "「表示」を押すとDBのデータを全件表示します" /> <TextView android : id = "@+id/textView2" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "２つ目のTextView" /> </ScrollView> # consoleのエラー ...（略） ...ScrollView can host only one direct child 注意２の解決方法 LinearLayout で指定したい要素を囲み ScrollView で指定する要素を LinearLayout の要素1つとすることで解決できます。 <ScrollView android : layout_width = "match_parent" android : layout_height = "match_parent" android : layout_marginTop = "200dp" android : isScrollContainer = "false" android : id = "@+id/scrollView" > <LinearLayout android : id = "@+id/LinearLayout" android : orientation = "vertical" android : layout_height = "fill_parent" android : layout_width = "fill_parent" > <TextView android : id = "@+id/text_view" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "「表示」を押すとDBのデータを全件表示します" /> <TextView android : id = "@+id/textView2" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : text = "２つ目のTextView" /> </LinearLayout> </ScrollView> 複数要素のスクロール おわりに 今回は ScrollView を使って特定領域をスクロールさせる方法をご紹介しました。最初は ScrollView で囲むだけなので簡単だと思っていましたが、レイアウト崩れや要素の制限などやってみると思いの他詰まり奥が深い（というか自分が知らないことが多い）なという印象です。 今後も Android アプリ開発 は続けるつもりなのでこういった記事を書いていこうと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

はじめに エンジニアは勉強しなければいけないのか？ 「知識を吸収すること」の大切さ 運営として 執筆者として 来年に向けて おわりに はじめに こんにちは、 @rs_tukki です。メリークリスマス！ というわけで、この記事は ラク ス Advent Calendar 2018の最終日の記事です。 qiita.com エンジニアとして働き始めて2年も経っていない私ですが、実は去年の10月からエンジニアブログの運営という大任を仰せつかっています。 最後の記事では、1年以上もの間このブログに中核から携わって気づいた「エンジニアが学び続けることの大切さ」について記事にしたいと思います。 エンジニアは勉強しなければいけないのか？ エンジニアという仕事をするにあたって、よく聞く言葉があります。 「エンジニアは、常に学び続ける必要がある」 正直、去年の今頃は、あまりこの言葉を信じてはいませんでした。 自分から社外の勉強会やカンファレンスに行くこともありませんでしたし、ブログの記事も最初にひとつ書いて終わりでした。「別に勉強なんかしなくても何とかなるんじゃない？」と心のどこかで感じていた気がします。 「知識を吸収すること」の大切さ ですが、今年1年、ブログの運営、あるいは執筆を続けていくうちに、社内に閉じたままではなく、社外に出て知識を得ることの大切さをひしひしと感じるようになりました。 運営として ブログの運営は、寄稿してもらった記事のチェック、投稿、アクセス数の集計などが主な仕事です。 この一年、 ラク スのエンジニアの方々の記事を見てきましたが、皆さん本当に様々な知識を持っているな、と実感しています。 Google Homeがブログの記事タイトルを読み上げるアプリを作って公開した話 - RAKUS Developers Blog | ラクス エンジニアブログ 「openSUSE」で始める初めてのLinuxデスクトップ - RAKUS Developers Blog | ラクス エンジニアブログ 新人がDockerを学習すべき4つの理由 - RAKUS Developers Blog | ラクス エンジニアブログ Android Studioで天気情報を表示するアプリを作ってみた - RAKUS Developers Blog | ラクス エンジニアブログ 5分で理解する！Google Apps Script超入門 - RAKUS Developers Blog | ラクス エンジニアブログ Dockerのコンテナ間通信~アプリとDBを繋ぐ~ - RAKUS Developers Blog | ラクス エンジニアブログ 業務に関係することだけでなく、新しい知識を積極的に取り入れている方が非常に多いです。 そしてどの方もそれを1回で終わらせず、習慣にしていることが素晴らしいと思います。Advent Calendarは募集したそばからどんどん埋まっていきました(自分は囲い込まれた側)し、社内チャットの技術チャンネルは毎日様々な話題で盛り上がっています。 そういった「勉強を推奨する風土」が、 ラク スの成長の一端なのではないかと感じています。 執筆者として 運営としてエンジニアブログに携わるだけではなく、私自身も記事を書く機会が結構あり、(この記事を除いて)全部で7本の記事を書かせていただきました。 新卒1年目が新卒0年目に贈る、5+1冊の「エンジニア虎の巻」 - RAKUS Developers Blog | ラクス エンジニアブログ Node.jsの勉強会でお手軽にWebアプリを作った話 - RAKUS Developers Blog | ラクス エンジニアブログ 自由度抜群！コスト削減！「ハイブリッドアプリ」の仕組みと「Monaca」で作るスマホアプリ - RAKUS Developers Blog | ラクス エンジニアブログ VagrantとDockerで「環境に縛られない」開発環境を構築しよう - RAKUS Developers Blog | ラクス エンジニアブログ 【新卒向け】説明力向上の虎の巻！？『Lightning Talks』のススメ - RAKUS Developers Blog | ラクス エンジニアブログ 振り返りの手法を理解しよう～KPT法編～ - RAKUS Developers Blog | ラクス エンジニアブログ 30歳以下限定の技術カンファレンス「Developers Boost」に参加してきました - RAKUS Developers Blog | ラクス エンジニアブログ 実は、このうち5本の記事が勉強会、あるいはカンファレンスで学んだ知識をもとに書いた記事です。 最初のころは、ただ何となく誘われたからとか、ブログの記事のネタになりそうだからとかで参加していた勉強会ですが、だんだんと知識をつけること自体が楽しくなってきて、最終的に1年間で 30以上 の勉強会に参加しました。 そして、そういった勉強会で身に着けた知識は、関係ないことに見えても業務で役立つことがあります。 先輩たちが話している内容が少しずつ分かるようになってきましたし、考える時間が増えたことで開発やテストも以前よりスムーズにできるようになりました。 また、自分と同年代のエンジニアがバリバリ活躍しているのを見て刺激になった、ということも多少なりあった気がしています。 来年に向けて というわけで、今ならはっきりと主張できます。 「エンジニアは、常に学び続ける必要がある」 そして来年は、ただ学ぶだけではなく、それを伝える機会を更に増やしていきたいです。 既に先輩方の中にはカンファレンスで登壇した方もいまして、登壇への憧れが日々増している今日この頃。 この前登壇してた人にまたもインタビューしてみた - RAKUS Developers Blog | ラクス エンジニアブログ PHP カンファレンス 2018 でライトニングトーク登壇してきました - RAKUS Developers Blog | ラクス エンジニアブログ このブログで記事を書いたり、勉強会で登壇したりといった 「学んだ知識をアウトプットする場」 を増やして、周りのエンジニアにも学ぶことの大切さ、楽しさを伝えていければいいなと思っています！ おわりに 今年一年、 ラク スのエンジニアブログを閲覧していただきありがとうございました。 来年以降は新卒のエンジニアを交えて、更に 「学び続けて」 いきたいと思いますので、どうぞよろしくお願いいたします！

こんにちは、 @kawanamiyuu です。先日東京で開催された PHP カンファレンス 2018 でライトニング トーク に登壇してきました。 PHP カンファレンスには毎年プライベートで参加していましたが、今回は登壇するということで会社に交通費を出してもらって参加することができました。会場近くのホテルに前泊できたので当日は朝ゆっくり寝れてありがたかったです。 イベント概要 日時 : 2018 年 12 月 15 日 (土) 会場 : 大田区産業プラザ PiO 公式 HP : http://phpcon.php.gr.jp/2018/ phpcon.php.gr.jp 登壇内容 今年の夏に開催された PHP カンファレンス関西 2018 への登壇 を業務として推進した取り組みの、その背景や具体的な施策について発表しました。 speakerdeck.com www.youtube.com 所感 発表内容としてはレギュラー トーク でも十分な話せそうなボリュームだったため、少し駆け足な発表になってしまいましたが、動画を見返したところ案外ちゃんとしゃべれていて安心しました笑。ネタによりけりですが、次回はレギュラー トーク にも挑戦してみたいと思いました。 発表の中でもお話しましたが、今年は PHP カンファレンスをはじめとしていろいろ登壇や協賛に向けての提案や取り組みを行うことができました。開発組織としても個人としても大きな一歩はもう踏み出すことができたので、来年、さらに取り組みを活発化して周囲を巻き込んで進めていきたいと思っています。