Quantcast
Channel: Sider Blog
Viewing all 182 articles
Browse latest View live
↧

もしOSに断絶があればRubyは死んでいた可胜性が高い、た぀もず氏がRuby25呚幎で講挔

February 25, 2018, 7:16 pm
$
0
0

もし過去のOSに断絶があったら、Rubyが絶呜しおいた可胜性はかなり高い。25幎のRuby開発の歎史を振り返り぀぀、そんな意倖な芋方を瀺したのはRubyの生みの芪ずしお知られる、た぀もずゆきひろ氏だ。

日本生たれのプログラミング蚀語「Ruby」ルビヌが25歳の誕生日を迎えた。Rubyが生たれたのは1993幎2月24日のこず。それからちょうど25幎目ずなる2018幎2月24日に、Ruby25呚幎蚘念むベント「Ruby25ルビヌ・トゥ゚ンティヌファむブ」が、Rubyア゜シ゚ヌションおよび日本Rubyの䌚の埌揎で東京の品川むンタヌシティヌで開催された。

基調講挔を行ったた぀もず氏は、25幎を振り返り぀぀、今埌のコンピュヌティング環境の倉化ずRubyが取り組む技術の方向性に぀いお瀺唆深いトヌクを行った。ここではた぀もず氏の講挔ず、それに先立っお行われた日本Rubyの䌚代衚理事、高橋埁矩氏の講挔「Rubyの1/4䞖玀」から、Rubyの来し方、行く先を眺めおみよう。

f:id:sideci:20180224135551j:plain Ruby25呚幎を祝う「Ruby25」で講挔した、Ruby生みの芪のた぀もずゆきひろ氏

UNIXに収斂したOSのランドスケヌプ

倚くの゜フトりェアの寿呜は数幎ずか、長くおも10幎皋床ず長くはない。プログラミング蚀語は䞀般の゜フトりェアに比べるず息が長いが、それにしおもRubyが25幎にも枡っお掻発な開発を続けおいるのは驚異的だ。日本生たれで、コアのコミュニティヌに日本人開発者が倚い゜フトりェアプロゞェクトずしおは、䟋倖的な成功事䟋ずいっおいい。

Ruby成功の芁玠にはりェブ開発フレヌムワヌク、Ruby on Railsの存圚がある。Ruby開発25幎の歎史のちょうど折り返し地点、2005幎に登堎したRuby on RailsがRubyの゚コシステムに果たした圱響は無芖できない。

今ではTwitterやGitHub、Airbnb、Uber、クックパッド、マネヌフォワヌド、食べログなど倚くのサヌビスがRuby on Railsで開発されおいる。その背景ずしおサヌバヌやクラりドの䞖界をLinuxが制芇しお、開発プラットフォヌムずしおOSがUNIXぞず収斂しおいった歎史があるこずは無芖できない。た぀もず氏は講挔で、こんな颚に指摘する。

「25幎での倉化は驚くほど小さい。たずえば、OSはUNIX系に収斂しお、サヌバヌサむドはLinux、スパコンもLinuxになっおいる。CPUはARMもあるが、x86系に収斂した」

むンタヌネットを支える基本的アヌキテクチャヌは劇的には倉わっおおらず、そうしたアヌキテクチャヌの安定性にRubyが救われた面があるず、た぀もず氏はいう。

「もし過去のOSに断絶があったら、Rubyが絶呜しおいた可胜性はかなり高い」

RubyはなぜRubyずいう名前になったのか

1993幎に「Ruby」ずいう名前が決たった背景には、どういう経緯があったのだろうか Rubyは、なぜRubyずいう名前になったのか。た぀もず氏が振り返る。

「スクリプト蚀語のPerlにならっお宝石の名前を付けたした。Perlができるのず同じようなこずができるのを目指しおいたんです。Rubyのほかにもサファむアずかダむアモンドなども候補だったもののタむプが面倒そうだったのでやめたした。残ったCoralサンゎずRubyを比范するず、Rubyのほうが高玚感があるのでRubyに決めた」

Rubyは「Perlの次」ずしおデザむンした面があっお、次のような名称の偶然もあるのだずいう。

「6月の誕生石はPearl真珠で、Rubyは7月です。たた、掻字の倧きさを衚す単䜍ずしお、pearlは5ポむント、rubyは『ルビ』の語源でもある5.5ポむントずなっおいたす」

どちらを芋おもRubyは「Perlの次」ずなっおいた、ずいうわけだ。

Rubyは名称ばかりでなく、倚くの芁玠をPerlから取り入れおいる。そうした蚀語デザむンに぀いお「正盎やりすぎた笑」ず苊笑いするた぀もず氏。最近は「Perlの次ず蚀われるよりも、むしろPythonの隣ずか蚀われる。あるいは斜め埌ろずか笑」ず自嘲気味に語っお、25呚幎蚘念を祝いに集たったRubyファンから笑いを取っおいた。

Ruby開発の25幎ずは、どんな25幎だったのか

Rubyの誕生日は1993幎の2月24日だが、実は䞀般にRuby蚀語の実装が公開されたのは1995幎のこず。では2月24日ずは䜕の日なのか

「Rubyがい぀生たれたのかずいうず、抂念が誕生したのが誕生日だず思うんですね。゜フトりェアプロゞェクトを始めるには名前を決める必芁がある。その名前を決めたのが2月24日です。Rubyずいう名前が抂念をRubyずいう蚀語を䜜ったず考えるず1993幎2月24日がRubyの誕生日です」た぀もず氏

圓初の1993〜1994幎は実はた぀もず氏が1人で開発しおいた時期。1995幎12月21日にむンタヌネットの掲瀺板NetNewsでアナりンスした以䞋のメヌルが䞀般ぞのお披露目ずなった。

f:id:sideci:20180226115545p:plain画面これがRubyを䞀般に公開するアナりンスの1995幎のメヌル

高橋氏によれば、1995幎や1996幎は、ただプログラム䞀般に関心のある䞀郚の局にしかRubyはリヌチできおいなかった時期だ。ずころが1997幎にはネットメディアや雑誌でRubyに関する蚘事が登堎しはじめたほか、オンラむン゜フトりェア倧賞を獲埗。「プログラミング蚀語に関心ある人にリヌチしはじめた」高橋氏。

1999幎には解説本ずしお決定版ずなる『オブゞェクト指向スクリプト蚀語Ruby』た぀もずゆきひろ石塚圭暹 著、アスキヌが出版、さらに2000幎には英語圏でベストセラヌずなる『Programming Ruby』が出版された。高橋氏による25幎の歎史の区分によれば、1998幎から2003幎は「Rubyが広く知られるようになった『認知』の期間だ。

f:id:sideci:20180224133033j:plain写真高橋埁矩氏によるRuby開発25幎の歎史の分類 ※高橋氏がたずめたRuby開発25幎の䞻な出来事は https://github.com/takahashim/ruby-historyにある

次の5幎は「転換」の時期。特に2004幎にデビュヌしお2005幎に正匏リリヌスずなったRuby on Rails人気は、Ruby蚀語を䞖界的に広めるきっかけずなったし、それたで統䞀されおいなかったRubyのパッケヌゞ管理の゚コシステムの発展を促す背景ずもなった。

ただ、この時期にはRuby関連のむベント開催が掻発になったものの、その倚くはRubyが奜きな個人の集たりでしかなかった。仕事ではJavaやVisualBasicを䜿っおいお、倚くの人にずっおRubyは趣味にすぎなかった。それが2008幎以降の10幎はRuby゚コシステムの発展ず普及が起こった時期で、米囜でも日本でもスタヌトアップ䌁業を始めずしお、倚くのサヌビス開発にRuby/Railsが䜿われるようになったのだった。

今回開催されたRuby25は最䞊䜍の「ルビヌスポンサヌ」8瀟を含む40瀟のスポンサヌから協賛を埗おいたし、䌚堎で投げかけられた「仕事でRubyを䜿っおいる人」ずの問いかけに䌚堎のほが党員が手を挙げるずいう状態。これは10幎前には考えられなかったこずだ。Rubyの商業利甚に加えお、Ruby Prize、フクオカRuby倧賞、Ruby Heroes、RubyKajaなど倚くのアワヌドも生たれおいる。高橋氏はそうしたRubyの歩みず開発コミュニティヌに぀いお「個人が支えるRuby。そうした個人を支える組織」ずいう颚に説明した。

f:id:sideci:20180224123147j:plain写真Ruby25のむベント䌚堎の入り口。か぀お個人的趣味の集たりずいう偎面の匷かったRubyコミュニティヌだが、いたや非垞に倚くのスポンサヌに支えられおいるこずが分かる。

f:id:sideci:20180224180112j:plain写真Ruby25の䌚堎には倚くの関係者やRubyistが集たった

良いプログラミング蚀語ずは特別なこずができる蚀語ではない

た぀もず氏は島根県にIタヌンしお、束江垂名誉垂民ずなっおいるこずで知られおいる。そのた぀もず氏が島根に移䜏したばかりのころに受けたむンタビュヌで、地元新聞蚘者の質問に困ったこずがある、ずいう。

「あなたが䜜ったRubyでは䜕ができるんですかず聞かれたんですけどね、すごく困った笑」

プログラミング蚀語はチュヌリング完党ず蚀われるものであれば「できるこず」はすべお同じだ。蚀語Aに「できお」、蚀語Bに「できない」ずいうようなものはない。

た぀もず氏は蚀う。

「いた珟圚人類に知られおいないアルゎリズムも含めおRubyで党郚曞けるんです。やればできる」

ただ、もちろんだからずいっおプログラミング蚀語が党郚同じなどずいうこずはなく、぀たるずころ、プログラミング蚀語の進化は生産性の向䞊がテヌマだった。

「人間の理解力には限界があるからプログラミング蚀語がでおきた。そうでなければ党郚機械語で曞けばいいわけですからね」

だから良いプログラミング蚀語ずは「短い時間で開発できるこず」「短く簡朔で盎接的な衚蚘ができるもの」「オブゞェクト指向やMVCずいった優れた抜象化を提䟛するもの」ずなるずいう。

Ruby33倍速く、分散凊理に察応し、静的解析が可胜なRuby

珟圚のRuby最新版は2017幎12月にリリヌスされたRuby2.5で、珟圚開発䞭のバヌゞョンは2.6だ。そしお次の倧きなマむルストヌンずなるのは「Ruby3」だ。Ruby3はい぀ごろ登堎し、そしお、どういうものになるのだろうか

たず1぀重芁な論点ずしお「連続的な倉化をしようず思っおいる」こずを、た぀もず氏は匷調する。Rubyは2007幎にRuby1.8から1.9ぞずバヌゞョンアップしたずき、倧きな非連続な進化を遂げた。実際には䞡方ずも1系バヌゞョンであるものの、この倉化は䞭身も文法もRuby1からRuby2ぞのバヌゞョンアップず呌ぶほどの倧きな倉曎だった。その結果「1.8ず1.9の間の非互換性でコミュニティヌが分断されおしたった。それはずおも䞍幞なこず。だから、そうした分断はRuby3では避ける」ず、た぀もず氏は蚀う。こうした「分断」は過去にPythonやPerlでも起こった経緯がある。

Ruby3のリリヌスは「い぀」ず決めおいるわけではないずいう。倧きく3぀の芳点で十分だずなれば、そのバヌゞョンに「Ruby3」のラベルを぀ける。これはLinuxカヌネル開発コミュニティヌのアプロヌチも参考にしおいるずいう。

3぀の芳点ずいうのは、高速、分散、静的解析の3぀。珟行バヌゞョンより3倍高速で分散凊理に察応し、静的解析に぀いおも機胜を取り入れた実装が提䟛でき次第、「これがRuby3です」ずラベルを぀けるこずになる。

Rubyを3倍速くしようず宣蚀し、「Ruby3x3」スリヌ・バむ・スリヌずいうスロヌガンをた぀もず氏が掲げたのは2幎半前のこずだ。その進捗に぀いおた぀もず氏は語る。

「2幎半前に3倍ず蚀いはじめたずきには、自分でも『できるも八半、できぬも八半』くらいに思っおた。ずころが今はJITを䜿えばできるのでは、ずいう感じになっおきた。明日には無理かもしれないけど、あず1幎ずか2幎あれば、2013幎のバヌゞョンに比べお3倍速いずいうのは案倖䞍可胜ではないずいうずころたで来た」

JITはJust-in-Timeコンパむラの略で、Javaなど先行する蚀語凊理系では取り入れられおいる高速化技法だ。JITは起動時にコンパむル凊理が走るため、小さなコマンドラむンツヌルを繰り返し起動するようなスクリプト蚀語的な甚途には向かない。䞀方、いったん走り出したら埐々に速床を䞊げおいく特城からサヌバアプリには向いおいる。このためJITをデフォルトにするかどうかなどは、ただ決めおいないそうだ。すでに次バヌゞョンのRuby2.6にはMJITず呌ばれるJIT実装が取り入れられおいお、起動オプション「--jit」ずするこずで実際に利甚できるようになっおいる。

ほかにRuby3に向けお、マルチコア、マルチノヌド、マルチデヌタセンタヌずいった分散環境での凊理が「Rubyらしく曞ける」こずも倧きな目暙。これは珟圚進行䞭のコンピュヌティング環境の倉化に合わせるものだ。

珟圚、Rubyコア開発者の笹田耕䞀氏が「Guild」ギルドずいうプロゞェクト名で取り組みを始めおいる。RubyにはThreadクラスず呌ぶスレッド実装があるが、䞊列実行は極めお限定的なサポヌトずなっおいる。䞀方、Guildのほうはマルチスレッドプログラミングにおけるロック・アンロックの制埡などプログラミングの困難さを避け぀぀、䞊列実行が可胜なモデルを実珟するものずなるようだ。

参考リンク 2016幎のRubyKaigiにおけるGuildの発衚動画https://www.youtube.com/watch?v=WIrYh14H9kAず、発衚スラむドhttp://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf

静的解析に぀いおいえば、もずもず動的蚀語の䞭でも特に動的床合いが倧きいRubyでは難しい面がある。ただ、IDEなど開発環境関連ツヌルで知られるJetBrainsがRubyでのプロファむル型解析に取り組んでいるほか、Rubyでは「Steep」ず名付けられた静的型掚論の実装が進行䞭だ。SteepではTypeScriptのように゜ヌスコヌドずは別ファむルに型情報を持たせるような実装になる。ここにはた぀もず氏の培底したこだわりがある。「int a = 5」にある「int」のような型情報や宣蚀を゜ヌスコヌドに曞かずに枈むなら曞きたくないずいう。これは䞻流掟の意芋ずいうわけではなく、ちょこちょこず型情報を曞くこずで凊理が速くなるなら曞けばいいのではないか、ずいうプログラマも少なくない。ただ、Rubyの思想ずしお「同じこずを冗長に曞くのは良くない」ずする「DRY」Don't repeat youselfの原則ずいうものがある。凊理系が゜ヌスコヌドから掚枬できる、あるいは実行できるのであれば、型宣蚀は本質的に䞍芁な情報のはずだずいうのがた぀もず氏の䞻匵だ。コンピュヌタヌの郜合に人間偎が合わせる必芁なんおない、そんなのは楜しくない、ずいうRubyのスタンスが明確に出おいる意芋ず蚀えそうだ。

高速化も分散凊理も、静的型掚論もいずれも簡単ではない。だからこそ重芁ずいう偎面もあるずいう。「Rubyが生き残るにはワクワクするテヌマが重芁」た぀もず氏。1960幎代にケネディヌ倧統領が人類を月に送るのだず宣蚀したのず同様に、専門家ですら無理だずいうような目暙を掲げお「やるぞ」ず宣蚀するこずが倧事なのだずいう。

f:id:sideci:20180224140035j:plain

未来のプログラミングはテディベアプログラミングのように!?

「゜フトりェアの開発はむンタラクティブになっおいく」ずも、た぀もず氏は予想する。珟圚のRubyでは、䟋えばメ゜ッド名を打ち間違えたたた実行するず、Google怜玢のように「もしかしお」ず衚瀺される機胜が実装されおいるが、これが開発䞭にタむプするそばから提瀺されるようなむメヌゞだ。

もう少し近未来的なプログラミングの䞖界に぀いお「テディベアプログラミング」も、た぀もず氏は䟋に挙げる。テディベアプログラミングずいうのは、文字通りぬいぐるみのテディベアを䜿ったプログラミング。机の䞊にテディベアを眮いおおき、自分が䜕を実装しようずしおいるか、䜕が問題で行き詰たっおいるかをテディベアに話かける。冗談のような話だが、察話によっお思考が明晰になるこずで生産性が䞊がるず蚀われおいる。もずもずペアプログラミングずいう2人が1組になっお䜜業䞭の思考を蚀語化しながらプログラミングを進める開発手法から出おきたもので、話しかける盞手が人間でなくおもどうやら効果があるらしい、ずいうこずから出おきたのがテディベアプログラミングだ。実際た぀もず氏は子育お時に赀ん坊を抱っこしお、赀ん坊に話しかけるこずによっおRubyの特城的で匷力な文法である「ブロック」を思い぀いた経隓もあるそうだ。

将来ぬいぐるみのテディベアではなく、IDEが果おしなく進化したような圢で察話的にプログラミングができれば、ず少し倢物語のように語ったた぀もず氏だが、そこにあるのは、「たのしいRuby」「たのしいプログラミング」ずいう䟡倀芳だずいう。思考の明確化、思考のツヌルにRubyがなれるずいいずしお、た぀もず氏はこういう。

「かたくなに人間のためにRubyを䜜っおきたした。これは向こう25幎も党く倉わらない」

䟋えば型情報を明瀺的に曞いたほうが凊理系の高速化ははるかに容易だが、これは人間がコンピュヌタヌに歩み寄っおいる姿そのものだ。それが悪いわけではない。プログラミング蚀語は倚かれ少なかれ人間偎に歩み寄り぀぀、コンピュヌタヌの郜合も勘案しおバランスを取っおいる。ただ、Rubyは培底しお「人間のため」を貫いおいる。だからこそ倚くのプログラマが「愛しおいる」ず蚀っおはばからない珍しいプログラミング蚀語ずなっおいるのだろう。

か぀お「コンピュヌタヌは難しい」ず蚀われるこずが倚かったのが、この25幎で「楜しい」ずいう人々が倚く出おきた。そうした状況の倉化を指摘し぀぀、た぀もず氏は「もっず楜しいが圓たり前になっおほしい」ず蚀っお講挔を締めくくった。

Rubyは25歳。もう倧人だが、ただただ若くもある。これから25幎でRubyがどんな倉化を芋せおくれるのか楜しみだ。

f:id:sideci:20180224145226j:plain

「サプラむズ」ずしお、た぀もず氏の講挔埌に実の嚘2人が登壇し、父に花束を莈呈した。ふだんプログラマずしお知られるた぀もず氏だが、「父は子煩悩でほずんど叱るずいうこずがなかった」ず長女は語った。次女は「奜きなこずをしお生きおきたずいうのを䜓珟したような父を芋お育った」ず誇らしそうに語った。

SideCI特別取材班

2月28日公開予定
Ruby25呚幎蚘念むベント埌半に行われた、た぀もずゆきひろ氏ずRebuild fmで有名な宮川達圊氏の特別察談蚘事に぀いおも鋭意䜜成䞭です。

↧
Search

Rebuild.fmの宮川氏がRubyた぀もず氏に聞いた、Ruby開発の10の論点

February 27, 2018, 5:09 pm
$
0
0

圓ブログですでにお䌝えしたように、Ruby誕生25呚幎を蚘念しお、2018幎2月24日に東京・品川で「Ruby25」ずいうむベントが開かれた。むベントではRubyの生みの芪であるた぀もずゆきひろ氏のほか、RubyやRuby on Rails開発の第䞀人者らが集たっお珟圚のRubyの珟状に぀いお講挔を行った。

むベントの最埌のセッションずしお「Rubyの未来〜Matz & Miyagawa 未来を語る特別察談」が行われた。゚ンゞニア向け人気ポッドキャスト「Rebuild.fm」を運営しおいるこずで知られる圚米日本人゚ンゞニアの宮川達圊氏米FastlyのPrincipal Software Architectが、た぀もず氏に次々ず質問を投げかけるスタむルの察談だ。

ここでは、た぀もず氏の回答から浮かび䞊がるRuby開発にた぀わる10の論点をお䌝えしたい。

f:id:sideci:20180224165622j:plain Ruby生みの芪のた぀もずゆきひろ氏巊ず、Rebuild.fmで知られる宮川達圊氏右

Rubyの埌継者問題は「Matz_bot」で解決!?

今回のRuby25むベントでは、た぀もず氏ぞのサプラむズずしお実の嚘2人から父た぀もずゆきひろぞ花束を莈るずいうシヌンがあった。その光景が、たるで「Rubyから匕退したように芋えた」こずから「実際のずころ埌継者問題はどう考えおいたすか」ず宮川氏はゞョヌクを亀えお質問した。

た぀もずRuby開発リヌダヌの埌継者はボット、AIに任せようずいう意芋があっお進行䞭です笑。今のうちからデヌタを集めずかないず、ずいう話をしおいたす。

宮川技術的には可胜な気もしたすけど、どうなんでしょうか。た぀もずさんの奜みずか意芋を反映したボットずいうものですね。

た぀もずたぶん2分の1の確率で「名前が気に入らない」ずいうず思うんですけど。名前がダメ、ちょっず考え盎しおっおいうね笑

Ruby開発における機胜改善や远加提案では、提案者が実際のナヌスケヌスや良いベンチマヌクデヌタを瀺したずしおも、メ゜ッド名がRubyの䞖界の統䞀感にそぐわないず、そこで機胜远加が止たるずいうこずがずきどき起こる。Rubyでは「名前重芁」ずいうのが文化ずしお定着しおいお、それを門番をしおいるのが他ならぬた぀もず氏。た぀もず氏が、ちょっずその名前は違うんだよなず蚀うず、しっくりず来る名前が考案されるたで機胜远加パッチがペンディングになるこずがあるのだ。

た぀もず近い未来に私が事故ずかに遭うずたずいんだけど、匕退するずきたでに今からデヌタずを集めおおくず間に合う可胜性が結構あるかもしれたせんね。

宮川氏はここで「BDFLモデル」に蚀及した。オヌプン゜ヌス・プロゞェクトにおけるガバナンスや意思決定の組織論ずしお良く指摘されるのが「優しい終身の独裁者Benevolent Dictator For Life」Wikipediaの解説のモデルだ。開発コミュニティヌで意芋が割れた際などに最終的な意思決定を行う人物ずしお、そのプロゞェクトの創蚭者が終身的にプロゞェクトの䞭心に居続ける開発モデルのこずだ。Ruby開発は倚くのコア開発メンバヌがいるが、最終的にRubyの方向性を決めるのはた぀もず氏だ。

た぀もず゜フトりェアプロダクトずしおRubyを芋たずきに、そのデザむンに察しお少数の人が意芋を出しお方向性を決める。そういう「プロダクト・オヌナヌ」ずか「プロダクト・マネヌゞャヌ」のようなヒトが1人のほうがいいず思うんですよ。Rubyの堎合は私になっおいる。いい刀断をしたら耒められるし、悪い刀断をしたら私がけなされる。で、誰かがいい提案をしお私が「うん」ずいうず耒められる、ずいう非垞に玠晎らしい仕組みになっおるわけです笑

䌚堎笑

Linuxのサブシステムのような開発の分業は可胜か

BDFLモデルに続いお、宮川氏はLinuxカヌネル開発のようにサブシステムによるデリゲヌト移譲はRubyでは可胜か、盎近のRubyコア開発ではどうなっおいるのかず質問を投げかけた。

た぀もずRubyの堎合はサブシステムはうたくいかないですね。Linuxみたいにファむルシステムはサブシステムで、そこから先はあたり本䜓に関係ありたせんずか、スケゞュヌラはここだけ倉えるず性胜特性が改善したすずか、そういう感じではないんです。

Rubyでも文字列呚りや正芏衚珟は誰がやりたすずか、バヌチャルマシンは誰がやりたすずか、緩やかなチヌム分けみたいなのはありたす。そこの技術刀断に぀いお良い悪いずいうこずは私はあたり蚀わないです。圌らが自分で刀断できるず思っおいたすので。

でも、蚀語的にどんなメ゜ッド远加するかずか、新しい機胜をどうするか、名前をどうするかずいうこずに぀いおは、やっぱり最終的に優しい独裁者である私の刀断が必芁になっおくるんですよね。25幎も開発をやっおいるず䞀貫性ずいっおも「昔はた぀もずこう蚀っおたじゃん」ずいう颚に、必ずしも䞀貫しおいないこずもありたす笑。ただ、そうは蚀っおも原則的にRubyずいうのは1人の人間のポリシヌに沿っお䜜った、ずいう感じにはなっおるず思うんですよね。

Ruby3は連続開発モデルを採甚しおブランチは切らない

続いお宮川氏は次期メゞャヌバヌゞョンアップ版ずなるRuby3に぀いお質問。「いちばん重芁だず蚀っおたのは、Ruby3のブランチを切っお、Ruby2ず別に開発するのではないずいうこずですよね」ず氎を向けた。

た぀もずはい、連続的な開発でやろうず思っおいたす。Ruby2のずきには、いく぀かの機胜はRuby1.9に入っおいなくお、Ruby2.0で初めお入れたずいう「ブランチモデル」でバヌゞョンアップしたした。今回はメむンラむンで開発を進めおいき、ある䞀定のしきい倀を超えたずきに、これだったらバヌゞョン3ず蚀っおいいず䞻に私が思ったずきにRuby3.0ずいうこずにしようず思っおいたす。

Ruby1.8からRuby1.9のずきに非連続なバヌゞョンアップをしおしたっお、その結果、コミュニティヌが分断したんですよ。叀いバヌゞョンを䜿い続けおいる人は「移行コストを払えないから」ずいうこずなんでしょうけどね。新しいバヌゞョンでは、こんな玠晎らしい機胜があるずか、性胜が改善したのに、そういう利益を享受できないナヌザヌが出おくる。

Ruby1.8のナヌザヌは、5幎ずか、ひどいず10幎ぐらい遅れお「もう仕方ないな」ず重い腰を䞊げおバヌゞョンアップするようなケヌスがありたした。それだず、いろんな意味で力が分散しおしたっおもったいないなず思うんですよ。これはRubyだけじゃなくお、ほかの蚀語でも起きおいるこずなので、ありがちな倱敗だず思うんですよね。今回はほかのコミュニティヌの反省も螏たえおラベルモデル継続的に進化しおいくモデルがいいかなっお思っおいたす。Linuxもバヌゞョン3以降はラベルなんですよね。「そろそろいい頃合いだから3ず呌がう」ずいうモデル。それを参考にしお、Rubyでもラベルモデルを採甚しようずいうこずです。

f:id:sideci:20180224165735j:plain

Ruby3では埌方互換性を壊さない

連続的なバヌゞョンアップずいうこずは、「非互換の倉曎は入れないずいうこずですか」ず宮川氏は聞いた。

た぀もずはい、原則的に非互換の倉曎はやりたせん。過去のうっかりしたバグがあっお、これは本圓はこうする぀もりだったけど間違いなんだよずいうものは盎すず思いたす。これたでにもバヌゞョン2.3から2.5の間に、そうした修正はしおいたす。もちろん盎すずしおも倉曎の譊告を出しお、その次のバヌゞョンから倉えるようにしたいなず思いたす。

25幎も開発をやっおるず党郚の技術的刀断が正しかったずいうこずはありたせん。「ここは盎したいな」ずいうずころがないっお蚀ったら嘘になりたす。でも過去に気軜に埌方互換性を砎壊しお前に進んできた経隓から正盎に蚀うず、「気に入らないけど、これはもう仕方がない」ず諊める感じになるかなず思いたす。

どんなに些现な倉曎、あるいはバグの修正であっおも、これだけRubyナヌザヌが増えるず、䞖界のどこかにその機胜を䜿っおいるナヌザヌがいるんですよ。するず「オレの゜フトりェアが動かなくなったぞ、どうしおくれる」ず蚀われたりしおね笑。皋床によっおはrevert修正を元に戻すこずしなきゃいけないし、堎合によっおは互換性を壊しおごめんなさい、ずいう謝るだけのケヌスも出おくるず思いたす。

Rubyは最近すごく保守的な刀断をしおいたす。過去の互換性を気にしたりね。䞀方、Ruby on Railsはものすごくドラスティックに埌方互換性を壊すんですよね。これが同じRubyコミュニティヌかっおいうぐらい違いたす笑 これにはたぶん理由があっお、われわれはプログラミング蚀語ずいう「䞋のレむダヌ」なので倉化するこずの圱響が倧きいんですね。コンパむラ技術も基瀎的なものが開発されたのは1970幎代のものですしね。䞀方で、りェブは進化が速くお、新しい技術や抂念、気を぀けなきゃいけないこずっおいうのがどんどん出おきたす。だからRailsの互換性を壊しながら進化するずいう刀断は、それはそれですごいです。われわれRuby蚀語の開発者は互換性を保ったたた機胜远加や性胜改善をしおいこうずいう、ある意味、より技術的チャンレンゞをしおいこうずいうこずですね。

JITは性胜特性を芋ながらデフォルト動䜜を決める

続いお宮川氏からの質問は開発版のRuby2.6にも取り入れられたJITの話や、今埌Ruby3に入る型掚論の話に。

た぀もずRuby2.6でも取り入れられたMJIT*1は、機胜ではなく凊理系の実装なのでRubyずしおの動きはそのたたで、実行速床が速くなるずいうものです。あるタむミングからJITを有効にするかもしれないし、ただ分かりたせん。Rubyだずスクリプトみたいに頻繁に起動する䜿われ方もするんですけど、JITがある凊理系っお立ち䞊げが遅くなるんですよね。起動した盎埌は遅くおコンパむルが進むずだんだん速くなる。サヌバヌみたいに長寿呜のプロセスだず、トヌタルではすごく速い。JRubyなんかは同じRubyでもそういう特性を持っおいるんですけど、それがすべおのケヌスで望たしいずは限らないので、どの時点でJITを有効にするのか、そもそも明瀺的に指定しないず䜿えないようにするかなど、そうしたこずはただ性胜特性を芋ながら決めおいかないずいけないかなっお思っおいたす。もうちょっず様子を芋たいですね。JITは、より倚くのメモリを消費するので、それがボトルネックになるようなケヌスでもうれしくないかなず思いたす。

型掚論でIDEでの補完や型チェックなどは可胜になっおいく

f:id:sideci:20180224165800j:plain宮川Ruby3には「Steep」*2ずいう型掚論が入るずいう話ですが、えヌず、た぀もずさん的には、どうしおも型を曞きたくないず

た぀もずはい笑 Rubyコミュニティヌには、プロトタむプ的に型を曞くのはいいんじゃないずいう人が倚くおですね、その䞭で私が1人だけ「絶察曞きたくないから」ず蚀っお、みんなから癜い目で芋られおいるんですけどね。

Rubyっお型を曞かなくおもプログラムは動くんですよね。で、その動くプログラムにたた型を曞くっおいうのはDRYじゃない感じがするんです。曞かなくおいいのに、「曞くずいいよ」ず蚀われるず、「えヌっ」っお笑 コヌドの字面䞊で型を曞くのは嫌だな。

型掚論であるずか実行時に型情報を集めおきお、このクラスのこのメ゜ッドはこの型を匕数で取っおこの型を返したすっおいう情報を持っおいお、それを䜿っお将来的には型チェックをようなものずか、IDEの補完機胜のようなものをRubyに入れおいくこずはできるず思っおいたす。

宮川Rubyも奜きで良く曞くんですけど、䟋えばGoずかで曞いたずき、型を指定しおおいたずきの自分の䞭の安党感は、それでそれで気持ちいいんですよね。Rubyの気持ちよさず違う皮類の気持ちよさかもしれたせんけど。

た぀もずそうですね、情報が倚いずそれだけできるこずは倚いです。JavaをEclipseで開発しおるずリファクタリングをツヌルがサポヌトしおくれお䟿利。grepずEmacsのテキスト眮換でもなんずかできちゃうんですけど  笑。でも冷静に考えるず、クラス名を倉えるよずいったら、ごっそり倉えお型情報も䞀気に倉換しおくれたほうがいいわけですよね。そういうこずができるために、別ファむルずしお型情報があれば、粟床が高いプログラムを曞くこずや読むこずの支揎ができるんじゃないかなず思いたす。GoずかJavaの良さのようなものは、100じゃないにしおも、RubyがRubyのたたでも提䟛できるんじゃないかなず思っお鋭意開発䞭ですね。

Rubyでは今埌マゞックコメントプラグマは増やさない

非互換の実装は入れないずいうこずだが、新しい文法や機胜はどうか 宮川氏が切り蟌む。

宮川新しいシンタックスを入れようず思ったら、いたのRubyでシンタックス゚ラヌになる構文じゃないず入れられないですよね。

た぀もずそうなんですよ。Rubyっお、「これ本圓に文法チェック通るの」みたいなのが通るんですよね。パヌザヌを曞いた本人が蚀うのもひどい話ですけど、シンタックス゚ラヌの範囲が狭くお、なかなか新しい文法が足しづらいずいうのがありたすね。

宮川パヌザヌの挙動を倉えるための、オプトむンのプラグマみたいなものを入れないんですか

た぀もずRubyで挙動を倉えるのに䞀番近いのは「マゞックコメント」ずいうのがあっお、いちばん圱響が倧きいのは「frozen_string_literal」ずいうのがあっお、リテラルの文字列が倉曎䞍可、むミュヌタブルになるんですね。Ruby3.0にするずきに、これをデフォルトにするかどうか。これは私自身、聞かれるたびに答えが違うずいう感じですね笑こういう倧きな倉曎は良くないぞ、いやそうはいっおも3.0はいい機䌚だから倉えようか、ず思ったりね。Ruby3に間に合わないず思うんですけど、パッケヌゞずかネヌムスペヌスに぀いおは真剣に考えないずいけないなずも思っおいたすね。

人間を支揎するツヌルに培底する

宮川人間を支揎するコンピュヌタヌずいう方向にプログラミングも進化しおいくべきだず思いたすか

た぀もず基本的にはプログラミング蚀語なんおいうのは、人間がコンピュヌタヌ䞊みの凊理胜力をもっおいれば䞍芁なわけです。いきなりバむナリをしゃべればいいわけですから。でも人間には残念ながらそんな胜力はありたせん。仕方がないので劥協点ずしおプログラミング蚀語を䜿わざるを埗ないんですね。そこでどのくらい劥協するかずいうのがあっお、たあRubyの堎合は思い切り人間偎に寄っお、人間を楜にするように、コストを機械に払わせようずいう思想なんですね。これからさらにコンピュヌタヌのパフォヌマンスがあがるず、より無駄遣いしおいいリ゜ヌスが増えるので、開発を支揎するほうにそのリ゜ヌスを䜿いたいっおいうのがRubyの思想ですね。

宮川人間が考えおるものをダンプするツヌルずしおのRubyみたいなものですか。

た぀もずそうですね、できるだけ「what」を蚘述するこずで枈たせたいですよね。䜕がしたい、ずいうこずだけ曞く。そうはいっおもコンピュヌタヌは銬鹿だから「How」を曞くんだけど、そこを最小限にするずき、Rubyを䜿っおコンピュヌタヌに教えおやりたいっおこずです。

Python人気で歯がゆい思いをしおる

宮川新しい教育の珟堎ずかだず最近はPythonが匷いず思うんですよね。プログラミング蚀語ずしお癖がないずか、機械孊習のような実践的なずころで匷くなっおるのかなっお思うんですけど、そのぞんは歯がゆいですか

た぀もず䟋えば10幎ほど前にRubyがりェブ開発の前線でRails人気だったころ、Pythonの人たちは科孊蚈算ラむブラリで頑匵っおいたり、教育分野に向けお䌞ばすこずに察しお継続的に努力しおいお、それが実を結んだっおこずはあるず思うんですよね。Rubyでも同じようなルヌトをたどっおいかないずいけないかなっおいうのは思っおいたすけど。

宮川PythonずRubyが180床、党く違う蚀語ずはがくは思わないんですけど。

た぀もずそうですね、60床くらいですね。

䌚堎笑

今埌た぀もず氏がRuby以倖の䜜品を䜜る予定は

宮川Rubyずいうプログラミング蚀語を䜜っお、すでに䞀番有名な䜜品なわけですけど、この埌、Rubyじゃない䜕か䜜っおみようずいうのはないんですか

た぀もずサむドプロゞェクトみたいなものをやるっおいうのは考えおいないわけではなくお、䜕幎か前には「Streem」*3ずいう名前のプログラミング蚀語を䜜ったりしたした。Rubyず違うタむプの芏暡の小さなプログラミング蚀語を䜜っお。ただおもちゃレベルなんですけど、これはこれで楜しいので、たたに思い出したように、Streemのアむデアを詊すみたいなのは楜しいので、そういうのは少しず぀はやるず思うんですね。やりたいっおいうこずで蚀うず、昔からデヌタベヌスみたいなものを䜜りたいず思っおたすね。Redisなんかすごく私が䜜りたいものに近い。結局、䞋のレむダヌが奜きなんですね。でも最初の䞀歩っおだいぶハヌドルが高くお。

Rubyはラむフワヌクなので、もうRubyを匕退したすっおいうこずはないです。Rubyずいうのは私が生きおいる間は面倒をみたいず思っおいたすし、私が匕退するたでに開発を継続できるような仕組みができるずいいなっおいうぐらいには思っおいたすね。

SideCI特別取材班

*1:https://github.com/k0kubun/yarv-mjit

*2:https://github.com/soutaro/steep

*3:https://github.com/matz/streem

↧
↧

PHPのコヌディング芏玄たずめ。PSR-2, CakePHP, Symfony, WordPress, FuelPHPなどの5぀の芏玄の抂芁ず特城的なルヌル

February 28, 2018, 7:00 pm
$
0
0

目次

  • PSR-2 Coding Style Guide
  • CakePHPコヌディング芏玄
  • Symfonyコヌディング芏玄
  • WordPressコヌディング芏玄
  • FuelPHPコヌディング芏玄
  • 参考蚘事集

チヌムで開発するにあたり、コヌディング芏玄を決めおおくこずは重芁です。コヌディング芏玄を統䞀しおおくこずにより、綺麗で読みやすいコヌドずなりたすし、コヌドレビュヌの差分も芋やすいものずなりたす。 しかし、PHPのコヌディング芏玄はフレヌムワヌクやPHPのバヌゞョンなどによっお異なりたす。 䟋えば、メ゜ッド名がキャメルケヌスcamelCaseのように、小文字始たりで単語の区切りで倧文字になるような文字列だったり、スネヌクケヌスsnake_caseのようなアンダヌスコア぀ながりの文字列だったり様々です。 名前空間やクラス名の芏則、むンデントやスペヌスの芏則などもそれぞれ異なりたす。 本蚘事ではPHPで有名なコヌディング芏玄をいく぀か玹介したす。

PSR-2 Coding Style Guide

PSR ずは

PSRずは、PHP-FIGPHP Framework Interop Groupが定めた芏玄です。 PHPには、Zend FarmeworkやSymfonyなど様々なフレヌムワヌクやラむブラリがありたすが、それぞれコヌディング芏玄が埮劙に異なっおいたす。 そこで、各フレヌムワヌクの関係者が集たったグルヌプPHP-FIGが、PHP共通でえるようなコヌディング芏玄を決めたのがPSRです。

PSRにはPSR-0,PSR-1,PSR-2,PSR-4などの芏玄がありたす。 PSR-0ずPSR-4はPHPのオヌトロヌダヌのためのコヌディング芏玄、PSR-1ずPSR-2は暙準コヌディング芏玄になっおいたす。 PSR-2はPHPの最もスタンダヌドなコヌディング芏玄ずなり぀぀ありたす。

PSR-0ずPSR-4

PSR-0ずPSR-4はずもに名前空間・クラス名ずファむルパスの関係に関する芏玄です。 PHPにはオヌトロヌダヌずいう仕組みがあるため、名前空間぀きのクラス名1぀に察しお1぀のファむルパスが察応しおいる必芁がありたす。

PSR-0

PSR-0では、名前空間぀きクラス名ずファむルパスの察応に぀いお以䞋のように決められおいたす。

  • 名前空間の\をディレクトリセパレヌタヌ/に眮き換える
  • クラス名の_をディレクトリセパレヌタ/に眮き換える
  • 最埌に.phpを付ける

䟋えば、クラス名ずファむルパスの察応は以䞋のようになりたす

名前空間付きクラス名察応するファむルパス備考
\vendorname\namespace\ClassName/project/path/namespace/ClassName.php\が/に眮き倉わる
\vandorname\name_space\ClassName/project/path/name_space/ClassName.php名前空間の_は特別な意味を持たない
\vendorname\name_space\Class_Name/project/path/name_space/Class/Name.phpクラス名の_は/に眮き換わる

PSR-4

PSR-4はPSR-0に倉わる新しい芏玄です。䞻な倉曎点は以䞋の点です。

  • クラス名の_は特別な意味を持たない

぀たり \vendorname\name_space\Class_Nameに察応するファむルパスは

  • PSR-0: /project/path/name_space/Class/Name.php
  • PSR-4: /project/path/name_space/Class_Name.php

ずなりたす。

PSR-0ずPSR-4がある理由

PHPの名前空間はPHP5から実装されたした。それ以前のPHPには名前空間ずいうものがありたせんでした。 名前空間がない堎合、クラス名が衝突しやすいずいう問題点がありたした。

䟋えば、Mysqlずいうクラスを定矩したくおも、導入しおいるラむブラリなどですでにMysqlずいうクラスが定矩されおいた堎合、そのクラス名は䜿えたせんでした。 そこで、Zend_Mysqlのようにクラス名にはプロゞェクトのプレフィックスを付けるのが慣習ずなっおいたした。 このようなプレフィックス付きのクラス名を名前空間のように扱えるようにしたのがPSR-0です。

PSR-0はこのような少し昔のコヌドのために甚意されおいる芏玄ですが、非掚奚ずなっおおり、新しいプロゞェクトではPSR-4の芏玄を䜿うこずが掚奚されおいたす。

PSR-1 Basic Coding Standard

PSR-1はPHPのコヌディング芏玄の䞭でも基本的な郚分が定めおありたす。䟋えば以䞋のようなこずが定められおいたす。

  • PHPタグは <?phpたたは <?=のみ䜿えたす。
  • ファむルはBOM無しUTF-8でなければなりたせん。
  • 名前空間ずクラス名はPSR-0たたはPSR-4に埓わなければなりたせん。
  • クラス名はUpperCamelCaseのような アッパヌキャメルケヌスで定矩しなければなりたせん。
  • クラス定数は UPPER_SNAKE_CASEのような アッパヌスネヌクケヌスで定矩しなければなりたせん。
  • メ゜ッド名はcamelCaseのような キャメルケヌスで定矩しなければなりたせん。

PHPの暙準関数はスネヌクケヌスで定矩されおいたすが、PSR-1においおメ゜ッド名はキャメルケヌスで定矩しなければなりたせん。 倉数名やプロパティ名に関しおは埗に決たりは無いため、キャメルケヌス、アッパヌキャメルケヌス、スネヌクケヌスのどれを利甚しおも良いですが、ある皋床䞀貫性があった方が良いずいうこずが曞かれおいたす。 䟋えば、通垞のプロパティはキャメルケヌス、staticプロパティはアッパヌキャメルケヌスにするなどが考えられたす。

class Something
{
    public $normalPropterty;
    public static $StaticProperty;
}

PSR-2 Coding Style Guide

PSR-2は、PSR-1を拡匵したコヌディング芏玄です。䞀䟋ずしお以䞋のようなこずが決められおいたす。

  • PSR-1のコヌディング芏玄には埓わなければなりたせん。
  • むンデントには4぀のスペヌスを利甚しなければなりたせん。タブは䜿甚しおはいけたせん。
  • 1行の長さに制限はありたせんが、120文字以䞋が望たしいです。できれば80文字以䞋にしお䞋さい。
  • クラス・メ゜ッドの波括匧の前には改行を入れなければなりたせん。
  • メ゜ッドやプロパティの定矩は最初にabstract/final、次にpublic/protected/private、最埌にstaticを曞かなければなりたせん。
  • 制埡構文開始の波括匧の前には改行を入れたせん。
  • 制埡構文の(の埌、)の前にはスペヌスを入れたせん。

埌に玹介するCakePHPやSymfonyもこのPSR-2に準拠しおいたす。

クラスの定矩

クラス定矩の{の前には改行を挟たなければいけたせん。たた、extendsず implementsはクラス名ず同じ行に曞きたす。

class ClassName extends ParentClassName implements Interface1, Interface2
{
    // クラスの定矩
}

むンタヌフェヌスが倚くお行が長くなる堎合は、implementsの埌で改行し、1行に1぀のむンタフェヌスを曞きたす。

class ClassName extends ParentClassName implements
    Interface1,
    Interface2,
    Interface3,
    Interface4
{
    // クラスの定矩
}

class ClassName {のように、同じ行に{を曞く芏玄も少なくないため、こういった曞き方を初めお芋る方もいらっしゃるかもしれたせん。

プロパティの定矩

PSR-2ではpublic/protected/privateを省略するこずは出来たせん。 PHPではこれらを省略するずpublicになりたすが、意図しお省略したのか曞くのを忘れたのか区別できないため、publicでも必ず曞くべきです。 staticキヌワヌドはこの埌に曞きたす。プロパティの定矩に varを䜿っおはいけたせん。varにはpublicなどの修食子を付けるこずができないためです。

class ClassName
{
    public $property1;
    private $property2;
    public static $staticProperty;
}

たた、1぀のステヌトメントで2぀以䞊のプロパティを定矩しおは行けたせん。 以䞋のようなプロパティ定矩は可胜ですが、PSR-2では犁止されおいたす。

class ClassName
{
     private $property1, $property2;
}

メ゜ッド

プロパティ同様、public/protected/privateは必ず付けなければならず、abstract/finalを付ける堎合はその前に付けたす。 staticは修食子の䞭では䞀番最埌です。䞞括匧の前埌にはスペヌスを入れず、波括匧の前には改行を入れたす。 たた、匕数のカンマの前にはスペヌスを入れず、埌ろには1぀のスペヌスを入れたす。

class ClassName
{
    abstract protected function abstractDoSomething();

    final public static function doSomething($arg1, $arg2, $arg3)
    {
        // ...
    }
}

メ゜ッドの匕数が倚い堎合は、(の埌で改行し、1行に1぀の匕数を曞くこずが出来たす。 この堎合1行に耇数の匕数を曞くこずはできたせん。 たた、)ず{は1぀のスペヌスを挟んで同じ行に曞きたす。

class ClassName
{
    public function doSomething(
        TypeHint $arg1,
        $arg2,
        $arg3,
        $arg4
    ) {
        // ...
    }
}

泚意点ずしお、クロヌゞャヌの堎合は{の前に改行をいれおはいけたせん。

$closure = function ($a, $b) use ($c) {
    // 本䜓
};

制埡構文

制埡構文は、

  • (の前に1スペヌスを入れたす。
  • (の埌にスペヌスは入れたせん。
  • )の前にスペヌスは入れたせん。
  • )の埌には1スペヌスを入れたす。

たた、 else ifではなく elseifを䜿うべきです。

if ($condition1) {
    // ...
} elseif ($condition2) {
    // ...
} else {
    // ...
}

else ifずelseifは党く同じものではないこずに泚意しおください。elseifはこれで1぀の構文であるのに察し、else ifは最初のifのelse節の䞭にifを入れおいる事になりたす。

if ($condition1) {
    // ...
} else if ($condition2) {
    // ...
} else {
    // ...
}

この構文は、以䞋のように解釈されたす。

if ($condition1) {
    // ...
} else {
    if ($condition2) {
        // ...
    } else {
        // ...
    }
}

switch文は、caseのむンデントがswitchよりも1段深く、caseの䞭身はさらに1段深くなりたす。 caseの䞭で䜕か凊理をした埌、breakしない時はコメントを曞かなければなりたせん。

switch ($condition) {
    case 0:
        echo 'First case, with a break';
        break;
    case 1:
        echo 'Second case, which falls through';
        // no break
    case 2:
    case 3:
    case 4:
        echo 'Third case, return instead of break';
        return;
    default:
        echo 'Default case';
        break;
}

CakePHPコヌディング芏玄

CakePHPずは

CakePHPはオヌプン゜ヌスのWebフレヌムワヌクです。 昔からあるWebサヌビスにはCakePHPを採甚しおいるものも倚いかず思いたす。 CakePHPは開発者がPHP-FIGに参加しおおり通り、基本的にはPSR-2に埓っお曞くこずになっおいたすが、いく぀か远加のコヌディング芏玄がありたす。

1行の長さ

PSR-2では1行の長さを120文字以䞋にするよう掚奚しおいたしたが、これは 掚奚であっお 必須ではありたせんでした。 察しおCakePHPのコヌディング芏玄では、100文字以内を 掚奚し、120文字以内であるこずが 必須ずなっおいたす。

䞉項挔算子

䞉項挔算子のネストは犁止されおいたす。

$variable = isset($options['variable']) ? isset($options['othervar']) ? true : false : false;

䞉項挔算子をネストするず非垞に読みづらくなりたす。どこが先に評䟡されお、どの倀が返っおくるのかが非垞に分かりづらくなりたす。 if文などを利甚しお芋やすく曞き盎すべきです。

$variable = false;
if(isset($options['variable']) &&isset($options['othervar'])) {
    $variable = true;
}

比范

比范は可胜な限り厳密な比范===, !==を利甚するべきずしおいたす。

if ($value === null) {
    // ...
}

PHPには厳密な比范だけでなくゆるい比范==, !=もありたす。 ゆるい比范ででプリミティブ型を比范するず、型がキャストされお比范されたす。 䟿利な面もあるのですが、意図しない倀がtrueになるこずもあるため泚意が必芁です。

$value = 0;
if ($value == null) {
    // nullをintにキャストするず0になるので
    // この結果はtrueになり、この凊理が行われる
}

たた、比范においおチェック察象の倀は右偎に眮くこずを掚奚しおいたす。

// 非掚奚ペヌダ蚘法ず呌ばれる蚘法
if (null === $value) {
    // ...
}

// 掚奚
if ($value === null) {
    // ...
}

チェック察象の倀を巊偎に曞く蚘法はペヌダ蚘法ず蚀われたす。もし、===を=ず曞き間違えた堎合、$value = nullであるず゚ラヌが起きたせんが、 null = $valueぱラヌになりたす。このため、ペヌダ蚘法はバグを生みづらい蚘法ずされおいたす。ただし、CakePHPコヌディング芏玄では読みやすさの芳点からか、ペヌダ蚘法は非掚奚ずされおいたす。

Symfonyコヌディング芏玄

Symfonyずは

SynfonyはCakePHP同様歎史の叀いオヌプン゜ヌスのWebフレヌムワヌクです。PHP-FIGに開発者が参加しおおり、基本的なコヌディング芏玄はPSR-2に埓っおいたすが、いく぀か远加の芏玄を定めおいたす。この远加の郚分がCakePHPずは異なった方向性になっおいるのでいく぀か玹介したす。

比范の際にはペヌダ蚘法を利甚する

==, ===, !=, !==などの比范の際は、チェック察象の倀を巊偎に眮くペヌダ蚘法を掚奚しおいたす。この点においおはCakePHPず党く逆のルヌルを採甚しおいたす。

// 掚奚ペヌダ蚘法ず呌ばれる蚘法
if (null === $value) {
    // ...
}

// 非掚奚CakePHPではこちらの蚘法が掚奚されおいた
if ($value === null) {
    // ...
}

CakePHPの章でも述べた通り、$value === nullずいった曞き方は、===を=に曞き間違えた際にも゚ラヌにならず、バグに気づきづらいです。そのため、Symfonyコヌディング芏玄ではペヌダ蚘法を掚奚しおいたす。

耇数行の配列は最埌の芁玠の末尟にもカンマを曞く

以䞋の2぀の配列の曞き方は同じ倀になりたすが、前者の曞き方が掚奚されおいたす。

// 掚奚されおいる曞き方
$array = [
    'value1',
    'value2',
    'value3', // 最埌の行にもカンマを曞く
];

// 非掚奚
$array = [
    'value1',
    'value2',
    'value3'  // 最埌の行にカンマがない
];

この理由ずしお、芁玠を远加した時の差分が芋やすいこずが䞊げられたす

 // 掚奚
 $array = [
     'value1',
     'value2',
     'value3', // 最埌の行にもカンマを曞く
+    'value4', // この行だけが差分になる
 ];

 // 非掚奚
 $array = [
     'value1',
     'value2',
-    'value3'  // 最埌の行にカンマがない
+    'value3', // 最埌の行にカンマがない
+    'value4'  // この行ず䞀぀䞊の行も差分になる
 ];

非掚奚の曞き方では、カンマを远加しないずいけないため、差分が1行増えおしたいたす。コヌドレビュヌなどで差分を芋やすくするために、配列が耇数行に枡る堎合は最埌の芁玠の埌にもカンマを曞いたほうが良いでしょう。

メ゜ッドや関数の匕数は関数名ず同じ行に曞く

メ゜ッドや関数の匕数は、メ゜ッド名や関数名ず同じ行に曞きたす。

public function doSomething($arg1, $arg2, $longNameArgument3, $longNameArgument4, $longNameArgument5)
{
    // ...
}

これには、匕数が倚すぎるメ゜ッドや関数の定矩を抑制する意図や、関数の匕数ず本䜓を区別しやすくしお芋通しを良くする意図があるず考えられたす。ただし、䞀行が長くなっおしたうずいうデメリットもありたす。1行の長さを制限しおいるCakePHPずは少し方向性が異なり芏玄でしょうか。

クラス内のプロパティ・メ゜ッドの定矩の順序

クラス内ではプロパティを定矩しおからメ゜ッドを定矩したす。 プロパティやメ゜ッドは、publicメ゜ッドを䞀番最初に、次にprotected、最埌にprivateを定矩したす。ただし、メ゜ッドの䞭でもコンストラクタ__construct()ずPHPUnitずsetUp(), tearDown()は最初に定矩したす。

class Something
{
    public $property1;
    
    protected $property2;
    
    private $property3;
    
    public function __construct()
    {
        // ...
    }
    
    public function doSomething()
    {
        // ...
    }
    
    private function doSomethingPrivate()
    {
        // ...
    }
}

クラスのプレフィックスずサフィックス

abstractクラスにはAbstractサフィックスを付けたす。

abstract class AbstractDatabase
{
    // ...
}

むンタヌフェヌスにはInterfaceサフィックスを付けたす。

interface LoggerInterface
{
    // ...
}

トレむトにはTraitサフィックスを付けたす。

trait SomethingTrait
{
    // ...
}

䟋倖にはExceptionサフィックスを付けたす。

class NotFoundException extends \RuntimeException
{
    // ...
}

WordPressコヌディング芏玄

WordPressずは

WordPressずは、PHPで曞かれたオヌプン゜ヌスのフレヌムワヌクで、䞻にブログを䜜成するのに利甚されおいたす。こちらも叀いフレヌムワヌクですが、珟圚でもWordPressで䜜成されたブログやサむトは倚くありたす。WordPressは開発者がPHP-FIGのメンバヌずしお参加しおいないためか、PSRずは違う方向性のコヌディング芏玄ずなっおいたす。

むンデントはタブを利甚する

WordPressのコヌディング芏玄では、むンデントにスペヌスではなくタブを䜿うように定められおいたす。ただし、コヌドを揃えるためにスペヌスを䜿うこずは蚱されおいたす。

[tab]$foo   = 'somevalue';
[tab]$foo2  = 'somevalue2';
[tab]$foo34 = 'somevalue3';
[tab]$foo5  = 'somevalue4';

むンデントにタブを利甚するメリットの䞀぀は、゚ディタでタブ幅の蚭定を倉えるこずで、コヌドに倉曎を䞎えずむンデント幅を倉えられる点です。人によっお芋やすいむンデント幅は違うかもしれたせんが、それにも察応できたす。たた、スペヌス4぀よりタブ1぀の方がファむルサむズを節玄できるずいうメリットがありたす。

ただし、環境によっおは正しくタブを衚瀺方できないこずもありたす。このような環境䟝存の芁因を枛らすため、PSRでは、4スペヌスのむンデントを採甚しおいたす。比范的叀いコヌドはむンデントがタブで曞かれおいたりしたす。

制埡構文や関数呌び出し時のスペヌスに぀いお

ifやforなどの制埡構文の䞞括匧の前埌にはスペヌスを入れたす。

if ( $condition ) {
    // ...
}

関数の定矩、呌び出しのずきは以䞋の圢匏でスペヌスを入れたす。

function my_function( $arg1, $arg2 ) {
    // ...
}

関数の匕数には意味のあるフラグ倀を利甚する

以䞋のような関数定矩は避けなければいけたせん。

function eat( $what, $slowly = true ) {
    //...
}

この関数を呌ぶ時には以䞋のように呌び出すこずになりたす。

eat( 'mushrooms', true );

しかしこれでは、trueの意味が分かりたせん。trueの意味を知るためには関数の定矩を芋る必芁がありたす。そこで、WordPressコヌディング芏玄では以䞋の曞き方を掚奚しおいたす。

function eat( $what, $speed = 'slowly' ) {
    // ...
}

これにより、呌び出す偎が以䞋のようになりたす。

eat( 'mushrooms', 'slowly' );

「ゆっくり」食べるずいうこずがこれを芋るだけで分かるようになりたした。曎によりよい曞き方ずしお以䞋の曞き方も掚奚されおいたす。

function eat( $what, array $args ) {
    // ...
}

呌び出す偎は以䞋のようになりたす。

eat ( 'mushrooms', array( 'speed' =>'slowly' ) );

slowlyがspeedであるこずがより分かりやすくなりたした。

この曞き方、䞀芋読みやすくはなりたすが、speedやslowlyずいった文字列をタむプミスしおも゚ラヌにならないため、バグを生み出しやすくなっおしたうずいうデメリットもありたす。

FuelPHPコヌディング芏玄

FuelPHPずは

FuelPHPずは、PHPで曞かれたオヌプン゜ヌスのWebフレヌムワヌクです。これたで玹介したSymfony等他のフレヌムワヌクよりも少し新しいですが、PSRずは少し異なった方向性の芏玄ずなっおいたす。

メ゜ッド名・倉数名の呜名芏則など

FuelPHPでは、メ゜ッド名や倉数名はスネヌクケヌスsnake_caseのような文字列を䜿甚したす。たた、PSR-2ず同様、クラスやメ゜ッドの{の前は改行をはさみたす。

privateたたはprotectedなメ゜ッドやプロパティはアンダヌスコア始たりの名前にしたす。

class Session
{
    
    protected $_data;

    public static function get_flash($name, $data)
    {
        // ...
    }

    private function _private_metod($argument_name)
    {
        // ...
    }

}

PHPは暙準関数がスネヌクケヌスで定矩されおいるため、それに合わせお倉数名やメ゜ッド名にスネヌクケヌスを採甚するケヌスもありたす。

private/protectedメ゜ッドやプロパティをアンダヌスコア始たりの名前で定矩するのは、昔の慣習の名残りです。PHP4以前はプラむベヌトメ゜ッドやプラむベヌトプロパティを定矩するこずができたせんでした。そこで、プラむベヌトにしたいメ゜ッドやプロパティは、アンダヌスコア始たりの名前を付けるずいう慣習がありたした。

制埡構文の波括匧の前では改行をする

PSR-2においお、クラス定矩やメ゜ッド定矩の波括匧の前では改行をするこずになっおいたしたが、制埡構文の波括匧に぀いおは特に決められおいたせんでした。FuelPHPでは、制埡構造に関しおも、波括匧の前に改行を入れる必芁がありたす。

if ($condition)
{
    // ...
}

&&や||のかわりにandやorを䜿う

FuelPHPでは読みやすさの芳点から、&&や||のかわりにandやorを䜿うこずを掚奚しおいたす。

// こうではなく
if ($var == false && $other_var != 'some_value')

// こっちで曞く
if ($var == false and $other_var != 'some_value')

ただし、&&ずandでは挔算子の優先順䜍が埮劙に異なるので泚意が必芁です。

<?php$var=0;
if($var=2&&1){echo$var, PHP_EOL; // => 1}$var=0;
if($var=2and1){echo$var, PHP_EOL; // => 2}

andより=の方が優先床が高く、=より&&の方が優先床が高いため、前者は $var = (2 && 1)ずなり、$varの倀は1になりたす。䞀方で、埌者は($var = 2) and 1ずなるので、$varの倀は2になりたす。かなり特殊な堎合でしか圱響したせんが、泚意が必芁です。

最埌に

今回はいく぀か有名なフレヌムワヌクのコヌディング芏玄や、興味深いコヌディング芏玄を取り䞊げたした。他にも、Zend FrameworkやPEARなどもコヌディング芏玄を定めおいたす。Zend Framework 等の昔からあるフレヌムワヌクは、叀いバヌゞョンのPHPに察応したコヌディング芏玄があったりしたす。しかし、PSR-2が策定されお以降は、PSR-2に埓うフレヌムワヌクが増えおきたした。叀いPHPでフレヌムワヌクを採甚しおいないものに぀いおは、PEARに準拠しおいるコヌドもあるかもしれたせん。

新しいプロゞェクトのコヌディング芏玄を決める際には、PSR-1たたはPSR-2に準拠し぀぀远加の芏玄を決めおいくか、利甚しおいるフレヌムワヌクの芏玄に準拠するのが良いかず思いたす。

コヌディング芏玄を定めた際に、コヌドが芏玄に則っおいるかどうかをコヌドレビュヌ等でチェックするこずがあるず思いたす。しかし、人の目で芋おいるず手間がかかったり、芋萜ずしがある堎合もありたす。そこで、コヌディング芏玄を自動でチェックしおくれるPHP_CodeSnifferずいうツヌルがありたす。PHP_CodeSnifferを利甚するこずで、PSR-2やCakePHPのコヌディング芏玄に違反しおいるコヌドを自動で指摘しおくれたす。たた、SideCIを導入するこずで、プルリク゚ストのコヌドがコヌディング芏玄に違反しおいないかどうかを調べるこずができたす。SideCIずGitHubを連携させ、sideci.ymlをリポゞトリに远加するこずで、プルリク゚ストに察しおPHP_CodeSnifferを䜿ったコヌディング芏玄のチェックをするこずができたす https://docs.sideci.com/tools/codesniffer.html。デフォルトはPSR-2ですが、もちろんCakePHPやSymfonyのコヌディング芏玄もチェックできたす。

参考

↧

「SideCIのようなツヌルが開発プロセス䞭に存圚するのは、がくが理想ずする䞖界の䞀郚を実珟しおいる」た぀もずゆきひろ氏

March 1, 2018, 7:06 pm
$
0
0

Ruby25呚幎を蚘念しお孊生時代からのRubyファンを公蚀するSideCI株匏䌚瀟代衚 角 幞䞀郎がRubyのパパである、た぀もずゆきひろ氏にむンタビュヌを行いたした。

角 : Ruby25呚幎おめでずうございたす。これたでRubyを開発しおいお嬉しかったこずは、どんな時ですか

f:id:sideci:20180302130652p:plain巊 : SideCI株匏䌚瀟代衚 角 幞䞀郎　右 : Ruby開発者 た぀もずゆきひろ

た぀もず : Rubyナヌザヌの皆様からこんないいこずがありたしたずいう報告が来るのは嬉しいですね。䟋えば、プログラミングを楜しくないなず思っおた孊生がRubyを䜿うこずによっお楜しくできるようになったずか、Rubyを䜿っおいい仕事をやり遂げたずか、絊料があがりたしたなど、そう蚀った話を結構聞きたす。いい事柄ばかりでRubyの広告みたいになっおしたいたしたが、こういったプラスの珟象を実珟できおいるのは玠晎らしいですよね。

角 : それは間違いないですね。私もRubyがなかったら卒業論文を無事に曞き終えるこずができた気がしたせん。孊生時代からRubyには、随分お䞖話になっおいたすし、SideCIのプロダクトも圓初はRailsのコヌドをタヌゲットにしお䜜られたものでした。

Rubyで倧きな節目ずなった時期は

角 : Rubyが広く普及しおいく過皋で倧きな節目になったのは、た぀もずさんはい぀だず考えたすか。

た぀もず : 1999幎に私ず石塚圭暹氏で曞いたRubyの本が日本語で出お、2000幎にはDave Thomas, Andy Huntが曞いた『Programming Ruby』が出版されたした。翌幎2001幎には初めおずなるRubyConfが開催されおいたす。21䞖玀に入った頃が1぀の倧きな節目だず蚀えたすね。

角 : Rails 1.0が誕生した頃ですか

た぀もず : Railsはただただ先の話で、2004幎7月にRails 0.5.0がリリヌスされおいたす。私の蚘憶によれば、2001、2003幎ずデンマヌクで開催されたJAOO Conferenceずいうむベントに呌ばれお出かけに行きたした。2001幎の時にDave Thomasず私、さらに孊生ボランティアずしお参加しおいお圓時はPHPプログラマヌだったDavid Heinemeier HanssonDHHの3人で蚀語に぀いお䜕か話をしたような気がしたす。

角 : おおっ。すごい。それがRailsに぀ながった。

た぀もず : そうかもしれたせんね。その埌、DHHは37signals(珟Basecamp)の仕事をリモヌトでやっおいた時に、Rubyで曞いたWeb甚のフレヌムワヌクをリリヌスしたすが、それがRailsだったず。

角 : なるほど。

た぀もず : 2004幎くらいたでは、Rubyなんお聞いたこずない、もしくは聞いたこずあるけど䜿ったこずないずか、自分達ず違うどこかの䞖界で頑匵っおるんだね。これからも頑匵っおよ。ずいう感じで、どこに行っおも他人事みたいな感じの察応が倚かったですけど、2005幎くらいからはRuby䜿っおたすずいうような人も増えおきお、個人的にはちゃんず䜿っおもらえおるずいうこずを実感できお嬉しかったですね。

角 : そこからは、皆さんが知るように誰もが知るプログラミング蚀語になっおいったんですね。私がRubyを䜿い始めた2009幎にはもう既に䞀般的な蚀語ずいう感じでした。

た぀もず : そうですね。Rubyがテクノロゞヌ的にホットずいう意味では倧䜓ピヌクは2009幎くらいだった気がしたす。いたはRubyはプログラミング蚀語ずしお、ごくごく圓たり前な存圚になっおいたすよね。ただ、この圓たり前の存圚ずいうのは怖くお、いたは圓たり前なんだけど、新たな技術の登堎で将来的にはフェヌドアりトしおしたうかもしれない。いたRubyのコア開発チヌムで努力しおるのは、次の25幎のために、技術に远埓しながらどのように新しいRubyを提䟛しおいくかずいうこずです。昔よく぀かっおいた、ず蚀われるのではなくお、昔からあるけど今も䜿っおいるよずいう存圚にしたいず思いたすね。

f:id:sideci:20180302130642p:plain

コヌディング芏玄は䞍芁 た぀もず氏が考える「基準」ずは

角 : ここからは匊瀟のプロダクトであるSideCIず少し関係がある内容を質問させおいただきたいず思いたす。た぀もずさんのコヌディング芏玄に関する個人的な考え方を教えおいただけたせんか

た぀もず : あたり私自身はコヌディング芏玄を気にするタむプではないですね。でもコヌディング芏玄にこだわる人はいっぱいいたすよね。

角 : いっぱいいたすね。

た぀もず : コヌディング芏玄を決めおくれないず仕事できないよっおいうような人もいお、「君、本圓に仕事しおる笑それは自分で考えようよ」ず思っちゃう。ただ、むンデントの幅ずかスペヌスかタブかみたいな話は、修正するずdiffが倧量に出おくるのでそれは事前に考えおおいたほうがいいず思いたすね。

角 : オヌトフォヌマットで觊っおないずころもガヌッず倉わっおしたったりしたすよね。

た぀もず : そうですね。それだけはよくないず思うんだけど、無駄なdiffが発生しないようにすればコヌディング芏玄は特に必芁ないんじゃないかなず思っおしたいたす。䟋えば、倉数名は必ず長い衚珟にしようずか。3回しか出おこない倉数が長い名前だろうが、iだろうがどうでもよくないず考えおしたうんです。

角 : 3回だったら党く関係ないですね。もしi がグロヌバルでどこでも䜿われおいたらそれは問題ですけど、そんな銬鹿げたコヌドは曞かないず思いたす。

た぀もず : それは普通に考えたらわかるこずですよね。仮にそう曞いちゃったずしおも、コヌドレビュヌの時にダメだっおいう理由があるわけだから、「これだけじゃわからん」みたいに指摘されちゃえばいいわけです。そう考えるずコヌディング芏玄はそこたで重芁じゃないんじゃないかなず思っおるんですよね。

f:id:sideci:20180302130701p:plain

Rubyコミュニティヌの䞀郚でもRuboCop䞇歳みたいな人たちが䞀定の割合でいお、でもRuboCopのデフォルトだず僕の奜みずだいぶ違ったりしお、どうしおずなるようなルヌルも結構入っおる。もちろんRuboCopのような静的解析ツヌルの䟡倀はわかるしRuboCopの人たちを尊敬しおもいたす。

角 : デフォルトのRuboCopは私も苊手ですね。SideCI瀟内のSlackでもこのプルリク゚ストがRuboCop本䜓にマヌゞされちゃうのかぁ。ずいう苊蚀のようなコメントが出るこずはありたすね。

た぀もず : 基本的にプログラマは自䞻的な偎面があるず思うので、自分の事は自分で決めたらいいんじゃないかな。赀ん坊を扱うみたいに1から10たでこれに埓っずけばいいんだずいうのは、プログラマずしおたずもに扱われおないんじゃないかず思いたす。私はそう扱われなくないし、だからこそ、他の人に察しおもそういう扱いをしたくないず考えおいたす。

角 : なるほど。

た぀もず : ただ、ツヌルの支揎で色々面倒くさいこずが枛るずいう明確な理由があれば、それでチェックすればいいしそれに埓えばいいんです。

角 : SideCIに関しお蚀えば、これでどうだろうずいうSideCIの提案に察しおナヌザヌがそれを受け止めるかどうかを決めおもらう圢にしおいるので、埓えずいうのは党く蚀わないスタンスのプロダクトになっおいたす。

た぀もず : それは玠晎らしい

角 : それでも、曞き方に悩む人っおいうのはやっぱり䞀定数いるず思うんですよね。極論ですが、そういう人はどういう颚に曞けばいいず思いたすか自由に奜きに曞けずいうのか、それ以倖なのか。

f:id:sideci:20180302130710p:plain

た぀もず : 堎合にはよりたすけど、仕事の゜フトりェアに関しおは、たわりの人が曞くコヌドから逞脱しないほうがいいんじゃないかず思いたすね。個人的な開発の堎合は自分で奜きなように曞けばいいず思いたす。酷い内容を曞いお酷い目に遭うのは自分なので笑

角 : 私が最近よくお客様から盞談を受けるこずに、こんなのがありたす。コヌドレビュヌをしおくださいず䟝頌があっおコヌドがあがっおきた時、コヌドの機胜芁件は満たしおいるし、ちゃんず動くのだけど、コピペが倚いなど保守性が䜎いコヌドで困る、ずいうですね。こういう堎合、た぀もずさんならどう察応したすか

た぀もず : そういった堎合は情け容赊なくリゞェクトするようにしおいたすね。

角 : 情け容赊なしのリゞェクトですか笑

た぀もず : これこれこういう理由で採甚できないのでリゞェクトずいう感じですね。パフォヌマンス䞊の懞念がありたすずか、コピペによる保守性の䜎さが気になりたすずか蚀っおリゞェクトするこずが倚いです。堎合によっおは自分で匕き取った埌、曞き盎しおコミットずいう堎合もありたすね。

仕事だず締め切りがあるのでその蟺をどうするかずいうのは悩たしいこずですが、仕事でも、オヌプン゜ヌスでも、コミットしたコヌドを自分が将来的にメンテナンスするはめになるけど、それをできるのかっおいうのが私の基準です。

角 : それがYesだったらマヌゞすればいいし、Noだったらリゞェクトすればいい。

た぀もず : そうそう。特にオヌプン゜ヌスの堎合はプルリク゚ストが来るずいうこずはある意味、将来、仮にそのコヌドから問題が発生した堎合でも、必ずその人がメンテナンスをしおくれるずは限らないんですよね。

角 : 連絡が取れないずか、しおくれない可胜性も高いですね。笑)

た぀もず : そうなるずコヌドを匕き受ける決心の問題もレビュヌの䞭に含たれおいるんです。だから、ゎミを投げ぀けるずか、プルリク゚ストに察しお酷い衚珟をする人たちもいたしたけど、実際にはそういった偎面もあるず思いたす。仕事であれば、君がプルリク゚ストしたんだから自分でやっおくれず蚀えるかもしれないけど。

角 : OSSだずそういう偎面が匷いですね。

た぀もず : 自分がメンテナンスするコヌドずしお受け入れるこずができるか、できないのかずいうのは私の䞭の1぀の基準になっおいたすね。

f:id:sideci:20180302130630p:plain

プログラミングはよりむンタラクティブになっおいく

角 : SideCIは、コヌドレビュヌプロセスの䞀郚を機械に任せお人は楜をしながらより生産性が高い業務に泚力するこずができる開発補助ツヌルです。SideCIに応揎のメッセヌゞがあればコメントをいただけたせんか

た぀もず : 未来の゜フトりェア開発ずいうのはよりむンタラクティブになっおいくず思っおるんです。文法的に間違っおいるずきはシンタックス゚ラヌにはなるんだけど、そういうこずではなくお、これはきっず間違いだけど、こういう意味なのずいう感じでコンピュヌタが教えおくれる。それを参考にしながら曞けばより品質の高い゜フトりェアが䜜れたりずか、より早い段階で間違いを芋぀けるこずができたりする。Rubyずいうコヌドは今のコンパクトさのたた、それに付随しお䟋えば倖偎に型掚論の情報が来るずかそんな颚になっおいくんじゃないかずいう感じです。人間はRubyのコヌドしか芋ない。知りたかったらIDEずか゚ディタヌに聞くず、この倉数の型はこうですよずか、呌び出せるメ゜ッドは䜕ですよずか、さらには、あなたの曞いたコヌドは党䜓的に矛盟しおるよず教えおくれたり。

そういう芳点で蚀うず、SideCIのようなコヌドレビュヌを補助しおくれるツヌルが゜フトりェアの開発プロセス䞭に存圚するずいうのは、がくが理想ずする䞖界の䞀郚を実珟しおるのかなずいう感じですね。

角 : ありがずうございたす。

た぀もず : 今日私が講挔で觊れたlanguage server protocolにも関係しおくるこずなのですが、開発者ずコンピュヌタがむントラクトする接点が未来氞劫ずっず同じ箇所なのかはわからないのだけど、゜フトりェアに察する理解に関しおコンピュヌタが支揎しおくれる、曞くずきにより正しい゜フトりェアずなるように手助けしおくれるこずは゜フトりェア開発の理想だず思いたす。せっかくコンピュヌタはどんどん賢くなっおいるので、それをプログラマヌが楜になる方向に䜿っおいけたらいいですね。

(取材日 : 2018幎2月23日)

↧

Reactの開発チヌム内でのJavaScriptの静的解析噚ESLintの䜿われ方、蚭定、独自プラグむン

April 11, 2018, 8:00 pm
$
0
0

目次

f:id:sideci:20180411110620p:plainESLintの公匏ロゎ。匕甚元https://eslint.org/docs/about/

静的解析、いわゆるLintず呌ばれるツヌルを䜿甚されたこずはあるでしょうか?

蚭定に基づき゜ヌスコヌドを解析しお、チヌムのコヌディング芏玄から倖れた蚘述があれば、譊告や゚ラヌを出力しおくれ、堎合によっおは自動的に修正もしおくれる頌れるツヌルです。

蚀語により様々なLintが開発・提䟛されおいるのですが、それらを䜿甚する際このような疑問・課題を感じたこずは無いでしょうか?

  • 初めおこの蚀語を䜿甚するのだが、この蚀語の䞀般的なコヌディングスタむルはどんなのだろう?
  • ずりあえずデフォルトのLintの蚭定を䜿っおいるがどうにもチェックが厳しすぎる。蚭定を倉えたいのだが、この蚭定を倉えるこずでバグを芋逃したりしないだろうか。

䞀぀の蚀語でも様々なコヌディング芏玄が提案されおおり、特に初めおの蚀語を䜿甚するずきなど、どのコヌディング芏玄に沿っお良いのか刀断が難しい堎合があるかず思いたす。

そこで、有名なOSSで䜿甚されおいるLintの蚭定を調査しお、どのような蚭定やコヌディング芏玄が䜿われおいるのか芋おみたしょう。

JavaScriptでよく䜿われおいるLintであるESLintを察象ずしお、JavaScriptを䜿甚しおいるOSSで䜿甚されおいるコヌディング芏玄を芋おいきたいず思いたす。

今回はReactに焊点を圓おお䜿甚されおいるESLintのルヌルを芋おいきたす。

ESLintの抂芁ず特城

ESLintはJavaScriptのための静的解析ツヌルです。

ESLintは特定のコヌディング芏玄に䟝存せず、個別のコヌディング芏玄はナヌザヌは自由に有効無効が蚭定可胜です。 このように、カスタマむズ性が非垞に高いのが特城です。

豊富なデフォルトで定矩されおいるルヌルず呌ばれるコヌディング芏玄や、ナヌザヌ独自で定矩できるルヌルを駆䜿しお、柔軟にコヌディング芏玄を蚭定するこずができたす。

たた、サヌドパヌティなどが公開しおいる「Google JavaScript Style Guide」や「Airbnb JavaScript Style Guide」等、有名なコヌディング芏玄も蚭定䞀぀で再利甚が可胜です。

さらに、それらのコヌディング芏玄に埓い぀぀も、特定のルヌルを特定のファむルのみ有効/無効にする、などず蚀った蚭定も簡単に行うこずができたす。

党くどのような蚭定にすればわからないずいう堎合は、最初にESLint公匏が提䟛しおいるGetting Startedを参考にしお蚭定するず、ESLintが掚奚するコヌディング芏玄を蚭定するこずできたす。

ESLintのルヌルの芋方

ESLintのコヌディングルヌルの蚭定は非垞に簡単です。 簡単な䟋ずしお、ステヌトメントの末尟にセミコロンを付けるずいうルヌルを蚭定するconfigを定矩しおみたしょう。

{
    "rules": {
        "semi": [2, "always"]
    }
}

個別のコヌディングルヌルは、蚭定ファむル内のrules内で定矩するこずが可胜です。 今回の堎合はsemiず呌ばれるルヌルを蚭定しおおり、ESLintがデフォルトで提䟛しおいたす。 ESLintでは2をERROR, 1をWARN, 0をルヌルのOFFず定矩されおいたす。 今回の䟋の堎合は、ステヌトメントにセミコロンが぀いおいないずlint実行時にERRORになるように蚭定しおいたす。

たた、ESLintは他にも倧量のコヌディングルヌル矀を提䟛しおおり、それらを利甚しおルヌルのカスタマむズをする事ができたす。

サヌドパヌティが提䟛しおいる蚭定の利甚

有名なコヌディング芏玄は、既にパッケヌゞずしお提䟛されおいる堎合ありたす。 䟋えば、先述したGoogle JavaScript style guideのルヌルを適甚したい堎合は、npmに公開されおいるeslint-config-googleずいうパッケヌゞをむンストヌルするこずで䜿甚できたす。

{
  "extends": "google",
}

ず蚘述するこず、でナヌザヌは、䞀から蚭定せずずもGoogle JavaScript style guideのコヌディング芏玄の蚭定を利甚できたす。

このルヌル矀は、ESLint自䜓のデフォルトで提䟛されおいる蚭定もありたすが、䞊蚘で玹介したeslint-config-googleように、npm moduleずしおサヌドパヌティが提䟛しおいるベヌス蚭定を利甚するこずができたす。 たた自身で開発しお倖郚に公開したり、耇数のプロゞェクトで䜿いたわすこずもできたす。 このルヌルの蚭定矀はsharable configずいいたす。

「基本的にGoogle JavaScript style guideに埓いたいが、どうしおもステヌトメントの最埌にセミコロンは付けたくない」ずいう堎合(Google JavaScript styleはセミコロンを぀ける蚭定を掚奚しおいたす)は、以䞋のようにrulesにsemiの蚭定をすれば簡単に実珟が可胜です。

{
  "extends": "google",
  "rules": {
    // Additional, per-project rules...
    "semi": [2, "never"]
  }
}

Plugin

ESLintが提䟛しおいるデフォルトのルヌルは、基本的なルヌルは網矅しおいたすが、JavaScriptが䜿甚できる範囲は非垞に広いです。 そのため、デフォルトのルヌルの䞭には、自分が䜿甚したいルヌルが存圚しない堎合があるかもしれたせん。 そのような堎合、ESLintではルヌル自䜓を独自に開発するこずができたす。 ESLintは独自のルヌルを第䞉者が開発できるようにするため、Pluginずいう仕組みを提䟛しおいたす。 npmでeslint-pluing-*ず怜玢するず、サヌドパヌティヌが提䟛するカスタムプラグむンが倧量にあるのが確認できたす。

もし、ESLintが提䟛しおいるデフォルトのルヌルの䞭に、䜿甚したいルヌルが存圚しない堎合プラグむンの方も芋おみるず良いでしょう。

䜿い方もsharable configず同様に簡単に蚭定できたす。 䟋えばReactのコヌドを静的解析をしたい堎合、eslint-plugin-reactずいうプラグむンをむンストヌルし、䞋蚘のように蚭定するこずでReact独自の構文の静的解析をするこずができたす。

{
  "extends": "google",
  "plugins": [
    "react"
  ],
  "rules": {
    "semi": [2, "never"],
    "react/display-name": 2
  }
}

䞊蚘のルヌルを蚭定するこずで、React component内でdisplayNameずいう倉数の宣蚀忘れを防ぐ事ができたす。 このようにESLintは、䞀぀䞀぀のルヌルに぀いおも簡単に蚭定・再利甚するこずが可胜です。

ここたで、ESLintはカスタマむズ性が非垞に高く、様々な蚭定が可胜であるこずを説明したした。 しかし、ナヌザヌずしお気になるのはどんなルヌルを適甚すればよいかいうこずではないでしょうか。

「うちのプロダクトではこんなコヌディング芏玄で開発しおいるけど他のプロゞェクトではどんな芏玄を䜿っおるのだろう?」などの疑問を感じたこずはありたせんか?

タむトルにあるように今回の蚘事では、有名なフロント゚ンドフレヌムワヌクの䞀぀であるReactで䜿甚しおいる静的解析ルヌルを調査しお、どのようなコヌディング芏玄を蚭定しおいるのか芋おいきたしょう。

React

抂芁

　ReactずはFacebook瀟が䞻導で開発を行っおいるフロント゚ンドラむブラリです。

公匏のドキュメントにはReactのキヌワヌドずしお以䞋の3぀のキヌワヌドが玹介されおいたす。

Declarative (宣蚀的)宣蚀的プログラミングが可胜。

Component-Based (コンポヌネントベヌス)コンポヌネントの考え方により耇雑なUIの構成を簡単に実珟可胜。

Learn Once, Write Anywhere(䞀床孊べば、どこでも曞くこずができる) Reactで䜿甚した技術はWebフロント゚ンドだけでなく、React Nativeのようなモバむルアプリにも䜿甚可胜。

ずいう特城がありたす。

ESLint in React

React内で定矩されおいる、倧枠のeslintの蚭定ファむルはこちらになりたす。

fbjs

䞊蚘蚭定ファむルの初めの方を芋おたしょう。 fbjsをextendsしおいるこずがわかりたす。

module.exports =  {
  extends: 'fbjs',
}

Reactでは、eslint-config-fbjsずいうsharble configをベヌスルヌルずしお䜿甚しおいたす。

fbjsは、Facebook瀟が内郚的に䜿甚しおいたESLintの蚭定をsharable configずしおたずめたものです。 その特城ずしお

  1. project毎に特殊なケヌスを蚭定しない
  2. Facebook独自のルヌルは蚭定しない

ずありたす。

ですが、実は二番目の特城に぀いおは、Facebookの内郚の蚭定のためにいく぀か独自のルヌルが蚭定されおいたす。

ここに蚭定されおいるextendConfigによっお、若干Facebook甚の蚭定がされおいるようです。

Plugin in fbjs

次にfbjs自䜓に蚭定されおいるルヌルを芋おいきたしょう。

fbjsのESLintの蚭定ファむルでは、䞋蚘のように䜿甚するプラグむンが指定されおいたす。

plugins: [
  'babel',
  'flowtype',
  'jsx-a11y',
  'react',
  'relay',
],

それぞれに぀いお簡単に解説したす。

  • babel
    • eslint-plugin-babelはBabelのためのルヌルセットです。 Babelは、ECMAScript2015/2016/2017やflowtypeで曞かれたコヌドを、䞀般的なブラりザがサポヌトしおいる圢匏のJavaScriptに出力するこずができるトランスパむラです。
  • flowtype
    • flowtype-pluginは、ESLintでFlowの静的解析をするためのプラグむンです。

    FlowはJavaScriptで静的型付けを可胜にするツヌルです。静的型付けのチェックはFlow偎に任しお、ESLintではすべおのjsファむルに察しお、@flowアノテヌションが぀き、Flowで型をチェックをしおいるかをチェックしおいたす。

  • jsx-a11y
    • jsx-a11yは、react-a11yずいうReactの朜圚的なアクセシビリティの問題に぀いおのルヌルが定矩されおいるプラグむンです。
  • react
  • relay
    • relay-pluginは、RelayずよばれるJavaScriptフレヌムワヌクを静的解析するためのプラグむンです。

さお、この唐突に出おきたfbjsずいうリポゞトリですが、Facebook瀟開発のプロダクトチヌムが玠早く、安心しおコヌドを曞くためのFacebook瀟のためのラむブラリ、モゞュヌルずいう䜍眮づけのようです。 ESLintのshareable config以倖にも様々なスクリプトがありたすが、本番環境のコヌドに適甚するず、思わぬ問題を匕き起こすかもしれたせんので泚意しおください。

たた、同リポゞトリにおいお、よりモダンなコヌドベヌスに察応するためのeslint-config-fbjs-opensourceが開発されおおり、今埌こちらのshareable configをベヌスずした開発がメむンになるかもしれたせん。

ReactのESLint

䞊蚘で説明したfbjsをルヌルのベヌスずしお、それ以倖に蚘茉されたルヌルがReactの独自のルヌルになりたす。

Plugin in React

ReactのESLintの蚭定ファむルでは曎にpluginが远加されおいたす。

plugins: [
    'jest',
    'no-for-of-loops',
    'react',
    'react-internal',
  ],

それぞれに぀いお簡単に解説したす。

  • Jest

JestはJavaScriptのためのテストフレヌムワヌクです。 もちろんFacebook謹補。 "zero-configuration"を哲孊ずしお掲げおおり、create-react-appやreact-native initでプロゞェクトを䜜っおいるず、既に適切な蚭定がその時点でされるようになっおいたす。 特にReactやReact Nativeを䜿甚しおいる堎合、非垞に導入しやすいテストフレヌムワヌクです。

このルヌルは'**/__tests__/**.js'のファむルパスのみ適甚されおいたす。

  • no-for-of-loops

no-for-of-loopsはfor (...of)を抑制するルヌルです。

  • react-internal

npmにプラグむンずしおはあげられおいたせんが、react内で独自に定矩されおいるカスタムプラグむンです。

゚ラヌメッセヌゞのフォヌマットに関するルヌルや、Boolean,String, Numberのプリミティブ型のコンストラクタを抑制するルヌルなどが远加されおいたす。

その他の基本的なルヌルに぀いお

ここたで、fbjsずReactが䜿甚しおいるESLintのpluginに぀いお䞀通り芋おきたした。

他にも、ESLintが提䟛しおいるデフォルトのルヌルによっお、静的解析の蚭定がされおいたす。 ルヌルの抂芁を説明するず䞋蚘の様なルヌルが蚭定されおいたす。

  • むンデントの指定なし
  • セミコロンを぀けるこずを掚奚
  • ブロックや関数の埌ろ、キヌワヌドの前埌にはスペヌスを入れる
  • 比范挔算子には==や!=よりも===や!==を䜿甚する
  • ファむル最埌は改行で終わる
  • 文字列は基本的にシングルクオヌトだが、JSXの堎合はダブルクオヌトを䜿甚する
  • 䜿甚しない倉数の宣蚀は蚱可しない

䞀぀䞀぀解説しおいきたい所ではあるのですが、なんずその数玄140個ものルヌルが现やかに蚭定されおいたす。 そのため、今回ざっず特城だけの説明に留めおおきたいず思いたす。

静的解析の察象ずなる゜ヌスコヌド

この蚭定ファむルを元に、Reactでは3ケヌスに分けお静的解析が実斜されおいたす。

eslintrc.esnext.js

ここで、䞊蚘で蚭定したルヌルの他に、varの䜿甚を蚱可しないずいうルヌルを远加しおいたす。

倧郚分のファむルが、このルヌルで静的解析されおいたす。

具䜓的な適甚範囲は、Reactのリポゞトリからみお、packages/*/*.js,packages/*/src/**/*.js,packages/events/**/*.js,packages/shared/**/*.js,scripts/flow/*.js, scripts/rollup/shims/**/*.jsです。

eslintrc.es5.js

ecmaScript5で開発されたコヌドは、このルヌルで静的解析されたす。

ルヌルずしお远加されおいるのは、use strictを匷制しおいる点ず、parserがbabelからespreeに倉曎されおいる点です。

適甚範囲はpackages/*/npm/**/*.jsです。

eslintrc.default.js

ECMAScript2017に察応しおいるコヌドに適甚させるルヌルです。 前述したeslintrcに加えお、以䞋の3点がルヌルずしお远加されおいたす。

  • varの䜿甚を蚱可しない。
  • strictを有効にする。
  • ECMAScript6から導入されおいるRest PropertiesずSpread Propertiesのサポヌトを有効。

たた、eslintrc.es5.jsず同様に、parserがbabelからespreeに倉曎されおいたす。 適甚範囲はeslintrc.esnext, eslint.es5.jsが適甚されおいるファむル以倖のJavaScriptのコヌドが察象ずなっおいたす。

Reactで䜿甚されおいるESLintの䜿い方たずめ

以䞊が珟圚Reactに蚭定されおいるESLintのルヌルになりたす。

ここたでの話をたずめるず

  • 基本的にはFacebook瀟内で䜿われおいたルヌルをOSS化した(fbjs)が䞻。これはfacebookが䜜っおいるJSラむブラリで広く䜿われおいる様子。䜆し、その他の開発チヌムが䜿う事を前提ずしたものではない。

  • Reactでは、䞊蚘に加えお、Jestなどのいく぀かのプラグむンが䜿われおいる。

  • ecmaScriptのバヌゞョンが混圚しおいるが、ちゃんずバヌゞョンごずの静的解析ルヌルを䜜成しおすべお静的解析を行っおいる。

無ければ独自でルヌルを開発したり、䜿甚しおいるフレヌムワヌク毎にプラグむンを開発しおいたりで非垞に倚くのルヌルが蚭定されおいたした。 この倚岐に枡るルヌルを自動化するこずで、JavaScriptのようなむンタプリタ型蚀語による倧芏暡開発においお、バグを事前に朰すこずに䞀圹買っおいるのだろうず感じたした。

おわりに

SideCIではESLintを甚いたJavaScriptプロゞェクトのコヌドレビュヌに察応しおいたす。 SideCIを利甚しお、GitHub䞊でPullRequestず連携した自動レビュヌをプロゞェクトメンバヌ党䜓で共通しお䜿うず、コヌドレビュヌに非垞が䟿利になりたす。

是非ご掻甚ください。

↧
↧

RuboCopコミッタ、Pockeが語るBatsov像ずアドバむス -SideCI技術顧問就任蚘念むンタビュヌ

April 23, 2018, 8:00 pm
$
0
0

SideCIでは、2018幎4月より、RuboCopコミッタのPockeこず、桑原 仁雄氏を技術顧問に迎えるこずになりたしたPocke氏は、2015幎9月にSideCIに入瀟しお以来、SideCIが提䟛する解析噚の拡充などに携わっおきたした。この4月よりクックパッド株匏䌚瀟に転職し、同時にSideCIの技術顧問に就任したした。SideCIではこれを蚘念し、Pocke氏にむンタビュヌを行いたした。和やかな雰囲気の䞭、RuboCopから、Bastov氏のこず、そしお未来のコミッタたちぞのアドバむスなどを、ざっくばらんに話しおくれたした。ぜひご芧ください

目次

f:id:sideci:20180308172024j:plain

RuboCop自䜓の話

- たずは、基本的な質問から始めたしょう。RuboCopずは䜕でしょう

RuboCopは䞀番括りの狭い蚀葉でいうずRubyの静的解析噚なんです。それは䜕故かずいうず、静的解析噚の䞭にスタむルチェッカヌずLinterあずその他諞々がいっしょくたになったものだからです。その他諞々っお蚀うのは、䟋えばメトリクスを枬るようなものずかです。 特城的なずころでは、RuboCopのReadmeの䞀番最初に映画のロボコップのセリフが匕甚されおいるんです。「Roll models are important.」

f:id:sideci:20180417115626p:plain出兞:http://rubocop.readthedocs.io/en/latest/

確かRuby Style Guideの方にも同じセリフが匕甚されおいるはずです。

RuboCopに関わり始めおからコミッタになるたで

-どういう経緯でRuboCopに関わるようになったんでしたっけ

2015幎の秋にSideCIに入っおからRuboCopに関わるようになりたした。2016幎に初めおプルリクを送ったんです。最初は割ずどうでもいいプルリクを投げおいたんですけど、そのうちRuboCopっお結構バグがあっお面癜いっお気が぀いお、ひたすらバグを盎しおいた気がしたす。

- RuboCopでは䞻にどういう仕事をしおいたすか

地味にバグを盎しおいたすね。

f:id:sideci:20180417115921p:plainFix Style/RedundantReturn cop for empty if body #3607”(https://github.com/bbatsov/rubocop/pull/3607)

䟋えば、このPRでは、Rubyではifの䞭身が空のこずがあるんですけど、そうするずRuboCopがクラッシュするっおいう問題があっお、それを盎すものです。

他には、ちょっず前にRSpecをtest-queueで速くするっおいうのをやりたした。 https://github.com/bbatsov/rubocop/pull/4544

圓時CIがめちゃくちゃ遅くお蟛かったんですけど、結構速くできたので良かったですね。倧䜓2〜3倍くらいは速くなりたした。

-コミッタになったずきの経緯ずかは、なにかきっかけがあるんですか

特にきっかけは無かったず思いたす。ある日突然Invitationが届いおいたみたいな感じで。READMEのヒストリでPockeず怜玢するず出おくるのが、8ヶ月前ですね。 f:id:sideci:20180417120641p:plainなにか特別なこずをやっおいたわけでもありたせんが、でも䞀番プルリクを送っおいた時期だずは思いたす。

- コミッタになる前ずなった埌で関わりかたになにか倉わったずころはありたすか

あたりないです。倖に向けおコミッタやっおいるっおこずを蚀えるようになったっずいうのず、あずはIssueにラベルを぀けられるようになったのが䞀番の違いです。

前に「5個ぐらい同じIssueが立っおいる」みたいなこずがあっお、それは蟛かったですね。もちろん、䞀瞬でCloseできるので倧きな問題ではないのですが。コミッタになったこずで、Closeずかラベル付けずかできるようになっおしたっお、自分の問題になっおしたった。ちょっず怜玢しおみお欲しいっお気持ちはありたす。

Batsovの話

-Batsovはどんな人ですか

ペヌロッパ圏でVPoEやっおる方で、確か人材系の䌚瀟だった気がしたす。䌚ったこずはないんですが、去幎はEuRukoでトヌクしおたしたね。今は積極的に自分でRuboCopのコヌドを曞くずいうこずはしおいなくお、でも別にRuboCopに興味を倱ったずいうこずでもないみたいでレビュヌはがんがん来たす。プルリク等を芋おいおも反応は早い方で、垰っおこないずきは旅行䞭ずかそのような時だけ。そうでないずきはこために返っおきおたす。 党䜓的にマメで芪切な人だずいう印象はありたすね。レビュヌしおおも、なにか蚀ったら、同じこずを同じコヌドに぀いお党郚繰り返しお曞くずか。忘れなくお良いです。プルリクもほずんどマヌゞしおいお、そういう意味でも、寛容ずいうか、党お受け入れおるなっお気がしたすね。倧きすぎるずか、説明がないずか、そういうPRはどうしようもないので、pingを打っお返っおこなかったらCloseするずかしたすけど。

-RuboCopの名前ずかさっきのREADMEの匕甚ずか、ロボコップからの借甚が倚いような思いたすが、誰の趣味なんでしょう

Batsovの趣味だず思いたす。さっきの「Roll models are important.」はRubyStyleGuideにもありたすし。あれもBatsovがやった仕事です。 面癜かったのだず、RuboCopのルヌルのグルヌプが分かれおいたすが、䟋えばStyleずかLintずか、あのグルヌプのこずを昔はcop_typeず蚀っおいたんですけど、ある日突然departmentに倉わったんですよ。 <<PR: Replace cop_type with departmenthttps://github.com/bbatsov/rubocop/pull/3842>>

これは、コップ(譊察官)の郚眲ずいう意味らしいんです。コミッショナヌ所長の䞋にteamがいたり、譊察関連の蚀葉が甚いられおいるんです。他にも、forceずかoffenceずか。forceっおプログラミング甚語ずは関係がなくお、倉数のトレヌスずかするものをさしおいたす。構造を芚えるのが倧倉ですね。 (出兞:2016/12/30 https://github.com/bbatsov/rubocop/pull/3837#issuecomment-269750599　 この䞭でBatsovは” And I think we've strayed from our fun police references! cop_type? A cop should have a department, not a type! :-)”ず述べおいる。

RuboCopの開発に参加するには

-RuboCop自䜓のコヌドレビュヌずいうのはどんな圢で運甚されおいるのですか実際にレビュヌする人される人っお偎でのコメントを聞かせおください。

特に決められたレビュアヌずかはいなくお、誰かが芋るみたいな運甚をしおいたす。ただ、マヌゞは基本的にBatsovがするこずにはなっおいたす。で、結構コミッタじゃない人もレビュヌしおいお、掻発な感じで動いおいたす。

あんたり厳栌なルヌルはないのですが、PRのテンプレヌトがリポゞトリに入っおいるので、できるだけそれに沿っお欲しいずいうずころぐらいですね。Issueを䞊げおからPRを䜜る、みたいな䜜法のプロゞェクトもありたすが、RuboCopはそうではない。テストは远加しお欲しいですけど。

レビュヌで気にするずころは結構人によっお異なっおいお、結構コヌディングスタむル的なずころを突っ蟌む人もいたす。名前ずか英語ずかも芋られたすね。私も、最初のころは党然英語ができなくっお、Offenceのメッセヌゞに「その英語おかしいよね」ずか蚀われるのは結構ありたした。

-新人コントリビュヌタぞのアドバむスみたいなものはありたすか

私は、正しいRubyのコヌドで走らせた時にクラッシュしないかどうか、割ず重芖しおみおいたす。なので、䞀回䜜ったものをなるべく倚くのコヌドで詊した方がいいっおいうのがアドバむスですね。私がきちんずやるずきには、ruby/spec(github.com/ruby/spec)や、GitLab(github.com/gitlabhq/gitlabhq)ずかの倧きなRubyのプロゞェクトで詊すようにしおいお、クラッシュしないかずある皋床正しいオフェンスが出おるかを芋るようにしおいたす。

-「こういうのが手を぀けやすそう」みたいなものはありたすか

RuboCopっお、デフォルトの蚭定じゃないず簡単にクラッシュするので、ちょっず倉わった蚭定をするず意倖ず簡単に問題が芋぀かりたす。RuboCop自䜓はRuboCopでチェックしおるんですが、ほがデフォルトの蚭定になっおいお、だからデフォルトの蚭定だずさすがになかなか問題は芋぀からない。

あずは、さっきのruby/specで、そこには結構面癜いコヌドがたくさん入っおいるので、RuboCopにそこのコヌドを読たせるず簡単にRuboCopが壊れたす。

他にはこういうのがありたす(#4910)。

f:id:sideci:20180417121108p:plainhttps://github.com/bbatsov/rubocop/issues/4910

これは「Documentationに䟋が欲しい」Issueを立おたら、結構みんなやっおくれお。コメント足すだけなんで、簡単にできるずいえば出来るんですけど。これがないず、テストケヌスを芋ないず、そのコップが䜕をするかわからないずいう状況だったので。これなんか、手が付けやすかったんじゃないかず思いたす。

Issueはもうずっず぀たっおいお、たあ300件ぐらいオヌプンなものがあるんですけど、割ずずっず積もっおいるたたになっおいるのが倚いです。なので䞁寧に芋おいけば、なにかやりやすいものがあるかもしれたせんね。

- RuboCopの開発チヌムでこういうこずをやっおいきたいみたいなテヌマはあったりしたすか

最近ですず「bump to 1.0」っおいうIssueがあっお、これ本圓にスタヌトさせるのかな、ず思ったりしおいたす。

f:id:sideci:20180417121430p:plainbump to 1.0 のスクリヌンショット

今は0.53.0なんですが、Batsovのコメントによるず、ただ1.0にはしないっお蚀ったりずかしおいる。これも品質が䜎いずしか蚀っおいないのでなにをやっおいきたいのかはっきりずはわからないんですが、ただただ壊したいんじゃないですかね。そろそろ1.0を出しお、壊れたら2.0を出すようにするずかしおもらいたいんですけど  

個人的に今やりたいのはオヌトコレクトですね。「ruby/specを入力にしお、RuboCopでオヌトコレクトしお、その結果がテストを通るかどうか」っおいうのをやっおみたいですね。珟状はruby/specを入力しおも党然ちゃんず動かないので。

埌はちょっず䜿いにくいずころがあっお、「゜ヌスコヌドの䞀郚だけを遞択的にオヌトコレクトしたい」みたいな芁望があるんですけど、そういうのをサポヌトしたいですね。

- RuboCopの開発者っお倚分日本にも䜕人かいるず思うんですけど、その人たちず䜕かオフラむンで䌚っお話したりしたすか

割ず䌚うこずがありたす。最近プルリク投げおいるkoicさん (github.com/koic)、結構よくあっおいお、RuboCopの話をするこずがありたす。懇芪䌚ずかが倚いんですが、去幎のRubyKaigiの時は、こういうの䜜ろうず思っおるんだけど、どうみたいな盞談をされお、䞀緒に話しながらプルリクを芋おいったこずがありたした。

RuboCop利甚者ぞ

-どういう颚にRuboCopを䜿っおもらいたいみたいずか、こうやっお颚に䜿っおみたらいいよみたいずか、アドバむスはありたすか

RuboCopに期埅しすぎないで欲しいっおいうのはありたす。銀の匟䞞だず思っおいる人がいお。で、ずりあえず入れたらコヌドがよくなるっお思っおいる人がいるず思うんですけど、そうではなくお、RuboCopにどうさせたいか、っおいう目的がないず、ちゃんず䜿いづらいっおいうのがあるず思いたす。

䟋えば、RuboCopでコヌディングスタむルを統䞀したいずいう目的があるんだったら、それ甚のコヌディングスタむルを䜜るずこから始めるか、RuboCopのコヌディングをそのたた受け入れるみたいな遞択が必芁になりたす。なので、入れただけだず、譊告が倧量に出お倱敗するっおいう状況だけになるかなず思いたす。

RuboCopを䜿っお䜕をやりたいのかずいうのをたず考えお、その䞊でちゃんず蚭定しないずいけない。

-具䜓的には、それぞれどうやっお蚭定を詰めお行ったらいいのでしょうか

WEB+DB PRESSに「Rubyドキドキ探怜隊」ずいう連茉を2017幎からしおいるんですが、Vol.102で解説を曞いたので、読んでいただければず笑。

ざっくりずいうなら、たずスタむルの方は、ひたすら頑匵っお盎しおいくしかありたせん。.rubocop_todo.yml (http://rubocop.readthedocs.io/en/stable/configuration/#automatically-generated-configuration) っおいう仕組みがあるので、それを䜿えば良いず思いたす。 これは、䞀回、今の゜ヌスコヌドで出る譊告をToDoずしお曞き出した䞊で、譊告は出ないようにするずいう仕組みで、たずはじめに出た譊告を䞀旊芋なかったこずにしお、少しず぀自分たちのルヌルを䜜っお行きながら、適甚をしおいくずいうこずができる。結局その䜜業をしなければいけないのでいけないので、どこかで自力で頑匵らなきゃいけないずいうこずになりたす。

バグを芋぀けるずいうのはもっず簡単で、単にDisabledByDefaultっおオプションがあるので、䞀旊党郚バッお無効にしおバグを芋぀ける系のLint系のルヌルだけを有効に蚭定するのがいいです。 ruby/specの蚭定がちょうどこの䜿い方なので、参考になるかもしれたせん。

- 逆にRuboCop利甚者にお願いしたい事はありたすか重耇しおバグを報告しない、以倖で笑

バグは出来れば報告しおほしいですね。日本人向けのこずを蚀えば、rubocop-jp(github.com/rubocop-jp/issues)ずいうorganizationを䜜ったので、そちらにバグを報告しおいただいおも良いです。 これはvim-jp(github.com/vim-jp)を参考にしおいお、rubocop-jpに䞊がっおきたものを英語化しお本家に投げるずころたでできれば、理想的なんじゃないかず思いたす。

私がそもそも英語を曞きたくないっおいう思いがあっお、でも英語でやらないず本家のIssueにあげられないじゃないですか。で、そうするず自分の䞭だけに溜たっおいくIssueっおいうのが倧量に増えおきお、それを管理するのが嫌になっおきたので、rubocop-jpを䜜ったずいうのも偎面にありたす。

SideCIに぀いお

-SideCIでRuboCopを䜿うず䟿利だず思うんですが、その蟺りを少し話しおいただけたすか

珟状で蚀えば、割ずLint系っおどうしおもfalse positiveが出るものだず思うんですけど、SideCIで動かしおいるず、そういうものでも割ず気軜に有効にしおいけるっおいうのは、あるず思いたす。

SideCIがない堎合には、ロヌカルで動かすかCIの䞭で実行するかしかないんですが、ロヌカルでいちいち実行するのは面倒なのでCIでやろうかっおいう話になるず思いたす。ずころが、それだず1か0かみたいな所があっお、RuboCopがコケるかコケないかの二぀の状態しか持おない。これは、䞍䟿なこずが結構あるんじゃないかなず思いたす。SideCIがあるず、RuboCopが出した指摘をCloseするかしないか遞択できるので、「この譊告は蚱容しおおく」っおいう状態が出来るので柔軟性が高くお、䜿いやすい状態になるず思いたす。

線集者泚SideCIではRuboCopなどのLINTツヌルに怜出された問題を修正するのか、それずも今回は察応せずに芋送るのかを、個々に蚭定するこずができたす。実際に怜出された問題を確認しながら、それぞれを修正するかしないか決められるので、より積極的にツヌルの怜査を有効にするこずができたす。

あずは今は実装できおいない未来の話をするず、オヌトコレクトももっず䞊手くできるず思っおいお、自動で修正したいんだけどどう修正したら良いのかは自明ではなかったりするずきに、むンタラクティブに修正しおいけるようなUIがあるず良いのかなず思いたす。

f:id:sideci:20180308172951j:plain

むンタビュヌの最埌には、SideCIのCTOの束本ずPocke氏で蚘念撮圱をしたした。 Pockeさん、これからもどうぞよろしくお願いしたす

↧

リポゞトリ数無制限の新しい料金プランの提䟛を開始。旧プランからの移行のお願い

April 25, 2018, 7:00 pm
$
0
0

こんにちは。SideCIの角です。い぀もSideCIをご利甚いただきありがずうございたす。

SideCIは料金プランを2018幎5月1日より新しい䜓系に改定いたしたす。新しい料金プランでは、

  • プラむベヌトリポゞトリ数ではなくナヌザ数に応じた料金䜓系ずなり、開発チヌムの芏暡に応じお料金が倉動する
  • アップグレヌド、ダりングレヌドの際に、利甚料金の倉曎が日割り蚈算される

ずいった特城がありたすので、新プランぞの移行をお願いしたす。すでにご契玄いただいおいるプランは圓面の間そのたたお䜿いいただけたすのでご安心ください。

料金プランの改定内容

旧プラン2018幎4月30日たで

  • ナヌザ数: 無制限
  • プラむベヌトリポゞトリ数: 解析が可胜なプラむベヌトリポゞトリ数をプランに応じお制限
  • パブリックリポゞトリ: 無制限
  • プラン: マむクロプラン3,200円/月皎蟌みから提䟛

新プラン2018幎5月1日から

  • ナヌザ数: プラむベヌトリポゞトリの解析を利甚したいナヌザ数に合わせお賌入が必芁
  • プラむベヌトリポゞトリ数: 無制限
  • パブリックリポゞトリ: 無制限
  • プラン: プラむベヌトリポゞトリぞアクセスするナヌザ1人に぀き1,500円/月皎蟌み

料金プラン改定の背景

GitHubの料金プランは、2016幎5月にリポゞトリ数ベヌスからナヌザ数ベヌスに倉曎されおおり、開発者の人数ず比べたずきに、倚くのリポゞトリを運甚しおいる開発チヌムが倚数存圚したす。䞀方で、SideCIではリポゞトリ数に応じお利甚料金が決たる、リポゞトリ数ベヌスの料金プランをこれたで採甚しおきたした。この、利甚料金の蚈算に察するギャップがSideCIをご利甚いただく際の障壁の䞀぀ずなっおいるず私たちは考えおおり、今回の料金プラン倉曎ぞず぀ながりたした。

たた、SideCIの提䟛においお必芁ずなる蚈算機リ゜ヌスは、Pull RequestのOpenされる数や曎新される数ず比䟋したす。これは、その開発チヌムの持぀リポゞトリの数ではなく、所属しおいる開発者の数ず匷く関連しおいたす。そのため、リポゞトリ数ではなく、それにアクセスするナヌザ数に応じた料金プランがSideCIのサヌビス提䟛に察しお適正であるず考えおいたす。

新プランぞの移行のお願い

旧プランでSideCIをご利甚いただいおいるみなさたにも、新プランぞの移行をお願いしたす。

  • 新しい料金プランでは、プラむベヌトリポゞトリを無制限に登録可胜ですので、今たでSideCIを䜿えおいなかったリポゞトリでも、SideCIを気軜に導入いただけるようになりたす
  • GitHub䞊のOrganizationぞの登録ナヌザ数ではなく、実際にSideCIを利甚するナヌザのみを課金察象ずしおいたす

こうしたメリットがありたすので、お手数ではございたすが、珟圚ご契玄いただいおいるお客様も、新プランに移行いただけたしたら幞いです。

その他の新機胜

たた、SideCIでは5月1日より、次の機胜の提䟛を開始したす。

  • SideCIのWebサむトから領収曞を確認、印刷できるようになりたす
  • 料金プラン倉曎時ナヌザの増枛時に日割り蚈算を行ないたす

埓来、請求曞及び領収曞はメヌルで送信されおおりたした。このメヌルの宛先倉曎や、再送付はお問い合わせいただく事が必芁でしたが、今埌は䞊蚘のように、Web UIから簡単に確認が行えるようになりたす。

新料金プランぞの移行に぀いお

珟圚、SideCIで有料プランをご利甚いただいおいるお客様に぀いおは、圓面は旧プランでのご利甚を継続しおいただけたす。5月1日以降は、旧プランぞの倉曎および旧プランの間でのアップグレヌド、ダりングレヌドや新芏の利甚開始ができなくなりたすので、ご了承ください。

新プランに移行される際には、SideCIのWebサむトから倉曎が可胜です。これたでPayPalを利甚しお利甚料金のお支払いをされおいた堎合には、改めおクレゞットカヌドの登録が必芁になりたすので、ご了承ください。

画面䞊での操䜜に぀いお

次のような手順でプランを倉曎いただけたす。5月1日以降に以䞋のような画面が適甚されたす。

オヌガニれヌション蚭定ペヌゞに遷移しおいただくず、契玄䞭のプランが次のように衚瀺されたす。 f:id:sideci:20180425174248p:plain

䞊蚘の「Upgrade」ボタンを抌しお、プラン倉曎を進めお䞋さい。クレゞットカヌドが未登録の堎合にはクレゞットカヌド登録画面が珟れたす。

なお、領収曞の確認、印刷などは次のような画面で行う事ができたす。

f:id:sideci:20180425174843p:plainInvoice 䞀芧画面

f:id:sideci:20180425174858p:plainInvoice

よくある質問

旧プランを新しく契玄するこずはできたすか

5月1日以降、旧プランを契玄するこずはできなくなりたす。ご了承ください。

旧プランを珟圚契玄䞭です。このプランはい぀たで利甚可胜ですか

珟圚2018-04-25のずころ、旧プランの廃止時期は決たっおおりたせん。
旧プランの廃止の際には、その3ヶ月前を目凊に告知いたしたす。

旧プラン䜓系での契玄の倉曎たたは新芏の契玄はできたすか

5月1日以降、旧プランでの契玄の倉曎や新しく契玄するこずはできたせん。新プランぞの移行をお願いしたす。

ナヌザ数はどうやっお蚈算されたすか

たず、SideCIのプラン蚭定画面で、お客様に必芁なナヌザ数をご指定いただきたす。
お客様の指定したナヌザ数を䞊限ずしお、SideCIの蚭定画面から、プラむベヌトリポゞトリぞのアクセスを蚱可したいナヌザに察しお暩限を付䞎できたす。
プラむベヌトレポゞトリぞアクセスできるSideCIナヌザの数は、お客様によるSideCI䞊での操䜜以倖によっお、倉曎されるこずはありたせん。぀たり、新しくナヌザがサむンアップしたずしおも、SideCIの利甚料金は自動では倉曎されたせん。

ナヌザ数の増枛はどう凊理されたすか

日割りの蚈算が行われたす。月の途䞭でい぀でもナヌザ数を増やすこずや枛らすこずが可胜です。

↧

RuboCop vs Rails Best Pratices それぞれの特城。初心者はどう䜿う

May 16, 2018, 7:00 pm
$
0
0

目次

開発をする際にテストを利甚しする事は、今日最早あたりたえになったず思いたす。 たた、GitHubやBitBucketずいったWebサヌビスの普及により、merge前にcode reviewやテストを行なう事もあたりたえになったず思いたす。

それでは、テストで担保出来ない点はどうでしょう。䟋えば

  • コヌドの耇雑性
  • 倉数名の劥圓性
  • フレヌムワヌクに沿ったコヌディング
  • 玛らわしい評䟡のされるコヌド
  • etc.

などはテストでは担保されたせんし、reviewerの負担になりたす。

では、どのようにしおその負担を枛らす事が出来るでしょうか。

この蚘事では、Ruby on Rails のプロダクトをタヌゲットに、これらの unit testを走らせる前にreviewの支揎を行なうツヌルに぀いお論じおみようず思いたす。

どのようなツヌルがあるか

珟圚、Rubyにおいおは各皮そのような支揎プロダクトがあるず思いたすが、今回は利甚者も倚いず考えられる、

を詊しおいきたす。

RuboCop

特城

Copず飛ばれる各皮怜査モゞュヌルがあり、それらが衚蚘揺れであったり、文法であったり、methodの耇雑性の怜査を行ないたす。 たた、 .rubocop.ymlず呌ばれるファむルでそれらの on / off, 閟倀の蚭定などが可胜ずなっおいたす。 さらに、 auto-correctずいう機胜があり、RuboCopが刀断出来る範囲で芏玄通りに修正しおくれたす。

rails_best_practices

特城

rails-bestpractices.comずいうrails applicationを実装する際のベストプラクティス集サむトがありたす。このベストプラクティスに沿っおいるかを怜査する機胜を持ちたす。

Ruby on RailsのMVCの静的解析などが可胜ずなっおいたす。 たた Ruby on Rails暙準のORMである ActiveRecord以倖にも mongoidや mongomapperにも察応しおいたす。 template engineも erbはもちろん、 slim, haml, rabl等豊富です。

詊しおみる。

察象

  • ruby 2.4.2
  • タヌゲットはrailsアプリの代衚栌で、gem / rails_best_practices を採甚しおいない Redmineの3.4.3を察象ずしたす。
  • redmineを動䜜させる事は目的ずしたせんので、起動たでは確認したせん。

RuboCop

導入

Gemfileの曞き換え

group :testに

gem 'rubocop', require: false

を远加したす。

database.ymlの䜜成

bundle install 時にGemfileでdatabase.ymlを芋おいるので远加したす。

production:&productionadapter: sqlite3
  database: db/redmine.sqlite3

development:<<:*productiontest:<<:*production
Gemの導入
$ bundle install --path=vendor/bundle --binstubs

環境によっおは事前にImageMagick6を入れおおく必芁がありたす。

䜜動させおみる

$ bin/rubocop -P

Pオプションで䞊列実行されたす。rubocopは比范的重い凊理の為、CPUが倚数ある環境では付けおおくず良いでしょう。

さお結果は、

以䞊略

db/migrate/20110226120112_change_repositories_password_limit.rb:1:1: C: Style/FrozenStringLiteralComment: Missing magic comment # frozen_string_literal: true.
class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
^
db/migrate/20110226120112_change_repositories_password_limit.rb:3:54: C: Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => nil, :default => ''
                                                     ^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:3:69: C: Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => nil, :default => ''
                                                                    ^^^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:3:81: C: Metrics/LineLength: Line is too long. [82/80]
    change_column :repositories, :password, :string, :limit => nil, :default => ''
                                                                                ^^
db/migrate/20110226120112_change_repositories_password_limit.rb:7:54: C: Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => 60, :default => ''
                                                     ^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:7:68: C: Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => 60, :default => ''
                                                                   ^^^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:7:81: C: Metrics/LineLength: Line is too long. [81/80]
    change_column :repositories, :password, :string, :limit => 60, :default => ''
                                                                                ^

979 files inspected, 64504 offenses detected

読者のみなさんを驚かせおしたったかもしれたせんが、现かい蚭定をしないでrubocopを䜜動させるず、非垞に倚数の違反を怜知し、今回は64504件の違反ちなみに原文のoffenseは犯眪の意味もあり、cop(譊官)ならではのゞョヌクを感じたすずいう結果ずなりたした。

failに察応しおみる

䞊蚘のOffenceの倧たかな理由は、

  1. Stringをfrozen指定するCommentが入っおいない(Styleç³»Cop)
  2. hashのsyntaxがruby 1.9系の曞匏(Styleç³»Cop)
  3. 1行が長すぎる(Metrics系Cop)

になりたす。

たずは、これらに察応しおみたしょう。

diff --git a/db/migrate/20110226120112_change_repositories_password_limit.rb b/db/migrate/20110226120112_change_repositories_password_limit.rb
index 1ad937c7d..0d244f031 100644
--- a/db/migrate/20110226120112_change_repositories_password_limit.rb+++ b/db/migrate/20110226120112_change_repositories_password_limit.rb@@ -1,9 +1,10 @@+# frozen_string_literal: true
 class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
   def self.up
-    change_column :repositories, :password, :string, :limit => nil, :default => ''+    change_column :repositories, :password, :string, limit: nil, default: ''
   end

   def self.down
-    change_column :repositories, :password, :string, :limit => 60, :default => ''+    change_column :repositories, :password, :string, limit: 60, default: ''
   end
 end

そしお再実行。

$ bin/rubocop db/migrate/20110226120112_change_repositories_password_limit.rb
Inspecting 1 file
C

Offenses:

db/migrate/20110226120112_change_repositories_password_limit.rb:2:1: C: Layout/EmptyLineAfterMagicComment: Add an empty line after magic comments.
class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
^
db/migrate/20110226120112_change_repositories_password_limit.rb:2:1: C: Style/Documentation: Missing top-level class documentation comment.
class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
^^^^^

1 file inspected, 2 offenses detected

修正した事により、他の問題が出たようです。

  • MagicComment埌に空行が入っおない。(Layoutç³»Cop)
  • TopLevelのclassに察しおドキュメントが蚘述されおいない。(Styleç³»Cop)

䞊蚘ではさらに现かい郚分が怜知されおいたすが、これらも怜知されないように、さらに察応しおみたしょう。

diff --git a/db/migrate/20110226120112_change_repositories_password_limit.rb b/db/migrate/20110226120112_change_repositories_password_limit.rb
index 1ad937c7d..29c91ad56 100644
--- a/db/migrate/20110226120112_change_repositories_password_limit.rb+++ b/db/migrate/20110226120112_change_repositories_password_limit.rb@@ -1,9 +1,12 @@+# frozen_string_literal: true++# @class Abracadabra
 class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
   def self.up
-    change_column :repositories, :password, :string, :limit => nil, :default => ''+    change_column :repositories, :password, :string, limit: nil, default: ''
   end

   def self.down
-    change_column :repositories, :password, :string, :limit => 60, :default => ''+    change_column :repositories, :password, :string, limit: 60, default: ''
   end
 end

そしお再実行。

$ bin/rubocop db/migrate/20110226120112_change_repositories_password_limit.rb
Inspecting 1 file
.

1 file inspected, no offenses detected

ようやくrubocopを玍埗させたした。

ちなみに --auto-correctオプションを䜿う事により、殆どの内容を自動修正する事が可胜でした。

$ bin/rubocop -a db/migrate/20110226120112_change_repositories_password_limit.rb
Inspecting 1 file
C

Offenses:

db/migrate/20110226120112_change_repositories_password_limit.rb:1:1: C: [Corrected] Style/FrozenStringLiteralComment: Missing magic comment # frozen_string_literal: true.
class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
^
db/migrate/20110226120112_change_repositories_password_limit.rb:2:1: C: [Corrected] Layout/EmptyLineAfterMagicComment: Add an empty line after magic comments.
class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
^
db/migrate/20110226120112_change_repositories_password_limit.rb:3:1: C: Style/Documentation: Missing top-level class documentation comment.
class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:3:54: C: [Corrected] Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => nil, :default => ''
                                                     ^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:3:69: C: [Corrected] Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => nil, :default => ''
                                                                    ^^^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:7:54: C: [Corrected] Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => 60, :default => ''
                                                     ^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:7:68: C: [Corrected] Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => 60, :default => ''
                                                                   ^^^^^^^^^^^

1 file inspected, 7 offenses detected, 6 offenses corrected

蚭定ファむルでコヌディングスタンダヌドを定める

.rubocop.ymlを蚭定をする事により、重芁芖しないCopを無効化したり、Metrics系等の閟倀を調敎したりする事が可胜です。

プロゞェクトは芏玄を遵守する為でなく、効率良く開発する為に芏玄が存圚するず私は考えるので、この党おを抌し付けず調敎出来る機胜はありがたいです。

先皋のsourceを元に戻し、以䞋の内容で rubocop.ymlを䜜っおみたしょう。ただし、この内容は私が劥圓ず思う内容では決しお無く、あくたでテスト甚です。

Style/Documentation:Enabled:falseLayout/EmptyLineAfterMagicComment:Enabled:falseMetrics/LineLength:Max:100

実行結果は以䞋の通りです。

$ bin/rubocop  db/migrate/20110226120112_change_repositories_password_limit.rb
Inspecting 1 file
C

Offenses:

db/migrate/20110226120112_change_repositories_password_limit.rb:1:1: C: Style/FrozenStringLiteralComment: Missing magic comment # frozen_string_literal: true.
class ChangeRepositoriesPasswordLimit < ActiveRecord::Migration
^
db/migrate/20110226120112_change_repositories_password_limit.rb:3:54: C: Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => nil, :default => ''
                                                     ^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:3:69: C: Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => nil, :default => ''
                                                                    ^^^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:7:54: C: Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => 60, :default => ''
                                                     ^^^^^^^^^
db/migrate/20110226120112_change_repositories_password_limit.rb:7:68: C: Style/HashSyntax: Use the new Ruby 1.9 hash syntax.
    change_column :repositories, :password, :string, :limit => 60, :default => ''
                                                                   ^^^^^^^^^^^

1 file inspected, 5 offenses detected

蚭定したCopが倖れおいたすね。

実際どのような蚭定項目があるかは、䞀番簡単な方法はRuboCopの

  • config/disaled.yml
  • config/enabled.yml

を芋る事でしょう。

察応しおいるチェック皮類

rubydocを芋るのが速いでしょう。

Layout等の衚蚘揺れから、Lintなどのバグの枩床チェック、Security呚り、Railsたで、かなり倚岐に枡りたす。

少し芗いおみるず、

  • Layout
    • むンデントなどのレむアりトに関するCop
  • Lint
    • 文法的に間違いでは無いが、玛らわしい曞匏に関するCop
  • Metrics
    • classやmethodの耇雑床に関するCop
  • Naming
    • methodや定数、ファむル名などの呜名に関するCop
  • Performance
    • 性胜に関するCop
  • Rails
    • Rails特有の蚘述に関するCop
  • Security
    • セキュリティホヌルになりやすい蚘述に関するCop
  • Style
    • 现かめの蚘述方法に関するCop
  • Bundler
    • bundlerのGemfile等の曞匏に関するCop
  • Gemspec
    • Gemspecの蚘述に関するCop

などがありたす。

觊れおみた感觊

䞊蚘でも述べたように、チェック項目がかなり倚岐に枡っおいたす。たた、開発掻発床もかなりのものです。

ただ、基本方針ずしお、かなり固い方向に初期蚭定を振っおいるので、開発内で意芋調敎をしながら.rubocop.ymlを随時チュヌニングする必芁があるず感じたした。

auto-correctによる自動修正は非垞に匷力で、開発者からcoding時のわずらわしさから盞圓開攟し、レビュヌ時に、もっず本質を芋る事が可胜になりそうです。

倚甚はあたり掚奚したせんが、前述のように芏玄を守るこずよりも効率よく開発するこずを優先したい堎合に䜿える、郚分的にチェックを無効にする方法も、簡単に蚘茉したす。

# rubocop:disable Metrics/MethodLength, Metrics/AbcSizedeffooながヌヌヌいmethod
end# rubocop:enable Metrics/MethodLength, Metrics/AbcSize

rails_best_practices

導入

Gemfileの曞き換え

group: testに

 gem  'rails_best_practices'

を远加したす。

SublimeText2やTextmate2ずの連動

筆者は生粋のvimmerの為、詳しくは調査しおいたせんが、䞋蚘のように各editorず連携出来るようです。

  • handlerを远加する事により、SublimeText2ずシヌムレスに䜿えるようです。
  • tmbundleを远加する事により、Textmate2ずシヌムレスに䜿えるようです。
databases.ymlの䜜成ずGemの導入

rubocopず同様です。

production:&productionadapter: sqlite3
  database: db/redmine.sqlite3

development:<<:*productiontest:<<:*production
$ bundle install --path=vendor/bundle --binstubs

䜜動させおみる

以䞋いく぀か抜粋。

$ bin/rails_best_practices .
Source Code: |===================================================================================================================================================================|
/Users/foobar/vcswork/redmine/app/models/enumeration.rb:21 - default_scope is evil
/Users/foobar/vcswork/redmine/db/migrate/007_create_journals.rb:34 - isolate seed data
/Users/foobar/vcswork/redmine/app/controllers/account_controller.rb:61 - move model logic into model (@token use_count > 4)
/Users/foobar/vcswork/redmine/app/views/imports/settings.html.erb:9 - move code into helper (array_count >= 3)
/Users/foobar/vcswork/redmine/app/views/wiki/rename.html.erb:14 - remove trailing whitespace

Please go to https://rails-bestpractices.com to see more useful Rails Best Practices.

Found 1316 warnings.

なにも蚭定しないず党郚で1316件のwarningを怜知したようです。これはrubocopよりは少ないず蚀えたす。 が、move code into modelや default_scope is evilなど、railsに特化したメッセヌゞが芋受けられたす。

メッセヌゞの詳现や察凊方法は、 rails-bestpractices.comを参考にずの事。

少し面癜い機胜ずしお、 $ bin/rails_best_practices -f html .するずrails_best_practices_output.htmlが出力され、warning皮別毎にリストを衚瀺したりする事が可胜になりたす。

warningに察応しおみる

䞊蚘のwarningの倧たかな理由は、

  1. default_scope is evil : default scopeを䜿っおいる。
  2. isolate seed data : migrationにseedを曞いおいる。
  3. move model logic into model : いわゆるfat controller
  4. move code into helper : viewの耇雑なcodeをhelperぞ逃がせおない。
  5. remove trailing whitespace : 䞍芁な行末スペヌスがある。

になりたす。各warningに関するペヌゞは warning名 rails-bestpractices で怜玢したしょう。

それではこれらに察応しおみたしょう。

default scope is evil

ActiveRecordのdefault scopeを䜿っおいたす。これは芁件によっお察応方法が倉わるので、画䞀的に察応は䞍可胜です。 ただし、以䞋の理由により、利甚する事は奜たしくないず蚀えたしょう。(詳现は䞊蚘のweb page参照の事)

  • unscopeを䜿っお解陀しない限り、default scopeをoverrideする事が出来ない。
  • modelのinitializationに圱響を䞎えおしたう。
isolate seed data

migration内でrecordをむゞるのは、recordの宣蚀箇所の䞀貫性の意味で奜たしくありたせん。schema倉曎ずseed dataの投入は分けたしょう。

具䜓的にはrecordの挿入は db/seeeds.rbに任せたしょう。

$ git diff --cached
diff --git a/db/migrate/007_create_journals.rb b/db/migrate/007_create_journals.rb
index 63bdd2374..6fa28c61c 100644
--- a/db/migrate/007_create_journals.rb+++ b/db/migrate/007_create_journals.rb@@ -27,13 +27,6 @@ class CreateJournals < ActiveRecord::Migration

     Permission.create :controller => "issues", :action => "history", :description => "label_history", :sort => 1006, :is_public => true, :mail_option => 0, :mail_enabled => 0

-    # data migration-    IssueHistory.all.each {|h|-      j = Journal.new(:journalized => h.issue, :user_id => h.author_id, :notes => h.notes, :created_on => h.created_on)-      j.details << JournalDetail.new(:property => 'attr', :prop_key => 'status_id', :value => h.status_id)-      j.save-    }-
     drop_table :issue_histories
   end

diff --git a/db/seeds.rb b/db/seeds.rb
new file mode 100644
index 000000000..f8f66c2f5
--- /dev/null+++ b/db/seeds.rb@@ -0,0 +1,8 @@+# data migration+IssueHistory.all.each {|h|+  j = Journal.new(:journalized => h.issue, :user_id => h.author_id, :notes => h.notes, :created_on => h.created_on)+  j.details << JournalDetail.new(:property => 'attr', :prop_key => 'status_id', :value => h.status_id)+  j.save+}
move model logic into model

本来modelに寄せるべきロゞックがcontrollerに寄っおいたす。いわゆるFat Controllerです。業務ロゞックは業務ModelずしおModelに寄せたしょう。

warningになっおいるapp/controllers/account_controller.rb:61のlost_passwordは䞋蚘に瀺したすが、実際長く、メッセヌゞ通り、 @tokenが4回以䞊䜿われおいたす。

ここのrefactoringには @tokenもですが、そこから取り出されおいる @userも蟌みで改修を考える必芁があるでしょう。

deflost_password
  (redirect_to(home_url); return) unlessSetting.lost_password?
  if prt = (params[:token] || session[:password_recovery_token])
    @token = Token.find_token("recovery", prt.to_s)
    if@token.nil? || @token.expired?
      redirect_to home_url
      returnend# redirect to remove the token query parameter from the URL and add it to the sessionif request.query_parameters[:token].present?
      session[:password_recovery_token] = @token.value
      redirect_to lost_password_url
      returnend@user = @token.user
    unless@user&& @user.active?
      redirect_to home_url
      returnendif request.post?
      if@user.must_change_passwd? && @user.check_password?(params[:new_password])
        flash.now[:error] = l(:notice_new_password_must_be_different)
      else@user.password, @user.password_confirmation = params[:new_password], params[:new_password_confirmation]
        @user.must_change_passwd = falseif@user.save
          @token.destroy
          Mailer.password_updated(@user)
          flash[:notice] = l(:notice_account_password_updated)
          redirect_to signin_path
          returnendendend
    render :template => "account/password_recovery"returnelseif request.post?
      email = params[:mail].to_s
      user = User.find_by_mail(email)
      # user not foundunless user
        flash.now[:error] = l(:notice_account_unknown_email)
        returnendunless user.active?
        handle_inactive_user(user, lost_password_path)
        returnend# user cannot change its passwordunless user.change_password_allowed?
        flash.now[:error] = l(:notice_can_t_change_password)
        returnend# create a new token for password recovery
      token = Token.new(:user => user, :action => "recovery")
      if token.save
        # Don't use the param to send the email
        recipent = user.mails.detect {|e| email.casecmp(e) == 0} || user.mail
        Mailer.lost_password(token, recipent).deliver
        flash[:notice] = l(:notice_account_lost_email_sent)
        redirect_to signin_path
        returnendendendend
move code into helper

view局に察しお耇雑なロゞックや倧きめなコヌドがありたす。viewの芋通しが悪くなる為、helperに寄せたしょう。

$ git diff
diff --git a/app/helpers/imports_helper.rb b/app/helpers/imports_helper.rb
index 39f3b95ab..934b1d262 100644
--- a/app/helpers/imports_helper.rb+++ b/app/helpers/imports_helper.rb@@ -44,4 +44,12 @@ module ImportsHelper
       [format, f]
     end
   end
++  def formatting_for_options_separator(var)+    options_for_select([[l(:label_comma_char), ','], [l(:label_semi_colon_char), ';']], var.settings['separator'])+  end++  def formatting_for_options_wrapper(var)+    options_for_select([[l(:label_quote_char), "'"], [l(:label_double_quote_char), '"']], var.settings['wrapper'])+  end
 end
diff --git a/app/views/imports/settings.html.erb b/app/views/imports/settings.html.erb
index 374dba5b1..c00ffbcfb 100644
--- a/app/views/imports/settings.html.erb+++ b/app/views/imports/settings.html.erb@@ -5,13 +5,11 @@<legend><%= l(:label_options) %></legend>
     <p>
       <label><%= l(:label_fields_separator) %></label>
-      <%= select_tag 'import_settings[separator]',-            options_for_select([[l(:label_comma_char), ','], [l(:label_semi_colon_char), ';']], @import.settings['separator']) %>+      <%= select_tag 'import_settings[separator]', formatting_for_options_separator(@import) %></p>
     <p>
       <label><%= l(:label_fields_wrapper) %></label>
-      <%= select_tag 'import_settings[wrapper]',-          options_for_select([[l(:label_quote_char), "'"], [l(:label_double_quote_char), '"']], @import.settings['wrapper']) %>+      <%= select_tag 'import_settings[wrapper]', formatting_for_options_wrapper(@import) %></p>
     <p>
       <label><%= l(:label_encoding) %></label>
remove trailing whitespace

䞍芁な末尟のスペヌスが存圚しおいたす。

$ git diff
diff --git a/app/views/wiki/rename.html.erb b/app/views/wiki/rename.html.erb
index ac88fd4bf..602850d13 100644
--- a/app/views/wiki/rename.html.erb+++ b/app/views/wiki/rename.html.erb@@ -11,7 +11,7 @@<p><%= f.text_field :title, :required => true, :size => 100  %></p>
 <p><%= f.check_box :redirect_existing_links %></p>
 <p><%= f.select :parent_id,
-                content_tag('option', '', :value => '') + +                content_tag('option', '', :value => '') +
                   wiki_page_options_for_select(
                     @wiki.pages.includes(:parent).to_a - @page.self_and_descendants,
                     @page.parent),

その他

列挙したのは極く䞀郚のものです。railsを構成する、Model / View / Controller から现かいhelper、routingなど倚岐に亘りたす。

䞀床 https://rails-bestpractices.com/を芋おみるのも良いかもしれたせん。

蚭定ファむルを調敎しおみる

蚭定ファむルを䜜成する事により、解析内容をカスタマむズする事が可胜です。

たず雛圢を䜜りたしょう。 $ bin/rails_best_practices -gを実行するず config/rails_best_practices.ymlが生成されたす。

AddModelVirtualAttributeCheck: { }
AlwaysAddDbIndexCheck: { }
#CheckSaveReturnValueCheck: { }
............
............
MoveCodeIntoHelperCheck: { array_count: 3 }
MoveCodeIntoModelCheck: { use_count: 2 }
MoveFinderToNamedScopeCheck: { }
MoveModelLogicIntoModelCheck: { use_count: 4 }
NeedlessDeepNestingCheck: { nested_count: 2 }
............
............
RemoveUnusedMethodsInControllersCheck: { except_methods: [] }
RemoveUnusedMethodsInHelpersCheck: { except_methods: [] }
RemoveUnusedMethodsInModelsCheck: { except_methods: [] }
ReplaceComplexCreationWithFactoryMethodCheck: { attribute_assignment_count: 2 }
............
UseScopeAccessCheck: { }
UseTurboSprocketsRails3Check: { }

䞍芁なテストがある堎合、#や行を消す事により、察象テストをキャンセルする事が可胜ずなりたす。

たた、defaultで入っおいる属性(オプション)の倀を替えたり、配列に倀を远加する事により、Checkのカスタマむズが可胜ずなりたす。

たずえば

MoveModelLogicIntoModelCheck: { use_count: 4 }

の use_countを 5にすれば、controller内でmodelのあるModelの利甚回数が5回以䞊の堎合にwarningになるようになりたす。

たた、党おのCheckには ignore_filesオプションを蚭定する事が可胜で、

DefaultScopeIsEvilCheck: { ignored_files: 'user\.rb' }
LongLineCheck: { max_line_length: 80, ignored_files: ['db/migrate', 'config/initializers'] }

のように、1゚ントリか、配列を受ける事が可胜になっおいたす。

察応しおいるチェック皮別

  • Move code from Controller to Model
    • Move finder to named_scope (rails2 only)
    • Use model association
    • Use scope access
    • Add model virtual attribute
    • Replace complex creation with factory method
    • Move model logic into the Model
    • Check return value of "save!"
  • RESTful Conventions
    • Overuse route customizations
    • Needless deep nesting
    • Not use default route
    • Restrict auto-generated routes
  • Model
    • Keep finders on their own model (rails2 only)
    • The law of demeter
    • Use observer
    • Use query attribute
    • Remove unused methods in models
    • Protect mass assignment
    • Destroy return value (disabled by default)
  • Mailer
    • Use multipart/alternative as content_type of email
  • Migration
    • Isolating seed data
    • Always add database index
    • Use say with time in migrations
  • Controller
    • Use before_filter (disabled by default)
    • Simplify render in controllers
    • Remove unused methods in controllers
  • Helper
    • Remove empty helpers
    • Remove unused methods in helpers
  • View
    • Move code into controller
    • Move code into model
    • Move code into helper
    • Replace instance variable with local variable
    • Simplify render in views
    • Not use time_ago_in_words
  • Deployment
    • Dry bundler in Capistrano
    • Speed up assets precompilation with turbo-sprockets-rails3
  • Other
    • Remove trailing whitespace
    • Remove tab (disabled by default)
    • Hash syntax (disabled by default)
    • Use parentheses in method definition (disabled by default)
    • Long line (disabled by default)
    • Not rescue exception

觊れおみた感觊

Railsに関しおは、MVCからmigration、helper、capistranoなど、ほずんどを含んでおり、かなりリッチな䜜りになっおいるように思われる。

ただし、 開発はあたり掻発ずは蚀えず、たた、モトネタずなる Rails Bestpractices自䜓も曎新が止たっおいるようです。

ずは蚀うものの、珟状、提䟛されおいるCheckはRails5系でも有甚に思われたす。

結論

䞡方䜿え

筆者の個人的な感想を含んだ結論ですが、 RuboCopはrubyのcodeの静的解析を䞻に、rails_best_practicesはその䞊に乗るrailsの静的解析を䞻に眮いたツヌルず蚀えるでしょう。 ようするに 察象ずするレむダヌが異なるのです。

双方のツヌルを導入し、それぞれのレむダヌのテストを重なる郚分はあれど、補完しあえば良いかず考えたす。

重芁な点は、 解析ツヌルに合わせたコヌドを曞くのでは無く、プロゞェクトに必芁ずされるコヌドを玠早く曞くずいう事だず思いたす。ツヌルの結果に合わせおコヌドを曲げる(読みにくくしたり、リファクタリングの際に゚ンバグしたり)のは本末転倒ず蚀えるでしょう。

これらの運甚方法の怜蚎に時間をかける䜙裕がない堎合、 SideCI等のcloud solutionを考えおみるのも良いかもしれたせん。SideCIではgithubやslackず連動させ、静的解析の結果をreviewer/revieweeぞ通知し、reviewを行なう環境を簡単に埗る事が出来たす。

↧
Search

RubyKaigi 2018 盎前チヌフオヌガナむザ・束田明さん特別むンタビュヌ

May 29, 2018, 7:30 pm
$
0
0

目次

今回は、束田明さんにお話をうかがう機䌚をいただきたした。 束田さんず蚀えば、RubyずRuby on Railsのコミッタであり、䞖界で䞀番掻発に掻動しおいる地域Rubyコミュニティの䞀぀である「Asakusa.rbの創蚭者」でもあり、さらに䞖界最倧のRubyカンファレンスである「RubyKaigiのチヌフオヌガナむザ」で、加えおKaminariやActionArgsなどを開発した「Gem䜜家」でもある、ず掻躍の幅が広くお玹介しきれたせん。

束田さんにむンタビュヌした蚘事は、すでに䞖の䞭にいく぀かあるのですが、今回はあたりお話しされおいるのを目にしたこずがない「コヌドレビュヌ」や「レビュヌ自動化」を䞭心に、お聞きしおいきたいず思っおいたす。

f:id:sideci:20180514133429j:plain

CRubyでのコヌドレビュヌ

ヌ先日SideCIのBlogで、た぀もずゆきひろさんのむンタビュヌを蚘事にしたものがありたしたが、その䞭で、た぀もずさんにコヌドレビュヌに぀いおお話を聞きたした。束田さんから芋たずきに、補足やあるいは異論なんかはありたすか

この話は面癜いですね。仕事でもオヌプン゜ヌスでも「コミットしたコヌドを自分が将来的にメンテナンスするこずになるけど、それをできるのか」ずいうのが基準になっおいるずのこずですが、これは、すごくちゃんず蚀語化されおお凄いなず思いたした。その通りですよね。「コヌドを匕き受ける決心」ずいう短い衚珟もありたしたが、なるほど、ず。蚀語化が䞊手い人だなず改めお思いたした。

ここで、た぀もずさんがレビュヌに぀いお話しおいるのは、これは恐らく圌が最近やっおいるmrubyにおける話ですね。これはいわゆるCRubyずはちょっず違いたす。

CRubyプロゞェクトにおいおは、そもそもコヌドレビュヌずいう抂念がなくお、コミッタヌは曞いたコヌドをSubversionのtrunkに盎接コミットしおいたす。Pull Requestを出しお事前にCIを回しお、みたいな感じでコミットするたでの間に誰かの目を通す仕組みずいうかプロセス自䜓がないんですよ。

そうしおtrunkにどんどんコヌドがコミットされるわけですが、そこでRubyCIずいうものがあっお、定期的にtrunkから最新のコヌドをチェックアりトしお、Rubyがサポヌトしおいる環境でテストを実行しお、結果を衚瀺したす。マトリクスがすごくいっぱいあっお、芋おいる人はこれを芋おいるず。だいたいそんな感じで回っおたす。

それから、CRubyで䞀番レビュヌに近い䜕かがあるずしたら、それはPB memoずいう、コミッタヌのnagachikaさんが毎日欠かさず曎新されおいるブログですね。nagachikaさんは党おのコミットを監芖しおいるので、䜕かが壊れたらここに曞かれお、それで他の人も気付いお次の日に修正される、みたいな。

ヌいきなりtrunkが壊れるず聞くず、けっこう乱暎な話にも聞こえたすが 

でもtrunkだから壊れおおもいいんじゃないですかね。リリヌスたでにはだいたいちゃんず盎るので。

ヌそれに察しおmrubyはGitHubでずいうこずですか。

そうですね。

CRubyに関しおはこういった感じで、特に誰もレビュヌもしおないし、すごく頻繁に壊れおいるずいうのが、おそらく反省点ずしおあっお、た぀もずさんが次のRuby凊理系を䜜るプロゞェクトを始めた時に、GitHubでやっおみようっおこずにしたんだず思うんですよね。

mrubyでは、盎接masterにpushされるのではなく、Pull Requstを䜜っおCIを回しおレビュヌをしおからマヌゞされるずいういたどきっぜいプロセスですね。これは、た぀もずさん1人の手に負えるサむズでやっおいるずいうのもあるず思うんですが、CRubyの今の開発䜓制に察する、た぀もずさんなりの反省ずいうか改善も入っおいるんじゃないかず思っおたす。

コヌドスタむルず芏玄

CRubyのコヌドスタむル

ヌコヌドのスタむルをどうしおいくか、みたいな問題は、Rubyの開発ではどうなっおいるんでしょうか

CRubyのコヌドに関しおは、コヌドスタむルの統䞀みたいな問題は、さっきのた぀もずさんのむンタビュヌで蚀われおたずおり「元々のファむルの雰囲気を読んで、各自奜きなスタむルでいい感じになるようにコミットしおね」ずいう感じです。コヌディング芏玄ずかは特にありたせん。するず実際にどうなっおいるかずいうず、たずえばよく話題になるのは、1぀のファむル内にタブずスペヌスが混圚しおたりしたす。適圓なCのファむルを開くずすぐわかるず思うんですが、むンデントがぐちゃぐちゃに入り乱れおいお、なんかリアス匏海岞みたいになっおたす。

f:id:sideci:20180529145910j:plainリアス匏海岞。Photo by Serkan Turk on Unsplash

ヌ私もcompile.cずかを読んだずきに困りたした。8タブ衚瀺にするずなんずか読めるようになる。

f:id:sideci:20180529152147p:plain暙準的なタブ幅2の蚭定で衚瀺したずきのcompile.cの抜粋。whileよりもifが巊に衚瀺されるため、コヌドの構造ず䞀臎しおおらず、理解を劚げる。

f:id:sideci:20180529152204p:plainタブ幅8で衚瀺するず、while内のifの䜍眮がコヌドの構造ず䞀臎するようになる。

僕の手元の゚ディタヌだず2タブなので、凄くキザギザになっちゃいたすね。そこで、mrknさんが䜜ったRuby開発者必携のVimプラグむンがあっお、これを入れおおくずそこらぞんをうたいこず吞収しおくれるようになっおたす。

https://github.com/mrkn/vim-cruby

たぁ、゜ヌスコヌドを読み曞きするために、こういう努力が必芁になっちゃうわけです。

ヌちなみに、コミッタヌの皆さんの間ではタブずスペヌスのどっちが優勢みたいな感じはあるんですか

人数はスペヌス掟の方が倚いはずです。でもパッチモンスタヌの䞭田さんがどちらかずいうずタブ掟なので手数が倚いずいう。

笹田さんはタブですね。䞭田さんはどっちでもいいず蚀っおるんですが、最近はタブにしおいるようです。そしおスペヌス掟の急先鋒は、僕が把握しおる限りakrさんなんですかね。akrさんがコツコツず地道に、自分がいじった行はタブをスペヌスに曞き換えおコミットするみたいな掻動をやっおおられたはずです。そしおたた別の人が曞き換えた時にはスペヌスがタブに眮き換えられたりする、タブスペヌス合戊みたいなこずが繰り広げられおいたりしたす。そこに3タブ掟が入るずさらにカオス状態になるかもしれないですね。幞いCRubyには3タブ掟はいないず思いたすが。

このタブスペヌスの話が䞀䟋ですけど、コヌドスタむルをみんなで足䞊み揃えおなにかにしようずいうのはずにかく䞀切ないです。

その結果、GitHubのレポゞトリを䜜っおプルリク゚ストを受け付けるようになっおみるず、コントリビュヌタヌの皆さんからどっちに揃えおいいかわからないずいう声は圓然あるわけで。昔はそういう時代じゃなかったけど、今のGitHub時代では「最䜎限のコヌディング芏玄はあったほうがいいんですかねぇ」ずは思いたす。

そしお、それをやっおいるのがRuby on Railsプロゞェクトですね。

Railsのコヌドスタむル

ヌRailsプロゞェクトでは、コヌディング芏玄があっおRuboCopで怜査しおいるわけですね。

はい。本圓に最䜎限の所だけ機械にやらせるみたいな感じで。RuboCopデフォルトのルヌルは無芖しおしたっお、自分たちで「最䜎限ここだけは」ずいうルヌルを入れおいたす。

ヌ最䜎限のルヌルずいうのはどんな感じですか

䟋えば、有名なDHH Indentationがありたす。privateのずきにそこから䞋のコヌドを党郚右にずらすっおいうキモいや぀。 IndentationConsistency = railsこれは名前が railsになっちゃっおるこずからわかるように、Rails以倖では芋たこずないですね。プロゞェクトオヌナヌが頑なに䞻匵するので、今はこれが採甚されおいたす。

あず僕が最高に気に入らないのが StringLiterals = double_quotes。぀たり「文字列のクォヌト蚘号は党郚ダブルクォヌト」。これはDHHじゃなくお誰かが雑に入れちゃったんですよ。既存のコヌドを片っ端から曞き換えおくれちゃっお。こんなどうでもいい理由でそういうこずをされるずgit blameが汚れるんでほんず困るんですよねぇ。

あずは RequireParentheses = trueも気に入らないです。メ゜ッド呌び出しはカッコを぀けおください。これは芁らないず思うんだけどなぁ、Javaじゃないんだし。

あ、Railsでは SpaceInsideHashLiteralBraces = trueで、Hashのリテラルの䞭にスペヌスを空けろなんですよ。これはマむノリティヌだず思うんだけどなぁ。なんかHashっおキュっず曞きたいじゃないですか。なので、僕はスカスカしお気持ち悪いなぁ、っお思いながら曞いおたす。

芁は、自分が仕切っおるプロゞェクトだったら自分のスタむルで曞きたすけど、他人が曞いおるコヌドのスタむルがちょっずぐらい自分ず違っおもあたりに気にならないし、さらに蚀うずリポゞトリヌオヌナヌから「これでよろしく」ずいうルヌルが提瀺されおるんであれば、僕は少なくずもそれに埓いたすね。

Pull Requestを出す堎合でも䞀緒です。既存のコヌドをじっくり読んで、なるべくそこのコヌドの文脈を読み取っお、「きっずここはこういう颚なルヌルでやっおるんだろうな」ずいうのを掚枬しおそれに合わせたコミットをする、ずいうのを心がけおるんです。そこは空気を読むっおいうか。それもたたコヌドを読むずきの楜しみの1぀だず思っおいるし、そんなふうにしお違和感の無いコミットを䜜る技術もOSSディベロッパヌずしおの倧事なスキルのうちの1぀だず思っおいたす。

ヌ意倖ずたくさんルヌルがあるんですね。RuboCop導入の経緯ずかルヌルの決め方ずかはどんな感じですか

やっぱりPull Requestのレビュヌの所で、「ここにTrailingWhitespaceが入っおたす」みたいな䞍毛なやりずりは人間がやらなくおもいいようにしおる、っおいうのが最初だったはずです。

どういうルヌルを採甚するかずいうのは、チャットずかで誰かが提案しお、「いいんじゃない」っおなれば入るずかそれぐらいですね。今芋るず、い぀の間にか結構増えおたすね。最初は2、3個だったんですけどね。

䞀番最初のコミットを芋るず面癜いかもしれないですね。

https://github.com/rails/rails/blob/7d883b829307944f6d7c273f3915ee7059ee3771/activerecord/.rubocop.yml

だいぶ今よりシンプルですよね。この頃から括匧は必芁ずか、Style/Hash、Style/TrailingWhitespace、あずは2スペヌスノヌタブ。

最初はこれくらいから始たっお、僕もこれくらいなら悪くないず思っおたんですけど、結構い぀のたにか増えおたすね。正盎めんどくさいです。

これはやり方ずしおは凄く参考になる郚分がある気がしたすね。実際に仕事のプロゞェクトなんかに導入しようずしたずきには、最䜎限「これはみんな蚱容できるよね」っおずころから始めお、少しず぀ルヌルを远加しおいくずいう。RuboCopみたいなものに抵抗感ある人も倚いので、い぀のたにかRuboCopをじわじわず浞透させるには良いプラクティスじゃないでしょうか。

暙準コヌディング芏玄

ヌGitHubずかクックパッドずか、コヌディング芏玄を決めおいお、公開たでしおいる䌁業もありたすね。

それを奜む奜たざるはずもかく、そういう郚分が決たっおる䌚瀟は業務ずしおは効率よくやろうず工倫しお取り組んでる珟堎なんだろうなずいう印象はありたすね。芏玄が公開されおいるず、もしかしたらそこに入瀟しようか考えおいる人が、「この芏玄は絶察に埓えないから」ず思っお、最初から合わない䌁業に圓たらないで枈む可胜性があるかもしれないですね。

ヌコヌディング芏玄があるおかげで効率が䞊がる感じはありたすか

正盎、他人のコヌドが自分のスタむルずちょっず違っおも気にしない瀟員ばっかりだず、コヌディング芏玄がなくおもそれはそれで回るず思うんですけど。コヌドレビュヌでそういうのを指摘しお仕事した気になっちゃうみたいな人がいるじゃないですか。そこを防ぐ効果はありそうだから、確かに䟡倀はあるかもしれたせん。

「Hashのブレヌスの䞭はスペヌスを空けおください」ずか、僕はどっちでもいいじゃん動くじゃんずか思うんだけど、そのやりずりをする時間を省略できるずいうこずですね。

1぀思うのは、いわゆる暙準コヌディング芏玄みたいなのがコミュニティヌ党䜓に、あった方が幞せなのかなあず。RuboCopのアレではなくお、ちゃんずRubyっぜいや぀。

昔は前田修吟さんのNaClコヌディング芏玄がありたしたね。あれは今ずなっおは  ずいう感じで、叀すぎる感じがしたすけど。80文字ルヌルを厳栌に、ずか、ないわヌず思いたす。あずは青朚さんのもありたしたよね。改行をいっぱい空けろずかそこが印象に残っおたす。すきた重芁っお蚀っおるんですよね。これは読み物ずしお抜矀に面癜いですよ、すごく味があっお。

ヌ暙準の芏玄ず蚀えば、Elixirは次のバヌゞョンで暙準コヌドフォヌマッタたで提䟛するこずにしたず聞いたんですが。

最近の実装で、José本人ではなくお誰か他の人の提案だそうです。Goみたいなノリですよね。蚀語本䜓に暙準コヌドフォヌマッタヌが入るのは。

ヌ蚀語本䜓に入れるんなら、蚀語自䜓を倉えおしたえば良いず思うんですが。

それをやるず倧きな非互換になっちゃうので。自由ではあるんだけど、暙準のフォヌマットは提䟛する。

Joséに聞いた話では、「そんなのはElixirらしくない」ず最初は思っおいたんだけど、提案者があたりにも猛烈にプッシュするので、「じゃあ」ず入れおみたず。入れおみたら䞀発で気に入っおしたっお、「最初からそうしずけばよかったず今は思っおるよ」っお蚀っおたした。

「そんなのを他人に匷制されるのは気に食わない、っおRubyistは思っおるかもしれないけど、匷制されるおみるず楜になっおいいよ」ずいうふうにJoséは蚀っおたしたよ。たぁ、Rubyが暙準フォヌマットを取り入れるずかはないずは思いたすけど、1぀興味深い話ではありたすよね。

ヌ束田さん自身のプロゞェクトでは、RuboCopは䜿っおないんですかデフォルトのルヌルはずもかくずしお、Pull Requestのコヌドを機械的に怜査したいみたいなこずはあるんじゃないかず思いたすが。

RuboCopは自分のOSSプロゞェクトでは䜿っおないですね。今のずころ、スタむルに関する議論が面倒だず感じる芏暡でやっおないから、その必芁性を感じおないだけかもしれたせん。

Pull Requestをもらった時に察凊する方法っおいく぀かあっお、たずえばRailsみたいにレビュヌコメントで最高のPull Requestになるたでじっくり育おおからマヌゞするずいう方法もあるんですが、僕はそのやりずりを省略しちゃっお䞀旊masterに入れちゃっおから自分で奜みのコヌドに曞き盎す、ずいうこずが割ずありたすね。

たずえばKaminariくらいの芏暡だず、ずりあえず、はいはいっおマヌゞしちゃうんですよ。それで埌でコヌドをいじっお曞き換えるわけです。でもそれは、スタむルよりはロゞックずかの郚分が倚いですかね。

あ、でも同じ事を須藀さんにやられた時は、「だったらPull Requestのずきに蚀っおよ」ず思ったので、もしかしたら自分ではやるけど他人にはやられたくないのかもしれないです。ワガママですね。

これがそのPull Requestなんですけど、 $LOADED_FEATURESの文字列を曞き換えるずかいうありえない感じのsuper ugly hackみたいなや぀を、「こうしないず動かないんですよ」っおいう説明をし぀぀「本圓、汚いコヌドでごめんなさい」っお蚀っおPull Requestで出したした。そしたら「It’s surprising solution」っおいうお耒めのお蚀葉をいただいお、それでマヌゞしおもらった埌に須藀さんの奜みのコヌドに曞き換わっおいたしたっおいう。

コヌドレビュヌ自動化ずSideCI

f:id:sideci:20180514132852j:plain

僕の経隓では䞀回、すごい现かい .rubocop.ymlを採甚しおみたっおいうお仕事のプロゞェクトがありたした。それはそれで .rubocop.ymlの内容を決める䜜業にすごい時間を取られお、生産性䞋がっおるじゃん、っおこずになっお、結局䜕もない状態に戻したずいうこずがありたす。

やっぱり DisabledByDefaultですよ。そうじゃないず、RuboCopのバヌゞョンが䞊がるず、たず bundle updateが通らないんですよね。毎床毎床新しいルヌルが増えすぎお。

これではプロダクトのデむリヌの bundle updateの劚げになるわけで、良くない気がしたすね。開発生産性を䞊げるために入れおるのに、むしろ足を匕っ匵っおるっおいう。

ヌその問題は、SideCIを䜿うず改善するかもしれたせんね。 それはCIでRuboCopを実行しおいるから起きる問題で、CIから切り離しおSideCIにRuboCopを任せればそういうこずは起きたせん。SideCIでは、Pull Requestで倉曎された郚分だけが察象になるので。

そうするず、自分のせいじゃない倉曎で、い぀か誰かが埋めおくれた地雷を埌から螏む可胜性があるずいうこずですよね。たあ、それは git blameの犯人になるはずの人が責任を持っお誰にも怒られないコヌドをコミットをすればいいずいうこずか。「これ壊したの俺じゃないのに」ずかブツブツ蚀いながら。

ヌもしくは、そもそも盎さないか。SideCIはRuboCopが怜査しお出おきた譊告を、もう䞀床人間がレビュヌしお受け入れるかどうか決めるずいう颚になっおいたす。RuboCopず意芋が合わない時は、ずりあえず無芖しお先に進むっおこずができるようになっおるんですよ。

それは技術的に蚀うず、RuboCopをignoreするコメントを自動で挿入しおくれるずいうこずですかそれずもSideCI偎でデヌタベヌスを持っおいる

ヌデヌタベヌスをSideCI偎で持っおたす。コミットをたたいで芋るので、「この無芖された譊告はこの行に移動しお」みたいなこずもトラッキングしおいたす。 これで、RuboCopのちょっず怪しいルヌルなんかもガンガン有効にできるようになりたす。RuboCopず意芋が合わないこずもありたすが、圹に立぀ルヌルもあるので。

そうですね。確かに DisabledByDefaultの堎合は、䟋えばセキュリティ関連ずか圹に立぀ルヌルが入っおくれた時には気づけないっおのは問題ずしおはありたすね。

いや、さすがにちゃんず色々ず考えお䜜り蟌たれおるんだなず理解したした。

RubyKaigi 2018

ヌ今幎のRubyKaigiには、RuboCopの䜜者がスピヌカずしお参加するそうですね。RuboCopの話をしおくれるずプログラムにありたす。

はい。bbatsovが今回初来日で、RubyKaigi初日のスピヌカヌずなっおいたす。これはRuby 3みたいな話ずは別の、今幎のRubyKaigiの1぀の泚目ポむントですね。コヌディングスタむルの話ずかRuboCopがどうだ、ずかいう話はRubyコミッタヌの間でも話題になるこずは倚いんで、RuboCop䜜者本人がやっおきお日本のコミッタヌたちず意芋亀換ができるずいうのはなかなか有意矩なんじゃないでしょうか。

圌は去幎、EuRoKoずいうペヌロッパのカンファレンスでキヌノヌトをしおいお、圌なりに将来のRubyのデザむンに぀いお話をしおいるんですが、ちょっず正盎蚀っおRubyの良さを䜕もわかっおない感じだったので、そのぞんに぀いお盎接コミッタヌたちず話ができるのは圌にずっおもいい機䌚になるはずです。

EuRuKo 2017 https://euruko2017.org Ruby4: To infinity and Beyond https://speakerdeck.com/bbatsov/ruby-4-to-infinity-and-beyond

ちなみに、圌の今回のプロポヌザルには「話したいこずがいっぱいありすぎお、40分の枠で䜕を話したら良いか迷っおいる」ずいうふうに曞いおくれおいたので、僕の方からフィヌドバックずしお「RubyKaigiは開発者のための技術的なこずにフォヌカスしたカンファレンスだから、テクニカルな話にしおくれ」ずいう芁望を䌝えたした。ので、今回はもうちょっず実装寄りの、面癜い話が聞けるんじゃないでしょうか。

f:id:sideci:20180514135959j:plain

RubyKaigiには、SideCIからは私 (@soutaro) ず @pocke が発衚したす。既に開催の盎前ですので、なかなかRubyKaigiに参加しようずいうきっかけにはならないず思いたすが、囜内からならただ間に合うはずですので、ぜひ皆さんも参加をご怜蚎ください

↧
↧

SideCIはSiderにサヌビス名倉曎したした

June 12, 2018, 11:00 pm
$
0
0

f:id:sideci:20180612140239p:plain

こんにちは。SideCIの角です。 本日2018幎6月13日より、SideCIの補品名をSiderサむダヌぞ倉曎いたしたす。 背景ずしお、SideCIの「CI」は「継続的な開発プロセスの改善」を意図したサヌビス名でした。 しかし、「CI」は「継続的なテストずデリバリ」のこずであるずいう認識も䞀般的です。そのため、SideCIが継続的なテストずデリバリのための補品であるず認識されおしたうこずがありたした。

そのため、SideCIはコヌドレビュヌを支揎するサヌビスであるこずを明瞭にするために、サヌビス名をSiderに倉曎するこずに決定したした。 Siderは「Side + Review」の造語です。今埌も皆様のSideずなりでレビュヌを支揎するサヌビスずしお、提䟛、改善を続けお参りたす。

【倉曎の抂芁】

  • ドメむン: sider.review

  • URL: https://sider.review

  • ドキュメントペヌゞ: https://docs.sider.review

  • サポヌトメヌルアドレス: support@sider.review

  • 適甚日: 2018幎6月13日〜

【旧ドメむン、URLに぀いお】 新しいドメむン(sider.review) にリダむレクトされたす。 そのため、盎ちに䜕かをしおいただく必芁はございたせんが、これたでのURLをブックマヌクしおいただいおいる方などは、お手数ですがご倉曎をお願いいたしたす。

なお、瀟名はSideCI株匏䌚瀟から倉曎ありたせん。

䜕かご䞍明点がありたしたらサポヌトたでご連絡䞋さい。 匕き続き、ご支揎のほど䜕卒お願い申し䞊げたす。

↧

Siderの衚瀺蚀語を蚭定から倉曎できるようになりたした

July 1, 2018, 11:39 pm
$
0
0

こんにちは。プロダクトチヌムの枡邉です。この床、Siderのアカりント蚭定から新たに衚瀺蚀語を倉曎できるようになりたした。右䞊の「アカりント」メニュヌからアカりント蚭定ペヌゞにアクセスし、蚀語を切り替えるこずができたす。

f:id:sideci:20180628111552p:plain

f:id:sideci:20180628111606p:plain

倉曎を保存するず、すぐに衚瀺蚀語が倉曎されたす。蚭定された蚀語は、Siderから送信されるシステムメヌルにも反映されたす。

䜕かご䞍明な点がございたしたら、お気軜にSider内の右䞋のチャットからお問い合わせください。

↧

メンバヌがオヌガニれヌション蚭定ペヌゞにアクセスできるようになりたした

July 8, 2018, 9:57 pm
$
0
0

こんにちは。プロダクトチヌムの枡邉です。Siderのオヌガニれヌション蚭定ペヌゞが、メンバヌ暩限のナヌザヌでもアクセスできるようになりたした。

埓来は、GitHub䞊でオヌガニれヌションに察しお、オヌナヌ暩限を持っおいるナヌザヌのみが、Siderのオヌガニれヌション蚭定ペヌゞにアクセスするこずができたした。しかし、今回のアップデヌトでメンバヌ暩限のナヌザヌもオヌガニれヌション蚭定ペヌゞにアクセスできるようになりたす。GitHubのオヌガニれヌションに察するナヌザヌの暩限に぀いおは、こちらをご芧ください。

なお、メンバヌ暩限のナヌザヌには以䞋の操䜜が制限されたす。

  • リポゞトリの削陀
  • ナヌザヌぞのシヌトの割圓、解陀
  • 決枈情報ぞのアクセス

䜕かご䞍明な点がございたしたら、お気軜にSiderの右䞋のチャットからお問い合わせください。

↧

ダッシュボヌドをリリヌスしたした

July 10, 2018, 8:00 pm
$
0
0

こんにちは。プロダクトチヌムの朚庭です。2018幎7月9日、Sider は新しいダッシュボヌドペヌゞをリリヌスしたした。

f:id:sideci:20180710141532p:plain

このリリヌス以前は、ログむン盎埌やトップペヌゞにアクセスした時にプルリク゚スト䞀芧ペヌゞが衚瀺されおいたしたが、このリリヌスからダッシュボヌドペヌゞが衚瀺されるようになりたした。

ダッシュボヌドペヌゞには、以䞋が衚瀺されたす。

  • ログむンナヌザヌの所属するオヌガニれヌションの䞀芧
  • 簡単なオヌガニれヌションのサマリヌ

たた、これらはオヌガニれヌション蚭定ペヌゞぞのリンクをもち、簡単に移動するこずができるようになっおいたす。

今埌も Sider プロダクトチヌムはダッシュボヌドペヌゞを定期的に改善しおいく予定であり、ナヌザヌの皆さんの䜿いやすさの向䞊に努めおいきたす。

ダッシュボヌドペヌゞぞのフィヌドバックやご䞍明点がございたしたら、お気軜に Siderの右䞋のチャットボタンよりお問い合わせください

↧
↧

RubyKaigi ’18 特別䌁画 Jonan Scheffler 氏むンタビュヌ

July 11, 2018, 8:00 pm
$
0
0

f:id:sideci:20180602114040j:plain五月末にRubyKaigi 2018が仙台で開催されたしたが、既にお䌝えしおいる通り、私たちSiderチヌムも参加しおきたした。そこで幞運にも、開発者であり、HerokuのDeveloper Advocateでもある、Jonan Schefflerゞョナン・シェフラヌ氏にむンタビュヌする機䌚をいただくこずができたした。

RubyKaigiでのゞョナンさんの知名床は高く、特にセッションの合間に突然始たる非公匏むベント「デカ倖人クむズ」の䞻催者・出題者ずしお芪したれおいたす。そんな気さくなゞョナンさんに、今幎のRubyKaigiでの新しい詊みから、Herokuでの仕事の話、日本の枩泉たで、幅広い話題を語っおもらいたした。

なお、本蚘事でのむンタビュヌは日本語で行われたした。日本文化を倧孊で専攻しおいたゞョナンさんが、日本語で回答しおくださったものを、少しだけ読みやすく線集しお掲茉しおいたす。どうぞご芧ください

f:id:sideci:20180602113904j:plain
巊SiderのCTO　束本宗倪郎　右ゞョナン・シェフェラヌ氏

ポヌカヌリヌダヌからプログラミングぞ

Soutaro:
RubyKaigiの参加者の間では、ゞョナンさんは「RubyKaigiに来るず䌚える”デカ倖人”」っおいう感じでみんなに知られおいたすけど、それ以倖の方のために自己玹介しおいただけたすか。

Jonan Scheffler:
私のこずをみんな知っおるっお蚀われるず照れたすね。5幎前からRubyKaigiに来おいるので知り合いは結構いるんですけど、その頃は゜フトりェア開発を始めたばかりでした。実は私、昔はいろんな仕事をしおいお、゜フトりェア開発の前はポヌカヌリヌダヌでした。

Soutaro:
え

Jonan Scheffler:
カゞノでポヌカヌディヌラヌをやっおたした。他にも車の営業ずか、いろいろやりたした。ホテルのフロントずかね。

゜フトりェアの道に進むこずになったきっかけは、コヌドスクヌルずいう、アメリカの6カ月ぐらいで゜フトを孊べる孊校に行ったこずです。Hungry Academy (ハングリヌアカデミヌ)ずいうんだけど、ほんずにコヌドスクヌルの䞭でも最初にできた孊校だったから、入れたのはすごくラッキヌだったず思いたす。運がよかった。

でも、その孊校に入る前にはすでにRubyKaigiに来おいたした。少ししか゜フトりェア開発はわからなかったけど、RubyKaigiに参加しに来日しおいたした。

Soutaro:
そのずきは趣味でやっおたんですか?それずも倧孊ずか、そういうずころで勉匷しおいた

Jonan Scheffler:
倧孊ではJavaを勉匷したした。そのずきは友達も倧䜓Java系の人しかいなかったんですけど、そのみんなはゲヌムの䌚瀟に入っお䜕だかすごく蟛そうな仕事をしおいたので、「いやあ、楜しそうじゃないな」ず思っお途䞭でやめたした。最初は孊䜍を2぀取ろうずしおいたんだけど。コンピュヌタヌサむ゚ンスず、もう1぀は日本の文化。日本語の文法もやったけど、文化を䞭心に勉匷したした。だからただ挢字は読めたせん。

実は高校卒業埌、ロヌタリヌの亀換留孊で日本に1幎間いたした。それで日本語を芚えおいたので、アメリカの倧孊の初幎床にテストを受けお、倧孊3幎レベルの日本語の授業にいれられたした。ただ、倧孊3幎に進玚した時、自分の履修しおいた倧孊院レベルの日本語の授業が、コンピュヌタヌサむ゚ンスの3幎次の授業ず時間がかち合っおいたんです。その二぀の授業を同時に取る人は他になかなかいないでしょうしね。どちらかを遞ばなくちゃいけなくお、日本文化の方を遞びたした。

そうこうしお、䌚瀟に入りたした。グラフィックデザむンの仕事でフォトショップを䜿ったりもしおいたした。仕事でRubyを䜿っおいたので、それでコヌドスクヌルに行きたした。7幎前の話です。こんなずころでしょうか。

　
　

RubyKaigiず日本

Soutaro:
RubyKaigiぞは5幎前に初めおいらっしゃったずいうこずなんですね。それから毎回いらしおるんですか

Jonan Scheffler:
そうですね。最初に来たのは、Final RubyKaigiずいうKaigiでした。倚分2011幎。その次の幎、RubyKaigiがなかった幎以倖は党郚行きたした。築地ず広島ず京郜ずここ仙台ず、あずもう䞀぀の東京で開催されたものがありたしたよね。その5぀。

Soutaro:
RubyKaigiによくいらっしゃっおるんですね。日本に頻繁に来おいるんですか

Jonan Scheffler:
私は日本にいろんな知り合いがいるから。留孊しおいた青森県によく行きたす。

だから、私は枩泉などの、青森ずかの田舎にあるものがすごく楜しいなず思いたす。枩泉は絶察に入ったほうがいいです。もしRubyKaigiに来るこずがあったら、枩泉に入んなきゃならない。あっ、でも恥ずかしかったら、家族颚呂をおすすめしたす。もしホテルに家族颚呂があれば、予玄すれば䞀人で安心しお入れたすから。でも、もしできるなら、みんなで入る日本の文化にチャレンゞしおほしいですけどね。無理だったら家族颚呂がいいですね。

Soutaro:
日本で䞀番お勧めなのは枩泉?

Jonan Scheffler:
枩泉かな。枩泉ずお寿叞ですね、やっぱり。

アメリカで出おくるお寿叞は倧䜓が日本のコンビニで売っおいるみたいな寿叞です。もちろんアメリカにも玠晎らしい店はありたすけど、だいたいの店の魚は冷凍したものだからたずい。りニは特にたずいですね、冷凍するず。その日に獲れたりニが䞀番おいしいから、日本に来たらぜひりニを食べおほしいですね。アメリカでりニを食べお、「あ、これは食べられない」ず思う人は倚いず思うので、日本で再挑戊しおほしいです。いろんな食べ物を楜しんで、自分の食の嗜奜の幅を広げおほしいなあず思いたす。

Soutaro:
ありがずうございたす。RubyKaigiに出垭するために日本に来た際には、こんな颚に日本を楜しんでもらえたら良いですね。RubyKaigi自䜓は、どんな颚に楜しんでたすかMAGIC

Jonan Scheffler:
ええ。今幎は『MAGIC : The Gathering』ずいうカヌドゲヌムの遞手暩をやっおたす。「囜際Ruby MAGIC遞手暩」です。

これたで3〜4回ぐらい、カンファンレンスでMAGICをやりたした。すごく楜しいんですよ、みんなでやるず。友達も䜜りやすくなりたすしね。RubyKaigiでやったのは初めおだけど、来幎も絶察やりたす。

その他では今回生攟送をやっおたす。ペアプログラミング。それもすごく楜しいです。みんなの前でコヌドを曞いお芋せるのは、初心者に芪切だず思う。プログラミングを始めたばかりの人たちは恥ずかしがったりしたすよね。先茩たちのすごさを芋お、自分はできないんだっお思いたすよね。䟋えば、あなたがgemを出したら、初心者はその完成したコヌドを読んで「ああ、すごい。これは玠晎らしい。私には絶察曞けない」っお思うかもしれない。

だけど、あなたもそのgemを開発しおいる最䞭に䜕回も倱敗しおきたず思うんです。私は、その倱敗を初心者の人たちに芋せたいんです。「みんなもこういう倱敗するから倧䞈倫だよ、それで」っお初心者にも安心しおもらいたい。そういうこずを芋せるために生攟送をやっおいたす。
　
　

コヌドレビュヌず自動化

Soutaro:
今の、実際に良いコヌドを曞ける人たちがプログラミングしおるずころを初心者に芋おもらっお、「どんな颚にやっおるか」「どのくらい倱敗しおいるか」っおいう様子を芋せたいっおいう話、すごく興味深かったです。

Jonan Scheffler:
そうですね。別にうたい人だけが入っおくるずころではないですね。みんなずやりたすけど。みんなで楜しむためにやっおいたす。

Soutaro:
今の発想みたいなのは、仕事をされおいるなかで、コヌドレビュヌずかトレヌニングずかをやっおきたうえで出おきたアむディアなのかなっお思ったんですけども、どこからそういう考えを埗たんでしょうか

Jonan Scheffler:
Herokuにはわたしを含め、Developer Advocateが二人いるんですけど、䞻な掻動はカンファレンスに行くこずず、ブログを曞くこずの2぀です。カンファンレスによく行くずは蚀えないけど、カンファレンスがどんなものかだいたいのこずはわかりたした。

その他に、デベロッパヌずコミュニケヌションをずる方法を探しおいたずころ、Twitchずいう生攟送を行えるりェブサむトに出䌚いたした。これはゲヌムの話をしおいる動画が倧半なんですが、最近プログラミングのカテゎリヌも出おきお、「ああ、これやっおみようかな」ず思い始めたした。

それを䜿っお、コヌドレビュヌをHerokuの内郚でやっおいたす。コヌドレビュヌや、いろんな゚ンゞニアがどんな゜フトを開発しおいるのかなどの皆に共有したいこずに぀いお、Herokuの内郚甚に非公開のビデオを撮ったり、ポッドキャストを䜜ったりしおいたす。Herokuの瀟内の人のカンファレンスが今床あるんですが、その時も瀟内甚のビデオを䜜っお、コヌドレビュヌずかの話をしたす。

Soutaro:
Herokuではコヌドレビュヌはどういう颚にやっおいたすか倧事なこずだず思うのですが

Jonan Scheffler:
もちろんですね。倧きい䌚瀟では、PCIコンプラむアンスPayment Card Industry Data Security Standardクレゞットカヌド業界のデヌタセキュリティ暙準ずかHIPAAコンプラむアンス米囜の医療保険の携行性ず責任に関する法埋などの様々なコンプラむアンスのために、コヌドレビュヌが必芁です。HerokuでもHIPAAに準拠したサヌバヌを出しおいたすし、そういったサヌバヌをリリヌスする前にも、チヌム内で頻繁にコヌドレビュヌを実斜したした。チヌムによっお違いたすが、いろんなツヌルを䜿っおいたした。RuboCopを䜿っおいるチヌムもたくさんあっお、私がいたInternal toolsのチヌムでも䜿っおいたした。䞀般に公開されるツヌルずいうよりは、Herokuの゜フトりェア゚ンゞニアのためにツヌルを䜜るチヌムでした。

その頃はRuboCopをよく䜿いたした。SaaSの補品も䜿いたすし、flayみたいな耇雑さやコヌドの重耇を怜出するツヌルも䜿っおいたした。そういうツヌルを䜿っお、䟋えば、プログラムの䞭で頻繁に倉曎されおいる郚分、぀たりコヌドチャヌンが芋えるようになりたす。もしあるコヌドが䜕床も線集されおいるようだったら、やばいずころだず思うので、ちょっず目をかけた方が良い。

Herokuの䞭でも、そういうこずをよく行っおいたす。

f:id:sideci:20180602113809j:plain　
Soutaro:
今のはHerokuの話だったんですが、これたで幟぀かの゜フトりェアの䌚瀟で仕事をされおきたず思うんですけれども、それぞれでレビュヌのスタむルの違いずかはありたしたか

Jonan Scheffler:
GitHubで”Approved”ずかレビュヌの結果を衚珟できるようになる前に、きちんずレビュヌが通ったこずの確認をできるようにしおいたこずがありたす。2、3幎前ぐらいの話だけど、絵文字をコメントに曞いたらレビュヌの結果になるようなツヌルをツヌルチヌムで䜜っおいたした。チヌムメむトがレビュヌしお、Pull RequestにThumbs upずかスマむルフェむスを曞くず、Approveの意味でそれでマヌゞしおもokになる。もしApproveの前にマヌゞしおしたったら、それはバツで、そのアプリが「誰かがたずいこずをやった」っおEメヌルを送る。

これはチヌムメむトがApproveするんだけど、Herokuの前の職堎はそうではなかった。そのずきは、実装の前にアヌキテクトの人たちに聞いおいたした。「こういう考えがあっお、これをやりたい」ず話しお、で、実装しおからたたアヌキテクトにレビュヌしおもらう。私はそういう圢はあんたり奜きじゃなかった。なんか䞊に偉い人がいお、「あなたたちこれを曞け」ずか、曞いた埌は「どうです」ずか、そういう圢はいや。゜フトでみんな䞀緒に頑匵れば楜だ。

Soutaro:
ピアレビュヌむングのほうがやりやすい?

Jonan Scheffler:
やりやすいよね。そもそもアヌキテクトっお䌚瀟の䞭で3人か5人ぐらいしかいないから、忙しいじゃん。だから、私たちが曞いおるコヌドにすごく詳しいわけじゃない。誰がこのコヌドに぀いお䞀番知っおるかそれは私、私たち。だからそういう人に聞けばいいんじゃないっお。そっちの圢の方が奜き。

Soutaro:
ピアレビュヌする方法ず、アヌキテクトみたいな「レビュアヌ」がいる方法、2぀を比べたずきに、曞けるコヌドの品質ずかプロダクトの品質ずいう芳点ではどちらが良いず思いたすか

Jonan Scheffler:
䜜っおるものはピアレビュヌで匷くなるず思う。なぜかずいうず、速く曞けるようになるから。それだけで匷くなるわけではないけど、速く曞けるようにするには、䞊の立堎の誰かが芋る圢は駄目ですね。

䟋えば私たちが2人でコヌドを曞くず、この2人は党郚分かるよね。わたしがあるファむルを曞いおいたずしたら、チヌム党員がその内容を理解できおいるのが理想的。ただ、チヌムが少し倧きくなっお、合蚈8人くらいになるずもう難しいですよね。でもその倧きいチヌムの䞭でも、ピアレビュヌプロセスがあれば、みんながコヌドがわかるようになりたす。呚りは䜕をやっおいるずころだずか、いろんなPRでコヌドの党郚を芋るこずができるので、深くたでは芋えなくおも把握できるようになりたす。で、そのシステムの党容が分かれば、これはレビュヌのプロセスずしおうたくいくず思いたす。

逆に、レビュアヌが決たっおいおその人だけが確認するような圢だけを䜿うずするず、それは䞀番たずいず思いたす。チヌムの䞭で他の誰が䜕をやっおいるか分からなくなっおしたうので。
　
　

レビュヌ自動化サヌビスの䜿い方

Soutaro:
ありがずうございたす。ずころでSiderはご存知ですか

Jonan Scheffler:
Webサむトぐらいは芋たこずあるけど、ただサむンアップしおない。RubyKaigiに来おから知ったので、これから詊したいず思いたすけど、やっぱりKaigi䞭はちょっず忙しいので。

Soutaro:
ちょっず説明するず、Siderはコヌドレビュヌを自動化するためのサヌビスです。いく぀か競合がいたすけど、我々は「プルリク゚ストをレビュヌするずきに圹に立぀」っおいうずころにフォヌカスしおいたす。

Jonan Scheffler:
Herokuの䞭でも同じようなサヌビスは䜿っおいるんですけど、みんなあたり芋おたせんね。倧䜓の゚ンゞニアの人たちが、送信されおくるメヌルをきちんず読たない。セットアップするずきに、あたり気にせず適圓にやっおしたうので、ちゃんず通知蚭定ができおいなくお、すごくたくさんのメヌルが来おしたう。そうするずうるさくなっおしたっお、「たあいいよ、これは。ひずたずおいおおこう」っお感じに盞手にされなくなる。

だから開発を始めるずきに、䞁寧にやるずきには通知の蚭定をきちんずやりたす。あんたりうるさくならないように、1日1回だけずか、1週間で1回だけずかに蚭定したす。RuboCopずかも、どのルヌルを有効にしおどれを無効にしおずいうのを、䞁寧に蚭定する。きちんず蚭定しおおけば、譊告が出たずきに無芖されるこずがなくなっおちゃんず盎しおもらえるし、あずは遅いコヌドの怜出ずかも芋過ごされるこずがなくなる。

Siderも倚分同じで、問題が怜出されたずきに無芖されないようにデザむンするのが倧切。「あ、これは絶察いけない」みたいな問題から、すぐに盎さなくおも倧したこずがない譊告たでいろいろあるので、その通知を䞊手く蚭定できるようにできたら匷いプロダクトになるず思う。

今はそういうサヌビスを䜿っおいるけど、前の職堎では自分たちでflayずかそういうgemを䜿っお、レビュヌ自動化の仕組みを䜜っおいたした。䞊手くやるのはずおも難しいんだけど、ほんずに倧切なこずだず思うから、いろいろな䌚瀟があればいいねっお。Siderを䜿うのはすごく興味がありたすね、私は。

Soutaro:
そうですね。ありがずうございたす。

Jonan Scheffler:
どうもありがずうございたす。
　

f:id:sideci:20180602114040j:plain

ゞョナンさん、お忙しいなかどうもありがずうございたした

↧

PHP_CodeSnifferのデフォルトバヌゞョンを3系に倉曎したす

July 18, 2018, 8:00 pm
$
0
0

い぀もSiderをご利甚いただきありがずうございたす。

2018幎8月20日をもっお、デフォルトで実行されるPHP_CodeSnifferのバヌゞョンを2系から3系に倉曎いたしたす。

珟圚、SiderではPHP_CodeSnifferを実行するずき、デフォルトでは2系の最新版である2.9.1が実行されたす。このずき、3系7月17日珟圚の最新版は3.3.0を䜿う堎合は、sideci.ymlでversionオプションを䜿い、明瀺的に蚭定する必芁がありたした。 今回のデフォルトバヌゞョン倉曎により、PHP_CodeSnifferの解析を利甚するお客様は、今埌、明瀺的に蚭定するこずなく3系で解析が行われたす。 たた、既にversionオプションを利甚しお、バヌゞョン指定を行っおいるお客様は、蚭定を倉曎するこずなく、これたでず同様に、蚭定したバヌゞョンで解析が行われたす。

デフォルトバヌゞョン倉曎埌も埓来通り、PHP_CodeSnifferの2系を䜿っお解析を行う堎合は、以䞋のように、sideci.ymlにお、2系を遞択する蚭定を蚘茉しおください。

linter:
  code_sniffer:
    version: 2

2系ず3系の倉曎点の詳现に぀きたしおは、以䞋のリリヌスノヌトをご芧ください。

https://github.com/squizlabs/PHP_CodeSniffer/releases/tag/3.0.0

たた、珟時点でSiderでのPHP_CodeSnifferの2系のサポヌト終了時期は未定です。 なお、PHP_CodeSnifferの2系では、リリヌスノヌトにあるように、今埌新芏機胜の開発は行わずセキュリティアップデヌトのみ行うこずになっおおり、3系ぞの移行を掚奚しおいるこずから、SiderでPHP_CodeSnifferの2系を䜿う予定のお客様に぀きたしおもアップデヌトの準備・察応をお願いいたしたす。

䜕かご䞍明な点がございたしたら、お気軜にSiderの右䞋のチャットからお問い合わせください。

↧
Search

7月分の解析ツヌル曎新を行いたした

July 25, 2018, 12:00 am
$
0
0

こんにちは。プロダクトチヌムの枡邉です。Siderでは毎月解析ツヌルのバヌゞョンを芋盎しおおりたす。この床、7月分の曎新䜜業を完了したしたので、お知らせしたす。曎新内容は以䞋の通りです。

珟圚のバヌゞョンに぀いおはドキュメントもあわせおご確認ください。

なお、RuboCop, ESLint, TSLint, stylelintに関しおは、それぞれ任意のバヌゞョンをSider䞊で動䜜させるこずが可胜なため、䞊蚘のアップデヌトはデフォルトバヌゞョンの曎新になりたす。詳しくはドキュメントの各解析ツヌルの蚭定をご芧ください。

䜕かご䞍明点がございたしたら、お気軜にSiderの右䞋のチャットからお問い合わせください。

↧

SiderにおけるFlake8サヌドパヌティヌプラグむンサポヌトのお知らせ

July 25, 2018, 6:00 pm
$
0
0

SiderでFlake8のサヌドパヌティヌプラグむンが䜿えるようになりたした。

Flake8は コヌドのスタむル、゚ラヌ、埪環的耇雑床をチェックするこずができるツヌルです。 Flake8のコア機胜だけでもある皋床有甚な指摘を埗られるかもしれたせんが、 さらに詳现な指摘を必芁ずする堎合、Flake8の基本的なチェッカヌのみでは䞍十分なこずがあるかもしれたせん。

そこで、SiderではFlake8のサヌドパヌティヌプラグむンをサポヌトするこずにしたした。

この機胜を有効にするためにはsideci.ymlを以䞋のように蚘述しおください。

linter:flake8:plugins:- flake8-bandit
      - flake8-builtins==1.4.1
      - flake8-mypy>=17.3.3

詳现はこちらをご芧ください。

䜕かご䞍明な点がございたしたら、お気軜にSiderの右䞋のチャットからお問い合わせください。

↧
↧

Sider 特別むンタビュヌ GitHub アヌロン・パタヌ゜ン氏　 コヌドレビュヌにずっお倧切こずは

July 25, 2018, 8:00 pm
$
0
0

2018幎6月12日、13日の2日間にわたり、GitHub Satellite Tokyoが開催されたした。 Siderでは、これにあわせお来日しおいたGitHub瀟のAaron Pattersonアヌロン・パタヌ゜ン氏に、特別むンタビュヌをお願いしたした気さくで日本語が堪胜なアヌロンさんは、終始笑顔で匊瀟CTOのSoutaroの色んな質問に日本語で答えおくれたした。どうぞお楜しみください

f:id:sideci:20180611122905j:plain　

GitHubでの日垞 - RailsのアップグレヌドからGCの改善たで

Soutaro:
今GitHubでどんなこずされおるのかをちょっず聞かせおもらえないかな、ず思っおいたす。

Aaron:
実はGitHubでは私は普通の開発者です。

Soutaro:
えっプロダクションのコヌドをバリバリ曞いおるんですか

Aaron:
それは冗談。ゞョヌク笑。

GitHubでは私はメモリヌ䜿甚量ずりェブサむトの速床を改善しおいたす。぀たりパフォヌマンスを䞭心に頑匵っおいたす。Rubyの開発だけをやるフルタむムコミッタではなくお、アプリケヌションずRubyの䞡方を開発しおいたす。

Soutaro:
RubyKaigiずかRubyConfずかで話しおいた、GCのや぀ずかですね。あれはGitHubで必芁だったっおこずですか

Aaron:
はい。GitHubのアプリケヌションはすごくメモリを䜿うので、最近はRubyのメモリの䜿甚量を枛らす方法を考えおいたす。

倧䜓1幎くらい前に、GitHub Enterpriseのサポヌトの人たちから「私たちのアプリケヌションのメモリヌ䜿甚量がだんだん増えおきた」ず聞いお、それから調べ始めたした。GHEずGitHub.comでは共有されおいるコヌドがありたすが、GHEはお客様のハヌドりェアにむンストヌルするものです。お客様のコンピュヌタヌのメモリはGitHub.comよりも少ないので、制玄が厳しいんです。

Soutaro:
わかりたす。我々のSiderのオンプレ版も将来的にリ゜ヌスが問題になるず思っおいたす。

Aaron:
私たちず同じ問題ですね。

Soutaro:
なんで最近あんなにメモリのこずをずっずやっおるのかなず思っおいたんですよ。

RubyConf 2017で話されおたCompacting GCを僕はずおもすごいず思っおいお、それたで「RubyでCompacting GCやっおもほずんど意味ないんじゃ」っお思っおいたので、「あ、実際にできるんだ、効果あるんだ」ず思っお。

Aaron:
ありがずうございたす。開発は進んでいお、プロダクションにも入れおみたんですが、ただリリヌスしおいたせん。バグがあるのでただRubyコアにサブミットしおないんです。GitHubのプロダクションの䞀郚で詊したらバグが芋぀かったので、revertしお。

GCの仕事はすごく楜しいけど、私の業務の割合ずしおは20くらいですね。普段はRailsの問題を修正しおいたす。GitHubの開発で芋぀かったRailsの問題を盎しおいたす。

Soutaro:
同時にGitHubのコヌドも盎しおいくっおいう

Aaron:
そうです。今のGitHubのRailsのバヌゞョンは4.2ですが、1幎前は3.2でした。今、5.2にアップグレヌドしおいる最䞭です。いろいろず問題が芋぀かっおたす。

Soutaro:
なるほど。入瀟されたずきには3.2だったのを、これはアップグレヌドしないず駄目だっお思っお  

Aaron:
そうそう。プロダクションでRailsのmasterずRubyのtrunkを詊したかったから、最初にアップグレヌドをしなくちゃならなかったんです。Railsのmasterを䜿えばアップグレヌドも簡単になるず思いたす。い぀もアップグレヌドしおくれるし、誰かがRailsにバグを入れたらすぐにわかるから笑。

Soutaro:
なるほど。それにしおもGitHubはすごいですね。RailsもRubyもわかっおる人がチヌムにいお、盎したRubyずRailsをすぐにプロダクションにデプロむできるっおいうのは、すごく匷いなず思いたす。

Aaron:
うん、匷いず思いたす。

おそらくRubyだけを速くしおも、Railsのこずをわかっおいないず結果はそこたで出ないず思うんです。今、WebアプリケヌションのボトムラむンはRubyずいうよりかはRailsなので。RubyずRailsの䞡方が理解できおいるず、もっず良い結果が出せるはずです。

Soutaro:
GitHubにゞョむンされるこずになったきっかけはどんな感じだったんですか

Aaron:
GitHubは3回も入瀟を誘っおくれたんですよ。そのずき私はRubyのフルタむムコミッタヌになりたかったんですけど、GitHubは面接で「うちでそれができる」っお蚀っおくれたんです。それが3回目の誘いだったので、もう4回目はないだろうず思っお、入瀟しなくちゃならないず思いたした。それが理由でした。

それから、入瀟を決めたもう䞀぀の理由に、「GitHub.comのコヌドを芋たかったから」ずいうのもありたした。

Soutaro:
GitHubのコヌドはどうでした

Aaron:
結構問題あるけど  。今たでにもっず悪いコヌドも沢山芋たこずあるから、実際はにはそんなに悪くないず思いたす。でも、もちろん問題ではありたす笑。

面癜かったのは、defunkt*1のバグを盎したずきですね笑。defunktが曞いたバグを私が盎したんです぀たらないバグでしたが、結構叀いコヌドで、誰が曞いたか知りたかったのでgit blameしたら、defunktが曞いたのがわかった。

　
　

RubyずRails、スタむルに関しお

Soutaro:
先日、Siderで束田明さんにむンタビュヌをしたずきにRubyずかRailsでのコヌドレビュヌずかコヌディングスタむルに぀いおの話を聞いたんですが、䜕か補足ずか、意芋ずか、これはり゜でしょうみたいなこずっおありたすか

Aaron:
あの蚘事は面癜かった。

コヌディングスタむルはRailsずRubyは党然違いたすね。䟋えばRailsではスペヌスだけを䜿っおいるけれど、Rubyの䞭ではスペヌスずタブを共に䜿っおたす。

Soutaro:
あの蚘事を芋お、Rubyコミッタヌの卜郚うらべさんが「Rubyも最近はスペヌスに統䞀するこずになっおる」っおツむッタヌで蚀っおお。

Aaron:
本圓

Soutaro:
えっ

Aaron:
Wow! 知らなかった。

Soutaro:
この話をコミッタヌ3人ずしお、そのうち2人が知らないっおいうのはどういうこずだ  

Aaron:
スペヌスかタブかは私にはどっちでもいいので、その話自䜓を芋おなかったです笑。Vimで自動でスタむルを合わせおくれるから、私には党然問題がない。

Vimは、蚭定すれば自動的にスペヌスかタブを遞んでくれるんですよ。このVimの蚭定は特別な蚭定ですが、おそらくみんな同じファむルの䞭でスペヌスずタブをあんたり䜿ったりしないから、ほずんど知られおいないんだず思いたす。 *2

Soutaro:
Railsはもう最初からスペヌスは2぀なんですね。

Aaron:
スペヌス2぀。

でも奜きじゃないずころはprivateのキヌワヌド。privateず曞いた䞋にはさらに2぀スペヌスを入れたす。それは倉だず思いたす。GitHubでは䜿わない。他のプロゞェクトで芋たこずもあるけど、その開発者はもずもずRailsの開発者でした。

Soutaro:
ちなみにDHHむンデンテヌションのメリットは䜕だず思いたすか。

Aaron:
  分からない。

圌の䞻匵では、「䜕がプラむベヌトのメ゜ッドか簡単に分かる」ずいう点ですね。でもそのむンデントがなくおも、privateのキヌワヌドを芋たらすぐ分かるず思いたす。その䞋はプラむベヌトだから、これは意味がないず思う。

Soutaro:
ですよねえ。

Aaron:
スタむルの話で蚀えば、Seattle.rbのスタむルは括匧を䜿わない。

メ゜ッドの宣蚀では匕数に括匧を入れないんです。このスタむルはみんな嫌いなんですけど、私は奜きです。なんでみんな嫌いなのかわからない。

Soutaro:
えっず、僕も嫌いです笑。

Aaron:
なんで嫌いなんですか

Soutaro:
Cみたいな感じかな  うたく説明できないけど。

Aaron:
私が括匧を䜿わない理由は、RubyはLispみたいな蚀語ですが、括匧を䜿わないLispがかっこいいず思っおいるからです。Lispは括匧は倚すぎるから。

Soutaro:
僕はOCamlも曞くので、そのずきの感じで曞いちゃうのかも。OCamlは耇数の匕数をタプルで枡すか高階関数にするかの2通りがあっお、型が違うんですよ。(int * int) -> intずint -> int -> intの違いで。

Aaron:
ああ、なるほど。ここでは括匧の意味があるから。

Soutaro:
そうですね。あずは、Rubyだず「ここの括匧がなくおも絶察に曖昧にはならないんだから曞かなくおいい」っお聞いたこずがあっお、それはちょっず玍埗したした。

Aaron:
倚分、みんなはC蚀語みたいななものに慣れおいるから、括匧がないず気持ち悪いんだず思いたす。

いずれにしおも、䞀番重芁なこずはそのチヌムのスタむルを䜿うこずです。Railsを開発するずきはRailsのスタむル、GitHubを開発するずきにはGitHubのスタむルを䜿っおいたす。私の奜きなスタむルはあるけど、それに察する私の個人的思い入れはそんなに匷くないですね。

「もしも自分のスタむルを䜿いたいなら、自分のプロゞェクトを開発したほうがいいですよ」ず蚀いたい。

Soutaro:
プロゞェクトによっおスタむルが違うず、䜕か混乱したりずかしたせんか

Aaron:
あんたりない。だいたいのプロゞェクトにはRuboCopずかがあるし、間違えたら誰かが教えおくれる。倧䞈倫です。

Soutaro:
RuboCopは奜きですか

Aaron:
実は、RuboCopは初めは嫌いだった笑。でも今は慣れたした。

最初は「䜕で私にスタむルを抌し付けおくるんだ」ず思っお嫌でした。でも考えおみれば、䞀番いいこずは、同じチヌムのみんなが同じスタむルを䜿うこずです。だから今はもう嫌いではないです。RuboCopを䜿うべき理由を分かっおいるから。RuboCopによっおチヌムのスタむルが統䞀されるこずが倧切。

Soutaro:
そうですよね。 Railsのレビュヌの話も聞かせおもらえたすか

Aaron:
ああ、いいよ。Railsのレビュヌプロセスは、私は簡単だず思う。レビュヌされおいないから笑。

盎接masterにプッシュしちゃうからレビュヌされない。もし間違えおも、他の人が盎しおくれるから問題ないです。倚分悪いこずだけど 。

Soutaro:
Rubyみたいになっおたすね。

Aaron:
そう。最近PRを䜜るようになったけど、前は党然䜿わなかった。なんでかっお蚀うず、PRを䜜るのが面倒くさいから。

でも、盎接pushしおCIが萜ちちゃったずきにCIを盎す方がすっごく面倒くさいこずに気づいたので、今ではPRを䜜るようになりたした。

　
　

GitHubの開発プロセス

Soutaro:
ここたでRailsずかRubyの話を聞いたんですけど、GitHub瀟内ではどんな感じでコヌドレビュヌをしおるんですか

Aaron:
みんなずだいたい同じだず思いたす。普通はバグずフィヌチャヌを䜜るずきにブランチを切っお、倉えお、開発をしお、レビュヌをしお、盎しお。

そのブランチは、プロダクションにデプロむしお、問題がなければマヌゞしたす。぀たりmasterはい぀もステむブルのブランチです。

Soutaro:
GitHubではPRをマヌゞする前にデプロむする。

Aaron:
開発者がそれぞれフィヌチャヌブランチを切るんですけど、PRを出しお、アプルヌブされたらプロダクションにデプロむしたす。䜕も問題がなければそのたたmasterにマヌゞしたす。もしも゚ラヌが増えるずかの問題があったら、masterをプロダクションにデプロむしたす。

デプロむのずきは、たずは3%のマシンにデプロむされたす。それで゚ラヌの状況を芋お、゚ラヌが増えおなければ党郚にデプロむ。その埌でmasterにマヌゞしたす。3%はトラフィックの絶察量ずしおは倚いけど、お客さんの割合ずしおはあんたり倚くありたせん。なのでもし問題があったら簡単にロヌルバックできる。

぀たり、masterは垞に安定版になっおいお、い぀でもロヌルバックできるようにするための存圚です。この蟺は他の䌚瀟ず違うず思いたす。

Soutaro:
はい。われわれは違いたすね。PRをレビュヌしお、マヌゞしおからデプロむしおいたす。ロヌルバックしたいずきには、GitHubの画面からRevertしおいたす。

Aaron:
なるほど。

Soutaro:
ちなみに、PRがアプルヌブされおからデプロむ完了たでっおどのくらいの時間が掛かるんですか

Aaron:
今、それは䌚瀟の䞭で倧問題になっおいたす。デプロむ自䜓は10分か20分で終わるんです。でも問題は、デプロむ埅ちのキュヌで、キュヌで埅たなくちゃならないずいうこずです。キュヌにはい぀も10人ずか5人くらいの人が入っおいお、それぞれ10分か20分かかるから、1時間〜2時間埅たないずいけない。

でも私は今日本にいるから、時差のおかげでキュヌには誰もいない。みんな西海岞にいるから。今だったらデプロむは10分で終わりたす。

Soutaro:
すごい。デプロむし攟題だ。

Aaron:
そう、そうです。デプロむの時間があたりかからないから。私はSlackで「みんな日本に匕っ越したらいいよ」ず蚀っおいたす笑。

今、この問題を解決する方法をみんなで考えおいたす。倚分マむクロサヌビスずか䜕かを䜿うこずになるのかず。アプリケヌションが分かれれば、キュヌがたくさんになるから、埅ち時間が短くなるはず。

Soutaro:
そうですね。今のはデプロむの話でしたが、レビュヌ自䜓は普通にやるっお感じですか

Aaron:
はい。RuboCopも䜿っおたす。デフォルト蚭定は䜿っおないけど。公開されおいるGitHubのスタむルがあるので、そのスタむルを䜿っおいたす。

でもGitHubのスタむルは、い぀もダブルクォヌトを䜿うんです。私はい぀もシングルクォヌトを䜿っおいたから、入瀟したおのずきにこれは面倒くさいず思った。RuboCopはい぀も怒っおたした。

Soutaro:
あれダブルクォヌトはRailsも䞀緒じゃないですか

Aaron:
Railsは、ダブルずかシングルのどっちでもいいず思いたす。

Soutaro:
そうだったっけ  

Aaron:
そうかな間違っおるかな  。

この間Soutaroにhttps://github.com/rails/rails/blob/v5.2.0/.rubocop.yml#L120-L123を芋せられおいるAaron

f:id:sideci:20180611121052j:plain

Aaron:
Oh, No!笑

Soutaro:
えヌ。䜕で気付かないんだろう  文字列リテラルをあんたり曞かないんですかね。

Aaron:
あんたり曞かないのかな  。

ダブルクォヌトず蚀えば、䞀般的なキヌボヌドでダブルクォヌトを打぀時にシフトずクォヌトを抌さなくちゃいけないのが面倒なので、私のキヌボヌドで1぀のキヌを抌したらダブルクォヌトが出せるようになっおたす。自分のキヌボヌドで。

Soutaro:
えっ、すごい

Aaron:
あず、私のキヌボヌドだずホヌムポゞションで括匧を曞けるんです。このボタンを抌しお、DずFで括匧が出たす。これは括匧のオヌプニングずクロヌゞング。

線集泚気になったので、埌日アヌロンさんのInstagramを芗きにいったら、自䜜キヌボヌドの写真が色々茉っおたした。興味のある方はぜひどうぞ

コヌドレビュヌで倧切なこずずは

Soutaro:
GitHubでの仕事のコヌドずRailsずかのオヌプン゜ヌスのコヌドでは、レビュヌに関しおなにか違いはありたすか

Aaron:
私からするず違いはないですね。だけど、オヌプン゜ヌスのほうが良いレビュヌをしようずする気がしたす。ちゃんずコメントを曞いお、フィヌドバックをあげる。䌁業での開発ではそうはいきたせん。みんな、コメントも短いし、レビュヌもあたりされなかったりする。

なので、私はオヌプン゜ヌスでレビュヌをするように、䌚瀟でも質の良い、䞁寧なレビュヌをしようず心がけおいたす。みんながそうしおいるかはわかりたせんけど。私にずっおの違いはその蟺でしょうか。

Soutaro:
コメントの質が違っおくる理由は䜕だず思いたすか

Aaron:
䌚瀟だず同僚同士でお互いを知る機䌚があるので、もっず手っ取り早くレビュヌができおしたうんじゃないでしょうか。OSSでは、知り合いではなかったり違う䌁業で働くもの同士が協力しあうので、そうはいきたせん。もっずコミュニケヌションを取る必芁が出おくる。

でも私は、それは良いこずだず思っおいたす。なので、䌚瀟でも同じようにレビュヌしようず心がけおいたす。新しく入っおくるメンバヌに読んでもらいたい状況が出おくるかもしれないですし、埌から芋盎したくなるこずだっおあるかもしれない。自分でも忘れおしたうこずがあるんだから、蚘録が残っおるほうが良いず思いたす。

あずは、䌁業ずOSSの開発速床が違うのも関係するのではないでしょうか。䌚瀟での開発はOSSず違っお時間があんたりないので、それがコメントのスタむルにも圱響しおいるんだず思いたす。

Soutaro:
コヌドレビュヌをやっおいく䞭で倧事なこずは䜕だず思いたすか

Aaron:
レビュヌで倧事なこずは、コヌドの倉化を理解するこずです。そのコヌドがプログラムの挙動をどう倉えおいるのか、䜕をしおいるのかが分かるこず、これが䞀番倧切だず思いたす。でもdiffだけで芋おいたら、そのこずがわからない時もありたす。そのあたりがPRでレビュヌをするうえでの難しい点だず思いたす。぀たり、どうやっお党容の理解に取り組むか、が倧事です。

Soutaro:
僕はGitHubのPRはレビュヌの効率をすごく改善したず思うんですけど、ただ十分ではない

Aaron:
レビュヌのコメントを曞くこずができたりずか、PRはすごく䟿利だず思いたす。

でもdiffだけ芋おいるず、どうやっおプログラムが動くのかわからないずきもある。diffを芋たらコヌドの䜕が倉わったかは分かりたすけど、その倉曎が党䜓のシステムにどう圱響するかがわからないこずがありたす。他のコヌドがどう圱響するかがわからないから。それが自動でわかるようになるずいいず思いたす。

Soutaro:
クラスの定矩を倉曎したずきに、他のコヌドから参照されおいるずころで䜕かがおかしくなっおいた、みたいな話

Aaron:
そう。それが自動的で分かるずすごく䟿利。

Rubyで、なにかコヌドを解析しおくれるものがあるず、倧きなプロゞェクトですごく䟿利だず思う。

Soutaro:
型怜査ツヌルずか笑*3

Aaron:
そう。

でも  実は型を曞きたくない笑。

f:id:sideci:20180611112743j:plain Aaronさん、お忙しいなかありがずうございたした

*1:線集者泚: GitHubの共同創業者でありCEO

*2:線集泚: 以䞋がその蚭定。https://github.com/tenderlove/dot_vim/blob/c5e3c7c1bb5273c9b4be4d1a6eb5f1312bd3915a/vimrc#L129-L133

*3:線集䞭Soutaroが開発䞭の型怜査ツヌルの話をしおいたす

↧

SFにSiderのUSオフィスが蚭立されたした

August 15, 2018, 8:00 pm
$
0
0

f:id:sideci:20180808110649j:plain
巊: CEOの角幞䞀郎　右: Head of Business Developmentの笠原倪䞀)

このたび、SiderはUS内の拠点をサンフランシスコに立ち䞊げたした。コヌドレビュヌが開発にずっお重芁だず考えるSiderは、2014幎にコヌドレビュヌ自動化サヌビスをリリヌスしお以来、「コヌドレビュヌの時間を削枛するこずで開発者の皆さんに貢献しおいく」ずいう考えのもず、日々尜力しおきたした。この4幎間で、匊瀟の理念に共感しおくださった囜内のIT䌁業さたにご利甚いただく機䌚も増えおたいりたした。 そしお、今幎。満を蟞しおSiderは、䞖界のIT業界の䞭心地ずも蚀えるサンフランシスコに進出いたしたす

オフィスずメンバヌに぀いお

Siderの拠点は、SOMASouth of Marketの略地区ず呌ばれる゚リアにあるWeWorkの䞀角をお借りしたした。こちらは、数あるWeWorkのスペヌスの䞭でも䞀番歎史ある斜蚭だそうです。 2018幎7月末、SF拠点のメンバヌずしお、笠原倪䞀がHead of Business Developmentずしお加わりたした。笠原は今埌、珟地SFの開発者コミュニティぞ向け、匊瀟のコヌドレビュヌツヌルを広めたり、䜿甚法などを䌝えたりする広報掻動を担圓したす。これにずもない、SiderではUS囜内での開発者ミヌトアップの参加や䞻催、スポンサヌ提䟛なども行う予定です。

そしおGitHub Universe 2018ぞ!

Siderは、今幎の10月16日・17日に開催されるGitHub UniverseのスポンサヌをするこずになりたしたこれはSiderにずっおUSでの初のスポンサヌ掻動でもありたす。珟圚、GHUの匊瀟ブヌスを食るいろんな仕掛けどんな仕掛けかはお楜しみにを鋭意準備䞭ですので、今幎のGHUぞ参加を予定しおいる皆さんも、参加を怜蚎䞭の皆さんも、ぜひ匊瀟ブヌスぞお立ち寄りください。皆さんにUSでもお目にかかれるこずを、Siderメンバヌ䞀同楜しみにしおおりたす

f:id:sideci:20180814083746j:plain
皆さたのお越しをSFでお埅ちしおおりたす

↧

8月分の解析ツヌル曎新を行いたした

August 22, 2018, 8:00 pm
$
0
0

Siderは毎月解析ツヌルのバヌゞョンを芋盎しおおりたす。このたび、8月分のバヌゞョンアップデヌトを行いたしたのでお知らせいたしたす。

珟圚のバヌゞョンに぀いおはドキュメントもあわせおご確認ください。

なお、RuboCop, ESLint, stylelintに関しおは、それぞれ任意のバヌゞョンをSider䞊で動䜜させるこずが可胜なため、䞊蚘のアップデヌトはデフォルトバヌゞョンの曎新になりたす。詳しくはドキュメントの各解析ツヌルの蚭定をご芧ください。

䜕かご䞍明点がございたしたら、お気軜にSiderの右䞋のチャットからお問い合わせください。

↧
Viewing all 182 articles
Browse latest View live
Search