銀座Rails#21で「Fat Modelの倒し方」を発表しました
Fat Model1まずはFatステージ1。Railsというものを全然知らない超初心者が陥るステージです。ビューに何でもかんでもロジックを書いちゃう。その結果がFat Viewです。 次にFatステージ2。ある程度Railsに慣れてきた開発者が陥るステージです。Modelへのロジック分離がうまくできず、Controllerにロジックが集中する。その結果はFat Controllerです。 最後がFatステージ3。Railsを習熟したエンジニアであればModelにロジックを寄せていくのが定石です。その結果出来上がるのはFat Modelです。 このように どんなにRailsに習熟してようと最終的にぶつかる壁がFat Model です。 Fat Model対処のための３つのアプローチFat Modelを倒すためのアプローチとして、僕は下記の3つに分けて整理すれば良いのではと考えました。 Rai
メドピア株式会社で働いてます
TL;DR株式会社Gunosy → メドピア株式会社※以下ダラダラと書いた雑文。興味ある人だけ読んで。 試用期間が終わってとりあえずはやっていけそうな感じなので、いわゆる在職エントリってやつを書いてみます。 Why 在職エントリ？ある程度様々な経験も積んでシニアレベルのエンジニアとして会社側の期待値も高い中での入社となり、試用期間中は黙ってひたすら期待された成果を出せるように一生懸命働いてました。 また前職はイヤだったから辞めたとかではないので、転職してお互い「あ、なんか違う」となるのがちょっと心配でした（平たくいうと「ビビってた」ということになりますw）。 試用期間を終えてとりあえずはやっていけそうな感じになったので、報告がてら本エントリを書くことにします。 あとはキラキラ希望に満ち溢れた退職エントリや転職エントリ書ける歳でもなくなってきたなーという感じもある。 前職でやってたこと前職は
SmartHR社に体験入社してきた - Hack Your Design!
体験入社してます pic.twitter.com/f2Ga5LE5Es — toshimaru (@toshimaru_e) July 11, 2019 SmartHR社の体験入社に参加してきました。同社の体験入社制度に関しては下記の記事に詳しいです。 エンジニア向けの体験入社制度ができました - SmartHR Tech Blog 今回は体験入社を１スプリント分の一週間、営業日換算で４日間体験入社させてもらいました。 なぜ参加したか？ SmartHR社のことはRubyKaigiや会社紹介資料などを通して知っており、傍目から良い会社そうだなぁという印象は持っていました。実際にSmartHRの中の人たちとも面談を通して直接話す中で、SmartHR社での働き方に興味が湧き、今回「体験入社をしてみたい！」という僕の申し出を受け入れてもらったかたちとなります。 僕が特にSmartHR社に関して良い
VOYAGE GROUPの『公開技術力評価会』に行ってエンジニア評価と給与設定について本気出して考えた - Hack Your Design!
人の評価は難しい 納得感のある評価 技術力評価会 定量化しない オープンな評価 揚げ足取りをしない 複数人の専門家による評価 社外評価者 ビジネス指向 エンジニアの評価制度の設計と導入 ランクと給与をマッチさせるべきか？ 給与テーブル 市場価値で給与を決定 人を正しく評価する社会であってほしい 参考文献 先日VOYAGE GROUP エンジニアの公開ガチ評価会というイベントに行ってきた。イベントの細かな内容まとめは他の方のブログに譲るとして、エンジニアの評価についていろいろ考える良いきっかけとなったので書いてみる。 人の評価は難しい （エンジニアに限らず）人の評価は難しい。自分も人を評価する立場になって改めて思う。 付与できる昇給額やインセンティブに対して使える原資は限られている。加えて、本人の高い自己評価に対して組織の求める期待値との乖離や、他のメンバーとの相対評価の間にミスマッチがある
日米ワークスタイル比較
就職活動が完了して日本の会社に勤め始めてはや１年が経った。カナダ・バンクーバーでの就労経験を経て、日本に帰国後日本の会社でWEBエンジニアとして１年間働いてみて思うところ（主に日米の技術者のワークスタイルの違いを中心に）をまとめてみようと思う1。 北米の働き方 vs 日本の働き方北米は定時で帰宅する一方、日本は残業前提なところがある。 僕の場合、北米で働いていたときは8時間の定められた労働時間後（9:00~17:00）すぐに帰宅していた。MAX残業してもせいぜい１時間、18:00前には必ず職場を出ていた。 スタートアップはバリバリ働く!?僕がカナダで務めていた会社は従業員10人ほどのスタートアップだった。僕の中で国は関係なく「小さい会社 = （人数が少ない分）バリバリ働く」という仮設があったので、僕の務めた会社も残業は日本ほどないにせよそれなりにある思っていた。 だけどその仮説は間違ってい
『その「エンジニア採用」が不幸を生む』を読んだ ~優秀エンジニアをどう採用するか~
目次 本書の概要エンジニアと企業のミスマッチ良いエンジニアは市場に出ない リファラル採用が一番多い転職ルートの多様化 年収の透明化採用担当者のリテラシー企業の情報発信企業の差別化ポイント 報酬 転職すると年収が上がるバグ就業条件評価と処遇企業内教育の制度キャリアパス迷ったら採用しないという原則エンジニア採用について最近いろいろ考える機会が増えたので読んでみた。 本書の概要本書ではIT分野で人材採用のコンサルタントとして活動している著者が、「エンジニアと企業のミスマッチ」はどうして起こるのか、それをどう解決していったらよいのかを紹介している。 本書前半部分ではイケてない会社やエンジニアの採用失敗例および就職失敗例が紹介されており、後半部分では企業サイドがどうエンジニアを惹きつけ採用に結びつけたらよいかの話が書かれている。 エンジニアと企業のミスマッチ本書では下記のようにエンジニアが特性に応じ
RuboCopチームにgemの名前を譲った話 - Hack Your Design!
かねてより僕が開発していたrubocop-railsというgemをRuboCop公式チームの要望により譲った。 僕がこのgemを作った経緯とかは下記の記事の通り。 つくったやつ | Railsと同じRuboCopの設定が利用できるrubocop-rails gemを作った - Hack Your Design! https://t.co/szG0eLPetS — toshimaru (@toshimaru_e) January 29, 2018 きっかけ 名前を譲ることになったきっかけは下記のIssue。 Extract Rails Cops in a separate · Issue #5976 · rubocop-hq/rubocop より正確にいうとこのIssueの前にRubyKaigi 2018の懇親会でRuboCop作者から僕へ間接的に打診があり、上記のIssueに至る。 Rub
Rails/ActiveRecord バッチ処理の最適化 - Hack Your Design!
目次 検証環境前提条件オリジナルコード ベンチマーク最適化1: 簡単な最適化 ベンチマーク最適化2: where & each を使う ベンチマーク最適化3: find_each を使う ベンチマーク最適化4: in_batches & update_all を使う ベンチマーク最適化5: where & update_all ベンチマーク最終結果「ActiveRecordデータ処理アンチパターン」で発表します参考リンクRailsのバッチ処理最適化の記事書いたら需要あるかな — toshimaru (@toshimaru_e) December 2, 2017ということで今日はRailsバッチ処理の最適化について書いてみたいと思います。 検証環境コードの検証に使った環境は下記の通りです。 macOS High Sierra (2.3 GHz Intel Core i5 / メモリ8G)Ru
技術者としてスポンジであり続けること あるいは老害回避戦略の話 - Hack Your Design!
エンジニアリングとは常に学習し続けることである エンジニアリングとは常に学習し続けることである。僕がWeb技術者として生計を立てる上で大切にしているモットーだ。 ドッグイヤーな変化の激しいIT業界、変化に取り残されないためには常に学習が必要だ。今僕たちがデファクト・スタンダートとしている技術は一年後もスタンダートであり続けるだろうか？ 一年くらいなら大丈夫？ じゃあ三年後は？ 五年後は？ 十年後はどうだろう？ 自信をもって技術トレンドは今と変わっていないと言えるだろうか。 変化する技術トレンド Web業界の技術トレンド変化を見るにしてもその変化が激しいことは明らかだ。古くは掲示板を動かしていたPerl CGIの時代から、最強のPHP製CMS・Wordpress、継続的にバージョンアップを重ね進化を続けるWebアプリケーションフレームワーク・Ruby on Rails…。近年だとサーバーサイ
ISUCON7に参加してきました
isuconに参加してきました。結果は400組中154位で予選敗退。予選敗退となりましたが初めてのisucon参加にしては中の上に食い込めてまぁまぁだったのではないでしょうか。 ※使用言語はRubyでした。 事前準備isuconの練習時間は取れなかったので、参加ブログや過去問を読み漁りました 使えそうな設定・ブログエントリなどはgistにまとめて秘伝のタレとして準備しておきましたまた協議中に使えそうなツール・コマンドもさらっと触っておきました当日の開発用レポジトリは事前にGitHub上にプライベートレポジトリを作成しておきチームメンバーを招待しておきましたボトルネック把握用にカジュアルに導入できるisucon用NewRelicのアカウントも作成しておきましたコミュニケーションツールとしてはSlackに専用のチャンネルを用意しておきました（今考えると新規にSlackチームを作ってもよかったか
Railsフロントエンド技術の今とこれから
待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。 Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンド Railsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ
プロセス毎のメモリ使用量を調べるコマンド
しかし、このコマンドの結果が見づらい。なので使用量の多い順にソートしてトップ10を出してみると下記のようなコマンドになります。
Amazon OpsWorksでRailsアプリを簡単Chefプロビジョニング
目次 OpsWorksとは？料金RailsをOpsWorksにデプロイしてみようデプロイ手順 スタックの追加レイヤーの定義レシピインスタンスの追加Appの設定幾つかのハマりポイント Gemfiledatabase.ymlCSSが適応されていない問題デプロイ・ディレクトリログ・ディレクトリまとめさいごに 参考本記事はChef Advent Calendar 2014の21日目の記事です。 OpsWorksとは？公式サイトの説明は下記です。 設定管理サービスである AWS OpsWorks を使用すると、ユーザーは Chef を使用して、あらゆる種類およびサイズのアプリケーションを簡単に設定および運用できます。パッケージのインストール、ソフトウェア設定およびストレージなどのリソースを含む、各コンポーネントのアプリケーションのアーキテクチャおよび仕様を定義できます。 AWS OpsWorks ポ
僕が単身海外（バンクーバー）に来て仕事を見つけるまでにやったこと
目次 僕のスペックバンクーバー来てから仕事を見つけるまでのフロー １．語学学校で英語のお勉強（2ヶ月間）２．就職活動開始１ヶ月目（レジュメ＆カバーレター送付）３．就職活動開始２ヶ月目（面接）アプライした会社面接で聞かれること 面接で聞かれた技術的なこと使ったサイト Indeed.cacraigslistlinkedinMonstar.cameetup.com海外就活にあたり参考にしたサイト・情報など [アメリカ日記12] ニューヨークで就職活動した話日本で全く冴えなかったWeb屋が海外就職する為に必要だった絶対の5カ条！アメリカでのiOSアプリ開発の仕事にありつけました その他感じたことなどここがポイント！まとめバンクーバーで就活して仕事をゲットしました。結果から言うと二ヶ月間就活して、二社からオファーをもらった。僕みたいに海外で仕事をしたいと思っているエンジニアのためにも、仕事を見つける
就活日記(0) エントリー
カナダからワーホリビザも切れるというところで帰国した。仕事も無いし金もないので日本で就職活動を開始した。その記録を残す。 使った転職サイト転職活動するにあたってはWantedlyを使用した。ソーシャルリクルーティングサイトの中では最近他のエンジニアからよく聞くホットなサイトだ。 使ってみて一番いいなと思った点はいきなり「選考開始！面接！」というよりも、「まずは話を聞いてみたい」から会社と関係を始めることが出来る点。求人文章を読んだだけでは会社の中の雰囲気まで伝わらないというのが実際。「興味はあるんだけどなー。でもまだ面接に行くほどでも…」みたいな温度感だと大体その会社をブクマしただけで応募までは行かないと思うが、Wantedlyはその辺の応募のハードルが低くて良い。 またWantedly登録後、（自分はプロフィールを充実させておいたのだが）企業からも「遊びに来ませんか？」という招待が来るこ
就活日記(6) KAIZEN platform Inc.
就活日記(0) エントリー きっかけKaizenといえばカリスマハッカー、Naoya Itoさんが勤めていることでよく知られているかと思う。ブログやプレゼン、rebuild.fmにてNaoyaさんが折に触れてKaizenについて言及するので気になって気になって仕方ない、ということで訪問。 Kaizenを支えている技術使われている技術は下記ページに紹介されているので、ここで改めて紹介する必要はないかと思う。 KAIZEN platform Inc. ではエンジニアを募集しています 開発の進め方などに関してはNaoyaさんがブログにまとめているのでそちらを読むとよいかと思う。 Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー 働き方上ページの中でも紹介されているがKaizenの働き方は特徴的だ。見出しだけ抜き出してみると、
UIの進化を止めるうんこユーザーに我々はどう立ち向かうべきか
「基本的に運営側がすることが正しいんですよ Webの世界ってそういう論理で動いてるんですよ」理論 実はここで言われている@masarakkiさんの意見はすごくわかる。「最高にクール」なUIがクソユーザー（便宜上、UIの良さがわからないユーザーを本エントリではそう呼ぶ）によって阻止されるのは中の人としては決して喜ばしいことではない。 ユーザーは「最高にクールなUI」がわかるか？ まずこの問いから始めたい。一般ユーザーは「最高にクール」なUIがわかるか？ 答えはNOだ。彼らは「使いやすい」UIはわかっても「クール」なUIはわからない。そして「使いやすい」というのは結局各人の主観に依るものなので、この「使いやすい」UIというのは参考にはできても信用はできないものである。 この話を読んで真っ先に思い出した１つの話がある。 フラットデザインや新機種が評判どうか、というのはAppleにとっては意味が無
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
