Gradle7に上げたら暗黙の依存性が云々と言われた件
gradleのversionを6系から7系に上げてbuildしたところ、
Task ':taskX' uses this output of task ':taskY' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.
こんなメッセージが出るようになった。 taskXがtaskYに暗黙的に依存しているよ、結果は保証しないよ、的なメッセージだ。
buildが失敗するわけではないが、結果が不安定になるのは良くない。
しかし、解消したいものの、taskX, taskYが自分で作ったものでない場合…pluginで定義されているものを使っている場合も多々ある。
ではどうするか。
あとから依存性を明示してあげればいい。
以下はbuild.gradle.ktsの例。
tasks.named("taskX") { dependsOn("taskY") }
homebrewでcouldn't find remote ref refs/heads/master
% brew tap --repair fatal: couldn't find remote ref refs/heads/master Error: Failure while executing; `git -C /usr/local/Homebrew/Library/Taps/chef/homebrew fetch origin` exited with 128.
うーん、なんでじゃろ…と思ったんだけど。
https://github.com/chef/homebrew-chef
repositoryを見に行くと、
default branchの名前が、masterからmainに変わってるんですね。
面倒なので、該当repositoryを一旦削除してからcloneし直し。
% cd /usr/local/Homebrew/Library/Taps/chef/ % rm -rf homebrew-chef % git clone git@github.com:chef/homebrew-chef.git Cloning into 'homebrew-chef'... remote: Enumerating objects: 1401, done. remote: Counting objects: 100% (228/228), done. remote: Compressing objects: 100% (172/172), done. remote: Total 1401 (delta 165), reused 69 (delta 56), pack-reused 1173 Receiving objects: 100% (1401/1401), 267.00 KiB | 949.00 KiB/s, done. Resolving deltas: 100% (887/887), done.
そして再実行。
% brew tap --repair Updating Homebrew... %
問題なく終了しました。
default repository名がmasterからmainに変わっているrepositoryは結構あると思うので、 homebrewで何かしようとしたときに
fatal: couldn't find remote ref refs/heads/master
が出たときには、その確認した方が良いですね、というお話でした。
銀座Rails#36を開催しました
去る2021/8/27(金)、銀座Rails#36を開催しました。
当日の様子は、togetterのまとめを御覧ください。
森 雅智(@morimorihoge)さん(BPS株式会社)
「出張Railsウォッチ in 銀座Rails~RDoc/YARDでコメントを書く~」
毎度おなじみ森さん。今回はRDoc/YARDを用いた、コメントおよびドキュメンテーションのお話。
自動ドキュメントツールには色々ある中で、Ruby界隈ではRDocとYARDが二大勢力となっています。 それぞれの特徴と良い点、微妙な点を列挙の上、個人的にはYARDがおすすめとの事でした。
河野 誠(@ginkouno) 「銀座Rails Season1 まとめ」
私は銀座Railsの第1回目から本第36回まで、主催・運営を務めさせて頂きましたが、次回から @morimorihoge さんに引き継ぐこととなりました。
3年間で総登録者数5230人、平均145人/回、計119セッションの実施など、実績のご報告を含めた簡単なまとめと、交代の挨拶をさせて頂きました。
@yutafujiiさん「【しくじり先生】RailsのAutoloadingとReloadingの仕組みとやってしまったバグ」
HR領域でのWebシステムを開発している @yutafujiiさん。今回はRailsのAutoloadingとReloadingのお話でした。
まずClassic Modeと、Rails6より採用されているZeitwerkの、AutoloadingとReloadingの挙動について説明。
そしてしくじり事例として、ファイル修正後にRelaodingが効かないというトラブルについて共有。その考察および解消方法を述べられ、最後に「原因は『Application(選考)』というRailsが用意するものと被った名前をもつmodelの運用をしていたことだった」とお話されていました。
スポンサーセッション DeNAさま
今回はDeNAさまより、玉田さんがご登壇。
前回に引き続き、Railsをゲームサーバでどう使っているかについて、高品質であるために実施している様々なことについてご説明頂きました。
さらに冒頭でRailsCommiterである @kamipo さんがjoinされているというお話をされ、参加者の多くが驚いていました。
スポンサーセッション リンクアンドモチベーションさま
今回もリンクアンドモチベーションさまより、河野さんがご登壇。
リンクアンドモチベーション社では、「輝かしい未来」をコンセプトに、キャリア・育成においてメンバーに寄り添って目標などの設定しているとの事。
また2021/9/29(水)にはClassMethod社と共同で「進化するエンジニアキャリアパスの在り方」と称し、多様化するエンジニアのキャリアをテーマとしたイベントを開催されるとの事でした。
ゲストスピーカー 松田 明(@a_matsuda)さん「RubyKaigi Takeout 2021 タイムテーブル徹底解説」
丸3年目の節目ということで、松田 明さんに3回目のご登壇を快諾頂き、今回は目前に迫ったRubyKaigi Takeout2021の解説をして頂きました。
Rubyistオタクとしての知識を存分に活かし、登壇される方々の様々な情報を交えながら、各セッションについてご説明。半分くらいの説明を終えたところで予定の時間となりましたが、参加者はまだまだ最後まで聞きたいと盛り上がっており、松田さんには予定を30分プラスした時間までお話頂きました。
RubyKaigi Takeout2021の申し込みはこちらから rubykaigi.org
次回、銀座Rails#37について
次回銀座Rails#37は2021/09/24(金)、オンラインでの開催となります。
ゲストスピーカーは飯塚 浩也(@0317_hiroya)さん、タイトルは「既存のRESTful なRails プロジェクトに、GraphQLの導入を検討した話」。
現在登壇者、参加者ともに募集中です。 ginza-rails.connpass.com
おわりに
お陰様でほぼ丸3年、皆様にご支援頂きながら、銀座Railsを継続することができました。
本当にありがとうございました。
次回以降、私 ginkounoは運営から退き、主催者は @morimorihoge さんに交代となりますが、よりよいコミュニティにすべく、すでに色々とアイディアを出して頂いております。
リニューアルされる銀座Railsを、今後もよろしくお願い致します。
銀座Rails#35を開催しました
去る2021/7/30(金)、銀座Rails#35を開催しました。
当日の様子は、togetterのまとめを御覧ください。
スポンサーセッション リンクアンドモチベーションさま
今日は河野さんにご登壇いただきました。
7/14に実施された「CTOが語る、テックカンパニーに向けた未来の話」。
テクノロジーで実現できる未来について語り合うこのイベントでは、2030-2040年代にかけて、テクノロジーでどんな時代が訪れるのかについて語られたとの事。
その中で、2020年代にヘルスケア領域で大きく進化することとして、バイタルデータによるリアルタイム診断や、AIによる診断などが挙げられました。
リンクアンドモチベーション社は、組織のヘルスケアを一つの解決課題としており、人間のヘルスケア領域と同様にデータ活用の深化やテクノロジーによって、コンサルレス・アンケートレスを目指していきたいとのことでした。
現在積極採用中とのことで、カジュアル面談をご希望の方は気軽に entry@lmi.ne.jp までメールを!とのことです。
森雅智(@morimorihoge)さん(BPS株式会社) 「出張Railsウォッチ in 銀座Rails 〜何かと便利なActiveSupport::Instrumentation〜」
毎度おなじみ出張Railsウォッチ。今回は「ActiveSupport::Instrumentation」がお題でした。
まずActiveSupport::Instrumentationとはなにか。PubSub機能を提供するものであると述べ、PubSubの例としてRedisやAWS SNSなどを挙げながら図解。 またその利用例を挙げ、どのようなオブジェクトのやり取りがされるかを説明し、RailsのあちこちにInstrumentsが仕込まれていることを説明されました。
さらにRailsGuideを見ると色々と解説があること、そこからRailsのLogに出ている情報が該当することを例示。
最後に自分で定義する場合のやり方や、使用上の注意点を述べられていました。
菊池修平さん 「認証基盤開発で遭遇したシングルログアウトの問題と対応について」
リンクアンドモチベーションさま所属の菊池さん。最近は「相手を地獄の底まで追い詰めるゲーム」ポケモンユナイトにハマっているとのこと。
本日の主題は、認証基盤を開発して導入した話、シングルログアウトを導入した話でした。
複数あるプロダクト毎に、ユーザ・認証情報を管理していましたが、似たような画面を毎回作成することになっていた。 そこで共通した認証基盤を作りたい。クラウド系IDaaSはありはするが、今回は認証だけでなく、独自機能や処理の挟み込みを行いたかったとのこと。
そこで中心部分をRailsで構築し、Auth0と組み合わせることにしたそうです。 特に困ったことは生じずに構築できたそうですが、一つだけ困ったのがシングルログアウト問題。
シングルログアウトとは「一つのアプリからログアウトすると、全てから自動的にログアウトする」ことですが、一つのアプリのログアウト状態を他のアプリにどう伝えるかが悩みどころだったそうで、最終的には横断的なCookieによってログアウトを判別するようにした、とのことでした。
@joker1007 さん 「Rails on AWS Lambda」
CTOから念願の離脱、チーフアーキテクトとなったjokerさん。 ワクチン接種後に禁酒していたものの、今日こそはビール飲むぞと気合を入れてのご登壇でした。
テーマはRails on AWS Lamda。コンテナイメージの利用がLambdaでできるようになって以降の、Lambda上でのRails動作のノウハウを共有していただきました。
まずはどのように動作するのかについて、RubyによるLambdaのAPIの利用例や挙動を説明。 コンテナイメージがキャッシュされ、コンテナイメージの大きさに左右されないこと、Lambdaの場合はFargateなどと比べコールドスタートでも高速であることなどの特徴を述べられました。
またRubyのLambda Runtime Interface Clientの動作の流れについて、注意点とともに説明。
更にRailsで動作について、方法や注意点、ユースケースなどを列挙。
最後にjokerさんの社内での活用方法について、EmbulkやStepFunctionを利用したワークフロー構築について述べられ、「AWSを使う限りでは、ActiveJob/sidekiqはもう要らないんじゃないか」という印象的な言葉を残されました。
なお、Repro社では引き続き人材募集中とのことです。
スポンサーセッション DeNAさま
スポンサーであるDeNAさまよりご登壇されたのは、学生の頃から趣味でRailsを使ってらっしゃるという三軒家さん。
DeNA社内でRailsを使っているのはpocochaだけじゃない!大規模モバイルゲームでもだ!とのこと。
大規模のモバイルゲームのサーバはRailsで作られ、大量のアクセスや多くの関係者のニーズに答えているそうです。
一般的なモバイルゲームに必要な機能から、ゲーム固有の遊びを実現する機能まで提供。
バグ極小化、高いRead/Write性能、高い可用性の実現などを備えた「高品質なゲームサーバの開発」をミッションとし、、綿密な調査、設計、レビュー、QA試験、シャーディング、レプリケーション、スキーマファースト開発、エコシステムえのcontributionなどがそれを支えているとのことでした。
島田浩二さん 「Railsと継続的アーキテクティング」
近年マイクロサービスに関する話題が増える中、Railsを使う我々に考えるヒントを頂きたいと思い、 書籍「モノリスからマイクロサービスへ」の翻訳を手掛けながら、日本Rubyの会の理事をされており、Railsを長く使われている島田浩二さんをお招きしました。
まず、「モノリスは駄目で、マイクロサービスなの?」「RailsはモノリスだがもうWebにはだめ?」という、Rails開発者が不安を抱きそうな点を挙げ、それについて「どっちが良い悪いではない」という事から始まりましたが、それよりも大切なことは「アーキテクチャに無関心な設計をしない」事であるとのこと。
そして、そもそもアーキテクチャという言葉については、ISOなどを参照しながら紐解いてゆき、「アーキテクチャ決定要因に基づいてなされた、システムの構造や品質特性、依存関係、インターフェイス、構造手法などに対する決定」と定義。
ここでアーキテクチャに関心を持つためのに、具体的に三つのアクティビティを例示いただきました。
そしてアーキテクティングについて、現代の「終わらないプロダクト開発」を前提とした場合、未知が多く、一方でアーキテクチャ決定は重い事を指摘。コツとしては、決定は責任を持てる限り遅らせることである、と説明。
どうアーキテクティングしていくかについては、必要十分なアーキテクチャからはじめ、システムのアーキテクチャが劣化しないように保護していくことが必要とのことで、これを「継続的アーキテクティング」という言葉で総括。
Railsについては、開発初期に最小限のアーキテクチャ決定を与えてくれ、継続的なアーキテクティングに対して開かれているが、Railsはよく出来ているが、Railsが与えてくれるのはあくまで最小限であり、そこに自分たちのアーキテクチャ決定要因は考慮されていないことに注意が必要、と述べられていました。
次回、銀座Rails#36について
次回銀座Rails#36は2021/08/27(金)、オンラインでの開催となります。
ゲストスピーカーには松田 明(@a_matsuda)さんをお招きし、「RubyKaigi Takeout 2021 タイムテーブル徹底解説」と題して、RubyKaigi Takeout2021のそれぞれのセッションの魅力を語って頂きます。
参加者募集中です。
ワーケーション記録 Vol.1
ずーっと家で仕事をしていると、なんといいますか、思考が直線的になってくる感じがするんですよね。
視野が狭くなり、とにかく目の前のことだけやることしか考えられなくなったりとか。
新しいサービスを生み出したい!と思う身としては、これは大変良くないなと。
そこでキャンピングカーを用い、政府も推奨している「ワーケーション」を実践してみることにしました。
基本方針
混んでいる場所を占拠しないようにする
公園の駐車場に駐車するときには、人がいない曜日や時間を選択し、お土産を買ったりとか、お昼ごはんを併設の場所で食べたりとかしてお金を使うようにしました。
Wifiは諦め、4Gが入っていれば良しする
Wifiがあるキャンプ場もあるのですが、あまり期待せず、Wifiは諦めて4Gが入っていればヨシとしました。
1. 霞ヶ浦 歩崎公園
http://www.kasumigaura-kankou.jp/page/page000010.htm
霞ヶ浦の北側に、歩崎公園という施設があります。
その駐車場に停め、社内でコードを書いてみました。
駐車場は広く、金曜日で平日だったこともあって、スペースには余裕がありました。
敷地内にはお昼ごはんを食べる場所やきれいな公衆トイレもあり、4Gもバッチリ入ります。
疲れたときには展望台や湖畔まで歩くと、頭がスッキリしました。
2. 榛名湖畔
榛名湖の脇にも駐車場があり、窓から湖を見ながらコードを書くことができました。
日曜日だったのですが雨が降っているせいか、観光客が少なかったため、駐車場には数台しか車が停まっていませんでした。
他の車のうち1台は、ワンボックスカーの後部扉を開け、湖を見ながらノートPCの操作をしていました。私たちと同じく、ワーケーションをしていたのかもしれません。
3. つくばねオートキャンプ場
つくばねオートキャンプ場 | 美しい自然の中で心も体もリラックス
筑波山の麓にあるオートキャンプ場です。
Wifiがあるのですが、借りたサイトでは電波の入りが良くなかったため、4Gを使って過ごしました。
管理事務所からなだらかな芝生が続いており、その途中からの山々を眺めていると、目の疲れが癒される感じがしました。
4. 成田ゆめ牧場ファミリーオートキャンプ場
100サイトもあり、芝生が青々と広がる大きなキャンプ場です。
ここでもWifiが飛んでいましたが、接続情報を見つけられなかったので、おそらくユーザへの提供はしていないものかと思われます。
つくばねと比べると平地なため、ちょっと疲れたときに散歩がしやすいなと思いました。
まとめ
霞ヶ浦と榛名湖では車内から出ずにコードを書いていましたが、つくばねと成田ゆめ牧場では外にテーブルを出して作業をしました。 やはり外の方が酸素供給に有利だったりとか、開放感があったりとかで快適ですね。
ただ、晴れた日に外でノートPCを広げると、どうしても日光で画面が見づらかったりするのですが、入手したキャンピングカーには幸いサイドオーニングがついていたため、日陰を作って凌ぎました。
公園も悪くはないのですが、やはりオートキャンプ場の方がのびのび作業ができる気がしますので、今後も色々と行ってみたいと思います。
銀座Rails#34を開催しました
去る2021/6/18(金)、銀座Rails#34を開催しました。
当日の様子は、togetterのまとめを御覧ください。
スポンサーセッション リンクアンドモチベーションさま
今回も前回に引き続き、リンクアンドモチベーションさまからは河野さんがご登壇されました。 「Ruby on Railsを使っているため、Ruby on Railsを盛り上げられたら」という思いで、始まりからスポンサーしてくださっているとの事。ありがとうございます。
リンクアンドモチベーション社ではここ数ヶ月、社主催のMeetupを開催しており、6/23には「DXの落とし穴を考えてみる会(組織力向上編)」を実施。 lmi.connpass.com
そして7/14には「CTOが語るテックカンパニーに向けた未来の話」を開催を予定し、現在参加者を募集中との事でした。 lmi.connpass.com
森雅智(@morimorihoge)さん(BPS株式会社) 「出張Railsウォッチ in 銀座Rails 〜DBコメントの有効活用について〜」
毎度おなじみ森さん、今回はDBコメントの話。 まずはDBコメントは何かについて説明の上、schema.rbでも確認できることを示し、Railsでの身近な活かし方にも触れつつ、その使い方を簡単に解説。
「カラム名を日本語から英語に変換する際に、情報が抜け落ちることがすごく多い。それを防止できる」「特に人の入れ替わり時に効果を発揮」と利点を述べられていました。
そして使いこなしポイントとして、enum定義まで入れておく、DB定義書を要求されたときにschema.rbから置換する、そしてA5:SQL Mk-2がSIer的には神ツールである、などノウハウを共有頂きました。
岸本直樹さん 「ECS移設におけるShoryuken導入の経緯と葛藤について」
リンクアンドモチベーション社にお勤めの岸本さん。開発から、ここ半年でSREチームに移籍されたそうです。今回はECS移設のお話。 LeanとDevOpsの科学とCriteriaをベースに、開発組織メトリクスを作成、優先度を検討。 今回はECSへの移設と、Shoryukenの採用を決めたそうです。
課題としては、Loggingやtestingなどありましたが、ECS移設後には安定稼働を実現。 設定値の共有の煩雑さは環境変数を利用することで回避、恐れていたSQS費用の上昇は思ったよりも上がらなかった、など、運用上での検討事項を共有頂きました。
またShoryukenは個人の方が開発されたgemなので、どこまで頼ってよいのか悩んだそうですが、複数の企業で利用実績があること、またオープンソースなので必要なときに自ら修正できることが、採用の決めてになったとのことでした。
今回のECS移設などにより、リリース作業のリードタイムが2-3hから30minに、デプロイ頻度が20回/月(2倍)に、メンテナンス時間が6hから0になったそうです。
YusukeIwaki(@yi01imagination)さん 「Railsのsystem specからPlaywrightを使う」
今回はじめてご登壇頂いたIwakiさん。Playwrightのお話をして頂きました。
まずはsystem specについて、feature specとsystem specの違いから説明。 system specは本当に確認したいポイントを絞り、安定・高速にテストを行うことが特徴とのこと。
次にCapybaraについておさらいし、DSLとドライバの関係について解説。 標準であるSeleniumドライバを用いた際Dom変更の検知が不完全な点など、機能的な不都合を述べられ、その解決策としてPlaywrightを使う例を示されました。
そしてPlaywrightをRubyで使うため、clientをgemとして作成されたそうで、その利用例について説明頂きました。
なお実運用実績を、現在広く求められているとのことです。
徳丸 浩(@ockeghem)さん 「Rails周辺におけるHTTPヘッダインジェクション脆弱性の動向」
以前ゲストスピーカーとしてご登壇頂いた徳丸さん。今回は公募枠にご応募の上、ご登壇頂きました。 テーマはHTTPヘッダインジェクション。PHPでは完全に修正されるのに9年かかるところ、Railsは一体どうなのか? 大体のパターンでは大丈夫だったが、キャリッジリターンだけの場合には効果が出てしまい、脆弱性となるとのこと。
hackerone.comでバグバウンティ報告をしたところ、Aaronさんが対応し、結果としてPumaの脆弱性として修正されたとのこと。 報奨金が得られなかった…という悲しみを脇に置き、Rack単体などでの再現コードの例などを説明。
まとめると、RailsのHTTPヘッダインジェクションの条件は3つの条件が揃った時のみなのでレアであること、不安な場合はアプリ側でvalidationすると良いことなどを説明し、非常に危険とは言えないレベルだ、との事でした。
今回も楽しくわかりやすいお話を、ありがとうとざいました。
スポンサーセッション DeNAさま
今回も、Pocochaを開発されている今西さんがご登壇。
DeNA TechCon 2021 Summer 2021を開催されるとの事で、セッションの見どころを解説頂きました。 既に開催日は過ぎてしまいましたが、下記URLより動画を視聴する事ができます。
普段今西さんが「業務でISUCONができる」というお話をされていますが、その成果を見ることが出来るとのこと。ぜひ御覧ください。
ゲストスピーカー 和田 卓人(@t_wada)さん 「がんばりすぎない設計判断を支えるリファクタリング/リアーキテクティング(仮)」
私が内容について、だいぶぼんやりとした要望を出してしまったのですが、和田さんはそれに答え、新作をお持ちいただきました。 ITはビジネスのコアとなった昨今、これをDXと表現することがありますが、その本質について「変更容易性の高いソフトウェア」と「アジリティの獲得」という説をまず説明。
この2つの間の距離をどう埋めていくか。 EMERGENT DESIGNからヒントを得て、CodeQualitiesがEmergentDesignに至るまでのピラミッドを図示。その各要素について解説頂きました。
以下キーワードや参考文献について列挙致します。
EMERGENT DESIGN
コードの質
講演「質とスピード」 speakerdeck.com
病理学
叡智
- 先人の知恵
- 巨人の肩
- c2.com
- FLOSS
原則
- SOLID原則
- Principles
- DRY
- KISS
- Demeter
プラクティス
- スタイル
- 名前
- 道具
ユニットテスト
リファクタリング
パターン
- 語彙、形式、共有
- パターンは近年では、リファクタリングのターゲットになっている
テスト駆動開発
パターン駆動開発
創発的設計
- 「諦観」リファクタリング第一版にのみ残っている言葉が印象的
- 第二版、20年で磨かれている
- 究極的に表した言葉「Easier To Change(ETC)」
次回、銀座Rails#35について
次回銀座Rails#35は2021/07/30(金)、オンラインでの開催となります。
ゲストスピーカーには島田 浩二(@snoozer05)さんをお迎えし、「Railsと継続的アーキテクティング」をお話頂きます。
現在、参加者募集中です。 ginza-rails.connpass.com
銀座Rails#33を開催しました
去る2021/5/21(金)、銀座Rails#33を開催しました。
当日の様子は、togetterのまとめを御覧ください。
スポンサーセッション リンクアンドモチベーションさま
今回ご登壇されたのは河野さん。
先日「LM Engineer Meetup」を開催したとのことで、 1つのテーマをもとに、相互コミュニケーションを取る形で開催し、好評だったとのことでした。 リピーターの方も多く、今後も「生産性」「信頼性」「顧客価値」の向上などについてゆるく話していく予定だそうです。
次回は5/27(火)19:00から、生産性向上の中でも障害対応をテーマに開催、参加者募集中とのことでした。
森雅智(@morimorihoge)さん(BPS株式会社) 「出張Railsウォッチ in 銀座Rails 〜Rails7.0で入る予定の新機能特集〜」
毎回確かなRails成分を注入してくださる森さん。今回はRails7.0で入る予定の新機能をテーマにお話頂きました。 コンセプトは「EdgeなRailsを追いかけるぜ」だとのことで、基本情報のおさらいやChangelogの辿り方から始まり、 森さんが個人的にアツい機能、普通に使って便利な機能などについて、それぞれどのような機能なのかについて解説頂きました。
「EdgeなRailsの追っかけ」はとにかく色々なメリットがある!とおすすめされていました。
伊藤はるかさん「ときめく開発体験を - デッドコードをなくしてときめきをつくる - 」
リンクアンドモチベーション社にお勤めの伊藤はるかさん。今回は「デッドコード削除が開発組織づくりに繋がった話」をしていただきました。
背景としては、開発効率を加速したいというニーズがあり、生産性の向上という観点からさまざまな選択肢を検討。その結果、ROIが高いデッドコード削除を実施したとのこと。
泥臭くデッドコードを追い、実績として2万行以上の削除を達成。さらに、コンマリ理論を引用して「ときめくコードか」という概念を導入・拡大し、そのコードの妥当性について議論する文化ができたそうです。
スポンサーセッション DeNAさま
今回もDeNA様より、人西さんがご登壇。
「DeNAというとgolanとか使ってるイメージがあるかもしれないが、Railsのサービスをやっている」とのこと。
DeNAはRailsで開発したサービスも運営しており、その1つであるライブ配信サービス「Pococha」は、巣ごもり需要もあり、220万DL突破、MAU前年比3倍と急成長中。 しかし、大規模開発で破綻していくコード設計、急増するサーバーへの負荷が問題として上がっているそうです。
そんな成長中のサービス開発の人材を募集しており、
大歓迎との事でした。
ゲストスピーカー Uchio Kondo(@udzura)さん「それ、mrubyで - 「Railsな人」のための初めての低レイヤ - 」
今回は「Webで使えるmrubyシステムプログラミング入門」の著者であるUchio Kondo(@udzura)をお招きし、mrubyのお話を聞かせて頂きました。
まずシステムプログラミングの定義について、「OSの機能を使ったプログラミング」と定義。次にそのOSの機能を使うための「システムコール」に触れ、これを知ることはアプリケーションを支えるレイヤを知ることであると説明。
次に、実際にstrace、perfなど「4種の神器」を用いた低レイヤのアプローチから、実際に問題解決をする事例について解説。システムを学ぶメリットについて例示されました。
そしてシステムを学ぶ手段としてmrubyのメリットを列挙、システムプログラミングをmrubyで行うcodeの例を示し、「低レイヤでもRubyを決めましょう」の言葉で締められました。
次回、銀座Rails#34について
次回銀座Rails#34は2021/06/18(金)、オンラインでの開催となります。
ゲストスピーカーには 和田 卓人(@t_wada)さんをお迎えし、主に設計のお話をして頂く予定となっております。 現在、参加者募集中です。 ginza-rails.connpass.com