О зефирках

Друзья, я часто слышу о зефирном тесте. Это тот эксперимент, где детей оставляют наедине с зефиркой и обещают еще одну, если первая не будет съедена за пятнадцать минут.
Красиво, эффективно, убедительно.
Скажите, а есть контр-примеры? Может быть существует альтернативное мнение, какие-то не столь популярные исследования с противоположным результатом? Или, может, подтверждающие? Что-то кроме загадочного Walter Mischel.
Лично мне, как трагические ситуации из окружающей реальности представляются забытые истории из 90-х, с обещанием сказочных прибылей согласившимся "купить акции завода сейчас" или супер-премии "когда все наладится" при задолженности по зарплате в несколько месяцев.
Как вы думаете, новый миф и заговор корпораций или особенность человеческой психологии?

Введение в ТРИЗ для программистов

Недавно лентой мне принесло прелюбопытнейшее видео: Введение в ТРИЗ для программистов. Это запись семинара, который проводился в СПбГУ, смотреть и скачивать можно совершенно бесплатно, правда, надо зарегистрироваться на сайте.

Лично я считаю, что материал неплохой, и сама ТРИЗ вещь очень нужная и полезная. Во-первых это практические методы реально помогающие в решении задач, во-вторых это философия и способ упорядочить сознание.
Но будьте осторожны! В материале могут встретиться моменты выносящие мозг с корнем. Например, в третьей лекции ("Примеры решения задач"). Решение задачи о вводе пароля мне кажется несколько неудачным. Я так и записал себе: "45-я минута - отметка с которой начинается глубокое погружение в маразм". А на 50-й минуте мне почудилась шизофазия (фраза об "это стало много"). Тем не менее, наверняка это особенности моего восприятия, а вы можете посмотреть и сложить собственное мнение.

P.S.: Я понял кого он мне напоминает! Манерой изъясняться он очень похож на моего школьного преподавателя ОНТТ (Основы Научно-Технического Творчества, же!) У того тоже была привычка говорить что-то вроде: "да, вы еще ничего не знаете про ОНТТ, а уже спорите" и задавать задачи о том "кто больнее на ногу наступит - слон или женщина на шпильке" и выдавать собственный ответ за правильный несмотря на то, что формула P = dF_n/dS ни для кого не секрет.

Но все-таки сам я собираюсь это видео досмотреть и вам советую.

Процесс или результат?

Совсем недавно мы основательно препирались с шефом по поводу одной методологической мелочи. В ходе «горячей беседы» шеф спросил:

«...почему я должен потратить ДВА часа вместо часа?
что важнее – РЕЗУЛЬТАТ или ПРОЦЕСС?»

Казалось бы, ответ очевидный: конечно, результат! Кого волнует какой-то там процесс, если результат – вот он, перед тобой. Да и сам процесс, собственно, затевался именно ради результата, а не наоборот.

Но!

Результат может оказаться хуже, чем ты рассчитывал увидеть. Знаете, результат вообще может быть из рук вон отвратительный. Никудышный результат. И тогда мы вспоминаем о процессе.

Есть мнение, что:

...качество продукта напрямую связано с качеством используемых для его создания процессов.

Так в десятой главе с сочным названием «Качество программного обеспечения» говорит нам SWEBOK. Во всяком случае все, кто согласен с этой формулировкой, ссылаются в первую очередь туда.
К тому же примерно о том говорят сверхпопулярные стандарты серии ISO 9000. Обратите внимание, что:

ISO 9000 – серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.

Или как объясняется чуть ниже:

Важно понимать, что соответствие стандарту ISO 9001 не гарантирует высокое качество продукции. Термин «quality management» здесь было бы правильнее переводить как «управление добротностью». Соответствие требованиям и рекомендациям этих стандартов говорит о способности предприятия:

• делать всё максимально возможное для достижения поставленных перед собой целей;
• улучшать результативность своей деятельности.

То есть, по сути, стандарты ISO 9000 выдвигают требования не к качеству конечного продукта, а к качеству ПРОЦЕССА его создания. Просто и со вкусом. И вряд ли найдется человек, который ни разу в жизни не встречал надписи «ISO 9001», например. А какие настолько же популярные стандарты на конечный продукт вы знаете? Кроме, конечно же, того самого пресловутого ГОСТа, слава которого тянется из советских времен?

Программисты, конечно же, знают обо всем этом и не устают повторять окружающим (см. «Страсти по качеству», раздел «Не плюй в колодец ISO 9000...»). Но, увы, не все верят.
Мне повезло. У меня перед глазами есть живой пример. Две команды разработчиков, у одной из которых нет процесса вообще, а вторая как-то пытается налаживать процесс. И знаете, кажется, у второй дела идут получше.

И теперь я знаю ответ на вопрос, что же важнее – результат или процесс:
Результат, конечно, очень важен. Но если у нас есть хороший процесс, то мы можем получить хороший результат, а можем и плохой. Однако если процесс дерьмовый, то и результат будет гарантированно отвратительный.

А я желаю вам хорошего дня и хорошего кода.

1C, ООП, DDD и дальше

Сегодня я хочу пригласить вас немного помечтать. А то что это мы все за код да за код. Давайте о жизни. Ну и о коде, конечно, тоже. Потому что какая жизнь у программиста без кода?

Вот недавно я прочел (если честно, еще дочитываю) очень увлекательную книжку с умным названием "Приемы объектно-ориентированного проектирования" за авторством знаменитой "Gang of Four". В книге идет речь о шаблонах проектирования. Кстати, рекомендую от всей души, если кто еще не читал. Сложно представить себе, что ООП можно изучать без таких простых и наглядных примеров использования, какие приводятся в этой книге. Честное слово, я бы ввел ее в школьную программу, может, и не в школьную, но в университетскую точно. А пытливому уму везде найдется польза и применение. Хоть 1С и не поддерживает ООП в полной мере, но и нашему брату, 1С-нику, крупицу истины из нее почерпнуть не грех.

А теперь давайте про 1С и ООП. Когда-то (до 19 октября 2005) Википедия про язык 1С утверждала, что:

Данный язык является интерпретируемым объектно-ориентированным языком высокого уровня.

(На самом деле это, конечно же, не так, но об этом позже.)
И добавляла, что:

Платформой предоставляется фиксированный набор базовых классов, на основании которых можно создавать любое количество порожденных классов, наследующих их свойства и методы. Разработчик имеет возможность определять собственные дополнительные процедуры и функции, а также свойства порожденных классов (с некоторыми ограничениями). Допускается только одна ступень наследования классов. Не допускается переопределение процедур, описанных в базовых классах.

Если кто не понял, поясню: есть класс "Документы", от него можно создавать дочерние классы, вроде "Приходная накладная" или "Закрытие месяца", эти классы в свою очередь позволяют создавать конкретные экземпляры классов (объекты) - конкретные документы (ага, с номером и датой), которыми и управляет пользователь в режиме "Предприятие".
Не вполне ООП, но достаточно близко. Тут и один уровень наследования классов и разница между классом и экземпляром. Ну а про статические методы я уже недавно писал. Как говорили древние, "для умного достаточно", но недостаточно для программиста, у которого душа просится в полет, а руки тянутся к клавиатуре. Голова в этом всем никак не участвует, поэтому продолжаем мечтать.

А вот если бы!.. А вот если бы 1С была как Axapta или C++, например. Уж там-то наверняка полноценно поддерживается ООП, можно и шаблонов навертеть, объектную модель отгрохать - закачаешься. Только вот беда, у C++ порог вхождения выше. С 1С все просто: открыл конфигуратор - и ты уж программист. Сначала форму печатную поправил, потом расчет суммы подкорректировал, и пошло-поехало (ботинками не кидайтесь, пожалуйста, сам так начинал и еще кучу народа знаю такого же). А открой проект на C++ (сиплю-сиплю, а ничего не выходит) - чего-то не там переставил, и все - не компилируется в лучшем случае. Сложно и дорого. Потому-то 1С так мил сердцу мелкого бизнесмена, что не нужны заоблачные бюджеты на разработку, да и типовых конфигураций пруд пруди. Ну и нам, 1С-никам, заодно тепло и сухо. Но объектов хочется.

И вот недавно сама 1С подкинула интересную мысль. Помните релиз 8.2.14? Там, где общие реквизиты вернули. Так вот, что такое общие реквизиты с точки зрения ООП? Не что иное, как обычные свойства класса "Документы". Класс документы-то всеми подклассами наследуется, и свойства, стало быть, тоже. А что если разрешить не один уровень наследования от документов, а несколько? Вот это было бы здорово. Захожу я в конфигуратор (1Сv9, конечно же!), добавляю в документы группу "Товарные документы". Сразу в эту группу документов реквизиты добавляю, типа "Контрагент", "Опустил", "Принял" и ТЧ "Товары" с такими реквизитами - "Номенклатура", "Количество", "Цена". И тут же в модуле группы документов пишу код, что, мол, если количество поменялось - сумму пересчитать, если сумма - цену. Ну, вы все эти процедуры обработки реквизитов и сами по сто раз писали, чего я рассказываю. А потом уже в группе документов "Товарные документы" создаю "Приходную накладную", "Расходную накладную", ну и все, что положено. И у них все эти реквизиты и ТЧ уже есть - унаследовались от товарных документов. Просто волшебство и сплошной "ахалай-махалай" получается. Конечно, кое-где добавляю особенностей для каждого класса, реквизитов специфичных, но каркас работает общий. Удобно, черт возьми. Надо разрядность цены в товарных документах поменять - р-р-р-раз! - и поменял одним махом. Реквизит-то один. И код по обработке один. Так, по мелочи, потом пройтись останется. Ну, естественно, кроме группы "Товарные документы" делаю группу "Кассовые документы" из общего корня - "Документы". Там свои особенности, но общего тоже много. И так далее, и так далее.
Про то, что похожие фокусы со справочниками и другими объектами работают, говорить не буду: сами спокойно дофантазируете, если хотите.
Тут же, кстати, и общие модули немного разгрузятся. Есть модуль группы документов, там и обработки для этой группы документов можно разместить. Например, всякие поиски цен, обработки подборов и прочее. Оно ж все, по логике, к товарным документам относится, верно ведь? Вот пусть в модуле группы "Товарные документы" и лежит, чтобы долго не искать.
И подсистемы тоже как-то оборачиваются в новом свете. Теперь те же документы объединяются в группы с иерархией намного лучше, чем это делали подсистемы. Вот есть группа "Кассовые документы", и все, что относится к кассе, находится в ней. И это обоснованно с точки зрения наследования и структуры кода. Хотя с отношением к нескольким подсистемам проблема получается, но, наверное, и тут какое-то решение есть.
Конечно, это еще не полноценное ООП, но хороший шаг вперед. Или назад?

Давайте посмотрим, что Википедия сейчас пишет про 1С:

Данный язык является предварительно компилируемым предметно-ориентированным языком высокого уровня.

Ключевое слово тут "икра" предметно-ориентированным. На самом деле это очень важно. Именно предметно-ориентированность позволяет быть языку 1С "заумью с человеческим лицом". Когда такие понятия, как "документ" или "проводка", встроены в само ядро платформы, то всякие надуманные абстракции вроде классов и подклассов тихо бледнеют и не отсвечивают. В нормальных "больших" языках программирования тоже хотят так уметь. Даже целое направление придумали - DDD (русская Википедия, извините, об этом еще не в курсе). Так не испортим ли мы 1С, если начнем туда тянуть все эти наследования? Не знаю. Если бы я был разработчиком платформы (во куда хватил! но мы ж тут помечтать договорились, да?), я бы по-тихому все-таки протащил бы такую доменную сущность, как группы документов, не особо афишируя, что оно все торчит из ООП. В принципе, в рамках доменной модели (не путать с объектной) понятие "группа документов" вполне интуитивно понятно, ценно и достаточно функционально. Так что катастрофы тут не предвидится. Катастрофа предвидится, когда мы заговорим о множественном наследовании, но тут могу заметить, что это:

...концепция, поддерживаемая частью объектно-ориентированных языков программирования...

Частью! Так что нам тут бояться нечего, тут еще сами апологеты ООП до конца не определились.
Ну а не хочется вам с этими новомодными "группами документов" разбираться да все конфигурации переписывать - пожалуйста. Не наследуйте от групп, наследуйте от "Документы". И для вас как будто и ничего не поменялось. Вот вам, кстати, обратная совместимость.
Да... Много еще чего можно хорошего намечтать...

Оставляю вас за этим занятием и хочу пожелать вам хорошего дня и хорошего кода.

P.S.: Сильно не ругайте, если кто чем недоволен, о грубых ляпах пишите - буду исправляться.

Публикация на Infostart

Принцип тропинки. Шаманград.

По ссылке от ЛЛео нашел интересную статью о "тропинках".

По принципу тропинки, людей можно разделить на две неравные (и в общем относительные) группы. Первые хотят по протоптанным и расчищенным тропинкам, либо эксплуатируя результаты трудов других, либо пытаясь малыми усилиями обогнать первопроходцев и отобрать у них, если не всю, то кусок успеха. Вторые сами протаптывают себе тропинки, ищут свой путь. Кому-то удается найти свою золотую жилу, кому-то везет меньше и они ничего не находят.

Еще о тропинках и Шаманграде на сайте shamangrad.net...

Как стать героем

Макс Дорофеев выложил отличную ссылку на статью Якова Сироткина "Как стать героем".
В ней про все, про баги, про злое начальство и капризных клиентов, про Microsoft и Apple и, конечно, о программировании.
Не могу не подписаться под словами Макса: Это просто нелья не пропиарить!

Проектирование по вытягивающему принципу

Прекрасная статья из Gaperton's blog:

Сегодня в беседе с коллегой рассказал про то, как работает архитектор, и осознал, что ни разу ни где об этом не писал.

Кто читал старые книги по программированию помнит термины "программирование сверху вниз", "программирование снизу вверх", и, самое невероятное - "от центра к краям". Удивительная особенность этих терминов в том, что они просты и понятны, но ни один нормальный человек, примеряя объяснения на себя, понимает, что так работать не может. Это модели понятные, но к реальности никак не относящиеся. Так же, как и «легенда агилистов о ватерфоле».

Что имеет место в реальности - это две стратегии при работе над архитектурой. Вы их сразу узнаете при объяснении. Назовем их "push" и "pull".

Продолжение...

P.S.: Люблю такие "архитектурные изыскания" до дрожи.

Урбосный подкаст №4

Не могу не поделиться подкастом, который записал замечательный Витальский.
Дело было так. Как-то вечером я сидел и мучал Qt, как вдруг внезапно в аську постучался Витальский. Он напал на меня с вопросами, а потом записал очередной подкаст для своего проекта "Урбос". В нем будет немного об "эффекте присутствия", об идеологии лиги роботов и о трансгуманизме.

Вот он:


Собственно, комментарии и другие подкасты проекта "Урбос" можно почитать и послушать у него в ЖЖ, кто заинтересовался - добро пожаловать.

Cочинение 7-летнего Тараса

Кем я хочу стать когда буду большим

Я хочу стать программистом, когда выросту большим, потому что это классная работа и простая. Поэтому в наше время столько программистов и все время становится больше.
Программистам не нужно ходить в школу, им нужно учиться читать на компьютерном языке, что бы они могли с компьютером разговаривать.

Думаю, что они должны уметь читать тоже, что бы знать в чем дело, когда все напереполох.

Программисты должны быть смелыми, что бы не пугаться, когда все перепуталось так что никто не разберет, или если придется разговаривать на английском языке по-иностранному, что бы знать, что надо делать.

У программистов должно быть хорошее зрение, что бы видеть сквозь одежду и что бы не бояться секретарш, потому что с ними приходиться работать.

Еще мне нравитса зарплата, которую программисты получают.
Они получают столько денег, что не успевают их все тратить.
Это происходит потому, что все считают работу программиста трудной, кроме программистов, которые знают, как это просто.

Нет ничего такого, что бы мне не понравилось, кроме того что девочкам нравятся программисты и все хотят выйти за них замуж, и поэтому женщин надо гнать, что бы не мешали работать.

Надеюсь, что у меня нет аллергии на офисную пыль, потому что на нашу собаку у меня аллергия.

Eсли у меня будет аллергия на офисную пыль, программиста из меня не получится и придется искать настоящую работу.

Оригинал тут.

P.S.: Все так и есть, все так и есть!!!

Сам я считаю, что дефектом многих существующих учебников по технологиям программирования (это относится не только к COM, но и вообще к любой технологии излагаемой в современных учебниках) является то, что они начинаются "сверху" - "вызовите Wizard, отметьте в нём... поставьте... Wizard сгенерировал вам код...". Но в учебнике очень невнятно объясняется, почему Wizard сгенерировал именно такой код! Что означают те или иные макросы по ходу текста, как выглядит и сам протокол к которому Wizard строит реализацию. Словом, современные учебники пытаются обучить сложению используя в качестве наглядного пособия калькулятор - а как калькулятор выполняет сложение учебник не объясняет. С моей точки зрения это - тяжелейший порок, поскольку квалификация программиста определяется прежде всего пониманием философии, основ, концепций. Писать реально работающие программы, конечно, нужно с применением соответствующих инструментов. Писать вручную - анахронизм, часто выдающий дремучесть программиста. Но и владея распрекрасным инструментом всё равно нужно знать, как работает механизм, потому, что в какой-то момент времени может обнаружиться ошибка в самом инструменте, произойти несчастливое стечение обстоятельств и параметров, а тогда программист должен суметь, пользуясь своим общим знанием, отыскать то самое место, в котором возникает ошибка и исправить её.

(с) Михаил Безверхов, "Технология COM"

Всё, что может понадобиться

Недавно я начал преподавать программирование. На самом деле говоря "преподавать программирование" это я так шучу. Слишком уж громко и пафосно это звучит. На самом деле просто я решил поделиться своими знаниями с одним человеком.
Вначале я подумал:
- Черт возьми! Программирование настолько огромная и сложная область знания, что совершенно непонятно с чего начать. Как же быть? Может, быть стоит начинать с двоичной системы (и разных систем счисления), ведь это основа работы компьютера (есть сигнал/нет сигнала). Или, может быть нужно внимательно рассмотреть аппаратную часть, познакомиться с принципом работы процессора? А возможно это должен быть какой-то язык и его синтаксис, чтобы можно было сразу приводить примеры и учить базовые алгоритмы? А, может быть вообще взять какой-нибудь визуальный редактор вроде Delphi, так как с помощью его можно быстро создавать маленькие, но полностью функциональные приложения?

Отчаявшись я сделал самый простой выбор, и решил  начать с того с чего начинал я сам: с базового представлении об алгоритме и самых банальных блок-схем.
Через пару часов, когда мы разобрались как построить блок-схему, как представить задачу в виде последовательности действий и условий, как детализировать, я сказал:
- Пожалуй, это все, что может тебе пригодиться. На самом деле в этом и заключается все программирование и теперь у тебя есть все, что нужно.

И только на следующий день я понял, что в этом и был ответ на мой вопрос о том, что самое главное в танке в программировании. Ни синтаксис языка, ни понимание каких-то особенных вещей и технологий, ни двоичная система не имеют никакого значения, когда нет умения представить задачу и решение как алгоритм, как последовательность действий.
Хорошими друзьями алгоритма я бы назвал глубокое понимание парадигмы языка на котором пишешь и гибкий ум, позволяющий "догадываться" о новых вещах. Вот, пожалуй и все.

P.S.: Алгоритмы алгоритмами, но язык нам все-таки понадобится. И это будет C++ несмотря на то, что я сам его почти не знаю. Мы уже купили толстую книгу с названием "Базовый курс" и теперь будем учиться вместе.

О сложности C/C++

Когда-то я совсем-совсем не умел программировать и только играл в компьютерные игры. Но я знал, что игры на чем-то написаны, что существуют языки программирования. Я спрашивал: "На чем написана эта игра?" А мне отвечали: "На си!"
Какой же сложный этот C, раз на нем можно написать такую игру! - думал я.

Позже я стал писать программы на бейсике, паскале, немного познакомился с ассемблером для Z80 и освоил ворох разных технологий вроде программирования COM-порта или OpenGL, прочел книжку Питера Нортона о жестких дисках и получил первые деньги за программу. Примерно тогда же нам читали курс лекций по C и я думал:
"Все-таки C это очень сложно. Пожалуй, сложнее всего, что я знаю".

Шло время я, наконец, понял что такое "указатель", успел пожалеть о том, что почти не осталось конспектов с того курса лекций. Я стал 1С-программистом, перестал писать на других языках, снова начал писать на других языках, увлекся PHP и веб-разработкой, начал читать Дональда Кнута, освоил еще ворох новых технологий, поучаствовал и успешно угробил несколько стартапов, сменил несколько фирм, захватил власть в Изумрудном городе с помощью племени Марранов (извините, это не оттуда) наконец перестал воспринимать менеджера проекта как личного врага, а тестера как недочеловека, купил красный галстук и черный костюм... И установил Visual C++ Express Edition 2008 взамен привычной, но неизбежно устаревающей Delphi7. Я открыл редактор в который автоматически был загружен "Hello world" и, знаете что я подумал?
Какой же этот С все-таки сложный!

P.S.: Надеюсь это не последняя моя мысль о СИ и наша любовь еще впереди.

The Rise And Fall of Waterfall

Это чрезвычайно любопытно! Чрезвычайно!



Спасибо Максу Дорофееву

Где ваши гарантии?

На сайте IT Happens есть одна поучительная история о тупом завкафе и умном студенте. В ней есть одна интересная фраза, которая "как бы" говорит о том, насколько недалек завкаф и насколько умен студент.
Вот она: "C каких пор протокол TCP гарантирует доставку пакетов?"

Давайте разберемся. Честно ответьте на вопрос: а гарантирует ли TCP доставку пакетов? Все, кто ответил "да", станьте справа, те кто ответил "нет" (или "нет, но...") - слева.

Ребята слева, вы можете пока расходиться, с вами нам еще предстоит провести множество славных часов, ковыряясь в коде, играя в крокодила и контакт или просто за чашкой хорошего чая.

Ребята справа (те, кто ответил "да, гарантирует"), эта встреча у нас, увы, последняя. Возможно наши дороги еще пересекутся, но сегодня нам явно не по пути. Напоследок, давайте разберемся.

Я разделил наши "разбирательства" на три этапа:

Этап первый: философский.
Я не буду приводить сейчас общечеловеческих и философских соображений о том, что дом выстроенный на зыбком фундаменте может пошатываться, а один протокол базирующийся на другом протоколе не предоставляющем гарантий доставки (IP), сам не будет гарантировать ровным счетом ничего.

Этап второй: переводческий.
Будем прагматичны, обратимся к RFC.
В частности к RFC1122. Для начала я захотел понять, откуда же взялось выражение "гарантирует доставку" и произвел поиск по включению "guar". Итак, слово "guarantees" встречается в документе:

1. В разделе "1.1.3 Internet Protocol Suite" (1.1.3 Стек протоколов Internet) в описании Internet Layer, где говорится о том, что протокол IP не гарантирует доставки пакета.

2. В разделе "3.3.1.4 Dead Gateway Detection" (3.3.1.4 Обнаружение мертвых шлюзов), где говорится о том, что успешный пинг гарантирует то, что адресный интерфейс и сама машина включена, но не гарантирует того, что она будет выполнять роль шлюза.

3. В разделе "4.1.1 USER DATAGRAM PROTOCOL - UDP (INTRODUCTION)", где говорится что протокол UDP не гарантирует доставку дейтаграмм и практически предоставляет приложениям прямой доступ к протоколу IP.

На этом "гарантии" упомянутые в RFC заканчиваются. Т.е. мы понимаем, что в оригинальном документе нам никто ничего не гарантирует. Значит? Обратимся к переводу. Не уверен, существуют ли какие-то "праведные" переводы RFC (вроде Муравьевского перевода Толкиена или Маршаковского Бернса), но нам подойдет первый же выдаваемый Яндексом с сайта rfc.com.ru: RFC1122 на русском.

Поступим аналогичным образом, поищем включения "гаран". Слово "гарантированной" (и подобные), встречаются примерно в тех же местах, где и в английской версии плюс еще кое-где. Давайте посмотим эти отличающиеся моменты.

Первый раз мы сталкиваемся в том же разделе 1.1.3, но на один пункт раньше, на транспортном уровне:

TCP представляет собой основанный на соединениях (connection-oriented) транспортный сервис с гарантированной доставкой пакетов, обеспечивающий надежную доставку с сохранением порядка пакетов и управлением потоком данных.Протокол UDP не использует соединений (connectionless) и передает данные в виде дейтаграмм (datagram) без гарантии доставки.

Этот же абзац в английской версии выглядит так:

TCP is a reliable connection-oriented transport service that provides end-to-end reliability, resequencing, and flow control. UDP is a connectionless ("datagram") transport service.

Уважаемый Drop-bear и здравая логика буквально переводят это так:

TCP это надежная модель обмена данными от точки к точке с повторным упорядочиванием и управлением. UDP это модель обмена данными без установки соединения (дейтаграммами).

Заметьте, никаких гарантий.

Второе упоминание (про настройку параметров и их загрузку я опустил) мы встречаем в разделе 4.2.1 (Протокол управления передачей TCP - Введение):

Протокол управления передачей - TCP (Transmission Control Protocol) [TCP:1] представляет собой транспортный протокол стека Internet для работы с виртуальными соединениями. TCP обеспечивает гарантированную доставку с сохранением порядка для полнодуплексных потоков данных (октеты или байты).Протокол TCP используется теми приложениями, которым нужен ориентированный на соединения транспортный сервис с гарантией доставки (например, электронная почта SMTP, передача файлов по протоколу FTP, служба виртуальных терминалов Telnet); требования к таким протоколам прикладного уровня описаны в работе [INTRO:1].

Английский текст:

The Transmission Control Protocol TCP [TCP:1] is the primary virtual-circuit transport protocol for the Internet suite. TCP provides reliable, in-sequence delivery of a full-duplex stream of octets (8-bit bytes). TCP is used by those applications needing reliable, connection-oriented transport service, e.g., mail (SMTP), file transfer (FTP), and virtual terminal service (Telnet); requirements for these application-layer protocols are described in [INTRO:1].

Который можно было бы перевести как (опять спасибо John-1123 и Drop-bear):

Transmission Control Protocol TCP [TCP: 1] является основным виртуальным протоколом транспортной схемы для сети Интернет. TCP обеспечивает надежную, последовательную полнодуплексную доставку потока октетов (8-битный байт). TCP используется приложениями, нуждающимися в надежных способах доставки, ориентированных на соединения между клиентами, например, электронной почтой (SMTP), при передаче файлов (FTP), службы виртуального терминала (Telnet); требования к этим протоколам прикладного уровня описаны в [INTRO:1].

Снова никаких гарантий.

Можно предположить зачем же переводчик добавил эти мнимые гарантии. Возможно, он хотел подчеркнуть отличие TCP от UDP (а как следствие и от IP), а может решил обобщить слова "надежность", "контроль" и другие хорошие (и надежные) слова  в хорошее (и надежное) слово "гарантии".

"И что из этого?" - спросите вы.

То, что фразу "TCP обеспечивает гарантированную доставку" теперь знает каждый, не задумываясь о природе протоколов, воспринимая якобы гарантированную доставку за аксиому.

А из этого следует:

Этап третий: практический.

Если предыдущий этап не убедил вас в том, что TCP все-таки не гарантирует доставки, то давайте проведем эксперимент:
Откройте любое приложение использующее TCP и начните обмен данными (скачивание музыки, получение почты подойдет). TCP гарантирует доставку? Похоже, что да? А теперь вытащите кабель подключения к сети, выключите модем и отключите WiFi (или что у вас там?) Ну, как? Гарантии TCP все еще в силе? =)

Вот в этом-то и проблема. На самом деле при отправке данных нет никаких гарантий, что они будут доставлены и поэтому хороший программист обязательно предусматривает вариант, когда данные НЕ будут доставлены.

Т.е. просто написать TCPSocket.Send(*data); и ожидать, что все будет хорошо, строить дальнейший код исходя из посылки о том, что есть "гарантия доставки" в корне не верно.

Представляете, если бы для осуществления ремонта линии электропередач вы бы послали команду "отключить подачу ста тысяч вольт" по TCP и думая о гарантированной доставке сразу полезли бы на столб? Есть среди оставшихся хоть один, кто бы рискнул?

Друзья, читайте RFC в оригинале. Это действительно хороший совет.
(Да, перестаньте плеваться те, кто УЖЕ читают RFC в оригинале, я и сам знаю, что оно сложно переваривается и не менее сложно усваивается. Тем не менее это RFC)

Эпилог: правильные гарантии.

Что же на самом деле гарантирует протокол TCP? Об этом очень хорошо сказано в статье википедии о TCP/IP:

TCP — «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных. TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP.

Слово "гарантированный" (вначале) забрано  в кавычки и все остальное определение на редкость точно и лаконично.

И особенно вкусен конец абзаца, не удержусь и повторю его еще раз:

Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP.

Вот это - правильные гарантии.


Спасибо.

Спасибо всем, кто дочитал до конца. Возможно для опытных программистов моя заметка не была слишком уж полезна, поскольку так или иначе с практикой становится интуитивно понятно, что "любое чертово сетевое соединение нужно так или иначе непрерывно контролировать", а новичкам все это покажется бесполезным философствованием. Но я надеюсь, что все мы будем делать действительно хороший код и с каждым днем все лучше. Возможно не без помощи этого поста.

Всем счастливо, а умному студенту привет и удачно делать свои снежинки.

Кто такие программисты

Что более важно для программиста: в совершенстве владеть каким-либо языком программирования, знать все его тонкости и эффективно использовать инструменты, или не знать ни одного языка кроме простейшего алгоритмического и уметь решать задачи при помощи него?
Что вообще должен знать и уметь программист, чтобы называть себя таковым?
Кто они вообще, эти программисты?
Джоел Спольски считает, что он должен быть толковым и целеустремленным.

Нельзя не согласиться.