2020年のフロントエンドエンジニアの技術スタックの一例
年の瀬なので、私自身が今年利用した技術をベースに技術スタックをまとめてみようと思います。 とはいえ Web Standard といった広い対象から、フレームワークやライブラリまで、粒度の違うものを全て言及するのは無理があるというもの。特に強く言及できるものは個別で説明しつつ、最後に利用する機会がなかったものも最後に記載する形で。 以下常体。 追記: マイナー企業のようなので一応書いておきますが、筆者は本業ではLINE株式会社という組織でいわゆるエンジニアリングマネージャーと言われるような業務とその採用に関わる仕事をしています。 利用した技術一覧 HTML/CSS/JS みたいなことを書いてるとキリがないので、独断と偏見で区分けして適宜漉いています。特に利用する機会が多かったものは太字でピックアップ。 Frontend Language/Platform TypeScript JavaScr
今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約（と可能なら余談）だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"（>= 2.1.3みたいなやつ）の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正
社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
こんにちは、よしこです。 株式会社ナレッジワーク というスタートアップで、2020年4月の創業時から一人目のフロントエンドエンジニアをしています。 初期に考えて組み上げたスタックで1年半ほど開発・運用してみて、なかなか快適に日々開発ができているので 新規開発のプロダクト立ち上げ時にどのようにフロントエンドを構築したのか？ 立ち上げから1年以上開発・運用を続けてきた今、それらの選択はどうだったのか？ を記事にして振り返り、公開したいなと思いました。 （プロダクトの内容はステルスで進めていてあまり対外的な発信ができないので、かわりに技術的なところはどんどんオープンにしていきたいなという気持ちがあります） いろいろな項目ごとに振り返りたいので、この記事は各項目を横断するindexとして項目ごとの概要を簡単に説明し、深堀りは項目ごとに追って詳細な記事を書いていく予定です！ 前提 プロダクトとしての
Gmailをメーラーとして使ってますが、メールを開くのがいまだに苦手です。 これをどうにかしようと、メールをもっと気軽に消せる方法はないかなーと思ってInbox Zeroを思い出したのでやり始めました。 次の記事や動画を参考にしています。 Inbox Zero and the Inbox Zero Method — everything you need to know 【15分で完了】1度設定したら戻れない、受信トレイ0生活 | おかんの給湯室 My Complete Inbox Zero Workflow (in 2022)! - YouTube 基本的には、この動画を参考にして設定しました。 Inbox Zeroの設定方法 細かい設定は参考にした動画や記事の方に任せます。 Gmailの”設定”でやること 詳細タブ [ ] 自動表示 を有効化(アーカイブしたときに次のメールを自動で開く
週末に自分がよく使っている技術をまとめたら反応が良かったので、テンプレートを作りました。 なにかWebサービスを作るときに、自分はこれらのライブラリを基本的には入れます。 ベースはcreate-next-appとなりますが、そこで生成された状態だと認証もDBも何もありません。 しかし、サービスを作るにあたって必要なケースがほとんどです。 このテンプレートには特定のライブラリを入れると毎回書かないといけない項目等を事前に作っておき、 開発に集中できる仕組みを作るのがゴールとなります。また、例を示しつつ削除するコード量を最小限に抑えます。 主にNext.js固有のハマるポイントや環境構築などめんどくさいけど毎回書いている点をカバーします。 linterと関連があるVSCode, pre-commit等の設定NextAuthに指定されたDB Schemaの作成やAPI routeの設置開発、テス
Retty インフラチームの幸田です。 6月に実施したマイクロサービス強化月間で公開した記事では、マイクロサービス環境を Terraform を利用して刷新した話を書きました。 engineer.retty.me この記事では前回と重複する箇所もありますが、Terraform の CI/CD にフォーカスした内容を書こうと思います。 CI を整備するにあたって意識したこと 「誰でも」かつ「安全に」利用できるように CI 上ですべての作業を完結させる Pull Request によるレビュー環境の整備 バージョンアップ作業の完全自動化 Terraform のディレクトリ構成について リポジトリの運用フロー Terraform によるリソースの追加、変更、削除 tfmigrate によるステートファイルの操作 CI で実行される job について Pull Request をオープンした時 P
エンジニア全員が Terraform を安心・安全に触れるような仕組みを整えています - VisasQ Dev Blog
はじめに こんにちは！DPE（Developer Productivity Engineering）チームの高畑です。 ちょっと前に iPhone 15 Pro に変えてようやく USB-C ケーブルに統一できる！と思っていたら、手元にある Magic Trackpad が Lightning ケーブルでしょんぼりしました。 さて今回は、ビザスクのインフラ周りで利用している Terraform をエンジニア全員が安心・安全に利用できる仕組みづくりを行なっている話をしていきます！ これまで ビザスクではインフラの構築・運用に Terraform を利用しており、依頼ベースで DPE のメンバーが Terraform の修正を行なってレビュー＆リリースをしていました。 開発メンバーから Terraform の PR をあげてもらうこともありますが、plan / apply の権限を持っていない
このエントリは、PHP Advent Calendar 2021 の20日目のエントリです。19日目は @takoba さんによる PHPプロジェクトのComposerパッケージをRenovateで定期アップデートする でした。 SQLインジェクションやクロスサイトスクリプティング(XSS)の対策を行う際には「エスケープ処理」をしましょうと言われますが、その割にPHP以外の言語ではあまりエスケープ処理の関数が用意されていなかったりします。それに比べてPHPはエスケープ処理の関数が非常に豊富です。これだけ見ても、PHPはなんてセキュアなんだ! と早とちりする人がいるかもしれませんが、しかし、他言語でエスケープ処理関数があまりないのはちゃんと理由があると思うのです。 本稿では、PHPのエスケープ処理用の関数を紹介しながら、その利用目的と、その関数を使わないで済ませる方法を説明します。 SQL用
前回のエントリで作った Docker イメージ motemen/datastore-emulator は、google/cloud-sdk をベースにしているが、このベースイメージがけっこうな頻度で更新される。とうぜん自分はその追従に手を煩わせる気はなくて、全部自動でやってほしい。 やりたかったこと google/cloud-sdk:x.y.z がリリースされたら、 リポジトリ中の ./Dockerfile と ./alpine/Dockerfile の FROM を google/cloud-sdk:x.y.z(-alpine) に更新し、 x.y.z タグを打って git push することで、 Docker Hub に x.y.z(-alpine) タグとしてリリースする これを自動かつ無料で実現したい。 採用しなかった案: 自分でなんか作る はじめは適当な GitHub Actio
個人的にTypeScriptプロジェクトで使って良かったと感じたライブラリやツール、役立ったノウハウ・情報源へのリンクをまとめていきます。随時更新します。 記事更新時に通知を受け取りたい方はこの投稿を「ストック」してください。 追加された内容は更新履歴をご覧ください。 書籍 『実践TypeScript ~BFFとNext.js&Nuxt.jsの型定義~』 - JavaScriptからTypeScriptに来た人が読むと、JSとTSの差分を学ぶことができる本。 『JavaScript Primer: ECMAScript 2019時代のJavaScript入門書』 - すでにプログラミング経験がある人が読むとJavaScriptの文法や機能を中心に学ぶことができる本。TypeScriptを書くにもJavaScriptの知識が必要不可欠なので、雰囲気でJSを書いてきた人やちゃんとおさらいしたい
「次の職場が Ruby なんだけど」と読み書きそろばんを聞かれたのと、大阪Ruby会議03、大江戸Ruby会議10、Kaigi on Rails 2023 と Ruby/Rails 関係のイベントに続けて参加して、作者の皆さまと会ったので。 「読める」になるために 言語仕様は何らかの本 1 冊の冒頭の方を読めば雰囲気は掴めるだろう。 Ginza Rails27 igaiga - Speaker Deck 著書や技術顧問、健康診断レポート でお馴染みの @igaiga555 さんの作った表で、難易度別にまとまっている。 たのしいRuby か、プロを目指す人のためのRuby入門 が定番かなぁ。 できることを知る るりま (Ruby リファレンスマニュアル) の Enumerable、String Rails Guides の Active Support Core Extensions 日本語
最初に作ったのがCIAnalyzerです。なるべくツール自体の運用の手間がかからないように常駐サーバー無し、データの保存先と可視化はマネージドサービスを使う前提で設計しました。具体的にはデータの保存先をBigQueryとすることによって自前でDBを管理する必要をなくし、webhookを受けるのではなくcronで定期的にAPIを叩くことで常駐サーバーを不要にし、データの可視化はBigQueryと簡単に連携できてマネージドサービスであるLooker Studioを使用する前提としました。 CIAnalyzerのアーキテクチャ CIAnalyzerを作ったきっかけはAzure Pipelineの分析機能に感銘を受けたことで、それと同等の分析を当時自分が業務とプライベートで使用していたJenkins, CircleCI, Bitrise, GitHub Actionsでも可能にしたいと思って開発を
先日初めて真面目に自分のコードを OSS として公開する機会があり、色々試行錯誤したのでまとめます。 何を公開した？ Vue Word Highlighter という Vue.js のコンポーネントライブラリを公開しました。 機能はとても単純で、文字列と検索クエリを渡すと検索クエリに合致した文字をハイライトする（<mark>タグ又は任意のタグ囲む）というものです。 自分なりに良い感じに使えるコンポーネントが出来たので、せっかくならば多くの人に使ってもらいたいと思い以下で記載する諸々をやってみました。 公開までにやってみたこと 🗒 READMEをちゃんと書く OSS の顔と言ったら README なので、ひと目でちゃんとしてそうな OSS 感を出すために README は整備しました。 ロゴを作る Google Font で良さそうな書体を探し一部をハイライトしただけの単純なものですが、ラ
こんにちは。ソーシャル経済メディア「NewsPicks」NewsPicks Stage.事業のエンジニアをしています、林です。 業務では Next.js / Rust / Go などを用いて、経済・ビジネス情報に特化した動画配信サービスであるNewsPicks Stage.の開発・運用を行っています。 はじめに 突然ですが、皆さんは自身のソフトウェアのライブラリアップデートは行えていますか？ 皆さんはどのようにライブラリアップデートを行なっていますか？ 新機能を試したくて？ npm iで失敗してから頑張る？ Renovate / dependabot が自動Mergeされる環境？ もしくは対応担当が特定の日にまとめてMergeする運用？ しかし多くの開発者は、アップデートに対して「うまくいっている」と言えないのではないでしょうか？自身も様々なプロダクトを開発してきた経験上、日々の中ではどう
2020-10-20フロントエンド開発環境の継続的なリファクタリングこんにちは、第二開発グループエンジニアの西村です。主にCLINICSの開発を担当しています。 はじめにCLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーションプロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラ
Terraform の CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform の CI を AWS CodeBuild (以下 CodeBuild) から GitHub Actions + tfaction に移行した話を紹介します。 これまでの Terraform Workflow (CodeBuild) 弊プロダクトの Terraform の CI に関しては過去の記事でも何度か紹介していますが、 元々 CodeBuild 上で CI を実行していました。 かつては CircleCI 上で実行していましたが、 CodeBuild に移行しました。 blog.studysapuri.jp CodeBuild に移行した理由は大きく 2 つありました。 Security 永続的な Access Key を発行することなく AWS のリソースを管理できる GCP に関しても Wor
Renovate の大量の Pull Request を処理する技術 - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Monorepo に対する Renovate の大量の Pull Request を処理するための技術について紹介します。 背景 過去ブログで何度か紹介しているように、弊プロダクトでは Terraform の Monorepo を管理しています。 先日、 CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました。 blog.studysapuri.jp working directory (state) の数は 400 近くあり、 working directory ごとに以下のような tool のバージョンを管理しています。 Terraform Terraform Provider tflint tflint plugin tfsec etc これ
この記事は FastDOCTOR After Advent Calendar 27日の記事です。 はじめに ファストドクター株式会社でテックリードをしている shirauix と申します。 弊社では、ある Next.js アプリケーションを別会社のパートナーさんに外注することによって初期開発を行いました。ある時点からこのシステムを内製化することになったのですが、それにあたって多くの課題を解決する必要がありました。 この記事では、外注と内製のそれぞれのメリット・デメリットや、内製に切り替える際にどんな苦労があったのかについての赤裸々な事例をご紹介します。 対象となる読者 外注で初期開発したシステムを内製に切り替えてメンテナンスしようとしているエンジニアの方 新しくシステムを開発したいが、外注と内製のどちらを選択すべきか悩んでいる方 外注と内製の違い 外注するか内製するかはあくまで手段の話であ
GitHub の merge queue で 「マージ待ち」を解消した話 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
こんにちは。 株式会社アカツキゲームスで ATLAS というチームに所属してゲーム内通貨管理基盤の開発及び運用を行っています、なかひこくん (@takanakahiko) です。 最近バイクを買いました。 私の担当するゲーム内通貨管理基盤の開発現場では、「マージ待ち」なるものが存在しました。 今回は、その課題を GitHub の新機能である merge queue で解決した方法を紹介します。 この記事は 2023-07-20 時点での merge queue 及び GitHub Actions の仕様に則ったものです。 今後のアップデートによりこの記事の内容が正しくないものとなる可能性があります。 「マージ待ち」とは 私の担当するゲーム内通貨管理基盤の GitHub リポジトリでは PR のマージ後に走る、同時に実施できない 15 分程度の E2E test が存在しました。 すなわち
数えてみたら意外と数あったのでまとめます。 release-please Google謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。 github.com 例えば↓のようなワークフローを用意すれば、モジュールごとにGitHub Releaseを作成するためのPRを自動作成できます。 初期セットアップでJSONファイルを2つ作る必要があるのが若干面倒ですが、それさえ越えてしまえば考えることは少なさそうです。 # .github/workflows/release-please.
みなさんこんにちは、電通国際情報サービス（ISID）Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。 この記事では、Git を使った仕事のやり方（以降は Git ワークフローと記載）を設計する上での検討事項を説明します。 これによって、読者の皆さんがGitワークフローを適切に定義できるようになることを主たる目的としています。 また、筆者の能力不足によって記載しきれなかった考慮事項について、より深く Git を使いこなしている識者からの指摘を受ける機会を得ることを副次的な目的とします。 この記事には書かれていないものの、検討すべき事項について知見のある方はブログ記事を書いたり、Twitter等のSNSで指摘してくださるとありがたいです。 はじめに 基本的な考え方 Git ワークフロー設計における考慮事項 チームの人数 monorepoの検討 参考文献 プロジェクト管理ツールと
これは、k8sクラスタを個人で運用する際に行った構成要素の技術選定の記録である。 技術選定の理由を書くのも見るのも楽しい、という心情のもとにここに公開する。 前提知識 以前、こんなエントリを書いた。 bitcoinのfull nodeをAWSでなるべく安く運用してみる - でこてっくろぐ ねお 上記の通り、個人でbitcoinのfull nodeという、状態をバリバリもつサービスを、AWSでのコスト面で最安を狙って作り運用を行っていた。 しかしその後、Oracle Cloudで運用したほうが安くなることに気づいたため引っ越した。 Oracle CloudではARMのVMが4台無料で使えて複数台構成が組め、AWSやGCP同様k8sのマネージドサービスもあり、また仕事でk8sを扱う部署に異動したのもあり、勉強のためk8sクラスタ上で運用することにした。 構成要素 以下の構成要素を選択している。
週に一度まとめて更新のようなパターンだと、体調が悪いときなどにその週はスキップされ、また次の週も更新しようとして偶然タイミングが合わなかった場合などに、1ヶ月更新が止まるみたいな状態は起きやすいです。 1ヶ月更新を止めてしまうと、そこで更新する習慣が失われて、この書籍でいう逆戻りが起きるのかなと思っています。 そのため、JSer.infoではタスクを細分化して進められる時にやっていけるような形を作っています。 ライブラリのメンテナンスのリズムをツール化する JavaScript周りは顕著ですが、ライブラリが細かく分かれていることが多いため、リポジトリの数も多いです。 そのため、リポジトリのCI設定や依存ライブラリのアップデートなどをメンテナンスするだけで無限の時間がかかります。 このメンテナンス作業を手動で毎回やるととても疲れるので、自分の場合はツール化していることが多いです。 作ったり、
「プロダクト間共通の React コンポーネントライブラリ」がどうなったか、という話 - SmartHR Tech Blog
こんにちは！ フロントエンドエンジニアの @diescake です！ 1 年程前に @nabeliwo よりこんな記事を公開しています。 tech.smarthr.jp 一言で要約してしまうと、SmartHR の各種プロダクトで一貫したユーザー体験を提供するために、SmartHR UI という React コンポーネントライブラリを実装し始めたよ！ しかも OSS として公開してるよ！ という話でございました。 github.com 本記事では、それから 1 年弱たった今 SmartHR UI がどうなっているか、という話をしつつ、現在の SmartHR UI の運用・開発体制について話をしてみようと思います。 SmartHR UI は成長しているよ！ 2019/08/01 2020/05/21 バージョン v3.9.2 v8.2.0 コンポーネント数1 30 66 ソースコード規模2 3
TLDR 開発体験が良くなると CI のコストも減る 不必要なジョブ実行を減らし、割れ窓を直すことから始めると良い Self-hosted runners ではクラウドコスト最適化の一般的なプラクティスも併用する GitHub Actions のコスト構造 GitHub-hosted runners GitHub が提供するインフラを利用する。一般的なクラウドより高めの料金設定になっている 1分単位で課金される。ジョブの実行時間が数秒間でも1分間で課金されるので注意 Public repository は無料、Private repository は従量課金になっている Organization 内で利用料金が合算されて翌月請求される。Organization Owner なら請求レポート (CSV) をダウンロードできる Self-hosted runners GitHub では課金され
バックエンドエンジニアのクラシマです。 2021/08/25(水)に、本番サーバのPHPを7.4.21 -> 7.4.22にバージョンアップしました。 renovateでプルリクエストが作られるので、追っかけるだけです。 tech.torana.co.jp AMIは前日に作ってあり、当日はLaunchTemplateの向き先を変更するためにterraform applyして、AutoScalingGroupからインスタンスの更新をするだけ。 や～便利になったなぁ、なんて作業してたらSlackが大騒ぎに・・・ 大惨事の一コマ 切り戻し！ 急いで切り戻し！と判断したのは良いものの、まさかPHPのバージョンアップ起因だとはその時は思いもよらず。 当日deployしたアプリケーションや、Aurora MySQLの設定変更などを順次戻していきますが、一向に回復せず。 stg環境でも動作が同じだったの
先日の ua-parse-js のハイジャックの件 を受けて、業務の中で毎日動かしている On-premise Renovate の cron を土日祝に停止させたいという話が上がった。 業務の合間に書く時間がちょっと捻出できそうになかったこと、加えて汎用的なコードということもあり、プライベートでも使えそうだったので一般化した範囲でコードを書いてしまって、業務で社内用に調整する形で決着させたので、せっかくなので共有しておく。 社内が基本的に CircleCI なので特化したものと、一般的に使えるものでバリエーションごとに2つのパターンを用意した。 祝日に停止させるアプローチ ひとまず今回は内製の Bot の運用のため、以下のような特徴があった。 土日の設定自体は cron で曜日指定ができるため祝日にフォーカスして良い 厳密性を重視しない ミッションクリティカルな領域の話ではない 以上を考
ここのことです*1。 真ん中のカラムがコードの表示 (開発者ツールで見ると textarea にコードが入っている 目次 目次 シンタックスハイライトはどうしているのか？ 上に表示されている div ならその文字もマウスカーソルで選択できるはずでは？ なぜこうしたのか？ 困ることはないのか？ たしかこないだまでは普通に div ？ で、テキストをマウスカーソルでドラッグアンドドロップで選択したりするような感じだったはずだけど、最近？になって、選択できる部分は textarea になっていて、点滅するカーソルが出るので、キーボードでエディタのように移動・選択することができる (もちろん編集はできない *2 )。 選択範囲の一番右に白く点滅するカーソルが登場している シンタックスハイライトはどうしているのか？ textarea は部分的に色を変えるとかはできないはずだし、スタイルの様子を見ると
Rails 6+Webpacker開発環境をJS強者ががっつりセットアップしてみた（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Rails 6: the missing developer setup guide - DEV Community 💻💻 原文公開日: 2019/11/19（最終更新: 2019/12/17） 著者: Vincent Voyer 日本語タイトルは内容に即したものにしました。画像はすべて元記事からの引用です。 原文の目次は省略しました。原文の乱れは訳文で修正してあります。以下のRailsガイドもどうぞ。 Webpacker の概要 - Railsガイド 更新履歴: 2019/11/28: 初版公開 2021/05/06: 更新 👋皆さんこんにちは。本記事では私がRubyやRuby on Railsを学んだ一環として、ドキュメントに書かれていないことを全部盛りしました。RubyやRailsのエコシステムは初めてなので、皆さまか
日本国内における新型コロナウイルスの感染拡大にともない、東京都が新型コロナウイルス感染症対策サイトを公開しています。 ここでは、このウェブサイトで使われている技術について見ていきます。 GitHub このウェブサイトのソースコードは、GitHub上で公開されています（！） GitHubは、言わずと知れたソースコードホスティングサービスです（設計図共有サイトではありません）。1 イシューやプルリクエストも受け付けており、既に多くの人がコントリビューターとなっています。2 GitHub Actions GitHub Actionsは、GitHubが提供しているCI/CDツールです。 このプロジェクトでは、ビルドやデプロイ、ソースコードの構文チェックなどがGitHub Actionsでおこなわれています。3 Renovate ライブラリの更新は、Renovateによって自動化されています。4 N
AWS知見共有会でTerraformのCI/CDパイプラインのセキュリティ等について発表してきました + GitHub新機能Push rulesについて - LayerX エンジニアブログ
先日2024/04/16にタイミーさんのオフィスで開催された、AWS知見共有会というイベントで発表してきました。この会のテーマは「運用のスケーラビリティとセキュリティ」ということで、私は「コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える」というタイトルで発表してきています。 イベントの動画もあります。 私の発表は 1:43 ぐらいからです。 この発表については資料と動画を見ていただければ！という感じで特に付け加えることもなかったのですが、イベントの開催後にGitHubから発表された新機能Push rulesがとても便利で、新たなベストプラクティスとなるインパクトがあると思ったので、この記事で紹介します。 Push rulesとは つい昨日発表された機能で、現在はpublic betaという状態です。なので、仕様変更と
社内でOSSへの貢献をもっと奨励していきたいねと話していて, そもそも普段どれくらい貢献できているか知りたくなった. 以前, 自分のポートフォリオに貢献しているOSSのリストを出すのをやっていて, ちょっと改造したら組織内のメンバー全員のものもすぐに出せそうだったのでやってみた. (というのをずっと前にやっていたけど宣伝するのを忘れていた.) モチベーション OSSに(趣味にせよ仕事の一部にせよ)貢献している同僚はけっこういるけど, 「こういうのやったよ!」と宣伝してくれない限りあんまりどういう活動をしているのか知らない. 「今月はこれだけの人たちがOSS貢献してました」というのを社内の全エンジニアで眺めてわいわい盛り上がれると, 自分も何かやってみようという気になるだろうし, 「これに手をつけてみたいけど, どこから手をつけたらいいかわからないから詳しそうなあの人に聞いてみよう」となって
ぼくのかんがえたNext.jsの構成
はじめに 普段開発している Next.js プロジェクトの構成がなかなかいけてるんじゃないかということで、その構成を公開しちゃおうというお話。ほんとはタイトルをぼくがかんがえたさいきょうのNext.jsの構成にしたかったけどひよりました (今回の記事を作るにあたり改めて一から Next.js のリポジトリ作ったら husky のバージョン上がってたり、eslint-config-prettier の v8 系になって config の書き方ちょっと変わってたり、時代は移り変わるのです・・) 意外と手順書いていくと長くなったので一部coming soonになっているものは確固たる意思を持って、随時追記します 更新履歴 2021/04/01 css modules が storybook で上手く呼べてなかったので修正、あと storybook のバージョンアップ 2021/03/31 なんと
Perlの依存モジュールのアップデートを自動化するためのCLIツールを作った。GitHub Actions上で動かしてPull Requestも送れる - hitode909の日記
近年のソフトウェア開発では、RenovateやDependabotといった依存関係更新のためのツールが普及していて、ツールの支援を借りながら依存ライブラリを更新していく開発フローが広まってきている。 これらのツールは、package.jsonで管理されているライブラリだったり、Dockerfileで指定しているイメージだったりを自動的に最新版に更新してPull Requestを出してくれるので、人間は内容を確認してマージボタンを押すか、変なところがあったら手直ししてからマージしていくだけでよい。 はてなでの開発フローでも使い倒していて、先月くらいにも、社内で共有して使ってる設定を公開したりしていた。今ではRenovateのない暮らしに戻ることは考えられないくらいに広まっている。 developer.hatenastaff.com 普段、仕事ではPerlやTypeScriptを書いていて、T
このエントリーは pyspa Advent Calendar 2019 の 11 日目の記事です。昨日は @chezou の「Vein の iOS ショートカット複数 URL 対応しました」でした。 はじめに#TypeScript は大変に素晴らしい言語で、僕の手によくなじむ。そのせいか最近はめっきり TypeScript ばかり書いている。 今回のエントリでは、僕がこの一年くらいの間に磨いた TypeScript のテンプレートプロジェクトについて説明する。かなり何度も使って必要十分なものだけを含めるようにしている。 しかし、僕の知識の偏りがそのままになっているので、万人に合うというわけではないだろう。 とはいえ、開発環境の初期構築はかなり面倒な作業なので参考にして貰えれば嬉しい。 細かい説明なんかよりもコードを見た方が早いってハードコアな方は、こちらへどうぞ。 taichi/ts-te
こんにちは、koidです。 この記事は Gunosy Advent Calendar 2021 - Adventar の25日目の記事です。 昨日の記事は aitaさんの EKSにJupyterHubを構築した - Gunosy Tech Blog でした。 ドキュメントの更新って面倒だし忘れがち ドキュメントのメンテナンスを自動化しよう コードからドキュメントを自動生成する ツールの利用によるドキュメント生成 CIによるドキュメント生成の自動化 状態からドキュメントを自動生成する ツールの利用によるドキュメント生成 CIによるドキュメント生成の自動化 まとめ ドキュメントの更新って面倒だし忘れがち 本題です。 みなさん、Pull Requestのレビュー時に、 ドキュメント・READMEも修正お願いします！ こういったコメントをした/された経験ってありませんか？ コメントをする側としても
現在WantedlyではNode.jsのパッケージ管理にyarn v1を使っています。現在私は開発者体験の改善を目指してyarn v2への移行を検討しているのですが、その過程でyarn v2が誤解されがちだと感じるようになりました。そこで社内への情報提供も兼ねて、いくつか誤解されがちだと思われる点を紹介したいと思います。 (わかりやすさのためにyarn v2と呼んでいますが、 yarn v3以降も含みます。これらはメジャーバージョンアップではあるもののyarn v1→v2のようにアーキテクチャが刷新されるわけではないからです) ポイント1: yarnをv2にするのにPnPは必須ではないyarn PnPはyarn v2の目玉機能で、パッケージをnode_modules以下に展開せずに仮想化してロードできるようにするというものです。node_modulesの展開作業が不要になるほか、依存関係の
はじめてのプロジェクトマネジメントでやりたい放題した結果
株式会社プラハは2022年、株式会社アガルートによるM&Aで子会社となりました。 この変化の一環として、アガルート社長自らがプロダクトオーナーのひとりとして参加する新規プロダクト開発が始まりました。プロダクトの開発はプラハの私たちが担当し、私も「開発チームのリーダー」としてそのチームに加わることになりました。 私はこれまで開発メンバーとしての経験しかありませんでしたが、エクストリームプログラミングとかレガシーコードからの脱却とかめっちゃ好きで、本で学んだプラクティスをリーダーとして実践できる機会が与えられて最高にハッピーでした。しかも、プロダクトオーナーの一人として参加するアガルート社長はこれまで伝統的な開発手法しか経験したことがないとのことで、新たな開発の進め方を経験してもらう絶好の機会でもありました。 やったこと 「欲しい機能一覧」を受け取ったが、いったん白紙に戻した プロジェクトが始
N 予備校に Visual Regression Testing を導入した話 + tips - ドワンゴ教育サービス開発者ブログ
こんにちは。N 予備校 Web フロントエンド開発チームの berlysia です。 N 予備校の Web フロントエンド開発に、 Storycap + reg-suit による Visual Regression Testing を導入しました。設定の工夫から、設定中や運用してしばらくの間に実際に発生したハマりどころを挙げ、簡単に注意点や対処例を紹介します。 背景 N予備校について N 予備校はドワンゴが提供するオンライン学習サービスです。大学受験対策、プログラミング、Webデザイン、機械学習など多様なコースがあります。オンラインでの利用に合わせた教材や、講師が生放送で行う授業、受講者同士でも質問し教えあえるフォーラムを備えています。 www.nnn.ed.nico 周辺状況 N 予備校の Web フロントエンド開発とそれを取り巻く状況には、次のような特徴があります。 React による
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Semantic Versioningの闇 - knqyf263's blog
2020年に立ち上げたWebフロントエンド構成の振り返り
メールの受信トレイを空にするInbox Zeroを始めた
Webサービスを作るときのテンプレートを作った - hiroppy's site
Retty の Terraform CI/CD 解体新書 - Retty Tech Blog
PHPにはエスケープ関数が何種類もあるけど、できればエスケープしない方法が良い理由
Dockerfile をベースイメージの更新に自動で追従させる - 詩と創作・思索のひろば
厳選TypeScript 〜おすすめしたいライブラリ、ツール、ノウハウ、情報源のリンク集〜 - Qiita
Ruby/Rails の勉強に何読んだらいいかと聞かれたとき - id:onk のはてなブログ
GitHub Actionsのワークフローを可視化するactions-timelineを作った
真面目にOSSを公開する際にやってみたこと・意識したこと
ソフトウェアエンジニアのライブラリアップデートの向き合い方 - Uzabase for Engineers
フロントエンド開発環境の継続的なリファクタリング | MEDLEY Developer Portal
外注で初期開発したシステムを内製化するためにやったこと
2022年に試した開発ワークフロー関係の機能やツール - Kengo's blog
Gitワークフロー設計について - 電通総研 テックブログ
個人運用k8sクラスタの構成要素の技術選定 - でこてっくろぐ ねお
Maintainer Month: オープンソースをメンテナンスするコツ
GitHub Actions のコスト戦略 - GeekFactory
PHPのパッチバージョンを上げたらひどい目にあった話 - TORANA TECH BLOG
CircleCI や GitHub Actions の cron を祝日だけ停止させたい
GitHubのコード表示部分はtextareaとbefore疑似要素でできている - hogashi.*
東京都 新型コロナウイルス感染症対策サイトで使われている技術 - Qiita
個人/組織のOSS貢献を可視化する - 貳佰伍拾陸夜日記
TypeScriptによるアプリケーションの開発環境 | さにあらず
面倒なドキュメント生成はCIにやらせよう - Gunosy Tech Blog
yarn v2にまつわる誤解 | Wantedly Engineer Blog