Есть альтернативный подход — разработка через рефакторинг. Т.е. вначале пишется прототип через «дамп потока», потом он анализируется и по его мотивам пишется уже нормальное приложение.
Особенно хорошо этот метод работает вместе с, как ни странно, TDD: после написания прототипа рефакторится его контракт вместе с написанием тестов (не обращая внимание на то, что некоторые тесты будут падать — не исправляя код прототипа), после чего по готовому контракту пишется нормальная программа.
С подбором гармоничных цветов не всё так просто, необходимо манипулировать ещё и яркостью-насыщенностью — года три назад как раз исследовал триадные наборы для дальтоников :)
Лекция — потому что это — сабскрипт того, что я рассказываю устно. Промышленное программирование — это противоположность программированию спортивному. Промышленное программирование — это вид прикладного программирования, результатом которого являются системы эксплуатируемые в реальном бизнесе. Отличительными особенностями промышленного программирования являются реализация бизнес-требований в согласованные сроки и долгая поддержка сданной в эксплуатацию системы.
Я пытаюсь вам объяснить, что вы вручную дополняете ряд до бесконечного и не отражаете это изменение в программе, после чего заявляете, что программа стала меньше :)
Ещё раз поясню: сама программа продолжает работать с исходными и конечными данными, она не знает, что о том, что можно произвести данное преобразование. По этому это знание необходимо добавить в программу.
Вы уверенны, что входных данных во втором случае стало больше? Именно этот момент я и просил вас пояснить и ответа не услышал.
Ещё раз — был конечный ряд. Мы берём делаем его инвариантное преобразование в бесконечный ряд + указатели откуда и доколе.
Но на вход программы всё ещё продолжает поступать конечный ряд.
Соответственно, в программу добавляется функционал по конвертации конечного ряда в бесконечный + добавляем новая структура данных «бесконечный ряд + указатели откуда и доколе».
Спасибо, учту ваши комментарии в следующей редакции лекции :)
Насчёт узости — задача такая: быстро напомнить джуниорам откуда вообще пошли языки и что стоит за ООП и языками, на которых они пишут (у нас пишут на Java и PHP).
Рассказывать системно и последовательно про историю программирования — это явно более 2х часов времени.
Следующие курсы — это уже тактика и стратегия написания промышленного кода. Максимум практики, минимум теории.
Ещё раз, сколько стоит преобразование из конечного ряда + граничные условия (это исходные даннфе) в бесконечный + исключения (это промежуточный формат данных)?
Вы придираетесь к словам: <? — > в третьей версии заменили на <? — ?>.
Суть от этого не изменилась: PHP изначально был создан как язык инъекций в язык HTML, что было отражено в его названии (FI == Form Interpreter).
Синтаксис обёртки инъекций специально подбирался с тем, чтобы он не конфликтовал с нативным языком HTML. Видите ли, если вы будете выводить JPEG файл с инъекциями PHP или код C, как в предыдущем примере, вы не будете застрахованны от конфликтов синтаксиса вставок с синтаксисом аутпута между вставок:
никто не гарантирует в JPEG файле отсутствие возникновения последовательности <? (с произвольным набором байтов после этого и падением интерпретатора на них), как и отсутствие в программе на C строки
printf("<?%s","death of interpreter");
Тоже самое, впрочем, относится и к обычному тексту, не оформленному согласно правилам HTML разметки (XML появился несколько позже первой версии PHP/FI). Для того, чтобы инъекции PHP не конфликтовали с прочим контентом файла, если он не написан на HTML, необходимо было специально учитывать наличие вставок на PHP.
Теперь с удовольствием выслушаю ваши возражения насчёт исторического предназначения конструкции <? — ?> и её практического применения в настоящее время.
Историческое предназначение конструкции — переключение интерпретатора PHP в режим pass through
В PHP первых (да и вторых) версий данной конструкции не было.
Это раз. Два — где-то написано, что HTML — это часть PHP? Я ещё раз процитирую фразу:
Другой пример — это PHP, который делится на HTML часть (все *ML языки являются декларативными), описывающий структуру данных для визуализации, и PHP часть, предназначенную для описания действий по заполнению структуры данными.
Особенно хорошо этот метод работает вместе с, как ни странно, TDD: после написания прототипа рефакторится его контракт вместе с написанием тестов (не обращая внимание на то, что некоторые тесты будут падать — не исправляя код прототипа), после чего по готовому контракту пишется нормальная программа.
habrahabr.ru/post/60426/
Ещё раз — был конечный ряд. Мы берём делаем его инвариантное преобразование в бесконечный ряд + указатели откуда и доколе.
Но на вход программы всё ещё продолжает поступать конечный ряд.
Соответственно, в программу добавляется функционал по конвертации конечного ряда в бесконечный + добавляем новая структура данных «бесконечный ряд + указатели откуда и доколе».
Я не вижу, где здесь уменьшение функционала?
Насчёт узости — задача такая: быстро напомнить джуниорам откуда вообще пошли языки и что стоит за ООП и языками, на которых они пишут (у нас пишут на Java и PHP).
Рассказывать системно и последовательно про историю программирования — это явно более 2х часов времени.
Следующие курсы — это уже тактика и стратегия написания промышленного кода. Максимум практики, минимум теории.
Суть от этого не изменилась: PHP изначально был создан как язык инъекций в язык HTML, что было отражено в его названии (FI == Form Interpreter).
Синтаксис обёртки инъекций специально подбирался с тем, чтобы он не конфликтовал с нативным языком HTML. Видите ли, если вы будете выводить JPEG файл с инъекциями PHP или код C, как в предыдущем примере, вы не будете застрахованны от конфликтов синтаксиса вставок с синтаксисом аутпута между вставок:
никто не гарантирует в JPEG файле отсутствие возникновения последовательности <? (с произвольным набором байтов после этого и падением интерпретатора на них), как и отсутствие в программе на C строки
Тоже самое, впрочем, относится и к обычному тексту, не оформленному согласно правилам HTML разметки (XML появился несколько позже первой версии PHP/FI). Для того, чтобы инъекции PHP не конфликтовали с прочим контентом файла, если он не написан на HTML, необходимо было специально учитывать наличие вставок на PHP.
Теперь с удовольствием выслушаю ваши возражения насчёт исторического предназначения конструкции <? — ?> и её практического применения в настоящее время.
Это раз. Два — где-то написано, что HTML — это часть PHP? Я ещё раз процитирую фразу: