RubyKaigi 2023 Let's write RBS! 予習記事 - pockestrap
こんにちは。ぽっけです。 RubyKaigi 2023 で RBS に関するトークをします。この記事では、そのトークをより楽しむために予習しておくと良い内容をかんたんに紹介します。 rubykaigi.org トークの内容 このトークでは、RBSを使ったRubyアプリケーションの開発にフォーカスしています。 このトークの軸は2つです。1つは最近リリースされたRBS 3.1の新機能を紹介すること。もう1つはRBSを使った開発を実際にデモして雰囲気を味わってもらうことです。 予習しておくと良さそうなこと 今回のデモではRBSの様々な機能を使う予定ですが、RBS 3.1以前からある機能についてはあまり解説をしません。また、RBSの構文なども解説しません。そのため、それらの内容を予習しておくとよりトークを楽しめるでしょう。 ということで、予習しておくと良さそうな資料へのリンクをまとめておきます。
A few words on Ruby's type annotations state
I don't build systems. I imagine them, then write them. …that were written in a military training camp and accidentally grew to 5k words. I am writing this on my phone, in a barrack that houses some 200+ of my brothers-in-arms in the Ukrainian army’s training camp; I use short periods of rest between training, mostly at night and on Sundays. TBH, since joining the army, I didn’t expect to have tim
ITエンジニア向けのトレンド情報 | Forkwell Press （フォークウェルプレス）
ShopifyやGithubに代表される大規模なWebアプリケーションの開発では、開発チームが膨大になることで必ず課題が生じます。この状況に変化をもたらすのがRuby on Railsです。 「なぜ大規模開発にRailsを導入すべきなのか」生みの親であるDHH氏にお伺いしました。 巨大アプリケーション開発の課題とRailsの関係性 大規模なチームでソフトウェア開発を行うことは開発環境に関わらず困難です。ソフトウェア開発という職業自体が本質的には「大規模なソフトウェアプロジェクトの失敗」の長い物語なのです。しかしRuby on Railsはそのような状況を改善するための手段になり得ます。 Ruby on Railsが長年構築されてきたアプリケーションを見てみると、 ・Github ・Shopify ・Airbnb ・Zendesk ・Cookpad ・Square ・Stripe などがあり
持続可能で幸せなOSS開発 ~ YAPC::Kyotoを終えて | おそらくはそれさえも平凡な日々
もうだいぶ前になってしまいましたが、3月に京都でYAPC::Kyotoに参加してきました。 YAPC::Kyotoは運営の皆さま、本当にお疲れ様でした。コロナ渦で運営の継続には色々苦労があったかと思います。そんな中、世間的にコロナ明けの雰囲気になってきている中、ちょうど先陣を切るような形でオフラインイベントが開催できて、大きな盛り上がりを見せたのは、皆様の苦労が報われたようにも思いました。旧交も温められたし、それだけではなく、学生支援制度などのお陰で、若い人も参加していて交流が盛り上がってよかったです。 思えば、2019年のYAPC::Tokyoのときに僕がベストトーク賞を受賞した勢いで、懇親会の最後にで胴上げされた後に、無責任に「次は京都でやるぞ!」と、勝手に宣言したのが実現した形でした。JPAにも禄に関わっていないのに(当時は一応末席で参加することもあった)。とはいえ、懇親会で @__
GWは自作DBをやってた - k-murakami0609の日記
年1くらいで低レイヤーとか自作XXにチャレンジすることをやっており、今年のGWは自作DBにチャレンジしていたのでそれについての日記です。(まだ全然終わってないです) WEB+DB PRESS 最初は WEB+DB PRESS の「作って学ぶ RDBMS のしくみ」をやりました。 WEB+DB PRESS Vol.122 | WEB+DB PRESS編集部 | コンピュータ・IT | Kindleストア | Amazon この本はわずか100ページ程度で、情報が適切に取捨選択され、全体像が把握しやすくなっています。文章も読みやすく、約2～3時間でざっと読むことができました。 これを実装しても良いんですけど、GWの時間余りそうだな！と思ったので、別途本格的な本を買ってやることにしました。 Database Design and Implementation 続いて取り組んだのは Databas
2023-05-07 / さようならTwitter - okadaic.net
今春、我が身に起きた出来事と心境変化についてあちこちで書いた。Twitterで書いた。Blueskyで書いた。このブログにも書いた。技術系の読み手が多いタイムラインでは努めて思想的に、感情的な読み手が多いタイムラインでは努めて客観的に書いた。反響は皆無だったが、いくつか感想も受けた。「箇条書きに要約して三行で読めるまとめ記事の形式で書いてほしい」とリクエストもあった。何日も何週間も何箇月も同じ話を書き連ねるわけにいかないので、一つ総括を書いておく。 私は2007年5月15日からTwitterを始めた。そして2023年5月15日を目処にTwitterをやめる。16年慈しみ育てた我が子のようなアカウントを「殺す」わけではないが、16年伴侶として連れ添ったサービスと「別れる」くらいの覚悟は決めている。あいつ消えたなと探しに来た人に、まずこの日記が読まれるとよい。（140字） 2022年10月末、
Goで特定のパターンのリファクタリングをASTを弄って自動化した - ちなみに
これは日記です。技術記事ではないので読みやすくはないです。 仕事のコードで特定のパターンでちょっと泥臭く書き換える必要のあるリファクタリングが必要になっているのだけれど、単純計算で100ファイル、1000箇所以上の書き換えが必要になっている。 これまでちまちま手作業でいろんな人が片手間で書き換えをやっていたのだけれど、無限に時間がかかりそうだったのでどうにか出来ないかと考えていた。 先行研究として id:hitode909 のASTを使ってリファクタリングするやつが記憶に残っていたのでもうちょっと簡易版で似たようなことをやってみた。 speakerdeck.com GoのAST周りはあんまり詳しくなくて、社内の静的解析ツールをちょっと弄ったくらいだったのでまずは勉強した。 motemen.github.io id:motemen さんの Go のための Go を読んでふむふむという感じで理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
