基本的に、https://cloud.google.com/appengine/docs/standard/python/getting-started/python-standard-env を実現する。

サンプルを、以下から入手

git clone https://github.com/GoogleCloudPlatform/python-docs-samples

入手後、/appengine\standard\flask\tutorial にFlaskのサンプルがある。

VisualStudio Codeで、デバッガを使用したいので、若干調整する。

1.ライブラリのインストール

1.1 実行Pythonの設定

が、、Python3.6、2.7 環境が混在しているため、pip –V でバージョンを確認すると、Python3.6の pip が起動しているため、とりあえず、Python2.7 のpipが起動するように環境変数(PATH)を変更する。

 %PYTHON_HOME%\Scripts
 %PYTHON_HOME%

PYTHON_HOME = C:\Programs\Python27-32  など、Python2.7へのパスを指定

当初、仮想環境を構築しようとしていたが、上記の手順に従うと、pipによりライブラリをインストールする先は、作業フォルダ lib 配下となるため、仮想環境は不要。

また、VS Codeから、ダイレクトにPythonを起動しないため、VS Code の python.pythonPath 設定では対応できない。

1.2 ライブラリをインストール

上記で入手したサンプルコードの、/appengine\standard\flask\tutorial ディレクトリから以下を実行

-t lib フラグを指定することで、ライブラリは 作業フォルダ以下のlib フォルダへコピーされる。App Engine にデプロイ時にアップロードされる。

(gaeflask) PS C:\workspaces\gcp\dokobingo> pip install -t lib -r requirements.txt

2.VS Code からデバッグを行う

基本的に以下のページに従う。

https://code.visualstudio.com/docs/python/debugging

Google App Engine は自身で起動するため、VS Code デバッガは直接利用できない。代わりに、ptvsd を使用して、Google App Engine をVS Codeがデバッガをアタッチできるモードで起動する。

3.1  ptvsd ダウンロード

https://pypi.python.org/pypi/ptvsd

上記からダウンロード。

VS Code 1.19.1 、Python 2.7 32 bit環境で検証しているが、現時点で最新版の、

pytvsd 3.2.1 ではデバッガがクラッシュしてしまう。3.2.0 、3.1.0 と試したがいずれもNG。

結局 pytvsd 3.0.0 が利用できたのでこちらを使用する。

作業ディレクトリへ展開する。

3.2 タスクの構成

tasks.json の構成を行う。

https://vscode-doc-jp.github.io/docs/userguide/tasks.html

dev_appserver.py のパスをGoogle SDKのパスに変更する。

  {
      "version": "0.1.0",
      "command": "python",
      "isShellCommand": true,
      "showOutput": "always",
      "args": [
          "C:\\Programs\\Google\\Cloud SDK\\google-cloud-sdk\\bin\\dev_appserver.py",
          "--python_startup_script=${workspaceFolder}/pydev_startup.py",
          "--automatic_restart=no",
          "--max_module_instances=default:1",
          "${workspaceFolder}/app.yaml"
      ]
  }

3.3 デバッグ構成

デバッグビューのトップバーにある歯車アイコンをクリックすると、VS Codeはワークスペースの.vscodeフォルダーの下にlaunch.jsonファイルを作成するので、以下のエントリを追加

https://vscode-doc-jp.github.io/docs/userguide/debugging.html

{
    "name": "Python: GAE(Attach)",
    "type": "python",
    "request": "attach",
    "localRoot": "${workspaceFolder}",
    "remoteRoot": "${workspaceFolder}",
    "port": 3000,
    "secret": "gae",
    "host": "localhost",
    "preLaunchTask": "python"
},

3.トラブルシュート

実行で、以下のようなエラーが出る。

Traceback (most recent call last):
  File "C:\Programs\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\runtime\wsgi.py", line 240, in Handle
    handler = _config_handle.add_wsgi_middleware(self._LoadHandler())
  File "C:\Programs\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\runtime\wsgi.py", line 299, in _LoadHandler
    handler, path, err = LoadObject(self._handler)
  File "C:\Programs\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\google\appengine\runtime\wsgi.py", line 85, in LoadObject
    obj = __import__(path[0])
  File "C:\workspaces\gcp\dokobingo\main.py", line 19, in 
    from flask import Flask, render_template, request
ImportError: No module named flask

https://github.com/pallets/click/issues/594

を参考に、appengine_config.py を以下に書き換える

import os
import sys
from google.appengine.ext import vendor
 
vendor.add('lib')

print os.environ.get('SERVER_SOFTWARE', '')

if os.environ.get('SERVER_SOFTWARE', '').startswith('Google App Engine'):
    sys.path.insert(0, 'lib.zip')
else:
    if os.name == 'nt':
        os.name = None
        sys.platform = ''

4.実行

本来は、デバッグビューから、上記3.3で追加した構成を実行すればよいはずだが、うまくアタッチされないため、別々に実行する。

run_debug

4.1 開発サーバーの実行

コマンドパレット(Ctrl+Shift+p) から、ビルドタスクの実行。これで開発サーバーが起動される。run_task

4.2 その後、デバッグビューから、Python:GAE(Attach) を実行

debug_desktop

ブレークポイントで止めることができるようになった。

CSharpBooks

約20年前鳴り物入りで登場した .NET の代表言語、C#。

当時.NETじゃないVBプログラマーだった自分は、オブジェクト指向?UML?フレームワーク?と悩みながら勉強を重ねて主にサーバーサイドのJavaプログラマーに転身していった。

オブジェクト指向が定着した後、軽量言語だとか設定より規約だとか関数型言語だとかさまざまなはやりの中、Javaが言語の拡張に対し慎重であるのに対し、C#は貪欲にそれら新しい概念を取り入れてきたように感じる。

そういう経緯もあり、こちらとしては何年もかけて常識として理解していることを、ゼロから学ぶ必要があるという意味において、C#という言語は初学者にとって「複雑」すぎるのではないか?かつてVBプログラマーだった自分がC++に感じたように迷宮のような言語になっているのではないか?と。やはり、後発のKotlinなどを見るとそう思う。

が、言語の適用範囲、シェアを考えると、JavaやC#は今後も重要な位置を占めていくに違いない。本書はC#が持つ歴史的な経緯による複雑さを、絶妙なレベルで体系的だてて説明することに成功しており、独習をうたうだけあり初学者にもお勧めすることができる。本書の著者の書籍を本書以外にも数冊読んだが、概念を体系立てて説明する著者の能力には感服する。どの書籍においても説明の分量が多すぎず、少なすぎず、冗長さはそぎ落とされており教科書的でもあるが、けっして無機質な文章ではなく読みやすい。

また、本書はかなり厚い本となっているが、都度バックグラウンドの説明、例えば「オブジェクト指向」とはそもそもどんな考え方なのか、ある実装について複数の方法がある場合、現在はどちらを採用するのが主流かなど著者の主観が入りそうなところは「エキスパートに聞く」として、また、正規表現や、日付の取り扱い、ファイル操作、サロゲートペアを含んだユニコードの説明など、著者は実務で何が必要で、はまりどころはどこかをわかっているなと感じさせる記述などが丁寧に説明される点などを見ると、逆にこの厚さによくこれだけの情報を無駄なく詰め込めるものだと感心する。

ちなみに、プログラミングC# 第7版 と比較すると、プログラミング言語C# 第7版が741ページに対して、本書 は606ページと若干薄いが、前者がXAML、ASP.NETなどの周辺技術の記述に100ページ程度割いている違いがある。本書は基本的に言語仕様の説明に焦点を絞っているが、その点については両者ともほぼ同じ範囲をカバーしているように見える。

初学者が利用、リファレンスとして手元に置くには本書が適していると思う。逆に言えば、ある程度実務でC#を利用している人には、すでに知っている知識も多いだろうと想定されるので、プログラミングC# 第7版 のほうがマニアックな掘り下げ方物語などから楽しんで読めると思う。

WINGSプロジェクト様より本書(独習C#)を献本いただき、レビューさせていただきました。

Windows 10 Home は、リモートデスクトップのサーバー側にはなれない。

Windows 10 10 Pro だとなれる。VNCだとか、Chrome リモートデスクトップだとか使えば、遠隔操作はできるんだけど、リモートデスクトップの遠隔操作をしていることを感じさせない使用感から比べると一つ落ちる。

というときに、WDP Wrapper というソフトをインストールすると、Windows 10 10 Homeをリモートデスクトップのサーバーとすることができる。

https://github.com/stascorp/rdpwrap/releases

手順としては、上記サイトからから、

  1. 最新バージョンのzip ファイルをダウンロード解凍(今回は、RDPWrap-v1.6.1.zip の話)
  2. install.bat を管理者として実行
  3. update.bat を管理者として実行
  4. 再起動

。。。これで問題なければOK、ならよかったのだが、ちょっとはまったので、メモ。

1.Lisner state が not listening になっていて接続できない

上記 zip を解凍したフォルダに、RDPConf.exe があるので、実行すると設定画面が開くが、Listener state: Not listening となっている。

drp_error

また、RDPCheck.exeを起動すると、接続の確認ができるのだが、エラーとなってしまう。

2.対処手順

Listener is not listening on Win 10 Home (build 14997+) のスレッドの手順から、

2.1 rfxvmt.dll の適用

(1) RDP Wrapperサイトからダウンロードし解凍

64-bit Windows 10 : https://github.com/stascorp/rdpwrap/files/1236856/rfxvmt.zip
32-bit Windows 10 : https://github.com/stascorp/rdpwrap/files/1238499/rfxvmt.zip

(2) 解凍して、できた rfxvmt.dll を c:\Windows\System32 フォルダ直下にコピー

3.確認

RDPConf.exe を起動すると、not listening が listening になっている!

rdp_wrapper01

RDPCheck.exe を起動すると、以下の確認メッセージのあと、

rdp_wrapper02

どうやら接続確認できたようだ。

rdp_wrapper03

別PCから確認してみる。

通常とは少し異なる確認メッセージが表示されるが続行

rdp_wrapper04

OK!接続できた。

rdp_wrapper05

これは捗る。