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

株式会社ラクスのITエンジニアによる技術ブログです。

Null安全なプログラミング言語、Kotlinについて調べてみた

はじめに

はじまして、新卒1年目エンジニアのyk_itgです。

今回は初めて参加したカンファレンス、JJUGで知ったプログラミング言語、Kotlinについて調べてみました。 www.java-users.jp

Kotlinとは

Kotlin(コトリン)Javaと同じ静的型付けのオブジェクト指向言語です。

開発したのは統合開発環境IntelliJ IDEAを構築しているJetBrainsで、Javaをもっと簡潔・安全になるように改良した産業利用向け汎用言語として開発されました。

また、JVM上で動作するのでほとんどの環境で実行が可能です。

なにができるの?

利用用途は幅広く、WebアプリケーションやAndroidアプリなどの開発をすることができます。

また、2017年にAndroidの公式言語になったので、安心してAndroidアプリの開発に使えます!

実行してみた

Kotlin公式サイトでお手軽に実行できます。

Kotlin Programming Language
kotlinlang.org

f:id:tech-rakus:20190204170915p:plain

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月「業務カイゼンジャーニー」~

はじめに

今回は大阪オフィスで開催された1月ビアバッシュをご紹介します。
前回のビアバッシュ記事はこちら↓

tech-blog.rakus.co.jp

テーマ発表

f:id:kasuke18:20190128083845p:plain:w500
業務カイゼンジャーニー
新年最初のビアバッシュのテーマは業務カイゼンジャーニーでした。ラクスの各製品の開発者にこんな業務カイゼンをやったよ、というお話をしていただきました。
また、テーマ発表の後にはテーマ自由の発表や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月のビアバッシュをダイジェストでお送りしました。 各チームとも課題を解決すべく様々なカイゼン活動を行っていました。課題があることは成長できる余地があるということなので、引き続きカイゼン活動を行っていきます。

ラクスも協賛!フェリーハッカソン2019に(今から)行ってくる!!

ラクスでメールディーラーの開発に携わっている@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アプリの画面は以下のようになりました。

f:id:MasaKu:20190122125133p:plain
トップページ

データベースに入力値を登録するだけの簡単なフォームですが、必要な要件はクリアしています。

使いづらい点

上記機能がすべて利用可能な既存アプリと比較して、今回作成したWebアプリの使いにくい点について、特に気になったポイントをご紹介したいと思います。

無駄な送信ボタン

私の作成したWebアプリでは、以下の操作が必要です。

  1. 使用したキャラクターをプルダウンから選択
  2. 勝敗をプルダウンから選択
  3. 送信ボタンを押下する

上記のうち必要が無い操作だと気づいたのは「3. 送信ボタンを押下する」です。

通常、送信ボタンを押す前にフォームに必要な情報が全て正しく入力できているかをユーザに確認させる必要かあります。

しかし、今回のWebアプリのような簡単な入力画面では必ずしも確認するフェーズは必要ではないのではないかと思いました。

入力間違いが許されないような画面については、送信前に確認させる意味合いも込めて、送信ボタンを押させる必要があるかと思います。
しかし、今回のような場合は少ない操作で登録できて、後から簡単に修正できるようにするのも良いかと思いました。

つまり、この操作は以下のように修正することができます。

  1. 使用したキャラクターをプルダウンから選択
  2. 勝敗ボタンを押下

f:id:MasaKu:20190122125444p:plain
送信ボタンを削除

確認ダイアログが何度も表示される画面などと似たケースにはまっていたのかもしれません。

キャラクターの選択操作

私の作成したWebアプリで使用したキャラクターを選択する場合は、プルダウンから選択する必要があります。
そのため、日本語化されたキャラクター名を探して、該当項目を選択しなければいけません。
しかし、既存アプリの場合は、キャラクターのサムネイルを選択するという方式になっていました。

f:id:MasaKu:20190120175053p:plain
キャラクターの選択方法

対象ユーザはゲームを遊んでいる人なので、キャラクターの名前と、キャラクターのサムネイルではどちらの方が馴染み深いかは言うまでもありません。
キャラクターの名前を忘れてしまうことがあっても、キャラクターそのものを識別できなくなることはほとんど無いでしょう。

選択肢がある入力フォームではプルダウンが採用されるという固定概念ができてしまっていたと感じました。

まとめ

今回は、以下の二点について勉強になりました。

  • 必要がない操作の削減
  • 探しやすい選択項目の表示方法

Webデザインにおける認知負荷では以下に気をつけなければならないようです。

  • 操作負荷 … マウスやキーボードといった機器の操作
  • 視覚負荷 … 目の前にみえる情報に気を止めたり、気付いたりすること
  • 知覚負荷 … 考えたり、記憶したり、スキーマと関連付けさせること

今回の場合は、操作負荷と視覚負荷を高めてしまった形になるかと思いました。

普段の開発業務では、モックや詳細設計書の画面イメージを元に開発を行います。
そのため、使いやすい画面とはどういう作りになっているか、ということについて、あまり意識していませんでした。

開発に携わるものとして、デザイン上のアンチパターンについてはしっかりと認識しておかなければならないと思いました。

参考サイト

builder.japan.zdnet.com

大阪・梅田エンジニアもくもく勉強会を開催しました

id:radiocat です。1月17日に大阪オフィスで初の「もくもく勉強会」を開催しましたので、今回はその模様をご報告します。

rakus.connpass.com

経緯

大阪の開発部門では毎週木曜日にもくもく勉強会を開催しています。以前のエントリーでもその様子を少しご紹介しています。

tech-blog.rakus.co.jp

2018年9月に大阪オフィスが移転して、広いセミナールームが確保できたことから、もくもく勉強会を社外向けにも開放してみてはどうかという声が上がるようになりました。そして私の所属する楽楽精算開発2課のメンバー数名と協力して最低限の運営方法などを整備してこのたび開催することになりました。

f:id:radiocat:20190117184336j:plain:w500

みんなで楽しむもくもく勉強会

まだ試行錯誤的な取り組みですが、せっかく社外の方にも参加していただくので何らかの接点を持って今後に繋げていただきたい思いがあります。もちろん「もくもく勉強会」と言うからにはエンジニアの自主学習の場であることが第一優先ですが、その中でこの場をさらに少しでも有意義な場にするために何かできることはないかと考えました。

f:id:radiocat:20190117184148j:plain:w500

もくもくすることを共有する

もくもくすることを共有できる「一言共有ボード」を準備しました。受付が終わると、まずその日にもくもくする事を一言で付箋に書いてホワイトボードに貼って頂きます。そして参加者が揃う19時ごろに付箋を見ながら自己紹介も兼ねた一言共有会を実施しました。

f:id:radiocat:20190121004240p:plain

その日やったことを参加者同士で共有し合うことで学習のモチベーションに繋がりますし、お互いが取り組んでいる技術などを知ることでエンジニア同士の交流にも繋がります。なお、付箋の記入と共有は希望者のみ実施していただくことにしていますので、共有しないと参加できないわけではありません。

もくもくのついでに交流もできる

参加者同士の交流は自由に行っていただけます。直接は会話しづらいこともあるかもしれないので、その場での連絡や情報交換を気軽にできるツールとしてSlackのチャンネルも準備しています。もちろんSlackへの参加する/しないも自由です。

また、今回は20時終了としていましたが運営メンバーで振り返りを行った結果、次回は21時を最終退出期限として自由時間を確保することにしました。もくもく勉強した後で交流時間に使っていただくも良し、もう少しキリの良いところまで自習していただくも良し、という予備時間です。もちろん、基本的に入退室は自由ですので都合のつく範囲で参加していただき、いつでも帰宅していただけます。

f:id:radiocat:20190117184452j:plain:w500

次回告知

次回は2月14日に開催予定です。既にconnpassに公開していますのでご覧下さい。

rakus.connpass.com

まだまだ試行錯誤中ですが、参加していただいた皆様と楽しみながらこの場を育てていきたいと思っています。興味を持たれた方は是非ご参加いただけましたら幸いです。

Laravel JP Conference 2019 に登壇します&協賛します

こんにちわ @kawanamiyuu です。来月開催される Laravel JP Conference 2019 に弊社から 2 名のエンジニアが登壇することになりましたのでお知らせします。また、株式会社ラクスは BRONZE スポンサーとしてイベントに協賛しています。

イベント概要

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開発チームでコードレビューを担当しています。
去年の4月からコードレビュー担当になり1年が経とうとしているので、若手(新卒2年目)がコードレビューをやって良かったこと、難しかったことなどを振り返ってみようと思います。

コードレビューとは

一言で言えば、書いたコードを他の人にレビューしてもらうこと。
主に以下について確認します。

  • コード規約違反がないか?
  • 保守性の低いコード、冗長なコードになっていないか?
  • コードミスがないか?
  • 仕様通りのコードになっているか?

コードレビュー担当をしていて良かったこと

① コードを読む力がつく

元々コードを読むことには自信がありましたが、ここ1年でかなりのコードを見たので、さらに自信がついたかなと思っています。
いろんな人が書くコードを読むので、読む力はかなりつきます。

② レビュワーの観点がつく

コードを書くときに、良いコードを書かなきゃと可読性を意識しますよね。
コードレビューをするようになってから実装をするときに、「このコードを自分がレビューするとしたら…」という視点が持てている実感あり、良いコードが書きやすくなっている自覚があります。
レビュワーとして指摘しているようなミスはできないし、書いた段階で気づけるので、効率よくコードが書けるようになった気がします。

③ 指摘が自分に返ってくる

②と繋がる話ですが、指摘した内容が自分に刺さることは少なくありません。
「偉そうに指摘したけど、人のこと言えないなぁ…自分がコード書くときは気をつけないと。」
みたいな感じです。
このようなことも含めて自分の成長に繋がっています。

④ 他の人が書くコードが読める

他の人のコードを読むことはすごく参考になります。
自分よりもエンジニア歴が長い人たちのコードが読めるので、「こういう書き方もあるんだ」と参考になることが多いです。

⑤ いろんな機能の仕様、中身を把握できる

コードレビューを行うためには最低限仕様を把握している必要があります。
開発中の機能の3〜4割程度のコードレビューを担当していますが、その分だけ仕様を把握することができています。
開発中によくわからないエラーに直面したときはいろんな機能を把握できているおかげで解決が早い事が多いです。

コードレビュー担当をしていて難しかったこと

① 指摘を出す

ベトナムの開発メンバーが書いたコードをレビューすることがほとんどです。
顔を合わせて話ができない、日本語で説明できない相手に指摘をすることになります。
指摘を返すときに、理由を明確にして相手が納得できるような指摘を返すことを心がけていますが、言語の壁があったり、指摘したことに実は意図があったりと最初は難しかったです。

② ついでに直して欲しいを指摘で返してはいけない

修正したことに関連して既存でイケてないコードがあると、ついでに直して欲しいと思うことがあります。
修正すべきなので良かれと思って指摘として伝えると、コードを書く人は不満を持ってしまうことがありました。
指摘ではないけど修正してほしいという意図をしっかり伝えて、コードを書く人に不満を持たせないように心がけています。

③ コード規約に載っていない暗黙のルール

コード規約や正しく書いていることを確認するチェックリストなどのドキュメントはありますが
どこにも書かれていないけど、こういうコードは良くないみたいな観点はあると思います。
「こういう書き方はしてほしくない」、「この場合はこういう書き方をしてほしい」、「この関数はこういう使い方をしてほしい」…etc
そういったことを明確なルールにしていくことが難しいと思いました。
ルールになっていなかったものや、指摘が多かったことをまとめたドキュメントを作成してメンバーに展開しました。

まとめ

若手のコードレビューはオススメ

コードを読む力、読むことで参考になること、コードを書くときに活かせるなど
メリットがたくさんあり、成長に繋がることが多かったと思います。
出した指摘から自分の意識と高めることができたり、レビュワーの視点が身についたり良かったことが多かったです。
コードが読めて、ある程度実装ができるなら、どんどんコードレビューを積むことは良いことではないかと思いました。

コードレビュワーが指摘するときに気をつけるべきこと

難しいと思ったことから簡単にまとめると…

  • 問題を明確にする
  • 理由を明確にする
  • 修正方法を明確にする
  • どういう観点なのか?
  • 参照すべきドキュメントがあるなら記載する
  • 指摘ではなくついでに直して欲しいことは明確に
  • 怪しいコードを見つけたら書いたコードの意図を聞いてみる

最後に

今後もコードレビュー担当を通して、成長できればと思っています。
品質向上にも貢献できるようにコードレビュー担当の観点でできることをやっていきたいと思います。

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