タグ

ブックマーク / patorash.hatenablog.com (22)

  • 株式会社リゾームで昇進しました(2回目) - patorashのブログ

    うちの会社は期首が9月で、今期で昇進した。世間では退職エントリーとか入社エントリーが多いから、自分は昇進エントリーを書く。(2回目) なお、1回目はこちら。3年前ですね。 patorash.hatenablog.com 課長に昇進した うちの会社ではキャリアとしてマネジメント職と専門職がある。前期までは専門職だったが、今期からはマネジメント職になる。マネジメント職になった経緯は、まぁ正直なところ横滑り的な感じではある。昨年、このポジションにいたカズさんこと id:tech-kazuhisa が退職したことで、傍から見ていた感じではあるが、チームが一気に硬直化してしまったように思えた。カズさんの存在の大きさがよくわかった1年だと感じた。 まぁそんなこんなで日々の雑談タイムや読書会などで彼らの話を聞いていると、色んな不安や不満の話が出てきたりするのだけれど、当時の自分は、違うチームのリーダーだ

    株式会社リゾームで昇進しました(2回目) - patorashのブログ
    luccafort
    luccafort 2022/09/06
    “「こうなったら、私が課長やるかー」という気持ちになってきたので、打診したところ”こういうことを言って、ちゃんと実践してくれるのって中々ないので普通にすごいことだと思う。おめでとうございます!
  • 「現場で役立つシステム設計の原則」読書会 vol.3 - patorashのブログ

    第3回の感想です。前回はこちら。 patorash.hatenablog.com 会社のブログのレポートはこちら。 tech.rhizome-e.com 3章 業務ロジックをわかりやすく整理する 私が書いていた箇条書きのメモ。 データクラスと機能クラスの話。真っ先に思い浮かんだのは、Fat Controllerである。モデルに機能を書かないでコントローラーのアクションに処理をまとめてしまうせいで、再利用できないようになってしまうやつ。やはり悪手として紹介されていた。どこに業務ロジックが定義してあるかがわかりにくくなる。 そして、共通化の手法として、汎用クラスの話があった。UtilsやCommonだが、これらもよくないとは直感的に思っていたが、やはりそうだった。同じような処理がたくさんできて、使い分けがわからなくなるというのは、ちょうど前回の読書会の感想で参加者メンバーの1人が言っていた話と

    「現場で役立つシステム設計の原則」読書会 vol.3 - patorashのブログ
    luccafort
    luccafort 2022/03/31
    “Railsだとデータソース層とドメインモデルが一体化したのがモデルになっている。”RailsというかActiveRecordなんだろうけどこれある程度の規模になると絶対に生まれる悩みなのでとてもわかりみが深い。
  • GraphQLでActiveRecord::RecordNotFoundをいい感じに処理する - patorashのブログ

    GraphQLを使ってWebAPIの構築をやっているのですが、対象のデータが存在しない(ActiveRecord::RecordNotFound)場合にどうすればいいかがわからなかったので調べました。 結論 graphql-rubyのエラーハンドリングのところに書いてありました。 graphql-ruby.org 該当箇所を抜粋すると、こういうことです。rescue_fromを使って、ActiveRecord::RecordNotFoundの場合にはGraphQL::ExecutionErrorを発行すればOK。 class MySchema < GraphQL::Schema # ... rescue_from(ActiveRecord::RecordNotFound) do |_err, _obj, _args, _ctx, field| # Raise a graphql-frien

    GraphQLでActiveRecord::RecordNotFoundをいい感じに処理する - patorashのブログ
    luccafort
    luccafort 2021/09/17
    “graphql-batchのサンプルコードのように、そもそもnullを許可したほうがいいのだろうか?と、ちょっとAPI設計的にどちらがよいのか疑問です🤔”nilなIDのデータをリクエストするって変なので許可したくないが、現実は。
  • 社内ISUCONのベンチマーカーをisucandarで作った話 - patorashのブログ

    前回の記事で、社内ISUCONをしたという話を書きました。 patorash.hatenablog.com そのときにベンチマーカーを作るのに、isucandarを使ったので、あとでまた記事を書く!と宣言していたのですが、なかなか書けず…。でも忘れないうちに書く! isucandarとは? isucandarとは、ISUCON用のベンチマーカーフレームワークです。 github.com @catatsuy さんが作ったISUCON9のベンチマーカーに感銘を受けた @rosylilly さんが作成したそうです。 @catatsuyさんがisucandarについて書いたZennの記事があります。 zenn.dev 私も実装前はこの記事読みながらも「わからんな?😇」と思ってましたが、今読むとなんとなくわかるくらいにはなりました(なんとなく、かい!) 私なりの雑な説明 以下、私なりの雑な説明をし

    社内ISUCONのベンチマーカーをisucandarで作った話 - patorashのブログ
    luccafort
    luccafort 2021/08/20
    めちゃくちゃいい話だ。最近コードがあまり書けていないので試してみたいお気持ちになった。前例があると何かを始めるときにシュッとできるし、うまくできたら社内にも展開できて最高ですね!
  • 5月になってやっていること - patorashのブログ

    4月のことを、この前書いた。 patorash.hatenablog.com もう3週間くらい経ってしまった。なかなかブログを書く時間も取れないほど、日々は慌ただしい。主に、家庭面で。まぁ岡山県も新型コロナの影響で緊急事態宣言が出てしまい、それもあって幼稚園が登校自粛になったりなど、色々あった。 まぁそれは置いといて。 5月になって取り組んでいること 前回の反省点を踏まえて、5月に取り組んでいることを並べる。 週単位でのスプリントプランニング アジャイルボード作り Rubyに関する読書会を開いた レビューする曜日を決めた モブレビューをした 一つずつ紹介する。 週単位でのスプリントプランニング まず、前回の反省で、細かなPRが沢山きてコードレビューだけで1日が終わってしまうという課題があった。 そこで、流量を決めるために、月曜日にスプリントプランニングを行うようにした。先のような課題はある

    5月になってやっていること - patorashのブログ
    luccafort
    luccafort 2021/05/22
    “毎日のようにレビューがあるとスイッチングコストが大きくなってしまう。”ぼくらとは別のアプローチだ。ぼくらはFBをすばやく返すためにレビューが来たら優先度順にチーム総出で潰す方向に倒したなー。
  • 情報格差を減らす取り組みの話 - patorashのブログ

    今期に入ってメンバーが私1人から新人(2年目)とパートナーさんが追加されて3名体制になったので、情報格差をなくすための活動に勤しんでいる。 以前にいたメンバーはそれなりに最初からRailsに詳しかったりしていたので、そこまで情報を整理しなくても勝手に学んでくれていたが、それも今思ってみるとある種の属人性と、私と年代が近く、同じ場所で働いているからお互いにサクッと聞ける、という環境メリットがあったからだなと思う。 しかし現代は令和となり、新型コロナの影響でリモートワークを余儀なくされ、メンバーの年齢は干支一周かそれ以上くらい年の離れているので、サクッと聞きづらいところもあろうかと思う。ましてや私は今や髭面坊主なのだ。 まぁ開発に取り掛かる上での情報はある程度は整備していたし、docker-composeでサクッと開発自体は開始できるようになっているし、参加しているうちにわかってくるかもなぁ〜

    情報格差を減らす取り組みの話 - patorashのブログ
    luccafort
    luccafort 2021/03/10
    railsやり始めたときにGemにコメントでなんのGemか書いてもらってたけど本来は登録されているGemと一対一になるドキュメントがほしいんだよなー。Gemそのものにあると可読性が悪くなるときがある。
  • 「その仕事、全部やめてみよう」を読んだ - patorashのブログ

    その仕事、全部やめてみよう――1%の質をつかむ「シンプルな考え方」 作者:小野 和俊発売日: 2020/07/30メディア: Kindle版 TLで見かけていて、面白そうだから買っていたのに積読していたので、消化した。 著者はクレディセゾンのCTOの小野和俊さん。プログラマ出身の経営者ならではの視点で、プログラマには非常に面白い読み物だった。若手にも中堅にもベテランにも刺さる内容だろうと思う。 タイトルは刺激的だけれど、言ってるのは「後戻りできないと思い込んでいるようなものをちゃんと見つめ直して、止めれるのであれば止めよう」というところだった。 手段の目的化になっていないか? 失敗しやすいパターンの話など、あるある過ぎて唸ってしまう。顧客を見ずに無理やり差別化とか、上司の思い付きをねじ込むとか。 また、新技術を使いたいから、製品を作るなど…。新技術は枯れていないため、問題が発生したときに

    「その仕事、全部やめてみよう」を読んだ - patorashのブログ
    luccafort
    luccafort 2021/02/09
    “谷を埋めるな、山を作れ”なるほどねー、確かにわかる。谷が気にならなくなるくらいのウヤマを作れていればあとは他に埋めるだけで他の追随を許さないような状況になるもんな。
  • has_manyの最新のデータをhas_oneで関連付けする方法 - patorashのブログ

    元ネタはこのQiitaの投稿。 qiita.com この投稿のように、UserモデルとArticleモデルが1対多になっていて、ユーザーに紐づいた最新の記事を取得したいこととかはあると思います。私がやってるプロジェクトでも似たようなことがありました。ユーザーに紐づいたデータがバージョン管理されていて、最新のが欲しいとき、とか…。 N+1が起きるコード 以下のようなModelがあったとします。 class User < ApplicationRecord has_many :articles, dependent: :destroy end class Article < ApplicationRecord belongs_to :user end これで最新の記事を取るためにメソッドを定義したら、こうなります。 class User < ApplicationRecord has_many

    has_manyの最新のデータをhas_oneで関連付けする方法 - patorashのブログ
    luccafort
    luccafort 2020/10/31
    preloadが使えるようになる、なるほど〜。
  • 開発環境で複数のRailsアプリを起動する場合はActiveJobのキュー名に気を付けよう - patorashのブログ

    アプリ連携を作っていた時に起きた現象なので、複数Railsアプリを起動する場合は気をつけましょう。 FooアプリとBarアプリがあって、どちらもActiveJobを使っていました。どちらもqueueの名前はdefaultのままにしていました。そして、同じRedisを共有していました。 こっちはFooアプリのジョブ。 class FooJob < ApplicationJob queue_as :default def perform puts "Foo" end end こっちはBarアプリのジョブ。 class BarJob < ApplicationJob queue_as :default def perform puts "Bar" end end そして、FooアプリもBarアプリもsidekiqを起動。 bundle exec sidekiq これで、BarJob.perfor

    開発環境で複数のRailsアプリを起動する場合はActiveJobのキュー名に気を付けよう - patorashのブログ
    luccafort
    luccafort 2020/10/28
    珍しいケースなんだろうけどもprefixかsuffixにアプリケーション名入れるとかが妥当な対応なのかなー。
  • CircleCIで使う処理をShellScriptにしていっている - patorashのブログ

    CircleCIで時々思わぬところでライブラリ系のキャッシュがされずにエラーになってしまうことがあった。 処理を速くするために複雑なキャッシュをするようになっていたので、それが原因である…。久々に自分で見てみても複雑だなぁ〜と思う。 patorash.hatenablog.com もっとシンプルにしたいなぁと思っていたら、たまたま以下の記事を見かけた。 qiita.com これには感銘を受けた。makeはイマイチよくわかっていないので今のところは採用しないが、.circleci/config.ymlで使っているcommand類はShellScriptにすることが可能だ。ShellScriptにすることで、ローカル環境で試しやすくなる。config.ymlに直書きだと、試しづらい。当たり前だけれどなんだか目から鱗だった。 遅くても必ず完走させるようにしたい キャッシュの不備が原因でテストがコ

    CircleCIで使う処理をShellScriptにしていっている - patorashのブログ
    luccafort
    luccafort 2020/09/30
    “ちゃんとライブラリの更新処理とキャッシュ処理をするようにした。これでもう予期しないエラーにはならないはず!😀”過去に何度かこれをやってるけど基本的には高速化するためのノウハウが足りてないんだろうな
  • スクラムで開発しようとしている - patorashのブログ

    弊社の他のプロジェクトスクラムを導入しているので、今期から、うちのプロジェクトでもスクラムやってみるか~と思って勉強中です。勉強中というかチケットの管理方法とかをを読みながら模索してルールを作ったりしました。 元々ある課題 結論からいうと、開発チームがなかった。正確には、1人だからチームじゃなかった。 私が担当しているプロジェクトは、開発チームではなく、長いことほぼ1人で担当していたため、そもそもスクラムをやるというモチベーションがありませんでした。途中で開発に参加してくれる人もいたのですが、元々違うプロジェクトを任されていて兼任になるため、私的にもなんか気を遣ってしまっていました。兼務なので、そちらが忙しくなるとフェードアウトしていってそのまま…という感じ。で、ようやく昨年新卒の後輩さんが私の下についたので、徐々に教えている状態。まだ格的にプロダクト開発には入ってないので、これから

    スクラムで開発しようとしている - patorashのブログ
    luccafort
    luccafort 2020/09/10
    いまは複数人いないから大丈夫なのかな?開発メンバーが複数になるとステータスにレビュー中みたいなものを足したくなることがある。あと終了の定義とかでよく揉める。実装完了してるけどまだデプロイしてないとか。
  • コンテナのTimezoneは統一しよう - patorashのブログ

    Railsアプリの開発中に、ちょっと物によっては時間がかかる処理があったので、ActiveJobに処理を移行させたのですが、perform_nowとperform_laterでデータを保存した時のcreated_at等が9時間ずれる現象が発生しました。 結論から書くと… 結論は、rails serverしているコンテナのTimezoneは'Asia/Tokyo'になっていたのですが、ActiveJobを処理するresqueを動かしているコンテナのTimezoneが未設定でした。 未設定だと、UTCになるのですが、Railsアプリケーション的には config.active_record.default_timezone = :local config.time_zone = 'Tokyo' となっていたので、Time.zone.nowなどをActiveJobで行ってもずれていることもなく…

    コンテナのTimezoneは統一しよう - patorashのブログ
    luccafort
    luccafort 2020/08/20
    9時間ズレてるですぐ気付ける内容だけどこういう基本的なこと忘れがちなのでちゃんとしないとですね。
  • 後輩との1on1で話したことをまとめておく - patorashのブログ

    1on1というか、今後どうしていきたいか等を話し合っている。継続的に話し合っていくので、まぁ1on1になっていくのかなとも思う。 「一人前」を定義する 目標がめちゃくちゃザックリとしていて、「一人前になる」というものなので、まずは一人前の定義を二人で行った。彼の考える一人前を聞き出して、「つまりはこういうことだろうか?」という感じで固めていった。詰まったときには、「Aさんはあなたから見て一人前と思えますか?」と聞き、そこから、どういうところが一人前と思えるのかを聞き出したりしていった。 現状を振り返る 大体一人前の定義が固まったところで、現状を振り返った。地図があっても現在地が分からなければ、その場所には向かえない。 格的にプロダクトの開発に入ってもらったことはまだないので、知識も経験もまだまだであることはわかるが、まぁそれは当然のことなので、別に落ち込むことではない。 果たしてそれは

    後輩との1on1で話したことをまとめておく - patorashのブログ
    luccafort
    luccafort 2020/07/19
    "自分自身としても「最終的にはもっと本を読もう」で終わってしまうのがなんかモヤモヤ"めちゃくちゃわかる。自分だったらこうするは伝えられるけどそれが相手にとってもそうであるかは自信がないですね。
  • SprocketsをやめてWebpackerに移行したのでどうやったか公開する - patorashのブログ

    ようやくSprocketsからWebpackerに移行したので、そのためにやったことをまとめておきます。 移行前の状態 Railsのバージョンは6.0系 Sprockets4 CoffeeScript Sass Bootstrap3を使用 yarnは使ってる 筆者(私)はECMAScriptに関してはそこまで詳しくなくて、今後習得していきたいと思っているレベル。 方針 「とにかくWebpackerに移行する」ということを念頭に置き、JavaScriptを完璧にモジュール化する等は目指さない。Webpackerで動けばいい。後でリファクタリングしていくから! Webpackerをざっくり理解する Webpackerはwebpackの設定などをほとんど意識することなく、いい感じに使えるようにしてくれるやつです。 webpackをざっくり理解する じゃあwebpackって何?となるかと思いますが

    SprocketsをやめてWebpackerに移行したのでどうやったか公開する - patorashのブログ
    luccafort
    luccafort 2020/07/04
    リクエストしたら書いてもらえた、やったぜ!!!
  • webpack実践入門を読んだ - patorashのブログ

    先日子供を車に乗せるときに背中を痛めてしまってしんどいです😥 寝返りを打つのも痛いし、咳・クシャミしても痛い状態です。どうも「ぎっくり背中」というらしいです。 出かけるのもしんどかったため、家でゴロゴロしつつ、このを読んでみました。 webpack 実践入門: webpackの基礎をしっかり理解して使いこなす 作者:soarflat発売日: 2019/08/31メディア: Kindle版 ちょうどRailsプロジェクトをwepbacker化している最中だったり、社内プロジェクトwebpackを使っていたりしてハマることが多かったので、ザっとわかっておこうと思いました。 このKindle Unlimitedに入っていたら無料で読めますし、もし入ってなくても500円で読めます。あとQiitaにも記事があるみたいですが、のほうが読みやすいかなと感じたのでKindleで読みました。 w

    webpack実践入門を読んだ - patorashのブログ
    luccafort
    luccafort 2020/06/22
    シュッと読めそうだったこと、ぼくらのチームもやっていくぞ!っていう現在進行系の話をしているのでちょうど良さそうだったので買った。
  • pgのバージョンを0.21.0にしたらセグメンテーション違反が起きなくなった - patorashのブログ

    少し前に、Railsを起動するとセグメンテーション違反が起きたが、原因がわかった的な記事を書いてた。 patorash.hatenablog.com これで落ち着いたかと思いきや、全然落ち着いておらず、またもやセグメンテーション違反が起きた。シングルプロセスでアクセスする場合は落ち着いていた感じだったのだが、Resque等のバックグラウンド処理用のワーカープロセスを起動すると、落ちまくった。heroku localを実行すると、ほぼセグメンテーション違反が起きた。 周囲に聞いてみても、落ちないですけどねーと言われるので、そのプロジェクトのGemfileを見てみたら、pgのバージョンが0.21.0だった。今は1.2.2が最新である。当初は「いやいや、もう1系出てるのに未だに0.21.0て…。アップグレードしないとダメでしょ」と思っていたのだが、試しにダウングレードしてからheroku loc

    pgのバージョンを0.21.0にしたらセグメンテーション違反が起きなくなった - patorashのブログ
    luccafort
    luccafort 2020/02/10
    1.2.2から0.21.0へのダウングレードはだいぶ厳しい。マイナーバージョンが1つ下がるレベルならまだ許容できるけど……。
  • 仕事の説明書読書会2回目 - patorashのブログ

    仕事の説明書〜あなたは今どんなゲームをしているのか〜 作者: 田宮直人,西山悠太朗,パブリック・ブレイン出版社/メーカー: 土日出版発売日: 2019/07/08メディア: 単行この商品を含むブログを見る 前回、仕事の説明書読書会を会社で始めたというエントリーを書いた。 patorash.hatenablog.com 今回で2回目。今日は2-5のイシューツリーから。前回で、問題を深掘りするロジックツリーを学びMECEに問題を切り分けてイシューの質を上げていくところだった。 イシューツリー イシューツリーはロジックツリーから出てきた課題から解決策をMECEにして分けていく。そのときに、How?を繰り返す。 問題を分解する切り口 要素分解型 因数分解型 ステップ型 対象概念型 よくある分け方ながら、言われたら成る程なと思う。 論理展開の基 演繹法 帰納法 アブダクション 前提となる事柄から

    仕事の説明書読書会2回目 - patorashのブログ
    luccafort
    luccafort 2019/09/13
    あーこうやって読書会での内容をエントリにまとめるの読むと読みたくなるな。これは良い試みなのかもしれない。でもこれは書き手の問題もあるかもしれない。ぼくが書いたら感情出すぎて駄目になりそう。
  • 仕事の説明書読書会を始めた - patorashのブログ

    以前に文化を育んでいきたいというエントリーを書いた。 patorash.hatenablog.com その際に触れていた、技術系じゃない社内読書会を開催した。毎週木曜日にしたのは、Okayama.rbと被っているのだが、私の帰りが遅くなる日をあんまり増やすのは家庭の負担になるから、木曜がいいかなと思ったため。 参加者が多い この読書会、驚いたことに参加者が12名となっている(今日は10名だったけど)。社内の、しかも開発部内のみで。元々の目的は、若手の人達に技術書以外のに触れてほしいことと、組織について考える機会を設けたかったというのがあった。 開発部全員のチャット部屋で告知 これもまた昇進エントリーのときに書いてるような上司との面談の度に、「開発部全員のチャット部屋を作ってほしい」と言っていた。これはもう事あるごとに言っていた。昇進エントリーはこちら。 patorash.hatenabl

    仕事の説明書読書会を始めた - patorashのブログ
    luccafort
    luccafort 2019/09/06
    “本の内容は人によってはやや難解な部分があったり、ピンとこないところもあったみたい”疑問に思ったことを付箋紙とかに書いておいてあとで振り返りとかしたら楽しそう。
  • Podcastを聴くようになった - patorashのブログ

    スマホを新しくしてからというもの、小さなライフ チェンジングを色々としていて、それの1つがPodcastを聴くようになったこと。仕事しながら聴いたり、家事しながら聴いたり、通勤しながら聴いたりしている。車のオーディオと接続がよくなったので、気軽にできるようになった😆 大体はエンジニアがやってるやつを流し聞きしてるんだけれど、仕事しながら聴いてるとあんまり頭には入ってこない。まぁでもラジオの代わりみたいな感じで時々「わかる!」とか「その発想はなかった」みたいな話とか出てくるので継続していこうかなと思う。 そもそもPodcastを聴かなかったのは、よいアプリを知らなかったのだけれど、スマホを機種変更したタイミングでアプリを入れ直してたらGoogle PodcastというGoogleが作ったアプリがあったので入れてみたら思いの外よかった。再生速度も細かく変えられるし。 ただ、エンジニアのPod

    Podcastを聴くようになった - patorashのブログ
    luccafort
    luccafort 2019/08/23
    podcastを1.5倍速で聞き慣れてしまうと1倍速だと遅く感じるようになるので大変オススメしない。
  • RailsにPR送ったらマージされた - patorashのブログ

    Railsに含まれているgem web-consoleに自分のPRが取り込まれた🎉 github.com 感動を残しておくためにブログに書いとく。 事の始まり 先日、Rails 6.0.0 rc1でrails newして、ごにょごにょと進めていたら、ログに以下のメッセージが出ていた。 Cannot render console from Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255 今はWindowsからHyper-V上のUbuntuに接続して開発しているため、web-consoleがホスト側のIPを許可していないってことだった。早速ググって、設定を追加しようとした。 qiita.com おー、これだこれだ…と思い、追加。 config.web_console.whitelisted_ips = '0.0.0.0/

    RailsにPR送ったらマージされた - patorashのブログ
    luccafort
    luccafort 2019/05/29
    いい話しだ。