20211202のRailsに関する記事は8件です。

[rails] travel_toの不具合とその回避策

この記事は ビビッドガーデン Advent Calendar 2021 の11日目です。 自分はビビッドガーデンの社員さんじゃなくて、食べチョクの開発を週3日でお手伝いしているだけの人なのですけど、普通に記事も書かせてくれるし、この間は生産者さんの農場に行って出荷の様子を見せていただくことも出来ました。 こういう分け隔てないやり方が快適でもう一年以上お手伝いをしています。 travel_toの罠 さて、今日の話題は最近ハマったRailsの不具合について。 時刻に関わるテストをする時、timecopを使わなくても、Rails標準のTimeHelpersを使えばほぼ同等のことができるよ、というのは最近みんな知ってることになりつつあります。 食べチョクプロダクトチームでも、Timecop.travel("2020-12-14")のようなコードをtravel_to("2020-12-14")に置き換えるPRを出して一括置換しました。 ところが先日、置き換えたテストが通らなくなっていることに気づきました。CIで回している間は通っているのですが、自分の手元で走らせると落ちるのですよね。 travel_toには、travel_to("2018-01-02 15:00")という具合に文字列を渡すと、その文字列をマシンのタイムゾーンでパースしちゃう(to_time使っちゃう)という不具合があり(参考)、修正のPRがマージされています。 ただこの修正、Rails6.1ではまだマージされてないのですよね。なので、USTで動かしている自分のマシンは見事この不具合にハマってしまいました。 パッチ 標準環境使えよという気持ちもあったのですけど、こういうタイムゾーンの不具合を甘く見ていると思わぬところで足元をすくわれるので、こういうのはちゃんとやっておきたい。一方で、CIとかみんなの環境では通ってるので、そんなに長い時間はかけてられない。 ということで、さくっとパッチを書きました。 # travel_to("2019-06-25") という具合に文字列を渡すと、RailsのTimezoneではなくPCのタイムゾーンでパースしてしまう不具合がある # PRはすでにマージ済みだが 6.1時点でまだリリースされていないので、しばらくモンキーパッチを適用する # # https://github.com/rails/rails/pull/40694 # https://github.com/rails/rails/blob/6-1-stable/activesupport/lib/active_support/testing/time_helpers.rb#L157-L162 # if ActiveSupport.version >= Gem::Version.new("6.2") raise "モンキーパッチの削除を検討してください" end require "active_support/testing/time_helpers" module TimeHelpersMonkeyPatch def travel_to(date_or_time) if date_or_time.is_a?(String) super(Time.zone.parse(date_or_time)) else super end end end if Rails.env.test? ActiveSupport::Testing::TimeHelpers.prepend TimeHelpersMonkeyPatch end ・travel_toに文字列が渡されたら、Time.zone.parseでパースしてからtravel_toを呼び直すようにする ・バージョンアップしたら外すように訴えて、不必要なパッチが残らないようにする という感じの作りになっています。 まとめ Rails標準のtravel_toの不具合に関する対応について書きました。 正直最初自信なかったのですけど、Rails詳しい人とか、Rubyコミッターとかハイスキルなエンジニアが増えたことで、これは間違いなく不具合だよね、パッチ書こうか、という感じで気軽に相談することが出来て、サクサクと片付けることが出来ました。 こういうのを相談できるチームっていいですよね。 ということで、そんなチームの一員になってみたい方を募集しております。 自分みたいに勤務日数を絞って業務委託で参画するやり方もあるし、正社員になってバリバリ働く働き方もあります。興味があればぜひコンタクトしてみてくださいませ。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

フリーターからエンジニアになってみて

今回、「エンジニアになったきっかけ」に関しての記事の作成依頼があったため、記事を書かせて頂こうと思います! 「自己紹介」 「エンジニアになろうと思ったきっかけ」 「エンジニアとして働いてみた感想」 「今後はどんなエンジニアを目指したいか」 という項目で記事を書かせてもらいます。 自己紹介 2019年3月に慶応義塾大学環境情報学部を卒業し、2019年4月からポテパンキャンプというプログラミングスクールで、RORを勉強し、2020年1月からWebエンジニアとして働いています。そのため、今はエンジニア2年目となります! 主な業務としては、ECの基幹システムの内製化や新規機能の要件定義・仕様策定・実装等を担当しています。 新しい人が入ってきた際は、育成等も担当したりしています。 また、ご縁があり、つい先日から副業も始めさせて頂きました! 副業の方は、まだjoinさせて頂いて1ヶ月も経たないような状態で、1日でも早く力にならなくてはと思い、日々開発させて頂いております! エンジニアになろうと思ったきっかけ 大学4年時に、企画から実装までを3人一組のメンバと共に実装するというものがありました。 その時、私はプランナーとしてjoinさせて頂き、初めて自分が企画したものが形になりました。 嬉しい気持ちの反面、もっとプロダクトの作成に関わっていきたいという気持ちが強くなりました。 この時、私は、エンジニアになる事を決意しました。 私は、プロダクトにエンジニアとして関わり、プロダクトをグロースさせていく事やユーザーにとって良いものとは何なのかという事を考え、実装していく事がやりたいと思いました。 そのため、自社開発企業でエンジニアとして働きたいと考え、行動に移していきました! エンジニアとして働いてみた感想 コーディングするという事に関しては、意外となんとかなった所が「エンジニアとして働いてみて」最も意外な点でした。 難しい内容をいきなり振られるという事はまずないですし、ある程度コーディングができれば、「未経験での入社」としてはいいのではないかと思います。 ※学習を継続していく事は必須ですし、入社してからどんどん吸収していく姿勢というものは必要になってきます。 そして、私が最も苦労した点としては、「お作法的な部分」です。 変数・メソッド等の命名、冗長な処理の添削等、実装とは直接的には関係ないが、綺麗なコードを書くために必要な事の習得が最も苦労しました。。。 ※今も習得出来てはいない。。。 「細かい所に意識を向ける」というのは、エンジニアとして最も必要な素養のように最近感じています。 これができれば、「お作法的な部分」で、レビューで指摘される事も減るのではないのかなと思います。 私自身、もともと大雑把な性格であった事もあり、細かい所に意識を向けるという事が苦手です。 しかし、エンジニアとして働いていく中で、少しずつですが、細かい所に意識を向け、気づく事ができるようになってきていると思います。 今後のエンジニア人生においても、大きな課題になってくる事は間違いないかなと思います。 エンジニアになる前から、意識をし、生活においても細かい所に意識を配るなど、できる事は多々あったと思います。今からエンジニアを目指すのであれば、コーディングだけではなく、そのような所も意識してみると良いかもしれないですね。 今後はどんなエンジニアを目指したいか 「自分の作りたいものが作れるエンジニア」です。 こういうものが作りたいと思った時に、パパッと作成し、世の中に出す事ができるようになれると良いなと考えています!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Git環境で独自のコマンドを登録する【zsh, bash】

はじめに Railsで開発するならbundle e rails (省略)とかめちゃくちゃ使用します。 私はgit pull origin feature/add-watch-modelとか当たりまえのようにタイピングしてました。 そして今更ですがaliasで独自コマンドを設定したので1人でも誰かの役にたてば良いな と思って記事にしました。 参考記事 環境 shell: zsh 独自コマンド登録方法 とりあえず下記で登録できます。 alias g='git' でもターミナルを閉じたり分割すると使用できなくなります なのでシェルの設定ファイルに書き込みます シェルの設定ファイルへ書き込む だいたいの人はbashかzshを使用していると思いますので下記のコマンドで設定ファイルを開きます vi ~/.zshrc # zshの場合 vi ~/.bashrc # bashの場合 aliasを設定する(ちなみに私の設定内容です) iを押してINSERTモードにします # aliasの設定 alias ll='ls -l' alias la='ls -la' alias ..='cd ..' alias ...='cd ../..' alias ....='cd ../../..' alias g='git' alias gs='git status' alias gb='git branch' alias gd='git diff' alias gf='git fetch' alias gc='git commit' alias gch='git checkout' alias ga='git add' alias gcp='git cherry-pick' alias gps='git push origin $(git rev-parse --abbrev-ref HEAD)' alias gpl='git pull origin $(git rev-parse --abbrev-ref HEAD)' alias b='bundle' alias be='bundle exec' alias bi='bundle install' alias bo='bundle outdated' alias bu='bundle update' alias beru='bundle exec rubocop' alias berua='bundle exec rubocop -A' alias ber='bundle exec rspec' alias rc='bundle exec rails c' alias rcs='bundle exec rails c -s' alias rs='bundle exec rails s' alias rg='bundle exec rails generate' alias rr='bundle exec rails routes' alias rdb='bundle exec rails db' alias rmi='bundle exec rails db:migrate' alias rms='bundle exec rails db:migrate:status' alias rmr='bundle exec rails db:migrate:reset' alias v='code .' alias vs='code .' そして:wqで保存します 最後に忘れがちなやつ 下記コマンドで設定を反映させる source ~/.zshrc # zshの場合 source ~/.bashrc # bashの場合 まとめ これで快適になりました。 とくにgit pullやgit pushはめちゃくちゃ楽になりました! 他に便利な独自コマンドがあれば教えて頂けると嬉しいです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Rails】目的地の日没時刻がわかるだけのシンプルなアプリを作った

はじめに タイトル通り、目的地の日没時刻がわかるだけのシンプルなアプリを作りました。 シンプルマジックアワーというアプリです。 開発の過程などを記していきます。 アプリの説明 日付と都市を選択すると日没の時刻を表示します。 それだけだとあまりに味気なかったので、マジックアワーの時刻も付け足しました。 なぜ作ろうと思ったか 一眼レフカメラで夕焼けの写真を撮るのが趣味なのですが、綺麗な夕焼けを撮るには日没の時間を知っておく必要があります。 日没の時間が分かるアプリはごまんとあるのですが、その多くは日没時刻以外の情報もたくさん表示されます。(日の出の時刻や太陽の位置など) また、地点についても詳細な位置を取得するためにGoogleマップを利用したり、とにかく選択肢が多かったりします。 日没時間だけを知りたい私にとってはこうした情報は必要ではなく、地点の選択肢も最小限だけあれば足りると考えました。 そこで練習も兼ねて、自分にとって使いやすいシンプルなアプリを作ろうと思い立ちました。 シンプルにこだわる とにかくシンプルで分かりやすいアプリを目指しました。 はじめはGoogleマップのAPIを使って詳細な位置を取得しようと考えましたが、 操作数が多くなる点や、画面の大部分を地図が占めてしまう点を考慮してセレクトボックスにしました。 都市の選択肢についても、全国天気予報の地点を参考に最小限にとどめ、選びやすさを意識しました。 デザインに関しても、紺を基調としたシンプルなデザインにしました。 初期のデザインはとにかく単調で白と黒しか使っていませんでしたが、友人たちから「夕焼けをイメージしたデザインの方がいい」とのアドバイスを受け、己のセンスのなさを一通り痛感したのちにすぐ修正しました。 主にスマホで利用することを想定しているので、小さな画面でもはっきり見えるように情報量を制限しました。 また、スクショした時に日時と都市、時刻といった必要な情報が一つの画面に収まるようにデザインしました。 使用した技術 Rails 5.2.6 Heroku CloudFlare 日没時刻の取得はAPIおはこん番地は!?を使用。 都市の緯度経度はGeocoderというgemを使用。 コントローラ def sunset_time # 入力された値を分かりやすいようにそれぞれ変数へ year = params["date(1i)"].to_i month = params["date(2i)"].to_i day = params["date(3i)"].to_i # 都市名から緯度経度を取得して変数へ geocode = Geocoder.search(params[:city]) lat = geocode.first.coordinates[0] lng = geocode.first.coordinates[1] # それぞれの値をURIの形式に変換し、変数rise_set_paramsへ @rise_set_params= URI.encode_www_form( { mode: "sun_moon_rise_set", year: year, month: month, day: day, lat: lat, lng: lng } ) # APIを叩き、結果を受け取り変数へ rise_set_uri = URI.parse("https://labs.bitmeister.jp/ohakon/json/?#{@rise_set_params}") rise_set_json = Net::HTTP.get_response(rise_set_uri) rise_set_result = JSON.parse(rise_set_json.body @sunset_hm = rise_set_result["rise_and_set"]["sunset_hm"] end デプロイ Herokuを使ってデプロイしました。 Herokuを選んだ理由は、とにかく簡単にデプロイできるからです。 AWSという選択肢もありましたが、すでに他のアプリで使っており、EC2の稼働時間が無料枠の上限を超えてしまうため却下となりました。 また、せっかくなのでお名前.comで独自ドメインを取得しました。 ちょうどアプリ名のドメインに空きがあって良かったのですが、次からは先にドメインを決めておいたほうが良さそうです。 Googleサーチコンソールに登録 デプロイできたので意気揚々に検索をしても、アプリが出てきませんでした。 色々調べるとURLがGoogleに登録されていなかったみたいです。 この辺りはこちらの記事で解説しています。 おわりに これが2作目のアプリ開発でしたが、よかった点と改善すべき点がありました。 よかった点 「シンプルな日没時間がわかるアプリ」というコンセプトを明確にしていたことです。 これによって寄り道しすぎず、集中して開発することができました。 学習ではなく利用を目的に開発できたのもよかったです。 1作目のアプリはかなりポートフォリオ的で、学習を目的に開発していました。 Railsの基本は学べましたが、結果的に「本当に利用してもらえるのか」が不明なアプリでした。 今作はあくまで「利用してもらうこと」が目的だったので、違った目線で開発できたのはいい経験になりました。 ユーザーに投稿してもらってはじめて価値が出るアプリではなく、Webツール型のアプリなので一定の需要はあるのではと思います。 マネタイズについても期待していましたが、シンプルすぎるのかGoogleアドセンスの審査になかなか通りません。 改善すべき点 シンプルすぎる機能には改善の余地があると考えます。 例えば太陽の高度を表示できる機能や、日没時間をツイートできる機能があればもっと使いやすいと思います。 開発過程にも改善すべき点があったと思います。 出勤前の時間を使って開発していましたが、前日に30分かけて作ったデザインを翌日に1時間かけて修正するといった、大変非効率な事態がたびたび起きていました。 原因は、明確な期限を設定していなかったことにあったと思います。 色々遠回りもしましたが、自分が使いたいアプリを作れたのはとても楽しい経験でした。 また何か作ろうと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ruby biz Grand prix 2021のファイナリストに選ばれた

Catallaxy Advent Calendar 1日目を担当します、エンジニア1号です。 Ruby biz Grand prix 2021(Ruby bizグランプリ2021)へエントリーして、ファイナリストに選ばれましたので、今日はそのことに触れてみたいと思います。 Catallaxyとは 金属加工プラットフォームを提供する2015年創業スタートアップになります。2018年に現在の業態にピボットしたのち、2021年3月にはシリーズAとして約4.1億円を調達しており、現在までに累計約8億円の資金調達をしております。従業員数26名のうち、エンジニア10名、デザイナー1名、エンジニアの業務委託・インターン数名のメンバー構成になっており(2021年9月応募時点)、約半数がプロダクトに関わる業務に携わっています。 Ruby biz Grand prix 2015年からRuby bizグランプリ実行委員会が開催するRubyを活用したビジネスを表彰するもので、『Rubyを使った自社商品・サービスなどで、Rubyの特徴を活かし、「新規性」「独創性」「市場性」「将来性」に富んでおり、今後継続的に発展が期待できるビジネス事例』として、当社は金属加工プラットフォームMitsuriとその周辺プロダクトで応募しました。 過去多くのpre-IPO/post-IPOのスタートアップが受賞されていますので、その名誉ある賞を受賞したい。その一心で応募しました。 応募までのみちのり 要綱に書かれた通り、Wordベースの所定応募書式があり、そのページ数は10ページに及びました。それ以外に補足資料として追加提出できました。 Ruby 100%でRuby biz Grand prixの存在を知っているメンバーはいましたが、会社としてこのグランプリに応募するかは検討委員会を立ち上げて検討を進めました。デイリーで組織全体のことを話すようにしているため、応募するかどうかの検討するまでの意思決定は即座にできたようです。 今回の2021が初めての応募だったのですが、実は主催事務局から2020年にも郵送で案内いただいていました。その際は社内のエンジニアリソースが枯渇しており、応募に向けて進められることはなかったようです。 COVID-19の影響で2020年4月からフルリモートとなっていた当社ではエンジニアは全員リモートワークしており、気付いた人がSlackに写真を上げた時の社内のリアクションです。 書類の記載 A4 10枚にもわたる所定の応募書式を埋めていく作業は大変でした。特に、アーキテクチャ図や、株主・株主候補以外に開示するビジネスの指標はまだ整っておらず、ビジネスの指標に至っては収集・整理・開示確認を行う必要がありました。 技術面の十分な深さを説明するだけでなく、Rubyをはじめとする技術を利用してビジネスとして成り立たせることをも説明的に記載する必要があり、緊張のある取り組みでしたが、時間的な制約も多く、集中して取り組めたのはよかったかなと思います。 技術的な深堀 今日の記事ではRuby biz Grand prix 2021への応募そのものについて記述しましたが、やはりRubyを含めた技術が他社の応募との差別化要因と理解しています。そのあたりもCatallaxy Advent Calendar 2021の中で他の執筆者が触れていってもらえるといいなぁと期待しています。 最終結果 RubyWorld Conference 2021に併設されて行われる、12月15日の表彰式でなんらかの賞にCatallaxyが表彰されるかもしれません。受賞した際はCatallaxy Advent Calendarでもお知らせしますので、定期的にチェックいただければと思います。 未来の工場をつくるCatallaxyではRubyを含む幅広い技術経験のあるエンジニア採用を強化しております。 https://open.talentio.com/r/1/c/catallaxy/homes/2947
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【オブジェクト指向】コンストラクタ

コンストラクタとは Rubyのようなオブジェクト指向のプログラミング言語で使われる機能の1つで、オブジェクトを生成した際に1度だけ実行される機能を指す名称。 initialize という名前のメソッドは自動的に private に設定される。 initialize 「new」メソッドが実行された際に自動的に呼び出される class Sample def initialize p '初期化処理' end end s = Sample.new "初期化処理" => #<Sample:0x0000557ab2005168> インスタンスを生成するnewメソッドで引数を指定することで、その値をインスタンス変数に設定することが可能 class Sample def initialize(name) @name = name end def execute() p @name + ' hello' end end sample1 = Sample.new('kato') => #<Sample:0x0000557ab2595ec0 @name="kato"> sample2 = Sample.new('takagi') => #<Sample:0x0000557ab25bd740 @name="takagi"> sample1.execute => "kato hello" sample2.execute => "takagi hello" initializeを実行しない場合はクラスをnewして、インスタンスメソッドへ引数を引き渡してという処理を、各処理毎に毎回設定しなければいけない。 class Sample def name=(name) @name = name end def hello p @name + ' hello' end end s = Sample.new s.name = 'kato' p s.execute => "kato hello" 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Rails】モデルとテーブルの関係について【初学者の疑問点を簡潔に】

はじめに  本記事は、Railsの学習を始めて1ヶ月の初学者が、学習を進めていて疑問に思った点について調べた結果を備忘録も兼ねてまとめたものです。  そのため、記事の内容に誤りが含まれている可能性があります。ご容赦ください。  間違いを見つけた方は、お手数ですが、ご指摘いただけますと幸いです。 今回の疑問点  今回の疑問点は、   ・モデルとテーブルの関係    です。   現在、Twitterクローンを作成しており、フォロー/フォロワー機能の実装の際に上記について疑問を抱きました。   疑問点についての解説 モデルとテーブルの関係について 結論:テーブルとコントローラをモデルがつなぎ、モデルとテーブルの関連付けは、それぞれの名前によってRailsが自動的に行う。  モデルとは  モデルとは、コントローラとテーブルとの繋ぎ役です。コントローラから指示を受けてデータベースとの間で情報のやり取りを行います。簡単に表すと以下の通りです。           コントローラ ⇄ モデル ⇄ データーベース     データベースとは  データーベースとは、データを格納する保存先です。さまざまなデータを整理して格納したテーブルが複数保管されています。       テーブルについて  テーブルには、データを整理するために、表計算ソフトのような表形式でデータが格納されています。  データベースとテーブルの関係は以下の通りです。   ※データベースには複数のテーブルが保管されています。      データベース       ・テーブルa      ・テーブルb      ・テーブルc         :      モデルとテーブルの関連付けについて  モデルとテーブルの関連付けは、それぞれの名前によってRailsが自動的に行います。そのため、命名規則に従い、モデルとテーブルの名前をつける必要があります。命名規則については、Railsにおける命名規則をご参照ください。 まとめ  モデルとテーブルの関係については、テーブルとコントローラをモデルがつなぎ、モデルとテーブルの関連づけは、命名規則に基づき付けられたそれぞれの名前によって、Railsが自動的に行うということがわかりました。最後に簡単に図示します。     コントローラ ⇄ モデル ⇄ テーブル(inデータベース)                ↑関連付けは、モデル及びテーブルの名前により自動的に行われる。    
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Rails】モデルとテーブルの関係について【初学者の疑問点を】【本当に簡潔に】

はじめに  本記事は、Railsの学習を始めて1ヶ月の初学者が、学習を進めていて疑問に思った点について調べた結果を備忘録も兼ねてまとめたものです。  そのため、記事の内容に誤りが含まれている可能性があります。ご容赦ください。  間違いを見つけた方は、お手数ですが、ご指摘いただけますと幸いです。 今回の疑問点  今回の疑問点は、   ・モデルとテーブルの関係    です。   現在、Twitterクローンを作成しており、フォロー/フォロワー機能の実装の際にアソシエーションの上記について疑問を抱きました。   疑問点についての解説 モデルとテーブルの関係について 結論:  モデルとは  モデルとは、コントローラとテーブルとの繋ぎ役です。コントローラから指示を受けてデータベースとの間で情報のやり取りを行います。簡単に表すと以下の通りです。      コントローラ ⇄ モデル ⇄ データーベース       データベースとは  データーベースとは、データを格納する保存先です。さまざまなデータを整理して格納したテーブルが複数保管されています。           テーブルについて  テーブルには、データを整理するために、表計算ソフトのような表形式でデータが格納されています。  データベースとテーブルの関係は以下の通りです。    データベース        ・テーブルa       ・テーブルb       ・テーブルc          :                     
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む