2017-08-01

なぜ会社名(ブランド名)を blog で出すのか？ [PR？]

Think

ナスです。

私は毎回記事を書く時に [cloudpack OSAKA blog] とタイトルに入れています。弊社のメンバーが blog を書く時も多少表現は違えど同じように書いている人が多いです。

一方で、他の技術系の blog ってあまり所属を出してないものが多いですよね？（もしかしたら私が知らないだけで所属を明かしてる人はいっぱいいるかも？

人それぞれ考えや思想は違いますので一概には言えませんが、私がなんで所属を明かしているのかを書いてみますね。

所属と名前が明らかだからこそ真剣に書ける

私の性質上、匿名だとどうしてもあまり考えずにものを書いてしまうことが過去の経験上わかっているからなんですね。せっかく書くからにはそれなりにインプットして頭の中で考えて整理整頓して、その結果を書いて未来の自分や読んでくれる方に伝えたいと思っています。だからこそ自分を奮い立たせる意味でも最初に明かしてしまおうと思いました。

社内外の人に「この分野ならナスだな」と思わせる

会社っていろんな人が所属しています。ある人は A が得意、ある人は B が得意、というように、得意分野も興味があることもバラバラです。それを blog を通じてうまく伝えることで、社内からはあの話だったらナスに聞こう、という「誰が何を知っているネットワーク」を広げることに一役買っていると思います。（というかそう思いたい

また、社外の人が記事を見てくれて、困った時にこの blog の存在が頭にあれば、「あーこの案件、cloudpack に頼めばなんとかしてくれるんじゃね？」となって仕事がくることもあるかもしれません。
（そんな簡単な話じゃないですし、人の頭に必要な時に思い出してもらえるようにするには、忘れられないようにほぼ毎日記事を書くことが必要です。週 1 ペース以下の私は土俵にすらのってません…）

その会社にどんな考えや知識を持っている人がいるかがわかる

例えば、みなさんが転職を考えているとします。転職エージェントに行って求人を紹介してもらうもよし、知人がいる会社に入るのもよし、人それぞれですね。では仮に、ちょっと気になる会社があって話を聞いてみたいけど、そこにどんな人がいるか、どんな仕事があるのかわからない会社と、逆に blog 等で意見や技術的な知識を公開している人がいる会社だと、モチベーションが変わってくると思います。人それぞれなので、もちろん気にせずガンガン問い合わせする人もいます。（過去の私です

というわけで、cloudpack に興味を持っていて、その方が欲しい情報を提供できるように記事を書いているという側面もあります。

ここまでなぜ私が所属を明かして記事を書いているのかを簡単にですが書いてきました。
そしてここまで読んだアナタはとてもラッキーです！！

まだ間に合います！「梅はち会」という中途採用説明会を、明日 8/2(水) 20:00 から開催します！！
私も転職のきっかけやその他いろいろな内容をお話ししますので、もし明日、関西にいて夜予定がなくて、cloudpack ってなんか気になるよなーって思っている方は是非来てください！！！
詳しくは↓　カツサンドとお酒も出るよー

cloudpack.jp

2017-07-10

SSM でコマンド実行できるかどうか確認するコマンド [cloudpack OSAKA blog]

AWS EC2 SSM

ナスです。

前回、SSM でコマンド実行するための IAM ロールについて書きました。今回は、GUI で確認してたことを aws cli でやってみただけの記事です。これ知ってるだけで確認時間短縮になりますので、忘れずに書き残してこうと思います。

ドキュメント

ドキュメントにも記載があります。前回の記事でも紹介したトラブルシューティングのドキュメントです。 docs.aws.amazon.com

試したコマンド

オンラインになっている EC2 インスタンスの情報を表示するコマンドです。もうこれだけで十分な気がしています。

$ aws ssm describe-instance-information --instance-information-filter-list key=PingStatus,valueSet=Online
{
    "InstanceInformationList": [
        {
            "IsLatestVersion": true,
            "ComputerName": "ip-172-31-31-244.ap-northeast-1.compute.internal",
            "PingStatus": "Online",
            "InstanceId": "i-********************",
            "IPAddress": "172.31.31.244",
            "ResourceType": "EC2Instance",
            "AgentVersion": "2.0.847.0",
            "PlatformVersion": "2016.09",
            "PlatformName": "Amazon Linux AMI",
            "PlatformType": "Linux",
            "LastPingDateTime": 1499692626.203
        },
        {
            "IsLatestVersion": false,
            "ComputerName": "WIN-43V67ICDPJJ.WORKGROUP",
            "PingStatus": "Online",
            "InstanceId": "i-********************",
            "IPAddress": "172.31.17.78",
            "ResourceType": "EC2Instance",
            "AgentVersion": "2.0.805.0",
            "PlatformVersion": "6.3.9600",
            "PlatformName": "Microsoft Windows Server 2012 R2 Standard",
            "PlatformType": "Windows",
            "LastPingDateTime": 1499692626.651
        }
    ]
}

AWS 管理コンソールでも確認すると、確かに 2 台オンラインになっていますね。 f:id:nasrinjp1:20170710223046p:plain

ちなみに、全台オフラインだとこんな結果になります。

$ aws ssm describe-instance-information --instance-information-filter-list key=PingStatus,valueSet=Online
{
    "InstanceInformationList": []
}

SSM でコマンド実行前にこういったコマンドで状況を確認することで、後続のスクリプトでエラーになる可能性を減らせる場面もあるかと思います（実際ここまで確認する場面があるかどうかは不明…）ので、積極的に aws cli を使っていきましょう。

sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。