ワルシャワ渡航記 Part41: プロジェクト移動から1年たった
プロジェクトを移動してから1年経ったらしい。仕事でやってきたことを記録して自己肯定感をあげてみようと思う。 Typescript の approver の権限をゲットした。しばらくの間、Typescript分からなすぎてコピペばっかりしていた。YoutubeでTypescript講座を見てからはだいたい分かるようになってきた。何事も基本が大事ということを再認識した。調子に乗って既存コードを大量にリファクタリングしたら、何も動かなくなってしまった。RxJSのことが何も分かっていなかった。CSSのレイアウトの基本的すぎることを質問したら、「お前、本当にフロントエンドのこと何を知らないんだな」と呆れられた。HTMLだけは分かるぞと油断していたら、i18n とか a11yとかの細かいルールや設定方法などに圧倒された。半年くらい経ったら、approver的な権限が付与された。気づいたら大体のことは自
ChatGPT 活用術 - 結婚式のスピーチ -
地元の友人のタカシが結婚することになった。結婚式のスピーチを頼まれたので、ChatGPT（無料版）と一緒に原稿を作ることにした。 > 親友のタカシが結婚することになった。結婚式のスピーチを考えて。皆さん、タカシの結婚式にお集まりいただき、ありがとうございます。 タカシ、おめでとう！君の結婚は本当に嬉しい。君は信頼できる友人であり、いつも明るい笑顔で周りを楽しませてくれる存在だ。君とパートナーが出会い、愛を育んできた姿を見て、心から感動したよ。 二人の未来は明るく、幸せに満ちたものになることを願っている。結婚生活は時に困難もあるかもしれないけど、お互いを支え、尊重し合って歩んでいってほしい。素敵な家庭を築き、いつまでも愛し合いながら幸せに過ごしてほしい。今日の特別な日を祝福し、幸せな結婚生活の始まりを祈っています。 > 以下のエピソードをスピーチに盛り込んで。タカシは学生時代”リーダー”とか
ワルシャワ渡航記 Part38: レイオフがあった
会社でレイオフがあった。何人かの同僚が会社を去ることになって非常に悲しい。「会社に来たらなぜか入館証が機能しなくてクビになったことを知った」とか、「会社のサイトに突然ログインできなくなってクビになったことを知った」など、日本企業では考えられないような混乱があった。 個人的な意見だが、レイオフという経営判断は正解だったと思う。レイオフをしないで数年後に会社に大きなダメージを与えてしまうよりは、はるかにましな選択だし、当然の選択だったと思う。むしろ判断は遅かったとすら思う。 いちワーカーとしては最悪自分がレイオフされてもいいと考えていた。いくら景気が悪いといってもBig Techで働けるくらいのスキルがあれば、再就職に困ることはないだろう。いっそ無職になって2,3年遊んで暮らしてみるのもいいかもしれないし、起業にチャレンジするのもいいかもしれない。みんな悲観的になりすぎだろうと呑気に考えていた
ワルシャワ渡航記 Part27: 財布不要説
ワルシャワに来てから紙幣・硬貨をほとんど使っていない。古びた印刷屋さんにコピーをしに行ったとき、さすがにクレジットカード使えんやろ（代金は10円とかのレベル）と思ったがそこでもクレジットカードが使えた。 最初の方はクレジットカードを財布に入れて持ち歩いていたが、どうやらApple Payにクレジットカードを登録しておけばiphoneから支払いができることに気づいてからは、財布を持ち歩く必要が無くなった。日本ではうっかり財布を忘れて「電子マネー使えますか？」って聞いて「使えません。」って言われて家まで帰ることが何回かあったが、今のところポーランドではそのような経験はせずに済んでいる。 Apple PayはEMVという仕様に対応している。EMVは、MastercardやVisacardが共通で策定したコンタクトレス決済の標準仕様で、もともとはクレジットカードを非接触決済で使うための仕様らしい。
ワルシャワ渡航記 Part18: ワクチン摂取証明を求められる
今日喫茶店に行ったら、外国人らしきおじさんと店員が言い争っていた。 店員：「英語通じてるか？」 おじさん：「通じてるよ。だからカプチーノくれよ」 店員：「その前にワクチン摂取証明をみせてくれよ。店の中は人が多くなっているから、証明書がない人は入れない」 おじさん：「分かったから、カプチーノくれよ」 これが何回か繰り返されたあと、店員側が折れて、おじさんはカプチーノをゲットすることができた。 さて、自分の注文の番がやってきた。日本政府のワクチン証明はまさかの紙媒体なので、当然持ち歩いているわけがない。もしものときのために iphone のメモ帳で Document Scan しておいたものがあったので、試しにそれを見せたら無事入れた。 店員さんは明らかにちゃんと内容確認していなかった。こんなゆるいチェックでいいのだろうか？スキャン画像なんていくらでも偽造できるんだから原本の提出を求めるべきで
Google の 二段階認証が快適だった
After you enter your password, you’ll complete a second step on your phone. Keep your phone nearby when you sign in. 2-Step Verification will be turned on automatically on December 9. You can turn this on sooner if you want — your account is all set.
ワルシャワ渡航記 Part8: Public Transportation
Jakdojade というアプリを入れておくとスマホでチケットを購入できる長期滞在で頻繁に交通機関を利用する場合は定期券（ワルシャワシティカード）を買った方がお得2021/4 から Jakdojade で買ったチケットは乗車後に有効化（validate）する必要があるこれがなかなか厄介な仕様らしく、利用者から批判が出ているらしいチケットを買ったときに、すぐに有効化するか、後から有効化するか選ぶことが出来るすぐに有効化するを選んだ場合は、下のような画面が表示されるので、20秒以内にQRコードをスキャンしなければならない。後から有効化するを選んだ場合は、QRコードをスキャンできる状態（乗車直前など）になってから有効化すればOK バスに乗る場合路面電車の場合と同じ地下鉄の場合改札にQRコードがあるので、これをスキャンする有効化されたチケットを選択し「show to the control」ボタン
class SRE implements DevOps
DevOpsはDeveloperとOperatorの障壁を取り除くための指針Developerは新しい機能を早くリリースしたいOperatorはシステムが安定して動くように新しい機能をリリースしたくないSREはDevOpsの実装の1つ プロダクトごとに求められる availability は異なるavailability の定義もプロダクトによって異なるSLI(Service Level Indicators) 過去5分間の95-percentile latencyが300ms未SLO(Service Level Objectives) 年間を通してSLIが99.9%正常であるSLA(Service Level Agreements) 年間を通してSLIが99.5%未満しか正常でなかったらカスタマーに返金する
Availability と Reliability の違い
いまいち違いが分かっていなかったのでメモ。結論からいうと、用いる指標が異なる。 Availability（可用性）は稼働率を指標として用いる。 稼働率 = (経過時間 - ダウンタイムの合計時間) / 経過時間 これに対して、Reliability（信頼性）は MTBF（平均故障間隔）、または MTTR（平均修復時間）を指標として用いる。 MTBF (Mean Time Between Failures) = (経過時間 - ダウンタイムの合計時間) / インシデント数 MTTR (Mean Time To Repair) = ダウンタイムの合計時間 / インシデント数 Availability の方はシステムが利用可能な時間の話で、Reliability の方はどれくらい壊れやすいか、壊れたときにどれくらい早く対応できるかという信頼性の話をしている。 例を使って考えてみる。 システム
ecsとasgを使ってオートスケールするサービスをterraformで構築する
GWの自己研鑽最終日です。前回試したCapacity Providerを用いたコンテナインスタンスのAutoScaleとECSサービスのAutoScaleをterraformでやってみました。 すでにterraformを書いている人たちがいたので、まずはそれをリファレンスと照らし合わせながら読んで理解するところから始めたThirosue/terraform-samplewaneal/terraform-test-ecs-capacity-auto-scalingterraformを書いたググると二種類のAutoScaleのどちらかをterraform化したものは出てくるのだが、どちらもやっているのは見当たらなかったので書いてみたterraformのファイルのprefixに番号をつけておくと、何から作っていったのかがわかりやすくていいかもと思ったvpcまわりをterraformで書くのは初め
ecsとasgを使ってオートスケールするサービスを立ち上げる
GWの自己研鑽４日目のメモです。 AWS ECS（EC2起動）でのAuto Scalingまわりの調査＆検証をしました。 サービスの Auto Scaling公式ドキュメントを読んだECSはサービスのリソース使用率（CPUやメモリの使用量）メトリクスをcloudwatchに発行しているこのメトリクスを利用して自動的にサービスのスケールイン・スケールアウトをすることができるターゲット追跡スケーリングをやってみたコンテナインスタンスの auto scalingEC2起動の場合はサービスをホストしているコンテナインスタンスのauto scalingも考慮する必要がある。公式ドキュメントを読んだCapacity Providerというものを使うといいらしいCapacity Provider = クラスタ中のタスクが利用するインフラを管理するやつtarget capacity（0~100）を定義する
ビルドしたamiを使ってecsクラスタを起動する(EC2起動)
AWSのお勉強の続きです。 前回ECS Optimized AMIをベースに作ったカスタムAMIをクラスタとして起動して、ECSを動かしました。 EC2起動のECSのgetting-startedをやってみるECSコンテナインスタンス = ECSコンテナエージェントを実行していて、ECSクラスタに登録されているインスタンスのことECSコンテナインスタンスには Amazon ECS コンテナインスタンス IAM ロールが必要まず空のECSクラスタを作成するクラスタテンプレート「EC2 Linux + ネットワーキング」から作成しようとすると、最新のECS Optimized AMI以外は利用できないっぽい次にECSコンテナインスタンスを起動する起動したECSコンテナインスタンスをクラスタに登録するバインドマウントでEC2インスタンスのライフサイクルに関連づけたデータをマウントするアプリもちょ
packer&ansibleを使ってamiをビルドする
GWの自己研鑽の続きです。 職場ではAMIの作成まわりは別のチームの人が担当しているので、自分でpackerを使うのは初めてでした。初歩的なことをやってみただけですが、雰囲気だけでも掴めて良かったです。 公式サイトの aws-get-started をやってみた新しいバージョンではHCLが使え るらしい作成したリソースを削除し忘れないように注意！サービス - EC2 - AMI から登録解除サービス - EC2 - スナップショットから関連するスナップショットを削除HCLを書くための環境を整えるIntelliJ に HCL プラグインを入れるECSをEC2起動するために使うカスタムAMIを作成するAmazon Linux2 の ECS Optimized AMI をベースに作ることにした対象のAMI名は以下のコマンドで探せるっぽいaws ssm get-parameters --names
ecsで簡単なサービスを立ち上げる(Fargate起動)
公式サイトのgetting-startedをやってみたFargateを使うとサーバーの管理が不要なので便利！適当なアプリを作ってecrにpushしたgetting-started では Docker Hub にある既存の image を使っている自作の image を使ってみたかったので、テキトーな image を作ったdocker や ecr まわりの丁寧な説明が公式ドキュメントにあるecrにpushしたimageを使ってサービスを実行したクラスタ、タスク定義、サービスを作ったタスクとサービスの違いが曖昧だったが違いが分かったタスク = どの image でどのプログラムを実行するかを定義サービス = どのタスクをどのクラスタで動かすか、デプロイ戦略はどうするか、タスクを何個動かすか、負荷分散はどのようにするかを定義
ドルで言われてもすぐに分からない
例えば1ドルだったら100円かと分かるのだが、「この市場は one hundred billion の規模です」と言われると「billion が 10億だから、10億が100個で1000億ドルか。これを円に直すと10兆円か」とどれくらいの数字か理解するのに時間がかかってしまう。
GCP MPI Cluster
https://github.com/Kenji-H/gcp-mpi-cluster （このブログを書いているときはv0.9.1のものが最新です） クラウドサービスに Google Cloud Platform、インフラの構築自動化に Terraform、構成管理ツールに Ansible、並列コンピューティングのライブラリに MPI を使っています。 0. Google Cloud Platform（GCP）のアカウントを持っていない場合は作成してください。また、ローカルマシンにTerraform、Ansible、jq が入っていない場合はインストールしておいてください。 1. GCPのコンソール画面から「Compute 管理者」ロールを付与したサービスアカウントを作成します。 2. サービスアカウントキーを生成し、terraform ディレクトリ直下に account.json という名
プロジェクトごとの環境変数の管理
複数のプロジェクト開発を担当していると、プロジェクトごとにさまざまな設定を管理しないといけない。 たとえばプロジェクトごとに aws アカウントが異なる場合は、 profile を作っておいて aws コマンドを実行するときに profile オプションを付ける必要がある。しかし、プロジェクト数が多くなってくると、profile 名何だっけ？となることがある。 他にもdbの接続情報などをプロジェクトごとに使い分けたかったりする。 direnv というツールを使うとディレクトリごとに環境変数を管理できるらしい。.envrc というファイルを作って環境変数を定義すると、そのディレクトリの中でのみ有効になる。 例として、projectX と projectY というディレクリを作って設定をしてみる。 $ mkdir projectX $ cd projectX $ echo "export MY
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"Top signs of an inexperienced programmer" by TechLead
"Time Management tips for productivity" by TechLead
ラッパー、バインディング、ポーティング