プチ技術メモ

技術系の情報を中心に適当に書いています

GitLab Meetup Tokyo #5で発表してきました

先週の金曜日に開催されたGitLab Meetup Tokyo #5で、「GitLabへのコントリビュート」というお題で発表してきました。

docs.google.com

ちなみに、今年の三月に開催されたGitLab Meetup Tokyo #1でも発表していて、その時のお題は「GitLabコミュニティへのコントリビュート」でした。

docs.google.com

とりあえず伝えたかったことは、GitLabは最高なのでみんなもコントリビュートしようぜってことです。

それと、12月13日にGitLabの中の人を呼んで都内でイベントを開催するらしいので、興味のある人は行ってみてはいかがでしょうか?私は、GitLabを口実に2ヶ月連続で東京に出張するはさすがに気が引けるので我慢しておきます。

connpass.com

【PR】GitLab 10.0のMVPに選ばれました

この度、GitLab 10.0のMVPに選ばれました。なお、GitLab 5.1の時もMVPに選ばれたので、今回で二回目の受賞となります。 この機会にGitLabのMVPについて少し詳しく解説します。

GitLabとは何か?

GitLabは、GitLab社により開発されているプロジェクト管理とGitリポジトリ管理のためのアプリケーションですが、近年はCI/CD機能などソフトウェア開発に必要な様々な機能の統合が進められています。

最新の10.0では、ベータ版ではありますが、ソフトウェアのアイディアを実装し、本番環境にデプロイして、モニタリングするまでの流れを自動化する”Auto DevOps”機能がリリースされています。興味のある方は、10.0のリリースページのデモ動画を見るとイメージがつかめるので、視聴をオススメします。

GitLabについてより詳しく知りたい場合は、私が寄稿した「GitLabのこれまでとこれから」も参照して頂ければと思います。なお、記事中に記載されている「GitHost.io」ですが現在は新規の受付を停止しているのでご注意下さい。

MVPとは何か?

GitLabは、初期の頃から毎月22日に新バージョンをリリースするというサイクルを守っています。

MVPは、2013年3月22日にリリースされたバージョン5.0から開始された、新バージョンのリリースに最も貢献したコミュニティメンバー(GitLab社の社員を除く)を表彰する制度です。基本的には、毎月一人がMVPに選ばれますが、複数人の貢献に甲乙をつけがたい場合などは複数人のMVPが選ばれることもあるようです。

MVPの報奨が気になる方もいるかと思いますが、賞品や賞金などの直接的なものはありません。基本的には、GitLabの公式ブログMVP受賞者履歴のページに名前が載るという二点となります。

貢献とは何か?

GitLabに貢献すると言われても、ピンと来ない人もいると思います。主な例を挙げると以下のような貢献方法があります。

上記の貢献方法以外にもGitLabの不具合の報告や改善案の提案なども、貢献方法の一つですが、それだけではMVPに選ばれることは無いようです。 実際にGitLabに貢献を行う際は、詳細なガイドライン(英語)があるので、最初にそちらを確認することを推奨します。

役立つスキル/知識

GitLabへの貢献に役立つ主なスキルや知識を紹介します。

Ruby on Rails

GitLabは一部を除いてモノリスRailsアプリケーションとして開発されているので、Railsの知識はほぼ必須です。

ES2015

GitLabのフロントエンドのJavaScriptはES2015で書かれています。フロントエンドの修正には、ほぼ必須の知識です。また、Issue Boardなど一部の機能ではVue.jsが使用されているので、Vue.jsの知識があると役に立ちます。

Go

GitLabでパフォーマンスが必要な一部の機能はマイクロサービス化されて、Goで書かれています。また、GitLab CIの実行環境にインストールするGitLab RunnerもGoで書かれています。

Git

Gitの使い方以外にも、Pro GitGitの内側に書かれているようなGitの内部構造に関する知識があると役に立ちます。

貢献対象の見つけ方

GitLabに貢献しようと思っても、最初は何をすれば良いか分からないと思います。そこで、簡単な貢献対象の見つけ方を紹介します。

GitLabの開発に関する課題(不具合や要望など)は全て公開されているので、その中から自分が興味のあるものを見つけて取り組むのが良いです。ただし、GitLabには膨大な件数の課題が登録されているので、その中から取り組むべき課題を見つけるのも大変な作業です。

そこで役に立つのが、ラベルでの絞り込みと人気順での並べ替えです。GitLabではコミュニティからの貢献を期待している課題に対して”Accepting Merge Requests”とラベル付けされています。また、GitLabには課題に対して人気投票する機能があり、人気順に課題を並べ替えることができます。

とりあえず、コミュニティからの貢献が期待されていて、人気の高い課題を確認したい場合はこちらのリンクを利用して下さい。

必要な英語力

GitLabに貢献する際のやり取りは英語でする必要がありますが、英語を母語としない国からの貢献も積極的に取り入れる方針のため、英語に自信が無くてもあまり心配する必要はありません。間違った英語でも、大抵の場合は向こうが察してくれます。

私も英語には自信がありませんが、高校レベルの英語とGoogle翻訳Weblioを駆使して何とかなっています。

宣伝

私が管理者を務めているGitLab.JPでは、GitLabに関するイベントを不定期に開催しています。また、GitLab日本コミュニティのSlackもあるので興味のある方は是非ご参加下さい。

私が所属する(株)Ruby開発では、GitLabのサポートサービスの提供を開始しました。詳細は会社ホームページよりお問い合わせ下さい。

GitLabにコントリビュートすると一流エンジニアからRailsのコードレビューをしてもらえる話

昨晩開催された「Rails Developers Meetup #4 リモート会場 - connpass」の『プロを目指すRailsエンジニアのための公開コードレビュー』をYouTubeで視聴していて、一流エンジニアからRailsのコードレビューをしてもらえるエンジニアはあまり多くはないんだろうなと感じました。

なぜなら、過去にきちんとRailsのコードレビューを受けたことがあれば、発表で取り上げられたような読みにくいコードは書かないはずだからです。 一流のエンジニアからコードレビューを受けることで、エンジニアとしてのスキルを飛躍的に高めることが出来ます。 しかし、そのような機会に恵まれるかどうかは、入社した会社の同じチームに優秀なエンジニアが在籍しているかどうかによるところが大きいと思います。

そこで、不幸にも会社の同じチームに優秀なRailsエンジニアがいなかった場合は、「GitLab.org / GitLab Community Edition · GitLab」にコントリビュートすることをオススメします。

GitLabはOSSのGitのホスティングツールとして有名ですが、メインはRailsで作られています。 現在、GitLabはGitLab社によって開発が行われていますが、元々は共同創業者であり現CTOのDmitriy Zaporozhets氏がはじめたOSSの個人プロジェクトでした。 そのような経緯もあり、GitLab社はコミュニティーからのコントリビュートを非常に重視しています。

そのため、GitLab社には「Merge Request Coach | GitLab」というコミュニティーからのマージリクエスト(=プルリクエスト)のコードレビューを業務として行う社員が複数人います。 ちなみにTeam | GitLabを見ると誰が「Merge request coach」なのか分かりますが、Backend Lead | GitLabなどを兼務している上級プログラマーアサインされているようです。 これは、質の悪いコードがマージされてGitLabのメンテンス性と生産速度が低下するのを防止するためではないかと思います。

ちなみに、私が投稿したAdd filter by my reaction (!12962) · Merge Requests · GitLab.org / GitLab Community Edition · GitLabは、コードレビューで大量の指摘を受けていますが、どうすればメンテンス性の高い綺麗なコードを書けるのか非常に参考になります。 なお、解決済みの指摘事項はデフォルトで折りたたまれて表示されますが、「Toggle discussion」をクリックすると表示することが出来ます。

なお、DBのパフォーマンスに関わるマージリクエスImprove AutocompleteController#users.json performance (!13754) · Merge Requests · GitLab.org / GitLab Community Edition · GitLabGitLab.comのデータベース障害から学ぶ — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or somethingで有名になったDatabase (removal) SpecialistのYorick Peterse (@YorickPeterse) | Twitter からコードレビューとパフォーマンスレビューをしてもらえます。

私は英語が苦手なので英語でのやり取りは大変だと感じていますが、アバウトな英語でも何とかなっています。 また、英語が苦手でコントリビュートの障害となっている場合はJoin gitlab-jp on Slack!の#devチャンネルで質問すれば、日本語でサポートして貰えると思います。

ちなみに来月は、GitLab 10.0という大きめのリリースが予定されているために、GitLab社のリソースが不足しているようです。 そのため、普段よりマージリクエストへのレスポンスが悪くなっているようですが、無視されることは無いと思うので気長に待つと良いです。

東北大学でGitとGitLabの講習会の講師をしてきました

昨年の11月頃にGitLabのイベントで知り合った東北大学の教員の方に、大学での教育や研究にGitLabを活用できないか相談したところ、ありがたいことに大学でのGitLabの利用にご理解を頂くことが出来ました。

まずは、学生と教職員の方からGitとGitLabの有用性を認知してもらう必要があるため、初心者向けのGitとGitLabの講習会を開催しようとの流れになり、その講師を引き受けさせて頂きました。

初心者向けの講習会ということでしたので、まずはSourceTreeでGitの基本的な操作方法の説明を行ったあとに、GitLabを使用して卒業研究を行うワークフローの説明をしました。3時間と限られた時間の上、私の説明もいまいちだったので、参加者の方にGitLabの良さを十分に伝えることができたのかあまり自信はありませんが、講習会を開催できて本当に良かったと思います。

今回の講習会のために、東北大学教育情報基盤センターにおいてGitLabサー バーとCI用のDocker Runnerを用意して頂くことができました。このサーバーは講習会に参加していなくても、東北大学の学生と教職員の全員が利用可能です。なお、GitLabの利用者が増えないと、最悪の場合はサーバーの閉鎖もあり得るとのことでしたので、東北大学の学生と教職員の方には積極的に活用して頂きたいです。 また、次の機会があればGitLab Pagesで大学の研究室のウェブサイトを管理する方法とかの話をしたいと考えています。

gitlab.cite.tohoku.ac.jp

それと、役に立つのかは分かりませんが、講習会で使用した資料のリンクも貼っておきます。よろしければ、初心者向けのGitとGitLabの教育資料にご利用ください。

docs.google.com

久しぶりにGitLabにコントリビュートしました

GitLab 8.14がリリースされましたが、久しぶりにコントリビュートしたので修正内容を紹介します。

Merge RequestのChangesのdiffの先頭の余分なスペースを削除しました。 Changesのdiffをコピー&ペーストするのが少しだけ楽になります。

Networkグラフで存在しないリビジョンを検索すると、404ページに飛ばされる不具合を修正しました。 リビジョンの検索は私が実装した機能なのですが、不具合のIssueがオープンされたままだったので対応しました。

Wikiの編集中に表示される右上の「Edit」ボタンを削除しました。 Wikiの編集後に間違って右上の「Edit」ボタンを押してしまって編集内容が失われる悲劇が少しは減ると思います。

なお、CHANGELOGの衝突問題を改善するため、今回のリリースよりCHANGELOGのエントリー毎にファイルを作成するように運用が変わりました。 以下のページの「Generate a changelog entry with bin/changelog」が参考になると思います。

久しぶりにGitLabにコントリビュートしました

前の記事 では毎月1コミットをノルマにと意気込んでいましたが、その後は全くコントリビュートしていませんでした。モチベーションの維持は思ったよりも難しいので、今後は気が向いた時にコミットして行きたいと思います。

今回私が行った修正は以下の3つです。

特にWikiページの日本語対応について、GitLab 8.4でWikiのページ名に日本語を使用できるようになった(※使用可能な文字の制限を緩くした)のですが、日本語を使用すると500エラーとなる上に、それ以降は日本語を含まないページを編集しても500エラーが発生するためにWikiの更新ができなくなります。そのような現象に困っている方は8.6にアップデートすると良いと思います。

それと、久しぶりにGitLabにMRを投稿して気がついたのですが、最近はMRがマージされるまでに最低でもGitLabのコアメンバーが2人でレビューするルールのようです。英語のコメントの言い回しがおかしかったりすると指摘してもらえるので、色々と勉強になります。 ちなみに、以前はGitLabの初期開発者&現CTOの@dzaporozhets氏が1人で全てのMRをレビューしてマージしていた気がしますが、レビューの負荷分散をしないと回らない規模になったのだと思います。

余談ですが、GitLabは毎月22日に新バージョンがリリースされますが、急いでアップデートすると思わぬ地雷を踏む可能性があるので、毎月1日まで待ってからGitLabのIssueで致命的な問題が無いことを確認してからアップデートしています。

その他のGitLab 8.6での変更点については以下の公式ブログを参考にして下さい。

GitLabへのコントリビュートを再開しました

前置き

2012年12月頃、前職の会社でGitLabを使って仕事をしていました。 しかし、network graphの出来があまり良くないと不満があったため、色々と修正をしてはGitHubプルリクを送っていました。

その頃は大体、月に5個くらいプルリクを送っていて、その功績が評価されて2013年4月にはGitLab 5.1のMVPに選ばれました

その後

GitLabのMVPがきっかけなのか、ITベンチャー企業からスカウトメールが届いたのを契機に、ベンチャー企業への転職熱が高まり、2013年11月にバイオベンチャー企業に転職しました。

その当時、個人的な関心としてはLinuxOSSを活用した開発をやりたかったのですが、転職前の会社はいわゆるSIer的な会社だったため、残念ながら仕事の中でその欲求を満足させることは出来ませんでした。 そのため、趣味として独学でその辺の勉強をしていました。GitLabへのコントリビュートも、その延長線上にあったのだと思います。

しかし、転職後の会社では業務として、かなり自由に技術を選択して開発をすることが可能になってしまいました。 そのため、仕事の中である程度の欲求が満たされてしまったために、GitLabへのコントリビュートが停滞することになりました。

転機

何となくOSSにもっとコントリビュートしないとなーと思っていたことやGitLab 7.12の変更がかなりアツい感じだったこともあり、GitLabへのコントリビュートを再開しようと決めました。

ただし、あまりハードルを上げ過ぎると長続きしないと思うので、毎月のリリース毎に最低1コミットをノルマにして行きたいと思います。とりあえず、先月と今月はなんとかノルマを達成できました。(GitLabのCHANGELOGを"Hiroyuki Sato"で検索すると、7.13.0と7.14.0でそれぞれ一件ずつヒットします。)

お願い

マーリクのネタが欲しいので、不具合やちょっとした機能改善の要望があれば、私のGitLabのForkで報告をお願いします。可能な範囲で対応をする予定です。

それと、私の経験ではGitLabに送ったプルリク/マーリクは9割くらいの割合でマージされているので、OSSにコントリビュートしたいRailsエンジニアは積極的にプルリク/マーリクを送ると良いです。興味のある方はMacにGitLabの開発環境を構築するを参考にして下さい。