概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 push時に実行 // feature/aaaで動く。 feature/aaa/bbbでは動かない on: push: branches: - feature/* // feature/aaa, feature/aaa/bbbで動く on: push: branches: - feature/** // なにかしらのtagがpushされたときに実行、branchのpushは無視 on: push: tags: [ '**' ] branches-ignore: [ '**' ] // 指定したpathの変更だけでは実行しない on: push: branches: - main paths-ignore: - '*.md' - 'docs/**' on: workflow_dispatch: inputs
Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います(@t_keshiさんありがとうございます!)。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成
全社員がリモートワークで働くGitLabが今日、米NASDAQ市場に上場。時価総額は約1兆2000億円に GitLab社が米NASDAQ市場に上場を果たし、14日午前9時半(現地時間)にニューヨークにあるNASDAQ市場のオープニングベルを鳴らすセレモニーを同社共同創業者兼CEOのSid Sijbrandij氏と同社共同創業者でエンジニアリングフェローのDmitriy Zaporozhets氏が行いました。 売り出し価格は77ドルで、同社の時価総額は110億ドル、日本円で約1兆2000億円となりました。 同社がサービスを提供しているソースコード管理の分野やDevOpsの分野には、マイクロソフトに買収されたGitHubという強力な競合企業がすでに存在し、それ以外にもDevOpsのためのソフトウェアやサービスを提供する企業が多数存在しています。 そうした中で、創業当初からオフィスを持たず、世界
仕事では日々の忙しさに追われ、根本的な問題解決に手が回らないことがよくあります。 やらなきゃいけない大切なことがある。でも、日々の業務が忙しくて着手できない…このような問題を『樵きこりのジレンマ』と呼びます。 昔々、樵きこりが木を切っているところに、旅人が通りがかりました。 ある樵きこりが、必死に木を切っていました。 そこへ通りがかった旅人が、 樵きこりの斧は長く手入れがしてないようで、刃がボロボロです。 これでは切れるわけがありません。 旅人は見かねて「そんな斧では仕事ができなかろう。斧を砥といだほうがいいのでは?」と、樵きこりに助言をしました。 すると樵きこりは、答えました。 「そんなことは知ってるよ…でも、今日の仕事が一杯で、それどころじゃないんだ」中長期で考えれば、未来への投資をするほうが正しいのに、短期視点では現在の作業に全リソースを投入せざるをえない。 いわゆるパラドックスの一
こんにちは、よしこです。 株式会社ナレッジワーク というスタートアップで、2020年4月の創業時から一人目のフロントエンドエンジニアをしています。 初期に考えて組み上げたスタックで1年半ほど開発・運用してみて、なかなか快適に日々開発ができているので 新規開発のプロダクト立ち上げ時にどのようにフロントエンドを構築したのか? 立ち上げから1年以上開発・運用を続けてきた今、それらの選択はどうだったのか? を記事にして振り返り、公開したいなと思いました。 (プロダクトの内容はステルスで進めていてあまり対外的な発信ができないので、かわりに技術的なところはどんどんオープンにしていきたいなという気持ちがあります) いろいろな項目ごとに振り返りたいので、この記事は各項目を横断するindexとして項目ごとの概要を簡単に説明し、深堀りは項目ごとに追って詳細な記事を書いていく予定です! 前提 プロダクトとしての
こんにちは!グラフィックデザイナーのあすみです。 今日は、資料やパワーポイントの作成に役立ちそうなデザインのポイントをご紹介したいと思います。 「資料はよく作るけど、ピンとこない」「もう少しできる気がする」など、ちょっとしたもやもやを、デザインのポイントで少しでも解決できたら嬉しいです! 今回のテーマは、どうしても悩みがちな「色」について! 色使いについては、プロのデザイナーでも非常に難しく、正直たくさん時間をかけても説明しきれません。このブログでは初歩的なコツについてお伝えします。 まずは、世の中にたくさんある「色」について、どんな種類ごとに分けられるかをいくつかの観点で見ながら、どんな色の組み合わせだと良いのか考えていきましょう。 「暖色」と「寒色」 この分け方は一番ポピュラーで、デザインや色彩学について勉強していなくても、どの色が暖色・寒色かなんとなく分けられるのではないでしょうか。
1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。
こんにちは。askenでエンジニアリング戦略や組織づくりを担当しているやすにしです。 マネジメントを中心にしておりまして、せっかくなのでブログでもマネジメントについて書いてみますね。 私はこれまでVPoEとしてエンジニア組織のマネジメントや、様々な会社でマネージャー向けにコーチング 1 をやってきました。そこで接してきたエンジニアリングマネージャーに共通しているのは「キャリアに悩んでいる」ということです。 例えばこのようなことです。 コーディングをしなくなり、技術的に取り残されて、エンジニアとしてやっていけなくなる感じがする 自分でやらないから成果が見えない。やっている感じがしない。 マネジメントをどうやればいいか、どう学べばいいかわからない。 マネージャーのキャリアで自分は定年(?)まで生きていけるのか? 共通点は、色々理由を言葉にしているものの、どれもしっくりきている感じではなく、「な
It's time to ditch Google Analytics Google Analytics is frustrating to use, difficult to understand, slow to load and privacy-invasive. That's why we built Plausible Analytics, a simple but powerful, lightweight (< 1 KB), open source and privacy-friendly alternative. Here's what makes Plausible a great Google Analytics alternative and why over 12,000 paying subscribers trust us with their website
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く