「フェリーハッカソン 2019」参加レポート！

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の実装を担当しました。

復路のフェリー内では、アプリケーションの結合を行う傍ら、発表資料を作成し、最終日には発表も担当させていただきました。 惜しくも最優秀賞は逃しましたが、協賛企業のさくらインターネット様による、「さくらインターネット賞」をいただきました。

デモ風景

所感

初めてのハッカソンイベント参加ということもあり、一番印象に残ったことは、社外エンジニアのスキルを感じられる点でした。 社内で使われていない技術や、自分が使ったことがない技術でも、社外では一般的なことや、技術に対する温度感を身近に感じることができ、自身の知識の低さや、認識の間違いに気づかされることもありました。

また、チームで作業をする中で、他社の業態や必要とされる技術など、実際の現場でのお話もお聞きできるため、勉強会やカンファレンスより深く知見が広がる印象でした。

参加前から過酷なイベントだと聞いていましたが、終わってみると、とても楽しく、また得るものも多いイベントだっだと感じました。 フェリーというあまり自由が利かない環境の中で、社外のエンジニアの方と作業することはとても新鮮で、勉強になりました。

「フェリーハッカソン 2019」に参加してきました！

はじめに

こんにちはMasaKuです。

先日、ブログでも告知させていただきました「フェリーハッカソン2019」に参加しました。

tech-blog.rakus.co.jp

ハッカソンへの参加が初めてだったこともあり、参加前は非常に緊張しました。
しかし、社外のエンジニアの方とチームを組んで開発したり、普段使ったことが無い技術を組み合わせて新しいサービスを考えることができ、総じて貴重な経験ができました。

今回はフェリーハッカソン2019に参加してみて「良かったこと」と「悔しかったこと」について書いていきたいと思います。

フェリーハッカソンの流れ

フェリーハッカソンは３日間で行うハッカソンです。
まずは、フェリーハッカソンの流れについてご説明したいと思います。

1. ３～４人程度のグループで船や旅に対するイメージをブレインストーミング
2. 出てきた案を元にして船旅が楽しくなるようなサービスを考える
3. 各サービスを参加者全員で評価
4. 評価が良かったサービスを開発するためのチームを作成
5. 開発開始
6. 発表会

私は「旅先で見つけたお土産を船上で食べるグルメパーティー」を提案しましたが、全然刺さっていない様子でした・・・。

作成したWebアプリ

私はその後、ほかの方が考えた「大阪から大分までの移動時間約10時間を最大限暇つぶしできるWebアプリの作成」をテーマにした、乗船客が白組と黒組に分かれて対戦する50×50マスのリバーシを作成するチームに参加しました。

50×50マスのリバーシ（対戦中盤から1手で変わる石の数が想像以上に多く爽快感があります）

私はサーバサイドを担当し、PHPを用いてゲームの進行状況を管理する機能の実装を行いました。

ホワイトボードを利用したシステム設計

フェリーハッカソンに参加して良かったこと

フェリーハッカソンに参加して良かったことはいくつもありましたが、その中でも特に印象に残ったものをご紹介したいと思います。

社外のエンジニアの方と一緒に開発する経験ができた

社内のMeetupやプライベートでエンジニアの方と交流することはありますが、一緒に作業した経験はありませんでした。

そのため、ハッカソンで同じチームになったメンバーと技術領域が違った場合の作業の進め方についてまったく想像ができず、少し不安な気持ちがありました。

しかし、参加してみると、サーバサイドとフロントエンド、インフラなど、各メンバーが不足点を補いながらチーム全体として最大の効率を発揮できる担当割り振りができました。

技術領域が違っているからこそ、気を掛け合わなければならない点について意識するようになり、各機能の結合時には積極的にコミュニケーションを取りながら作業を進めることができました。

他のメンバーとは異なるユニークなスキルを持っていれば、できることの可能性も広がっていくと思ったので、自分の興味のある内容については知名度を気にせず、どんどん挑戦していきたいと思いました。

自分のすべきことを全うしようという意識ができた

自分の担当作業において、他のメンバーが扱ったことがない技術やプログラミング言語を選択している場合は、メンバーに協力を依頼できない場合があります。

そのため、開発中にトラブルが発生し実装が予定よりも遅れたとしても、自分の力で解決しなければならない状態になる場合があります。

しかし、そういったプレッシャーのかかる状況だからこそ、自分の担当機能がほかのメンバーが開発した機能と結合できた際の達成感は大きかったです。

自分に任された作業をしっかりとやり遂げるために、自分の技術を磨くこととトラブル時の状況説明を明確にすることの大切さを改めて実感することができました。

新たな技術習得に対するモチベーションが向上した

普段の業務で利用している技術については、どのように利用できるかが明確なので、今回作成したWebアプリの開発においても、自分がどのようにチームに貢献できそうかも想像できました。

しかし、外部のエンジニアの方はそれぞれの技術領域での解決方法を知っており、アドバイスを頂いた際に「そういう方法もあるんだ！」といった気づきを得ることもできました。

自分の技術領域を広げていくことで、「自分ならこうして実現するな」であったり「あの技術を組み合わせたらこんなこともできるな」といった発想力を持つことができるようになると思いました。

自分の枠にとらわれず、積極的にいろいろな技術に触れて柔軟な思考ができるようになりたいと思います。

棋譜をレシートとして出力したメンバーもいました

悔しかったこと

自分としてはうまくできると思っていたところも、かなり苦戦してしまった場面もいくつかありました。

反省点の振り返りも兼ねて2点ご紹介したいと思います。

時間内に全ての機能が実装できなかった

開発開始当初に実装しよう思っていた機能のうち、一部の機能が時間内に実装することができませんでした。

結果的に、ほかのメンバーが開発した機能とうまく連携できなかったものもありました。

Webアプリとして、より面白いものを作りたいという気持ちと、時間内に実現できそうなラインの見極めが重要だと思いました。

開発環境をしっかり整えておけばよかった

普段の業務ではマルチモニターにしたり、その他周辺機器を利用して開発を行っています。

今回、ハッカソンに参加するにあたって、荷物の関係上あまり多くの周辺機器は持ち込めないと思ったので、特にツール等は持ち込まず、普段あまり使わないタブレットPCに最低限の準備だけをして参加しました。

案の定、小さなモニターとタッチパッド操作に慣れず、実装中に操作面で足を引っ張られた場面が何度かありました。

開発環境を整えておくことで、開発の効率も変わってくると改めて実感したので、より効率よく作業をするために、今一度業務で利用している開発環境も見直すべきかと思いました。

まとめ

ハッカソン初参加ではありましたが、大変実りのある経験ができたと思います。

今回は３日間という短い期間でのチームでしたが、通常業務でのチーム開発にも通ずる経験ができたと思ったので、今回学んだ内容を反映させていきたいと思います。

開発チームという枠組みで個性を発揮しつつも、チーム開発で最大の効率が出せるようなチームメンバーになっていきたいですね。

おまけ

開発の休憩時間を利用して、別府観光にも行きました。

楽しく開発しつつ観光も楽しめる素敵なイベントになりました。

白池地獄

とり天定食

参考サイト

フェリーハッカソン2019 - connpass

Facebook

無効なURLです

フェリーハッカソン2019のまとめ - Togetter

東京開発ビアバッシュに参加しました～2019年1月編～

はじめに

こんにちは、id:FM_Harmonyです。

今回は先週開催された東京オフィスのビアバッシュについて、紹介記事を書きました。
なお、東京オフィスでのビアバッシュについては、下記の記事にて詳しく紹介されています。

tech-blog.rakus.co.jp

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

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

テーマ発表

業務カイゼンジャーニー

新年最初のビアバッシュのテーマは業務カイゼンジャーニーでした。ラクスの各製品の開発者にこんな業務カイゼンをやったよ、というお話をしていただきました。
また、テーマ発表の後にはテーマ自由の発表や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アプリの画面は以下のようになりました。

トップページ

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

使いづらい点

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

無駄な送信ボタン

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

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

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

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

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

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

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

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

送信ボタンを削除

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

キャラクターの選択操作

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

キャラクターの選択方法

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

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

まとめ

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

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

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

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

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

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

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

参考サイト

builder.japan.zdnet.com