スカイダイビングしてきた

1月1日に前からやってみたかったスカイダイビングをしてきました!!

 

 

 

素人なので、後ろにプロのスカイダイバーさんについてもらって飛びました!

落ちるというより、下からすごい風圧を感じながら飛んでいるようでした。(千と千尋の神隠しのラストで千尋とハクが飛んでるシーンのイメージのままでしたw)

変な浮遊感や内蔵の気持ち悪さは全くなく、すごく快適でした!

パラシュートが開く前の落ちている時間が一番楽しかったです。

 

動画や写真はsdカードで貰ったのですが、sdカードを読み取るアダプター的なものをを持ってないことを思い出し、家用のWindowsを久し振りに使いました。

そこからGoogleDriveにあげて、やっと自分のスマホ&パソコンで確認することができました。

 

1月1日からやりたかったことを実行できたし、今年はいい年になりそうな気がします!

仕事面ではそろそろエンジニアになって丸1年になるので、しっかりしていきたいと思います! 

3ヶ月の振り返り

今の職場に来て3ヶ月がたちました。

なので個人的な振り返りKPTをしようと思います!

 

K
  • 楽しい
  • 居心地よい
  • とても手厚いサポート&フォローもらえる環境
  • 最低限のSQL読み書き出来るようになった
  • API開発ちょっとずつ慣れてきた
  • エラーハンドリング考えられるようになった
  • アプリレベルだけでなくDBレベルで制限かけることの大事さを知った

 

P
  • 問題や既存の実装を完全に理解できていないまま実装開始してしまい手戻りが起きがち
  • 既存の実装理解できてない箇所多い
  • 何か問題あったらレビューで指摘もらえると心のどこかで甘えている気がする
  • typo
  • コンテキストの共有をせず話出してしまい、相手にわかりにくい話になっていることがある

 

T
  • 問題は何なのか、解決方法は何があるのか、どうするのがベストなのか考えることの習慣化
  •  ユーザー、レビュアー、クライアント側の開発者、後々メンテする人それぞれの事を考えて実装する
  • 実装箇所以外も関連する場所は理解するよう努める
  • 人に何か質問したり伝えるときは、コンテキストを共有するようにする
  • 基本情報の勉強進める

 

感想その他

パッと思い出せるKPTはそれぞれ上記の内容でした。

とりあえず直近はTryに書いた内容を実践していきたいと思います!

また、何か思い出したら追記していこうと思います!

 

 

 

updated_atだけ更新

find_or_create_byを使う際、すでにレコードがあるときはupdated_atだけ更新して欲しいと思う状況がありました。 

 

User.find_or_create_by(name: “Hayashi”)

 

これだと既にHayashiさんが存在する場合、updated_atは更新されません。

 

 

なので以下のようにfind_or_initiaize_byしてからアップデートしようかと考えておりました。

user = find_or_initiaize_by(name: “Hayashi”)

user.update(name: “Hayashi”, updated_at: Date Time.now)

 

しかし、touchメソッドを使えばupdated_atのみ更新できると知りました!

 

User.find_or_create_by(name: “Hayashi”).touch

 

 

User.find_or_create_by(name: “Hayashi”)だと返り値は保存したオブジェクトですが、

User.find_or_create_by(name: “Hayashi”).touchとすると返り値がbooleanになるので注意する必要がありました!

 

 

 

文字列を配列に入ったハッシュに変換

文字列を配列に入ったハッシュにしたい状況がありました。

具体的には以下のような変換をしたいと思っておりました。

 

 

"[{{day: '2019/12/22', value: '5000'},{{day: '2019/12/22', value: '5000'}]"

=>

[{:day=>"2019/12/22", :value=>"5000"}, {:day=>"2019/12/22", :value=>"5000"}]

 

 

 

split(',')としてもハッシュの途中で区切られてしまうしどうしようかと思ってした時、instance_evalで解決できると知りました!!

 

instance_eval("[{day: '2019/12/22', value: '5000'},{day: '2019

12/22', value: '5000'}]")

=> [{:day=>"2019/12/22", :value=>"5000"}, {:day=>"2019/12/22", :value=>"5000"}]

 

 

感想その他

instance_evalを仕事のコードで使うのはよくないし、本来の使い方なのかは謎ですが、instance_eval使う機会が訪れて嬉しかったです!

 

 

 

TokyoGirls.rb Meetup vol.2へ参加した

本日TokyoGirls.rb Meetup vol.2へ参加しました!
去年の第一回目に参加して楽しかったし、各セッション面白そうなものばかりだったので以前から気になっておりました!
とってもよかったので記憶が薄れないうちに各セッションを聞いて感じたことや気づいたことをメモしておこうと思います!


TokyoGirls.rb とは?

「女性も参加しやすい(でも女性限定ではない)Ruby勉強会」です。

以下がイベントのリンクです!

techplay.jp


セッション

Ruby on Rails最初の一歩」(ただあき(@tdakak)さん)
  • 何か調べるとき検索でヒットする記事を参考にして済ませがちだが、やはり公式ドキュメントに目を通すことが大事
  • railsならRailsガイド、より深くなぜこう書くのかを理解するためにAPIドキュメントを見る
  • 1プルリク・1コミットの大きさを考える
  • 修正等行った際はなぜそうしたか&根拠となるソースも載せる
  • レビューでギスギスしないために人後のコミュニケーション大事

 

 

「事業知識を深掘りし、より人の役に立つサービスに改善する」(Kubota Nao(@kazenomachi_)さん)
  • 事業にコミットするにはコードを書けるだけでなくドメイン知識が必要
  • ドメイン知識が浅いと情報の分け方がわからないのでDB設計も間違えてしまうリスクがある
  • 事業知識が増えると本質的な部分でのサービス改善提案もできるようになる

 

 

「Rackミドルウェア入門のためのRackミドルウェア」(塩井美咲(しおい / @coe401_)さん)

speakerdeck.com

 

github.com

発表スライド以外にも事前資料作ってくれている!!!

 

 


「エンジニアとチームを組んで見えないものをデザインする」(羽野めぐみ(@featherplain)さん)

speakerdeck.com

  • デザイナーさんのご発表
  • figmaというツール良さそうできになる
 

「プロジェクトマネジメントへようこそ」(浪川舞(まいどる / @maidol_28)さん)

speakerdeck.com

  • タスクを見える化することで属人化も減らせる

→ただ闇雲に頑張るという状態を防げる

  • 上下関係ない人同士のフラットな1on1

→フラットな関係だからこそ言いづらいことも言えるというメリットがある

 

 

「いつもの開発のようにOSS活動をしよう」(makicamel(@makicamel)さん)

speakerdeck.com

  • エンドユーザー、開発者、レビュアー、いろんな人のことを考えて実装しているのすごい!!
  • レビュアーさんがわかりやすいように伝えるための努力も参考にしたい
  • わからない何かがわかるようになるのは楽しい

エンドユーザー、開発者、レビュアー、いろんな人のことを考えて実装しているのがすごいと思ったのですが、@makicamelさん自身は普通のこととおっしゃっており、自分も普通の事として出来るようになりたいと感じました!!

 

「絶対に後戻りしない!時短勤務ママエンジニアの、要件ヒアリング力」(ちょうかおり(@kaori_cho)さん)

  • エンジニアの仕事は問題の発見と解決

→背景を知ることが大切
→理想を正しく把握すること
→なぜ?をきく

  • 背景や目的を聞きにくい時「いつ使ってる?」「今どうやってる?」と聞いてみる
  • 「念のため作って」という顧客からの依頼には一旦使ってもらって様子を見てから追加実装対応する方向に持っていく

 


「強いエンジニアという灯」(大場寧子(@nay3)さん)

speakerdeck.com

  • エンジニアには技術を使った問題解決力・折れない心・柔軟で強いことが求められる
  • クラッチでコードが書けることが大事

→覚えることは速さの根源
→全部覚えるのは効率悪いので法則を覚える

  • 法則を意識して実装する

→そうしないとあとで全部調べないとメンテできなくなる

  • 1つ1つの実装に信念をもているようにする

→不安定な土台の上に新たな土台を載せることはできない

  • 失敗から学べることは多い

→失敗を知っているから回避できるようになる

→失敗の芽を気にせず得た成功はラッキーで再現性がない

  • 失敗の芽とうまくいくパターンの引き出しをたくさん持っておく

 


感想その他 

刺さる発表ばかりでした!!

自分が今まさに課題だと感じている問題に関係するセッションがいくつもあり、参加できてよかったです!!

 

 

日本語のtypoチェックツール

日本語のtypoチェックツールを探しておりました。

一番最初に以下のツールを見つけたので試してみました!!

 

 

enno.jp

どうやらこちらはRubyで作られているようです!

 

試してみる

試してみたのですが、日本語はなかなか難しいようで以下の例はtypoを検出してくれませんでした。

  • 本来であれあば可能です。もう一度試していただけないでしょうか。
  • 本来であれば可能です。もうう一度試していただけないでしょうか。
  • 本来であれば可能mです。もう一度試していただけないでしょうか。

 

以下の例のように明らかに文法的におかしい場合は検出してくれました!

  • 私にの正しい。

にの正しい。

にの【純粋エラー】助詞「の」「に」のいずれか一方は不要な可能性があります。

 

 

感想その他

他の日本語typoチェックツールも探していきます!!

まず次は以下のツールを試してみようと思います!

https://github.com/textlint/textlint-app/releases/

RipperとRubyParser

今日とあるプルリク上でrubyで書かれたコードをパースする話が出てきました。

気になったので調べてみました。

 

Rubyで書かれたコードをパースする方法はいくつかあるようです。

 

RubyParserを使う

gem install ruby_parser を実行してruby_parserをローカルに入れます。

その後、以下のようにすればコードをパースできます。

irb(main):001:0> require 'ruby_parser'

=> true

irb(main):003:0> p RubyParser.new.parse 'hello world'

s(:call, nil, :hello, s(:call, nil, :world))

=> s(:call, nil, :hello, s(:call, nil, :world))

 

 

 

Riooerを使う

RubyにはRipperというライブラリが用意されているようです。

以下はRipperのリファレンスマニュアルリンクです。

docs.ruby-lang.org

 

以下のようにパースできます。

irb(main):004:0> p Ripper.sexp('hello world')

[:program, :command, [:@ident, "hello", [1, 0, [:args_add_block, :vcall, [:@ident, "world", [1, 6]], false]]]]

=> [:program, [[:command, [:@ident, "hello", [1, 0]], [:args_add_block, [[:vcall, [:@ident, "world", [1, 6]]]], false]]]]

 

 

感想その他

Ripperはgem installしなくても使えるので楽ですが、パースした結果はRubyParserの方がみやすいと感じました。