Vapor Trail

明るく楽しく元気よく

AWSクラウドプラクティショナーに合格した

1. きっかけ

AWSについて勉強しなきゃなぁーと前から思っていたものの、サービス多すぎアップデート早すぎでどこから手を付けていいのかわからないままでいた。

お正月休みでまとまった時間が取れるので、今までやろうと思ってたけど腰が重くてできてなかったことをやろうと思って、年明けからDockerとAWSについて学び始めました(あとちょっとVue.js)。

udemyで「手を動かして2週間で学ぶAWS基本から応用まで」というドンピシャな内容があったので、ちょうどセールで安かった(udemyっていつもセールしてる気がするけど・・・)のもあって、これをやることにしました。

手を動かして2週間で学ぶAWS基本から応用まで

2. 感想

やった感想としては、実際の画面の動きを見ながら、一緒にポチポチ作業して学べるので、非常にわかりやすかったです。

AWSの入門書みたいな本もありますが、たぶん技術書だったらVPCとかセキュリティグループあたりで理解できなくて挫折してたと思います。 人にもよると思いますが、こういうのはよくわからなくても、実際に手を動かしてやりながら理解したほうがいいと感じました。

正月休みの間に終わらせるぞーと意気込んでいたものの、コマンドとか手順とかをまとめたりしながら作業したので、結局1月末までかかりつつ、なんとかやりきる事ができた感じです。

3. AWSの認定試験を受ける

 AWSの基本的なサービスに一通り触れたので、認定試験を受けてみることにしました。

クラウドラクティショナーなので一番簡単な試験ですが、

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

 

この本がちょうど出たばかりだったので、買ってお昼休みとかに読んで勉強しました。

結果は無事合格でしたが、udemyの講座を受けて実際にELBとかIAMのサービスを手を動かして触れていたおかげで、比較的簡単に感じたのでudemyの講座を受講しておいてよかったです。

 

4. 今後やりたいこと

基本的なサービスの使い方はわかったので、これからやりたいこととしては、

  • EC2・RDSを冗長構成でLaravelをデプロイする
  • CodePipelineでコミットしたら自動でデプロイできるようにする
  • AWS CodeStarでコミット・ビルド・テスト・デプロイといった一連の流れを構築する
  • ECSなどのコンテナ技術を使ってみたい

といったことです。

PHP プロセスの多重起動を防ぐやり方

cronでPHPのタスクを定期的に起動したいが、すでにプロセスが動いている場合に起動しないようにしたい。

  • PHPのタスクを実行する前に確認するタイプ
<?php
    /**
     * @param $process_command
     * @return bool
     */
    public function checkDoubleProcess(string $process_command): bool
    {
        $output = [];
        exec("ps aux | grep -E \"{$process_command}$\" | grep -v sudo | grep -v grep", $output);
        return count($output) >= 2;
    }

    /**
     * 動かしたいタスク
     */
    public function task()
    {
        //はじめにすでに起動していないかチェック
        if ($this->checkDoubleProcess("bash")) {
            exit;
        }

        //処理したい内容
    }

こんな感じで、プロセス名に一致するものが返ってくるので数を数えているだけ。

<?php
Array
(
    [0] => user   1161  0.0  0.2 115712  2312 pts/0    Ss   19:28   0:00 -bash
)
  • cronでlockファイルを作って多重起動を防ぐタイプ
0 * * * * apache /usr/bin/flock -n /tmp/process.lock php /src/task.php

今までわざわざ前者でやってたけど、crontabに書いたほうが楽だった

Railsのwebpackのsource mapsの設定についてのDHHのコメントがかっこいい

source mapsの設定についてのissueでDHHのコメントがかっこよかった。訳は若干怪しい。

プロダクション環境におけるsource mapsの設定についてのissue。
デフォルトでソースを見えないようにする設定にしており、すでに1年以上前にcloseされている。


github.com

ちょうどこのスレッドに気づいた、そして可能なら元に戻してほしい。 コードを難読化する必要性を感じる人がいる理由は十分に理解しているし、尊重したい。しかし、それをデフォルトにすることは良いことだと思わないし、良いメッセージを送っているとも思えない。

私は長年に渡りソースを読むことで、構造からCSS、そしてJSにいたるまでの多くのことを学んできた。しかし、それは圧縮化とトランスパイルによって難しいものになってしまっている。それはとても残念なことだ。ウェブは私達に多くのものをもたらしてくれた。デフォルトはできる限りの方法でもとに戻すべきだ。ソースを読めるということは受け継ぐべき特徴であり、Railsのようなフレームワークはそれに敬意を表すために努力するべきだ。

だから、デフォルトのsource mapsを元に戻したいが、この方法でウェブに敬意を表することができないと感じている人や、そうするつもりがない人のために、簡単にドキュメントにしてほしい。Thanks!

Rails 6はデフォルトのJavaScriptバンドラーとしてWebpackerが同梱されます。そしてデフォルトでsource mapsはプロダクションで有効にされます。確かにそれを無効にすることができますが、私はそうしないことを願っています。Webを構築する方法を他の人から学びやすくするようにしましょう。


プログラミングをしている人で、developer toolでHTMLやCSSJavaScriptのソースを読んで、何らかの形で学んだり参考にさせてもらったりしたことがない人はいないと思う。 1年以上前のコミットに気付いて、source mapsの設定一つで他の人が学ぶ機会を失うのではないかと考える、視野の広さと考えの深さすごいなー。

ソースマップを使用する - 開発ツール | MDN
CSS と JS のプリプロセッサの設定  |  Tools for Web Developers  |  Google Developers
Devtool | webpack
多段SourceMapの対応方法とライブラリ | Web Scratch