【初心者向け】ハッカソンにエンジニアとして初参加するために準備したこととその参加レポート

はじめに

先日、connpassで募集していた「はじめてのハッカソン」というイベントに参加しました。こちらがHPになります。
今回の記事はその時の参加レポートです。自分はRails(Ruby)エンジニアとして参加しました。今までハッカソンの経験はなく、参加するまでスキル面で色々と不安に思うことがありました。
ですので、今回はイベントの詳細をお伝えすると共に、ハッカソンに出るためにやっておいたほうがいいことなどを体験談をもとに話させていただきます。(今回はアイデアやタスクマネージメントなどの話ではなく、開発面の話を中心にしたいと思います。)

「はじめてのハッカソン」の概要について

このハッカソンでは事前のアンケートをもとに運営の方が5人前後のチームに分けてくれます。当日そのチームが発表され、1日でアイデア出しと実装を行います。
スケジュールについては、11時すぎくらいから昼過ぎくらいまでで作るアプリを考え、18時ごろまでに実装+プレゼン資料作成をするといった流れです。ですので、実装できる時間はだいたい5時間程度といったところです。
順位づけなどは特に行わず、誰でも気軽に参加できるハッカソンというのがこのハッカソンのコンセプトです。参加者の中にはプログラミング歴1ヶ月のような方もいました。
この「はじめてのハッカソン」はスキルに不安がある人でも気軽に参加できるのが特徴だと思います。

自チームの作品と作業担当について

今回はクリスマスプレゼントにおすすめな商品を紹介するというコンセプトのアプリケーションを作りました。商品の検索にはAmazonAPIを利用しました。 僕のチームは4人いたのですが以下のような感じで役割を分担しました。

  • フロント担当、プレゼン資料作成
  • フロント担当、画面遷移など
  • サーバーサイド担当、マージ作業
  • サーバーサイド担当、検索ロジックの作成 (自分)

言語はRuby(Rails)を利用しました。
RailsでAmazonAPIから商品を表示させるという雛形をサーバーサイド担当で実装し、その間にフロント担当は各画面のHTML, CSSを作成しました。
その後、フロント側で作成したHTMLをRailsでも利用できるようにERBに変換するマージ作業を人手で行い、完成という流れでした。

やっておいたほうがいいと思ったこと

ハッカソンでは時間がありません。ですので、調べながら開発をするという時間はなるべく減らせたほうがいいと思います。
ハッカソンで必要になるであろう機能についてあらかじめ自分で実装しておいて、それをカンペとして用意しておくとかなり早い段階でアプリの雛形を作ることができます。機能が十分になくても、雛形が完成するとしないでは精神的な面で全然違うと思います。
主にサーバーサイドの話になりますが、例えば以下のようなものはすぐに作れるようになると(覚えていると)開発が楽になると思います。

  • テーブルの作成(1:多の関係をすぐに作れるとなおよい)
  • テストデータをDBに入れる
  • 検索フォームの作成
  • 外部API(Twitter, Amazon, GoogleMapなど)のアクセスキー取得とAPIの利用方法
  • CRUD APIの作成
  • Herokuへのデプロイ
  • gitコマンド

実際、今回の作品は、自分が事前にAmazonAPIを利用して作成した商品検索のアプリを雛形にしたので、当日はかなり良いスタートを切ることができたと思います。

感想など

色々上から目線で語ってしまいましたが、正直自分の実力のなさを痛感した日でした。
もっとコーディングスキルをあげて、息を吸うように開発ができるようにしないといけないと思いました。
また、各メンバーが持っているスキルセットによってチームで採用する(できる)技術も変わってくるので、得意分野を極めつつも、自分の出来る分野を広げていこうと思いました。

そのほかに、うまく作業を分担するにはどうすればいいのかという課題があったと思います。
今回はHTMLを作成してもらい、それをRailsでも利用できるように人手でERBに変換したのですが、少し非効率な気もしました。
この辺りを他のハッカソンのチームはどうやっているか知りたいです。

最後にですが、色々な課題やうまくいかない点が多かった今回のハッカソンですが、「ハッカソンに参加する」という予定を先に入れてしまうことでプログラミングの勉強も集中してできたかなと思いました。
これからも頑張っていこうと思います。

第3回もくもく会:クラウドワークスがカフェ代わりに!?、に参加しました

恵比寿ガーデンプレイスにあるクラウドワークスのもくもく会に参加しました。今回で2回目です。 前回もそうでしたが、ここのもくもく会は参加者全員かなり集中して開発や勉強をしており、いい意味で緊張感が保てる場となっております。

今回はLTをやってきました。Qiitaで少し話題になった記事をスライドにまとめて発表しました。 ただ、5分では到底終わる内容のものではなく、LT向けの内容ではなかったなと終わってから思いました。

speakerdeck.com

次回のLTでは「作ってみた」をテーマになにか発表したいと思います。

React+Reduxで電卓作ってみました

先日、Wantedly主催の「React速習会(デスクトップアプリ)」の勉強会に参加しました。

勉強会では、ReactとReduxの概要からはじまりReact+Reduxを利用したElectronについてサンプルコードをベースに教えていただきました。 特に、Reduxについては結構な時間を割いて説明をしてもらいました。

なんとなくReduxというものに理解したつもりではいるものの、実際に手を動かさないとわからないと思い、簡単な電卓アプリをReactとReduxを利用して作成しました。(create-react-appをベースにしています。)

github.com

もしReact.jsやReduxに興味がある人は是非参考にしてみてください。 また、こちらのソースコードReact初心者の自分が試行錯誤で作ったものなので不適切な箇所などもあるかと思います。ですので、是非ともフィードバックをいただければと思っております。

React+Reduxのサンプルアプリを作成して理解が深まったのですが、一方でReduxを本当に利用する必要があるのか、Reduxを実務レベルのアプリで利用することができるのかという点に関しては少し懐疑的でもあります。 勉強会のあとに行われた懇親会でも話にあがったのですが、最新技術を身につけていくことが目的になってはいけないと思いました。 技術を知っておくことは大事ですが、常に「なにをしたいか」ということを意識しながら勉強を進めていこうと思います。

2016年11月25日 追記

今回の内容を勉強会で発表してきました。

speakerdeck.com

コーテッグのRuby on Railsもくもく会 #1に参加しました

末広町にあるコーテッグのもくもく勉強会に参加しました。 10名程度の規模で、お菓子などもありとてもアットホームな勉強会でした。 Ruby on Railsの勉強会だというのに、なぜか関数型言語について盛り上がるなど、なんでもありの勉強会でした。

自分がRailsを使い始めて思ったこととしては、環境構築(いわゆるnokogiri問題など)にコストがかかるということです。 今回の勉強会では、Dockerを使ってRailsの開発を行っているという話を伺いました。 Docker fileをどのように作成すればいいか少し勉強しないといけないですが、ライブラリの問題などで時間を取られることを考えると早いうちに使い捨てできる開発環境を作ったほうが最終的には効率がいいのかなと思いました。 11月は色々とやることがありますが、今回の勉強会で学んだ「Dockerを利用したRails開発」を早めに実現したいと思います。

(個人用メモ) React.jsとRailsを組み合わせる前に周辺技術について調べてみた

はじめに

React.jsとRailsを個別で学習しており、そろそろ二つを合わせてアプリケーションを作成したいなと思っております。
しかし、調べてみるとReact.jsとRailsを一緒にする方法としていくつかあるようでした。
ひと通りネットで調べて情報をまとめたので、以下にその内容を記載します。
自分はReact.js+Railsなアプリを作ったことがないです。各ツールについてもネットで調べただけで実際に使ったことがないので見当違いなことをいっているかもしれないです。ですので、あまり鵜呑みにしないでください。(ただし、参考資料だけはとてもわかりやすいものばかりでした。)

ReactとRailsの組み合わせかた

1.Railsのviewの中にReactを埋め込む

概要

2.Railsプロジェクトの中にReactのフロントエンドアプリを入れる

概要

  • webpackなどを利用する(ツールなどは下記に詳細を記述する)
  • Railsのasset-pipelineの仕組みには頼らない

    メリット

  • 作業としては分かれているがプロジェクトとしては一元管理される
  • npmモジュールを使ったりES6で記述できたりできる
  • npmのpackage managerを使える

    デメリット

  • フロントエンドの開発環境のセットアップが大変

3.Rails APIと Reactで分ける

概要

  • Railsjsonを返すことだけ(=API)に徹する
  • RailsAPIのみを作成するなら、 rails-apiというgemがあるのでrailsではなくそれを利用するほうがいいらしい。
  • サーバーレンダリングとか考える必要がないならこの設計がいいらしい

    メリット

  • 開発を分けることができる(デメリットといえばデメリット)

    デメリット

  • プロジェクトを別で管理しないといけない。サーバーも別で用意する必要がでてくる
  • API認証やCORSなどを考える必要がある
  • フロントとバックエンドを別のプロジェクトで管理されるため、開発のオーバーヘッドが高くなる

ビルドツールのまとめ

react, railsで調べているとwebpackとかbabelとかよくわからないのがたくさん出てくるのである程度体系的にまとめる。

モジュールハンドラー(ファイル生成系)

JSビルドツールのこと。フロントエンドのJSファイルを生成する。JSファイルのコーディングの部分で開発者の手助けをする

Webpack

  • コード分割できる
  • pluginによる拡張できる
  • Loaderという仕組みがあり、ソースコードに適用する処理を柔軟に設定できる
  • babel-loaderを使うことでes2015やJSxで記述したJSファイルを変換することができる。babelはJSXファイルをコンパイルするもの。
  • ビルドやコードの配置まではwebpack, ファイルへのフィンガープリントはSprocketsに任せるという運用
  • 機能がたくさんあるので、gulpなどを使わなくても設定ファイルを変更するだけで大体のことは実現できる。

    Browserify

  • 単一ファイル作成に特化している
  • browserify-railsを利用すると、RailsのSprocketsでbrowserifyを利用できるようになる。ただ、browserify-railsはビルドがすごい遅い。
  • ビルドに時間かかる
  • browserify-railsを導入するとnpmのモジュールとgemとして提供されているライブラリの両方がsprocketsに載せてasset precompileできるようになる。

    スクランナー(実行管理系)

  • gulpとGruntで人気を二分している。
  • JSXやLESSやSCSSなど変換する必要があるファイルをどうゆう処理で変換して、どこに出力するか「タスク」として管理してくれるもの。
  • Webpackなどを呼び出してントリポイント毎にJSファイルを一つにしたりなどする。
  • Railsのassetのコンパイルの仕組みを完全に捨てている。自由度が高いが環境構築に時間がかかる。(タスクランナーを利用せず、Browserifyなどを直接呼ぶのであれば、Rails側と住み分けができる。)
  • 「タスクランナー」の中で「モジュールハンドラー」が呼ばれるの関係性

    gulp

  • 現時点で開発コミュニティの活動が一番活発。シンプルな設定ファイルと、実行速度に定評あり。プラグインをpipeして連続実行できるため、中間ファイルの生成が不要。
  • コーラみたいなアイコン

    Grunt

  • 遅い! 設定ファイルが分かりにくい! とか言われつつもデファクト感のあるのがGrunt。プラグインが最多
  • イノシシみたいなアイコン

    (Sprockets)

  • gemのひとつでJavaScriptCSSコンパイルする仕組みが提供されている。Sprocketsはasset管理を行う。gulpとかとは対立の関係にあるものといってよい(デフォルトのコンパイラーに任せるか、フロントと切り離してフロント側のコンパイラーに作業を委譲するか、みたいな対立。)

    ライブラリ管理系

    バージョン管理などでよく利用される。フロントとバックエンドで管理ツールを分けるとWebpackが取り扱うライブラリを細かく指定できるのでメリットがある

    npm

  • node.js側

    Bower

  • フロントエンド側

おわりに

自分の短期目標としては、「ハッカソンでチームに貢献できるメンバーになる」、「バックエンドエンジニアとして開発と設計ができる」ことなので、色々調べたけれどもRailsAPI作成に専念してもらって、React.jsにフロントを全て任せるというスタンスを中心にプログラミングやっていこうと思います。
とはいえ、せっかく調べたので、react-railsやwebpackについても触りくらいは学習しておこうと思います。

参考資料

ReactとRailsの関係性とサンプルアプリケーションのまとめ - Qiita

モダンJavaScript開発環境 on Rails - クックパッド開発者ブログ

webpackを使った Rails上でのReact開発 - クックパッド開発者ブログ

BrowserifyからWebpackへの移行時の注意点 - Qiita

Ruby on Rails + Reactのベストプラクティスを模索してみる - Qiita

Webpackってどんなもの? - Qiita

ビルドツールまとめ。Gruntとかgulpとか (フロント寄り) - Qiita

RailsでAPI開発する前に知っておくべき4つのこと - Qiita