2020-02-23

ストレングス・ファインダー2.0をやってみました

読書

こんにちは！

3連休ですが特に予定を入れずにのんびり休日を堪能しています、のがさです。
今日は本を読みふける日に設定しており、しばらく気になっていた 『さあ、才能（じぶん）に目覚めよう -ストレングス・ファインダー2.0』を読んでみた感想などを残したいと思います。

読んでみた感想
読もうと思った経緯
私の5つの強み
これをどう活かすか

読んでみた感想

本書は「欠点を克服すること」に価値を置くのではなく、「自身の持つ才能」を認知し、これを磨き「強み」に昇華することが
社会の中で自分になにが適しているのか把握することに繋がり、本当の自分を大きく飛躍させることができるとしています。

実際に本書のメインとなる「ストレングス・ファインダー2.0」のアセスメント（WEBで受ける性格診断のようなもの）を受けてみて感じたこととしては
何かのプロジェクトチームを形成する際にひとつの指標となり得ると感じました。

まず、アセスメントの結果を読んでみて自分の普段の行動・思考がポジティブに言語化される感覚が心地よく、自己肯定感がかなり高まります。
最近心理学系の本も読んでいるので確証バイアスがかかっているかなとも感じますが、それを踏まえても自己肯定感を高めてくれるという意味では一読の価値があると思います。
また、それぞれの強みに対して「行動アイデア」が用意されており、その中で強みを発揮することで誤解などを生みやすいシチュエーションや意識すべきことを提示してくれており
より実践的な内容になっている点も好感が持てました。

さあ、才能(じぶん)に目覚めよう新版ストレングス・ファインダー2.0

作者:トム・ラス
出版社/メーカー: 日本経済新聞出版社
発売日: 2017/04/13
メディア: 単行本

読もうと思った経緯

本書は2001年に出版された第1弾である「ストレングス・ファインダー」の新版として2017年に出版されている。
もともとこういった自己啓発系の書籍は好みなので出版された当時に書店に並んでいるのを見て気になっていはいたものの
当時の私は「自己啓発疲れ」の状態で「同じようなことが書かれているんだろう」と少し穿った見方をしており結局購入には至らなかった覚えがあります。

そんな感じでなかなか手に取る機会を逸していたのですが
昨年11月に転職をして新しいプロジェクトへ配属されたこともあり、自分自身の存在価値を改めて考える日々が続いているところで
最近聞いているVoicyのワーママはるさんのワーママはるラジオの話題に度々出てきたり
会社で実施したチームビルディングのワークショップでプロジェクトメンバーの1人が本書の結果を引用して自己開示していたりと
頻繁にこの名前を聞く機会が増えたため、購入に至りました。

私の5つの強み

ストレングス・ファインダーの結果として得られた自分の強みとそれに対する自分なりの見解

親密性

「親密性」という資質は、あなたの人間関係に対する姿勢を説明します。簡単に言えば、「親密性」という資質によって、あなたはすでに知っている人々に引き寄せられます

これはまさに。私は外交的な性格に見られがちですが、どちらかというと妻や旧来の友人との関係性を大切にしており
ガンガン外に出て仲間を増やそうというタイプではありません。仕事でも社内での広い交流よりもプロジェクトメンバーとの
コミュニケーションを大切にしているのでかなりしっくりきました。

目標志向

「私はどこに向かっているのか？」とあなたは自問します。毎日、この質問を繰り返します。目標志向という資質のために、あなたは明確な行き先を必要とします。行き先がないと、あなたの生活や仕事はたちまち苛立たしいものになる可能性があります。ですから毎年、毎月、さらに毎週でさえ、あなたは目標を設定します。

この目標志向という強みは、単に「自分で目標設定をしてそれに向けたアクションを取ることが得意」ということに留まらない捉え方を
されているところに思わず「なるほど」と納得してしまいました。
というのも目標志向を持っている人は、議題・目的がはっきりしていない会議が苦手だったり、会議中の脱線が気になる性分らしく
話の本筋を維持することに焦点を当てて考えるそうです。
（アセスメントの中で「目標設定を毎週している」にあてはまると回答したけど実際は年単位の目標設定しかしていません。。）

慎重さ

あなたは用心深く、決して油断しません。あなたは自分のことをあまり話しません。あなたは世の中が予測できない場所であることを知っています。

仕事の仕方に当てはまるかなと。自分の認識が正しいのかは仕事に取り掛かる前にうざいくらい聞いてしまいます。
あと信用できるまで自分の個人情報をさらけ出したりしません（誰でもそうだと思いますが…）

未来志向

「もし・・・だったら、どんなに素晴らしいだろうなぁ」と、あなたは水平線の向こうを目を細めてみつめることを愛するタイプの人です。未来はあなたを魅了します。

今のプロジェクトでも「こういう風に環境を変えたい」「こんな風にしたらもっと良くなる」を発信するのはよくしています。
ただ、行動アイデアには「人に受け入れられるには現実的な可能性に根差しているとき」
「<活発性>の資質の高い人とパートナーを組むことで、未来は今日のあなたの行動によって生み出されるものだということを思い出させてくれる」
という言葉は青写真を描きがちな私には本当にその通りで肝に銘じなければと感じました。

共感性

あなたは周囲の人の感情を察することができます。彼らが感じていることを、まるで自分自身の気持ちであるかのように感じることができます。

なんだかスピリチュアルな感じがしてきましたが、今のプロジェクトに配属されて2週間くらい経ったときに
プロジェクトメンバー（他社の方）と飲みに行った際に「（配属された）今のプロジェクトがどう見えているか」を質問されたときの
ことを思い出しました。
私はプロジェクトのメンバーそれぞれがどんな風に仕事に取り組んでいるように見えて、それがうまく組み合わさっているところと
軋轢が生じていると思われるところとその理由を話したのですが
質問したプロジェクトメンバーの方からすると、これがかなりの精度で当たっていたらしくとても驚かれました。
この共感性は「共感」とそのすべてに同意することは分けており（これを"同情"としています）、かなり共感（同意）できました。

これをどう活かすか

本書で認識できた才能は強みに昇華していくため、日々の業務や行動の中で意識的に発信していこうと思います。
また、行動アイデアにあったようなこの才能（強み）を発揮することで生まれうる誤解などにも目を向けることも大切にしていかなければいけません
できればチームメンバー全員でそれぞれの才能（強み）をシェアしてみたいのですが
なかなか難しいかもしれないので、すでにストレングス・ファインダーを実施済みのメンバーと自身の強みについて話してみようかなと思っています。

2020-02-21

Lambda関数でAssumeRoleして他のアカウントのNACL設定を取得する

AWS

こんばんは！！

複数アカウントをOrganizationで運用していくにあたり
Masterアカウントから配下のアカウントのNACLの設定状態を取得するのを
Lambda関数で実装したいと思い、自宅の疑似環境でお試ししてみました。

やっていること

①Masterアカウント→SlaveアカウントにAssumeロール
②AssumeロールしたロールでSlaveアカウントのNACL設定を取得

実際は取得した内容を成型しないと使い物にならないのですが
とりあえず取得できるというところまでやれたので
忘れないうちに残します。

1. Masterアカウントでロール作成 Lambda関数で使うロールです
ロール名：AWSGetResourceByLambdaReadOnlyRole（なんでもよい）
* 1111111=SlaveアカウントのID

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::1111111:role/AWSGetResourceByLambdaReadOnlyRole",
            "Effect": "Allow"
        }
    ]
}

2. Slaveアカウントでロール作成

NACL情報を取得するためのロールです
MasterアカウントのアカウントIDを信頼エンティティに追加しています
※NACLはVPCではなく'"ec2:Describe*"'で取得するので注意が必要
EC2の読み取りのみの権限を付与しました

3. Lambda関数を作成

import boto3
import json
from boto3.session import Session
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)

# 引数で渡された AWS アカウント/ロールのクレデンシャルを取得
def sts_assume_role(account_id, role_name, region):
    role_arn = "arn:aws:iam::" + account_id + ":role/" + role_name
    session_name = "test"

    client = boto3.client('sts')

    # AssumeRole で一時クレデンシャルを取得
    response = client.assume_role(
        RoleArn=role_arn,
        RoleSessionName=session_name
    )

    session = Session(
        aws_access_key_id=response['Credentials']['AccessKeyId'],
        aws_secret_access_key=response['Credentials']['SecretAccessKey'],
        aws_session_token=response['Credentials']['SessionToken'],
        region_name=region
    )

    return session

def lambda_handler(event,context):
    print("Received event: " + json.dumps(event, indent=2))

    account_id = event['account']
    role_name = event['role']
    region= event['region']

    # account_id = event['account']
    # role_name = event['role']
    # region = event['region']

    # イベントで指定されたAWSアカウント/ロールのクレデンシャルを取得
    session = sts_assume_role(account_id, role_name, region)

    ec2 = session.client('ec2')

    # 取得したクレデンシャルを使ってインスタンスリソースを取得
    instances = ec2.describe_network_acls(MaxResults=123)
    # logger.info(instances)

    return print(instances)

イベント

{
  "account": "1111111",
  "role": "AWSGetResourceByLambdaReadOnlyRole",
  "region": "ap-northeast-1"
}

Roleは2.で作成したロール名を記載します

結果

{'NetworkAcls': [{'Associations': [{'NetworkAclAssociationId': 'aclassoc-4e406234', 'NetworkAclId': 'acl-8e50e1e8', 'SubnetId': 'subnet-f81dc9d3'}, {'NetworkAclAssociationId': 'aclassoc-49406233', 'NetworkAclId': 'acl-8e50e1e8', 'SubnetId': 'subnet-49eed112'}, {'NetworkAclAssociationId': 'aclassoc-4f406235', 'NetworkAclId': 'acl-8e50e1e8', 'SubnetId': 'subnet-b72ce1ff'}], 'Entries': [{'CidrBlock': '0.0.0.0/0', 'Egress': True, 'Protocol': '-1', 'RuleAction': 'allow', 'RuleNumber': 100}, {'CidrBlock': '0.0.0.0/0', 'Egress': True, 'Protocol': '-1', 'RuleAction': 'deny', 'RuleNumber': 32767}, {'CidrBlock': '0.0.0.0/0', 'Egress': False, 'Protocol': '-1', 'RuleAction': 'allow', 'RuleNumber': 100}, {'CidrBlock': '0.0.0.0/0', 'Egress': False, 'Protocol': '-1', 'RuleAction': 'deny', 'RuleNumber': 32767}], 'IsDefault': True, 'NetworkAclId': 'acl-8e50e1e8', 'Tags': [], 'VpcId': 'vpc-ebadad8c', 'OwnerId': '11111111'}, {'Associations': [{'NetworkAclAssociationId': 'aclassoc-0e2844846f5677dd7', 'NetworkAclId': 'acl-034327f98e1edb609', 'SubnetId': 'subnet-0a15d8d5a3c54b67b'}, {'NetworkAclAssociationId': 'aclassoc-0f53fb9a35dc2f745', 'NetworkAclId': 'acl-034327f98e1edb609', 'SubnetId': 'subnet-002cfbbdfa4df0df6'}, {'NetworkAclAssociationId': 'aclassoc-0148161c1f8bea553', 'NetworkAclId': 'acl-034327f98e1edb609', 'SubnetId': 'subnet-05a23ba6e5bd8e188'}, {'NetworkAclAssociationId': 'aclassoc-08cc336738cb46568', 'NetworkAclId': 'acl-034327f98e1edb609', 'SubnetId': 'subnet-0180a727935d772cd'}], 'Entries': [{'CidrBlock': '0.0.0.0/0', 'Egress': True, 'Protocol': '-1', 'RuleAction': 'allow', 'RuleNumber': 100}, {'CidrBlock': '0.0.0.0/0', 'Egress': True, 'Protocol': '-1', 'RuleAction': 'deny', 'RuleNumber': 32767}, {'CidrBlock': '0.0.0.0/0', 'Egress': False, 'Protocol': '-1', 'RuleAction': 'allow', 'RuleNumber': 100}, {'CidrBlock': '0.0.0.0/0', 'Egress': False, 'Protocol': '-1', 'RuleAction': 'deny', 'RuleNumber': 32767}], 'IsDefault': True, 'NetworkAclId': 'acl-034327f98e1edb609', 'Tags': [], 'VpcId': 'vpc-021e22d78fe136fdb', 'OwnerId': '11111111'}]

参考サイト

EC2 — Boto 3 Docs 1.12.4 documentation
Lambda で Switch ロールに対応した複数アカウントのインスタンス一覧の取得 - Qiita

2020-02-21

クロスアカウントでのリソース共有

AWS Resource Access Manager

こんにちは！

私の職場ではRAMで複数のAWSアカウントでTransitGatewayを共有しています。

このRAMでの共有の設定をいちいちGUIぽちぽちしているのが地味にめんどくさくて Lambdaで自動化できないか自宅で疑似環境環境作って試してみました。 (TransitGatewayはコストかかるので以下ではサブネット共有にしています)

そもそものクロスアカウントでリソース共有するところでつまずいたので備忘的に残します。

結論

RAMで異なるアカウント間でリソース共有する際は、以下の設定を行う 1. AWS Organizationでリソースを共有したいアカウントを招待 2. AWS Organizationの設定でAWS のサービスに対する信頼されたアクセスのAWS RAMへのアクセスを有効化

Lambdaで試していたコード

import json
import boto3
client = boto3.client('ram')

def lambda_handler(event, context):
    # TODO implement
    response = client.associate_resource_share(
    resourceShareArn='arn:aws:ram:ap-northeast-1:123456789/resource-share/hogehogehoge',

    principals=[
        '123456789-account-id',
    ],
)
    
    return response

エラーメッセージ

An error occurred (InvalidParameterException) when calling the AssociateResourceShare operation: The resource you are attempting to share can only be shared within your AWS Organization. This error may also occur if you have not enabled sharing with your AWS organization, or that onboarding process is still in progress.: InvalidParameterException

対処

AWS Organizationでリソースを共有したいアカウントを招待アカウントの追加から共有したいアカウントの招待を行います（特に難しいことはないので後続処理は省略します）
AWS Organizationの設定でAWS のサービスに対する信頼されたアクセスのAWS RAMへのアクセスを有効化

はまったところ

2を実行するとAWS RAMの設定画面でも以下のように設定がグレーアウト（有効化）されるのですが私はなぜかうまく連動されませんでした。仕方ないので手動でチェックボックスにチェックを入れて設定の保存を実施

結果

無事にLambdaの処理が通ってくれました！ f:id:nogasalog:20200221130446p:plain

RAMの共有プリンシパルにも追加されています f:id:nogasalog:20200221130648p:plain

あとは共有先で共有の承認をしないといけないのですが、一旦今回はここまでにします。

2020-02-02

LambdaでS3にアップロードされたjsonパラメーターを読み込む

ここ最近、業務でCloudFormationを使用する機会がかなり多くなりました。
主にStacksetsの機能を使用して複数のアカウントに対して同時デプロイを行うのですが
Stacksetsの実行はGUIでパラメーター入力しているような状態で
あまりイケてる感じはしません。

ということで、以前に勉強用として作ったStackTemplateを活用して
「S3へのパラメーターファイル(json)のアップロードをトリガーにCFnを実行する」Lambdaを作ってみたいと思っています。

とはいえほとんど知見がないので今日はS3へアップロードしたjsonファイルを
PythonのDictへ格納するところまでしか進みませんでした（作業時間：約3時間）涙

OutPut

import json
import boto3
import logging
import pprint

client = boto3.client('s3')
s3 = boto3.resource('s3') 

##S3にアップロードされたパラメーターファイルを取得
def importParameter(event, context):

    # set logging
    logger = logging.getLogger()
    logger.setLevel(logging.INFO)

    # set "bucket name" and "object name"
    BUCKET = 's3-lambda-cfn-bucket'
    TEST_FILE = 'parameters/parameter.json'
    
    # get s3 object
    try:
        response = client.get_object(Bucket = BUCKET, Key = TEST_FILE)
        body = response['Body'].read()
        bodystr = body.decode('utf-8')
        #bodystr = json.dumps(body)
        js = json.loads(bodystr)
    except Exception as e:
        return logger.error("Failed to get object: {}".format(e))
        
    return {
        'parameters': js
    }

参考にさせて頂いたサイト

2019-10-16

オンラインセッション「はじめてのコンテナワークロード」個人的まとめ

AWSInnovate AWS Innovateセッション

（今更ながら）AWS Innovate オンラインカンファレンスに参加しました

昨日、AWS Innovate オンラインカンファレンスに参加してみました。

aws.amazon.com

昨年からUdemyやらBlackbeltでAWSの学習はすすめていたのですが
オンタイムでAWSのカンファレンスに参加するのは初めてです。

様々なセッションが容易されている中で、以前から
「名前は知っているけどよく知らない」状態だった
Dockerコンテナ技術のセッションがあったので
「はじめてのコンテナワークロード」のセッションを拝聴させて頂きました。

セッション自体はPart1～Part3まであり、すべて見させて頂いたのですが
（スピーカーの原さんが息切れするほど笑）かなり濃密な内容で
特にPart2,3についてはビジネスでコンテナ技術を導入するにあたっての
障壁やケーススタディ的な要素が多かったため今回はPart1の内容で
学びとなった内容をまとめていきたいと思います。

セッションのゴール

コンテナを持つ技術的な特徴と価値を整理
単一環境でコンテナを動かせるようになる

コンテナ仮想化とは

ひとつのホストOSの上に、アプリケーション実行に必要な要素を一通りそろえた
「仮想的なユーザー空間（コンテナ）」を複数作成することができる技術

通常のサーバー仮想化と比較

サーバ仮想化では

ひとつのホストOSの上にさらに仮想OSを作り、アプリケーション実行環境を構築する
→OS起動しアプリケーションが利用可能になるまでのオーバーヘッドが長くなりがち

コンテナ仮想化では

「コンテナ」は実質的にはホストOSのプロセスを切り出して独立させているだけ
→アプリケーション実行までの待ち時間が短くてすむ

f:id:nogasalog:20191016121129p:plain

コンテナ技術導入で解決できる課題

環境差異によるアプリケーション実行時の障害やそれを防止するための環境移動時のコード修正/設定変更
開発/本番環境の環境差異（ランタイムのバージョンや環境変数）などが起因とされる障害

コンテナ技術がどのように解決するか

アプリケーションの

ランタイム/エンジン
依存ライブラリ/パッケージ
コード

をまとめて「コンテナイメージ化」し、各環境間でイメージを簡単にデリバリすることが可能

まとめ

Dockerコンテナの技術的特性

アプリケーションの依存物すべてをひとつにパッケージングが可能
パッケージの統一的なデリバリ方法を実現するコマンド群（イメージレジストリとのやり取り）
コンテナを実行するための統一的なコマンド群

期待できる効果

アプリケーション実行環境の再現容易性向上
→環境依存要素の考慮不要
アプリケーションの可搬性向上
→push/pullでアプリケーションを動かせる
（上記によって）高速な開発とリリースサイクルが実現できる

セッションを受講してみて

これまで「名前を聞いたことがあるけど、よく知らない技術」だったコンテナ技術について
技術的な特性や利点を整理して理解することができました。

今後も気になっているけど参入障壁高い（そう感じてしまいがち）技術については
軽い気持ちでWebinarやセッションを聞いて、やってみるというサイクルを活用していきたいと思います。

また、少し調べてみると個人開発レベルでもDockerコンテナを利用して開発している方もいるようです。
確かに「ローカルで開発した環境をまるごとイメージ化してAWSの仮想サーバにDocker環境作ってローンチ」は
かなり開発スピード上りそうで魅力的ですね。

参考

注目を浴びる「Dockerコンテナ」、従来の仮想化と何が違うのか？ | 新野淳一コラム | 東京エレクトロンデバイス株式会社

2019-10-14

WSLを使用してWindowsOS上でUbuntuを操作できるようにしてみた

WSLで WindowsOS上でUbuntuを操作できるようになる？

私は根っからのWindowsユーザーです。
よく「開発するならMac一択！」みたいに言われていますが、なかなかMacを購入する自己投資に踏み切れずにいます。

そんなWindowsユーザーにとって、開発やらなんやらの勉強をする際の
開発環境ってどんなものがそろっているのが良いんだろう？と思って調べていたんですが
ナレッジが収集しやすかったり、そもそもいろいろなTech系のブログが
Linux系の環境を前提にしていたりするため
やっぱり開発はMac（Linux系）の環境で進めた方が良さそう。

Windows環境でLinux環境を整える良い方法。。
一応、VMwareWorkStationとかでLinuxの仮想環境作るとかはできるんですが
結構PCへの負荷が大きかったりするのであまりやりたくない。

他に良い方法。。と思って調べていたらWindows10から「WSL」という機能が
標準搭載されたとの記事を見かけましたので
内容について調べて、実際にインストールしてみました。
以下のサイトを参考にさせて頂きました

【WSL入門】第1回 Windows 10標準Linux環境WSLを始めよう：ITの教室 - ＠IT

WSLとは

WSL（WindowsSubsystem for Linux）の訳
Windows10 FallCreatorsUpdateから標準搭載
WindowsStoreからLinuxディストリビューションをインストールして
WindowsOS上でLinuxディストリビューションを操作することができる機能

利用するメリット

WSL側からWindowsOS側のすべてのファイルやフォルダにアクセス可能
WindowsOS上でLinuxのコマンドを使用できる
→ 類似機能を持つコマンドがWindowsにあってもLinuxコマンドの方が機能が充実しているものがある
仮想マシンを使用するより、起動負荷が少なく、起動時間が早い

制限事項

ハードウェアを操作するようなアプリケーションは動作できない
コンテナなど特殊なソフトウェアは使用できない
Linux カーネルの一部の機能が制限される ex.デバイスドライバの組み込み。システム管理系機能はWSL内の情報取得のみ
デーモンの自動起動はされない（手動で起動して動作させることは可能）
→Webサーバなどをホスティングする用途には向いていない

とりあえず使えるようにしてみた

HTTPサーバのホスティングに向いていないのか。。と
ちょっとだけモチベーションが下がりつつとりあえず使えるようにしてみました。

WSL機能を有効化

PowerShellを管理者権限で起動して下記のコマンドを実行してWSLを有効化

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

f:id:nogasalog:20191014195428p:plain

WSLの有効化後はシステムの再起動が必要

f:id:nogasalog:20191014200341p:plain

Linuxディストリビューションのパッケージインストール

WindowsStoreからLinuxディストリビューションを検索

f:id:nogasalog:20191014200542p:plain

今回はUbuntuをインストール選択してインストール

f:id:nogasalog:20191014200621p:plain

Ubuntu(WSL)起動

インストール環境後、初回起動

初回起動は数分かかる

f:id:nogasalog:20191014200840p:plain

初期設定

ユーザー名、パスワードを設定
f:id:nogasalog:20191014200958p:plain

とりあえず必要な設定はこれだけで非常に簡単でした。おそらく使い込んだらもっとやるべきことがあるんでしょうが。。

動作確認

おまじないのごとくaptコマンドでパッケージ更新してみましたが
使用感は普通のLinuxホストと遜色ないように感じました。

ちなみに初期設定で作るユーザーは特権ユーザーではありません。
初期状態でsudoできるようになっているため、コマンド実行時は注意が必要です。

$ sudo apt update

$ sudo apt upgrade

インストールしてみて

使いどころをあまり理解できていないのですが WSLからWindows上のファイル操作も可能という利点を活かして
「Windows上のVSCodeでLinux動作を想定したスクリプトを書いてWSLから実行してテスト！」
みたいな使い方はできるかなと思いました。
また、仮想マシンを使用したLinux環境で必要となる

仮想マシン作成→OS起動
Windowsでの操作が必要なときはいちいち環境切り替え
Windows環境で作ったファイルを使う場合はいちいち環境またいで受け渡し

をやらなくても良いというのは確かに利便性はあるように感じました。

Windowsユーザーで開発者の方はどんな環境で開発をしていますか？
私の環境模索はまだまだ続きそうです。。。

それでは！

2019-10-10

Anacondaを利用したWindows環境へのdjangoのインストール

Udemyの学習講座「【3日でできる】はじめての Django 入門 ( Python 3 でウェブアプリを作って AWS EC2 で公開！）」に手をつけてからかなり時間が経ってしまったので、序盤の講義内容を備忘として記載。
Anacondaのインストール部分は省略。

仮想環境作成からDjangoのインストールまで

仮想環境作成
$ conda create -n 仮想環境名

$ conda create -n Py37Out

WARNING: The conda.compat module is deprecated and will be removed in a future release.
Collecting package metadata: done
Solving environment: done

・・・中略・・・
## Package Plan ##

  environment location: C:\Users\***\Anaconda3\envs\Py37Out



Proceed ([y]/n)? y

Preparing transaction: done
Verifying transaction: done
Executing transaction: done
#
# To activate this environment, use:
# > activate Py37Out
#
# To deactivate an active environment, use:
# > deactivate
#
# * for power-users using bash, you must source
#

※ 仮想環境名は半角英数字で指定

仮想環境一覧の表示
$ conda info -e

WARNING: The conda.compat module is deprecated and will be removed in a future release.
# conda environments:
#
base                  *  C:\Users\***\Anaconda3
Py37Out                  C:\Users\***\Anaconda3\envs\Py37Out
myPy37                   C:\Users\***\Anaconda3\envs\myPy37

仮想環境の切り替え $ activate "仮想環境名"

$ activate Py37Out

(Py37Out) C:\Users\***>

djangoのインストール $ conda install django

Udemyのレクチャーではpip install djangoも併用しているが condaコマンドで実行しているので不要？
参考：https://echomist.com/conda-pip-install/

djangoのバージョン確認

(Py37Out) $ python
Python 3.7.4 (default, Aug  9 2019, 18:34:13) [MSC v.1915 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> print(django.get_version())
2.2.5