まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:eclipse

ある意味、先日のこの記事の続きです:
「チームでアプリケーション開発を体験したい」、どうやる?


1つの案として(候補案4の)「オンラインエディタを使う」方法を紹介しました。ここで紹介したオープンソースのオンラインエディタ Eclipse Orion を Linux サーバーに、特に docker 環境下で簡単に導入する方法を紹介します。なお、ここでの「 docker 環境下」は正確には「x86_64 チップの docker 環境下」とさせてください(後述する docker イメージが linux/amd64 アーキテクチャ向けのため)。


まずは docker 環境を用意します。既に手元にあれば飛ばしていただいて構いませんが、こちらを参考いただくなどして環境にあった方法で docker エンジンが起動している状態にしておいてください:
Docker のインストール

今回紹介する方法ではこちらの Eclipse Orion 用 docker イメージを使わせていただきます:
https://hub.docker.com/r/cloudeity/orion


早速 docker pull して、・・・の前に、Eclipse Orion が参照する対象となるフォルダを自分の手元に用意しておきます。フォルダが空の状態から始めるのであれば空のフォルダを用意すればいいのですが、サンプルファイルが含まれた状態で始めるのであれば、対象ファイルがコピーされた状態のフォルダを用意しておく必要があります。

今回は以下のような index.html ファイル1つだけが用意されたフォルダを /tmp/web/ 以下に準備することにします(別のフォルダでも構いませんが、以下の内容を読み替えてください)。まず /tmp/web というフォルダを作ります(後でこのフォルダを Eclipse Orion の作業フォルダとします):
$ mkdir -p /tmp/web


そして以下の内容の index.html を作って、/tmp/web/ フォルダにコピーしておきます(/tmp/web/index.html ファイルを作ります):
<html>
Hello World.
</html>

改めて docker を使って Eclipse Orion をインストールします。まずは docker pull でイメージをダウンロードしておきます(初回のみ):
$ docker pull cloudeity/orion

次にコンテナ化して起動するのですが、その際に -v オプションで作業フォルダをボリューム指定します。今回のように /tmp/web を作業フォルダとする場合は以下のコマンドを実行します:
$ docker run -d --name orion -v /tmp/web:/opt/orion.client/modules/orionode/.workspace -p 8081:8081 cloudeity/orion

コマンドの実行に成功したらウェブブラウザで 8081 番ポートにアクセスします。成功していると /tmp/web フォルダがプロジェクトフォルダとなって、ウェブブラウザ画面から既存の index.html ファイルを編集したり、新規にフォルダやファイルを作成したり、編集したりができるようになります:

(同じマシンから http://localhost:8081 にアクセスした時の画面。他マシンからアクセスする場合は localhost 部分を IP アドレス指定にします)
2021022301

(index.html ファイルを選択するとエディタが開き、直接編集できます)
2021022302


Eclipse Orion 自体を終了するには docker コンテナを止めます:
$ docker stop orion




「複数人でプログラミングを体験する」ための環境を作ることになった場合、その環境をどう実現すればいいかを考えました。
computer_mob_programming


より具体的にはこんな状況・前提だと思ってください(余談ですが DX の影響なのか、業務でこういう需要を耳にする機会が増えているように感じてます):
- 複数人でアプリ開発(プログラミング)体験を行いたい
  - 参加者は1チーム5~6人程度
  - 参加者は普段 Windows を使っている。Mac, Linux の経験はほぼゼロ
  - 参加者はコマンドプロンプトなどの CLI は普段使っていない
  - 参加者はプログラミングに関してはほぼ初心者
- チームで1つのアプリを作って動かす、という体験をしたい
- 体験期間は半日、長くて1日
- 参加者の PC に何かをインストールしたり、アカウントを作ったり、設定したりする場合、作業できるのは当日
  - 参加者 PC 以外の Linux サーバーなどに主催者が事前準備するのは自由
- 全員オンライン参加、zoom などのオンラインツールの利用に問題はない


最後の前提は必須ではないですが、昨今だとどうしてもこの条件になるかなあ、ということで加えています。


この状況下でどういう仕組を用意すれば、目的に会ったプログラミング体験ができるかを考えます。


候補案1
「とりあえず正攻法でやってもらう」方法です。ソースコードは git などでリポジトリ管理して(必要であれば事前にサンプルを用意して)、各自はリポジトリから clone したソースコードを画面共有を併用しながら手元で編集して動かしてもらう。環境が許せば Visual Studio Code の LiveShare なども使って共同編集する。。

・・・これが本来のスジであることは重々承知しているし、将来的に役立てることを意識するならこの形を学ぶべきだとは思っています。ただプログラミング初心者相手に半日~1日でここまでやるには少しハードルが高すぎる気がしています。環境準備段階でのハードルの高さもありますし、git も教えないといけないし、LiveShare 使うならアカウントから準備しないといけないし、その上でほぼ未経験のプログラミングをオンラインで・・・ 何を作るかにもよりますが、Hello World 程度すら厳しいかも。。

#おまけとして、業務においてはこの手の「管理者権限が必要な作業」自体が実施上のリスクとなる可能性があることを経験談として触れておきます。


候補案2
参加者がそこそこ Linux に詳しい人だったら、Linux サーバーにサンプルを含むソースコードを集める形にして、全員が個別に SSH や VNC でログインして vi でプログラミングすればよい、です(同時編集によるコンフリクトはいったん目をつぶりますw)。同じサーバーでアプリを動かせば、それぞれがウェブブラウザで動作確認もできます。

でも今回、この形で行うにはハードルが高すぎます。普段から SSH やコマンドプロンプトを使うような人ではなく、ましてやキーバインドにクセのある vi を使わせるのは厳しそうです。

手段の1つとして「SSH でログインして nano エディタを使う」ことや「Linux に X Window まで導入した上で、VNC でログインして簡易テキストエディタを使う」も考えられます。これらはありっちゃあり、懸念があるとすれば慣れない CLI や Linux での操作でしょうか。nano エディタも vi や Emacs ほどクセはありませんが、Linux コマンドを無視することもできませんし、CTRL キーや ALT キーと組み合わせてのメニュー操作は慣れるまでは苦労するかも、という印象です。

その辺りの苦労も体験の一部とみなしてやってもらう、という案は相手次第ではあり、かな。。


ここまで書いておいてアレですが、個人的にはここまでの案1&2は現実的ではないかな、と考えています。オンラインでなければまだしも、オンラインでこの慣れてないはずの作業のサポートをするのはかなり難しそうという印象を持っています。理想どおりに実施するのことがかなり厳しそう・・・


候補案3
いわゆるローコード・ノーコード環境を事前に Linux サーバーに用意して、この環境を使う方法です。

これは目的に対する解答になっていると思います。Linux に例えば Node-REDScratch などをインストール&起動しておいて、参加者は画面共有しながらウェブブラウザで(CLI ではない、ここがでかい!)アクセスしてコーディング作業を行う、というものです。なんといっても参加者の PC に何かを事前にインストールする必要がない(=準備段階のリスクが低い)点がポイントです。ローコードなのでプログラミング開始時の敷居が低く、1日でもそこそこ学べるものだと思っています。

懸念が2つあるとすれば、この環境が1つは共同作業に適したツールかどうかの判断や対応が必要になる点と、もう1つはやはりどうしてもできることの制限があることです。ローコードであるが故に「ループ」や「条件分岐」といったコーディングの基礎のようなことを行う選択肢が少なかったりするわけです(ループができないとは言わないけど「整数配列をその数だけループさせながら加算する」とかは Node-RED では難しい)。動くものは作れるかもしれないけど、プログラミング体験という当初の目的を達成できるものになるかどうか、が鍵だと感じました。


候補案4
実はいま個人的にはこれが一番いいかも、と考えているのが、この候補案4です。概要はこんな感じ:
(1) サンプルを含むソースコードを事前に Linux サーバーに用意する
(2) 同サーバーに Eclipse Orion をインストールする
(3) 参加者はウェブブラウザで Eclipse Orion にアクセスして、サーバーのソースコードを直接編集
(4) 誰か一人(主催者でもよい)がサーバーでアプリを起動して動作確認

(1) のサンプルはあらかじめ最低限動くものを用意しておきます。目的にもよりますが、Hello World 表示だけのウェブアプリでもかまわないと思ってます。

(2), (3) の Eclipse Orion は「オンラインテキストエディタ」です。サーバー上で起動し、サーバー内の特定フォルダ以下のテキストファイル(ソースコード)をオンラインで編集できるようになります。テキストエディタとしての基本機能があるので、便利にコーディング作業をすすめることができます。オンラインエディタは必ずしも Orion エディタでなくてもいいと思ってますが、オープンソースであることや docker 環境下で使える便利さもあっておすすめです。

(4) そして編集したソースコードを使って実際に動かし、可能であれば全員がウェブブラウザで動作も確認する、というものです。

この方法も候補案3同様に、参加者 PC 側での事前準備が不要です。CLI 操作もなく、全て GUI 作業です。Java なり JavaScript なりの実行環境もサーバーだけに事前に用意しておけばいいので参加の負担はありません。実際にコーディングも行うので、内容も(分岐やループから、外部API へアクセスしての AI 体験みたいなことまで)自由度高く設計可能です。

プログラミング環境も、Eclipse Orion インスタンスを1つだけ起動して、全員で同じインスタンスに接続して共同プログラミングしてもいいし、Eclipse Orion インスタンスを複数起動して別々に接続させることで同じテーマで個別にプログラミングすることもできます。純粋なプログラミング環境を比較的容易に準備する方法と考えます。


こちらの懸念はあらかじめ用意しておくサンプルをどうするかと、候補案3と異なり「実際にプログラミングを行う(しかも半日~1日で)」ことになる点です。データベースを使うかどうかなど、サンプルに合わせたカリキュラムの検討が必要だと思っています。その代わり「プログラミング体験」という目的に合っていて、「まず一度体験してもらう」ための案としては自由度も高くて悪くない、と思っています。

 

IBM Cloud(Bluemix) のアカウントを所有していると、マネージドサービスとして利用できる GitLab が使えるようになります。サーバーのインストールなどは不要で、プライベートリポジトリを作成することも可能です:
2018011701


使い勝手は GitLab そのものだと思ってください。Issues 管理の機能も使えますし、IBM Cloud の Continous Delivery サービスと連携した Delivery Pipeline による DevOps サービスの一部としても利用できるようになっています。アカウントをお持ちの方は、単にプライベートリポジトリが使える Git として考えるだけでも便利だと思うので、是非活用してください。


ところで、この IBM Cloud の Git を使って Java のアプリケーションコードを管理しようと、作成したリポジトリから Eclipse の Git 機能を使って clone を試みた際に、稀に以下のようなエラーメッセージに遭遇し、クローンに失敗することがあります:
  :
  :
!MESSAGE https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
!STACK 0
org.eclipse.jgit.api.errors.TransportException: https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
  at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:196)
  at org.eclipse.egit.core.op.ListRemoteOperation.run(ListRemoteOperation.java:99)
  at org.eclipse.egit.ui.internal.clone.SourceBranchPage$8.run(SourceBranchPage.java:324)
  at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: org.eclipse.jgit.errors.TransportException: https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
  at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:499)
  at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:308)
  at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:175)
  :
  :

「git-upload-pack がオープンできない」という耳慣れないエラーメッセージで、実はこのメッセージそのものからは原因の追求が難しいものでした。同じようなエラーに遭遇する人が現れた場合に備えて、自分の経験と回避策を紹介します。

エラーメッセージそのものからはわかりにくにのですが、実は直接の原因は暗号化方式の不一致による通信エラーでした。

まず上記で紹介した IBM Cloud の Git 機能を https 接続で使う場合の暗号化方式には TLS v1.2 を使う必要があります:
https://console.bluemix.net/docs/services/ContinuousDelivery/git_working.html#git_local


さて、Eclipse が使う Java のバージョンが 1.8 以上であれば、デフォルト設定のままで TLS v1.2 が使われます。したがってこの場合は何もしなくてもそのまま IBM Cloud の Git を利用することができます。

一方、Eclipse の Java バージョンが 1.7 以下だった場合、デフォルト設定で採用される通信方式は TLS v1.1 以下です。つまり条件を満たしていないことになります。そしてこの条件で Git に接続しようとすると上記のようなエラーメッセージが表示されてしまうのでした。


では、このエラーメッセージが出た場合の解決策はどうすればいいのでしょうか? 1つの方法としてJava のバージョンを 1.8 以上にするという簡単な方法があります。Java 1.8 以上であれば上記のように(デフォルトで) TLS v1.2 が使われるので、この条件を満たすことができるようになります。

ただ何らかの事情で Java 1.8 を導入するわけにはいかない場合もあると思っています。そのような場合は以下の1行を eclipse.ini に追加した上で Eclipse を起動する、という方法もあります:
  :
  :
-Dhttps.protocols=TLSv1.2

この記述により、Java が 1.7 以下であっても強制的に https 接続時の暗号化方式を TLS v1.2 に指定することができ、やはり上記のエラーを回避することができるようになります。


IBM Cloud 以外の Git でも、同様のエラーメッセージが出た場合にはこの対策が有効だと思っています。頭の片隅に入れながら、無料で便利な IBM Cloud の Git を是非使ってみてください。


EclipseNode.js アプリケーションの開発(というかデバッグ)を行うことができるような環境を作ります。そのために Nodeclipse というプラグインを導入します:
2017022001


導入手順は Eclipse のメニューから Help - Install New Software を選択し、インストール元の URL には "http://nodeclipse.org/updates/" を指定します。しばらく待つと導入可能なプラグインの一覧が表示されるので、"1st Nodeclipse Core" と "Enide Tools Collection" の2つにチェックを入れてインストール作業を続行します。最後に Eclipse を再起動するよう指示されるので再起動します:
2017022002


導入作業はこれで終わり。以下は使い方の説明です。Eclipse が再起動したら、Node.js のアプリケーションプロジェクトが作れるようになっています。

Eclipse のメニューから File - New - Project を選択するとプロジェクトウィザードが起動します。その選択肢の中に Nodeclipse カテゴリがあり、そこから Node.js や Node.js Express のプロジェクトが作れるようになっているはずです。今回は試しに "Node.js Express Project" を選んでみました:
2017022003


いつものようにプロジェクト名(以下の例では "MyExpress01")を入力し、属性を設定します。テンプレートエンジンが何種類かの中から選べそうだったので、今回は個人的に慣れている ejs を選んでみました。最後に "Finish" をクリックしてプロジェクトを作成します:
2017022004


Node.js Express プロジェクトが作成された直後の様子です。ejs テンプレートを使ったシンプルなアプリケーションが生成されています。興味ある方は中身を個別に確認してみてください:
2017022009


Eclipse の全体画面がこちら。右上を見ると Node.js 用のパースペクティブが追加され、同パースペクティブで開いていることが確認できます:
2017022000


特に明示的には何も手を加えていないこの状態で一度実行してみることにします。app.js を右クリックし、Run As - Node Application を選択します:
2017022006


コンソールに起動メッセージが表示されます。3000 番ポートで起動しているようです:
2017022007


というわけでウェブブラウザで localhost:3000 にアクセスしてみます。こんな画面になれば成功です。このページ自体は app.js から routes/index.js が呼ばれ、views/index.ejs をテンプレートとしたレンダリングが行われた結果が表示されています。ここまで確認できたら一旦サーバーを停止しておきましょう:
2017022008


では次に今の様子をデバッグしてみることにします。まず routes/index.js を開き、レンダリングを行っている箇所にブレークポイントを仕掛けてみます(該当行の左側をダブルクリックしてブレークポイントマークが付いたことを確認します):
2017022001


今度はデバッグモードで Node.js を起動します。app.js を右クリックして Debug As - Node Application を選択します:
2017022002


デバッグモードでの起動を明示したので、Eclipse のパークペクティブをデバッグ用に切り替えるか?という確認ダイアログが表示されることがあります。その場合は "Yes" を選択します:
2017022003


Debug パースペクティブに切り替わります。同時にアプリケーションがデバッグモードで起動し、最初の1行目で止まった状態になります(まだ起動していないのでブラウザからはアクセスできません)。F8 を押すか、メニュー下の Resume アイコン(右向きの緑の矢印)をクリックして、実行を続けます:
2017022004


コンソールに先程のようなメッセージが表示されるとサーバーが起動してことを意味します。ではあらためてこの状態でウェブブラウザから localhost:3000 にアクセスしてみます:
2017022005


先程のような画面が表示される前にブレークポイントを設定していたので、そこで停止しているはずです。Eclipse の画面を確認すると指定したブレークポイントで止まっている様子が確認できるはずです:
2017022006


この状態で各種変数の値を確認したり、ステップ実行したり、・・・といった、いわゆるデバッグ作業を行うことができるようになっています。最後にもう一度 Resume して処理を続けます:
2017022007


Resume 後にウェブブラウザを確認すると、先程と同じ画面が表示されているはずです:
2017022008



Nodeclipse の紹介はざっとこんな感じ。ところで、Node.js の開発に Eclipse を使うのって、結構マイノリティな気がしているが、実際のところどうなんでしょ??


(参考)
http://qiita.com/suesan/items/7f2c4863feb87a623517

普段は Eclipse で Java のコーディングをしています。そして開発時のアプリケーションサーバーには Jetty を使っています。最近この開発環境を構築する際の手順を久しぶりに行ったのでまとめておきました:

まず Eclipse に Java EE の開発環境までは導入済みであると仮定します(或いは初めから Java EE 開発環境を選択して Eclipse をインストールします)。その Eclipse に Jetty のプラグインを導入して、開発環境を構築します。

Jetty プラグインをインストールするには、Eclipse のメニューから Help - Eclipse Marketplace を選択します:
2017013101


マーケットプレースのダイアログが開いたら、検索ボックスに "jetty" と入力して検索します。検索結果の中に
 ・Eclipse Jetty
 ・Run-Jetty-Run
が含まれているはずなので、これらを1つずつインストールします(まとめての導入はできないので、2回に分けてインストールを実行します)。インストールが完了したら Eclipse を再起動:
2017013102


これで開発用アプリケーションサーバーに Jetty を使った開発が可能になります。開発中のウェブアプリケーションをこの環境下で実行するにはプロジェクトを右クリックし、Run As を選ぶと、実行方法の選択肢の中に "Run Jetty" というものが追加されているはずです。これを選択します:
2017013103


すると選択中のウェブアプリケーションが Jetty に読み込まれた形で起動します。起動時のポート番号は 8080 番です:
2017013104


ウェブブラウザで http://localhost:8080/(プロジェクト名) にアクセスすると、開発中のウェブアプリケーションに試験アクセスすることができます:
2017013105


今はいちいち Jetty を別途インストールする手間とか不要になったんですね。こりゃ便利!

このページのトップヘ