You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ソフトウェアエンジニアとして成長するために続けてきた活動と、学習を支えるモチベーションは何だったのか。Repro株式会社の橋立友宏(joker1007)さんに10年以上のキャリアを振り返っていただき、それぞれのステージで意識してきたことについて寄稿いただきました。 Repro株式会社でチーフアーキテクトをしている橋立です。ネット上ではjokerの名前(@joker1007)で活動しています。 私は神戸大学法学部を卒業し、野村総合研究所でテクニカルエンジニアとして勤務、株式会社ウサギィでの受託開発を経て、フリーランスエンジニアになりました。その中で縁があったRepro株式会社に正式にジョインすることになり、CTOとして6年ほど勤務。会社のステージの変化で、立ち位置がCTOという肩書と噛み合わなくなってきたため肩書を変更し、今はチーフアーキテクトとして勤務しています。 以前、自分のブログで「ソ
しばらくRubyをあんま触ってない日々が続いてたんですが、オフラインでRubyKaigiに参加したKaigiEffectということでやる気が甦ってきたので、型を真面目に書くための準備を整えようと色々とやってました。 RubyKaigiでモダンなRubyの開発体験のデモをいくつか見たんですが、大体VSCodeだったのが生粋のVimmerである自分としては残念だったので、neovimでも色々やれるぞという環境を整えておきたかったのも一つです。 という訳で色々環境が整ったのでまとめていきます。 ちなみに、今回の題材はrbsとSteepによる型検査です。sorbetとかもありますが、自分としてはrbsの書式の方が圧倒的に好きなのでこちらでやっていきたいと思います。 (sorbetはRubyコードに直接書けるという大きなメリットはあるんだけど……) Steepを動かす まず対象のプロジェクトにSte
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
2020/10/3 に開催されたKaigi on Rails 2020に登壇してきました。 オンラインのイベントやカンファレンスに登壇したことはあるんですが、今迄割とカンファレンスの現場感みたいなのが薄いなと感じる中で、Kaigi on Railsはかなり以前の祭り感みたいなのを感じることが出来て、とても良いカンファレンスだったと思います。 特にSpatial Chatでカンファレンス会場の廊下っぽい空気を完璧とは言えないまでも再現出来てたのはとても良い試みだと思いました。 さて、私はというとキーノートを除いた通常発表のトリとして発表させていただきました。 (午前だったら寝坊してたのでやばかった……、運営チームの気遣いに感謝しておりますw) 内容は以下の通りです。 speakerdeck.com 背景とか反省とか RailsというWebアプリケーション開発のフレームワークを中心にしたカンフ
長らく改訂版をお待たせしていたパーフェクトRailsがついに新しくなります。 私は、やはり人間は締切が近くならないと働かない、という極めて重要な事実を改めて学ぶことができたのが良かったと思っています。 そろそろ献本させていただいた本は届き始めている様で、ブログやTwitter等で紹介していただけて嬉しい限りです。 全体の解説や紹介はそちらに任せるとして、私は今回担当していた箇所が大きく変わったので、それについての感想や裏話を書こうかと思います。 前回担当していた箇所 前回は、基本的に終盤のRailsの基本機能を越えたアプリケーションを作る時に助けになる章を担当していました。 元々は、そういう仕事としてRailsアプリケーションを書く上で気にしておきたいこと、というのが書かれた本が余り無く、何とかそういう本を作りたいという思いがあったので、あの辺りの章を担当させてもらいました。 正解の無い部
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く