TypeScript による GraphQL バックエンド開発10/14 の Tech Play での発表資料です https://techplay.jp/event/873259
【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました！ - ブロッコリーのブログ
目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
リリースノート管理術
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
Goのリリースプロセスとブランチ戦略 - YAMAGUCHI::weblog
はじめに こんにちは！Google Cloudでオブザーバビリティの担当をしているものです。CVE-2021-44228のおかげでバタバタしていますがみなさんはお元気ですか？ このエントリーはpyspa Advent Calendar 2021の15日目の記事です。昨日は @moriyoshit さんの「Goのロギングライブラリ 2021年冬」でした。めちゃめちゃ調べてあって良い記事でした。Goでログライブラリの選定をする際にはこちらをまず読むと良さそうです。 2021.12.21 追記: 穴が空いていたのでGo Advent Calendar 2021 その1の14日目の記事にもしました。 さて、今日は本当は「Goならわかる確定申告第三表」という記事を書こうと思ったのですが、まだ確定申告の時期ではないのでそれは辞めにします。そのかわり、今日はGo 1.18がめでたくベータ版リリースとなっ
Common Anti-Patterns in Go Web Applications
Miłosz Smółka Principal Backend Engineer at GetHarley. Co-founder of Three Dots Labs. Creator of Watermill. At one point in my career, I was no longer excited about the software I was building. My favorite part of the job were low-level details and complex algorithms. After switching to user-facing applications, they were mostly gone. It seemed programming was about moving data from one place to a
Under Deconstruction: The State of Shopify’s Monolith
Opens in a new windowOpens an external siteOpens an external site in a new window Ruby on Rails is a great framework for rapidly building beautiful web applications that users and developers love. But if an application is successful, there’s usually continued investment, resulting in additional features and increased overall system complexity. Shopify’s core monolith has over 2.8 million lines of
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
ミドルウェアのソースコードリーディングのすすめ - freee Developers Hub
この記事は freee Developers Advent Calendar 2020 の 21 日目です。 プロダクト基盤本部で本部長をしています浅羽と申します。プロダクト基盤は文字通りプロダクトの基盤を作っており、SRE、アカウントアグリゲーション基盤、セキュリティ、アプリケーションの基盤、品質、Eng企画と多岐にわたるチームになっています。普段は組織運営であったり困ったことに相談乗ったり、暇を見つけてコード書いたりしています。よろしくおねがいします！ freeeではサービスの安定稼働を重視しており、SREではデプロイの高速化やカナリアリリースなどのような「仮にまずいリリースがでてもすぐに引っ込める」仕組みの開発をしています。もちろんサービス障害が発生しないようにQAチーム中心に対策していますが、失敗はある前提の元でいかにリカバリを素早くできるかも大切にしています。これはこれでどこかで
なぜメルペイQAはDevOpsに取り組むのか？ | メルカリエンジニアリング
Merpay Advent Calendar 2020 の18日目は、QAエンジニアチームの @miisan がお送りします。 昨年のMerpay Advent Calendar 2019で 「メルペイQAの今と未来と私の日常」 というTech Blogを書かせていただいてから約1年たちました。メルペイではこの1年で、さらに多くの機能をスピード感を持って、お客さまに届けてきました。 今回は、メルペイQAがDevOpsサイクルの中で、普段どのような取り組みを行い、プロダクトを支えているかについて紹介したいと思います。 最初に結論をお伝えしてしまいます。ひとことで表すと、「お客さまにより早く、より確実に、より良いサービスを継続的に届けるため」です。 DevOpsの良いところ 協力体制：役割に関係なく、サービスの価値向上に目的意識が向き、プロダクト全体に対して活動できる。 信頼性向上：責任範囲を
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
Command Line Interface Guidelines
Contents Command Line Interface Guidelines An open-source guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day. Authors Aanand Prasad Engineer at Squarespace, co-creator of Docker Compose. @aanandprasad Ben Firshman Co-creator Replicate, co-creator of Docker Compose. @bfirsh Carl Tashian Offroad Engineer at Smallstep, first e
Making Terraform Provider Development More Accessible
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
15分スプリントの具体的な進め方について動画で話した #15min_sprint - うさぎ組
15分スプリントの具体的な実践例をYoutubeにあげました。今後なにかの参考になれば幸いです。 www.youtube.com リンク先でチャプター毎にわかれているので、みてみたいところだけかいつまんでみるか、2倍速くらいで見るのをオススメします。 Twitterで実況してくれていた方達のツイートまとめはこちらになります。 togetter.com 動画内で利用していたスライドはこちらになります。 こちらの放送をしたのは、もともとは次のイベントとしてやっていました。 15分スプリントを2年間やったけど質問ある? - connpass やってみてどうだったか この放送をやる経緯自体は 15分スプリントを2年間やったけど質問ある? #15min_sprint at 2020-10-14 21:30 - うさぎ組 にかいたとおりで、おもいのほかたくさんの人にご参加いただけてうれしかったです。
Zero Touch Productionとは何か
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization at Google is working to build upon the concept of least
社内PlatformチームのProduct Management
現職においてPlatform チーム（社内基盤チーム）として働き始めて2年近くがたった．このチームにおいて自分はTech Leadをメインに努めてきたが，同時にPlatformの「どのような機能を」「どのような優先度で」作るか? を決めるProduct Manager的な役割も果たしてきた（ちなみにTech Leadに関してはメルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ で少し話した）．これは何度も失敗しながら悪戦苦闘しつつやってきたが自分たちなりのフレームワークをつくり実際に回すことができている． 未だに試行錯誤しているのでここで書いていることが正解だとは思っていないが，今後同じようにPlatformチーム的なことを始めるひとに向けて現状自分たちがどのようにやっているのかについて簡単にまとめておく（他の会社がどのようにやってるのかも聞きたいのでもし同じような
Jasper v1.0.0をリリースしました🚀（GitHub用のissueリーダー） - maru source
以前から開発しているJasper(GitHub用のissueリーダー)のv1.0.0をついに今日リース！やったー！前バージョンから作り直しレベルでコードを書き換えたので、かなり大変だったなぁ。でもそのおかげですごく良いものにできた！ jasperapp.io というわけで、こんにちは丸山@h13i32maruです。今日はJasper v1.0.0のリリース記事なのですが、GitHubを普段使ってる人にはJasperも是非使ってみてほしいので、少ししっかりめに書いてみました。よろしくおねがいします🙋 🕵️ Jasperとは（初見の方向け） JasperはGitHubのissueを柔軟に見ることができるツールです。例えば「nodejs/nodeのbugラベルがついたissue」「自分が作成したpull request」などの条件でissueを見たり通知を受け取れます。この条件はJasper
realize + dockerでGolangのホットリロード付き開発環境を構築する
今回は、gin + gqlgen + gormなGoプロジェクトのホットリロード付き開発環境を構築します。 環境 Go 1.12.6 プロジェクトの構造 . ├── db │ └── db.go ├── models │ ├── model_a.go │ └── ... ├── schema │ ├── schema.graphql │ └── ... ├── server │ └── server.go ├── docker-compose.yml ├── go.mod ├── go.sum ├── gqlgen.yml └── ... 使用するホットリロードツール realizeというツールを使用します。 他にもfreshなどのホットリロードツールがありますが、realizeの方が設定が細かくできるため、realizeを選択しました。 実は最初、freshで試していたのですが、Go M
2020年、オンラインサービスやWebアプリの開発を独学で勉強したい人に役立つ練習プロジェクトのまとめ
Webアプリやスマホアプリ、オンラインショップ、オンラインサービスなど、Web開発における一通りの需要に応えられるような知識・スキルを練習するのに役立つプロジェクトを紹介します。 8つのプロジェクトにはそれぞれ異なる課題が設定されており、開発者が行う実際のタスクが反映されています。 バックエンドが中心ですが、フロントエンドのCSSのテクニックなども磨けます。 8 Projects with modern designs to become a Full-stack Master 2020 by Thu Nghiem 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに Image Uploader My Unsplash CatWiki Authentication App Shoppingify Chat Group Tw
開発体験を変える! Chrome DevTools Tips 7選 - Qiita
最近Chrome DevToolsについて調べていて発見した便利機能を紹介します。 誰もが使える最高便利な開発マシンChrome DevToolsを使いこなして開発体験を変えましょう！ 1. $0で選択中のDOM要素の取得 特定の要素に何かしたいという時には、要素のIDやclassを確認してConsoleでdocument.querySelector("#xxx")で取得するというのが一般的だと思います。実はそれはカーソル選択と$0で代替できます。 Classや、IDがついていない特定のDOMを取得したい時とかにも使えるので地味に便利です。 手順 カーソルで取得したい要素を選ぶ Consoleタブで$0を入力 最近知ったChrome DevToolsの便利機能① $0 での選択中のDOM要素取得 Elementsタブで選択状態のDOM要素は、Console上で $0 を入力することで取得で
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
