並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 18 件 / 18件

新着順 人気順

Slackの検索結果1 - 18 件 / 18件

  • 大公開!バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG

    こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab

      大公開!バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG
    • 【2024年版】平成元年発売のテトリスが 世界中で大変なことになっている|slappin' Notes

      はじめに2023年10月、毎年恒例となった賞金制のテトリスの世界大会である「CLASSIC TETRIS WORLD CHAMPIONSHIP」が開催されました。 Super Killscreen導入後初の世界大会となった今回、フルセットまでもつれ込んだ白熱の決勝戦はKillscreen中にテトリスも飛び交う激しい競り合いが繰り広げられ、歴戦の猛者のSidnev氏を破り、前回準優勝のFractal氏が悲願の初優勝を遂げました。 皆様お久しぶりです。今回もNESテトリス世界大会の記事を執筆することとなりました。前回から1年半ぶりとなります。 2023年はあまり書くこともなさそうだな…と思っていましたが、そんなことはありませんでした。本当に大きな出来事が何度も、立て続けに起きてしまったため、この記事の公開が12月末から今年の6月になってしまったほどです。この記事も相当長くなることをお伝えしてお

        【2024年版】平成元年発売のテトリスが 世界中で大変なことになっている|slappin' Notes
      • 組織が記憶喪失になるのをどうすれば ~ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog

        何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていない――。 この記事では、そうした組織が記憶喪失になることにどう対処していけばよいか、NTT Comの技術顧問である吉羽龍太郎 (@ryuzee) さんにふらっと相談してみたら一瞬で突破口が見つかった&話に奥行きが出た話を共有します。 目次 目次 軽く自己紹介 事の発端 ryuzeeさんの油セール 実際に聞いてみた 新たなる概念:ADR ADRの実践:その1 何を書くか ADRの実践:その2 どこに書くか ADRの実践:その3 どう書くか 相談を受けて試しに書いてみたADR まとめ 軽く自己紹介 イノベーションセンターの小林 (@ppyv) です。 開発・検証用PCの開発に一段落つけた後、社会人学生としてたっぷり2年間学習を積んでいました。 いまはイノベーションセンターで働く社員のみなさんに、よりよ

          組織が記憶喪失になるのをどうすれば ~ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog
        • 網羅的なPRDやDesign Docを書かなくなった - kosui

          2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー

            網羅的なPRDやDesign Docを書かなくなった - kosui
          • 読み手につたわる文章 - テクニカルライティング - mochikoAsTech - BOOTH

            72ページ / A5サイズ / 電子版はPDF(フルカラー) / 紙の本は表紙カラー、本文モノクロ 技術書典16(2023年5月25日~6月9日)の新刊「読み手につたわる文章 - テクニカルライティング」です。 「PDF版」は名前のとおり、PDFをダウンロードできます。紙の本はついてこないので注意してください。 紙の本が欲しい方は「書籍版+PDF版」を購入してください。技術書典16の会期中は技術書典オンラインマーケット(送料無料)で購入できます。 https://techbookfest.org/product/3t8AGqtB65jsPtPhx6m5fr 「ダウンロードカード用」は、既に紙の書籍をお持ちの方向けのファイルです。紙の書籍を購入された方は、あとがきの後ろにダウンロード用のパスワードが記載されています。ダウンロード後、あとがきに記載されているパスワードでZIPファイルを解凍して

              読み手につたわる文章 - テクニカルライティング - mochikoAsTech - BOOTH
            • 社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU

              自分も含めて社内に詳しい人がいない領域のコードをいじることってあるよね。特に歴史の長いサービスだと当時触っていた人が誰もいないとか。仮にいたとしても1年くらい触ってないとほとんど忘れてしまって知らないのと同じような状態になっていたりする。 自分もそういうことが何度もあって、雑にスタンスややってることをまとめておこうと思う。 前提のスタンス 「これを倒したら俺がこの領域で一番詳しい最強になるんや」という気持ちを持ってる 詳しい人がいない状態で属人化とか気にしても仕方ない。まずは自分が詳しくなってから考えるでよい 自分用メモを作る キャッチアップしたことを書き残していく。ドキュメントじゃなくてSlackに垂れ流すでもいい 過去のドキュメント・やりとりを探す 全体像を把握できるドキュメントがないかを探すのを最初にやってる ここは近道はない。とにかく全部集めて全部読む気持ちで臨む Google D

                社内に詳しい人がいない領域のコードを触る時 - Konifar's ZATSU
              • Slackにプロジェクト管理機能が追加、「Slackリスト」正式リリース。タスクリストなどの作成と共有が可能に

                Slackにプロジェクト管理機能が追加、「Slackリスト」正式リリース。タスクリストなどの作成と共有が可能に セールスフォースはSlackの新機能として、プロジェクト管理機能を実現する「Slackリスト」の正式リリースを発表しました。 Introducing Slack lists Manage projects from start to finish, directly in Slack Take on tasks as a team, right where you’re already working Automate and triage requests with workflows in lists https://t.co/KDiiDiC9T6 pic.twitter.com/mAZbwaTBZ7 — Slack (@SlackHQ) June 6, 2024 Slack

                  Slackにプロジェクト管理機能が追加、「Slackリスト」正式リリース。タスクリストなどの作成と共有が可能に
                • バグ報告が来た時にデキるエンジニアの動き方

                  ❗❗問題発生❗❗ 作った機能のバグの発見報告が上がってきました。 この時点で何となく 「ヤバさ」 と 「あたり」 を自分の中でつけます 売上に響くやばい? 条件がある?全員? ボタンが押せないならクライアントだし、API飛んで成功してないならサーバ?届いてないならネットワークもあるか。 モバイル、Webどっち?両方? そもそもどこの環境?開発中のもの? 購入ボタンってどこのこと?特定のアイテム?それとも全部? 購入できてないってどういうこと?DBはどうなってる? まずは 👀 をつける これは 「見ていますよ」 という表現です。 もしくはリプライで 「見ます!」 と宣言するのも良いですね。 これにより投稿者は 「対応してくれるな」 と安心できます。 必要な情報をもらう 発生している環境 発生時間 アカウント名+ログイン情報 スクリーンショット・録画 この時点で試せることは色々試してもらいま

                    バグ報告が来た時にデキるエンジニアの動き方
                  • Your API Shouldn't Redirect HTTP to HTTPS

                    TL;DR: Instead of redirecting API calls from HTTP to HTTPS, make the failure visible. Either disable the HTTP interface altogether, or return a clear HTTP error response and revoke API keys sent over the unencrypted connection. Unfortunately, many well-known API providers don't currently do so. Updated 2024-05-24: Added the Google Bug Hunter Team response to the report that the VirusTotal API resp

                      Your API Shouldn't Redirect HTTP to HTTPS
                    • 入社2年目の悩みー仕事と競プロの両立についてー - 競プロ始めました-kaede2020-

                      0.はじめに 1.仕事のこと 2.体力が続かない 3.離れてみてわかったこと 4.仕事で何を目指すのか 5.競プロで何を目指すのか 6.そしてまた日常が始まる 7.終わりに 8.おまけ(その後のこと) 0.はじめに 昨年の2023年2月1日にAtCoder株式会社に入社しました。おとぎ話にたとえるならば、「めでたしめでたし」と全てが円満に終わって、その後は読者の想像にまかせることになるのだと思います。しかし、それがスタートであるというのは、ある程度の人生経験があればきっとわかるのではないかと思います。 前だけを見て走り続けた1年でした。 1年経ってやっと少しだけ周りの景色を見る余裕ができました。このまま後14年、定年までこの速度で走り続けられるのだろうか。そう思ったとき、私の足は前へ進まなくなってしまいました。そして立ち止まった私は、この1年間、四六時中AtCoderのことを考えていたのを

                        入社2年目の悩みー仕事と競プロの両立についてー - 競プロ始めました-kaede2020-
                      • ワールド・ワイド・ウェブの消失(八田真行) - エキスパート - Yahoo!ニュース

                        ピュー・リサーチ・センターの調査 日本のメディアでも報じられたのでご存じの方もいるかもしれないが、米国シンクタンクのピュー研究所が最近発表した報告が話題となっている。 この調査は定期的にウェブ全体をクロール(ダウンロード)し、収集したデータをオープンデータとして提供する非営利団体Common Crawlのデータに基づくものだが、報告によれば、膨大な量のウェブコンテンツが失われつつあるという。 例えば、2013年のクロール時に存在したウェブページのうち38パーセントはすでに消失した。該当ページが削除されたか、ウェブサイトごと消滅したためである。また、2013年から2023年の間に存在したウェブページの4分の1が、2023年10月現在アクセスできなくなっている。消えるのは古いページだけではなく、2023年のクロールで存在したページのうち8パーセントがすでに利用できなくなっているそうだ。 ソーシ

                          ワールド・ワイド・ウェブの消失(八田真行) - エキスパート - Yahoo!ニュース
                        • Findyの爆速開発を支えるテクニック - Findy Tech Blog

                          こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 早速ですが、これは弊社のとあるチームの1ヶ月のサイクルタイムです。 最初のコミットからマージされるまで平均3.6時間程度と、開発に着手したらその日のうちにリリースされるのがデフォルトとなっています。 今回はこの開発スピードを継続し、更に速くするために弊社で実践しているテクニックを紹介していきます。 それでは見ていきましょう! タスク分解 Pull requestの粒度 テスト CI/CD 高速化 自動化 通知 まとめ タスク分解 開発タスクをアサインされた時、まず最初にタスク分解をします。 タスク分解をすることによるメリットとしては、 工数見積もりの精度が上がる 対応方針の認識を他メンバーと合わせやすくなる 対応漏れに気づきやすくなり、手戻りの発生が少なくなる Pull requestの粒度を適切に保つことが

                            Findyの爆速開発を支えるテクニック - Findy Tech Blog
                          • Playwrightを使ったE2Eテストを導入した話 - インフラ編 Playwright × Allure Report × AWS - Uzabase for Engineers

                            はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日は Playwright を使ったE2Eテストの導入について、紹介させていただきました。 今回は作成したテストをAWS 基盤上で動かす方法を紹介させていただきます。 前回の記事 tech.uzabase.com E2Eテスト実行のタイミング NewsPicksでは 下記のタイミングで E2Eテストを実行させています。 ①リリース時のカナリーデプロイ後 NewsPicks ではカナリーリリースを採用していてカナリーへのデプロイが完了した後、カナリーに向けてE2Eテストが動きます。 ②開発環境デプロイ後 動作確認をしたい場合に feature ブランチなどでデプロイ後 E2Eテストを実行できるようにしています。 本記事では主に 「②開発環境デプロイ後」 を例に紹介します。 実行方法 具

                              Playwrightを使ったE2Eテストを導入した話 - インフラ編 Playwright × Allure Report × AWS - Uzabase for Engineers
                            • セクハラ男性講師を野放しにしたお茶の水女子大学の異常な「隠蔽体質」|小山(狂)

                              SNSを中心に「炎上」状態になっているお茶の水女子大学講師の神山翼氏を中心とするセクハラ・アカハラ疑惑とその隠蔽問題について、発端から現在に至るまでの簡単な流れをまとめました。 本件は筆者のもとに20名以上の関係者から証言が集まったことで急速に注目された事件ですが、そもそもなぜ神山翼氏のアカハラについて多数の証言が集まったのか、どのような経緯で注目されるに至ったのかを含め、時系列順に解説していきます。 発端:神山翼氏の「男性は原罪を背負ってる」発言もともと神山翼氏は女性に対するアファーマティブ・アクションを強く主張するフェミニスト男性として知られていました。ただしその主張には批判も多く、「男女間格差の解消のため若年男性がワリを食うのは仕方ない」という差別的な主旨の発言をして炎上するなど、良くも悪くも度々SNSで目立つ振舞いをする教員として知られていました。 そんな神山翼氏がかつてない大炎上

                                セクハラ男性講師を野放しにしたお茶の水女子大学の異常な「隠蔽体質」|小山(狂)
                              • AWSコスト異常検知を導入したら、『人にお願いする』トイルが発生したのでSlackBotを作って解消した - KAYAC engineers' blog

                                SREチームの池田(@mashiike)です。SRE連載の5月号になります。 AWSのコストについては、多くの方がすごく気にしていると思います。 カヤックでもAWSのコストの変動に関しては敏感に気にしています。 そんな方々の心のお供になる機能が、 AWSコスト異常検知(AWS Cost Anomaly Detection) です。 今回は、このコスト異常検知にまつわるトイル削減の取り組みを紹介します。 背景 AWSコスト異常検知は、AWS マネジメントコンソールの中では『Billing and Cost Management』配下にある機能になります。 この機能を使うことでAWSで発生したコストに関して、通常とは異なるコストの発生を検知することができます。 コスト異常検知自体については、CureApp テックブログ様のZennの記事がわかりやすくまとまっているので、そちらを参照いただければ

                                  AWSコスト異常検知を導入したら、『人にお願いする』トイルが発生したのでSlackBotを作って解消した - KAYAC engineers' blog
                                • プルリクエストを見る時、出す時に重要なマインドセット - NRIネットコムBlog

                                  本記事は 【プルリクウィーク】 4日目の記事です。 💻 3日目 ▶▶ 本記事 ▶▶ 5日目 📚 こんにちは越川です。 GitHubはアプリケーションの開発に携わる人がメインで使う、という印象が強かったのですが現在、クラウドエンジニアの私もほぼ毎日GitHubを触っています。 私の場合、業務上、IaCを使うのでプログラミングをする機会が多く、その分プルリクエスト(以降PR)を見ることも出すことも多くあります。今回は自分自身がPRを見る時、または出す時にどんなことを意識しているのかを書いてみようと思います。 ※PRとは新規開発や改修などの内容を関係者に通知する仕組みです。このPRをトリガーに関係者はコードのレビューを実施し、問題なければマージを行います。 ※IaCとはInfrastructure as Codeの略称で、サーバーやネットワークなどあらゆるインフラリソースをコード化し、構築を

                                    プルリクエストを見る時、出す時に重要なマインドセット - NRIネットコムBlog
                                  • スプリントプランニングの未来予測: 予言の書 - SmartHR Tech Blog

                                    こんにちは! SmartHR プロダクトエンジニアの @sakata と @hypermkt です。 SmartHRではほぼすべてのチームでスクラム開発を行っています。スプリントプランニングとスプリント進行中における課題に対し、私たちのチームでは「予言の書」という取り込みを行っています。本記事では、この「予言の書」の概要とその効果についてご紹介します。 予言の書が必要な背景 スクラム開発で、チームが消化できるキャパシティからタスクを選定したにも関わらず、すべてのタスクの消化ができなかったという経験はありませんか? 私たちはたくさん経験したことがあります。そこにはスプリントプランニングにおける計画とスプリント進行の難しさがありました。 すべてのタスクが終えられるか不安がある まだ作業タスクには何も着手していないので当たり前ではありますが、チームが消化可能なキャパシティからタスクを選定し、優先

                                      スプリントプランニングの未来予測: 予言の書 - SmartHR Tech Blog
                                    • 大規模サービスのローンチに向け、パフォーマンスチューニングした話 #go #aws

                                      背景 こんにちは!Hanoi Dev Centerでバックエンドエンジニアをしているminhquangです。この記事では、私がAI事業本部のある新規プロダクト開発に参画した際に経験したパフォーマンスチューニングについて話したいと思います。 皆さんはサービスのローンチ(サービスを世の中に初めて出すリリース)をやったことがありますか。サービスローンチするときに、リクエストのスパイクや、ユーザー数の増加によるサーバー負荷増加など、様々な未知な課題が存在します。 私のチームでは数百万人の利用が見込まれるサービスにおいて、18000RPSを実現するべく負荷試験とパフォーマンスチューニングを実施しました。 本記事では、上記のサービス要件を満たすために私たちが取り組んだ負荷試験やパフォーマンスチューニングについて説明しつつ、これらの経験から得られた学びを共有したいと思います。 前提 技術スタック サーバ

                                        大規模サービスのローンチに向け、パフォーマンスチューニングした話 #go #aws
                                      1