カンファレンスとは?CfPとは?プロポーザルって出すといいことあるの?調べてみました!

はじめに

タイトルはふざけていますが本文はまじめです。

カンファレンスとは

私達ソフトウェア開発者の世界におけるお祭り、それが技術カンファレンス(以下「カンファレンス」)です。年に一回、日本中あるいは世界中から人々が集まり特定の技術分野に関する発表を行います。カンファレンスには企業が主催するもの(例:Google I/O)とコミュニティあるいは任意団体が主催するもの(例:RubyKaigi)があります。

カンファレンスのメインコンテンツは技術発表です。では、その発表はどのようにして集められるのでしょうか。

CfPとは

技術発表を公に募集するものがCfP(CFPとも)です。この単語は"Call for Proposals"または"Call for Papers"の略称であると言われますが、言わんとすることは同じで「発表募集」です。

もしカンファレンスの主催者が大勢の人から発表者を集めたいと思った場合、CfPの形式を取ることが多くあります。それ以外の方法だと主催者から個別に声をかけていく方法が考えられますが、コストなどの兼ね合いから一定以上の規模ではCfPのほうが好まれる傾向にあります。

CfPにおいては、あるカンファレンスでの発表を希望する人が「プロポーザル」と呼ばれるドキュメントを主催者に提出し、主催者はそれらの中から自分たちのカンファレンスにふさわしいと思われるものを選びます。選ばれたプロポーザルを書いた人は実際にカンファレンスで発表することになります。

CfPの選考は名前付きでの選考とそうではない匿名形式での選考があります。前者においては「この人の話が聞きたい」という要素が含まれるのに対し、後者ではプロポーザルの内容によってのみ判断が行われるという違いがあります。事前に選考の指針やガイドラインが示されている場合も多いのでプロポーザルを提出する際には参考にしましょう。

プロポーザルを出すといいことがあるの?

まず、自分が好きなカンファレンスに対するある種のサポートの意味合いがあります。というのは、多くのカンファレンスではプロポーザルが集まらないと質量ともに十分なコンテンツを確保できないからです。もちろんむやみにプロポーザルを送ればいいというものではありませんが、もし自分が発表に値する内容を持っていると思うのであれば、時にはカンファレンスに発表者として参加してみるのもよいのではないでしょうか。

もしプロポーザルが採択されなくても、プロポーザルを書くことそれ自体にメリットがあります。プロポーザルを書く過程で自分のスキルや得意なことの棚卸しをすることになるのです。これはキャリアや技術スタックの観点で意味を持ちます。

そして、プロポーザルが採択されて登壇・発表をするとさらに良いことがあります。カンファレンスでの発表は公的な成果であり、例えば職務経歴書などに書くことができるでしょう。特に印象的な発表をすれば多くの参加者の記憶にも残り、フリーランスのような個人の名前に依存した働き方をしている人にとってはかなり大きな効果があるでしょう。また、参加者とのコミュニケーションを取りたいときにも発表自体がネタになるのでその点でも役に立ちます。

私個人のことですが、「VimConf2018にプロポーザルを送る→採択されて発表する→翌年の主催者の一人になる」という流れがあり、結果的にはKaigi on Railsでチーフオーガナイザーをするにまでつながってきています。このような出会いはカンファレンスでの発表の醍醐味かもしれません。

さいごに

いかがでしたか?カンファレンスでの登壇・発表に興味を持っていただけたら幸いです。

最後に、6月17日の20時から、「登壇準備もくもく会」と題したイベントを開催します。ぜひご参加ください!

growrb.doorkeeper.jp

2021年の抱負

前置き

今年はちゃんと元日に抱負を書きます。

ご挨拶

皆様あけましておめでとうございます。本年もどうぞよろしくお願いいたします。

今年のキーワード

今年のキーワードは実は2つあって、「健康」と「挑戦」です。

健康

こんな時代ですので、やっぱり健康第一だと思っています。睡眠に関しては幸い十分すぎるほど取れているので(というか、睡眠時間を減らしたい)、特に運動と食事に気をつけていきたいです。

あと、マインドフルネスのアプリを入れたのに全然使いこなせていないので、2021年はもうちょっと瞑想もがんばりたいですね。

挑戦

2020年はなんだかんだいってやりたいことをたくさんやれた年ではあって、その意味で攻めの一年だったのですが、2021年はもっと攻めていきたいです。

具体的なところは以下のやることリストに書いていきます。

やることリスト

現実的な順番で書いていきます。

  • Kaigi on Railsをバージョンアップして2回目を開催する
  • コーチングビジネスにトライする
  • 技術書を同人で出版する

Kaigi on Railsをバージョンアップして2回目を開催する

2020年にお陰様で成功裏に終わったKaigi on Railsについては2回目を開催する意志を固めており、そのための準備もゆっくりとではありますが進んでいます。

2021年のKaigi on Railsは大幅なバージョンアップを考えています。詳細についてはまだ何も確定していませんが、Ruby/Railsコミュニティにとって重要な役割を果たせたらいいなと思っています。ご期待ください。

コーチングビジネスにトライする

プログラミングスクールを取り巻く状況などを見るにつけ、特に初学者にコーチングをすることに意味があるなと思うようになりました。格安でコーチングをすれば人は集まってくるであろうとは思うのですが、せっかくなのでビジネスとしての持続可能性を模索していこうという意識があります。

例えばオンライン質問会みたいなものをやってみるなどして、現実の需要についての調査をやってみたい気持ちです。

技術書を同人で出版する

技術書を書きたい気持ちは前々からあったのですが、今年はいよいよちょっとした技術書を書いてみれたらなと思っています。

テーマとしては得意分野のRailsを絡めつつ、Web技術の基礎を解説するような本にできたらいいなと考えています。Web技術は私も知らないことがたくさんあるので、勉強にもなって一石二鳥になったら最高ですね。

雑に考えていること

2021年は人々が新型コロナの混乱から立ち直りつつも、以前の生活を取り戻すには至らない、そんな一年になるような気がしています。

2020年を振り返ると、とにかくバタバタしていたというか、急場を凌ぐような感覚の強い一年だったように思います。なにしろ100年に一度レベルの出来事が起きてしまったことを考えると、むしろRubyコミュニティを含めた日常がある程度維持されていることが奇跡と言ってもいいくらいに色々なことが変化してしまったので、急場を凌げただけで御の字ではあると言えるでしょう。

しかし、それはいわば守りの営みであり、ある意味で貯金を切り崩すような一年であったとも言えます。2021年はもっと前を向いていきたいというのが私個人の感覚です。

私のキーワードの一つは「挑戦」なのですが、これは私個人の挑戦であると同時に現状の様々な問題に対する挑戦でもあります。

私が属するWeb業界を見てみると、新規参入者の増加に受け皿が追いついておらず、結果的に一部のスクールへの依存が深まっているようにも思えてきます。また、Rubyコミュニティについて考えると、本来ならそこにいても不思議ではない新規参入者があまりおらず、既存のメンバーが親睦を深めるに留まっているように見えます(それが悪いと言っているわけではありませんが、放っておくとコミュニティが徐々に年老いていくので…)。

こういう問題意識から、新規参入者の人々を既存のコミュニティに上手に接続する、というのが一つの方向性として見えてきました。やることリストが向いているのもそちらです。Kaigi on Railsを含めたリソースを上手に活用して、なにかしらの方法論を模索していきたいと考えています。

おわりに

2020年は大変な一年でした。2021年はそれよりは良い一年になると期待はしていますが、幸いなことに期待するだけでなく実現するための手段もないではありません。この際、良い一年だったと思えるような挑戦をしていきたいなと思います。

2020年の抱負

前置き

やっぱり抱負を書かないと一年が始められないと思うので、今から今年の抱負をつらつら書いていきます。

キーワードは「創造」

2019年のキーワードは「自律」だったのですが、今年は「創造」がキーワードかなと思っています。

理由としては、自律についてはある程度達成できたという感覚があり、それを踏まえて守りから攻めに転じる一年にしたいなという想いがあるからです。

また、後述するように大型のテックカンファレンスをやる可能性があるというのがあるのですが、それって立派な創造行為だよなという自負がありまして、このキーワードとなりました。

やることリスト2020

今回はやりたいこと順になっています。

  • テックカンファレンスをやる
  • ちょっと痩せる
  • Rails以外の技術を一つ勉強する
  • 代表作のOSSを作る

テックカンファレンスをやる

これはおそらくRailsに関係したテックカンファレンスになる可能性が高いのですが、すでに界隈にはRubyKaigiがあるということを踏まえつつそれとは異なるカンファレンスをやるという方向性になりそうです。これについては語ると長くなりそうなので今回は省略します。

ちょっと痩せる

なんかわからんけど最近体重が顕著に増加して70キロ台を突破してしまったので、2020年はせめて70キロちょうどくらいまで体重を落としたいと思います。

Rails以外の技術を一つ勉強する

毎回言っている気がしますが、Railsしかできないというのも技術者としてはあまりよろしくないよねとは常日頃感じているので、2020年はフロント関係の技術とかやりたいなあと思っています。

代表作のOSSを作る

去年はRailsにコントリビュートできたりと色々やれた感はあったのですが、自分に代表作がないのがなんとなく寂しく感じるようになってきたので、作ってみたいなあという気がしています。

まとめ

書き出してみると結構やりたいことありますね……

健康に気をつけつつ攻めの姿勢で過ごす一年にしたいですね!

Railsの未来についての一考察

概要

前置き

この記事はRails Advent Calendar 2020の15日目の記事です。昨日はnegito6さん忙しい人のための Rails デバッグ方法まとめでした。

動機

うなすけさんのRailsを主戦場としている自分が今後学ぶべき技術について(随筆)という記事と、それに対するmizchiさんのアンサーブログ、Re: Rails を主戦場としている自分が今後学ぶべき技術についてに触発されて書いています。

お断り

この記事ではRailsの技術的な側面を意図的に重視していません。というのは、私がRails以外の技術についてそこまで詳しくないため比較するのが困難だからです。

また、ふわっとした話題を扱うということもあり、どうしても書き方が推測多めになってしまっています。これは私の知見と経験の少なさによるものです。

本編

アプリケーション開発のマトリックス

いきなりですが、アプリケーションを開発するときに、チームのサイズ感と将来的なスケール感とをそれぞれ横軸と縦軸にすると以下のようなマトリックスが描けるかと思います(テキスト失礼!余談ながら、Webでいい感じにマトリックスみたいな図が描けるツールあったら教えてください)。

チームサイズ 将来的なスケール感
スモールチーム スケールしない
ビッグチーム スケールしない
スモールチーム スケールさせたい
ビッグチーム スケールさせたい

このうち、「ビッグチーム・スケールしない」というアプリケーション開発は例が他と比較して極端に少なさそう(スケールしないならビッグチームを支えられない可能性が高い)なので、実際に考えるべきはそれを除いた3つになります。

Railsはスモールチームでスケールしないアプリケーションを開発するのに最適

上記のマトリックスのうち、Railsが最も力を発揮するのは「スモールチーム・スケールしない」のケースです。これはRubyが動的型付け言語であるということと、Railsのそもそもの設計思想によるというが私の考えです。

Rubyが動的型付け言語であるということは、Rubyでの開発はチーム規模が大きくなるほど生産性が(その他の言語と比較して)急激に低下しやすいことを示唆しています。これにより、Railsはスモールチームに最適化されていると考えられます(異論はあると思います)。

Railsの設計思想についてはやさいちさんのRuby on Railsの正体と向き合い方に詳しいのですが、要するに「少人数チームによる速くてキレイな開発を実現するためにコンポーネントを密結合させている」という話で、これがRailsではスケールが困難という事実につながってきます。もちろん、Ruby言語自体のスケーラビリティが低いということも場合によっては意味を持つでしょう。

チーム規模の拡大とスケールを前提としたアプリケーションをRailsで作るのは理にかなっているとは言えない

ということは、なんにせよスケール前提のアプリケーションであれば、それをRailsで構築するのは最適ではないのかもしれません。少なくとも、何らかの工夫なしにRailsアプリケーションがスケールしていくと辛くなってくる、という事例は複数あるようです。また、チーム規模が大きくなることでRailsでの開発が最善ではなくなってくるケースもあるでしょう。

何より、世の中にはRails以外の選択肢も豊富にあります。静的型付けやスケーラビリティを求めるのであればそれらを採用することが最適である場合が多いと考えられます(現状のチームが持つ技術的な強みなど他の考慮点もあるので常にとは言えない)。

スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワークRails

RailsのオリジナルアプリケーションはBasecampですが、このアプリケーションを開発しているBasecamp社は創業当初から社員数を増やさないことを徹底しているらしく、チームページによれば、創業から21年経った今でも60人ほどしかいないようです。

また、Basecampというアプリケーションはフリーミアムモデルを適用しておらず、価格ページによると現在は月99ドルの固定価格のようです。これはBasecampが大規模にスケールしなくてもビジネスとしては成立するということを意味しています。

このように、Railsの開発を最も強く推進しているBasecamp社の現状を考えると、Railsが「スケールが不要なアプリケーションをスモールチームで開発する」ことに特化しているとしてもさほど不思議ではないでしょう。

興味深い話として、Basecamp社は自社のスマートフォンアプリをWeb技術中心で開発し、そのために自社開発のライブラリであるTurbolinksを活用して、わずか数名のチームでiOSAndroid向けのスマートフォンアプリを開発できたということです(リンクを探したのですが見つかりませんでした…)。このように、Basecamp社のアプローチは少なくとも彼らの環境では機能しているようです。

また重要な点として、Railsはこの「スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワーク」としては最も成熟したフレームワークです。近年ではLaravelとの差が急激に縮まっている、またはすでに追い抜かれているとの言説もあるようですが、その文脈においてすらRailsの成熟度と利便性は否定されません。

Railsが強みを発揮できるケースはどれくらいあるのか

この「スケーラビリティが不要なアプリケーションをスモールチームで開発する」というシチュエーションですが、Webアプリケーション開発の全体に占める割合はどのくらい大きいのでしょうか。意外と大きいのでは、というのが私の見解です。

まず、スタートアップ企業が開発するアプリケーションはすべからく少人数での開発となる場合が多いです。これは単純に資金が少ないまたは貴重であることからチーム規模を大きくできないケースが多いでしょう。スモールビジネス(スタートアップと違って大きく成長する前提ではない)も定義上スモールチームでの開発をするしかありません。これらのケースではRailsを採用することは、以下のスケーラビリティの問題をクリアできるのであれば、合理的な選択肢の一つと考えて間違いないでしょう。

アプリケーションのスケーラビリティについてですが、いわゆるSaaSの場合はスケールメリットが相対的に小さいとは考えられます。一方、UGC(User Generated Contents)のサービスであれば、スケーラビリティは必須になってくるでしょう。それ以外にもECサイトなど、急激なスケーラビリティを必ずしも必要としないサービスはそれなりにあると思われます。

個人開発の友

Railsは「フルスタックフレームワーク」であり、それが逆にフロントエンドの最適化の妨げになっているという話がmizchiさんの記事の一つの論点であると私は理解しています。私はフロントエンドに詳しくないので深く議論することはできないのですが、Rails(あるいは他のフルスタックフレームワーク)がフロントエンドの最適化をある意味で犠牲にして提供しているものがスモールチームでの生産性です。その究極の形は個人開発でしょう。

個人開発は笑い飛ばせるような存在ではもはやなく、実際にいくつものサービスが個人開発から育っていっています。そこでは「フロントエンドの最適化」よりも「いかに仮説を検証するか」が重要であり、Railsが提供する高速な開発が重要な意味を持ちます。Railsのエコシステムにより各種実装を省略できることもまた重要です。

これらの点で他のフレームワークRailsを超えるまでは、Railsはある程度安泰と言っていいかもしれません。

Railsの改善点:段階的なスケーラビリティ

もちろん、ここまでの話はRailsに問題がないことを意味しません。私の考えでは事実は逆で、Railsには改善すべき点が多くあります。ここではいくつかの考えを紹介します。

Railsに欠けているものは詰まるところ「段階的なスケーラビリティ」に尽きるのではないかと私は考えています。これは、現実の世界では「スケールするアプリケーション」と「スケールしないアプリケーション」にハッキリと分かれるわけではないという、これまであえて触れて来なかった事実に由来します。最初は個人開発またはスモールチームで作ったものが予想以上に成功してしまい、スケーラビリティを考慮する必要が出てきた―こんなシチュエーションはRailsの最も顕著な弱点です。

Railsはomakaseであるというのが、Railsドクトリンに掲げられたRailsの思想ですが、これに照らし合わせれば、Railsはいわば「スケーラビリティを標準で備える」べきです。具体的には、多くのケースでモデル層が肥大化することがスケーラビリティを下げているという点を踏まえ、モデル層を段階的に分割するような機構を導入することなどが考えられます。例えばコマンドオブジェクトやフォームオブジェクト、シリアライザなどです(大雑把にはそれぞれCRUDのD, CU, Rに相当します)。

もちろん、Railsのエコシステムにはこれらが含まれているのですが(それぞれinteractor-railsyaafactive_model_serializersなどが代表例)、これらは結局コアと統合されておらずメンテナンスなどの面で不安があります(実際、AMSのメンテナンスは滞っています)。

Railsに「段階的なスケーラビリティ」が組み込まれることで、開発の初速を担保しつつ開発をスケールさせられるようなフレームワークに進化すると良いなと思っています。

まとめ

というわけで、Railsの未来について考えてみました。この記事ではいくつかの点に触れることができず(例えばShopifyやCookpad, GitHubのような大規模Railsアプリケーションの実例など)、悔しい気持ちも少しあります。もしかしたら、また別の機会に似たテーマで書くかもしれません。

Rubyコミュニティカタログ2020

概要

Ruby言語の一つの特徴に活発なコミュニティ活動があります。東京だけでも10近いローカルなRubyコミュニティがあり、私はそれらのほとんどに参加したことがあったのでした。

しかし、今年はCOVID-19の影響でオフラインでの活動が困難となり、多くのコミュニティがオンラインに活動の場を移しました。この記事ではそんなRubyコミュニティをざっくりとご紹介します。

紹介の基準としては、少なくとも私が1回は行ったことがあるコミュニティに限っています。言うまでもなく、実際に体験したことがないものの紹介をするのは無理があるためです。また、現在も活動しているコミュニティだけを紹介しています。

本編

Asakusa.rb

老舗コミュニティであるAsakusa.rbは現在も毎週火曜日に活動しています。一時期は毎回使用するボイスチャットツールを変えていたのですが、現在ではDiscordを使用することが多くなっています。

集まる人たちはRuby歴が長い人も多く、しばしば「インターネット老人会」的な会話になることもあります。私のような若輩者には非常にありがたい話です。

雑談ベースの場ではありますが、回によっては非常に静かであることもあります。

Tama.rb

比較的新興のコミュニティであるTama.rbは夏ごろから活動を再開し、"Coffee Lounge"と名付けた雑談会をほぼ毎月どこかの週末で開催しています。また、「OSSコードリーディング部」の活動も内部的に行っており、先日はWEBrickのコードリーディングを公開形式で行うなど課外活動も行われているコミュニティです(ちなみにコードリーディング部は私が音頭を取っています)。

Slackでのコミュニケーションが活発であることも特徴的で、総じてにぎやかなコミュニティといえるでしょう。

私はTama.rbの共同オーガナイザーの一人です。

Fukuoka.rb

Fukuoka.rbは(文字通り)福岡で活動しているRubyコミュニティです。現在は21時からの「夜会」をメインに毎週水曜日に活動しています。

形式はいわゆるもくもく会に近いですが、回によっては雑談メインになることもあります。

エンジニアフレンドリーシティ福岡アワードのコミュニティ部門を受賞したようです。

Sendagaya.rb

Sendagaya.rbは東京ではAsakusa.rbと並んで毎週開催をしていたコミュニティです。現在もオンラインで毎週月曜日の19時30分から活動しています。

ディスカッションメインですが、その場で話題が決まります。自由な雰囲気で、フィヨルドブートキャンプの受講生を中心に未経験の人が比較的多く来るのも特徴的です。

Mitaka.rb

Mitaka.rb三鷹市近辺のRubyistのためのコミュニティです。ずっとイベント管理アプリケーションをモブプロで作る活動を行っており、オンラインになってからも継続しています。

だいたい毎月第2木曜日に開催されています。

Omotesando.rb

Omotesando.rbは毎月第1木曜日に開催されているコミュニティです。しばらく活動を休止していましたが、11月から再開しています。

LT会メインで、コミュニティのオンライン移行に伴いLTの場が減った中で貴重な存在です。

オフライン時は懇親会が豪華だったのですが、オンラインに移行してからも懇親会は行っています。寿司は自前です。

西日暮里.rb

西日暮里.rbは長期に渡って活動しているコミュニティです。オンラインに移行してからはもくもく会メインで活動しています。

ボイスチャットを使わずにテキストチャット中心にコミュニケーションを取るのが特徴的になっています。

開催は毎月最終の月曜日が多いようです。

nikotama.rb

nikotama.rb楽天のメンバーが中心となって運営しているコミュニティです。最近はオンラインでLTとディスカッションを組み合わせた活動を行っています。

Rubyに関するニュースを紹介するコーナーもあるなど、内容の多彩さが特徴的です。

火曜日の開催が多いようですが、他の曜日で開催することもあります。

Machida.rb

Machida.rbは今回取り上げるコミュニティの中では最も新しいコミュニティです。最近は毎回テーマを変えてオンラインで活動しています。

こちらもフィヨルドブートキャンプの関係者が多く参加しています。

開催は第1金曜日です。

Shinjuku.rb

Shinjuku.rbはディスカッションをメインとしたコミュニティです。LTをする人がいればLTが行われ、その内容についてディスカッションが行われます。

最終水曜日に開催されています。

Hamada.rb

Hamada.rb島根県浜田市の地域Rubyコミュニティです。現在はオンラインで"Ruby Hacking Challenge"の活動を行っています。

Ruby言語本体に関する話題が多いのが特徴です。

火曜日に開催されることが多いようです。

Sendai.rb

Sendai.rb仙台市の地域Rubyコミュニティです。現在はオンラインでもくもく会と企画をだいたい交互に行っているようです。

開催は月後半の木曜日が多いようです。

Entaku.rb

Entaku.rbは私が主催しているコミュニティで、オンラインでのディスカッションにフォーカスしています。

もともとの意図としては、COVID-19下で新しい出会いが減ってしまったため、ディスカッションを通じて知り合いを増やしてほしいと考えて作ったコミュニティです。

最近は私が忙しくてあまり開催できていません。

Grow.rb

Grow.rbは私が去年始めたコミュニティで、Rubyのコードを書くことにフォーカスしています。

オンラインでも数回活動しましたが、私が忙しいため開催頻度が減ってしまっています。

まとめとちょっとした感想

というわけで、私がCOVID-19後に行ったことのあるコミュニティについてご紹介しました。

日程被りについて

ちなみに、私はShibuya.rbのオーガナイザーでもあるのですが、最近活動できていません。理由はやはり忙しさではあるのですが、それとは別にある事実もあります。

それは、「オンラインだとすべてのコミュニティに参加できるため、日程被りを気にしないといけなくなった」という点です。実際、地域.rbカレンダーというものがあるのですが、これを見ているとほとんど隙間がありません。従来であれば物理的に行けなかったので気にする必要はなかったのですが、全てがオンラインになると気にする必要が少し出てきます。

どうせ開催するならたくさんの人に来てほしいな、と考える私のような人間にとって、この日程被りはなかなか難しい問題だったりしています。

おわりに

そんなわけで、コミュニティの紹介をしつつ最後に主催者としての私の気持ちについてもちょっとだけ書いてみました。

ご覧いただいたようにRubyコミュニティはオンラインでも活発に開催されています。またどこかのコミュニティでお会いしましょう!

プログラミングを学習する上で気をつけるべきこと―コーディング・調査・質問

前置き

この記事はRails Girls Japan Advent Calendar 2020の2日目の記事です。昨日はsuperrino130さんのターミナル で文字化けしたら Git Bash を使おうでした。

概要

この記事では「プログラミングを学習する上で気をつけるべきこと」というテーマでいくつかのTIPSを書いていきます。

プログラミングを学習中の(業務歴がない)方あるいはプログラミング学習に興味がある方が主な対象ですが、業務歴がある方でも役に立つことはあるかもしれません。

また、RubyRailsなどの言語やフレームワークに固有の話ではなく、あくまでプログラミング学習一般の話をしたいと思います。

本編

手を動かす

実際にコードを書くのが上達への最短ルートであることは間違いありません。本を読む・動画教材を見るなどの学習法はもちろん有効ですが、コードを書くことと併用することで更に効果が高まると思います。

ただ、闇雲にコードを書くと間違ったやり方を覚えてしまったりもします。コードを「正しく」書くためにはいくつかの方法があります。

写経する

まずは写経です。これは本などに出てくるサンプルコードをそのまま書き写す方法です。いわば「体で覚える」やり方ですので、合う合わないがかなりあります。私個人はあまり合わないようですが、もくもくと練習するのが好きな人にはうってつけです。

写経に慣れてきたら、写経したコードをベースに自分なりの改造を加えてみてもいいかもしれません。その際、Gitなどを使って元のコードにすぐ戻れるようにしておくとはかどります。

レビューを受ける

もう一つ重要なのがレビューを受けることです。どんなに完璧だと思っていても、自分が書いたコードには何かしらの改善点があるものです(プロの開発者ですらそうなので心配無用!)。あるいは、自信がないコードを見てもらいたいということもあるでしょう。

身近にコードレビューをしてくれる人がいるなら、その人にお願いしてコードを見てもらいましょう。お題は何でもよいのですが、課題にアクセスしやすく理解もしやすい競技プログラミングなどがおすすめです。

身近にレビュアー候補がいないなら、Exercismなどのサービスを利用するのも一手です。このサービスではメンターにコードを見てもらいながら徐々にコードを改善していくことができます。英語でのコミュニケーションになるのが難点ですが、英語に自信がある人におすすめできます。

同じ問題を何通りもの方法で解いてみる

もしレビューが受けられないのであれば、セルフでレビューをするしかありません。このときにポイントとなるのは、同じ問題には複数の解法があるということです。同じ問題を考えつく限りの方法で解こうとすることで、結果的にコードレビューを受けたのに近い効果を得られるかもしれません。

解く問題ですが、例えば伊藤淳一さんの問題などが良いでしょう。ネットに回答例があるものであれば自分で答え合わせもできます。

上手に調べる

ある問題について調べる能力はプログラミングをする上で欠かすことができません。調べ方にはコツがあり、コツを抑えることで効率的に調べることができます。

エラー内容をコピペする

なにかを調べる必要に駆られるケースはいくつもありますが。最も多いのはエラーに直面したときでしょう。

エラーメッセージはほとんどの場合英語ですが、恐れる必要はありません。エラーの出方もメッセージの種類もたかだか数十通りくらいしかありませんし、コピペすればかなりの確率で解決法がわかります。

その際、自分の環境に固有の問題との区別を付けることが重要です。例えば、以下のようなRubyのコードがあるとします。

hoge

ここで、hogeはいきなり登場しているのでエラーになります。おそらく、NameError (undefined local variable or methodhoge'のようなエラーになりますが、メッセージに含まれるhogeは今まさに問題となっている名前そのものです。これを除外して、例えばNameError undefined local variable or method`とWeb検索できれば解説が載っているサイトまでたどり着けます。

基本的に、「名前」(今回はhoge)は検索クエリに含めても意味がない場合が多いです。NameErrorのようなErrorで終わっている単語とuninitializeundefinedのような否定的な意味の単語を組み合わせて検索するのがコツです。

公式情報から探す

RubyRailsのような成熟したソフトウェアは公式の情報が非常に充実しています。まずは公式情報から調べるようにすることで余計な手間を省ける可能性があります。

Webで検索する際は、"site: ruby-lang.org"のようにサイトを指定すると公式サイトからの情報のみに絞り込むことができます。

注意点としては、公式情報は(以下にあるように)英語で書かれている場合が多いです。「英語にビビらない」こともプログラミング学習におけるポイントの一つです。

日本語で出てこないときは英語で調べる

プログラミングに関する情報はほとんどが英語で出回っています(Rubyなどの少数の例外を除く)。エラーメッセージを検索する場合は結果的に英語での検索になりましたが、もっと抽象的な調べ方をする場合でも英語で検索するのは有効な手段です。

例えば、"How to reverse array in Ruby"(「Rubyで配列を逆転させる方法」)のように調べると、高確率で海外のQ&Aサイトがヒットします。そのサイト内でのベストアンサーを頼りにすれば、多くの場合問題を解決できるでしょう。

なお、比較的マイナーなライブラリについて調べようと思うと日本語での情報がほとんどない場合もあります。そのような場合は否応なく英語で調べることになります。

上手に質問する

なにかを学習するとき、質問をしたくなるケースがあると思います。プログラミング学習においては現役のエンジニアが質問に回答してくれる場所がオンラインに複数存在しますが、同じ質問でもいくつかの点に注意を払うことで回答を得やすくなります。

画像を貼らない

エラー画像を貼ってはいけません。繰り返します、エラー画像を貼ってはいけません!

エラーはテキストで表示されます。テキストはコピペできます。テキストは加工できます。テキストならタイポが見つかりやすくなります。エラーを画像で送るとこれらの利点がすべて消し飛んでしまいます。

エラーについて質問したいなら、エラー内容をコピペしてください。それだけで回答者はだいぶ楽になります。

5Wをしっかり記述する

質問をしたいときというのはなにかに困っているときです。その「困り方」は、質問者であるあなたはわかっていますが、回答者の人は全く知りません。この知識の差が困難を生みます。

質問をする際、"5W"をできるだけ正確に記述するように心がけてください。"5W"とは、

  • When, 問題が起きたのはいつか(問題の直接の原因と思われる行動)
  • Where, どのような環境で問題が起きたのか(OSの種類や言語のバージョンなど)
  • Who, あなたはどこまで問題を理解しているのか(問題を修正するために何を試してみたのか)
  • What, 問題となっている具体的なものはなにか(ライブラリやフレームワークの名前)
  • Why, なぜそれが今問題になっているのか(何を達成したいのか)

です。

具体例を示します。例えば、

「画像アップロードがうまくいきません!」

はダメな質問です。一方、

Mac環境でCarrierwaveというライブラリを使って画像をアップロードしたいです。ローカルにはアップロードできていますが、S3にアップロードしようとするとNoMethodErrorが出ます。どうすれば修正できるでしょう。以下にログを貼ります。」

は良い質問です。

省略しない

質問をするときに、「重要でない」部分(ログの一部など)を省略する誘惑に駆られるときがありますが、これは罠です。というのは、どんな情報が重要なのかを判断するのは回答者であって質問者ではないからです。

質問には可能な限り多くの情報を載せましょう。断言しますが、情報量が多すぎて困る回答者はいません。ほとんどすべてのケースで情報が少なすぎるのが問題なのです。

まとめ

というわけで、コーディング・調査・質問の3つのサブテーマでプログラミング学習における注意点について解説してみました。

プログラミング学習は困難な道のりですが、この記事にあるような抑えるべきところを抑えればぐっと効率が上がるはずです。みなさんのプログラミング学習の道が実り多きものでありますように!

データで見るKaigi on Rails STAY HOME Edition

概要

この記事はKaigi on Railsに関するいくつかのデータを公開して、オンラインカンファレンスを更に良いものにするための考察を行うためのものです。

なお、以下で使用されているグラフの数値と本文中の数値が異なるケースがありますが、グラフ表示上の制限などによるものです。ご了承ください(数値に大差はないため、論旨には影響がないと考えています)。

データ

視聴者数など

トータルの視聴数(視聴者数ではない)は1622でした。ユニークな視聴者数でいうと705となっています。延べ視聴時間数は約1600時間、1視聴当たりの視聴時間は約1時間でした。

また、同時視聴者数は240人前後で一定でした(お昼休みなどを除く)。

f:id:okuramasafumi:20201014175128p:plain
Kaigi on Rails STAY HOME Editionの同時視聴者数

コメント

コメント数は1595でした。ということは、1回視聴されるごとに1回コメントが残されていた計算ですね。

視聴者属性

視聴者のうち、男性は82.7%女性は17.3%でした。業界の男女比にかなり近い数値が出たのではないでしょうか。

また、年齢分布は

  • 18~24: 5.5%
  • 25~34: 47.4%
  • 35~44: 40.7%
  • 45~54: 6.4%

となっています。やはりRailsを業務で使っているであろう年齢層が多く、若年層にはあまりリーチできない結果となりました。

f:id:okuramasafumi:20201014175253p:plain
Kaigi on Rails STAY HOME Editionの年齢と性別

視聴デバイスなど

視聴に使われたデバイスは、コンピュータが約50%スマートフォン約40%となっています(残りはタブレットなど)。興味深いのは、4割を占めるスマートフォンが視聴時間に占める割合はわずか7%しかないという点です。具体的には、スマートフォンでは平均して約15分しか視聴されていません。この数値はコンピュータの約1時間10分と比べると非常に低く感じられます。

また、OSで見ると、Mac, iOS, Androidの順に多く、この3つで9割を越えます。Windows2.4%のみであり、Rails開発者のほとんどがWindowsを利用していない可能性を示唆しています。

考察

ここから先は個人的な考察となります。

良かった点

単純に、700人もの人に見てもらえたのはよくやったと思います。多くの人に見てもらうのは直接の目的ではないにしても、やはりせっかくの素晴らしいコンテンツを一人でも多くの人に届けたいという想いもあります。約240人がほぼ通しで見てくれたということも含め、初回のイベントとしては上々だという受け止めです。

また、女性の視聴者が多かった点は重要だと思います。今回のKaigi on Railsは、運営メンバー7人のうち3人、登壇者の16人(基調講演含めれば18人)のうち4人が女性でした。視聴者も含め、全体的な女性比率は2割くらいと言ってもよいでしょう。オンラインカンファレンスはオフラインによくある「会場に男性ばかりで参加しづらい」というような感覚(あくまで感覚であって実際にはそんなことはないのですが…)が生じづらく、結果的に女性の視聴を促した面があるのかもしれません。

コメントの多さもかなり目を引きます。積極的にコメントをしてくださった方々が多かったからこそだと思いますし(ありがとうございました!)、オフラインカンファレンスのわいわい感が少しでも出せていたらよいなと思います。

悪かった点

そんなに悪い点はないのですが、やはり若年層にリーチできなかったのは少し残念です。今回は初回でありリーチも限られていたので仕方がないのですが、20代前半の人たちが興味を持たない技術は徐々に衰退していきそうだなあ、などと考えると、次回以降は若年層にもアピールできるとなおよいのかなと思いました。

まとめ

また次回!