TeamCity 2018.2がリリースされました:セカンダリノード、GitHubプルリクエスト、プラグイン作業の改善、テスト結果にスクリーンショットを追加、Kotlin DSL Previewなど

TeamCity 2018.2、今年2回目のメジャーリリースです。 このバージョンでは、VCS変更の収集をセカンダリノードにアウトソース、GitHubプルリクエストをビルド、またはサーバーを再起動せずにプラグインをインストールできます。 テスト結果にスクリーンショットを追加することが可能になり、自動調査の割り当て、複数のNuGetフィードも導入されています。

1200x628_Facebook_バナー_リリース_var

このブログポストでは、本リリースの主な新機能について説明いたします。(サムライズム様による翻訳はこちらになります。)

セカンダリTeamCityノードによるスケーラビリティの向上

セカンダリTeamCityノードは、バージョン管理システムから変更を収集してチェックするタスクを引き継ぐことによって、メインTeamCityサーバーの負荷を下げるように設計されています。 VCS変更の収集をセカンダリノードにアウトソースし、インストール全体のスケーラビリティを向上させることができます。 また、セカンダリノードを使ってHigh-Availability設定(高可用性設定)を行うこともできます。

スクリーンショット 2018-12-05 16.38.46

GitHubプルリクエストをビルド

TeamCityはGitHubプルリクエストのサポートを強化しました。 プルリクエストを作成者別にフィルタリングし、内部または外部の共同作業者に限定、あるいは全員に公開できます。 ターゲットブランチでプルリクエストをフィルタリングするオプションもあります。

プラグインとの作業をもっと簡単に

  • プラグインリポジトリからインストール。 TeamCityのプラグインをJetBrainsプラグインリポジトリから直接閲覧してインストールできるようになりました。
  • サーバーを再起動する必要がなくなりました。 プラグインリポジトリからプラグインをインストールすると、それを適用するためにTeamCityサーバを再起動する必要はなくなりました。
  • 手間のかからないプラグイン開発。 同様に、TeamCity用のプラグインを開発する場合、サーバーを再起動する必要がなくなりました。

テスト結果にスクリーンショットを追加

TeamCity 2018.2では、スクリーンショットや、リンク、アーティファクト、ログ、数値などの他のテストデータをテスト結果に追加することができるようになりました。 これらは、UIのテスト詳細セクションでネイティブに表示されます。

テストメタデータ

Kotlin DSL Preview 設定

Kotlin DSL形式の設定をどのように記述するのが最適なのかわかりませんか? TeamCityはすべての設定用のDSLコードを自動的に生成します。それを管理UIでプレビューすることができるようになりました。 DSLフォーマットの学習や、ただDSLの一部をコピーして既存の settings.kts ファイルにペーストするのに便利です。

調査の自動的な割り当て

TeamCityでは、ヒューリスティックの数に基づいてチームメンバーに調査をサジェスト、または自動的に割り当てることができるようになりました。 そうすれば、ビルドを壊した可能性が最も高い人は、通知を受けて失敗を調査できます。

自動割り当て

複数のNuGetフィード

TeamCity 2018.2では、プロジェクトとそのすべてのサブプロジェクトのビルドで使用される複数のNuGetフィードを指定できます。 また、NuGet Server API v3のサポートも導入されています。

nuget

このリリースではさらに多くの新機能を用意しております! これらの機能やその他の機能の詳細については、当社のドキュメントのWhat’s newセクションをご参照ください。

TeamCity 2018.2をダウンロード

新しいバージョンをインストールする前にアップグレードノートを確認し、バグ・問題があった場合、お気軽にYouTrackでご報告、またはディスカッションフォーラム でご質問ください。

また、2019年1月8日に開催される無料ウェビナーに登録し、LIVEで新機能をご確認ください。

[原文Original post in English is written by Yegor Naumov

Posted in TeamCity, お知らせ | Leave a comment

DataGrip 2018.3リリース!

こんにちは!

DataGrip 2018.3リリースについてのニュースです。 いつものように、このリリースサイクル中にIDEの改善をサポートしていただいたEAP参加者の皆様に感謝申し上げます。 最も積極的にご支援いただいた方々には、感謝の気持ちを込めて、無料でDataGripサブスクリプションを贈呈させていただきました。Rujrn4Rw

このアップデートの詳細な概要を確認したい場合は、当社のWhat’s new ページをご覧ください(サムライズム様による翻訳はこちらです)。このブログポストの続きを読んで、DataGrip 2018.3の拡張機能の全リストをご確認ください。

データベース・オブジェクト

Cassandra データベースサポート
— 選択したオブジェクトのSQLファイルを生成
PostgreSQLextensions サポート
PostgreSQL 11 でのストアドプロシージャ(stored procedure)をサポート
Quick Doc の統計
Use drop cascade syntax オプション

CassSelect

 

コード補完

— Postfix completion
テーブル名を完成する際にエイリアスを自動的に追加する 新しい設定
GROUP BY での非集計フィールド
SELECT、MERGE および INSERT INTO テーブル変数に全てのカラムリスト
— ストアドプロシージャの名前付きパラメータ
SUM() および AVG() の数値フィールド
フィルタリング(WHERE…)
自動生成ON句のオペランドを反転する オプション
— Window 関数

Postfix

コード生成

Live Template 用のdialect
INS Live Template を使用すると、カラム名のヒントが自動的に表示されます
SELECTCREATE TABLEの定義

DialectsPerLiveテンプレート

 

リファクタリング

Introduce table alias インテンションアクション
Extract subquery as CTE アクションの改善

エイリアスを導入

コードインサイト

— 安全でない DELETE および UPDATE に関する警告
— 到達してないコードを検出するための新しいインスペクション
— Unused subquery item(未使用のサブクエリ)インスペクション

実行後に警告を更新

 

接続

— シングル接続モード
— タイムアウト後の自動再接続

検索とナビゲーション

— 新しい Search Everywhere (どこでも検索)
— 複数行のTODO コメント
Find/Replace in Path で複数行検索

どこでも検索

ユーザーインターフェース

ハイコントラスト カラースキーム
ページサイズ 設定用のUI改善
-データソース Properties ダイアログの色設定

ブログ用HC

 

すでにご存知でしょうが・・・
DataGripの30日間体験版をダウンロードできます。
Twitter (英) / Twitter (日)でお待ちしてます!
フォーラムで何でも話しましょう。
— バグがあれば、YouTrackにてご報告ください。

よろしくお願いいたします!

DataGripチーム
_
JetBrains
The Drive to Develop

[原文Original post in English is written by Maksim Sobolevskiy

Posted in DataGrip, お知らせ | Leave a comment

GoLand 2018.3がリリースされました!

blog@2x

このリリースでは Google App Engine、Goコアダンプ、Mozilla rr などのデバッガの新ツール、またはシグネチャの変更(Change Signature)リファクタリングや Testify サポートをお楽しみいただけます。 新しいコードインスペクションとインテンションアクション、コード補完の改善、ダイアグラムのサポート、VCS、Docker、Kubernetesのアップデートなどがあります。

GoLand 2018.3をダウンロード

GIFを含む新機能の説明を確認するには、What’s Newページ (サムライズム様による翻訳はこちらです)をご覧ください。

本リリースのハイライトを簡単に見てみましょう。

リファクタリング

  • 新しい Change Signature リファクタリングを使うと、数回クリックするだけで、関数、メソッド、またはメソッド仕様シグネチャを変更できます。
  • Inline は、適用後にインライン化されたコードをハイライトします。
  • Rename は、名前の変更によって発生する可能性のあるコンフリクトがある場合は警告します。

デバッガ

本リリースでは、さまざまな点でデバッガが改善されています。 以下を行えるようになりました:

  • Google App Engine アプリケーションをローカルで実行してデバッグできます。
  • サードパーティツールを使用せずに コアダンプ(Go core dumps)を解析できます。 Run | Open Core Dump を選択するだけです。
  • Mozilla rrデバッガがサポートされています。 デバッガで2つのボタンを使用するだけで、エラーが発生するまでプログラムの実行を記録して再生できます。

さらに、デバッガは Evaluate Expression ダイアログと Watchers パネルに対してコード補完、インスペクション、およびクイックフィックスを提供します。

テストランナー

Goland 2018.3はTestifyをサポートしています! 通常のテスト機能のようにスイートとメソッドをエディタから直接実行できます。

コードインスペクション

  • 新しい Unhandled Error インスペクションは、エラーがチェックされていないときにエラーを返す関数またはメソッドを警告し、クイックフィックスでエラーを受け取る変数を導入できます。
  • 新しい Unreachable code インスペクション は、決して実行されることのないコード部分を検出します。
  • Function Call コードインスペクションは、新しい Finish Call Expression のクイックフィックスと並行して機能するようになりました。

インテンションアクション

  • 新しい Add format string argument インテンションアクションは、ポップアップで指定された式用のプ​​レースホルダを生成します。
  • 新しい Generate Constructor は、structタイプの値を作成するための関数を生成します。
  • Generate getter/setter および Generate getter and setter は定型コードを作成し、ポインタ/非ポインタレシーバ型とその名前をカスタマイズできるようになりました。
  • Generate Constructor だけでなく、Generate getter/setter および Generate getter and setter も、Generate ポップアップメニューから利用できます。

コード補完

GoLand 2018.3では、method-like completion for functions(関数をメソッドのように補完)が追加されています。 T型の値tがある場合、t.Fooを書くと、Tタイプを最初の引数として受け入れる関数を見ることができます。

Goテンプレート(html/template)

Goテンプレートを使用して作業するときに、コード補完、 find usages(使用箇所の検索)、Renameリファクタリング、コードフォーマットの改善などをお楽しみください。

検索&ナビゲーション

  • Search Everywhere ポップアップには新しいUIがあり、Go to typeGo to fileGo to symbol Findへのクイックアクセスを備えています。
  • Find in PathReplace in Path ダイアログは、複数行のコードスニペットをより良くサポートしています。

コードインサイト

GoLandのコードエディタは、さまざまな点で成長および拡張しています。

  • 新しいガターアイコンを使用すると、埋め込みタイプのシャドー化された/シャドー化しているメソッドをより正確に特定できます。
  • Complete Current Statement は、複合リテラル(struct、sliceなど)に必要な末尾のカンマを自動的に挿入し、次のステートメントにカーソルを置くようになりました。
  • GoLandは、Go、JavaScript、TypeScript、CSS、およびSCSSの複数行のTODOコメントをサポートしています。
  • Reformat codeOptimize importsRearrange というコードアクションから特定のファイルセットを除外できます。

ダイアグラムサポート

ダイアグラムでは、次のようなビジュアライズと探索が可能です:

  • Go module依存関係。
  • JavaScriptとTypeScriptプロジェクトでコンテキスト内での import と export 。
  • データベースとSQLでのテーブルとその関係。

VCS

  • 新しい GitHub Pull Requests ツールウィンドウには、GitHubからのプルリクエストがすべて、その説明、現在のラベル、変更されたファイル、および担当者とともに表示されます。
  • GoLandは、ルートリポジトリだけでなく、そのサブモジュールもすべてクローンするようになりました。

ツール:

  • KubernetesプラグインはHelmをサポートしています。
  • Dockerは、Docker run configuration(実行コンフィギュレーション)のビルド部分のCLIオプションをサポートしています。

アクセシビリティの改善

  • ハイコントラストテーマ:Settings | Appearance & Behavior
  • スクリーンリーダーサポートの改善。

その他

  • Attach アクションは、Open Project ポップアップで利用できます。
  • ファイルやプロジェクトをウェルカムスクリーンにドラッグして開くことができます。
  • Activity Monitorには、サブシステムとプラグインが消費しているCPUの量が表示されます:Help | Activity Monitor
  • Settings | PluginsPlugins ページを、その機能性とUIの両方を含めて、完全に作り直しました。

JavaScript & TypeScript

  • TypeScript 3.1のサポート
  • JavaScriptの自動インポートとパラメーターヒント。
  • nullundefined チェックの改善。
  • Angular テンプレートのコーディング支援が改善。
  • package.json の以前のパッケージバージョンの補完。

データベースとSQL

  • Cassandraデータベースのサポート。
  • コード補完の改善。

GoLand または All Products Pack の有効なサブスクリプションをお持ちの場合は、ダウンロードページまたは便利なToolbox App を使用して、今すぐGoLand 2018.3にアップグレードしてください。もし Toolboxお使いでなければ、このブログポストを読み、ぜひお試しください!

そうでない場合は、無料の30日間体験版をご利用いただけます! ぜひお試しください!

また、JetBrainsのTwitter (英)Twitter (日)、または YouTrack へ、お気軽にご意見をお寄せください。

[原文Original post in English is written by Ekaterina Zharova

Posted in GoLand, お知らせ | Leave a comment

PhpStorm 2018.3 リリース: DQL、PHP 7.3、複数ホストへのリモートデプロイメント、PHP CS Fixer、強化されたリファクタリングなど

PhpStorm 2018.3がリリースされました!PhpStorm 2018.3

本メジャーリリースでは、Doctrine ORMのDQLサポート、PHP CS Fixer、複数ホストへのリモートデプロイメント、新しいインテンションアクションと強化されたリファクタリング、GitHubプルリクエストとGitサブモジュールのサポート、アクセシビリティの向上などの新機能をお楽しみいただけます!

 

PHP

品質ツール

デプロイメント

バージョン管理

ウェブテクノロジー

  • JavaScriptで自動インポート
  • パラメーターヒント
  • Angularサポートの改善
  • Vuetify サポート

IDE

データベースツール

  • Cassandra サポート
  • コード補完の強化
  • PostgreSQLのエクステンションのサポート
  • Introduce table alias (テーブルエイリアスを導入)インテンション
  • タイムアウト後に自動再接続

新機能の完全なリストは、リリースノートで確認できます。


詳細については、PhpStorm 2018.3の新機能ページをご参照ください(サムライズム様による翻訳はこちらです)。是非、無料の30日間のPhpStorm体験版をダウンロードしてください。

PhpStorm 2018.3をダウンロード

PhpStormまたはAll Productsの有効なサブスクリプションをお持ちの方は、ウェブサイト、または便利なToolbox Appで無料で PhpStorm 2018.3 にアップデートできます (もし Toolboxお使いでなければ、このブログポストを読み、ぜひお試しください)!

フィードバック大歓迎です! Twitter (英) / Twitter (日)、ディスカッションフォーラムYouTrackで、ご意見やご提案をお聞かせください!

JetBrains PhpStorm チーム
The Drive to Develop

[原文Original post in English is written by Roman Pronskiy

Posted in PhpStorm, お知らせ | Leave a comment

RubyMine 2018.3リリース:Struct&Railsスコープのコードインサイト、新しいI18n & リファクタリング機能など

RubyMineの今年最後のメジャーアップデート、RubyMine 2018.3(ビルド183.4284.145)がリリースされました。 What’s Newページ(英)ですべての新機能を確認できます(サムライズム様による翻訳はこちらです)。以下のビデオでは簡単なサマリーをご覧いただけます:


このリリースについて

この新バージョンでは:

  • Railsスコープ:コード補完とナビゲーション
  • Structをフルサポート
  • i18n翻訳を作成し、他のi18nの新機能も使用できます
  • IDEから直接GitHubプルリクエストをプレビューできます
  • パラメータ、インラインメソッド、変数をより安全に抽出できます
  • 新しいインテンションアクションで問題のあるコードを素早く修正できます
  • よりクリーンな Darcula カラースキーム
  • 新しい Search Everywhere ダイアログ

また、JavaScript、データベース・ツール、マークダウンのサポートが強化され、新しいテストガッターが導入されています。

参考になる記事

テスト、リファクタリング、および国際化機能の使用方法についての記事をいくつか作成し、アップデートしました:

プラットフォームの改善について:

前述のように、RubyMine 2018.3では新しいDarculaカラースキームを使えます。JetBrainsがどういう戦略でスキームをアップデートをしたのかを説明する記事を書きました。 この記事では、Darculaの前バージョンにロールバックする方法についても説明しています。

RubyMine 2018.3をダウンロード

RubyMine 2018.3の新機能の詳細については、What’s new ページ をご覧ください(サムライズム様による翻訳はこちらです)。

すべての改善点についてはリリースノートをご覧ください。ご意見、フィードバック、ご提案がある場合はお気軽にお知らせください

よろしくお願いいたします。
RubyMine チーム

[原文Original text in English is written by Artem Sarkisov

Posted in RubyMine, お知らせ | Leave a comment

PyCharm 2018.3リリース

PyCharm 2018.3 がリリースされました: Linux用のWindows Subsystem (WSL)、複数行TODOコメント、Search Everywhereの改善など

PyCharm 2018.3をダウンロード

PyCharmの新機能

  • WindowsでLinux上で動作するアプリケーションを開発しているユーザーはWindows Subsystem for Linux(Wsl)を使ってPyCharmからコードを実行できるようになりました。 PyCharm 2018.3は、WSL内でPythonインタプリタを使うように設定できるようになりました。
  • Issue Trackerで最もリクエストされた機能の1つは、複数行のTODOコメントでした。PyCharm 2018.3で書けるようになりました!
  • Search Everywhere(どこでも検索)は新機能ではありませんが、使いやすくなりました。結果をどのようにフィルターできるのかが分かりやすくなりました。

詳しくは What’s New でお読みください(サムライズム様による翻訳はこちらです)。 リリースノートも確認できます。

今すぐアップグレード

PyCharmの新バージョンを使うには、次のいずれかの方法でアップグレードしてください。

ご質問、ご不満、またはご提案等はございますか? お気軽にご連絡ください! Twitter (英) / Twitter (日)YouTrackで、皆さんのご意見をお待ちしております。

[原文Original text in English is written by Ernst Haagsman

Posted in PyCharm, お知らせ | Leave a comment

IntelliJ IDEA 2018.3:GitHubプルリクエスト、Java 12、複数行TODOコメント、Gitサブモジュールサポートなど

IntelliJ IDEA 2018.3がリリースされました! IntelliJ IDEAの今年3回目のメジャーアップデートには、注目すべき機能がたくさんございます! 詳細は、What’s newをご確認ください(サムライズム様による翻訳はこちらです)。ウェブサイトにアクセスし、IntelliJ IDEAの最新バージョンを今すぐダウンロードできます。 新機能のシンプルなサマリーはこのブログポストにございます。

KGBfLKOw

 

Java

  • IntelliJ IDEAは今後公開予定のJava 12をサポートしています。すでに、IDEで生文字列リテラル(Raw String Literals)(JEP 326)をプレビューできます。 もっと詳しく
  • IDEはより複雑なケースで重複を見つけることができるようになりました。さらに、その速度も向上しています。
  • Java Stream APIの改善:minが後続する冗長なsorted呼び出しが検出されるようになりました。
  • 新しいデータフローベースインスペクションでは、後続の条件により不要な条件が検出されるようになりました。
  • IDEは、抑制されたインスペクションが、関連するメソッド本体、クラス、またはステートメント内の警告を処理しない状況を識別するようになりました。

What’s new ページの Javaセクション で詳細を確認できます。

エディタ

  • IDEは、エディタ内の最初とその後の全てのTODOコメント行をハイライトし、それらをTODOツールウィンドウで表示します。
  • 新しいインデントステータスバーには、現在のファイルのインデントのサイズが表示されます。
  • スコープを作成して、特定のファイルやフォルダでコードフォーマットを無効にすることができます。 Preferences / Settings | Editor | Code Style の ‘Formatter Control’ タブで設定できます。
  • EditorConfigファイルでシンタックスハイライトとコード補完ができるようになりました。

What’s new ページの Editor セクション で詳細を確認できます。

バージョン管理

  • GitHubプルリクエストの初期サポートにより、IDEでプルリクエストを見れるようになりました。
  • Gitサブモジュールのサポートにより、プロジェクトを更新、diffをコミット、diffを表示、または競合を解決できます。
  • VCSログでは、前または次の選択されたコミットにナビゲートできます。
  • ‘ History Up to Here’ アクションは、完全なファイル履歴を表示するようになりました。
  • ホワイトスペースの変更は、マージ中に無視できます。
  • Annotations のコンテキストメニューに、新しい Ignore Whitespaces オプションが追加されました(Gitのみ)。
  • アノテーションのラインのDiff PreviewがVCSポップアップで表示されるようになりました。
  • IntelliJ IDEAでは、Gitブランチから別のブランチにファイルをコピーするための新しいオプションが追加されました。
  • ファイルをコミットしているブランチが、コミットダイアログに表示されるようになりました。
  • IDEはGitマルチリポジトリプロジェクトを以前よりもずっと速くアップデートします。
  • IDEはデフォルトでネイティブGit SSH Executableを使用するようになりました。

What’s new ページの Version Control セクション で詳細を確認できます。

Search and Replace

  • 新しい Search Everywhere では、次のナビゲーションダイアログが統合されています:Search Everywhere、Find Action、Go to class、Go to file、Go to symbol。
  • Find in Path ダイアログで複数行のフラグメントを検索できるようになりました。
  • 新しい更新された Structural Search & Replace ダイアログでは、検索フィールドのオートコンプリート、より柔軟なスコープ設定など、多くの機能が強化されています。

What’s new ページの Search and Replace セクション で詳細を確認できます。

再構築されたプラグイン設定ページ

  • プラグインの管理、インストール、アンインストール、アップデートをより簡単にできるように、Preferences (Settings)(環境設定(設定))の Plugins ページを再設計しました。 もっと詳しく

Run Anything

  • Runコンフィギュレーション、ターミナルコマンド、Gradleタスク、または他のコマンドを簡単に実行するには、新しい Run Anything アクション(ダブルCtrlキー)を使用できます。 もっと詳しく

Kotlin
バンドルのKotlinプラグインがv1.3へアップグレード。

  • IDEはプロジェクトを新しいバージョンのKotlinにアップグレードを手助けします。
  • IDEはマルチプラットフォームプロジェクト用の一連のプロジェクトサンプルを提供します。
  • 新しいKotlinインスペクションとクイックフィックスが追加されました。

What’s new ページの Kotlin セクション で詳細を確認できます。

Spring & Spring Boot

  • IDEは、最近リリースされた Spring Boot 2.1 をサポートしています。
  • プロジェクトの作成時に、IDEは適切なプラグインのインストールまたは有効化を提案し、選択されたすべてのテクノロジーがサポートされていることを確認します。
  • KotlinのJPAとSpringデータのサポートが改善されました。

What’s new ページの Spring & Spring Boot セクション で詳細を確認できます。

アクセシビリティ

  • IntelliJ IDEAをよりアクセシブルにするために、新しいハイコントラストテーマを導入しました。
  • スクリーンリーダーは、ライン番号、VCS注釈、デバッガ、およびその他のガターアイコンを読見上げることができるようになりました。
  • HTML用のアクセシビリティインスペクションが利用できます。

What’s new ページの Accessibility セクション で詳細を確認できます。

JVMデバッガ

  • サービサビリティ・エージェント(SA)を使用してデバッグ・エージェントなしで開始されたJavaプロセスにアタッチすることが可能です。
  • IDEは、リモートデバッグプロセスが切断された後も、自動的にリモート接続を継続して待機することができます。
  • 好みのカスタムショートカットを設定して、ファイルまたはプロジェクト内からすべてのブレークポイントを削除することができます。
  • IDEはリモートJVMのasyncスタックトレースをサポートしています。

What’s new ページの JVM Debugger セクション で詳細を確認できます。

Maven

  • すべてのビルドと実行アクションをMavenに委譲できます。 もっと詳しく

ターミナル

Run Configuration

  • Java run configurationsでマクロのサポートを利用できます。
  • テキストファイルを入力に使うことができます。
  • Run configurationはデフォルトでシングルインスタンスとして実行されます。

What’s new ページの Run Configuration セクション で詳細を確認できます。

JavaScript & TypeScript

  • JavaScriptの自動インポートは、ESモジュールとして記述された、または型定義ファイルがあるプロジェクトの依存関係のシンボルでも機能するようになりました。
  • 強化されたAngularサポート:pipe、async pipe、およびテンプレート参照変数のより正確なコード補完とGo to definition
  • Node.jsワーカースレッドをデバッグできるようになりました。
  • ESLintとTSLintがよりフレキシブルになりました。

WebStorm What’s new ページで詳細を確認できます。

Kubernetesプラグイン

  • Kubernetesプラグインには、コーディングアシスタンス、Helmテンプレート結果のプレビュー、新しい ‘Helm Update Dependencies’ アクションなどを含むHelmサポートが追加されました。

What’s new ページの Kubernetes セクション で詳細を確認できます。

データベースツール

  • Cassandra データベースがサポートされるようになりました。
  • SQLコードの補完が改善されました。
  • Introduce table alias アクションが改善されました。
  • タイムアウト後に自動的に再接続するようになりました。

What’s new ページの Database Tools セクション で詳細を確認できます。

サーバー / クラウド

  • ライブラリとしてアーティファクトのインストールとWebLogicデプロイメント・プランのサポート。
  • Jetty 9.4.xサポート。
  • OpenShift Origin(V3)とトークン認証のサポート。

Docker

  • DockerプラグインがIDEにバンドルされました。

実験的な機能

  • JVMプロファイラ(macOSとLinux)。 もっと詳しく
  • Linuxのグローバルメニューバー。
  • アクティビティモニタ。

その他

  • GTK(Linux)とWindowsネイティブテーマは削除されました。
  • ウェルカム画面でファイルとプロジェクトをドラッグ&ドロップできます。

改善の完全なリストについてはリリースノートをご覧ください。ぜひ引き続き、ディスカッションフォーラムIssue Tracker、または Twitter (英) / Twitter (日) で、ご意見やご提案をお聞かせください! よろしくお願いいたします!

IntelliJ IDEA 2018.3を今すぐダウンロードしてください!

Happy Developing!

[原文Original text in English is written by Zlata Kalyuzhnaya

Posted in IntelliJ IDEA, お知らせ | Leave a comment

JetBrainsのクロスプラットフォーム対応.NET IDE「Rider」誕生までの歴史とそのアーキテクチャ

こんにちは。JetBrains堀岡です。

「最近JetBrainsは.NET関連ツールに注力してないのでは?JetBrains Night Tokyoでもセッション無いし。」というご意見を頂きました。そんなことありません。実際のところJetBrainsの.NET系製品群はIntelliJ IDEAに次ぐ代表製品で、日本でも多くのお客様にご利用いただいております。つい先日、弊社Developer Adovocate(@cwoodruff@maartenballiauw)によるRiderに関する英文記事がCODE Magazineで公開されました。せっかくなのでCODE Magazine 様から了承を頂き、英文記事の抄訳を作成しました。Riderをお使いのお客様や、これから使ってみたいと考えているお客様にRiderの設計思想やメリット、JetBrainsの.NET製品への継続的な取り組みをご理解頂くために参考にして頂ければ幸いです(ただし、かなりの長文です)。英語の原文で読みたい方は以下をご覧ください。

“This article originally appeared in CODE Magazine – Nov/Dec 2018: https://www.codemag.com/Article/1811091/Building-a-.NET-IDE-with-JetBrains-Rider

800x400_blog@2x

JetBrains Riderについて

JetBrains Riderは.NET/Mono/.NET Core環境、およびASP.NET、ASP.NET Core、Xamarin、WPFなどのフレームワークを使用するテクノロジをサポートするクロスプラットフォーム(Windows, Linux, macOS)対応IDEです。Riderは、C#、VB.NET、F#、JavaScript、TypeScriptなどの多くの言語に対応しており、コンソールアプリケーション、ライブラリ、Unityゲーム、Xamarinモバイルアプリケーション、ASP.NET MVCの構築、及び、Angular/React/Vue.jsなどを用いたWebアプリケーション作成をサポートしています。

Riderには、.NET開発者にとって日々のコーディングを快適にし、品質の高いコードを書くために役立つ多くの機能があります。例えば、Riderは他のJetBrains IDEと同レベルの優れたコード補完、コード生成、リファクタリング、ナビゲーション、2,300を超えるコード検査(静的コード解析)機能を備えています。これらのコーディング支援機能に加えて、.NET開発者がIDEの基本機能として期待するような、デバッガ、単体テスト実行、(高速な)NuGetクライアント、データベースツール、WPF XAMLプレビューウィンドウ、バージョンコントロールシステムとの連携機能も備えています。さらに、Dockerとの連携やUnity Editorのような最新のテクノロジーにも対応しています。しかしながら、特筆すべきことは、これらの豊富な機能が全て備わっていても、Riderはメモリ効率が良く、高速で機敏に動作するということです。

Rider誕生までの歴史

Riderの技術とアーキテクチャの話に入る前に、その歴史について触れなければなりません。 2004年、JetBrainsはVisual StudioアドインReSharperのスタンドアロンアプリケーション版の作成を検討していました。 結果としてリリースされることはありませんでしたが完全に機能するプロトタイプが既に存在していました。

以下の図1がReSharper 2.0 IDE UIのスナップショットです。ソリューションエクスプローラ、エディタ、使用箇所の表示、コード補完、リファクタリング機能は既に実装されていました。 ユーザーインターフェイスはモダンではありませんが、エディタ上でドキュメンテーションをインラインで装飾表示するための機能は.NET WinFormsをベースに実現されており、WPF(Windows Presentation Foundation)が存在しなかった当時としては革新的な取り組みでした。

image1

図1: ReSharper 2.0 IDE UI

その後スタンドアロン版ReSharperプロジェクトは一旦中止となってしまいましたが、そこで開発された要素技術(アクションシステム、テキストコントロール実装、ツールウィンドウおよびツールバーコントロール、単体テストランナー、ReSharperコマンドラインツール)は、その後のReSharperの進化とRiderの誕生に応用され、決して無駄になることはありませんでした。

ReSharper 2.0 IDEにおいて1つの重要なデザイン上の決定は、ReSharperのコア機能と(エディタとしての)IDE機能をデザイン上分離しておくということでした。この決定はその後のReSharperの開発の効率化(Visual Studio 2010, 2013, 2015, 2017の同時サポートを共通のReSharperコア機能上に個別のIDE対応レイヤーを作成することにより実現)に寄与しました。このデザインはRiderの開発にとっても重要な役割を果たしました。簡単に言ってしまえば、Riderの開発に必要なことは、ReSharperコアに別の(IntelliJ向けの)インテグレーションレイヤーを追加することのみに出来たからです。

ReSharper 2.0 IDEの開発同様、JetBrainsは新しいIDEを開発する上で、既存の技術とツールを可能な限り再利用したいと考えていました。それは論理的にはJetBrainsが長い年月をかけて構築してきたIDEプラットフォーム(IntelliJ IDEA)を再利用するということでした。IntelliJ IDEAは様々な開発シナリオをサポートし、WebStormIntelliJ IDEA Ultimateのような他のJetBrains IDEの基礎となっています。一方で、JetBrainsには、他のIDEではサポートしていないC#やVB.NET向けVisual Studio用アドオン製品としてReSharperがありました。

そこでJetBrainsはIntelliJとReSharperを融合するという挑戦を開始しました。IntelliJのリッチなフロントエンド機能やバージョンコントロールシステム連携などの共通ツール機能、ReSharperの.NETツール機能の融合です。しかしそれぞれのツールは異なるテクノロジー・スタックの上に実現されています。具体的には、IntelliJ はJava Virtual Machine上で動作し、ReSharperは.NETベースで動作します。そのため我々はこれら2つのプロセスを協調して動作させる必要があったのです。

軽量かつスマートなUIレイヤー

RiderはIntelliJをReSharper上で動作する軽量なユーザインタフェース層として主に利用しています。すなわち、IntelliJはRiderにおいては、エディターとしてのユーザインターフェースを提供します。ただし、JavaScriptやTypeScriptのような言語に対しては、言語解析等の全ての機能を提供します。一方で、IntelliJのフロントエンドはC#やVB.NET、F#のような言語に対しては、知識を持ち合わせていません。それらの知識はReSharperバックエンドから提供される必要があります。

ユーザがソースファイルを編集するとき、IntelliJはユーザの操作を追跡します。 例えば、ステートメントの記述を完了するタイミングで、IntelliJは現在の言語サービスに補完項目を要求します。 C#、VB.NET、F#、および他のいくつかの言語に対しては、Riderのフロントエンドは、実際の処理を行う代わりにReSharperバックエンドから情報を取得するファサード言語サービスを呼び出します。 そこで得られた情報がフロントエンドに渡され、補完候補リストとして表示されます。

このような情報の流れは逆方向にも起こりえます。RiderのIntelliJフロントエンドはコードインスペクション結果を波線で表示する仕組みを持っていますが、C#用のインスペクション機能自体は持っていません。Riderは、ソースファイルを開いたタイミングで、ファイル情報をReSharperのバックエンドプロセスに通知し、ReSharperがファイル解析を行い、インスペクションの実行が完了するのを待ちます。ReSharperはインスペクション結果として指摘箇所、重要度、tooltip(吹き出し)テキストのリストを出力し、フロントエンドはその情報を表示するだけです。

まとめると、RiderにおいてはIntelliJフロントエンドの役割は特定の言語(JavaScript等)向けの処理、Tool Window群の提供、バージョンコントロールシステムとの連携となります。一方、.NET言語に対しては、IntelliJフロントエンドは編集機能の提供やその他の共通機能のフレームワークとして動作し、必要な情報はバックエンドプロセス(ReSharper)から取得します。

カスタムプロトコルの必要性

前述の通り、RiderのIntelliJフロントエンドには、編集、コード補完、メニューエントリの表示、コード検査結果の表示など、多くの機能に対するフレームワークが用意されています。 一方で、ReSharperのバックエンドプロセスも、コード補完、コード検査、リファクタリング等の同様の概念を持っています。

これらの類似点のため、JetBrainsは、フロントエンドとバックエンドの間で共有されるシンプルなモデルを利用できることに気付きました。 例えば、ユーザがコードを編集した時に、少量のテキストと差分情報をフロントエンドからバックエンドに渡すことができます。 コード検査結果を表示するために、バックエンドからフロントエンドにドキュメント範囲、重要度、および説明を提供すれば良いのです。 ということは、もし、あるコード検査結果をReSharperからIntelliJのフロントエンドで表示することができれば、その他のコード検査結果も同様に表示することができるはずです。 また、もし、エディタでコードの一部を変更し、小さなコードの部分データをReSharperに渡してモデルを更新することにより、1つのリファクタリング機能を動作させることができれば、外のすべてのリファクタリングも同様に動作させることができるはずです。

そこでJetBrainsはフロントエンドとバックエンドの間で、どのような手法でアクションやデータを受け渡すのが良いのかを決定するために、以下を検討しました。

  • 初めに、Language Server Protocol (LSP)の利用を評価しました。 – 結局採用しませんでした。LSPは素晴らしく、多くの機能がありますが、我々の用途とはあまりマッチしませんでした。例えば、ReSharperのいくつかのリファクタリング機能をLSPを用いて実装するためには、多くのカスタマイズが必要であることが判明しました。 また、C#/ VB.NETとHTML、CSS、JavaScriptを混在させたRazorのような言語をLSPがどのように扱うべきかも我々にとって不透明でした。 恐らく、別々の言語のLSPコンポーネントが必要であり、組み合わせ言語のLSPコンポーネントも必要でしょう。結果として、 LSPは多くの複雑さをもたらし、我々の特定のユースケースに対してほとんど利益をもたらさないと判断しました。
  •  次に、各プロセスが別のプロセスに呼び出すことができるカスタムRESTプロトコルを構築し、評価しました。 JetBrainsは、JSONやProtoBufなどのさまざまなトランスポートメカニズムとシリアライザを試していました。 残念なことに、これらのプロトコルは遅く、カスタマイズが難しく、効率的な開発には適さない事が判明しました。 これらアプローチの主な欠点は、リモートプロシージャコール(RPC)タイプのプロトコルを使用していることです。 これらの手法の場合、常に「要求 – アクション – レスポンス」フローで考える必要があります。一方で我々は、フロントエンドとバックエンドの間に、同じ概念で構築された、より自然なフローを持たせる方法を探していました。例えば、 フロントエンドがバックエンドに「add file to solution」メッセージを送信し、状態が更新されたという応答を待つ代わりに、solution.Add(filename)というコードを書いたら、両方のプロセスをが自動的に同期され、 競合の解消やその時点で例外が発生した場合に何が起きるかをあまり気にせずプログラミングできるようにしたいのです。

もう一つの実装における重要な検討事項は、互いに受け渡されるデータの型でした。コード検査の場合、交換されるデータは、ドキュメントの範囲、重要度、および説明のみになります。 RPCスタイルでは、実際にコード検査を実現するには詳細な情報が必要です。例えば、このコード検査はどのソリューション対するものなのか?ソリューションのどのプロジェクトものなのか?そして、どのファイルに対するものなのか?あらゆる呼び出しには、そのようなコンテキスト情報が必要となり、RPC呼び出しが大量になり、開発者に多くのオーバーヘッドが必要になります。

そこでModel-View-ViewModel(MVVM)パターンとしてこのプロトコルをモデリングしようとしたとき、私たちに気づきの瞬間が訪れました。 Wikipediaの定義によれば、MVVMは、ビューモデル(VM)をバリューコンバーターとして使用して、バックエンド(M:モデル)の開発からユーザーインターフェイス(V:ビュー)の開発を分離することを容易にします。 私たちの場合、IntelliJはビューであり、ReSharperはモデルを提供しています。そして「プロトコル」が、UIコンポーネントに必要な軽量のデータとデータを共有するビューモデル(VM)です。

このデザインでは、(フロントエンドとバックエンドの)両方のプロセスに状態を持ち、それらを同期させようとするのではなく、両者から操作できる共有モデルが存在することが特徴です。私たちが最初に欲しかったのはまさにこのデザインでした。開発者がフロントエンドのプロジェクトに新しいファイルを追加すると、共有モデルが更新され、フロントエンドとバックエンドの両方のプロセスがそれに反応します。 ReSharperで動作しているリファクタリングで新しいファイルが追加されると、共有モデルが更新され、再び両方のプロセスがそれに反応できます。共有モデルはシステムの状態であり、両プロセスはモデルの変更を監視して反応することができます。

競合の解決

プロセス間通信において、MVVMは競合を解決しません。変更はフロントエンドまたはバックエンドのいずれかから来る可能性があり、競合が発生する可能性があります。たとえば、バックエンドがリファクタリングを実行中に、フロントエンドはファイルを削除する可能性があります。その結果、バックエンドは、モデル内の削除されたファイルに対して、レポートおよび更新を行おうとします。 ReSharperのバックエンドがリファクタリングを実行中に、コードを変更する場合、矛盾する変更をどのように解決すればよいでしょうか?コードを書いている人間による変更が優先されるのでしょうか?バックエンドプロセスが勝つのでしょうか?このような場合、どのようにモデルに対する動作を同期させれば良いでしょうか?

1つの解決方法は、ロックの概念を導入して、このような競合の発生を防止することです。しかし、リファクタリングの実行中にIDEが応答を停止するのを見たい人はいないでしょう。開発者は、長時間実行されているタスクがまだ完了していなくても、そのファイルを削除したり、新しいファイルを作成したり、モデルを更新したいはずです。我々はIDEが常にサクサク動作することを期待するのです!

そこで、JetBrainsは、競合の発生を防ぐために、以下のいくつかの基本的なルールを決めました:

  • クライアントとサーバーを定義します。Riderの場合、クライアントはIntelliJで、サーバーはReSharperです。
  • ビューモデルに格納される各値にはバージョンがあります。
  • クライアントによって値が更新されるたびに、バージョンが増分されます。
  • サーバー側の更新はバージョンを増やしません。
  • (ビューモデルは)バージョンが同じかそれより新しい場合にのみ、変更された値を受け入れます。

クライアントによって値が変更されると、ビューモデルはそれを受け入れます。一方、サーバーが処理を行い、値を変更しようとしたときに、変更した値のバージョン番号が現在のバージョンより低いと、その変更はビューモデルで受け入れられません。これにより、競合が発生したときに、クライアント側の変更プロトコルが常に優先されるようになります。

Riderプロトコル

JetBrainsは、MVVMのアプローチと競合解消のルールを組み合わせたRiderプロトコルを構築しオープンソース化しました。しかし、私たちは多くのプロトコルの詳細が開発者に面倒をもたらすことを避けたいと思っていました。代わりに、私たちはプロトコルを図2のようにしたいと思っていました。

image2図2:RiderプロトコルとReSharperバックエンド

プロトコルの最下層は通信自体を提供し、ソケットで動作します。Riderは、差分情報を送信するバイナリワイヤプロトコルを使用します。必要に応じてバッチ処理を提供し、ワイヤを通過するすべてのデータをダンプするためのロギングをサポートします。それでも、このプロトコルは、開発者にとって詳細すぎると考えました。そこで、 JetBrainsはこのプロトコルを使用するためのフレームワークを構築しました。

IntelliJフロントエンドはJVM上で実行され、ReSharperバックエンドは.NET上で実行されます。そこで我々は、Kotlin(JVM言語)ライブラリとC#ライブラリを作成し、両方のライブラリが共通で使用するプリミティブを定義しました。また、これらのプリミティブを使用して、ドメイン固有の言語でビューモデルを定義し、フロントエンドとバックエンドで使用できるコードを生成できるようにする(Kotlinベースの)コードジェネレータも作成しました。

(フレームワーク又はライブラリによって)JetBrains開発チームは、プロトコルで動作する基本的なプリミティブについてのみ知っていればよく、ライブラリの背後にある他のすべての魔法を習得する必要はありません。このフレームワークを使用する別のメリットは、プロトコルレイヤは自動生成されるので、reflectionやintrospectionについて工数をかけることなく、パフォーマンスよく開発できることです。

このプロトコルではまた、オブジェクト階層を管理するためのアプローチとして、ライフタイムの概念をサポートしています。オブジェクトをメモリから、いつ、どこで削除するかをコントロールする代わりに、オブジェクトはライフタイムに付けられ、ライフタイムが消滅するタイミングで同時に削除されます。例えば、コード検査結果をエディタ・タブのライフタイムに付けることができます。これにより、エディタ・タブを閉じて(ライフタイムが終了すると)コード検査結果もメモリから削除されます。また、そのエディタのタブ自体をソリューションライフタイムに関連付けることができるため、ソリューションが終了して親ライフタイムが終了すると、すべての存在するオブジェクトも破棄されます。 IntelliJとReSharperはどちらもこのアプローチを利用しており、プロトコルのビューモデルはこれに従う必要があります。

ライフタイム以外にも、Riderプロトコルは次の概念をサポートしています:

  • シグナル:何かが発生したときに生成されるイベント
  • プロパティ:Observableな値
  • マップ:Observableなコレクション
  • フィールド:Immutableの値
  • 呼び出し:ケースバイケースで必要となるRPCスタイルの呼び出し

これらはすべて、stringenumclassdefまたはaggregatedef(ビューモデル内のノード)、およびstructdef(データを保持するオブジェクト)といったデータタイプの受け渡しに使用することが出来ます。

概念のみだと曖昧に聞こえるかもしれないので、簡単な例を見てみましょう。 RiderのNuGetクライアントは、さまざまなパッケージソースの使用をサポートしています。 これらはすべて名前とURLを持っています。

このプロトコルでは、NuGetクライアント情報(RdNuGetHost)を保持するビューモデルノードを定義します。このノードには、NuGet configuration(configManager)を管理するノードがあり、NuGetのソース名とURLを保持するプロパティ(knownFeeds)があります。

コード生成を実行すると、図3に示すように、IntelliJフロントエンドが使用できるKotlinのクラス定義と、ReSharperバックエンドが使用できるC#のクラス定義が取得されます。

image3図3: Riderプロトコルに対するコード生成

これにより、開発者は生成されたプロトコルに対して作業することができます。 たとえば、フロントエンド側では、以下のようにKotlinプログラミング言語でフィードのリストを設定できます:

一方、バックエンドの.NETコードでこのリストを購読し、変更に反応することができます。 または、指定した時点でリストの値を列挙できます。 図4に示すように、プロトコルコードが生成されているため、コード補完も得られます。

image4図4:Riderでのコード補完の例

まとめると、プロトコルに対するコード生成のおかげで、IntelliJフロントエンドとReSharperバックエンド間のコミュニケーションや状態について詳細をケアすること無く、共有モデル用いてコードを書くことができるのです。

マイクロサービス

Riderは、IntelliJのフロントエンドとReSharperのバックエンドの2つのプロセスで構成されていることをすでに説明しました。両方とも異なるテクノロジスタック(JVMと.NET)で動作しているため、Riderは、Riderプロトコルを使用して相互に通信する複数のプロセスを実行する必要があります。複数プロセスによる実行にはいくつかの利点があります。1つの利点は、それぞれのプロセスが独自の64ビットメモリ空間を持ち、マルチコアマシンでは、これらのプロセスが独自のCPUコア上で実行される可能性が高いため、パフォーマンスが向上することです。

もう一つ興味深い利点があります。プロセスの独立性です。複数のプロセスが独立して実行されるので(プロトコル経由での通信は別として)、独立したガベージコレクションが実行可能です。また、起動や停止に関しても独立して実行可能です。この特徴はとても興味深いです!独自のメモリスペース、独自のガベージコレクタ、および潜在的に独自のCPUコアを使用して、必要に応じてプロセスを開始および停止できるのです。

Riderは、使用しているソリューションのタイプに応じて、2つ以上のプロセスを実行することがあります。 Windows Presentation Foundation(WPF)プロジェクトで作業する場合、図5に示すように、3つのプロセスが実行されている可能性があります。

image5図5:RiderのWPF XAMLプレビュー

まず、エディタ自体はRiderのIntelliJフロントエンドであり1つのプロセスです。次に、コード補完、コード解析、クイックフィックスなどは、RiderのReSharperバックエンドプロセスとして実行されます。 そして、画面下部のXAML Previewウィンドウが3つ目のプロセスです。ReSharperのバックエンドは、WPFアプリケーション向けに作業していることを検出し、別のインスタンスのプロトコルでReSharperとビットマップ表現を通信するレンダリングプロセスを開始します(図6) 。

image6図6:XAML Previewレンダラと動作するRiderのプロセス

RiderはRoslynアナライザーの実行もサポートしています。多くの開発チームは独自のアナライザを作成して、構築したフレームワークに追加のツールを提供します。Riderでは、ReSharperバックエンドがRoslynを使用してコードを解析する別のプロセスを開始します。Roslynによる解析結果がIntelliJのフロントエンドに渡され表示されます(図7)。

image7
図7:Roslynと動作するRiderのプロセス

デバッガもまた別のプロセスでも実行され、ReSharperバックエンドによって生成され、Riderプロトコルを使用して通信します。したがって、Roslynアナライザを使用するプロジェクトでXAMLプレビューツールウィンドウを開いて、それをデバッグしようとすると、さらに多くのプロセスが実行されます(図8)。image8

図8:デバッガを使用したRiderのプロセス

まとめると、オンデマンドでプロセスを開始および停止できるアーキテクチャでは、次のような利点があります。

  • 独立したガベージコレクションとメモリスペースの分離
  • オンデマンドでの機能の開始/停止、ソリューションで必要なときにのみ、完全な機能セットをロード
  • 独立したクラッシュ。これは、XAMLプレビューレンダラのようなプロセスで重要になります。例えば、問題のあるユーザーデータをレンダリングする必要がある場合です。そのような場合、IDE全体が停止するのではなく、1つのプロセスを正常に失敗させることができます。

まだ説明していないもう1つの利点があります。 Riderプロトコルはソケットベースなので、必ずしも同じコンピュータ上で実行する必要はありません。たとえば、Dockerデバッグサポートでは、デバッガプロセスはDockerコンテナ(基本的に別のコンピュータ)で実行され、RiderのReSharperバックエンドプロセスと通信します。これは、現在と将来に対して多くの柔軟性をもたらします。

これまで見てきた例では、Riderがプロセスを所有し、起動/停止を行いました。一方、 Unity Editorとの統合においては、Riderは(Unity Editorの)プロセスを所有していません。 RiderとUnity Editorは独立して起動することができますが、両方のプロセスが互いのRider Protocol接続を探すことができます。両方とも起動し、接続が許可されている場合、RiderはそのビューモデルをUnity Editorと共有することができ、その逆も可能です。これにより、RiderはUnityの再生、一時停止、停止ボタンをコントロールすることができます。また、Unity Editorで実行中でもRiderでコードをデバッグすることができます(図9)。

image9
図9:macOSで動作しているRiderによるUnityデバッグ

Unityプラグインの内部に興味がある場合は、https://github.com/JetBrains/resharper-unityをご覧ください。IntelliJフロントエンド、ReSharperバックエンド、およびUnity Editorプラグインによるマイクロサービスの実現を見ることができますよ!

Riderの独自UI拡張のためのデザイン

ここまではRiderのIntelliJフロントエンドとReSharperバックエンド間における、ビューモデルの共有について重点を置いて説明してきました。ビュー自体はどうでしょうか?確かに、Riderにはビュー側で開発されたいくつかの独自のユーザーインターフェイス要素とツールウィンドウが必要がですよね?

その通りです。コード検査やクイックフィックスの表示においては、ドキュメントの範囲、重要度、および説明といった、IntelliJで既に使用されているものを再利用するため、フロントエンドでの変更を必要としません。一方、他の機能、例えばNuGetツールウィンドウでは、構築したプロトコルに基づきにすべての機能を実装する必要があります。

最近のバージョンのRiderを開発中に、JetBrainsは、多くのユーザーインターフェースとユーザーインターフェース要素が本質的に似ていることに気づきました。たとえば、すべてのコード検査設定は、検査の概要、重要度、およびそれらをオンまたはオフに切り替えるブール値です。これらのすべての設定は、そのリストをグリッドビューにバインドする同じユーザーコントロールを共有します。

他の多くの設定では、ユーザーインターフェイスは多くの場合ヘッダーの後に1つ以上のテキストが続き、その後にチェックボックス、テキストボックス、またはドロップダウンが続きます。そこで、それらを個別に再構築するのではなく、プロトコルを使用して実装できるいくつかの標準ビューを構築し始めました。たとえば、RiderのC#インタラクティブ設定は、次のコードスニペットを使用してReSharperバックエンドで定義されます。

RiderのIntelliJフロントエンドはこれらをレンダリングし、適切な設定ペインが表示されます(図10)。

image10図10:Riderの設定ペイン

ReSharper側でユーザーインターフェイスを定義する利点は2つあります。まず、UIを手動で構築する必要はなく、代わりにプロトコルモデルからUIを生成できます。第2に、RiderとReSharperは同じコードベースなので、ReSharperの将来のバージョンでもこれらをレンダリングできるのです!

Riderの開発がReSharperの進化にもたらすメリット

RiderはReSharperの機能をできる限り再利用して作られているという話をしました。このようなデザインにより、JetBrainsがRiderに追加する機能は、ReSharperでも利用可能であり、ReSharperへの機能追加は同様にRiderでも利用可能であるという利点があります。

これは機能に限った話だけではなく、パフォーマンスの最適化においても、一方での改善が他方にもメリットをもたらします。 例えば、ReSharperにおいて、ソリューションをロードする速度を最適化すれば、Riderはそのメリットを得るでしょう。 RiderがIDEコンポーネントの読み込みを最適化すれば、ReSharperも同様の改善によるメリットを享受することができます。

現在のRider開発において、JetBrainsは今後ReSharperバックエンドを.NET Core CLRの上で動作させることに重点を置いています。これは、.NET Framework(Windowsの場合)またはMono(macOSおよびLinuxの場合)を必要としないようにするためです。この取り組みは、現在のような2つの異なるランタイム環境ではなく、すべてのプラットフォームのランタイム環境が.NET Coreになるという点でRiderにとって有益です。Riderはまた、ReSharperと同様に、.NET Coreで行われた多くのパフォーマンス強化の恩恵を受けるでしょう。

Rider開発において我々はUIとは別のプロセスとしてReSharperを実行させるデザインに取り組んできましたが、この取り組みはVisual Studioにおいても、ReSharperを別プロセスとして実行させることに応用されようとしています。 JetBrainsはこれに積極的に取り組んでおり、Visual Studioにおいてもこの記事で紹介している利点をもたらします。Visual StudioとReSharperはそれぞれ独立したプロセスで動作し、独自のメモリスペースと潜在的に独自のCPUコアを使うことができるようになります。この取り組みは .NET Core CLR上でReSharperを実行するためのサポートの変更とともに、Visual Studio上におけるReSharperにおいてもパフォーマンスの大幅な向上をもたらすでしょう!

さらなる機能:DataGrip、WebStorm、およびdotToolsとの統合

Riderの歴史から学んだように、Rider IDEの強みは、IntelliJファミリの他のIDEの機能を包含している点にもあります。 .NETとASP.NETの開発者にとって、JetBrainsはDataGripとWebStorm IDEの多くの機能をRiderに統合しました。これは基本的に既存のプラグインをRiderにバンドルすることによって実現しました。

DataGripのデータベースツールをバンドルすることで、RiderはOracle、MySQL、Microsoft SQL Server、Azure SQL Databaseなどをサポートするデータベースおよびデータに対する豊富な機能を提供します。Riderのユーザーは、SQLテキストエディタのインテリジェンスを使用してSQLコードを作成し、SQL文を実行し、結果セットを表示し、データベーススキーマを迅速にナビゲートして、使用しているデータベースでテーブル、ビュー、プロシージャ等を確認することができます。

JetBrainsは、単に既存のプラグインと機能を組み合わせるだけでなく、1+1=3になるように機能を拡張しようと積極的に考えています。例えば、 C#ファイルの文字列の中にSQLコード補完を提供することができれば、どれくらいうれしいですか?または、そのクエリを実行するAlt + Enterアクションを提供しますか?これはまさに私たちが取り組んでいることです(Rider 2018.3でSQLに対するLanguage Injection機能が拡充されます)。両方のプロセス(さらに、おそらく、他に協調するマイクロサービス)からインテリジェンスが得られるため、IDEはさらにスマートになります。

その他の例は、バンドルされているWebStormの機能にあります。ここ10年間のWebクライアントベースの開発の増加に伴い、ほとんどのASP.NETおよびASP.NETコア開発者は、プロジェクトやソリューションでJavaScriptの使用を強化する必要性を認識しました。 RiderのエディタはJavaScriptだけでなく、Angular、React、Vue.jsなど、現在利用されている代表的なWebフレームワークも理解しています。Riderは、また独自のコード解析機能と、現在利用可能な最も人気のあるオープンソースのLinterと組み合わせて、Webコードをチェックすることができます。 WebStormの組み込みデバッガとユニットテスト機能を使用して、すべてのJavaScriptコードを.NETコードとは別にデバッグしてテストすることもできます。 ASP.NETとASP.NET Coreを使用して構築されたWeb APIをテストするためのRESTクライアントもあります。

現在、Rider上でTypeScriptファイルをコーディングする場合、関連するすべての機能は、フロントエンドのWebStormプラグインによって提供されます。しかし、ReSharperにも、JavaScript、TypeScript、HTMLなどの多くの機能もあります。そこで現在、私たちは、フロントエンドとバックエンドの両方でコード分析、完了、コード生成などを行うことで、両方の世界のベストな機能を組み合わせることに取り組んでいます。

Rider 2018.2では、コードカバレッジと継続的テストが統合されました。これは別のバックエンドプロセスであるdotCoverによって実行されます。今後Riderに追加されうるその他の機能としては、dotTrace(JetBrainsのパフォーマンスプロファイラ)とdotMemory(JetBrainsのメモリプロファイラ)があります。現在、これらはWindows上でのみ実行されます。今後の我々のゴールは、これらのツールをmacOSおよびLinux上でも実行できるようにし、Riderの豊富なプロファイリング機能もそれらのプラットフォームでも利用可能にすることです。(※これらプロファイリング系機能を使用するためにはReSharper Ultimate + RiderまたはAll Products Packのご購入が必要です。

まとめ

.NETとASP.NET開発の将来は非常にエキサイティングであり、Riderはその一部になりたいと考えています。 JetBrainsはAzure、WinForms、WPF、Xamarin、.NET Coreなど.NET開発者が現在使用している多くのテクノロジのサポートを追加し、継続的に改善にも取り組んでいきます。 現在は、.NETソリューションを開く際の起動時間の改善や、エディタ上でのタイピング時におけるゼロ遅延機能を追加することによる、Riderのパフォーマンス向上に取り組んでいます。

また、将来的な機能拡張としては、ソリューションやプロジェクト内でC ++コードのサポート、プラグイン開発者がRiderのIntelliJフロントエンド、ReSharperバックエンドを拡張できるようにする、より簡単なSDKを提供することによるプラグインエコシステムの構築することを検討しています。

Rider IDE誕生までの歴史やアーキテクチャ、異なるテクノロジスタック上で動作する既存の製品を組み合わせる際に直面する課題を紹介するしました。これにより Riderに対する理解を深めていただけたら幸いです。

RiderはWindows、Mac OS X、およびLinuxで使用できる非常に豊富で有益な.NET IDEです。製品の詳細や無料トライアル、購入に関するお問い合わせはJetBrains Riderウェブサイト(英語日本語)または、日本の販売代理店までお知らせください。

お知らせ

2018年11月20日(火)午後6時より、JetBrainsの本社メンバーや日本における第一人者からベストプラクティスや最先端の現場からのユーザ事例を知ることができる貴重なイベントJetBrains Night Tokyo 2018を開催します。本記事の作者の一人である.NET関連製品スペシャリストの@maartenballiauwとも懇親会のAsk the specialistでお会いいただけます。以下から引き続きお申込み受付中です!
JB_Night_WS1 (1)

(2018年11月8日 追記)

突然ですが、2018年11月19日(月)午後7時より、株式会社ライフベア様のご厚意により、会場をお借りして、JetBrains “.NET” night Tokyo 2018を開催します。会場のキャパシティに限りがあり抽選による参加となる可能性がございますが、興味がございましたらぜひお申込みください!

https://lifebear.connpass.com/event/107559/

Posted in ReSharper, Rider | 3 Comments

IT導入補助金をご活用いただけます-JetBrainsのチームツールやIDE製品の導入に最大50万円の補助金が交付

it-hojo-jetbrains

IT導入補助金とは

IT導入補助金とは中小企業・小規模事業者(個人事業主含む)の業務効率化・売上アップをサポートするための支援事業です。
JetBrainsのパートナーである株式会社サムライズムはIT導入支援事業者として採択されておりJetBrainsのIDE製品、並びにチームツールが補助金交付の対象となっております。

IT導入補助金の対象事業者

主な対象事業者は以下の通りです。

業種・組織形態 資本金 常勤従業員数
製造業、建設業、運輸業 3億円 300人
卸売業 1億円 100人
サービス業(ソフトウエア業、情報処理サービス業、旅館業を除く) 5,000万円 100人
小売業 5,000万円 50人
ゴム製品製造業(自動車又は航空機用タイヤ及びチューブ製造業 3億円 900人
ソフトウエア業又は情報処理サービス業 3億円 300人
旅館業 5,000万円 200人
その他の業種(上記以外) 3億円 300人
医療法人、社会福祉法人 100人
特定非営利活動法人(NPO法人)

詳細につきましてはIT導入補助金 – 補助対象となる事業者をご参照ください。

また対象となるツールの導入実績がこれまでにない事業者に限られます。
交付申請が可能であるかどうかについて詳しくは「ITツールについて ~交付申請における考え方~」(pdf)をご参照ください。

スケジュール

現在三次公募を受付申請しており、2018年12月18日まで交付申請が可能です。
事業の実施、実績報告は2019年1月31日までとなります。
schedule
IT導入補助金 – トップページより

申し込み方法

株式会社サムライズム様のページよりお申し込みいただけます。交付申請まで多数の手続きがございます。余裕を持ってお申し込みください。
IT導入補助金をご利用いただけます – 株式会社サムライズム

Posted in お知らせ | Leave a comment

Kotlin 1.3リリース – コルーチン、Kotlin/Nativeベータ

Kotlin 1.3リリースです。もちろんビルドツール、ライブラリ、学習素材も同時リリースです。

JetBrainsはすべてのデベロッパーとって、あらゆる規模かつすべてのプラットフォームで優れたツールになるように、Kotlinの開発に取り組んでいます。 Kotlin 1.3では、コルーチンが進化して安定し、ノンブロッキングコードの読み書きが簡単になりました。 スケーラブルなアプリケーション開発がこれまでになく容易になりました。このリリースでは、KotlinコードをNativeバイナリに直接コンパイルするKotlin/Native ベータも導入されています。 Kotlinのマルチプラットフォーム機能は、サポートされているすべてのプラットフォームをカバーするようになりました。そのため、AndroidやiOSアプリなどのコンポーネント間でビジネスロジックを共有できます。 サーバーアプリケーションのロジックをWebやモバイルクライアントと共有でき、マルチプラットフォームライブラリにより、日々のタスクを簡単に移植できます。

1_3_banner_dark

1.3の主な機能を紹介する一連のウェブセミナーを開催します。こちらから登録できます。

コミュニティーとエコシステム

Kotlinは今年前例がないほど採用率が伸びています。 2018年1月以降、約150万のユーザーがKotlinコードを書きました。この数字は昨年の2倍以上に増えました。 StackOverflowでのトレンドと私たちのパブリックSlackでのトレンドも非常に励みになります。 私たちはKotlinコミュニティにサポートいただき、感謝しております!

Kotlin周辺のエコシステムが成長し、成熟しているのを嬉しく思います。 Kotlinは、Google Cloud PlatformSpring FrameworkGradle の友人であり、またもちろん、Androidのファーストクラスサポートは言うまでもございません。 オープンソースコミュニティは、RxKotlinmockito-kotlinTornadoFXKodeinΛRROW などの優れたライブラリを作成しています。 また、SquareのOkio やLibreOffice のようなプロジェクトは、Kotlinに移行しているか、そうする予定です。 ぜひ皆さん、素晴らしいアイデアやプロジェクトとともにKotlinエコシステムにご参加ください。

JetBrains以外の多くの方々に、pullリクエスト、バグレポート、そしてあらゆる種類のフィードバックで、Kotlin 1.3にご貢献いただきました。 皆様のご協力に本当に感謝しております。ぜひKotlinを一緒に、前進させていきましょう!

コルーチンがstableへ昇格しました

コルーチンは、理解しやすく進化しやすい、ノンブロッキングの非同期コードを書く現代的な方法です。 また、バックグラウンドワーカーへのワーク負荷の軽減から、複雑なネットワークプロトコルの実装まで、あらゆる用途でパワフルなツールです。 kotlinx.coroutinesライブラリは、構成、キャンセル、例外処理、UI固有のユースケースなど、あらゆる規模の非同期ジョブを管理するためのしっかりした基盤を提供します。

kotl.in/coroutines でスタート!
コルーチンウェビナーにいますぐ登録

Kotlin/Nativeベータ

Kotlin /Nativeは LLVM を使用し、iOS、Linux、Windows、Mac、さらに、WebAssemblyやSTM32などの組み込みシステムを含む、さまざまなオペレーティングシステムやCPUアーキテクチャ用に、Kotlinソースをスタンドアロンバイナリ(VMは不要!)にコンパイルできます。 またこれは、完全自動メモリ管理を搭載し、C、Objective-C(およびSwift)との相互運用が可能で、Core Foundation、POSIX、およびお好きなネイティブライブラリなどのプラットフォームAPIを公開しています。

Kotlin/Nativeランタイムはイミュータブルデータを活用して、スレッド間で保護されていないミュータブルなステートを共有することを防ぎます。実際に、スレッドはKotlin/Nativeには存在しません。スレッドは低レベルの実装の詳細として抽象化され、ワーカーに置き換えられます。これは、並行処理を行う安全で管理しやすい方法です。

kotl.in/nativeで Kotlin/Native について学べます。
ウェビナーに今すぐ登録

マルチプラットフォームプロジェクトとツール

すべてのプラットフォームで作業するのがKotlinの明確な目標です。しかしこれは、より重要な目標に対する前提と考えています。その目標とは、プラットフォーム間でコードを共有することです。 JVM、Android、JavaScript、およびNativeのサポートにより、Kotlinは最新のアプリケーションのあらゆるコンポーネントを処理できます。 また、これにより、コードや専門知識に計り知れない再利用のメリットが生まれ、すべての作業を2回以上実行することなく、より困難なタスク用に力を節約できます。 Kotlinのマルチプラットフォーム機能はまだ実験段階ですが、1.3は大きな前進となります。

Kotlin 1.3には、 HTTP シリアル化コルーチンの管理 などの日常的な作業をカバーするマルチプラットフォームライブラリが付属しています。 マルチプラットフォームコードを書く最も簡単な方法は、そのようなライブラリに依存することです。 プラットフォーム固有の依存関係を共通のAPIにラップする、あなた独自のマルチプラットフォームライブラリを作成できます。

プラットフォーム間でコードを共有:kotl.in/multiplatform
ウェビナーに今すぐ登録

Kotlin/Nativeとマルチプラットフォーム用のツーリング

Kotlin 1.3は、IntelliJ IDEA Community Edition、IntelliJ IDEA Ultimate、およびAndroid Studioで利用可能なKotlin / Nativeおよびマルチプラットフォームプロジェクト用のツールサポートを備えています。 エラーのハイライト、コード補完、ナビゲーション、リファクタリングなどのすべてのコード編集機能が、3つのIDEすべてでご利用いただけます。 私たちはコマーシャルツールとの高度な統合と機能に取り組んでいきます。

Ktor 1.0 ベータ

Ktorはコルーチンを使用してHTTPスタック全体を完全に非同期的に実装するアプリケーションフレームワークで、ベータ版をリリースしました。ktor.io でご利用いただけます。

その他の改善

これまでにご紹介したものすべてに加えて、このリリースには次のような機能と改善点が追加されています:

詳細は当社のWhat’s New ページでご参照ください。 変更ログはこちらで確認できます。 互換ガイドはこちらです。

KotlinConf

1.3リリースに関する最も熱い話題をカバーする、KotlinConf 2018の全動画を公開しました。 オープニングの基調講演とセッションの録画を観て、新機能や注目すべき点をご確認ください:

KotlinConf 2018の他の動画はJetBrains TVで

Kotlinを学ぶ

私たちはKotlinを簡単に、そして楽しく学べるように、全力を尽くしています。 利用可能な多数のリソースの中でも、特にこれらをハイライトしたいです:

  • Svetlana Isakova と Andrey Breslav による新しいコースが、Courseraで始まります。
  • Bruce Eckel と Svetlana Isakova による初心者向けの本、Atomic Kotlinが早期アクセスで公開されています。
  • 新しいplay.kotl.inミニウェブIDEには、Koans、例、埋め込み可能なコードスニペットがあります
  • EduTools プラグインは、IDEで直接Kotlinを学習するのに役立ちます
  • 認定Kotlinトレーニングが、世界中の複数のプロバイダからご利用いただけます。

Kotlin 1.3ウェビナーは、素晴らしいスタート地点になります。

アップグレード方法

いつものように、play.kotl.inKotlinをオンラインで試すことができます。

  • Maven、Gradle、npmでは:コンパイラと標準ライブラリ用のバージョン番号として1.3.0を使用します。 ドキュメントをこちらでご参照ください。
  • IntelliJ IDEAでは:2018.3にはKotlin 1.3がバンドルされています。以前のバージョンでは、Kotlinプラグインをバージョン1.3をインストールまたはアップグレードしてください。
  • Android Studioでは:Plugin Manager を使用してプラグインをインストールまたはアップグレードしてください。
  • Eclipseでは:Marketplace を使用してプラグインをインストールできます。
  • コマンドラインコンパイラは、Githubリリースページからダウンロードできます。

Let’s Kotlin!

P.S. このブログ記事については RedditHacker News、または下の欄でコメントを残すことができます。

[原文Original post in English is written by Roman Belov

Posted in Kotlin, お知らせ | Leave a comment