【翻訳】テスト駆動開発の定義 - 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の正
GitLabで学んだ最高の働き方 Developers Summit 2022-02-18
Page Scrolling Vertical Scrolling Horizontal Scrolling Wrapped Scrolling
社内PlatformチームのProduct Management
現職においてPlatform チーム（社内基盤チーム）として働き始めて2年近くがたった．このチームにおいて自分はTech Leadをメインに努めてきたが，同時にPlatformの「どのような機能を」「どのような優先度で」作るか? を決めるProduct Manager的な役割も果たしてきた（ちなみにTech Leadに関してはメルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ で少し話した）．これは何度も失敗しながら悪戦苦闘しつつやってきたが自分たちなりのフレームワークをつくり実際に回すことができている． 未だに試行錯誤しているのでここで書いていることが正解だとは思っていないが，今後同じようにPlatformチーム的なことを始めるひとに向けて現状自分たちがどのようにやっているのかについて簡単にまとめておく（他の会社がどのようにやってるのかも聞きたいのでもし同じような
Microsoft 365 apps say farewell to Internet Explorer 11 and Windows 10 sunsets Microsoft Edge Legacy
August 17, 2021: Support is now unavailable for Microsoft 365 apps and services on IE11. Additionally, you should expect no new features when accessing Microsoft 365 apps and services on IE11 and that the daily usage experience for users could get progressively worse over time until the apps and services are disconnected. Banners will be used to communicate and alert users to upcoming changes in e
DX Criteriaとは - DX Criteria v201912- 「２つのDX」とデジタル経営のガイドライン
DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。 また、本基準は絶対ではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会の個人会員様と議論をおこないながら、適宜アップデートをしていくものです。 https://dxcriteria.cto-a.org
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
コードの健全性: 礼儀正しいレビュー == 役立つレビュー
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads 71 Ads API 10
２つのDXと技術的負債-YAPC Tokyo 2019
「エンジニアリング組織論への招待」はビジネス書としても技術書としても評価された。これら二つは別のことなのだろうか。それをも同じものなのだろうか。 この講演では技術者体験DXと企業のデジタル化のDXの２つを橋渡ししていく。 「エンジニアリング組織論への招待」の骨子である、不確実性を恐れる人間の本能を乗り越えて、それらに向き合える組織を作ることによって生産的なチームができる。 そして、ソフトウェアを作るとは、「認識に齟齬がないほど明晰な言語に書き下すこと」であれば、これは情報の非対称性を減らすというコミュニケーションそのものだろう。 このコミュニケーションのコスト構造をそのまま、システムの構造に当て込んでしまうというのを「コンウェイの法則」と呼ばれている。 組織構造の問題が、システムへと転移して、コントローラビリティを喪失すること。これが技術的負債の真実であるなら、これはありふれた経済現象であ
安全なWebアプリケーションの作り方2018 - slideshare
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
リモートワーク歴7年の会社に聞いてきた！テレビ会議16のコツ | リモートワークラボ
テレビ会議がじわじわ浸透してきたけど、ちょっとした「うまくいかないこと」のせいでなんとなく好きになれない・億劫に感じてしまう…そんなことはありませんか？ 全社員フルリモート・すべての会議はテレビ会議、というスタイルで、今年7年目を迎える株式会社ソニックガーデンの社員の皆さんから、そのノウハウを聞き出してきました！ この「17のコツ」を押さえれば、明日からのテレビ会議がもっと自然でスムーズなものになりますよ！ 株式会社ソニックガーデンについてはこちら↓ 【リモートワークスタイルのフラッグシップに】 チームで働くリモートワーカー集団ソニックガーデン（前編） ～リモートワークスタイルのフラッグシップに～ チームで働くリモートワーカー集団ソニックガーデン（後編） リモートワーク7年目社員たちが教える「テレビ会議16のコツ」 1). 指示代名詞を使わない 「あれ」「それ」「これ」は音声に頼る時、かな
ZOZOTOWNシステムリプレイスの道のり/ ZOZOTOWN 更换云系统之道 - Speaker Deck
All slide content and descriptions are owned by their creators.
1秒でも早くプルリクをマージしたい - chiastolite’s blog
最近プルリクを作ったり見るときに考えてること。 前提 プルリクはマージされてシップするまで顧客に対して価値を産んでいない 1秒でも早くマージしてシップすることが何より大切 もちろん質をおろそかにしていいわけではない この2つをレビュアーとレビュイーが共有する必要がある どうやったら早くマージできるか これは単純で プルリクの意図/価値を共有しておく やり取りの回数を減らす 指摘→修正→指摘→修正みたいなのはさける 読むべき量を減らす だけでOK レビュイーとして プルリクの意図を必ず書く 「なぜ」これが必要なのか 想定した問題やそれに対する考えなどがあったなら書く(パーマネントリンクを添えると最高) 想定した結果、あえて選択しなかった手段/方法とかもあるなら書いておいたほうがいい 余計な変更は入れない コードスタイルの変更などは読むときのノイズになる 伝わりづらい/自分でもわかりづらいと思
レガシーコードの触り方 / Working Effectively with Legacy Code
オープンセミナー2017@岡山
闇のDevOps DevOpsと業績評価 – ところてん – Medium
ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究
登場人物を分類し、振る舞いを分解して、機能を考える（企画職の人に教えてもらったこと） - $shibayu36->blog;
本職の企画の人が優れた機能案を出してくる理由がわからなくて、どうやってやってるんですかと雑談した。新たな発見があったので、雑なメモだけ残しておく。*1 その人の企画の流れ 企画の流れは、以下の3ステップで行っているらしい。 1. 登場人物を分類する 2. 登場人物ごとの振る舞いを分解する 3. 様々な振る舞いを照らし合わせて、機能・UIを絞り込んでいく 「1. 登場人物を分類する」は、機能に関わる人物をツリー構造に分類していき、分類をした結果から、その機能を使うメインターゲットを決めるフェーズらしい。 例えば、ブログユーザーをブログの作者と読者に、さらに作者を毎日更新する人とそうでない人に、みたいにどんどん分解していく。すると、機能のメインターゲットが浮かんでくる。 「2. 登場人物ごとの振る舞いを分解する」では、メインターゲットを中心に、どのような振る舞いをするかを考えるフェーズらしい。
Front-End Developer Handbook 2017 · GitBook
AVAILABLE NOW: Front-End Developer Handbook 2018 Front-End Developer Handbook 2017 Written by Cody Lindley sponsored by — Frontend Masters This is a guide that anyone could use to learn about the practice of front-end development. It broadly outlines and discusses the practice of front-end engineering: how to learn it and what tools are used when practicing it in 2017. It is specifically written w
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バス因子が自分で バス因子を脱するための方法
現役スクラムマスターが考える「こんなプロダクトオーナーは嫌だ」
技術的負債と向き合う
DeNA流データエンジニアリングの極意
