[AWS][EC2][Windows Server 2019]同サブネットグループ内で、pingが通らないときに確認すべき2点

タイトルのとおりです。

複数のWindows Serverインスタンス間で通信を行おうとしたのですがうまくいかず、そもそもpingも通らないことに気づいたものの、対処に少々時間がかかったのでまとめます。

ちなみに、以下で説明する確認ポイントはpingの受け手側が対象です。

セキュリティグループの確認

VPCにはデフォルトのセキュリティグループが用意されていますが、対象のEC2インスタンスがそのグループに所属していることを確認してください。

↓こんな感じのグループです。

f:id:alek3:20190427111843p:plainf:id:alek3:20190427111853p:plain

※追記:これは、このセキュリティグループに所属するインスタンスからのインバウンドトラフィックを許可するものです。

VPC のセキュリティグループ - Amazon Virtual Private Cloud

Server内のセキュリティ確認

これだけだとつながらない場合は、Windows Serverのセキュリティを緩めます。

メニューから、「Windows Security」にアクセスし、ファイアウォールの設定画面を開きます。

f:id:alek3:20190427112120p:plain

このうち、Private NetworkのFirewallをオフにします。

f:id:alek3:20190427112218p:plain

ping確認

通りました。

f:id:alek3:20190427112548p:plain

株式会社カサレアルの、初心者向けSpring 5 ハンズオンを完了した

以下のSpringハンズオンをやりきったので報告です。非常におススメです。

qiita.com

私がこれを知ったのは去年12月のJJUG CCCでしたので、ようやく重い腰を上げて実施したわけです。

よいところ

  • 無料

  • すぐ終わる

3時間あれば全部のハンズオンを一通り終えることができます。*1

  • Springの基本的な全体像が分かる

Springを始めよう、またはSpring案件に入ったけど何が何だかわからない、という人には非常に有用です。

  • ハンズオン後に「その次やるべきこと」が示されている

実は講義編としてのスライドも用意されています。

www.slideshare.net

その中で、さらに学びたい場合の参考書籍が紹介されています。

学んだこと

Springは簡単なレベルで雰囲気で使っていましたが、今回のハンズオンでいくつか学びがありました。

「HogeHogeのBeanを、コンストラクタでDIする」という言い回し

あるクラス内で、とりあえずコンストラクタ周辺で以下のような記述がよくあります。

    // Fugaクラス内
    private final Hoge hoge;

    public Fuga(Hoge hoge) {
        this.hoge = hoge;
    }

今までは雰囲気で、「ここはBeanを使いまわしているからインスタンスを新しく作成する必要がないんだな~」くらいにしか思っていませんでしたが、

これで何をしているかが言葉で説明できるようになりました。

@Validatedアノテーションと検証用アノテーションの存在

フォームから入力された値に関するバリデーションはどこでもやると思いますが、コントローラーの各メソッドの引数に@Validatedを付与し、サーバーサイドのフォームを構成するプロパティに@NotBlank, @Length, @Emailなどのアノテーションを付けてチェックができることは初めて知りました。

ハンズオンの例にもあるように、ステートレスなバリデーションで使うのがいいかもと思いました。

その他

次はこれを読んで、さらに理解を深めたいと思います。

*1:IntelliJ IDEAやEclipseのインストールから始めるなど、まっさらな状態から環境構築するとなるともう少しかかる

ABC124感想

2週連続で参加しました。

atcoder.jp

A感想

同じ場合と違う場合で場合分けすればよさそう。3分でAC。

B感想

螺旋本の最初に乗っている例題とだいたい同じもの。5分でAC。

C感想

010101…か101010…の2パターンしかないのでどっちかを計算すればよい。 もう片方は文字列の長さから引けば算出できる。 12分でAC。

D感想

問題文を読み違えていて、気づいたのが30分後くらいだったのでそのままギブアップ。とはいえ読み直しても無理でしたね……。

Dは問題文もそれなりに複雑な気がするので焦らずじっくり問題文を理解すべきと思いました。

全般感想

20分でCまでACできたのは満足。Dはこれからですね。

D解きなおし

解説のPDFを読んで方針を確認して実装しました。方針がわかれば実装は素直にできる気がします。

Submission #4969555 - AtCoder Beginner Contest 124

D問題は、以下の3つを考えるのが大事だと思いました。

おまけ

最近勢いがすごいんですけど何があったんでしょうか?

ABC123感想

AtCoderのテストを久しぶりに解きました。

atcoder.jp

どれくらい久しぶりかというと、この記事を書いたときぶりで、今年に入って初です。

alek3.hatenablog.com

結果

A~Cの3完でした。Cにてこずりすぎたかなと思いつつも、自分にとっての最低ラインである3完は死守したのでよしとします。

A感想

最近のAの中だと割と難しい気がします。3分でAC。

B感想

料理の注文時間の1の位に着目すればよいが、それを完全に理解するのにやや時間がかかりました。 10分でAC。

C感想

ボトルネックとなる一番輸送能力の低い交通機関にのみ着目すればよいということはパッと見で分かりました。

しかし、割り切れる割り切れないの場合分けを忘れていて、3WAを出してしましました。

10分で最初の提出、そこからACまで25分かかりました。

D感想

本番中は、実装方針を考えましたが、アルゴリズム書けなさそうとみてギブアップ。

解説のPDFを見て、方針②なら簡単に実装できそうと思い、改めて解きなおしてみました。

Submission #4880342 - AtCoder Beginner Contest 123

秒数はギリギリでしたが、一発AC。

解法①や②はアルゴリズムをほとんど使っていませんね。それでもDが解けるかもしれないと判明したのは収穫でした。

今後に向けて

6月末*1までに、

  • Rate800↑
  • ABC4完

を目標に頑張りたいと思います。

アルゴリズムはこちらで勉強していきます。

蟻本で挫折したのでもう少し簡単そうなものにしました。

ちなみにIDは「alkwest」です。なんでこんな名前にしたかというと、alekからちょっと変化を加えたかったからです。正直かなり名前変えたいですが、チャンスが1回しかないそうなのでまだいいかという気持ちです。

*1:時期に意味はないけどあんまりダラダラやっててもしょうがないということで

レビュー『ブロックチェーンアプリケーション開発の教科書』

サラッと読んだところでレビューします。

目次

  1. ブロックチェーンとは?
  2. ブロックチェーン技術の理解
  3. ブロックチェーンアプリケーションの理解
  4. ブロックチェーンプロダクトの比較
  5. ビジネスへの応用
  6. アプリケーション開発の基礎知識
  7. Solidityによるアプリケーション開発
  8. アプリケーション開発のフレームワーク
  9. アプリケーション設計の注意点
  10. 技術的課題と解決策
  11. ブロックチェーン技術の未来

どんな本か

  • 説明は幅広い
  • コードの記載量は多くない

「WEBアプリケーション開発の教科書」という本が巷では出回っていないのは、現代のWEBアプリケーションは高度に細分化されているため、最低限の知識でさえ網羅しようとすると何千ページにもなってしまうからでしょう。

しかしながら、ブロックチェーンについては、少なくともブロックチェーンそのものの開発をするわけでないのなら、まだギリギリこのようなコンセプトの本も成立するのではと思います。

コードは時間が経てば古くなってしまって使いづらくなってしまいそうですが、概念については変わらないので、そこについては有用であり続けると思います。

レベル感については、1冊目とするには少し厳しい気がしていて、読み物的な入門書を1冊挟んでから取り掛かるのがいいかもしれません。

扱われていないもの

実際のコードについては、7章と8章でしか扱われていません。また、Solidity*1と書かれている通り、Ethereumのことが記載されていて、他の基盤については具体的なコードの記載はありません。

また、ブロックチェーンの活用方法も、仮想通貨などのパブリックブロックチェーンに関するそれが中心で、パーミッションブロックチェーンについてはあまり記載されていないように見えます*2

おまけ

完全に個人の感想ですが、ユースケースについてはもっと「おおっ」と唸るような例がもうちょっとほしいなと思いました。

また、ブロックチェーンでがっつりコーディングにページを割いた書籍は出づらいと思いますので、諦めて自分で書いて学んだり、書いている人に話を聞いたりするしかないと思います。

*1:Ethereumで用いるスマートコントラクト開発言語

*2:厳密にはブロックチェーンでない基盤もあるのでそれはそうという感じもある

読了『まんがでわかるLinux シス管系女子②』

積んでいたのをようやく崩しました。

本書は「まんがでわかるLinux シス管系女子」シリーズの第二巻で、第一巻を引き継ぎ、より複雑なシェルスクリプトを書く方法や、コマンドを叩いたりするのに必要なコマンドが紹介されています。

古びない知識

記載内容の初出は2013年~2015年です。扱う内容はLinuxコマンドであったりシェルスクリプトであったりするので、現在でもそのまま使えるでしょう。

ユースケースベースの利点

1巻からそのスタイルは変わっていないのですが、「こんなことできたらいいな」というユースケースからスタートしています。

なので、私のような初学者でも、実際の業務で試してみようという気分になってきます。*1

トピック

以下の二つのトピックは重点的に取り上げられています。

正規表現はそれ単体でも使われますが、取り上げられているfindやsedと一緒に使われているケースが紹介されています。

標準入出力は、例えば引数入力の代替手段としての標準入力が紹介されていますした。

他にも、while文、case、continue / breakなど、プログラミング言語であれば始めのほうに出てくる話が2巻の後半で集中するのは興味深いです。

体系的書籍への道筋

作中では10行前後のスクリプトが書かれていますが、それ以上の複雑な内容になってくると、マンガでカバーするのは難しくなっていくように思います。

なので、この後はもう少し体系的な書籍へ進むのが上達に有効なのかなと。

入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界

入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界

一応持ってますけど例によって積読です。

気になるところ

本筋とはあまり関係ないのですが、いまのみんとちゃんのようにゴリゴリにスクリプトを組んでいくと、「秘伝のタレ」化しないか少し心配なのですが、世の中のシス管現場はどうなっているですかね?

目次

最後に目次を挙げます。

  • 第1話 定期的に行う作業を自動実行したい
    • crontab
  • 第2話 鍵認証で安全にログインしたい
    • 公開鍵認証
  • 第3話 定時処理で自動的にscpしたい
  • 第4話 複数のサーバーのファイルを効率よく収集したい
  • 第5話 条件に当てはまるログの行数を集計したい
    • wcと算術展開
  • 第6話 複数のテキストファイルを一括編集したい
  • 第7話 表記が一定でない語句をまとめて置換したい
  • 第8話 正規表現のパターン指定をもっと簡潔にしたい
    • 大文字小文字の違いの無視と文字の範囲指定
  • 第9話 正規表現のパターン指定をさらに簡潔にしたい
    • 範囲外の文字の指定と行頭・行末の指定
  • 第10話 古い日付のファイルを探して消したい
    • find
  • 第11話 もっと複雑な条件でファイルを探したい
    • findの複雑な検索条件
  • 第12話 ディスクが満杯になる前にファイルを削除したい
    • dfと数値の大小での条件分岐
  • 第13話 前のコマンドが成功したら次も実行したい
    • ANDリスト
  • 第14話 前のコマンドが失敗したら次を実行したい
    • ORリスト
  • 第15話 親ディレクトリーにいちいち戻る操作を省略したい
    • サブシェル
  • 第16話 3パターン以上の場合分けをしたい
    • case
  • 第17話 社員番号の最初の方の文字で処理を振り分けたい
    • caseのパターン指定
  • 第18話 同じ処理を1時間繰り返し実行したい
    • whileループとsleep
  • 第19話 コマンドの出力をパイプラインで受け取りたい
  • 標準入力とread
  • 第20話 スペース混じりのファイル名もループ処理したい
    • whileループとread
  • 第21話 キーボードからの入力を待ち受けたい
    • readからの入力待ち
  • 第22話 キーボードからの入力を確認の後でやり直したい
    • continueとbreak
  • 第23話 コマンドのすべての出力をファイルに保存したい
  • 第23.5話 ユーザー作成用コマンドの違いを把握したい
    • useraddとadduserとuserdelとdeluser

おまけ

『まんがでわかるLinuxシス管系女子①』まとめたった - 等身大から1割増し

まんがでわかるLinux シス管系女子3 がめっちゃイイ - 等身大から1割増し

*1:例えば、自分の場合だとスクリプトの標準入力についてちゃんと見直してみようと思いました。

きっと読むほどうまい『失敗から学ぶ RDBの正しい歩き方』

『失敗から学ぶ RDBの正しい歩き方』を読みました。

失敗から学ぶ RDBの正しい歩き方:書籍案内|技術評論社

要約

  • RDBを扱う上で気にすべきことが幅広く書いてあります。
  • 挙げられたトピックは頭に叩き込んでおくべき。

取り扱われないもの

タイトルで「RDBの歩き方」とあるようにNoSQLのようなデータベースはチラッと登場するのみです。

また、本文中ではMySQLPostgreSQLの例がほとんどであり、RDBMSの比較については、あまり扱われません。ただ、種類の違いを意識することの重要性は説明されています。

さらに、この書籍は20のアンチパターンの列挙で構成されていますが、それぞれに対して「アンチパターンを生まないためには?」というアンサーを記載しています。しかし、『SQLアンチパターン』のような直接的な「解決策」を明示していないように思えました。

例えば第5章「フラグの闇」では、削除フラグというアンチパターンが紹介されています。そこでの記載がこちら。

このように、テーブルに状態をもたせてしまった場合、その対処方法に銀の弾丸はありませんのでご注意ください。

もう一つ挙げます。

しかしテーブルに状態を持たせると、何らかの理由でそれをリファクタリングする必要が出た場合に困難を極めます。

なかなか冷や汗出ますね。この章に限らず、RDBに関して誤った設計をしてしまうと、取り戻すのが非常に大変ということが読み取れました。

カバーする範囲の広さ

この本の最大の特長は、カバーする範囲の広さにあると思います。例えば、開発と運用両方をカバーしています。

  • 開発(テーブル設計):第1章~第2章、第4章~第9章、第15章、第20章
  • 開発(テーブル設計以外):第3章、第13章~第14章、第16章~第17章
  • 運用:第10章~第12章、第18章~第19章*1

テーブル設計以外とは、具体的に言うとクエリとロックとキャッシュです。*2

わずか300ページ弱の書籍ですが、RDBを扱う上で頻出、かつ影響度が大きいポイントはほぼ網羅されているのでは、と思いました。

読む、試す、また読むのサイクル

この本を読んで、自分には刺さるところが多くありました。第5章「フラグの闇」、第8章「JSONの甘い罠」、第11章「見られないエラーログ」などです。

内容の細かいところまで暗記するのは難しいにしても、少なくともデータベース設計や運用を考える際に、本書で取り上げられたテーマはパッと浮かぶべきだと思いました。

また、この本を読んで得られた気付きに基づき、今関わっているシステムを改善しようと思います。そのうえで、また本書に戻ってくるとさらなる学びがあるに違いありません。

まとめ

RDBを使っているなら読んでおくといいと思います。

また、本文中でいくつかSlideshareのリンクが貼られているので、電子書籍を買ったほうがいいかもしれません。

私は紙の書籍を買ってしまったので、URLを頑張って手動で打ち込みます……。

*1:12章までが連載部分でそれ以降が描き下ろしなのでこのように分割されているっぽい。ひとまとめにしたほうが読みやすかった気もしますが

*2:INDEXはテーブル設計の方に入れてあります