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

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

タグ:programming

「複数人でプログラミングを体験する」ための環境を作ることになった場合、その環境をどう実現すればいいかを考えました。
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日で)」ことになる点です。データベースを使うかどうかなど、サンプルに合わせたカリキュラムの検討が必要だと思っています。その代わり「プログラミング体験」という目的に合っていて、「まず一度体験してもらう」ための案としては自由度も高くて悪くない、と思っています。

 

このエントリの続きです:
Visual Studio Code Live Share でモブプログラミング(1)


前回 VSCode LiveShare を使うまでの準備段階とその手順を紹介しました。今回は実際に VSCode LiveShare を使ってモブプログラミングを行うまでの手順と、使っている時の様子を紹介します。

なお VSCode LiveShare を使う場合、開発画面を提供する人(ホスト、1名)と、ホストの開発画面を使って開発に参加する人(ゲスト、1名以上)それぞれで手順が異なります。以下順を追って紹介しますが、ホスト側の手順はこの色で、そしてゲスト側の手順はこの色でそれぞれ紹介していきます。


【ゲストの招待】
まずはホストとなる人からゲストとなる人へ、Live Share に参加するための URL を送信する必要があります。このホストとなる人の VSCode の環境(ファイルシステム、ファイル)を共有することになる点にご注意ください。この手順は前回紹介した準備手順が全て完了している状態から続けて以下を行います。


まず VSCode を開き共有するプロジェクトを1つ作成して開きます。ここで開いている画面を共有することになる点に注意してください。したがって関係のないプロジェクトフォルダが含まれるような画面ではなく、共有するプロジェクトフォルダだけが開いているような画面にしておくのがよろしいと思います:
2020042008


なお、この例ではフォルダの中に README.md ファイル1つだけが入っている状態からスタートする例を紹介します:
2020042105



プロジェクトの準備ができたら VSCode 画面左下の、ログインしている自分のアカウント名をクリックします:
2020042006


メニューが表示されたら一番上の Invite Others(Copy Link) と書かれた部分をクリックします。これで招待用 URL がクリップボードにコピーされた状態になります:
2020042007


そのままメールやメッセンジャーなどを使って、招待するゲストの人達全員に先程コピーした内容をペーストして共有 URL を送信します:
2020042009


ホスト役の人の作業はいったんこれで完了です。次はゲスト役の人達の作業となります。


【ゲストとしてプロジェクトに参加】
ゲスト役の人達は上述の最後の手順で送信された共有 URL 付きのメッセージを受け取ったら、そのリンクをクリックします:
VSCLS00



ゲストのログインが環境していない場合、ウェブブラウザで VSCode LiveShare を使うためのアカウントログインを行います。以下は GitHub を使って OAuth ログインする場合の画面です。必要であればアカウントにログインします:
VSCLS01


そして OAuth を行うため、内容を確認して Authorize ボタンをクリックします:
VSCLS02


ログインが完了すると以下のようなダイアログが表示され、Visual Studio Code が選択されていることを確認して「リンクを開く」ボタンをクリックします:
VSCLS03


この際に Live Share プラグインがこの URI を開くことを許可するか?と聞かれたら、OK をクリックして許可してください:
VSCLS04


またゲストが Windows を使っている場合、初回だけは Visual Studio Live Share Agent の実行をファイアウォールに許可する必要があります。以下の画面が出たら「アクセスを許可する」を選択してください:
VSCLS05


ここまで成功すると、ゲストの VSCode でホストの VSCode プロジェクトが共有されている状態になります。ホストが共有したプロジェクトをゲストの VSCode 内でも開いていることを確認してください:
20200421001


【ゲストがプロジェクトを編集】
ここから先の作業はホストでもゲストでもいいのですが、今回はゲストがプロジェクトを中心的に作っていくものとして紹介します。というわけで引き続きゲスト側の作業となります。

ゲストの VSCode 内で新規にファイルをプロジェクトに追加したり、そのファイルを編集したり保存したりすることができます。これらの変更はあくまでホストのファイルシステムに対する変更ですが、その作業はゲスト側から行うことができるようになっています:
20200421002


なお、このゲストが行った変更はホスト側の VSCode でもリアルタイムに変更が反映されます:
2020042101


更に同時にホストも、また他のゲストもプロジェクトの同じソースコードに対して変更を行うことが可能です。Google Drive の同時編集機能を使ったことがある人であれば、あれのソースコードプロジェクト版だと理解いただくとわかりやすいかもしれません。また他のファイルを編集することも可能ですが、共有される画面はあくまで1つ(ホストのもの)であることに注意してください。

このような共同作業を通じてプロジェクトを作っていきます。


【ターミナルの共有】
ある程度プロジェクトができあがると動作確認をしたくなります。VSCode LiveShare ではホストのターミナル(Shell や PowerShell)を共有してコマンドを実行することで動作確認作業を共有することが可能となっています。

実際にターミナルを共有するにはホスト側で再度画面左下の自分の名前をクリックし、表示されるメニューから Share Terminal を選択します:
2020042102


ターミナルに対するゲストの権限を指定します。"Read-only" はターミナル自体はホストだけが作業をして、ゲストはターミナルの様子を見ることができる、というモードです。一方 "Read/write" はゲストもターミナルに対してコマンドを実行することができるモードです。ターミナルはかなり強い権限で実行され、想定外のコマンドを指定されてもそのままホストのPC上で実行してしまうので、よほど信頼できる相手と共有している場合のみ後者を選ぶべきだと思います:
2020042103


ターミナルを共有すると、ホストの PC が Windows であれば PowerShell、それ以外であれば Shell 画面が VSCode 画面内に表示されます(ターミナルアプリを WSL などにを変更することも可能です 参照):
2020042104


同時にゲストの VSCode 画面内にも同じターミナルが表示されます。モードによってはゲストからこのターミナルにコマンドを指定して実行することも可能です:
20200421003


このターミナルから Node.js などのコマンドを実行するなどしてテストや動作確認を行い、その結果を全員が共有することが可能です。



と、このような形で VSCode LiveShare を使うことができます。実際にはこの機能とウェブ会議システムを併用して、ホスト役の人が行う内容をプレゼンテーションと音声で共有しつつ、実際のプログラミング時には VSCode LiveShare の画面を共有する形でモブプログラミングを進める、といったことができそうです。

この方法であれば、従来の画面共有だけを使ったモブプログラミングと比較して、エラーが発生した時の内容を共有しやすいという大きなメリットが挙げられます。ホスト役でない人の PC で発生したエラーの内容をホストやサポート役の人が把握するのが難しいのですが、VSCode LiveShare を使っていると、エラーの様子も共有されることになり、その内容からどこをどう直せばよいか、というアドバイスもしやすくなると考えられます。


普段のエディタは Vi(m) か ATOM(+vi プラグイン)を気に入って使ってます。軽量で使いやすく、vi の慣れたキーバインドで使えるという点にメリットを感じています。 が、最近になって Visual Studio Code(以下 VSCode)を vi キーバインドで使うという選択肢も気になっています。特に後述する Visual Code Live Share(以下 VSCode LiveShare)は、今日のようなオンライン中心のイベントや勉強会で使える共同開発ツールとしてポテンシャルを感じています。そんなわけで、このブログでも VSCode LiveShare を使ったモブプログラミング(共同開発作業)を紹介しようと思いました。まず今回は環境準備の説明です。


【前提条件】
Windows 7 以上、64 bit Linux、 または macOS 10.13 以上 を使っている必要があります。VSCode 自体は Raspberry Pi などの他環境向けにも提供されていますが、後述する VSCode LiveShare プラグインは動作環境が限られているようで、現時点(2020/04/20)では Windows, Linux または macOS を使う必要があるようです。


【VSCode のインストール】
VSCode の公式サイトから VSCode をダウンロードして(普通に)インストールしてください。なお、VSCode LiveShare を使う場合はバージョン 1.22 以上が必要です。


【VSCode LiveShare プラグインのインストール】
VSCode LiveShare は VSCode を使ったコーディングの共同作業を行うツールです。それを実現するための拡張機能が VSCode LiveShare プラグインです。このプラグインは共同作業におけるホスト役の人(自分のコードを他の人に編集させる人)だけでなく、ゲスト役の人(他の人のコードを編集する人)の環境にも両方にインストールが必要です。

インターネットに接続された状態で VSCode を起動し、画面左のメニューから Extension タブを選び、検索フィールドに Live Share と入力して検索します。その名の通りの Live Share プラグインが見つかるのでこれをインストールします:
2020042001


プラグインのインストールの最後にリロードを促されるのでリロードします。この後バックグラウンドで依存ライブラリのインストールが始まり、完了まで少し待ちます。

プラグインのインストールが完了すると画面左下が以下のようになり、Live Share が利用可能になっていることがわかるようになります:
2020042002


なお、VSCode に(日本語化パックや VIM など)他のプラグインを使う場合はこのタイミングで必要なものを導入しておいてください。


【ログイン】
VSCode LiveShare で共同作業する際、「誰が」コードを編集しているのかがわかりやすいようにログインする必要があります。VSCode LiveShare の場合、Microsoft アカウントまたは GitHub アカウントで OAuth 認証を行う必要があります。以下は GitHub アカウントを使ってログインする例を紹介します。

上述画面の Live Share と白抜きで表示されている部分をクリックしてログインします。下図のような表示になるのでログインに利用するアカウントを選んで進めます(以下は "Sign in with GitHub" を選んだものとして説明を続けます):
2020042003


選択したアカウントの OAuth 認証の画面が表示されます。内容を確認して、許可(Authorize)するボタンをクリックします:
2020042004


プログラムを起動するダイアログが表示されたら、"Visual Studio Code" が洗濯されていることを確認して「リンクを開く」をクリックします:
2020042005


再び VSCode の画面に戻ります。この時点で画面左下にログインしたアカウントのユーザー名が表示され、VSCode LiveShare を利用するための準備も完了しています:
2020042006


これで VSCode LiveShare を使う準備ができました。次回はこの続きで実際に VSCode LiveShare を使う様子を紹介する予定です。


(2020/04/23 追記 続きはこちら)
http://dotnsf.blog.jp/archives/1077356596.html


先日のこのブログエントリの続きであり、こちらのブログからのリレーブログでもあります。

ちょっとした隙間時間や空き時間をプログラミングに活用したい、そんな想いから先日の「通勤プログラミング」を書きました。 今回のテーマはその上級編、「脳内プログラミング」です。
nonai


私は暗算とか苦手ですが、あんな感じなんでしょうかね。与えられたテーマに対してプログラミング環境や(ケースバイケースですが)紙&鉛筆もなしに、頭の中だけでアルゴリズムを組み立ててコードに書き起こしていく、という作業です。

私自身、コードに書き起こすとなるとそれなりの準備というか道具が必要になりますが、「ランニングしながらアルゴリズムを考える」のは結構やってます。走る苦痛を妄想でごまかしているだけですけど。 あと会議中の「明らかに自分は関係ないなあ・・」という話題の時も、脳内ではシステムの設計してたりアルゴリズムを考えたりしてることはあります、はい。

悪く言えば職業病なんでしょうけど、よく言えば刺激的で楽しいから自然とやってる、という感覚です。その意味ではソリティアとかクロスワード、クイズに近い感覚なのかもしれません。


で、そんな脳内プログラミングですが、「そもそも何をプログラミングするの?」という方もいると思います。 もちろん脳内でできる範囲のプログラミングなので大規模な内容のは無理でしょう。上でも触れましたが、ちょっとしたクイズ感覚で空いた時間を健全な妄想で過ごす、というものです。この「ちょっとしたクイズ感覚」になるようなプログラミングのネタを探すのが簡単ではないのかもしれません。


で、そんなみなさんに私から提案。「CodeIQ やってみませんか?」

CodeIQ(コードアイキュー)はエンジニア向けのプログラミングチャレンジサイトです。与えられたお題に(多くの場合で)プログラミングで回答します。プログラミング言語の条件があるものやないものもあり、単に解ければいいものだったり、その実行速度が求められたり、なるべくコンパクトなコードに仕上げる必要があったり、、、と多くの問題から自分が解けそうなものを選んで挑戦できます。その結果フィードバックを見て、エンジニアとしての自分のスキル確認もできます:
https://codeiq.jp/

各設問の難易度にもよりますが、CodeIQ の問題を解くこと自体は(回答条件を満たしているかどうかはともかく)かなり簡単だと思っています。出題内容そのものは覚えられる程度で、そのロジックを頭の中で考えて、で時間のある時にコードに書き起こす、と。言ってみれば「脳内プログラミングにピッタリ!」だと思っています。

以上、僕が少し関わっている CodeIQ の宣伝でした(笑)。









一度、この話題でブログを書いてみたかった。

私は業務でもシステム系プログラマーですが、それとは全く別に、プライベートでも自分のためのウェブサービスを作ったり、たまにそれを公開したりしています。 ただ平日はほぼ朝から夜まで業務に携わっていて、プライベートでのプログラミング時間はかなり限られています。

そんな自分の時間をなるべく有効にプログラミングに充てるため、必然的に思いついたのが「通勤プログラミング」です。通勤時間をうまくプログラミング時間として活用しています。

ただ通勤プログラミングにはいくつか条件があります。まず「座れる」こと。座ってノートPCを取り出して膝の上でキーボードを開いて・・・というスタイルなので、立ったままではちと難しいです(まあ立ったまま「脳内プログラミング」をすることもありますが、こちらはかなり上級編だと思ってます)。いかに座席を確保できるか、というのも非常に大きな要素になります。私自身は電車の始発駅に居住していることもあって、「駅で少し待てば座れる」立場です。座ってしまえば最初の乗換駅まではプログラミングに充てられるため、それなりの時間を確保できます。

次に「通信手段の確保」も必要になることが多いです。駅にいる間は公共 WiFi を使えるケースもあるかもしれませんが、通勤での移動中はそうもいきません。タブレットで開発できるものであればタブレット自体の通信機能が使えるかもしれませんが、Eclipse を使うなどの本格的なプログラミングをするとなると現状はタブレットではなく、まだノートPCが必要になってきます。そしてノートPC単体では通信機能を持っていないケースがほとんどだと思うので、WiFi ルータなどのいわゆる「テザリング」環境を用意する必要があります。 プログラミング自体は通信なしでも可能ですが、サーバーアプリの動作を確認したり、デバッグやログを見る目的でサーバーインスタンスにリモートログインしたり、分からないことをちょっとググって調べたり、という際にネットワーク環境が必要になったり、あると便利だったりするので、この通信手段が確保できるかどうかも効率に影響します。

最近は「限られた短時間内で何をするのか?」を明確にしておくことも大事だと分かってきました。業務ではプログラミングに集中していて気が付くと1~2時間経っていた、なんてことも珍しくないのですが、通勤で座っていられるのは自分の場合はせいぜい30分程度です。この時間内に区切りが付くことをする、その1回のゴールを明確にしておくことも大事です。当たり前のことですが、この30分はプログラミングというか、コーディングのためだけに使いたいので、そのためにも前提となる設計や方針など座っていなくてもできることは可能な限り事前にまとめておき(あるいはプラットフォームで待っている間に脳内で行なっておき)、座ってノートPCを開いたらコーディングに集中する、というスタイルが理想です。

余談ですが、この超短期的なゴール意識は普段の業務にも好影響を与えているように思います。設計の時間と実装の時間を明確に分離することで、コミュニケーションを取る時間と一人で集中する時間のメリハリを付けるようになりました。集中できる時間はどうしても限られてしまうのですが、このスタイルを続けることで逆に集中しない時間をうまく活用できるよう、意識が変わってきていると感じています。

と、まあ簡単ですが、僕の通勤プログラミングはこんな感じ。 プログラミングに限らず、通勤中にノートPCを広げる人はたまに見かけるので同じようなことを考えている人はいるかもしれません。また、なるべく腕を動かさず、キーボード音もならないよう心掛けているつもりですが、それでも迷惑に感じている人がいるかもしれません。申し訳ないです。

本当は通勤プログラミングを快適に行う(笑)ためのアイテムやらコツやらにも触れたいのですが、それはまた別の機会に。こんな通勤プログラミングをしている人が他にいらっしゃるようであれば「PCは何使ってるの?」とか色々お話ししてみたいです。





 

このページのトップヘ