安全2

趣味のコンピュータ

2024メインブラウザ

roytanck.com

この記事を読んで、1月からメインブラウザをChromeからFirefoxに変更していたがまたChromeに戻す予定。

 

ネット生活をがっつりGoogleに依存していて、AndroidのOS機能とChromeの連携が便利すぎるため離れがたかった。

 

思いつく限りだと、

  • Chromeは支払い情報をGoogle Payから自動入力してくれる体験がよすぎる
  • Chromeの翻訳は言語サジェストしてくれたり気が利いてる
  • FirefoxブラウザではGoogle Pay支払いができない
  • AndroidFirefoxアプリはパスワード生成できない(ユーザー新規登録時とか不便。PCだとできる)

など。

 

それ以外の理由だと、公共系のサービスはChrome or Safariを強制されることが多く、結局たまにChromeを使っていた。

 

コミュニティにはお世話になっているので、PCだけでもFirefoxをメインブラウザにしておきたいがパスワード/履歴/ブックマークのデバイス間連携の利便性は捨てがたく、検証用として残すくらいになりそう。

いつのまにかvscode-rubyがdeprecatedになってた

github.com

Shopify's ruby-lsp and associated vscode-ruby-lsp are recommended alternatives to this extension. It is substantially easier to produce a high-quality LSP implementation using Ruby itself vs relying on another language such as TypeScript.

In addition, sponsorship of a project by a company like Shopify could help to ensure a high-quality developer experience going forward. Even with multiple people helping on this project, keeping up with Microsoft's development of VSCode plus the wide array of Ruby community tooling is a tall undertaking.

As of 4/2/2023, the VSCode extensions are not marked deprecated. They will be within the next few weeks.

いつのまにかvscode-rubyがdeprecatedになってた。今後はShopifyのRuby LSPを使うようにとのこと。

github.com github.com

ドメイン管理をムームードメインからCloudflareに移行した

経緯

このエントリを読んだのがきっかけ。 zenn.dev

自分はこれまでムームードメインを使っていて特に不満はなかったものの、Cloudflareは知ってるけど使ったことがなくて試したかったので移行した。ついでに維持費用が安くなると嬉しい。

ここでは方法については説明しないので移管元/移管先のドキュメントを読んでうまくやってください。
muumuu -> Cloudflareの場合は以下。

失敗

どうせ誰も見てない個人サイトだしと思って適当に設定しまくってたらページが表示できなくなった。
2ドメインまとめて移行して、それぞれVercelとGitHub PagesでホスティングしてるサイトだったんだけどいずれもToo Many Redirectsが出た。

これはCloudflareのSSL/TLS構成を「フレキシブル」に設定していたのが原因。
Cloudflare -> Origin Serverの通信がHTTPになってしまっていて、Origin Serverが308を返してリダイレクトループにハマっていた。SSL/TLS構成を「フル」に変更して解決。
詳しくはこの辺に書いてあります。

developers.cloudflare.com

vercel.com

思いがけず嬉しかったこと

Cloudflareだとwhoisで見れる個人情報をいい感じにマスクしてくれる。 developers.cloudflare.com

ドメインレジストラの会社情報を代理公開してくれるより全然ありがたい。

近況

随分と間が空いてしまった。1年以上もこのブログを放置しているあいだに転職した。

過去の記事を読んでいて気付いたが、fish shellを捨ててbashに回帰しているし(供養)、現職ではAWSもほぼ触ることなくオンプレ(供養)、仕事でGoは書いていないし(供養)、サーバサイドに加えてandroidの開発を担当するようになっていた。

これまでほぼRubyJavaScriptしか書いていなかったため、androidでKotlinを書いたのが初めての静的型付け言語体験であり戸惑った。
(大学でC#Java少しやったけど記憶にない)

Kotlinをある程度書けるようになってからずっと、結局Java知らないとつらいこと結構あるなと思ってUdemyで 【 5日でできる】はじめての Java プログラミング入門 を受講した。
www.udemy.com

感想としてはちょっとレベル設定をミスった感がある。これは初めてプログラミングに触れる人が受けるべき講座であって他言語でのプログラミング経験者には易しすぎる。ついでに言うと多分プログラミング入門者であっても5日はかからないはず(PC操作が怪しいレベルとかだと無理だと思います)。

そもそもJavaを学習しようと思ったのはKotlinの理解を深めるためというのももちろんあったけれど、デザインパターン, アルゴリズムとデータ構造の名著と呼ばれているものがいずれもJavaの実装例を載せているというのがある。これらをちゃんと理解していないという引け目が2年くらいある。

とりあえずJavaをかろうじて読み書きできるレベルにはなったので上記2冊やりたい。

. . .

そういえば私用PCをWindowsに鞍替えしたため、macOS用のステータスコードの辞書ファイルもまったく使わなくなってしまった…。(供養)

ローカル環境(macOS)のGoとGo Playgroundで同一コードの実行結果が異なる

ここ最近ちゃんとGoやろうと思って、A Tour of Go(日本語版)をやっているんですが、Appending to a sliceの章にあるサンプルコードの実行結果がローカル環境(macOS)のGoとGo Playgroundで違う現象に遭遇してしまった。コードは以下。

  • append.go
package main

import "fmt"

func main() {
    var s []int
    printSlice(s)

    // append works on nil slices.
    s = append(s, 0)
    printSlice(s)

    // The slice grows as needed.
    s = append(s, 1)
    printSlice(s)

    // We can add more than one element at a time.
    s = append(s, 2, 3, 4)
    printSlice(s)
}

func printSlice(s []int) {
    fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s)
}

ローカルの実行環境

$ go run append.go

len=0 cap=0 []
len=1 cap=1 [0]
len=2 cap=2 [0 1]
len=5 cap=6 [0 1 2 3 4]

Go Playground

  • The Go PlaygroundのAboutを参照

    • この記事を書いている2019/08/22現在、Goのバージョンは1.12.9とのこと
  • 実行結果

len=0 cap=0 []
len=1 cap=2 [0]
len=2 cap=2 [0 1]
len=5 cap=8 [0 1 2 3 4]

考えた原因

Goが実行される環境のOSによって結果が変わってしまうのでは?

-> DockerでLinuxのGo実行環境を作って試してみる

以下のdocker-compose.ymlでコンテナを作る。

version: "3"

services:
  golang:
    image: golang:1.12.9-alpine3.10
    tty: true
    volumes:
      - ./:/go
    environment:
      - "GOPATH=/go"

各環境でOS情報を取得してみる

以下のコードを実行。

package main

import (
    "fmt"
    "runtime"
)

func main() {
    fmt.Println(runtime.GOOS)
}
  • ローカルの実行環境(macOS)
darwin
  • The Go Playground
nacl
  • Docker上のGo実行環境
linux

naclがわからないのでググったらGo Playgroundの内部的なことを書いたGo Blogの記事を見つけた。

blog.golang.org

見つけたんですが、初学者ゆえにわからない点があまりに多いので一旦Docker上のGo実行環境での実行結果を確認します。

$ go run append.go

len=0 cap=0 []
len=1 cap=1 [0]
len=2 cap=2 [0 1]
len=5 cap=6 [0 1 2 3 4]

macのローカル環境で実行した場合と同じ実行結果。

Go Playgroundの内部的なところは難しそうなのでちょっと後で読んでみるとして、darwinlinuxで実行結果が変わらないことだけわかった。

引き続き調べようとは思うものの、誰か詳しい方がいたらご教授頂けると嬉しい・・・。

fishの自作関数の話(peco, fishだ〜いすき)

あなたは fish shell を使っていますか? fishshell.com

自分は数年fish shellを使っていて、当初は

  • bashより良さそう
  • zshほど頑張ってカスタマイズしなくても初期設定でかなり使える

くらいの印象で、導入した時点でもtab補完の強力さぐらいしか魅力を感じていなかったのですが、ここ最近fishで関数を自作することが多い。

手作業すれば必ず人間はミスる、しょっちゅうやる作業はミスらないよう機械に任せてお願いしましょう、というのが信条なのでこういうのは楽しいなと思う。

たとえば、普段Railsのプロジェクトでrakeタスクを実行するときあのタスクなんだったっけ?と思うとき、そういう場合 bundle exec rake -T を叩く -> 表示されたタスク一覧から任意のタスクをコピペして実行、というような方法を取っていたのですが、fishで関数を作ってpecoでインタラクティブに選択できるようにするとちょっと便利。
そもそも rake -T に時間かかるので待ち時間はそれなりに発生するが便利。
f:id:nkzsdy:20190227213103g:plain

Rakeタスクをインタラクティブに選択できるfish function

あと、似たようなもので、gitで特定のブランチにチェックアウトしたいときにもpecoを使った処理を関数化している。
ちょうどいいgitリポジトリが見つからなかったのでいいキャプチャが撮れなかったが、結構な数ブランチがある場合便利です。 f:id:nkzsdy:20190227212608g:plain

gitのブランチ一覧からインタラクティブに選択してcheckoutする

みんなで便利な関数および社会を作っていきましょう。
fish の日本語のリファレンスはるびきちさんによる以下のサイトが便利です。世の中便利なものが多くて便利ですね。自分も誰かの関数になりたい。

fish.rubikitch.com

AWS認定 ソリューションアーキテクト - アソシエイトに合格した(2019/02 受験)

AWS認定 ソリューションアーキテクト - アソシエイトに合格しました。
検索すればQiitaとか個人ブログとかでヒットすると思いますが、2019年に入ってからの受験記事が見当たらなかったので書きます。

ほとんど知識ゼロの状態からの受験で、所要期間はだいたい1ヶ月前後でした。
だらだらと勉強してしまうのが嫌で先に受験日を設定した、という方の意見をよく目にしたのですがちゃんとスケジュールを立ててやりきれる自信があれば是非そうすべきだと思います。
私は計画立ててちゃんとやるのが苦手なのでAWS公式の模擬試験で8割取れたら受験しようと思っていました。

目次

なぜ受けようと思ったか

一年前にAWSを試してみようと思いAWSアカウントを登録したのですが、できることが膨大すぎて手も足も出ず無料利用枠の期間が終わってしまっていました。

半年ほど前から業務で関わるようになった案件で、検証環境としてEC2インスタンスを作ったり壊したりしているうちにEC2以外のサービスを使ってみたくなり -> 体系的に学ぶなら資格対策が手っ取り早いのでは?と受験を考えました。

あとは、しばらく新しい対策本が出てなかったのですがちょうどいいタイミングで出版されたので受けてみることにしました。(「対策本を読む」の項で詳しく触れます)

受験前の自分のレベル

新卒でWeb系に入り2年目、普段はRuby on Railsのアプリケーションの設計・開発をやっています。AWSに関しての経験は業務でEC2インスタンスを立てたことがある程度でした。
EC2以外のサービスはELB, S3, RDS, Lambdaは何ができるか知ってる、他は有名どころは聞いたことある・・・くらいの感じです。

勉強法

試験の概要をつかむ

aws.amazon.com

上記リンクの 試験ガイドのダウンロード から、試験ガイドのpdfが読めます(読みましょう)

推奨される AWS の知識
• 可用性、費用効率、フォルトトレランス性、および拡張性が高い分散型システムを AWS 上で実際に設計した 1 年以上の実務経験。
AWS のコンピューティングサービス、ストレージサービス、およびデータベースサービスを使用した実務経験。
AWS の展開サービスおよび管理サービスに関する実務経験。
AWS 上で動作するアプリケーションに関する技術要件を明確にして定義する能力。
• 特定の技術要件を満たす AWS サービスを判断する能力。
AWS プラットフォーム上でセキュアかつ信頼性の高いアプリケーションを開発する際に推奨されるベストプラクティスに関する知識。
AWS クラウド上で構築するアーキテクチャの基本原則に関する知識。
AWS グローバルインフラストラクチャーに関する知識。
AWS に関連するネットワーク技術に関する知識。
AWS で使用できるセキュリティ機能およびセキュリティツールに関する知識、ならびに AWSのセキュリティ機能およびセキュリティツールと従来型サービスの関連性に関する知識。

これを読んでいる時点では一つも当てはまりませんが大丈夫な気がします。こういうときは無根拠な自信が大事です。

次に出題分野と試験における比重です。

分野 1: 回復性の高いアーキテクチャを設計する 34%
分野 2: パフォーマンスに優れたアーキテクチャを定義する 24%
分野 3: セキュアなアプリケーションおよびアーキテクチャを規定する 26%
分野 4: コスト最適化アーキテクチャを設計する 10%
分野 5: オペレーショナルエクセレンスを備えたアーキテクチャを定義する 6%
合計 100%

各項目で言わんとすることは大体わかりますがAWSの前提知識がないので具体的にどの分野でどういう問題が出るのかイメージできません。
なので、一旦飛ばしてサンプル問題を見てみることにします。

先程のリンクの サンプル問題のダウンロード からサンプル問題が見れます。(見ましょう)

ここに10問のサンプル問題があるのですが、この時点ではまったく解けませんでした。問題文に出てくるサービスを使ったことがないので具体的にイメージできず判断できないという感じ。

このサンプル問題を読んだ時点で、まず自分が対策本に取り掛かるべきか or その前に実際にAWSのサービスを触ってみるべきかという選択をするといいと思います。
例えば「こういう要件を満たすシステムをAWS上で設計してください」とお願いされたとして「あのサービスを使えばよさそうだな」というくらいに前提知識がある方は次のハンズオン形式の動画で実際にAWSを使ってみるは飛ばしてもいいかもしれません。

私は対策本の前に 実際にAWSを触ってみる ことにしました。

ハンズオン形式の動画で実際にAWSを使ってみる

これはAWS公式のトレーニングとかドットインストールとか、あるいはQiitaのハンズオン記事とかに沿ってやってみるとかいろいろ方法があると思うのですが、調べて検討した結果、一定期間でまんべんなく体系的に学べそうという理由でUdemyの以下のコースを受講しました。

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

自分はUdemyのセール期間に購入したので¥1400でした。本来は¥15600みたいです。

また、あとで気づいたんですが、講師の方のブログで配布されてるクーポンコードを使うと¥1200で購入できるみたいです。

www.ketancho.net

本来の価格とはいったいなんだったのか。どちらにせよありがたいです。
このコースは基本的にAWSの無料試用枠の範囲で収まるようになっています。

仕事が忙しかった日はサボってしまい結局2週間以上かかりました。
内容は以下の構成で基本的なことは抑えられたと思います。

  • Day1: AWSことはじめ【AWS アカウントの開設、IAM、CloudTrail】
  • Day2: EC2を使ってサーバを立てる【EC2】
  • Day3: VPCを使ってネットワークを構築する(1)【VPC、EC2】
  • Day4: VPCを使ってネットワークを構築する(2)【VPC、EC2】
  • Day5: リレーショナルDBのマネージドサービスRDSを使う【RDS】
  • Day6: Elastic Load Balancer(ELB)を用いて Web レイヤの可用性を高める【ELB】
  • Day7: オブジェクトストレージ S3 を使ってみる【S3、AWS SDK
  • Day8: Route 53 を使ってドメインを登録する【Route 53】
  • Day9: IAMについて理解を深める【IAM】
  • Day10: AWS CLIによるAWSの操作とCloudWatchを用いたシステム監視【AWS CLI、CloudWatch】
  • Day11: AWSにおけるコンテンツキャッシュとインメモリキャッシュの基本【CloudFront、ElastiCache】
  • Day12: Eメール送受信サービスSESとキューイングサービスSQS【SES、SQS】
  • Day13: アプリケーション開発を支援するCodeシリーズ【CodeCommit、CodeBuild、CodeDeploy、CodePipeline】
  • Day14: CloudFormationを用いた環境構築の自動化【CloudFormation】

コースを受けた後に再度サンプル問題を読んでみるとちゃんと意味がわかるようになっててすごいなと思いました。
ここからようやく試験対策に入ります。

対策本を読む

ソリューションアーキテクト アソシエイトの試験は2018年2月に大幅にアップデートされたようなのですが、他の受験記事をいくつか読んだところ、対策本は2016年8月発行の「合格対策 AWS認定ソリューションアーキテクト - アソシエイト」が定番だったようです。

サービスも試験内容もアップデートされているのに新しい対策本が出ていないから受験に踏み切れなかった方も多いと思うのですが、2019年1月末に新しい対策本が出たので私はそちらを購入しました。

この対策本を朝と夕の通勤時間と会社の昼休みに読んで3日くらいで1周目を読み終わりました。
2周通して読み終わったあとで付録の模擬問題を解きました。

正答率集計用に解答用紙を作っていたのでmacのNumbers形式ですが必要な方はお使いください(模擬問題もアップデートするらしいので正答の列が正しくない場合は適宜修正してください)。 (2023/07/17追記: 削除しました)
1回目を解いたときの正答率が66.2%でヘコんでたんですが、1回目はそんなものだと思います。かなりがんばったつもりでいたので8割いくっしょとか思っていた慢心でした。

間違えた箇所の解説はちゃんと読みましょう。
それでもあまり理解できなかった箇所だけ、AWS公式の通称BlackBeltと呼ばれる以下の資料集(スライド形式)の関連項目に目を通すようにしました。

aws.amazon.com

この模擬問題を3回解くつもりが2回目で83.1%取れたのでいけるっしょ感が出てしまい、AWS公式の模擬試験を受けました。

AWS公式の模擬試験(有料)を受ける

AWS公式の模擬試験を受けるには¥2160かかります。が、本試験とほぼ同じ形式の問題が出題されることや、本試験と同じ画面で同じ流れを体験しておくことで当日テンパる要素を少しでも減らしておくために受けておきます。

なお、受験にはAWS認定 アカウントの登録が必要です。AWSアカウントとは別物です。
本試験の際にも必要なのでこのタイミングで登録しておきましょう。(というかこの時点だともうアカウント持ってるのが普通なのかもしれない)

www.aws.training

以下模擬試験概要。

試験時間: 30分間
問題数: 20問
合格ライン: 明記なし
受験料: ¥2160

問題数少ないのであんまりしんどくないですね。

-> 結果

総合スコア:  80%

トピックレベルスコア:
1.0  Design Resilient Architectures: 88%
2.0  Define Performant Architectures: 100%
3.0  Specify Secure Applications and Architectures: 66%
4.0  Design Cost-Optimized Architectures: 0%
5.0  Define Operationally-Excellent Architectures: 100%

コスト最適化アーキテクチャの設計がかなり厳しいです。このあたりは実務経験がないのでなんとも身につきにくいのかもしれない。

が、冒頭で書いていた目標のAWS公式の模擬試験で8割には到達していたのでこの勢いのまま本試験の受験日を予約してしまいます。
受験場所と受験日を選択して、クレジットカードでの支払いを済ませたら予約完了です。

本試験を受ける

午前中ふつうに仕事して、午後休を取得して14:30から受験しました。場所は銀座の歌舞伎座タワーです。

別会場で受験した他の人の記事だと「試験中、カメラで監視されていて、下を向いていたり動きが不穏だと適宜注意が入る」など書いてあって緊張してましたがこの会場はそんなことありませんでした。
カメラも無いようで、下向くと注意されるどころか紙とボールペンが配られましたが一度も使いませんでした。アクセスも東銀座から直結なので近くの方はおすすめです。
30分ほど時間を残してテスト終了。

-> 結果
合格でした。
865 / 1000 点でした。合格ラインは720点とのこと。
(受験後その場でモニターに合否が表示されますが、AWS認定アカウントへの反映および内訳が見れるようになるまで2日かかりました。)

合格したのはいいんですが、やはりコスト最適化アーキテクチャの設計だけ「再学習の必要あり」でした。今後の実務経験でなんとかカバーしていきたい。

所感

情報系の資格試験について色々思うところはあるのですが、AWSはそのサービスの膨大さ、アップデートの早さなどを考えると体系的に学ぶというのがなかなか難しいと思います。
本試験の対策をしていればおのずと基礎的な知識をつけられるという点で良かったです。プロフェッショナル取得を目指すかと言われるとそれはちょっとわかりません。