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

Sider からハッピー・ホリデイズ！

December 19, 2018, 7:00 pm
$
0
0

f:id:sideci:20181112180325p:plain

忘年会などの季節の集まりに大忙しの方も、年末進行に追われて12月のパーティムードを楽しむどころではない頑張りやさんの方も、皆様が素晴らしい年を迎えられますように！ Siderのコンテンツチームも翌週より冬休みをいただき、1月の第二週、1月10日より新年の投稿を開始いたします。新年のテックブログ第一弾は1月17日に投稿予定ですので、ぜひ来年もお付き合いください。

良いお年を！ Sider

あなたのチームの開発効率向上に！
Siderの自動コードレビューを14日間の無料トライアルでお試しください！

↧
Search

Siderより新年のご挨拶

January 2, 2019, 7:00 pm
$
0
0

f:id:sideci:20181112181257p:plain

あけましておめでとうございます。 2019年も皆様にとって沢山の喜びがあふれる年となりますように！

Sider が生まれた日本では、お正月はとても大切な季節行事となっています。 通常のブログ投稿は1月17日ごろ再開する予定ですので、どうぞ今年もお付き合いくださいませ。

さて皆様、今年の干支が亥（＝猪）なのはご存知でしたか？ Siderも弊社のミッション「Better Code Review for Better Products」をさらに実現していけるよう、猪突猛進を続けていきたいと思います。

もし、皆様が新年の目標として開発の効率改善など考えていらっしゃるようでしたら、ぜひSiderにお手伝いさせてください！今年も皆様のコードレビュー、そして開発がより良いものとなるように、お手伝いできればこんなに嬉しいことはございません。

本年もどうぞよろしくお願いいたします。

Happy coding! Sider

あなたのチームの開発効率向上に！
Siderの自動コードレビューを14日間の無料トライアルでお試しください！

↧
↧

パブリックリポジトリの解析結果ページがサインインなしで閲覧できるようになりました

January 10, 2019, 7:16 pm
$
0
0

こんにちは。プロダクトチームの渡邉です。
この度、以前からご要望のあったパブリックリポジトリの解析結果をサインインなしで閲覧する機能を公開しましたので、ご紹介します。

Siderでは、プルリクエスト上で発生した警告を確認し、その重要度に応じて、ユーザーが対応、未対応の選別ができる解析結果画面を提供しています。
従来、リポジトリがパブリックまたはプライベートに関わらず、常にSiderへのサインインまたはサインアップが必要でしたが、リポジトリがパブリックの場合には、サインインなしで解析結果を閲覧することができます。
なお、コメント、クローズなどの操作には引き続きサインインが必要です。

何かお気づきの点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧

PHP向け解析ツールPhinderのご紹介

January 15, 2019, 9:42 pm
$
0
0

Siderでは新しいPHP向け解析ツール「Phinder」の提供を開始しています。PhinderはPHP向けのプロジェクト固有のルールを気軽に追加できるオープンソース解析ツールで、私たちが開発してきたQuerly、Goodcheckなどのツールと同様の哲学に基づいています。

Phinderを使うと、簡単にチーム向けにコードレビューで検査したいルールを追加することができます。チームが必ず従わなくてはいけないルールを自動で検査するLintツールと言うよりは、チームの事情を考慮した上での知識やベストプラクティスの共有を補助することが目的です。Phinderでは、次の様にルールを書くことができます。

gist.github.com

Phinderのルールは patternと messageの組です。PhinderはPHPコードを走査し、 patternにマッチするコードを発見したときに messageを表示します。

f:id:soutaro:20190111155546g:plain

ルールを定義して、リポジトリに追加し、Siderでチェックして、コードレビューを改善しましょう。

QuerlyやGoodcheckについてご存じの方であれば、Phinderがそれらのツールと全く同じメカニズムに基づいていることがわかるはずです。

プロジェクト固有の知識

「コードレビューをツールで効率化する」という話題になると、私たちは一般的なベストプラクティスに注目しがちです。つまり、その言語とかフレームワークで書かれたプログラムであれば、全てが従うべき、そういう習慣について考えてしまいます。こういった目的には、PHPMDやPHP_CodeSnifferなどのツールが活用できます。これらのツールは、ベストプラクティスに反するコードを自動で検出し、開発者が修正することを助けます。

しかし、プロジェクトが進んでコードベースが大きくなると、このような「一般的なベストプラクティス」よりも「プロジェクト固有の知識」が、コードレビューにおいてより重要になっていきます。プロジェクトの中で提供されているAPIの一部を安全に使うには特別な注意が必要になったりしますし、その状況を他の開発者にもれなく伝えるのはなかなかに苦労します。

f:id:soutaro:20190111160552j:plain
プロジェクトの知識に関する正確で科学的なグラフ

問題は、一般的なLintツールでは、こういったプロジェクトに固有の知識を上手く取り扱うことができないことです（なぜなら、Lintツールはあなたのプロジェクトのために開発されたものではないから）。多くのツールでは、こういった状況のためにプラグインを開発できるようになっていますが、5名程度で開発しているプロジェクトのためにわざわざプラグインを開発するのはなかなか正当化するのが困難です。

Siderは、この問題、つまり「開発チームがチーム内で知識を上手く共有すること」に集中しています。「コードレビュールールブック」とか「レビューチェックリスト」を作るのではなく、Phinderにルールを追加しましょう。Phinderは、自動で検査してくれます。

使い方の例

Phinderをどのように活用すれば良いのか、いくつかの例を示します。ここに書かれているルールはあくまで例であり、パターンやメッセージは個々のプロジェクト向けにカスタマイズが必要です。

秘密情報の取り扱いに関する警告

Userクラスに oauthToken()メソッドが定義されているとします。このメソッドはユーザーのOAuthトークンを返します。トークンは秘密情報なので、ログに書き出されたりしないように特別な注意が必要です。oauthToken()メソッドの呼び出しを見つけたときに、警告を出してみましょう。

gist.github.com

Phinderルールの _は任意のPHPの式にマッチします。このパターンは $user->oauthToken()や $this->currentUser()->oauthToken()にマッチしますが、 oauthToken()関数の呼び出しにはマッチしません。

過去に発生した障害の参照

過去に、 PostCategory::import_records(associations)メソッドの呼び出しによって、サービス障害が発生したとします。このメソッドは、複数のレコードをバルクインサートするため個々のレコードを一つずつINSERTするよりも高速ですが、デッドロックを引き起こすことがあり、過去にサービスが停止する障害を引き起こしたことがありました。このメソッドが必要になることはありますが、呼び出すときには開発者・レビュアーは障害に関するレポートを確認して、障害が再度発生することがないようにしたいです。

gist.github.com

おそらくここでは「関連するレコードについてロックが取られているか」「ソートされているか」「タイムアウトなどは適切か」などの事前条件が必要となりますが、このような事前条件をツールによって自動で検査するのは困難です。Phinderは、それを諦めてしまい、単に開発者・レビュアーに注意喚起をします。現実的には「単にチェックするのを忘れていた」ことによって問題は発生するので、このくらいでも役に立ちます。

新しいAPIのアナウンス

Postテーブルのレコードを取得するための新しいAPIを追加したとしましょう。この新しいAPIでは、関連する tagsと authorsを自動で同時に取得します。既存の古いAPIの呼び出しを一気に置き換えてしまえるなら話は簡単なのですが、一部では tagsを取得しないAPIが欲しかったりするので、簡単ではありません。こういう状況では、Phinderを使って新しいAPIの存在をアナウンスしていきましょう。このルールでは、ORMネイティブのAPIを使ってPostを取得しているコードを発見したときに、新しいUsers::posts()を使うようにメッセージを出します。

gist.github.com

このルールには justificationsというフィールドを含めています。このメッセージを無視してもかまわない状況、つまりUser::posts()を使うことができない状況について、説明を追加することができます。

Phinderを使うには

一番簡単な方法はSiderを使ってみることですが（笑）、Phinderをローカルでインストールして試してみることもできます。PhinderのWebサイトに説明がありますので、どういう動作になるのか、実際に試すと理解できると思います。

PhinderとSiderを組み合わせて、コードレビューをもっと効率的に進められるようになることを、そしてもっと自信をもってデプロイできるようになることを期待しています。なにか質問やフィードバックがあったら、気軽にお聞かせください。

PHP以外の言語では？

Ruby向けにはQuerly、特定の言語に基づかずに正規表現でルールを書くにはGoodcheckが使えます。Goodcheckは、正規表現ベースなのでPhinderやQuerlyに比べると表現力が弱いのですが、任意のテキストファイルに対して使えて、意外と便利です。

リンク

この記事は英語版Siderブログに公開された記事からの翻訳です。

↧

1月分の解析ツール更新を行いました

January 16, 2019, 7:00 pm
$
0
0

Siderは毎月解析ツールのバージョンを見直しております。このたび、1月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、RuboCop, ESLint, TSLintに関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧
↧

Scoutyさまの導入事例をリリースしました

January 30, 2019, 7:00 pm
$
0
0

この度、Siderの導入事例ページに新しく、株式会社scoutyさまの導入事例が追加されました。人工知能によりインターネット上のオープンデータから情報を取得し、最適な企業とマッチングする転職サービスを展開していらっしゃるscoutyさまは、JS、Python、CSSによる開発現場で、Siderをご利用になっています。 エンジニアとデザイナの双方がSiderによるきめ細やかな指摘とレビューの効率化を実感し、１プルリクエストあたりの開発効率を上げたというScoutyさまの導入事例には、開発現場での参考になるところも多いかと思います。ぜひご覧ください！

Scoutyさま導入事例ページはこちら
https://sider.review/ja/customer_stories/scouty

あなたのチームの開発効率向上に！
Siderの自動コードレビューを14日間の無料トライアルでお試しください！

↧

RuboCopでより柔軟なgemのインストールをサポートしました

February 12, 2019, 9:17 pm
$
0
0

こんにちは。プロダクトチームの渡邉です。 この度、RuboCopの実行時にサードパーティーのRubyGemsリポジトリやGitリポジトリからのgemインストールをサポートしましたので、ご紹介します。

SiderではRuboCopの実行時にプラグインなどを有効にするために、以下のようにsideci.ymlにインストールするgemを定義することができます。

linter:rubocop:gems:- name:"rubocop"version:"0.63.1"- name:"meowcop"version:"1.17.0"

今回のアップデートでは、上記に加えて、以下の2種類のgemのインストールをサポートしました。

サードパーティーのRubyGemsリポジトリ

sourceオプションを指定することで、https://rubygems.org以外のRubyGemsリポジトリからgemをインストールすることができます。

linter:rubocop:gems:- name:"project-cop"version:"0.63.0"source:"https://gems.example.com"

Gitリポジトリ

gitオプションを指定することで、Gitリポジトリからgemをインストールすることができます。gitオプションは、versionやsourceと一緒に指定できないことに注意してください。

linter:rubocop:gems:- name:"owncop"git:repo:"https://github.com/myname/owncop.git"branch:"master"- name:"project-cop"git:repo:"git@github.com/org/project-cop.git"tag:"v0.63.0"

repoオプションは必須です。その他にbranch, tagまたはrefの中から、どれかひとつを必ず指定する必要があります。詳しくはドキュメントをご覧ください。 また、プライベートリポジトリを指定する場合にはこちらの設定が必要です。

↧

Issueをクローズできる権限を制限できるようになりました

February 18, 2019, 11:33 pm
$
0
0

こんにちは。プロダクトチームの渡邉です。
Siderではプルリクエスト内で発生したIssueに対して「修正しない」または「確認済みである」ことを表明するために、それぞれのIssueをクローズできるようになっています。この機能は、そのリポジトリに対してGitHub上でWrite権限以上を持つすべてのユーザーが利用可能です。リポジトリの権限に関する詳しいドキュメントはこちらをご覧ください。

今回、このクローズできるユーザーを Write権限以上からAdmin権限のみに制限するための設定を追加しました。 本設定を有効にするためには、リポジトリ設定画面から「管理者専用」タブを開き、権限の制限を有効化してください（この操作には該当のリポジトリに対してAdmin権限が必要です）。

f:id:sideci:20190219162329p:plain

設定を有効にすると、Write権限のユーザーには以下のようにクローズボタンが無効な状態で表示されます。

f:id:sideci:20190219162353p:plain

詳しくはこちらのドキュメントも併せてお読みください。

↧
Search

2019年2月分の解析ツール更新を行いました

February 19, 2019, 7:00 pm
$
0
0

Siderは毎月解析ツールのバージョンを見直しております。このたび、2月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、RuboCop, ESLint, stylelintに関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧
↧

旧料金プランの廃止及び新料金プランへの変更を2019年4月1日に実施します

February 27, 2019, 6:00 pm
$
0
0

こんにちは。いつもSiderをご利用いただきありがとうございます。

2018年5月1日にリポジトリ登録数が無制限になる、シート単位の料金体系をリリースさせていただき、リポジトリ単位の料金プランを廃止（Deprecate）させていただきました。
それから約1年の猶予期間を経た2019年4月1日に、旧料金プランをお使いの方の課金体系を現料金プラン(シート単位)へ変更いたします。
※プラン変更対象となるお客様には既に個別にご連絡しておりますが、改めてこの場でもアナウンスいたします。

この変更処理は4月1日に自動的に実行されます。その際に、ご契約いただいているオーガニゼーションに所属しSiderに登録しているユーザ様全員に対しシートが割り当てられます。そのため、ご契約シート数はSider登録済ユーザー数となりますのでご了承ください。

これにはSiderに登録したが使っていない方が含まれる可能性があります。実際にSiderに必要な方のライセンス数の購入とライセンス（シート）の割当てを新料金プラン移行と併せて行っていただくことを推奨いたします。お手数をおかけし申し訳ございません。

ご不明な点等ございましたら sales@sider.reviewまでお問い合わせください。

今後も、Siderではお客様への一層のサービス向上に取り組んでまいりますので、何卒ご理解のほどお願い申し上げます。

参考:

アナウンスとしては以上になります。 変更手続きの手順を下記に記載いたします。

切替手順

  1. お使いの「オーガニゼーション設定画面」から「アカウントと支払い」を選択してください。
    「現在のプラン」の右にある「更新」を選択してください。 f:id:sideci:20190228093957p:plain

  2. 旧価格プランをキャンセルして、新価格プランを申し込みを開始するメッセージが表示されますので、「続ける」を選択してください。 f:id:sideci:20190228095024p:plain

  3. ご利用頂くseat数を入力し、「次へ」を選択してください。 f:id:sideci:20190228094021p:plain

  4. 変更内容の最終確認画面が表示されます。クレジットカードは現在ご登録のものがそのまま継続されます。よろしければ、「変更」を選択してください。こちらで変更処理は完了です。

f:id:sideci:20190228094211p:plain

↧

シート未割り当てユーザーによるSiderの利用について

March 3, 2019, 8:51 pm
$
0
0

Siderでは、「プライベートリポジトリの解析が必要な場合には、Siderを使用する開発者人数分のシートをご購入いただき、開発者にシートを割り当てた上でPull Requestを解析する」というモデルでサービスを運営してきました。しかし、シート未割り当てである開発者についても「Pull Requestの解析ができてしまう」という問題があり、修正をしましたのでアナウンスします。

プライベートリポジトリについて、シートの割り当てがない開発者には次の制限が課されます。

  1. シートが割り当てられていない開発者がオープンしたPull Requestは解析されない
  2. シートが割り当てられていない開発者は解析結果画面にアクセスできない

（これまでは、2については実装がされていましたが、1の制限については実装されていませんでした。）

Siderでの解析を必要とされる開発者については、人数分のシートを購入し割り当てを設定してください。（Siderでの解析が必要ない場合には、シートの割り当ては不要です。）

GitHubの設定でRequired status checksを設定されている場合、Siderでの解析がされないケースで、status check待ちの状態が続いてしまうことがあります。GitHubのリポジトリ設定をご確認ください。

↧

解析をスキップするブランチ名のパターンに正規表現をサポートしました

March 4, 2019, 8:29 pm
$
0
0

こんにちは。プロダクトチームの渡邉です。 Siderでは、特定のブランチの解析をスキップするために、sideci.ymlで解析対象から除外するブランチ名を指定することができます。 今回、このブランチ名のパターンとして正規表現をサポートしましたので、ご紹介します。

例えば、リリースブランチにrelease-#{release_date}のような命名規則を設けており、これらのブランチの解析を行いたくない場合には、以下のように書くことができます。

linter: # ...branches:exclude:- /^release-.*$/

詳細はドキュメントをご覧ください。

↧

SiderのSlack通知の範囲を設定できるようになりました。

March 14, 2019, 8:00 pm
$
0
0

Siderをご利用いただきありがとうございます。SiderのSlack通知において、通知範囲を設定できるようになったのでお知らせいたします。

Siderは、Slack連携に対応しており、Webhookを適切に設定することで、解析完了時に、登録したSlackチャンネルに通知を行う機能があります。 これは、すべての解析結果に対して通知を送る機能です。しかし、開発者の人数が多く頻繁にプルリクエストを開くチームの場合、Slackに多くの通知をしてしまい、本当に受け取りたい通知やメッセージが埋もれてしまうという問題がありました。

そこで、この度Slack通知を制御する機能を追加いたしました。

通知設定
Slack連携設定

通知の範囲設定は、

  • 常に通知
  • エラー時のみ通知

の2種類があります。「常に通知」を選んだ場合、Siderはこれまで通りすべての解析結果についてSlackへ通知します。「エラー時のみ通知」を選んだ場合、解析が成功し、かつissueが1件も見つからなかった場合には通知を行いません。検出したissueが1件以上ある場合か、何らかの理由により解析が途中で失敗した場合のみ通知するようになります。

また、こちらのドキュメントも併せてご覧ください。

この機能について、何かご不明な点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧
↧

2019年3月度の解析ツール更新を行いました

March 18, 2019, 8:00 pm
$
0
0

Siderは毎月解析ツールのバージョンを見直しております。このたび、3月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、RuboCop, ESLint, TSLintに関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧

2019年4月度の解析ツール更新を行いました

April 17, 2019, 8:00 pm
$
0
0

Siderは毎月解析ツールのバージョンを見直しております。このたび、4月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、Ruby gems（RuboCop, Reekなど）およびnpmパッケージ(ESLint, TSLint, stylelint)に関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧
Search

Siderでプロジェクトの知識をチームに広げる

May 13, 2019, 7:07 pm
$
0
0

Siderでサポートしているツールのうちの三つ、QuerlyとPhinder、GoodcheckはSider自身が開発しているものです。*1*2

f:id:soutaro:20190510231121p:plain

これらのツールは

特定のテキストのパターンを発見したときに、なんらかのメッセージを表示する

という動作をします。とても単純な機能ですが、これをどう使えば良いのでしょうか？

チームの知識、経験、歴史

ちょっと一般的な話をしましょう。

コードレビューには「問題があるコードを見つけて修正を促す」という品質に対する効果もありますが、それよりも実際に高く期待されているのは「チームの情報共有を進める」という効果だと言われています。「チームに長くいる人が、過去にチームで発見されたベストプラクティスについて伝える」「以前発生した障害のことを覚えている人が、新しく書かれたコードに似たパターンを見つける」「既に定義されているSASSのmixinについて教えてあげる」こういった、チーム内での知識共有を通して、チームは成長していきます。

一番良いのは開発者同士でレビューして知識を伝えていくことですが、これを多少なりとも自動でやるにはどうしたらいいでしょうか？

Linterでやることもできなくはありません。Linterが提供している組み込みのルールはあなたのチームについての知識を持っていないので、プラグインに相当する仕組みでルールを追加する必要があります。まあ面倒ですよね……一般的なLinterのルールは、それなりに複雑なので、普通のプラグインの仕組みは結構複雑なルールを書けるようになっています。つまり開発のコストが大きすぎる。

「これはチーム全体で知っておいて欲しいことだ！」となにかを思いついた直後に、3分くらいで実装できないといけませんが、プラグインでは困難です。本当はルールを手動で書くこともしたくないのですが、人間のコミュニケーションから自動的に抽出するというのはあまりに難しいのでひとまず諦めましょう。そもそもGitHubとかSlackとかに完全にコミュニケーションが乗っているわけでもないので、まあ無理です。

その辺りをSiderチームで詳細に検討した結果、「パターンにマッチしたメッセージを表示する」くらいのメカニズムが適当なのではないかな、ということになりました。説明に戻ります。

カスタムルール

Siderでは、これを「カスタムルール」と呼んで、自分でルールを追加・定義できるLinterとして活用することを提案しています。プロジェクト内で定義されたAPIについてなんらかの注意事項を表示したり、言葉の利用方法についてレビューで注意したり、オペレーションの手順を表示したりできます。

rules:- id: yield_self
    pattern:"yield_self() {}"message: yield_selfではなくthenを使いましょう

これはQuerlyの例ですが、yield_self() {}というテキストでパターンを定義し、yield_selfメソッドの呼び出しを検出することができます。この例では「yield_selfではなくthenを使いましょう」と言っていますが、逆もできます。yield_selfというメソッドの呼び出しが本当に Kernel#yield_selfなのかは、微妙なところですが、その辺りは引数の数とかでアタリを付けます。

引数の数以外（レシーバも条件にはできますが）で、メソッド呼び出しを特定することはできないというのがポイントです。このくらいなら、パターンの構文を覚えればすぐに書けるようになるし、書きたいものは大体書けます。（「大体」は言い過ぎかもしれませんが、まあ意外と書けます。）ここでは書いていませんが、パターンをユニットテストする仕組みも用意していますので、

  1. チェックしたいことを考える
  2. パターンを考える
  3. テストを書く

まで、YAMLファイルを少し編集すれば書けるようになるのです。

また、多少一般的な感じのルールは、Twitterで紹介しています。「実際にどんなルールを書いたら良いのか？？」と悩んだときにご覧ください。

誤検出について

Querlyなどの紹介をしたときに必ず聞かれるのは「誤検出があるのではないか？」ということですが、これについては「そういうもんですが、まあトータルで見たときには利益の方が大きいのでは」というのが私たちの回答になります。

まず、誤検出を減らすことがあまりできない設計になっているのは、意図的なものです。誤検出を減らすためには、高度なプラグラミングが必要になります。簡単に言うと、パターンの正確さと定義のための労力にはけっこうな関連があります。Siderでは、「あんまり深く考えないでルールをたくさん作ってもらう方が利益が大きい」という戦略を採用しています。

誤って検出されたメッセージについては、「Siderからクローズする」という運用を提案しています。Siderでは、

  • GitHubのPull Requestで変更したところに関連するメッセージしか表示しない
  • 不要なメッセージを気軽に「クローズ（無視）」できるようにする

という工夫があり、誤検出に負けないユーザー体験を提供しています。

逆に言えば、Sider以外でこれらのツールを使おうと思ったときには、残念ながら少し厳しい体験になるはずです。例えば、手元の開発環境でエディタでソースコードを編集している最中に実行しようとすると、「Pull Requestの情報がないので、全部のコードに関する問題を表示する必要があり、誤検出が多すぎて厳しい」ことになるでしょう。*3

極端なことを言えば、「パターンにマッチしたメッセージを表示する」というのはおまけで、「リポジトリにチームの知識が明文化されて残っていく」ということがより重要です。

まとめ

Siderでは、コードレビューの大きな目的の一つである「チーム内の知識共有」について注目し、製品の開発を行っています。通常のLinterが検査する一般的なルールだけではなく、チームの知識をルールとして簡単に記述できるツールを開発しています。Siderを使って、チームの知識をファイルに書き、自動的に共有していきましょう。

リファレンス

*1:実はQuerlyは id:soutaroが開発しているものですが。

*2:俺がSiderだ。

*3:というのも少し雑な説明で、reviewdogとかprontoとかを使えば、それなりに戦うことができる気はします。

↧

2019年5月度の解析ツール更新を行いました

May 16, 2019, 8:00 pm
$
0
0

Siderは毎月解析ツールのバージョンを見直しております。このたび、5月分のバージョンアップデートを行いましたのでお知らせいたします。

Siderは毎月解析ツールのバージョンを見直しております。このたび、5月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、Ruby gems（RuboCop, Reekなど）およびnpmパッケージ(ESLint, TSLint, stylelint)に関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧
↧

解析結果画面で、目的のIssueを絞り込めるようになりました

June 10, 2019, 7:00 pm
$
0
0

解析結果画面でIssueをさまざまな条件で検索・絞り込みが行えるようになりました。 この機能では、解析ツール名やルールIDでIssueを絞り込める他、ディレクトリツリーからの絞り込みも行うことができます。

解析結果画面で表示されているIssue件数が多い時、フィルタリング機能を使うことで表示件数を減らし、Siderを利用したレビューをより行いやすくします。

Issue検索機能

f:id:a_ksi19:20190610171205p:plain

この機能は解析結果画面の「高度な検索」から利用することができ、ツール名やルールIDを選択することでIssueを絞り込みます。 絞り込み時に検索モーダルから表示されていないルールIDなどは、テキストエリアに入力することで絞り込むことも可能です。

f:id:a_ksi19:20190610171316p:plain

ディレクトリツリー

ディレクトリツリーは解析結果画面左側にあるトグルボタンから開くことができます。ディレクトリツリーに表示されるのは、Siderが報告したIssueがあるファイルに限られ、目的のファイルやディレクトリを選択することでIssueを絞り込むことができます。

f:id:a_ksi19:20190610171343p:plain

今回の機能やその他Siderの機能やUXについて、お気づきの点やご要望がありましたらSiderプロダクトチームにお知らせください！

↧

2019年6月度の解析ツール更新を行いました

June 18, 2019, 7:00 pm
$
0
0

Siderは毎月解析ツールのバージョンを見直しております。このたび、6月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、Ruby gems（RuboCop, Reekなど）およびnpmパッケージ(ESLint, TSLint, stylelint)に関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧

2019年7月度の解析ツール更新を行いました

July 21, 2019, 7:00 pm
$
0
0

Siderは毎月解析ツールのバージョンを見直しております。このたび、7月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、Ruby gems（RuboCop, Reekなど）およびnpmパッケージ(ESLint, TSLint, stylelint)に関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

↧
Viewing all 182 articles
Browse latest View live
Search