ひさしぶりにzshに戻りました - ちなみに
仕事用のマシンをM1 MacBook Proに交換してもらったので、開発環境を整え直しました。 2年ほど fish を使ってきたのだけれど、普段は良いのだけれど、ちょっと自動化したくなったときに、やはりPOSIX準拠じゃないシェルはなかなか難しかった。macOSの標準も zsh になったことだし、久しぶりに戻ってみることにした。 導入 現代なので XDG Base Directory Specification に乗っかっておくことにする。 Arch Linux の Wiki がよくまとまっていて助かるのでこれを参考にして進めた。 zshの場合は ZDOTDIR を指定するといいのだけれど、これをどこで指定するのかという問題がある。zshの起動時に最初に読み込まれるユーザー設定は ~/.zshenv なのだけれど、ここに ZDOTDIR を書くということは .zshenv だけホームディレ
GitHub Actions のワークフローをチェックする actionlint をつくった - はやくプログラムになりたい
GitHub Actions のワークフローを静的にチェックする actionlint というコマンドラインツールを最近つくっていて，概ね欲しい機能が揃って実装も安定してきたので紹介します． github.com なぜワークフローファイルの lint をすべきなのか GitHub Actions が正式リリースされてからだいぶ経ち，GitHub 上での CI は GitHub Actions が第一候補となってきているように感じます．僕も新規にリポジトリを作成して CI をセットアップする場合はほぼ GitHub Actions を使っています． ですが，GitHub Actions には下記のような問題があり，actionlint でそれらを解決・緩和したいというのが理由です． ワークフローを実装する時は，GitHub に push して CI が実行されるのを待って結果を確認するという
# フロントエンドエンジニアのステップアップのための集合知 ジュニアとミドルはソフトスキル多めなのでフロントエンドエンジニアに限らなそうです - 期待役割 ... 該当ステップ内での TO BE - できてほしい ... 該当ステップ内での WANT (🔐は次ステップへ進む上では MUST) - 次のステップへの期待 ... 次のステップへ進む上での MUST ## ジュニア (ステップ1) ### 期待役割 - 指示された小さいタスクをこなすことができる - ~3人日くらいの影響範囲の閉じたタスクを想定 - 仕様が決まっている、あるいは不明な場合は質問できる ### できてほしい #### ハードスキル - 初歩的なセキュリティバグを生まない - #### キーワード - XSS - コード内に必要に応じて意図をコメントとして残せる - #### 🔐自立的にファイルや関数を分割ができ
GitHubが狙う「ライブラリのバージョン管理問題」の解決と依存関係地獄の話 - ぶるーたるごぶりん
GitHubが狙う「ライブラリのバージョン管理問題」の解決と依存関係地獄の話 Githubが OSS Security Foundation に入りましたね。 大変興味深くて 関連するドキュメント なりについて会社のチームで雑談していたところ、 GitHubの「DependaBot」が何を狙い、どういう「大きな課題」を解決するのか？ という話において、点と点が結びついた感じがあるので言語化してみます。 「この大きな課題」を説明する前に Dependency Hell について国内で言及してる記事がそれほどないので その辺りをまずは書いていきます。 ここのあたりが国内の開発者の中でも認識が広まっていくと、より一歩先のステージにいくのかなと思うので、 比較的ラフな感じで書いていきます。 ちなみに、このブログ記事は所属組織とかに関係なく個人で執筆しています。 なので1デベロッパーとして、
チームやプロジェクトを率いる立場で意識していることの1つに、「メンバーがタスクをやり切ったと継続的に感じられる仕組み作り」がある。特にスクラムを採用している場合は ”前に進んでいる感” を継続的に醸成していく事も欠かしてはいけないと思っている。ただ現実にはこの観点は悪気なく疎かになってしまうケースが（自他共に）多いという感覚がある。 Pull Requestレビューを例にしてみる。2週間スプリントのアジャイルチームでとあるプロジェクトの主担当として開発をリードしているエンジニア氏。仕様検討・周囲との調整・実装を頑張ってPull Request作成まで漕ぎ着けた。エンジニアは一旦ココで”仮達成感”に浸る（と、個人的に思っている）。そしてレビュワーにレビューを依頼して、反応を待つ。のだが。。。 スプリント1: 「進捗してます」「pullreqレビューをassignされたエンジニア程、別件で忙し
この記事は LITALICO Engineers Advent Calendar 2021 その2 の7日目の記事です。 Pull Requestを作るときに割と入念にセルフレビューしてからレビュー依頼するようにしており、また他メンバーのもののレビューをしているときに「これは事前にセルフレビューして修正しておいてほしいなぁ」と思うことがあり、セルフレビューの重要性を感じるこの頃です。 レビュー時に都度指摘してもよいのですが、意外と観点が多いこともあり、思考の整理がてらアウトプットしてみるか、という試みです。 なぜ自分でレビュー？ まず、そもそも自分で書いたコードを何故自分でレビューするのか？という点について書いておきます。 よくプログラミング一般の議論で「N日前のコードは他人のコード」と言われます。ということは、Pull Requestを作成した時点の自分から見て、該当コードを書き始めた時
GitHub Organization の管理の仕方
導入 GitHub の Organizationの管理をする機会を得ましたが、管理機能については不勉強でしたので、公式ドキュメントを読み込み、ここにまとめます。 本記事は、主に以下のような疑問を持つ方に役立つ情報を記述しています。 Organizationってなに？Projectsってなに？Teamってなに？ どういうまとまりで管理者がいる？ Organizationには個人で加入可能？Teamに入らないといけない？ Teamは入れ子構造にできる？ 権限はオーバーライドされる？権限のレベルにはなにがある？ Organizationでまとめられた大きなグループを「階層型組織として管理するTeam」という概念、「プロジェクトごとに管理するProject」という概念がある中で、権限周りの管理はどうやって区分けしたらいい？ 1. 各用語の定義 Organizationとは？ Organizatio
Github上にローカル環境からTerminalなどのコマンドラインを使ってPush,PullRequestを作成する流れをまとめてみました。 大まかな流れ ①Github上からローカルにファイルをclone(保存)する ②GithubへPullRequest用のBranchをローカルで作成する ③データを更新編集し、ローカルに add, commitする ④Githubにpushする ⑤GithubにPullRequestする ※⑥PullRequestをMergeする 用語の整理 ①Github…オンライン上にレポジトリーを保管し、複数人で共有・編集できる ②ローカル…自分のPC ③clone...Githubなどオンライン上のリポジトリーをローカルにコピー保存すること ④Branch...１つのレポジトリに複数のBranchを作ることで同時に複数のバージョンでレポジトリを管理すること
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 18日目の記事です。 TL;DR下記のような CI (継続的インテグレーション) のユースケースを Skaffold + Cloud Build + GitHub Actions + k6 で実装してみました。 ローカル環境で、アプリケーション、コンテナ、Kubernetes デプロイのテストを継続的に回しながら開発をする。プルリク作成時、レビュー前に GCP 上でビルド & デプロイをテストして、合わせて API のパフォーマンス測定を行なう。サンプルコードどこにまとまってるの？という方は こちら。 はじめにこんにちは、Google Cloud の Koichi です。 Kubernetes 上にデプロイするアプリケーションをローカル環境で開発するとき、アプ
以前にhuggingface/trasformersで固有表現抽出する方法を試してましたが、日本語ではうまく動かせませんでした。今回は日本語の言語モデルの上にファインチューニングして固有表現抽出出来るところまでやってみます。 前回: huggingfaceのtransformersでNER(named entity recognition)を試してみる huggningface/transformersのexampleのファインチューニングのコードがちょっと複雑だったのでどうしようかと思っていたら、どうやらRasaも対応しているらしいので、Rasaの上で動かしてみようと思います。 以前にRasaをいじっていたときの記事一覧 まずはRasaで日本語の固有表現抽出出来るところまで(Spacyを利用) huggingface/transformersを使用する まとめ 2020/04/29追記
今年を振り返ります。 2019 年の大きな出来事について 今年も終わるので全部正しくさらけ出して振り返ります。 反省 仕事でやりきれなかった なんだかんだで一年中複業体制でいましたが、夏頃は本業のプロジェクトの都合で副業をコミットできず迷惑かけてしまったのが反省です。 本業自体が炎上気味で、私のレイヤーでできることはやったので仕方ないとはいえ、まぁ所属する組織規模が大きくなるとパワーで解決できてもできないみたいなことが多くなるのは考慮すべきですね。 このあたりはもどかしさがありつつも色々と学びもあった一年。あんまり物事に首突っ込みすぎるとフリーランスのときとは違って困ることが多そうなので、なんだかんだで手を動かすのは連休期間くらい、それ以外は基本は技術相談だけ請けておくようなスタイルが今の私にはマッチにしてそうだなという結論になりました。 なので多分当分はコード書く系の仕事は個人としてはあ
N-ISUCONを支えた技術 - Qiita
この記事は NTTコミュニケーションズ Advent Calendar 2019の1日目の記事です． はじめに 大昔に1度投稿したきり，お久しぶりななおすけです． 気がついたら就職をして，とある会社でお世話になっています． 最近はESXiと戯れながらRubyを書く仕事をしています． さて，本記事はN-ISUCONの運営を支えた技術について解説します． これまで，社内ISUCONの問題公開はあっても，裏側の話はあまり見かけなかったので書いてみました． N-ISUCONについて知りたい方はこちらの記事を参照ください． N-ISUCONのアーキテクチャ 競技VMの構成 競技者には，リソースとして下図のようなGCE上のVM(競技VM)が3台提供されていました． 初期状態として，下記のソフトウェアがインストールされています． Apache HTTPD Server MySQL 問題実装の言語やそのラ
お、pullreqきてる。コンポーネント生やしたのかなるほど。storybookにも追加されてるな。 ...ちらっとでいいからstorybookの画面でも触りたいなぁ。 TL;DR webアクセスをIP制限したS3バケットを用意し、pullreqごとにgithub actionsでstorybookをビルド・S3にアップ・pullreqにURLをコメント、という仕組みを作った やりたいこと pullreqごとにstorybookの画面を見たい テスト環境にアップしてもらったり、checkoutしてビルドして、とかは面倒 プレビューはインターネットに公開したくない（アクセス制限したい） ちらっと見れればよいのです。pullreqにスッと置かれたリンクをおもむろに押して、軽く触ってみて、うんうん、と頷くくらいがよいのです。 なお成果物のリポジトリはこちら: https://github.com
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドエンジニアのステップアップのための集合知 - HackMD
アンチパターン “ゴールが延び続けるスクラム”
Pull Requestのセルフレビューでやっていること
初心者向けGithubへのPullRequest方法 - Qiita
Skaffold + Cloud Build で Test にパフォーマンス測定を加えた CI を回す
Rasaとhuggingface/transformersを使って日本語の固有表現抽出する - もふもふ技術部
2020年に向けて - potato4d log
pullreq毎にprivateなstorybook(や静的webサイト)プレビューを作る