サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
blog.toshimaru.net
2020年にCircleCIの次世代イメージ・cimg が登場しました1。 個人のRuby on Railsプロジェクトで、従来のcircleci/rubyから次世代イメージであるところのcimg/rubyに移行してみたので紹介します。 ベースイメージの変更 circleci/ruby から cimg/ruby へ変更します。 executors: default: working_directory: ~/app docker: + - image: circleci/ruby:2.7-node-browsers - - image: cimg/ruby:2.7-browsers CircleCI 公式 Orb の利用 今回の変更とあわせて、下記2つのCircleCI公式Orbも導入しました。 CircleCI Developer Hub - circleci/ruby CircleCI
目次 TL;DRRubyで数値の0埋めRuboCopのオススメ書き方 Favor format over sprintfFavor format over String#%Prefer annotated tokens結論Rubyで数値の0埋めするときの書き方をよく忘れるのでメモ。 TL;DR結論としては下記のように書くとよい。 format("number: %09<number>d", number: 1) #=> "number: 000000001"
PR作者を自動でアサインするGitHub Actions, auto-author-assign を作った 本記事はGitHub Actions Advent Calendar 20206日目の記事です。 今日は作ったGitHub Actions、auto-author-assignの紹介をしたいと思います。 作ったきっかけPull Request(以下、PRと表記)を作成をしたとき、多くの場合そのPRの担当者(Assignee)はそのPR作者自身になるかと思います。 その「PR担当者をPR作者にアサインする」アクションを自動化した、というのが今回作成したGitHub Actionsになります。 何が嬉しいか?たくさんの人がPRを出しまくる、そんな大規模プロジェクトだとPR一覧を開いたときに 「誰がPRの担当者なのか?」がアイコンで一目でわかるようになる(Author に加えて)Assig
リードエンジニアから学ぶMedPeerのプロダクト開発という僕が所属する企業のイベントで、「アラサーエンジニアの生存戦略」というタイトルで発表しました。 発表の経緯もともとの発表の着想となったエントリはこちらになります。 技術者としてスポンジであり続けること あるいは老害回避戦略の話 エンジニアリングとは常に学習し続けることである。 思うに、コードを書かず学習意欲を失ってしまった35歳のおじさんたちが自分がコードが書けないこと・学ばないことの言い訳として言い出し始めたのがこの「35歳定年説」の真実じゃないだろうか。 この文章は僕自身が若手とは言えない年齢となり今後シニアな立場へとなっていく中で「自分は老害化していくのではないか」という危機感から自戒も込めて書いたものである。願わくば五年後十年後自分がここに書いたような老害になっていないことを祈る。 この記事のトピックとしては、「エンジニアの
本記事は『銀座Rails#21で「Fat Modelの倒し方」を発表しました』の後編になります。 当日あった質問、発表してみての感想などを書きたいと思います。 当日の質問 ファイルの置き場についてtrailblazer について初リモート登壇してみて セットアップ感想Special Thanks当日の質問ファイルの置き場について質問の文脈としては「POROファイルの置き場ってどこ?」という内容でした。 発表中でPOROは「Modelの補助輪」という表現をしましたが、役割としてはModelにあたるので置き場所もapp/models配下で問題ないと考えます。 特別な置き場を作りたくなってしまうかもしれませんが、Railsの提供するMVCのレールを逸脱しない範囲で独自路線を作っていくのが個人的には良いアプローチかなと考えています。POROをモデルの延長線上にあるものと考えれば、app/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対処のための3つのアプローチFat Modelを倒すためのアプローチとして、僕は下記の3つに分けて整理すれば良いのではと考えました。 Rai
1前提環境MySQL 5.7方法以前紹介した連番の仮想表を作るテクニックを駆使すればやりたいことが実現可能です。 MySQLで連番の仮想表を作る 日付だけのテーブルを作る対象期間、つまり2018年1月1日〜2018年1月10日までのデータを生成します。 SELECT '2018-01-01' + INTERVAL seq_no DAY AS date FROM (SELECT @seq_no := 0 AS seq_no UNION SELECT @seq_no := @seq_no + 1 AS seq_no FROM information_schema.COLUMNS LIMIT 10) tmp;
目次 対象読者採用経路について サービス経由ダイレクトメッセージ経由経歴書・レジュメ レジュメを公開するレジュメの内容日本の履歴書という悪習面接外資系(GAFAM)について企業とのコミュニケーションおすすめ企業2019年は転職というイベントがあった。 どんな感じで転職活動をしたのかを備忘録として残しておこうと思う。 対象読者主に自分のために残しておいているが、下記のような人に役立つかもしれない。 ソフトウェアエンジニアとして転職を考えている人今後転職するかもしれないソフトウェアエンジニア各社の採用担当者、あるいはヘッドハンター採用経路についてサービス経由前回の転職活動の場合は Wantedlyをメインで使って、そこから繋がったいくつかの会社を訪問した上で転職(就職)先を決めた。そのあたりは下記の記事にまとめてある。 就活日記(完) 就職 今回使ったのは主にスカウト型のサービスがメイン。転職
✕✕即時性: コミュニケーションがどれだけ早く成立するかオーディエンスへの浸透度 : オーディエンスにメッセージを届けるためにどれくらい効果的か負担: そのコミュニケーションに参加するための必要な時間と労力コンテキスト: 特定のコミュニケーション方法で必要とされるコンテキストがどれくらいあるか構成の緻密さ: 伝えたいことがどれくらい緻密に構成されていなければいけないか優れたリーダーの条件周囲から最良のものを引き出す 自分自身や少数の「ロックスター」だけを重視してはならない。周りにいるすべてのひとたちから裁量のものを引き出せ優秀な組織とそうでない組織の違いはこの能力の有無で出るメンバー個人のビジョンと企業やチームのビジョンを一致させるように支援する規範たれ リーダーは自分が期待している行動の規範となるべきまわりのひとはリーダーの悪い行動も真似ることがあるので気をつけろクソの傘たれ 上層部から
この記事は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) } }
TL;DR株式会社Gunosy → メドピア株式会社※以下ダラダラと書いた雑文。興味ある人だけ読んで。 試用期間が終わってとりあえずはやっていけそうな感じなので、いわゆる在職エントリってやつを書いてみます。 Why 在職エントリ?ある程度様々な経験も積んでシニアレベルのエンジニアとして会社側の期待値も高い中での入社となり、試用期間中は黙ってひたすら期待された成果を出せるように一生懸命働いてました。 また前職はイヤだったから辞めたとかではないので、転職してお互い「あ、なんか違う」となるのがちょっと心配でした(平たくいうと「ビビってた」ということになりますw)。 試用期間を終えてとりあえずはやっていけそうな感じになったので、報告がてら本エントリを書くことにします。 あとはキラキラ希望に満ち溢れた退職エントリや転職エントリ書ける歳でもなくなってきたなーという感じもある。 前職でやってたこと前職は
GitHub Marketplace ※v1と同一URL2つあるので、「GitHub Actions」というキーワードでGoogle検索したときに古いv1の情報が出てくることもあるので注意してください。v1前提なのかv2前提なのかで全く内容が異なってきます。 またv1が手元で使えるからといってv2が自動的に使えるわけではありません。それぞれ別物なのでv1が使えてたとしても、v2が利用可能対象ユーザーとして降ってくるまでは使えません。 導入方法設定方法は簡単。GitHub Action v2が使える対象になっていれば、下記のように表示されますので Enable Repository してください。 有効化されると、下記画面が出てくるのでGUIでポチポチワークフローを設定するもよし。 .github/workflows以下に直接YAMLを置くもよし。動くYAMLサンプルは下記の公式 start
What is HRT? アンチパターン1・コメントが怖い 説明 解決策 アンチパターン2・理由がない 説明 解決策 アンチパターン3・誹謗中傷 説明 解決策 アンチパターン4・大量コメント 説明 解決策 アンチパターン5・長大な議論 説明 解決策 なぜHRTなレビューが必要なのか? 全ては心理的安全性のため 参考情報 『Team Geek』の書評でも書いたんだけど、コードレビューのときはHRTの精神を大事にしたい。 What is HRT? HRTとは下記の3つの精神のことだ。 Humility(謙虚) Respect(尊敬) Trust(信頼) HRTについて詳しくは弊ブログの下記記事を参照。 心理的安全性の阻害はHRT精神の欠如によって起こる。常に仲間に対して謙虚、尊敬、信頼の念を持とうな。お兄さんとの約束だぞ! 『Team Geek』読んだ ~HRTの精神を知り会社でサバイブしてい
体験入社してます pic.twitter.com/f2Ga5LE5Es — toshimaru (@toshimaru_e) July 11, 2019 SmartHR社の体験入社に参加してきました。同社の体験入社制度に関しては下記の記事に詳しいです。 エンジニア向けの体験入社制度ができました - SmartHR Tech Blog 今回は体験入社を1スプリント分の一週間、営業日換算で4日間体験入社させてもらいました。 なぜ参加したか? SmartHR社のことはRubyKaigiや会社紹介資料などを通して知っており、傍目から良い会社そうだなぁという印象は持っていました。実際にSmartHRの中の人たちとも面談を通して直接話す中で、SmartHR社での働き方に興味が湧き、今回「体験入社をしてみたい!」という僕の申し出を受け入れてもらったかたちとなります。 僕が特にSmartHR社に関して良い
目次 第一世代から第二世代の比較どのように移行したらよいの?注意点 app.yaml の変更第一世代と第二世代の間の過渡期世代があるPHP7.2は dev_appserver.py が使えないApp Engine APIの移行先参考Google App Engineを第一世代から第二世代に乗り換えました。GoとPHPの環境をGoogle App Engine上にもっているのですが、それぞれGoは1.9から1.11、PHPは5.5から7.2へのアップデートとなります。 Google App Engine で動かしているGoの環境を1.9から1.11に上げた。わりとすんなりいけた — toshimaru (@toshimaru_e) May 14, 2019勢いでPHP on Google App Engine もphp 5.5からphp 7.2に上げといた — toshimaru (@tos
目次 <<識別子<<-識別子<<~識別子Tips① GitHub Syntax HighlightTips② 引数内のヒアドキュメントの書き方参考Rubyの覚えてそうで覚えられないヒアドキュメントの書き方をまとめてみたいと思います。 <<識別子これがRubyのヒアドキュメントの基本型となります。識別子であるEOSの始点の<<EOSから次に出てくるEOSまでの囲まれている部分が文字列となります。
Roppongi.rb#8で「Make Rails Documents SEO(Search Engine Optimized)」を発表しました Roppongi.rb #8にて「Make Rails Documents SEO(Search Engine Optimized)」と題して発表してきた。 発表スライドrailsdoc.github.io発表では僕が過去に行ったいくつかのRails公式ドキュメントのSEO対応の紹介とともに、現在進めているプロジェクトであるrailsdoc.github.ioを紹介した。 GitHub: railsdoc/railsdoc.github.io: Rails API Documentation. railsdoc.github.ioのゴールapi.rubyonrails.orgをSEO強くするapi.rubyonrails.orgを使いやすくする下
人の評価は難しい 納得感のある評価 技術力評価会 定量化しない オープンな評価 揚げ足取りをしない 複数人の専門家による評価 社外評価者 ビジネス指向 エンジニアの評価制度の設計と導入 ランクと給与をマッチさせるべきか? 給与テーブル 市場価値で給与を決定 人を正しく評価する社会であってほしい 参考文献 先日VOYAGE GROUP エンジニアの公開ガチ評価会というイベントに行ってきた。イベントの細かな内容まとめは他の方のブログに譲るとして、エンジニアの評価についていろいろ考える良いきっかけとなったので書いてみる。 人の評価は難しい (エンジニアに限らず)人の評価は難しい。自分も人を評価する立場になって改めて思う。 付与できる昇給額やインセンティブに対して使える原資は限られている。加えて、本人の高い自己評価に対して組織の求める期待値との乖離や、他のメンバーとの相対評価の間にミスマッチがある
目次 やりたいこと前提環境方法応用編 0からデクリメント値を倍加させる直近30日間の日付をリストアップ注意点やりたいことMySQLで実テーブルを参照せずに連番のデータを生成したい。 前提環境MySQL 5.7方法下記のようなSQLでやりたいことが実現できます。 SELECT @seq_no := 1 AS seq_no UNION SELECT @seq_no := @seq_no + 1 AS seq_no FROM information_schema.COLUMNS LIMIT 10; ポイントとしては下記の通り。 全体の構成としては、2つのSELECT文をUNIONを使って結合しているというもの@seq_noという変数を用意1つ目のSELECT文で変数を初期化する2つ目のSELECT文で初期化した変数のインクリメントの処理を行う その際にデータ件数を確保するために、MySQLで最初
rubocopの自動レビューをreviewdogを使ってやってみたのでその知見です。 追記Auto-RuboCop on CircleCI powered by reviewdog 1. config.ymlの設定2.コメントできるTokenを取得 & 設定3. rubucopの結果をreviewdogで通知完成yamlイメージなぜreviewdogなのか最後に参考資料追記本記事の GitHub Actions 版を書きました。 blogged. | reviewdogを使ってGitHub Actions上でRuboCop自動レビューを動かす - Hack Your Design! https://t.co/4u11iBjm6G — toshimaru (@toshimaru_e) May 31, 2020Auto-RuboCop on CircleCI powered by review
目次 内容紹介HRT 謙虚(Humility)尊敬(Respect)信頼(Trust)あらゆる人間関係の衝突はHRTの欠如によるものコードレビューとHRT有害な人間と付き合う 有害な人への対策有害な人のパターン有害な人を追い出す社内政治、ソーシャルエンジニアリング 自分の価値を高める自分が居心地のいい場所を作る自分を売り込む逃げるという選択肢チームはパンのようなものマネジメントについて マネージャーになるべき!?サーバントリーダーの役割リーダーはパーフェクトではない(ネガティブ)フィードバックを正しく伝えるリーダーの行動指針まとめかの有名なHRTの精神の原典になっている本ということで読んでみた。 内容紹介読む前の印象としてはHRT精神ということでどんなエモい内容が書かれているんだろう…と期待していたのだがとんでもない、めちゃくちゃ実践的で(誤解を恐れずに言うと)、狡猾な内容が書かれていた。
目次 今日の日付の取得2006年1月2日の謎Goの内部実装を覗いてみるGoの標準日付フォーマットGoの現在時刻は time.Now() で取得することができるが、フォーマットされた現在日時はどのように取得すればよいのだろうか? 今日の日付の取得 package main import ( "fmt" "time" ) func main() { // フォーマットなし現在時刻 fmt.Println(time.Now()) // フォーマットあり現在時刻 fmt.Println(time.Now().Format("2006年01月02日")) } 2006年1月2日の謎しかしここで1つの疑問が残る。Format()の引数として与えられる 2006年01月02日 はどうして2006年1月2日なのだろうか? 2001年2月3日でもダメだし1234年5月6日でもダメだ。きっちり 2006年1月
目次 本書の概要エンジニアと企業のミスマッチ良いエンジニアは市場に出ない リファラル採用が一番多い転職ルートの多様化 年収の透明化採用担当者のリテラシー企業の情報発信企業の差別化ポイント 報酬 転職すると年収が上がるバグ就業条件評価と処遇企業内教育の制度キャリアパス迷ったら採用しないという原則エンジニア採用について最近いろいろ考える機会が増えたので読んでみた。 本書の概要本書ではIT分野で人材採用のコンサルタントとして活動している著者が、「エンジニアと企業のミスマッチ」はどうして起こるのか、それをどう解決していったらよいのかを紹介している。 本書前半部分ではイケてない会社やエンジニアの採用失敗例および就職失敗例が紹介されており、後半部分では企業サイドがどうエンジニアを惹きつけ採用に結びつけたらよいかの話が書かれている。 エンジニアと企業のミスマッチ本書では下記のようにエンジニアが特性に応じ
目次 対応 Pull RequestInstall selenium-webdriverChange Capybara.javascript_driverInstall chromedriver On MacOSOn CircleCIOn TravisCI参考リンクRailsのCapybaraを使ったE2Eテスト(feature spec)をこの度、poltergeistからHeadless Chromeに乗り換えてみたのでそのときのメモ。 対応 Pull Request今回対応したPull Requestはこちら。 Use headless Chrome instead of PhantomJS(poltergeist) by toshimaru · Pull Request #211 · toshimaru/RailsTwitterClone · GitHub 思ったよりも差分はコンパ
目次 Visual Studio Team Servicesアカウントの作成プロジェクト作成アクセストークンの取得vsceのダウンロードPublisher作成vsceログイン公開!参考資料先日VSCode Extensionを公開しました。公開するにあたっての手順をメモがてら残したいと思います。 Blogged. | はじめてのVS Code Extension、Hybrid Next Plusテーマを公開しました - Hack Your Design! https://t.co/2cg3jwnT5q — toshimaru (@toshimaru_e) August 1, 2018Visual Studio Team Servicesアカウントの作成まずVSCode Extensionを公開するためには、Visual Studio Team Servicesアカウントが必要になります。
かねてより僕が開発していた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 Developers Meetup 2018で「ActiveRecordデータ処理アンチパターン」というタイトルで発表してきました。 発表資料発表概要ActiveRecordはWebエンジニア達が嫌う(?)SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。 本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。 ※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。 事前に公開したエントリ発表資料に出てくる最初の事例はこちらがベースの事例となっています。 今月末のR
1on1 をチームで実施することとなり、勉強がてら『シリコンバレー式 最強の育て方 ― 人材マネジメントの新しい常識 1on1ミーティング』と『ヤフーの1on1 ― 部下を成長させるコミュニケーションの技法』の2冊を読んだ。 ※以下、それぞれをシリコンバレー式1on1本とYahoo 1on1本と表記する 両本のちがいシリコンバレー式1on1本 1on1の必要性、1on1で何を話すべきかが体系的にまとまっている1on1の質問・伝え方例一覧が巻末にあるYahoo 1on1本 1on1における上司のロールとしてはコーチング的な要素強い1on1での改善事例、サクセスストーリーが漫画・会話形式多く書かれているコミュニケーションの細かなテクニック・Tipsも多く書かれているシリコンバレー式1on1本のほうで体系的に1on1の必要性・話すべきことを掴んで、実際に1on1の開催イメージを掴んでいくためにY
目次 検証環境前提条件オリジナルコード ベンチマーク最適化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
次のページ
このページを最初にブックマークしてみませんか?
『toshimaru/blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く