この記事はGo7 Advent Calendar 2019五日目の記事です。 やりたいこと下記のように直列で動作し実行時間の長いGoのプログラムを、並行処理に変えて処理を効率化させます。 package main import ( "fmt" "time" ) func main() { for i := 0; i < 100; i++ { time.Sleep(2 * time.Second) // 長い処理 fmt.Println("End:", i) } }

目次 内容紹介HRT 謙虚（Humility）尊敬（Respect）信頼（Trust）あらゆる人間関係の衝突はHRTの欠如によるものコードレビューとHRT有害な人間と付き合う 有害な人への対策有害な人のパターン有害な人を追い出す社内政治、ソーシャルエンジニアリング 自分の価値を高める自分が居心地のいい場所を作る自分を売り込む逃げるという選択肢チームはパンのようなものマネジメントについて マネージャーになるべき！？サーバントリーダーの役割リーダーはパーフェクトではない（ネガティブ）フィードバックを正しく伝えるリーダーの行動指針まとめかの有名なHRTの精神の原典になっている本ということで読んでみた。 内容紹介読む前の印象としてはHRT精神ということでどんなエモい内容が書かれているんだろう…と期待していたのだがとんでもない、めちゃくちゃ実践的で（誤解を恐れずに言うと）、狡猾な内容が書かれていた。

Rails Developers Meetup 2018で「ActiveRecordデータ処理アンチパターン」というタイトルで発表してきました。 発表資料発表概要ActiveRecordはWebエンジニア達が嫌う（？）SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。 本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。 ※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。 事前に公開したエントリ発表資料に出てくる最初の事例はこちらがベースの事例となっています。 今月末のR

待望された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のエコシステムに乗っ

「基本的に運営側がすることが正しいんですよ Webの世界ってそういう論理で動いてるんですよ」理論 実はここで言われている@masarakkiさんの意見はすごくわかる。「最高にクール」なUIがクソユーザー（便宜上、UIの良さがわからないユーザーを本エントリではそう呼ぶ）によって阻止されるのは中の人としては決して喜ばしいことではない。 ユーザーは「最高にクールなUI」がわかるか？ まずこの問いから始めたい。一般ユーザーは「最高にクール」なUIがわかるか？ 答えはNOだ。彼らは「使いやすい」UIはわかっても「クール」なUIはわからない。そして「使いやすい」というのは結局各人の主観に依るものなので、この「使いやすい」UIというのは参考にはできても信用はできないものである。 この話を読んで真っ先に思い出した１つの話がある。 フラットデザインや新機種が評判どうか、というのはAppleにとっては意味が無

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

人の評価は難しい 納得感のある評価 技術力評価会 定量化しない オープンな評価 揚げ足取りをしない 複数人の専門家による評価 社外評価者 ビジネス指向 エンジニアの評価制度の設計と導入 ランクと給与をマッチさせるべきか？ 給与テーブル 市場価値で給与を決定 人を正しく評価する社会であってほしい 参考文献 先日VOYAGE GROUP エンジニアの公開ガチ評価会というイベントに行ってきた。イベントの細かな内容まとめは他の方のブログに譲るとして、エンジニアの評価についていろいろ考える良いきっかけとなったので書いてみる。 人の評価は難しい （エンジニアに限らず）人の評価は難しい。自分も人を評価する立場になって改めて思う。 付与できる昇給額やインセンティブに対して使える原資は限られている。加えて、本人の高い自己評価に対して組織の求める期待値との乖離や、他のメンバーとの相対評価の間にミスマッチがある

リードエンジニアから学ぶMedPeerのプロダクト開発という僕が所属する企業のイベントで、「アラサーエンジニアの生存戦略」というタイトルで発表しました。 発表の経緯もともとの発表の着想となったエントリはこちらになります。 技術者としてスポンジであり続けること　あるいは老害回避戦略の話 エンジニアリングとは常に学習し続けることである。 思うに、コードを書かず学習意欲を失ってしまった35歳のおじさんたちが自分がコードが書けないこと・学ばないことの言い訳として言い出し始めたのがこの「35歳定年説」の真実じゃないだろうか。 この文章は僕自身が若手とは言えない年齢となり今後シニアな立場へとなっていく中で「自分は老害化していくのではないか」という危機感から自戒も込めて書いたものである。願わくば五年後十年後自分がここに書いたような老害になっていないことを祈る。 この記事のトピックとしては、「エンジニアの

目次 検証環境前提条件オリジナルコード ベンチマーク最適化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