八巻芳夫（やまき よしお、1900年 - 1990年）は、日本の土木技術者、都市計画家。仙台市の戦災復興都市計画に従事・尽力。青葉通り、定禅寺通りのケヤキ並木道の設計者。丸森町出身。東北帝国大学附属工学専門部/旧制仙台高等工業学校土木工学科卒業後、朝鮮総督府に勤務。総督府で地方出先の土木課長などを歴任。朝鮮時代に乱伐された山林をみて緑のない地方道は次々に並木を整備していったという。1946年に帰国し、仙台市に勤務。仙台市戦災復興局建設部公営課長から後に建設局復興部長、建設局長を歴任。1959年からは仙台市技監。1966年に退職。その後土地区画整理審議会全国連合会などに関わる。
第28回都市対抗野球大会（だい28かいとしたいこうやきゅうたいかい）は、1957年7月27日から8月4日まで後楽園球場で開かれた都市対抗野球大会である。
特筆以外すべてクレジットは「監督」である。公開日の右側には特筆する職能のクレジット、および東京国立近代美術館フィルムセンター（NFC）所蔵等の上映用プリントの現存状況についても記す。同センター等に所蔵されていないものは、とくに1940年代以前の作品についてはほぼ現存しないフィルムである。
マイクロソフトが提供するクラウドベースの、ソースコード管理（GitおよびTFVC）、レポーティング、要求管理、プロジェクトマネジメント、自動ビルド、テスト・リリースマネジメントからなる統合ツールである。小規模チーム向けのエディションであり最大5ユーザまで無料、それ以上のユーザはライセンスを購入することにより使用可能となる。なお、関係者ユーザ（ワークアイテムやカンバンなどの管理・利用のみできる限定ユーザ）およびVisual Studio契約者は特典としてサービスへの無償アクセスが可能である。
Visual Studio 2005において「チームでの開発」に関する機能を司るサーバ製品として2006年に発売された。その後Visual Studioのバージョンアップに伴い1〜2年に1回新バージョンがリリースされており、2017年現在の最新版は「Team Foundation Server 2018」。それ以前のVisual SourceSafe (VSS) の後継製品に当たり、VSSが持つソースコード管理機能に加え、データの保存、プロジェクト管理などのソフトウェア開発プロジェクトを円滑に進めるための機能を備えている。Team Foundation Server 2018は、サーバ側はWindows Server 2012以降のWindows Serverが必要になる。
敵対国の王の妃イグレイン（Igraine）に恋をし、あろうことか妃を奪うためコーンウォールに攻め入り、マーリンの力を借りて敵の王ゴルロイスに姿を変えた。ゴルロイスに姿を変えたユーサーと妃は交わり、己の欲望を満たした。一方本物のゴルロイスはこのとき戦死してしまった。ユーサーとイグレーヌはその後結婚し、子をマーリンに預けた。この子供こそアーサー王である。当時は略奪婚など珍しくなく、勝者こそが姫を奪うことが許されていたのである。姫、妃は勝者の側につかないことには生存すら許されないのである。アーサー王物語はその部分をカットせずに伝えている。
リファクタリングが登場する以前は、一度正常な動作をしたプログラムは二度と手を触れるべきではないと言われていた。なぜなら、下手に手を加えて動作が変わってしまうと、それに伴って関連する部分にも修正が加えられ、やがてその修正作業はプロジェクト全体に波及し対処しきれなくなる可能性があったからである。また、ソフトウェアテストを十分に行い、正常な動作が確認されたとしても、そのプログラムを少しでも改変してしまえば、その後バグ (欠陥) が見つかったときに、改変があったプログラムを疑わなければならない。しかし、プログラムには必ず変更があり、プログラムはどうしても継ぎ接ぎだらけになることは避けられない。また、仕様が開発開始時から確定していることは少なく、開発をしている間にもソフトウェアに対する要求は日々変わり続けており、ソフトウェアには常に仕様変更に対応できる柔軟さが求められる。さらに、いくら厳密に設計しても実際に動作させないと分からない部分も多く、完璧な設計を行うことは不可能である。変更が必要になったとき、二度と手を触れられないほど煩雑になったソースコードを修正することは困難を極め、プログラマにも勇気が要求される作業になる。そこで、Smalltalkプログラマなどの間で、常日頃からプログラムを整理し、仕様変更にも対応できる整理されたプログラムを書いていく考え方が生まれた。この過程では、ウォード・カニンガム、ケント・ベック、ラルフ・ジョンソン（GoFの一人）などの人々が大きな役割を果たした。この手法がリファクタリングと呼ばれている。また、リファクタリングは、プログラムの全容を捉えるためにも効果的である。例えば、バグが検出された場合でも、ソースコードが整理されているので、修正しやすい。また、プログラマとしても、普段から修正しているコードに手を入れるだけなので、修正にも積極的になれる。さらに、設計者も設計ミスによる心残りをなくすことができる。そのため、「リファクタリングは設計の代用にもなる」とする意見もあり、事前設計を非常に簡素化する役割も担っている。リファクタリングは、オブジェクト指向設計と深く関係している。ほとんどのリファクタリングは、オブジェクト指向の性質に沿ったものであり、オブジェクト指向のコードの再利用性を最大限に引き出すことができる。また、オブジェクト指向プログラミングを行える言語であれば、プログラミング言語の種類に関わらず、リファクタリングを適用できる。リファクタリングを行うことで、開発が停滞してしまうのではないか、という心配をされることも多い。たしかに、リファクタリングを行っている間は、何の機能追加も行われない。しかし、たいていの場合は、設計が向上することで機能追加やバグフィックスをしやすくなり、開発のスピードは安定するばかりか、速くなることもある。また、すでに機能しているコードを危険に晒すべきでない、とする意見もあるが、手順を守りテストを十分に行えば、ある程度危険を減らすことができる。