On August 15, 2018 GitHub was deployed to production running Rails 5.2. This was a historic event; for years GitHub had been behind Rails and dependent on a custom fork of Rails 2.3. This talk will visit GitHub's past, including our tumultuous relationship with the Rails framework, and the grueling effort it took to get our application on the latest version. You’ll learn what mistakes to avoid and

バックエンド二人（うち一人フロントエンド兼任）、フロントエンド一人という最小構成のチームにおける、バックエンド開発の効率化を模索する試みについてお話します。 具体的な話題としては、チーム人数が少ないことで生じる主な問題点、開発方針（速度と保守性のバランス）、RailsのAPI開発に関するツール（特にfast_jsonapiとinteractor）、コードレビューに関するツールと姿勢（RuboCopの使い方など）などが話題となります。 少人数のチームで開発されている方には特に参考になる内容になると思います。

The following exposition is part of a series of articles concerning, Practical Web Development and Architecture. This article continues to focus on the theme, ‘separation of concerns’, demonstrating how the concept can be applied to a NodeJS server application development using the example ws-node-demo. The development of the front-end application ws-ngx-login-demo, a consumer of the NodeJs applic

つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018

Rails Developers Meetup 2018 Day 3 Extreme 発表資料 https://techplay.jp/event/679666 YouTube: https://www.youtube.com/watch?v=1U6SDJD_sp8&t=0s&list=PLLpMWAO4_8wIvjyxzS6p1XpvpOM9v_u3z&index=48

@potato4d の名前で活動 フリーランスのWebエンジニア Vue.js jp Docs core maintenance member Vue.js Japan UserGroup スタッフ nuxt/docs en & ja contributor Nuxt tech book 著者

Transcript ϑϩϯτΤϯυͷٕज़બఆ� 3PQQPOHJ�KT��� None ࠷ۙͷϑϩϯτΤϯυք۾ʹ� ͋Γ͕ͪͳ࿩୊ ࠷ۙͷϑϩϯτΤϯυք۾ʹ� ͋Γ͕ͪͳ࿩୊ w7VFͰ͠ΐʂ� w"OHVMBSͰ͠ΐʂ� w3FBDUͰ͠ΐʂ� ɾɾɾͱܾΊ͚ͭͯ͠·͏ ͲΕ΋ૉ੖Β͍ٕ͠ज़ None ͱ͸͍͑਺ଟ͘ͷϑϩϯτΤϯυٕज़͕� ଘࡏ͍ͯ͠ΔதͰ� Ͳ͏΍ٕͬͯज़બఆΛ͍͚ͯ͠͹ྑ͍͔ʁ (JU)VC�4UBS (JU)VC�4UBS w(JU)VCϦϙδτϧͷӈ্ʹ͋Δɺ
 ϦϙδτϦͷਓؾΛද͢�ͭͷࢦඪ� w਺ࣈ͕ଟ͍͔Βͱ͍ͬͯɺա౓ͳ৴༻͸͠ͳ͍� wϦϙδτϦ࡞੒೔਺͕௕͔ͬͨΓɺ
 ϢʔϞΞ͕͋Δ͚ͩͰελʔ͕ଟͭ͘͘৔߹΋ (JU)VC�1VMTF (JU)VC�1VMTF w(JU)VCϦϙδτϦ����*OTJHIUT����1VMTF� wϦϙδτ

sdevtalks.org開発報告 / reporting that sdevtalks.org was launched

Blockchain.tokyo #2 にて

2. 自己紹介 • 大仲 能史 a.k.a. @onk • 株式会社ドリコム • Railsエンジニア歴8年ぐらい – 1.2.6から触り始めた – 本格的にproductionで使ってるのは3.0から 1

私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

ちなみに、最初に結論だけ言っておくと、まず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

2. Copyright (C) DeNA Co.,Ltd. All Rights Reserved. ⾃自⼰己紹介 ! 惠良良和隆（えら かずたか） ⁃ 2002年年 株式会社フロム・ソフトウェア⼊入社 • コンソールゲームの開発（クライアント、サーバー） • ライブラリ、フレームワークの開発 • 開発環境構築 • etc ⁃ 2013年年10⽉月 株式会社ディー・エヌ・エー⼊入社 • ゲームアプリ開発に必要なライブラリやフレームワーク、 サーバーなどの開発するグループに所属 • ゲーム開発のワークフロー整備 • cocos2d-‐‑‒xをベースとした社内ゲームエンジンの開発 • ゲームシステムのアーキテクチャアドバイザー • etc