タグ

developmentに関するnaglfarのブックマーク (126)

  • 【翻訳】テスト駆動開発の定義 - t-wadaのブログ

    このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

    【翻訳】テスト駆動開発の定義 - t-wadaのブログ
    naglfar
    naglfar 2024/03/08
    テストを書く際に忘れちゃいけないこと。闇雲にテストをしても意味はない。
  • 開発組織を改善していくための技術|BTO

    OPENLOGI Advent Calendar 2022 5日目の記事です。 おはこんばんちは!! 尾藤 a.k.a. BTOです。 今年の8月にオープンロジという物流テックの会社に入社しました。入社してから4ヶ月経ち、無事に試用期間が終了したということでほっとしております。 今までウノウ、UUUM、Reproという会社でCTOを歴任してきました。立場や経験上、開発組織の立ち上げや改善に携わることが多いです。今まで自分がやってきて、開発組織を改善するために気をつけていることを書いていきます。 既存のシステムをリスペクトするあなたがこの瞬間のシステムを切り取って見た時に、仕組みがぐちゃぐちゃだったり、意味不明な処理をしていたり、不合理な仕組みになっていることは大いにあると思います。しかしながらこれまでの会社を支えて売上を作ってきたのは、紛れもない今のシステムなのです。過去の経緯もいろいろあ

    開発組織を改善していくための技術|BTO
    naglfar
    naglfar 2022/12/09
    めっちゃ興味深い、意識していきたい。
  • 「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ

    2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない!」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが当に望んでいることは異なります。「UXデザインUXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。Read less

    「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
    naglfar
    naglfar 2022/09/18
    とってもよかった。
  • EC サイトの URL 構造 ベスト プラクティス | Google 検索セントラル  |  ドキュメント  |  Google for Developers

    フィードバックを送信 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 e コマース ウェブサイトの URL 構造を設計する Google が e コマースサイトのウェブページを効率的に発見して取得できるように、URL を適切に設計してください。お客様が URL の構造を管理されている場合には(たとえば、独自のサイトをゼロから構築されているなど)、このガイドを参考にして URL 構造を決定すると、Google が e コマースサイトをインデックス登録する際の問題を回避できます。 URL 構造が重要である理由 URL 構造の設計が適切であれば、Google はサイトをクロールしやすく、インデックス登録もしやすくなります。URL 構造に不十分な点があれば、以下の問題が発生する可能性があります。 Googlebot が 2 つの URL で同じコンテンツが返される

    EC サイトの URL 構造 ベスト プラクティス | Google 検索セントラル  |  ドキュメント  |  Google for Developers
    naglfar
    naglfar 2021/10/23
    思想が違う相手にも「 Google 推奨はこっちですから」で押せる!
  • ソフトウェアドキュメント作法 - maru source

    こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。 #devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました! #33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日 これらのドキュメントは個人的にわりと良く書けたと思ってますし、

    ソフトウェアドキュメント作法 - maru source
  • タイムゾーン呪いの書 (知識編)

    「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越すことにしました。 この改訂では Software Design 誌の 2018年 12月号に特集の一章として寄稿した内容も取り込みつつ、夏時間をめぐって各地で起きつつある変化について 2021年 6月現在の状況なども追加しました。そんな追記もしていたら記事全体が長大になってしまったため、この「知識編」と、「実装編」・「Java 編」に記事を分けました。「知識編」は、導入にあたる第一部です。 Qiita のほうは、引っ越した旨とこの引っ越し先へのリンクだけ追記して、しばらくそのまま残すつもりです。 はじめに タイムゾーンという概念のことは、ほとんどの人が聞いたことがあると思います。ソフトウェア・エンジニアでも多くの方が、時刻やタイムゾ

    タイムゾーン呪いの書 (知識編)
    naglfar
    naglfar 2021/07/07
    呼んだら後戻りできないところまで含めた呪いか……。とても素晴らしい。
  • いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。|Fritz | Lead Product Manager @ Mercari

    いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が(たぶん) IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル(

    いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。|Fritz | Lead Product Manager @ Mercari
    naglfar
    naglfar 2021/01/22
    長いんだけど「ほんとそれ」が詰まってた。コミュニケーションコスト、削減したい。
  • ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita

    はじめに 今日は、ニコニコのプレミアム会員サービスを支える「プレミアム課金システム」を動画システムのモノリスから切り出し、変更可能にしていった過程について書きます。プレミアム課金システムは金銭を扱うシステムですので、「(特に、失敗した)話を聞くのは面白いけど、自分で触りたくない」と思われる方も多いのではないでしょうか。 この記事では、決済にかかわるシステムでも一般的なシステム改善の方法が適用できることをお伝えしたいと思います。また、コストを抑えつつ着実なシステム改善を行う方法論としてもご理解していただけると嬉しく思います。 背景 プレミアム会員サービスについて 月額500円(税別)のプレミアム会員制度には159万人(2020年9月末現在)の方が加入してくださっており、ニコニコ事業を支える主要な有料サービスです。 ニコニコ動画は2006年にサービスを開始し、2007年にプレミアム会員サービス

    ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita
    naglfar
    naglfar 2020/12/04
    とても好い記事。今のシステムをただ生き長らえさせるだけではなく、しかし全く新しいものに変えるわけでもなく。
  • 本番環境でやらかしちゃった人のカレンダー | Advent Calendar 2020 - Qiita

    昨年非常に盛り上がっていましたので作成させていただきました。 番環境でやらかしちゃった人のアドベントカレンダーです。 例) DB吹き飛ばした 番サーバをデストロイした ネットワーク設定をミスって番サーバにアクセス出来なくなり、サーバが世界から孤立した などなど... 以下の2点については必須項目なので、記述お願いします。 惨劇はなぜおこってしまったのか 二度と惨劇を起こさないためにどうしたのか もう二度とあの惨劇を繰り返さないために、みなで知見を共有しましょう。 過去 番環境でやらかしちゃった人 Advent Calendar 2019

    本番環境でやらかしちゃった人のカレンダー | Advent Calendar 2020 - Qiita
    naglfar
    naglfar 2020/11/27
    こわたのしみ……。
  • GUILTY GEAR Xrd開発スタッフが送るアニメ調キャラモデリングTIPS

    2018年8月に行いました講演のスライドを公開します。 講演者:村・C・純也(アークシステムワークス株式会社) 「GUILTY GEAR Xrd開発スタッフが送るアニメ調キャラモデリングTIPS」 近年需要が高まりつつある「3Dでのアニメ調キャラクター作成」のTIPSを、 GUILTY GEAR Xrdのキャラクターモデルを作例として硬軟織り交ぜて紹介します。 主なトピック: ・GUILTY GEAR Xrdでのモデリングのワークフロー(設定画からモデリングまで) ・破綻の少ない顔形状の作り方の実践TIPS ・初心者がやってしまいがちなミスとその回避方法 ・実践的な法線編集のテクニックRead less

    GUILTY GEAR Xrd開発スタッフが送るアニメ調キャラモデリングTIPS
    naglfar
    naglfar 2020/11/07
    めちゃめちゃ素晴らしい tips だ。これくらいできるようにがんばりたい……。
  • 1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary

    自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

    1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
    naglfar
    naglfar 2020/11/05
    つらい……カジュアルの定義を知りたい……。
  • Playストアからの削除警告について - Subway Tooter blog

    Subway Tooterの概要 Subway Tooter は分散マイクロブログサービスであるMastodonAPIを利用するクライアントアプリケーションです。 このアプリはMastodon APIと十分な互換性のある任意のサーバにアクセスできます。接続先のサーバを運営しているのはSubway Tooterではないことに注意してください。 Mastodonの概要 Mastodonは分散マイクロブログの製品名です。Webやメールと同様に、世界中に何千ものサーバが存在します。それらのサーバはそれぞれ異なるポリシーを持ち、全体が緩く連合しています。サーバやユーザは他のサーバやユーザを自由にブロックできます。 Googleからのメール Subway Tooter だけでなく、Fedilab, Husky, MastoPane なども同様の削除警告を受け取っています。 From: Google

    Playストアからの削除警告について - Subway Tooter blog
    naglfar
    naglfar 2020/10/02
    禁止サーバリストを追加しない対応、支持する。
  • データベースをリファクタリングしたお話 - BASEプロダクトチームブログ

    基盤チーム所属の沖中( @okinaka )です。 「リファクタリング」という言葉、エンジニアのみなさんならご存知でしょう。 システムの振る舞いを変えずに内部を改善することを指す言葉です。 一般的に、コードの修正を指すことがほとんどですが、今回はデータベース設計のリファクタリングについてお話ししたいと思います。 絶版になってしまいましたが、データベース・リファクタリング という書籍に様々な手法が紹介されていて参考になります。英語で良ければ 原書 はまだ入手可能ですね。 データベース・リファクタリング 作者:スコット W アンブラー,ピラモド・サダラージ発売日: 2008/03/26メディア: 単行 Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler)) (

    データベースをリファクタリングしたお話 - BASEプロダクトチームブログ
    naglfar
    naglfar 2020/09/17
    テーブルの内容を同期して、日々すこしずつ参照している部分を書き換えていったのか。そういうやり方が許されるの素晴らしい……。
  • 設計書には何を書くべきなのか - terurouメモ

    設計とは、 要求(やりたいこと)をヒアリングする 要求を要件(何を満たさないといけないのか)に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する(一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する) 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案(いわゆる比較表で書いていくのが楽) 検証結果 選定・合意結果(合意した代替策や妥協ラインについても記載する) 詳細設計(どういう実装にするとか、パラメーターにするとか、細

    設計書には何を書くべきなのか - terurouメモ
    naglfar
    naglfar 2020/08/03
    今までに「なぜ」を書いてるドキュメント、ほとんど見た覚えない。意識的に残していきたい。
  • テストの説明に安易に「正しく」とか書かない - Object.create(null)

    みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正

    テストの説明に安易に「正しく」とか書かない - Object.create(null)
    naglfar
    naglfar 2020/07/24
    同感。「正しく」って見るといつも「何が正しいんだよ、それを書くのが仕様書じゃないのか」って思う。天の邪鬼だからってのもあるけど。
  • 非エンジニアから相談を受けたときの心得 - Qiita

    まえがき 非IT企業で社内SEをやっている人です。 私が入社して1ヶ月後にケガで長期入院してしまった上司の代わりに、社員から「こういうシステムって作れますか?」「このツールの設定がわかんないから教えて〜」みたいな相談を受ける窓口となって、要件定義的なことしてきました。 最近この役割を後輩に譲ることにしたので、おもに自分が失敗してきた経験をもとに社内SEが非エンジニアから相談や依頼を受けたときに意識したいことをまとめてみました。 後輩だけでなくこの記事を読んだ人にも役立てていただけると幸いです。 目次 日語でちゃんとコミュニケーションをとる 技術のことはいったん忘れる 言われたとおりにやらない ユーザーシナリオを書く あとがき 日語でちゃんとコミュニケーションをとる 日語も立派なエンジニアリングスキルの1つです。 「スキルアップしたいです!」っていうエンジニアには「まず日語の使い方を

    非エンジニアから相談を受けたときの心得 - Qiita
    naglfar
    naglfar 2020/07/20
    好かった。コミュニケーションは大事で難しい。SE、PG同士でも「当たり前」で済ませないようにしたい。
  • ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが? - Qiita

    ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが?LaravelDDD設計アーキテクチャCleanArchitecture ある日夢の中で設計に詳しい悪役令嬢が現れてこんなことを言い放ったので、考察してみましたという設定のポエムです。 問題提起 ドメイン駆動設計、オニオンアーキテクチャ、クリーンアーキテクチャといった考え方はもちろん重要なものの、僕は難しく考えずに「削除しやすいように機能を作る」のが第一歩として重要ではないかと考えています。 記事では「削除しやすい設計」について持論を展開してみます。 ※議論のスコープはWebサービスに限定し、例示としてPHPのフレームワークであるLaravelを用います 削除しやすいことがなぜ重要か 一度開発した機能は、それで終わりではなく、改修、改善を繰り返し、そして場合によっては仕様が廃止さ

    ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが? - Qiita
    naglfar
    naglfar 2020/07/16
    例はさておき、不要になった機能はきちんとコードからも削除すべきという方針には同意する。未使用とか廃止ってコメントをつけて残すくらいならバッサリしたい。
  • ローカル開発環境の https 化 | blog.jxck.io

    Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う

    ローカル開発環境の https 化 | blog.jxck.io
    naglfar
    naglfar 2020/06/30
    “ permission 周りの挙動の違いや、 mixed contents の見落としなど”、身に覚えがありすぎて泣いた。仕事では自由になるドメインがなくて悲しい。
  • 現場で役立つシステム設計の原則メモ - Qiita

    This article is a Private article. Only a writer and users who know the URL can access it. Please change open range to public in publish setting if you want to share this article with other users. ※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ

    現場で役立つシステム設計の原則メモ - Qiita
    naglfar
    naglfar 2020/04/06
    とても良い記事。ありがたい。って……本の内容を書き下したものなのか。
  • 障害の対策というゲーム その進め方 - 虎の穴開発室ブログ

    初めましての方は初めまして。お久しぶりの方はお久しぶりです。虎の穴のY.Mです。 このブログが始まった頃に、よく記事を書いていました。 月日は流れて、現在はEC開発のリーダーをやっております。 今回は技術的な内容というよりは、開発プロセスの内容を少し書きます。 書こうと思ったワケ 弊社のブログを眺めていたところ、これまで虎の穴の開発文化を紹介したことがなかったなと感じました。 チームでの開発をする上では、技術力はもちろん大事ですが、そのチームの開発文化が品質に大きく影響してきます。 ブログを読んでいただいている皆さんに、少しでも「こんな仕事のやり方をしてるよ」というのを知ってもらうべく、久しぶりに筆をとりました。 今回はそのとっかかりとして、一番エンジニアが頭と心を痛めるであろう『障害の事後対応』について書きます。 せっかくオタクエンジニアとして書くので、ちょっとゲーム仕立てにしてみます。

    障害の対策というゲーム その進め方 - 虎の穴開発室ブログ
    naglfar
    naglfar 2020/03/28
    基本に忠実なよいまとめだと思う。「なぜなぜ分析」を個人攻撃にしないことが、わたしの場合、一番むずかしい……。