初心者RubyエンジニアがRailsチュートリアルに入門して2週間の感想
先週からほそぼそとRailsチュートリアルをやっていたのですが、昨日やっとチャプター14まで一通り終わらせることができたました。
今回はRailsチュートリアルを一通りやってみての感想をまとめたいと思います。
なぜ、やったか
今回Railsチュートリアルに手を出した理由は大きくわけて、ふたつあります。
- 業務では静的言語を使っているので動的言語での開発を覚えたかった
普段はC#やJavaを使用して開発を行っているので、「達人プログラマー」の毎年1つの言語を学べという教えに則って、普段とは違うRubyを使用した開発を覚えたほうが良いと考えました。なぜ、Rubyを選んだかというのにはコミュニティの活動が盛んであることやRailsというMVCフレームワークのデファクトスタンダードがあることなど様々な理由がありましたが、後述の理由が自分のなかでは大きいです。
- 転職活動をしており、Ruby on Railsを覚えたほうが選択肢が広がると思った
現在、私は転職活動をしておりWeb業界へ進みたいという思いがあります。そこで大手からスタートアップまで幅広く採用されているRuby on Railsでの開発を覚えたほうが選択肢が広がると考えました。入社してから覚えます！という意欲を見せるより、実際に手を動かして今学んでいるということをアピールできたほうが企業への自分のアピールになると思いました。
困った点は、わからないことを聞けない辛さ
Railsチュートリアルを行う上で、困った点はつまづいたときに自分のまわりに教えてくれる人が居なかったことです。まわりに教えてくれる人がいなかったため、わからない点は自分でググり倒して問題を解決しました。今思えば、Stackoverflowで質問したり、このブログなどで不明点を書けばもっと早くわからないことが解決して時間を無駄にせずに済んだかもしれません。。。
私の現職ではRuby on Railsは使用しておらず、環境もUNIXではなくWindows。なおかつ、同僚には技術的に興味をもっている仲間もいませんでした。勉強会などに参加していれば、そこで仲間ができたのかもしれませんが今はまだRubyのコミュニティ活動には参加していないので、これまた聞ける相手はおらず。。。
結果、Google先生に質問をぶつける毎日でした。
それでも、このググり倒すことで時間は無駄にしたかもしれませんが、なんとか自分で問題を解決する力が身についた気もします。
実際にやってみて気づいたこと
Railsはコマンドで色々なことができます。これが自分のこれまでの経験してきた言語と圧倒的に違う点で、最初は慣れが必要だったかなぁと思います。
それこそ最初はdb:migrateしたときにマイグレーションファイルでカラム名をtypoしていて「あれ！？これ、カラム名ってどうやって直すんや！？」なんて悩み倒したときもありました（めっちゃ恥ずかしい）
私はいきなりRailsチュートリアルに手を出したのですが、最初にドットインストールなどで一通りの基礎的な部分を学んでおけば躓くことも少なく進められたかもしれません。
Railsチュートリアルの次に何をするか
Railsチュートリアルを終え、Railsを使えるようになったかと言いますと、まだまだ手に馴染んだという感覚はないので書籍を購入して引続き、まずは勉強という感じです。
最近仕事でRailsのコードレビューをする時間が長くって、いろいろ指摘するんですが、 Railsって「Railsチュートリアル」には書いてないのに覚えないと仕事にならないこと多すぎだなと気付かされます。
Ruby on Railsを仕事にしていくための第一歩 - 酒と泪とRubyとRailsと
と、あるようにやはりRailsチュートリアルができたからといって業務ができるレベルということではなさそうです。今後はこの記事中にある参考書籍やTipsを読み漁る活動になることでしょう。
また、Railsの知識だけでなく根本は「コードを書く」ということなので、コーディングに関すること（リーダブルコードを読むとか）や、オブジェクト指向、ソフトウェアの設計、ソフトウェア・テストなど引続き学ばなければならないことはたくさんありますね。
Ruby on Railsエンジニア募集中の企業様へ
Railsチュートリアルを一通り完了しました。
エンジニア募集中の企業様、お声がけ頂く事ができましたら幸いでございます。
連絡はコメントかメールでご連絡ください！
パーフェクト Ruby on Rails
posted with amazlet at 17.02.16
RubyでHit&Blow書いてみた
どうも、Ruby初心者です。
今日、「Hit & Blow」という問題を教えていただいたので勉強中のRubyで解いてみました。
マスターマインドという呼び方が一般的なのかな？
マスターマインド - Wikipedia
コードはこちら↓
どなたか添削お願いします…
Cookpad TechConf 2017に参加してきたメモとか
Cookpad techconf 2017に参加してきました。
ライブ配信もあったようで、こちらから動画を見ることができます！
Cookpad TechConf 2017 - YouTube
やはり世界規模のサービスを運営しているということで、トークの内容はどれも聞いていて面白いものでした。 CTOのmirakuiさんのトークでは、Rubyコミッタのささださんがjoinしたというサプライズが！Herokuどうなるんだろう。
印象的だったのは丸山亮さんの「チームでプロダクト開発をするための取り組み」のトークで、作りたいものがあるけど一人で実現するのは難しいからチームでやっていくというTEAM GEEKに通じる話しがあり、チームから信頼を得るための取組みや、スケジュール管理、目標設定の話などかなり勉強になりました。
CTOのトークの中で「レシピ投稿のサービスで上場している世界唯一の企業」という紹介があったのですが、世界唯一と豪語できるのすごい。 グローバルでの開発の話も聞けてかなり刺激を受けました。
ぜひ、次回開催のときも参加したいと思いました！
以下、メモ。
cookpad tech conf
Cookpad under a microscope @mirakui
- 組織拡大に伴う課題
改善のサイクルを高速に回すためには
コード品質による事業への影響
- 開発効率
- メンテナンス性
- セキュリティ
- パフォーマンス性
1年後、10年後に手を加える可能性もある
エンジニア行動評価
- シンプルな設計になっているか
社内外の開発者全体に貢献できているか
課題共有会
自分たちの道具に責任を持つ
- サービス、企業、コードは常に増大している
- 各要因の増大に伴う課題、その解決
- 世界一規模でのRailsコードベースなのでRailsの設計から外れたところの問題を引く
- 解決した課題はオープンソースとして公開 / OSS、コミュニティへの貢献
Go Global @rejasupotaro
- 宗教もサービスのローカライズへ影響
- 地域性の理解無しでサービスローンチは厳しい
- サービスをどれくらいローカライズするか
- 当たり前品質、魅力品質
- 当たり前品質はコストをかけても満足度はかわらない
- 魅力品質はコストをかければかけるほど満足度は上がる
- 何が当たり前なのか魅力的なのかは地域で異なる
- 海外ではエクストリームなバグの修正よりも使いたく鳴るような機能へリソースを咲くほうがいい
- 検索、翻訳、その他全部が大事
Building infrastructure for our global service @sorah
サービス開発におけるデザインの取り組み方 @若月啓聡
- 価値検証のためのプロトタイピング
- 実際のデータを使って検証
- レイアウトの崩れの発見、実際の動作のイメージ
- 限定公開機能
- 現状の把握
- 定量調査
- 定性帳歳
- ユーザー認知の拡大へ
- アプリ内のお知らせ
- メール配信
モバイルアプリのABテスト @加藤 龍
- webのABテスト
- chanko + EasyAbによるAB
- webとモバイルアプリの違い
- webほど頻繁にデプロイできない
- 電波状況によって通信に失敗する可能性
- アップデートがユーザーによる
- モバイル向けAB
チームでプロダクト開発をするための取り組み @丸山亮
- 料理きろく
- スマホで撮影した料理写真のみが取り込まれる
- マネジメント(1), デザイナー(1), エンジニア(6)
- チームのパフォーマンス
- チームメンバーからの信頼を得る
- 信頼と信用は違う
- 自分なりの方法で
- 相手を信用する
- メンバーはどうつくるか、どのくらいかかるかを決めさせる
- スケジュールの予実差を確認
- 予測と現状を把握してスケジュールを常に生きた状態を維持にしておくことが重要
- 見える化/言語化
- 作るもの（理想）、現状、仮定を言語化する
- リーダーの目標＝チームの目標＝メンバーの目標の総和
- コントロール可能な目標/不可能な目標
- GHEのリポジトリで目標を管理して誰でも見えるようにしておく
- エンジニア力・ものづくり力
- すべてのIssue/PRに目を通す
- 自分でも手を動かす
- ログ設計・分析の設計
- プロダクト開発の最初から最後までを実施する
- より大きな成果を出すためにチームで開発する
