Firefoxのシェア低下について
TwitterのトレンドにFirefoxがあがっていたのでちょこっと調べてみたメモ。
Firefoxの現状
Firefoxのシェアが6%まで低下していて、続々とWebサービスがFirefoxのサポート打ち切りを発表しているらしい。
以下は、statcounter社による2022年2月時点の全世界的なブラウザのシェア。
Firefoxは4.21%まで下がり対するChromeは62.78%のシェアを擁する。
過去3年間ほど振り返っても同じ傾向であった。
公式統計によると、2018年末のアクティブな（月間）ユーザーの報告数は約2億4400万人でした。
そして、2021年第2四半期末には1億9,800万に減少したようです。
つまり、ユーザーベースはなんと4600万人も減少します。
Chrome1強時代に考えること
「Internet for people, not profit」を目指す非営利団体のMozillaがシェアを落としてしまうというざっくりとした悲しみがある。
Microsoft EgdeもChromiumベースなので他の対抗馬はSafariぐらいになるのだろうか。
実際にはMozilla Corporationは課税対象で親会社のMozilla Foundationが非営利団体だったりするんけど、全ての利益はMozillaプロジェクトに還元されているのでこの認識であっているはず。
非営利団体としてGoogleとは違った目線・立場で仕様を策定していたり、セキュアなブラウザとしてかなり頑張っていたイメージがある。
たまにMozilla's Positionsを見てTC39のプロポーザルに対してMozillaはどんな意見を持っているのか見るのが好きだった。
特に「harmful」のラベルがついたものはよく読んでいる。
といっても個人的にはChromeを使っているし「何を言っているんだお前は」状態。
でも選択肢があり続けるのはよいことで、Webはもっとカオスであってほしいという個人的な願いを持っているのでこれから一所不住に色んなブラウザを使ってみようかと思う。
前述したTC39の件もあるのでこれからもMozillaには頑張ってほしいと思ってます。
https://donate.mozilla.org/ja/
少額ですが寄付してみました。
Terraform Cloud使ってみた
Terraform cloudを利用する機会がでてきたので調べる。
今回は簡単な使い方だけ。
初回実行用に公式がsampleを用意しています。
適当に使ってみるだけであれば↓でOrganizationとWorkspaceの作成をして動きをみることができるようになっています。
$ terraform login $ git clone https://github.com/hashicorp/tfc-getting-started.git $ cd tfc-getting-started && ./scripts/setup.sh
事前準備
今回はS3 bucketを作成するだけにしました。
terraform {
required_providers {
aws = "~> 3.74"
}
}
でversionを指定しているのは、S3 bucket resourceが大幅に変更が入ったためです。
うーん、個人で運用しているレベルなのでそこまで問題ないんですが、業務レベルで使用していると結構たいへんそうな
— mutao (@mutao_net) February 13, 2022
Workspaceの作成
3つの選択肢がありますが、今回はGitと連携して作成します。
「Version controle workflow」を選択。
対象のRepositoryを選択。これだけで完了です。
AWSのtokenを設定
variableで参照できるようにするため環境変数を設定します。
このとき「SENSITIVE」にしておくと設定したTokenが参照できなくなるため設定しておきました。
main(master)ブランチにmergeされると terraform plan が実行されます。
実行計画を確認したら「Confirm Plan」で terraform apply が実行されて完了。
実際にS3 bucketが作成されていることが確認できたら完了です
「Setting」から自動でapplyまでしてくれるようにも設定可能です。
退職エントリ
本日をもって2017年に新卒入社し、約5年ほど勤務した都内の某SIerを退職しました。
振り返り
入社の経緯
とある文系大学で全くプログラミングと関わりのない大学生活を送りながら就職活動をして突如エンジニアになることに決めました。
- エンジニアってかっこいい！
- 自分でなんでも作れる人間になりたい！
- スーツ着なくてもいい！
最初はこんなレベルでした。反省しかないです。
今になると私にとってエンジニアは天職だなと思います。
新卒入社からずっといたので比較対象はないですが。
日々見についていく技術、達成感、どこに手を出しても新しい世界が見えてくるワクワク感。
形容し難いほど魅力的な仕事です。
入社後
3ヶ月の研修期間に入ります。もちろんプログラミングとは縁がなかった私は酷いありさまでした。
研修時代のどうしようもない私をなんとかしようとあくせくしていた講師陣の方々には感謝の念しかありません。
入社後Javaの研修を受けてからPHPメインのプロジェクトにアサインされました。
「Javaじゃないじゃん。。。」と肩を落としていた講師の方々が今でも目に浮かびます。
案の定どうしようもない結果しか残せない私は社内の先輩エンジニアの方に相談し技術書を大量に購入して勉強してました。
勉強が嫌で仕事を辞めようと思うことはなかったです。むしろ成果を残せない現状をどうにかしたい一心でした。
ちょっとマシなエンジニアへ
亀の歩みで新卒時代とは違って「ちょっとマシ」なエンジニアへとなります。
それから案件をいくつかの案件を周り、某Web企業のエンジニアとして今まで3年近くお世話になってました。
リーダーをやったり、インフラエンジニアっぽいことをしたり。はたまたSEOについて勉強してみたり。
マネジメントの経験は初めてでこれもいい経験になりました。
- チームメンバーがパフォーマンスを発揮するためには
- 心理的安全性
- HRT
- メンバーのスキルセットを加味した上でのタスク割り振り
- シンプルな進捗報告の行い方
- 顧客折衝
- 仕事を得る(生み出す)ということ
当時同じチームだった@ryuichi_1208 さんが退職されてからはもろにインフラエンジニアでした。
@ryuichi_1208 さんは勉強熱心な方で、転職してからもどんどんとつよつよエンジニアになっている模様です。
お客様にもプロジェクトメンバーにもレベルが高い方が多く、モチベーションに一気に火が付きました。
反面、「こんなすごい人たちがたくさんいるんだ」という焦りにもつながりました。
そうして日々を過ごしていくうちに、使いたい技術が増え、やりたいことも明確になっていって転職に至りました。
ざっくり言えばインフラ領域を極めていきたいという感じです。
退職
有給消化
してないです。重要なのはできないのではなく望んでいないだけです。
仕事は好きですし、まとまった休みがあっても結局技術書を読むか、コード書いているだけです。
それなら土日と祝日、定時後でなんとかなりますし、退職で迷惑をかけたくなかっただけです。
立つ鳥後を濁さず。でできることは全てやろうと思いました。あと中途半端が嫌いです。
挨拶
退職が決まってからお世話になった色んな方に挨拶まわりやメールをしました。
色んな人から返信をいただきました。
飲み会での失敗談から仕事でのお礼まで。全て嬉しかったです。
お客様とコーヒーを飲みながらちょっとお話したりしたのでおセンチな気分です。
会社のGoogleアカウントからログアウトできずにチャットを読んで思い出にふけっています。
今後
次はSREとして働きます。
退職エントリを書いている今でも「次の会社で足手まといにならないだろうか」という不安でいっぱいです。
継続は力なりを胸に頑張り少しでも早くパフォーマンスを発揮できるようになりたいです。
願わくば自分の優位性みたいなのを持てるといいかなと思ってます。
〜〜ならmutaoだよね。みたいな人間として認知されたいです。
Dynalist駆動開発
Dynalist
MarkdownエディタのTyporaの代わりに出会ったアウトライナー
Githubっぽい見た目だったりで凄い重宝していたんですが、有料化してしまったので乗り換えました。
読書メモだったり、開発前のちょっとしたメモ書きをするのに使ってます。
ショートカットに慣れるまではちょっと時間がかかりそう。
あとは無料化のままだとそのまま画像をコピペすることはできないのでGyazoとかを使用してリンクを作らなきゃいけないのがちょっと残念。
このまま使うならProにします。
Dynalistでざっくり書いたものです。
自分専用の新聞的なもの作れたらいいなぁと思ったりしてました。
慣れるためなのでちょっとしたものをまずは書いてみて、コーディング中に気づいたメモをどういったフォーマットで書くか試行錯誤してみます。
完成したもの。
無理にAWS要素を入れてみたけど、これくらいだったら自宅サーバで動かす感じで良かったなぁと思った。
API Gatewayを使う必要は流石になかったので、Lambdaの定期実行にしました。
個人開発ならAPI Gatewayの出番はあんまりないかもしれない。もっと練って見よう。
今度はもっとAWSの要素を絡めたもの作りたいです。
使ってみた感想
勉強になったOSS
ただGitHubでスターをつけているだけだとなんとも実りがない気がしたので、メモかつ何がどう参考になったかというのをまとめておく。
全部に言えることは「実装がきれい」。
Go
fast-service
エキスパートたちのGo言語の「1.3 インターネット回線のスピードテスト」で知った。
- sync/atomiパッケージを使用した非同期処理の実装
- Goroutine/Channel型の実装
を学ぶには実践的でとてもよかった。
Goを学びたての時に読むと理解が深まると思う。
action-slack-notify
GitHubActionでslackに通知したいなと思ったときに使ったもの。
usesで定義する中身を知りたいなと思って見た。
中身はすごくシンプルかつやっぱり読みやすい。
Goの標準パッケージしか使ってないところを見ると流石と思う。
os.Getenvで各パラメータを参照しているところを見ると、実際どうなっているのかわかりやすいと思う。
こっちで指定したSlackのWebhookURLはコンテナの中で環境変数として設定されてるんだな。とか。
公式documentをななめ読みしたり、英語全然できないタイプにはもってこいのサンプル。
slackbot作りたい人も読むと参考になると思う。
私の中ではプログラミング言語はユニバーサル言語。
go-setlock
cronの多重起動を防ぎたいけど、CentOS7/8だしなぁと思っていたときに勧めてもらった。
daemontools-encore の setlock.c を見比べたりしてみると面白いと思う。
Go言語を読んでいたと思ったらいつのまにかC言語を読んでいたという出会いに感謝。
Perl
MySQLのスロークエリを解析したいときに使う mysqldumpslow。
「お世話になってます。あなたPerlだったのね。」と感慨深く？なった。
Perlで何かしら実装したことがある人は読めると思う。
MySQLに興味を持ち始めているお年頃なのでPerlを触る機会があってよかったと再認識できる。
Perlアレルギーの人もぜひ一度触ってもらいたい。何にしろ食わず嫌いはよくない。
GitHubActionsでghcrにBuild&Push
Githubの提供するghcr.io(GitHub Container Registry )でdocker imageを管理したいなと思ったのでやってみたときのメモ。
ArgoCDをLocalで試してみるにあたっての前段階的にやってみた。
事前準備
- ghcr.io の認証
ログインにgithubの Personal Access Tokenが必要なのでそれも容易しとく。
手順は公式で書かれているものがある。
Tokenのpermissionはドキュメントにあるように、read:packages write:packages があればよい。
docker login ghcr.io した後に動作確認を兼ねて docker tag docker push で Githubの Packages にdocker imageが表示されれば問題なし。
- Dockerfileの準備
適当にbuild対象になるDockerfileを容易しておく。
今回はFlaskのDockerfileを作っていたのでそれを使用。
上記の記事で使ったもの。
Workflow作成
公式ドキュメントにあるサンプルを一部改変したものです。
とりあえず動作確認で動かしたかったので pull requestをトリガーに動かすようにする。
password: ${{ secrets.GHCR_TOKEN }} は Personal Access Token を指定。
env.github.XXX は 公式ドキュメントのコンテキストを参照。
name: Publish Docker image
on:
pull_request:
env:
REGISTORY: ghcr.io
IMAGE_NAME: ${{ github.repository }}
jobs:
build-and-push-image:
name: Push Docker image to Docker Hub
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- name: Check out the repo
uses: actions/checkout@v2
- name: Log in to Docker Hub
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
with:
registry: ${{ env.REGISTORY }}
username: ${{ github.actor }}
password: ${{ secrets.GHCR_TOKEN }}
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
with:
images: ${{ env.REGISTORY }}/${{ env.IMAGE_NAME }}
- name: Build and push Docker image
uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
with:
context: app
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
これで pull reqestを作成すれば、GitHub Actionsが実行される。
GitHubActionsでlinter実行
ただのメモ書き。過去のツイートを漁ってたらlinter仕込みたいってつぶやいたのでやってみた。
HCLのlinterをmerge前に仕込みたい
— mutao (@mutao_net) December 31, 2021
tflintって言えばいいのに。
super-linter
github公式のsuper-linterというのがあったのでそれを使います。
サポート言語も豊富で、とりあえずこれ使っておけば！という感じ。
.github/workflows/hoge.yml として置くだけ。
ymlの中身はREADMEをそのまま持ってきて token の部分だけ変更すれば大丈夫。
name: Lint Code Base
on:
pull_request:
jobs:
build:
name: Lint Code Base
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Lint Code Base
uses: github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: main
GITHUB_TOKEN: ${{ secrets.LINTER_TOKEN }}
結構時間かかる
差分ファイルだけlinterを実行する VALIDATE_ALL_CODEBASE: false を設定しても 1m30s ぐらいかかりました。
というのも image pull で 1m30s かかっているので最低限このくらいかかるという指標にはなりそう。
大量にソースを管理しているリポジトリではlinterの実行時間も合わせてもう少し時間がかかりそうです。
バク？みたいな謎の動物のAAが可愛い。
こういう遊び心好きです。
