はてなブックマーク

目次 jQuery 1.4以前の書き方jQuery 1.5以上の書き方jQuery 1.8以上の書き方【発展編1】Deferredを用いた書き方 deferredとは何か？【発展編2】$.when() を用いた書き方参考本エントリは軽めのjQuery Advent Calendar 2012の14日目の記事として書きます。軽めといいながら少し重めになってしまった感がありますが、初めてのAdvent Calendar参加ということでご勘弁を。 ※ Twitter API仕様変更によりTwitter APIを使ったコード例は現在動作しなくなっていることにご注意。 jQuery 1.4以前の書き方まずは、少し古めのコード、昔のjQueryの本とかでよく見る書き方。 $.ajax({ url: "ajax.html", success: function(data) { alert('succes

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

目次 本書の概要エンジニアと企業のミスマッチ良いエンジニアは市場に出ない リファラル採用が一番多い転職ルートの多様化 年収の透明化採用担当者のリテラシー企業の情報発信企業の差別化ポイント 報酬 転職すると年収が上がるバグ就業条件評価と処遇企業内教育の制度キャリアパス迷ったら採用しないという原則エンジニア採用について最近いろいろ考える機会が増えたので読んでみた。 本書の概要本書ではIT分野で人材採用のコンサルタントとして活動している著者が、「エンジニアと企業のミスマッチ」はどうして起こるのか、それをどう解決していったらよいのかを紹介している。 本書前半部分ではイケてない会社やエンジニアの採用失敗例および就職失敗例が紹介されており、後半部分では企業サイドがどうエンジニアを惹きつけ採用に結びつけたらよいかの話が書かれている。 エンジニアと企業のミスマッチ本書では下記のようにエンジニアが特性に応じ

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

リードエンジニアから学ぶ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

:network_authentication_requiredちなみにこれのRuby元コードはどこにあるかというとrack/rackの/lib/rack/utils.rbにあります。 HTTP_STATUS_CODES = { 100 => 'Continue', 101 => 'Switching Protocols', 102 => 'Processing', 200 => 'OK', 201 => 'Created', 202 => 'Accepted', 203 => 'Non-Authoritative Information', 204 => 'No Content', 205 => 'Reset Content', 206 => 'Partial Content', 207 => 'Multi-Status', 208 => 'Already Reported', 226

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

昨年末にスクラムマスター研修を受けてきて、認定スクラムマスター (CSM)となりました。スクラムマスター研修で学んだこととして社内で共有した内容を本ブログでも共有してみようと思います。 Scrum vs Agile 〜歴史から学ぶ〜1993年: スクラム誕生2001年: アジャイルソフトウェア開発宣言 アジャイルマニフェスト: アジャイルソフトウェア開発宣言アジャイル原則: アジャイル宣言の背後にある原則アジャイルは「より良い開発/方法を探している」という状態のことです。状態なので原理的には「アジャイル開発をしている」という表現は正しくありません。振り返ってみて「あのプロジェクトはアジャイルだった」と評価できるもの。極端に言うといわゆるウォーターフォール型の開発も１つのアジャイルと定義することもできます。 Don’t do agile, be agile （訳: アジャイル開発をするな、ア

git log --graph --pretty=oneline でもいいんだけど、情報として物足りない。 エイリアスの設定によりこんな感じに美しくすることが可能です。 .gitconfigのエイリアスは下記のように設定します。 [alias] lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative lga = log --graph --all --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-com

GitHub Marketplace ※v1と同一URL２つあるので、「GitHub Actions」というキーワードでGoogle検索したときに古いv1の情報が出てくることもあるので注意してください。v1前提なのかv2前提なのかで全く内容が異なってきます。 またv1が手元で使えるからといってv2が自動的に使えるわけではありません。それぞれ別物なのでv1が使えてたとしても、v2が利用可能対象ユーザーとして降ってくるまでは使えません。 導入方法設定方法は簡単。GitHub Action v2が使える対象になっていれば、下記のように表示されますので Enable Repository してください。 有効化されると、下記画面が出てくるのでGUIでポチポチワークフローを設定するもよし。 .github/workflows以下に直接YAMLを置くもよし。動くYAMLサンプルは下記の公式 start

目次 TL;DRテーブル構成 Railsモデル構成has_many, through の定義 belongs_to, through は使えない？1. delegate を使う方法2. has_one, through を使う方法 includes も使うことができるどちらの方法が良いか？参考TL;DRhas_many+throughの逆の関連の定義には: belongs_to+throughは使えないdelegate or has_one+through が使えるhas_one+through の方が効率もよく、 includes も使えてオススメテーブル構成とあるRailsアプリケーションでこんなテーブル構成があったとします。 Railsモデル構成ユーザー（User）は複数の記事（Post）をもっていて、その記事は複数のコメント（Comment）を持っている、という状態です。 clas

自分がオーガナイザーを務めた Roppongi.rb #1で「Rails高速化戦略」という題で発表してきました。スライドは下記になります。 発表内容をこちらのブログでも文章形式でざっとまとめてみたいと思います。 Rails (Ruby) 遅いよねRailsないしRubyはプログラミング言語の中では速くはない言語であることは言うまでもないと思う1。 実際に「Rails/Ruby遅いよねって今まで思ったことある方どれくらいいますか？」と会場でも聞いてみたところ、予想では半数以上手を挙げてくれると思ったのだけど、実際は30人中3~4人くらい。あまりにも意外な結果だったので自分なりに理由を分析してみると２つあるかなと思う。 パフォーマンスを求められないから例えば社内の数人が使うような管理画面の場合。この場合、パフォーマンスよりも機能性（ちゃんと検索・閲覧できるかとかCRUD操作ができるかとか）など

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

この記事は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精神ということでどんなエモい内容が書かれているんだろう…と期待していたのだがとんでもない、めちゃくちゃ実践的で（誤解を恐れずに言うと）、狡猾な内容が書かれていた。

かねてより僕が開発していた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

(画像はウンコード・マニアより引用) 1. オブジェクト指向を理解しないダメエンジニアはオブジェクト指向を理解しません。 もちろんオブジェクト指向を理解しなくてもプログラミングはできますし、動くプログラムを書くことは可能です。しかしオブジェクト指向プログラミングを使わずに（あるいは十分に理解せずに）書いたプログラムは著しくメンテナンス性・可読性が低く、共通化すべき箇所が共通化されず無駄なロジックが散在するコードとなるでしょう。 オブジェクト指向の技術は1970年頃の登場以降、様々な進化を遂げながらも今なお開発の最前線で使われている技術です。こんなすばらしい技術を使わない手はないでしょう。 2. コードが美しくないダメエンジニアのコードは汚いです。 では美しいコードとはなんなのか。個人的には「プログラマの思想が見えるコード」「一貫性があるコード」だと思っています。 思想が見えるコードというの

Railsアプリケーションのデバッグはどのように行っていますか？　愚直にプリントデバッグ？　でも複雑なロジック内だと「このロジックのこの処理のここでピンポイントで止めたい！」という場合もありますよね。 そんなときに便利なのがpry-byebug. Githubのリンクは下記。 https://github.com/deivid-rodriguez/pry-byebug pry-byebugを使えばピンポイントで処理を止めてステップ実行が可能になります。 RequirementRuby2以上pry-byebugで使われているByebugはRuby2前提のデバッガーなので2以上が必要になってきます。 導入下記をGemfileに追加してbundle install. ユースケース例えばこんなコントローラーのロジックがあったとする。 class PostsController < Applicat

目次 僕のスペックバンクーバー来てから仕事を見つけるまでのフロー １．語学学校で英語のお勉強（2ヶ月間）２．就職活動開始１ヶ月目（レジュメ＆カバーレター送付）３．就職活動開始２ヶ月目（面接）アプライした会社面接で聞かれること 面接で聞かれた技術的なこと使ったサイト Indeed.cacraigslistlinkedinMonstar.cameetup.com海外就活にあたり参考にしたサイト・情報など [アメリカ日記12] ニューヨークで就職活動した話日本で全く冴えなかったWeb屋が海外就職する為に必要だった絶対の5カ条！アメリカでのiOSアプリ開発の仕事にありつけました その他感じたことなどここがポイント！まとめバンクーバーで就活して仕事をゲットしました。結果から言うと二ヶ月間就活して、二社からオファーをもらった。僕みたいに海外で仕事をしたいと思っているエンジニアのためにも、仕事を見つける

目次 対象読者採用経路について サービス経由ダイレクトメッセージ経由経歴書・レジュメ レジュメを公開するレジュメの内容日本の履歴書という悪習面接外資系（GAFAM）について企業とのコミュニケーションおすすめ企業2019年は転職というイベントがあった。 どんな感じで転職活動をしたのかを備忘録として残しておこうと思う。 対象読者主に自分のために残しておいているが、下記のような人に役立つかもしれない。 ソフトウェアエンジニアとして転職を考えている人今後転職するかもしれないソフトウェアエンジニア各社の採用担当者、あるいはヘッドハンター採用経路についてサービス経由前回の転職活動の場合は Wantedlyをメインで使って、そこから繋がったいくつかの会社を訪問した上で転職（就職）先を決めた。そのあたりは下記の記事にまとめてある。 就活日記(完) 就職 今回使ったのは主にスカウト型のサービスがメイン。転職

エンジニアリングとは常に学習し続けることである エンジニアリングとは常に学習し続けることである。僕がWeb技術者として生計を立てる上で大切にしているモットーだ。 ドッグイヤーな変化の激しいIT業界、変化に取り残されないためには常に学習が必要だ。今僕たちがデファクト・スタンダートとしている技術は一年後もスタンダートであり続けるだろうか？　一年くらいなら大丈夫？　じゃあ三年後は？　五年後は？ 十年後はどうだろう？ 自信をもって技術トレンドは今と変わっていないと言えるだろうか。 変化する技術トレンド Web業界の技術トレンド変化を見るにしてもその変化が激しいことは明らかだ。古くは掲示板を動かしていたPerl CGIの時代から、最強のPHP製CMS・Wordpress、継続的にバージョンアップを重ね進化を続けるWebアプリケーションフレームワーク・Ruby on Rails…。近年だとサーバーサイ