ExcelVBAdeで少数点以下あれば表示

以外にも、小数点以下があれば小数点を表示するというVBAが中々うまくいかなかったので備忘録。(A1が対象セルです)
結論として、入力規則を2つ定義するイメージです。
1つ目は小数点ありの場合、2つ目は小数点がない場合の入力規則です。
Dim xlFormatCondition As FormatCondition, xlFormatConditions As FormatConditions
Dim r As Range: Set r = Range(“A1”)
If r.FormatConditions.Count > 0 Then
For Each xlFormatCondition In r.FormatConditions
xlFormatCondition.Delete
Next
End If
Set xlFormatConditions = r.FormatConditions
‘小数点ありの場合の入力規則
Set xlFormatCondition = xlFormatConditions.Add(Type:=xlExpression, Operator:=xlLess, Formula1:=”=IF(RIGHT(TEXT(A1,””0.#””),1)=””.””,FALSE,TRUE)”)
xlFormatCondition.NumberFormat = “#,##0.#;[赤]-#,##0.##”
xlFormatCondition.SetFirstPriority
xlFormatCondition.StopIfTrue = True
‘小数点無しの場合の入力規則
Set xlFormatCondition = xlFormatConditions.Add(Type:=xlExpression, Operator:=xlLess, Formula1:=”=IF(RIGHT(TEXT(A1,””0.#””),1)=””.””,TRUE,FALSE)”)
xlFormatCondition.NumberFormat = “#,##0;[赤]-#,##0”
xlFormatCondition.SetFirstPriority
xlFormatCondition.StopIfTrue = True

蛇足
入力規則で制限する場合
With Selection.Validation
  .Delete
  .Add Type:=xlValidateCustom, AlertStyle:=xlValidAlertInformation, Operator:= _
  xlBetween, Formula1:=”=A1*100=INT(A1*100)”
  .IgnoreBlank = True
  .InCellDropdown = True
  .InputTitle = “”
  .ErrorTitle = “小数点以下入力桁数エラー”
  .InputMessage = “”
  .ErrorMessage = “小数点以下は2桁まで入力可能です。”
  .IMEMode = xlIMEModeAlpha
  .ShowInput = True
  .ShowError = True
End With
・Type 必ず指定します。入力規則の種類を指定します。
  xlValidateInputOnly:すべての値
  xlValidateWholeNumber:整数
  xlValidateDecimal:小数点
  xlValidateTextLength:文字列(長さ指定)
  xlValidateList:リスト
  xlValidateDate:日付
  xlValidateTime:時刻
  xlValidateCuestcm:ユーザー設定

・AlertStyle 省略可能です。入力規則でのエラーのスタイルを指定します。
  xlValidAlertStop:停止
  xlValidAlertWarning: 注意
  xlValidAlertInformation:情報

・Operator 省略可能です。入力規則での演算子を指定します。
  xlBetween:Formula1とFormula2の間
  xlEqual:Formula1と等しい
  xlGreater:Formula1より大きい
  xlGreaterEqual:Formula1以上
  xlLess:Formula1より小さい
  xlLessEqual:Formula1以下
  xlNotBetween:Formula1とFormula2の間以外
  xlNotEqual:Formula1と異なる

・Formula1 省略可能です。データの入力規則での条件式の最初の部分を指定します。

・Formula2 省略可能です。データの入力規則での条件式の 2 番目の部分を指定します。
引数OperatorがxlBetweenまたはxlNotBetween以外の場合、この引数は無視されます。

参考
https://qiita.com/Q11Q/items/f035b383620eb308bc2b
https://excel-ubara.com/excelvba1/EXCELVBA391.html
https://hipstergate.jp/column/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3%E5%BF%8D%E6%B3%95%E5%B8%96%EF%BD%9E%E5%B0%8F%E6%95%B0%E7%82%B9%E4%BB%A5%E4%B8%8B%E3%81%8C%E3%81%82%E3%82%8B%E6%99%82%E3%81%A0%E3%81%91%E8%A1%A8%E7%A4%BA%E3%81%99/

この接続ではプライバシーが保護できません。

ShowCase.siteの証明書にLet’s Encryptを使用しているのだが、90日を過ぎた時点で「この接続ではプライバシーが保護できません。」(NET:ERR_CERT_DATE_INVALID)と表示され、サイトが開けない状態に。
証明書発行の更新はcrontabで自動更新しているので、問題ないはずなのに。
>sudo certbot renew
で手動更新してもかわらず。
試行錯誤後、nginxをリスタートしたら、無事サイトが開けた。
>sudo systemctl restart nginx
crontabは
00 09 1 * * /usr/bin/certbot renew -q –renew-hook “/bin/systemctl reload nginx”
reloadが間違ってたってことか...

ValueError: Related model ” cannot be resolved

クライアント環境で新たに追加したテーブルを既存テーブルの項目として外部キーを指定して追加した後、デプロイ先のクラウド環境へ同様の作業を行おうとして、躓いたので備忘録。
新たに追加したテーブルを既存のテーブルの項目として追加し、外部キーとして追加した。
作業手順としては、
・新しいテーブルを作成
・新しいテーブルにデータを追加
・既存テーブルの項目に新しいテーブルの外部キーを追加
ところが、デプロイ先ではこの手順で作業しようとすると、
>python manage.py makemigrations
を実行した時点で、
ValueError: The field [既存テーブルの項目名] was declared with a lazy reference to ‘[アプリ名.追加テーブル名]’, but app ‘[アプリ名]’ doesn’t provide model ‘追加テーブル名’.
と怒られた。
そこで、どうやら、手で追加したテーブルがmigrationとして認識されていないなと思い、手作業で追加したテーブルをdropして、magrationsフォルダの下の最新のmigration実行用ファイル(000n_auto_YYYYMMDD-HHFF.py)の追加したテーブル部分だけを残してそのほかを削除し、
>python manage.py migrate
を実行して、データを管理画面から手で追加。
再度、最新のファイルの内容を既存テーブルの項目(migrations.Addfield(…))だけ残して実行すると、今度は
ValueError: Related model ‘[アプリ名.追加テーブル名]’ cannot be resolved
と怒られた。
結論から言うと、migration実行用ファイル(000n_auto_YYYYMMDD-HHFF.py)内の
dependencies = [
(‘[アプリ名]’, ‘000n_auto_YYYYMMDD_HHFF’),
]
のアンダーライン部分をそのまま実行したため、migration処理が直前の処理を認識できず、エラーを吐いていたと思われる。
新たにmigration実行用ファイルを追加して、そこに既存テーブルへの外部キーを追加する処理部分を記載し、dependenciesに先ほどテーブル作成したファイル名(.pyを除く)を指定して
>python manage.py migrate
を実行したら、無事作成できた。
当然と言えば、当然だけれど、エラーだけ見るとさっぱりわからないし、ググっても同じような事例は見当たらなかった。
わかったことは、migrationという仕組みが、実テーブルだけではなく、前回実行履歴を参照して実行されるということと、外部キー参照している項目を追加する場合、元のテーブルは作成しているだけではなく、実データも入力していないと、外部キーとして項目追加するとき、デフォルト設定した値の参照先がないというエラーとなり、migrateできなくなる。
この場合は、上記のように、最初に参照先のテーブルを作成するようmigration実行用ファイルを修正して、migarateし、データをinsert後、外部キーの項目追加をおこなう必要がある。
その時参照される履歴とは、[アプリ名]’, ‘000n_auto_YYYYMMDD_HHFF.pyであり、000n_auto_YYYYMMDD_HHFF.cpython-99.pycということだ。
このことを知っていれば、同エラーが発生した場合、全テーブルをdropして、maigarationsフォルダ配下のファイルを__init__.py以外すべて削除して再度作成しなおしたらうまくいったなどという解決策を平然とのせている回答例よりはましな解決策がみつかるのではないか?

imagekitでサムネイルが作られない

サムネイルを作成するには欠かせないdjangoのツールといえばimagekitかと思われますが、インストールは
pip install django-imagekit
settings.pyのINSTALLED_APPSに’imagekit’を追加して、
model.pyを↓のようにすればよいのですが、簡単には言うことをきいてくれないのがDjangoです。(だいぶ慣れてきました)
origin = models.ImageField(upload_to=getPhotoUploadPath, default=’defo’,
verbose_name=’画像’)
big = ImageSpecField(source=”origin”,
processors=[ResizeToFill(1280, 1024)],
format=’JPEG’
)
thumbnail = ImageSpecField(source=’origin’,
processors=[ResizeToFill(250,250)],
format=”JPEG”,
options={‘quality’: 60}
)
middle = ImageSpecField(source=’origin’,
processors=[ResizeToFill(600, 400)],
format=”JPEG”,
options={‘quality’: 75}
)
small = ImageSpecField(source=’origin’,
processors=[ResizeToFill(75,75)],
format=”JPEG”,
options={‘quality’: 50}
)

アプリ動かしてもsettings.pyのMIDIA_ROOTのCACHEにできるはずのサムネイルができていない。
そこで、魔法の呪文の
python manage.py generateimages
を実行すると、あれよあれよとサムネイルができました。
どこに隠れてたのかな?



migrateでテーブルが追加されない

Djangoで新規に追加したテーブルがmakemigrationsで認識されない現象が発生したのでググって解決しようとして、うまくいかなかったので備忘録。
まず最初に躓いたのが、AttributeError: ‘NoneType’ object has no attribute ‘is_relation’というわけのわからないエラー。
これはクライアント側でテストしたソースをgitでデプロイ環境へアップした際に発生。
この現象はdjango-reset-maigrationsをインストールし、INSTALLED_APPSに’reset_migrations’,を追加して、python manage.py reset_migrations appを実行して解決しましたが、次にテーブルを追加した後に同じようにデプロイした後、makemigrationsすると何も更新するものないよと言われました。
それで、デプロイ先のテーブルを覗くとやはり、該当するテーブルが存在しないので、ググって、app/migratesの下の__pycache__と、__init__.py以外を削除すればいいのかと思いおもいきり削除した結果、django.db.utils.ProgrammingError: relation “app_xxxxxxxxxx” already existsというのが出るようになってしまいました。
今思えば当然のことですが、仕方ないので、データベースから、”app_*”をdrop。
ようやく、makemaigrationsからmigrateまで、無事実行できました。
本番ではデータのバックアップ/戻しなど手間のかかる作業となりそうです。

一つのアプリだけテーブル削除して、やり直したければ(通常のmigrateがスルーしてしまう場合)以下の方法が有効のようです。
python manage.py migrate –fake app_xxxxxxxxxx zero
を実行する

python manage.py showmigrationsで確認

app_xxxxxxxxxx
[ ] 0001_initial

※スルーする場合だいたい、[X]0001_initialとなっているはずなので、XがはずれていればOK

python manage.py migrate
を実行する。


Djangoで直接SQLを実行した値をTemplateに表示する

例えば、viewsで直接SQLを実行した場合、結果を表示するにはどうするのでしょうか?
from django.db import connection
views側
SQL = ‘SELECT A.id,B.name,C.dept_id ‘ \
            ‘ FROM exhibitinfo A LEFT JOIN dapartment B’ \
‘ ON A.dept_id = B.id AND B.syain_id = {}’  \
            ‘ INNER JOIN customuser C’ \
‘ ON A.user_id = C.id’ \
            ‘ WHERE A.is_display=True ORDER BY A.id DESC;’.format(request.user.id)
with connection.cursor() as cursor:
  cursor.execute(SQL)
            exhibit = cursor.fetchall()
for history in connection.queries: 
           logger.info(‘****** history:’ + str(history))
context = {
        ‘exhibit’: exhibit, 
}


template側
{% for item in exhibit %}
<div>{{ item.0}}</div> ← id
<div>{{ item.1}}</div> ←name
<div>{{ item.2}}</div> ←dept_id
{% endfor %}

となります。
例が悪くすみません。
(というか、躓きそうなところをできるだけ網羅しました。)

allauthのLoginカスタマイズ

all-authをインストールした仮想環境(以下の場合”venv”)のall-authのテンプレートをすべて、自作アプリのテンプレートフォルダにコピーします。
venv/lib/python3.x/site-packages/allauth/templates/account
→ templates/allauth/account

次に、settings.pyの”TEMPLATES”に以下の☆を加えます。
TEMPLATES = [
    {
        ‘BACKEND’: ‘django.template.backends.django.DjangoTemplates’,
        ‘DIRS’: [
            os.path.join(BASE_DIR, ‘templates’, ‘allauth’),   ☆追加
            os.path.join(BASE_DIR, ‘templates’),
        ],
  …
あとは、templates/allauth/account配下のlogin.htmlを修正すればカスタマイズ可能です。

DegitalOceanでのVSCode

degitaloceanでVSCode使おうとしてはまったので備忘録。

最初のイメージとしては、ターミナルの中から起動するイメージだったのですがクライアントのVSCodeを起動してアクセスする方式にしました。
(この方式だとPUTTYのターミナルはあまり必要なくなりました。)
躓いたのは、公開鍵の持ち方です。
・普通のフォルダに鍵ファイルを置いて指定すると怒られる。
 (ユーザフォルダなどに置くと良い)
・PUTTYGenで作成した公開鍵をOpen形式に変換したファイルを指定する必要がある。
 (PUTTYGenに変換機能あり)
の2点です。
詳しくは後程追記します。

Ubuntuのmigrateで失敗する

Windows10の環境で作成した、ユーザ認証用のDjangoライブラリ(django-allauth)を使用したプロジェクトをDegitalOceanにデプロイする際にはまったので備忘録です。
まず、
>python manage.py makemigrations
を実行すると
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration account.0001_initial is applied before its dependency accounts.0001_initial on database ‘default’.
などのエラーが表示されます。
どうもallauthで作成されるモデルが作成されていないため、作成さていないテーブルへカスタマイズ用の定義を追加しようとしたため、順番が違うよと言われているようだったので、再実行すると基本のテーブルが作成されているにも関わらず、カスタマイズ用のテーブルが作成されなくなりました。
>python manage.py showmakemigrations
でスケジュールを見てみると

account
[X] 0001_initial
[X] 0002_email_max_length
admin
[X] 0001_initial
[X] 0002_logentry_remove_auto_add
[X] 0003_logentry_add_action_flag_choices
auth
[X] 0001_initial
[X] 0002_alter_permission_name_max_length
[X] 0003_alter_user_email_max_length
[X] 0004_alter_user_username_opts
[X] 0005_alter_user_last_login_null
[X] 0006_require_contenttypes_0002
[X] 0007_alter_validators_add_error_messages
[X] 0008_alter_user_username_max_length
[X] 0009_alter_user_last_name_max_length
[X] 0010_alter_group_name_max_length
[X] 0011_update_proxy_permissions
contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name
sessions
[X] 0001_initial
sites
[X] 0001_initial
[X] 0002_alter_domain_unique
socialaccount
[X] 0001_initial
[X] 0002_token_max_lengths
[X] 0003_extra_data_default_dict
と表示され、カスタマイズテーブルは無視されています。
そこで個別にmigrateしようとおもい、

>python manage.py makemigrations xxxx
(xxxx はアプリ名)
を実行すると、今度は
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration socialaccount.0001_initial is applied before its dependency accounts.0001_initial on database ‘default’.
と怒られます。
仕方ないので、env/lib/python3.8/…/socialaccount/migrationsの下を__init__.py以外を削除して実行すると今度は
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration account.0001_initial is applied before its dependency accounts.0001_initial on database ‘default’.
と怒られたので、同様にaccount/migrationsの下も__init__.py以外を削除。
これでやっと
>python manage.py makemigration xxxx
が成功しました。
書いてみると単純そうだけど、試行錯誤してる最中はもう直接create tableしちゃおうかとも思ったけれど、migrateの恩恵にあずかると、楽したくなるなあと思う今日この頃です。


Djangoのチュートリアルにあるchoice_set

これはQuestionテーブルが外部参照しているChoiceテーブルのデータ、という意味のようです。
これは、はじめてこのチュートリアルを実行する人はなやむかもなあ。
まず、抽出して表示するのがなんでChoiseデータなの?
ってところからおかしくない?
Questionテーブルの内容を表示させるところじゃないかなあ???

ところで、またも勝手な備忘録
Djangoの新しいプロジェクトを作るコマンド
>django-admin startproject mysite
Djangoの新しいアプリを作るコマンド
>python manage.py startapp myapp

セールスフォース・ドットコム

クラウド型のシステム開発基盤としては、Azure、Googleクラウド、AWSといったところが主なものかと思っていましたが、セールスフォース・ドットコムという会社のFource.com、Herokuというのがあるんですね。
なんと、持続化給付金の申請サイトはこの会社が手掛けたそうですし、トヨタ自動車KDDIみずほフィナンシャルグループ三菱UFJフィナンシャル・グループ損害保険ジャパン日立グループジョンソン・エンド・ジョンソンファーストリテイリングローソン株式会社日本総合研究所小田急電鉄楽天など、規模・業種を問わず多数の企業がこの会社のクラウドコンピューティング・サービスを導入しているそうです。
2009年には環境省経済産業省総務省が所管するエコポイントのインターネット申請システムを経済産業省から打診を受けてからわずか3週間でシステム開発を完了・稼働させたそうで、この会社、2019年度版日本の「働きがいのある会社」ランキング1位に選出されているそうで、クラウド=AWSと思っていましたが、Herokuもありかな?
Herokuはサーバーがアメリカにあるのでアクセスが難ありと聞いていましたが…

AWSで.Net CLiサンプル動かず?

AWSの.NetCoreのサンプルのコンソールアプリを動かしてみました。
結果、bash: line 1: hello/obj/project.assets.json: No such file or directory
と怒られました。
確かにobjフォルダの下にDebugフォルダも、exeもdllもできていません。
で、色々とネットで調べてみるとどうやらAWSで動かすために必要なファイルがサンプルのインストール手順だと不足していたようです。
コマンドプロンプトから
>dotnet restore
を実行したら、正常に実行されました。

Django3おすすめ本(+Kindleで検索できない)

kindleを以前購入したんですが、文字検索でちっとも目的の本が検索できないと思っていたら、問い合わせしようと思ってWi-Fiに繋げたら検索できました。
あほすぎて笑ってしまった。
ところで、↑のようなことやってる人が言うのもなんですが、Djangoやるなら、「現場で使えるDjango の教科書(基礎編)」横瀬明仁著は目を通した方が良いと思います。

Zoom

Qiita会議に参加しようかな?
ということで、Zoom入れてみました。
公式サイトはここです。
facebookアカウントでログイン

右上のリソースをクリックして表示された選択リストから “Zoomクライアントをダウンロード” を選択(画像だと弄ってたら選択リストが英語になったのでRESOURCE)

ミーティング用Zoomクライアントの “ダウンロード” ボタンをクリック
ダウンロードしたインストーラを実行

ミーティングに参加

AWS Summit Online 開催のお知らせ

クラウドの最新技術を “実際に手を動かして楽しみながら学ぶ” 23日間
開催期間 2020 年 9 月 8 日 (火) ~ 9 月 30 日 (水)  
◎詳細:
http://rd.itmedia.jp/33DW

これはちょっと参加してみたい!

話は違いますが、知り合いがアマゾンを騙ったメールにうっかり返信してしまったそうですが、アマゾンに問い合わせたところ、とても親切に対応して頂けたそうです。
勢いのある企業は、働き手も違う?

 

 

Cloud9とDjangoとWebサーバー起動と

Cloud9でPythonベースのWebシステムを構築する場合に使用するWebフレームワークですが、DjangoとFlaskが主なフレームワークのようです。
どちらを採用しようかググった結果、日本語環境が比較的整備されているDjangoにしようと思います。(;’∀’)
cloud9のコンソール画面でPythonのバージョンを確認します。

3.6.10ですね。2.x.系の方は3.x.系にアップグレードしてください。
Djangoの特徴としてプロジェクトごとに仮想環境を作成していくことが一般的な開発手順のようです。
次のコマンドで仮想環境を構築します。

コマンドの先頭に(venv)が表示されている場合、仮想環境に居るようです。
ではインストールしてみましょう。

pipが古いよって警告が出ていますが、Djangoは無事インストールされたようです。

Cloud9には既にMySqlがインストール済のようです。

起動/停止してみます。

はじめての起動時はパスワードなしで起動してください。

文字コードを確認します。

character_set_databasecharacter_set_serverlatin1ですね。
このままだと日本語を書き込もうとしたときにエラーで落ちるので、/etc/my.cnfに設定を追加します。
character-set-server=utf8mb4

mysqlを再起動します

再度キャラクタセットを確認します。

Django用のユーザーとDBを作成します。

権限を付与します。

以上でmysql側の設定は終了です。

ちょっと横道にそれちゃいますが、
仮想環境は複数の開発を行う場合、それぞれのプロジェクトによって必要となってくるライブラリなどが異なってくるため、環境の競合がが発生しないためにプロジェクトごとに仮想環境を作って管理していこうというものですが、Pythonの標準ツールとしてvenvがあります。
venv以外にもvirtualenvなどのサードパーティ製のツールを使用しても仮想環境を作成することは可能です。ちなみに、venvで作成した仮想環境から抜けるには、
>deactivate
を実行します。

では、Djangoのサンプルを起動するところまで頑張ってみたいと思います。

任意のフォルダを作成し、gitからDjangoのサンプルアプリを取得します。

仮想環境を起動します。

サンプルの起動準備をします。

マイグレーションでサンプルアプリのデータベースを作成します。

サーバーを起動します。

ただし、アプリサーバは起動していますが、まだAWSのファイアーウォールとdjangoのホスト制限のせいで外部からアクセスできません。
これからその設定をしていきます。

Cloud9のメニューバーから’Go To Your Dashboard’を選択します。

サービスをクリックし表示画面から、’EC2’を選択します。

EC2のダッシュボードが表示されるので、「実行中のインスタンス」をクリックします。

EC2インスタンスの一覧が表示され、1つしかない場合、選択状態になっています。
画面下部にはその詳細が表示されていますが、そのうち「パブリック DNS (IPv4)」の欄に表示されているのが、URLの中央部(ホスト)になります。
この前に”http://”を、後に”:8000″をつけてアクセスしてください。

次に、セキュリティグループの欄をクリックします。

インバウンドルールを設定するダイアログが表示されるので、「ルールの追加」をクリックし、TCPカスタムを選択し、ポートの欄に8000を入力します。最後に、追加をクリックします。これで、ファイアーウォールの設定画変更され、8000番ポートのアクセスが許可されます。

上記の、「パブリック DNS (IPv4)」の欄に表示されている内容に、前に”http://”を、後に”:8000″をつけてアクセスしてください。

この時点で、Djangoのアプリにアクセスすることができます。
ただし、ホスト制限に引っかかり、下記のようなエラーが表示されます。

DjangoのALLOWED_HOSTSを設定する

まず、開きっぱなしのCloud9のIDEで、アプリケーションのディレクトリにあるconfig/settings.pyを開きます。
その中ほどまでスクロールし、ALLOWED_HOSTSというリストに、先程の「パブリック DNS (IPv4)」の欄に表示されている内容を追加します。
もう一度、:8000で終わるURLにアクセスして下さい。

サンプルアプリが起動しました。

次回は、このサンプルのDBをSQLiteからMySqlに変更したいと思います。

Gitのリモートリポジトリの移動

リモートリポジトリの移動は色々とあるようですが、簡単そうな方法で。
移動先のフォルダを初期化します。

ローカル側に一度リモートリポジトリのクローンを作成し、カレントフォルダをクローン作成先に変更します。

初期化した新しいリモートリポジトリへPushします。

以上です。

動的に読み込んだJavaScriptのソースがデバッグで表示されない

これはそう言われればなんとなく理解できるのですが、最初なんでPF12押しててソースでないんだ???
しゃーないconsole.logでだすか・・・
なんて思ってましたが、debugger;っていれるとデバッグモードであればそこで止まってくれます。
単純に止めたい行の前にdebugger;って入れてください。
そこでブレークします。
本番モードだとブレークしません。
IEでも、chromeでも大丈夫でした。
chromeだとその後ブレーク設定するとそこでブレークしました。
IEだとスルーするような?

AWS Lambda

AWS Lambdaとはなんでしょう?
Amazonの説明によると”AWS Lambda はサーバーをプロビジョニングしたり管理する必要なくコードを実行できるコンピューティングサービスです。 “ということですが、どうやらアプリだけ用意すればそのほかのリソース云々は気にせず、使用量に応じた料金だけお支払いいただければよろしいですよ!ということのようです。
(かなり大雑把な説明ですみません。)
これは、ベンダーはサーバーを持たずに開発だけすればよく、ユーザーもサーバーを維持&メンテナンスする必要がなく、開発費用とアプリの使用頻度に応じて決められた料金を負担すれば良いことになります。(この使用頻度に応じた料金もかなり安価だと思いますし、使用していない時間帯は費用が発生しません。)しかも、無料利用枠があり、1 か月ごとに 100 万件の無料リクエスト、および 40 万 GB-秒のコンピューティング時間が、それぞれ含まれます。
これは小さな会社にとっては、アイデア次第で大化けできる可能性を秘めたツールと言えそうです。

AWS SDK for Python

AWS SDK for Python(別称:BOTO3)を構築してみます。
前提条件は、IAMアカウントの取得、AWS CLIがインストール済であることです。
ここを参照して、構築します。
Windowsなので、コマンドプロンプトから、
>py -m pip install boto3

BOTO3とは、Pythonを介してAWSを操作するためのライブラリです。

まずは、サンプルアプリケーションを実行してみます。
このチュートリアルに従って実行します。
画面下方にある”モジュール1を開始する”ボタンをクリックします。

AWSコンソール画面から、cloud9を選択し、”Create environment”ボタンをクリック

続いて、環境名とその説明を記入して、”Next step”ボタンをクリック

構築環境は今回デフォルトのままで、”Next step”をクリック

“Create environment”ボタンをクリック

IDEが作成されると、次のようなウェルカム画面が表示されます。

ここでチュートリアルだといきなりgithubからソースをもってきて実行しろとなってますが、ちょっといきなりなので、ここではお決まりの文言をコンソールに表示するだけにしておきます。

赤まるの中のステータスを入力して保存(File → Save)します。
右上のRunをクリックして実行します。

コンソール画面が表示され、処理結果が出力されます。

以上です。

ネットで調べていると、Cloud9のPythonのデフォルトが2系になってるとか出ていますが、私がやった限りでは、デフォルトは3系になっていました。
もしうまくいかなければ、↓が必要かもしれません。

sudo yum -y update && sudo yum -y install python36

蛇足ですが、保存した環境を再度開くのは、ハンバーガーメニューからです。

カテゴリー AWS