Ситуация: оформляешься в банке, а тебе говорят, что твой номер телефона уже в базе, но не принадлежит тебе. Значит тебе надо подтверждение, что номер теперь твой. Идёшь к оператору, а оператор не имеет формы для выдачи по месту требования. Значит нужно найти свой договор (некоторые его уже выкинули), пойти к нотариусу, заверить документ и принести в банк, чтоб твой номер отвязали от другого клиента.
Техника управления сложностью известна с древних времен: Divide et impera (разделяй и властвуй). Аналогия между построением доказательства и построением программы, пожалуй, просто поразительна. В обоих случаях даны отправные точки (аксиомы и существующая теория против примитивов и доступных библиотечных программ), в обоих случаях задана цель (доказанная теорема против желаемых результатов), в обоих случаях сложность преодолевается делением на части (леммы против подпрограмм и процедур).
Я полагаю, что гениальность программиста соответствует сложности решаемой задачи, а также полагаю, что он сумел добиться подходящего разделения задачи. Затем он продолжает действовать следующим образом:
* Он разрабатывает полные спецификации отдельных частей.
* Он убеждается, что проблема в целом решается при наличии в его распоряжении частей программы, удовлетворяющих этим спецификациям.
* Он разрабатывает отдельные части в соответствии со спецификациями, но при этом делает их максимально независимыми друг от друга и от окружения, в котором они будут использоваться.
Очевидно, что построение каждой такой отдельной части может снова оказаться сложной задачей, так что для данной части задачи потребуется дальнейшее разбиение.
Некоторые могут счесть описанный метод разбиения на части недостаточно прямолинейным и слишком извилистым путем достижения конечной цели. Мое собственное мнение я лучше всего могу выразить так: я твердо уверен, что царских дорог в математике нет, или, другими словами, что у меня очень маленькая голова, и я вынужден обходиться ей. Поэтому я рассматриваю технику разбиения на части как базовый прием человеческого мышления и считаю, что стоит попробовать создать условия, в которых она может быть наиболее плодотворно применена.
Предположение о том, что программист сделал подходящее разбиение, находит подтверждение в том, что становится возможным выполнить первые два этапа: спецификацию частей и проверку, что они совместно решают задачу. Здесь элегантность, точность, ясность и тщательное понимание задачи являются необходимыми предпосылками. Но в целом техника разбиения основывается на том, что обсуждалось значительно меньше, а именно на том, я назвал бы принципом невмешательства. На втором этапе подразумевается, что правильная работа целого может быть установлена путем рассмотрения только внешних спецификаций частей, без деталей их внутреннего строения. На третьем этапе принцип невмешательства всплывает снова; здесь подразумевается, что отдельные части могут быть поняты и построены независимо друг от друга.
Возможно, здесь уместно заметить, что если я правильно понял нынешнее отношение к проблеме определения языка, при несколько более формальном подходе состоятельность техники разбиения подвергается сомнению. Те, кто выдвигает возражения, аргументируют свою точку зрения следующим образом. Когда вы используете механизм, подобный описанному двухэтапному, во-первых, должны быть созданы спецификации, а во-вторых, описано, как все это работает. При этом вы вынуждены в лучшем случае сказать дважды одно и то же, но вероятнее всего, вы придете к противоречию. С точки зрения статистики, как ни грустно мне об этом говорить, последнее замечание достаточно серьезно. Единственный ясный путь к определению языка, возражают они, это просто определение механизмов, потому что все, что они будут делать, следует из этого. Мой вопрос: А как оно следует? мудро оставляют без ответа, и я боюсь, что это тонкое, но порой значительное различие между понятиями определено и известно сделают их работу интеллектуальным упражнением, которое ведет в тупик.
/Эдсгер Вайб Дейкстра. Программирование как вид человеческой деятельности. В переводе. Отрывок/
Но есть одна проблема. Все то, что делал наш разработчик, не масштабируется.
После этого читать статью не стал. Как бы главразраб вряд ли дурак и предусмотрел возможности для масштабирования. Просто раньше масштабировать было не нужно, а сейчас достаточно взять людей и «открыть кран» для потоков данных. Современная литература давно содержит фразы типа «распределённые системы», «высоконагруженные приложения», «создание микросервисов» и др. Суть статьи: высосали причину из пальца и уволили. Может даже дело в деньгах, т.к. главразраб не последний человек и посягает на кусок в бизнесе.
Блокировщики рекламы помогают обычному человеку оградить себя от засилия корпоративных монстров. Нужно рассмотреть обязательное внедрение на каждую показанную рекламу обязательной обратной связи с производителем, причем обратная связь обязана обеспечиваться за счет средств производителя. Таким образом через обязательную обратную связь в рекламе каждый сможет сообщить о том, что ему надоел/принёс пользу данный вид рекламы
Нельзя побороть самый мощный блокировщик — отказ от просмотра сайта в целом. Я готов отказаться от сайта с рекламой, даже если он очень полезен и просмотр его жизненно необходим. А вы?
Автор ясно дал понять в первом абзаце об Ubuntu. Сделать выводы далее достаточно легко. Создать программный маршрутизатор можно и на Linux. Но до сути статьи идёт явное указание на невозможность использовать Ubuntu и миграция, хотя ни слова (даже справедливости ради) о железе, идентификаторах моделей и производителей неких сенсоров и контроля за вентиляторами. Замечу, что некоторые драйвера можно позаимствовать из других дистрибутивов (например как для Broadcom)
Что? Разве? Да не может быть такого точного значения с различными причинно-следственными связями.
в силу широчайшего использования в России розеток без заземляющего контакта и, тем более, без подведённого к ним заземления, на корпусе компьютера постоянно присутствует переменное напряжение величиной ровно в половину сетевого, то есть 230/2 = 115 В.
MVC не единственный шаблон проектирования. Бесспорно, что нужно применять тот шаблон, который наилучшим образом подходит к проекту. Указанная в статье структура по большей части опирается на бизнес-логику проекта и выделение независимых частей в проекте. Такая структура позволила с лёгкостью переносить код, компоненты, целые каталоги между проектами без ущерба основному функционалу проектов. Обсуждение плюсов разработки по шаблону MVC достаточно хорошо описано в других статьях https://habr.com/search/?q=mvc
Я бы не сказал, что первый перевод утратил свою актуальность. Названия типов полей в формах те же. Вызов такой же. Рендеринг в шаблоне тот же. В чём новизна? wtforms не изменился.
Выводы: зачем нужен банк? Храните ваши денежки наличкой под матрасом. Целее будут.
Техника управления сложностью известна с древних времен: Divide et impera (разделяй и властвуй). Аналогия между построением доказательства и построением программы, пожалуй, просто поразительна. В обоих случаях даны отправные точки (аксиомы и существующая теория против примитивов и доступных библиотечных программ), в обоих случаях задана цель (доказанная теорема против желаемых результатов), в обоих случаях сложность преодолевается делением на части (леммы против подпрограмм и процедур).
Я полагаю, что гениальность программиста соответствует сложности решаемой задачи, а также полагаю, что он сумел добиться подходящего разделения задачи. Затем он продолжает действовать следующим образом:
* Он разрабатывает полные спецификации отдельных частей.
* Он убеждается, что проблема в целом решается при наличии в его распоряжении частей программы, удовлетворяющих этим спецификациям.
* Он разрабатывает отдельные части в соответствии со спецификациями, но при этом делает их максимально независимыми друг от друга и от окружения, в котором они будут использоваться.
Очевидно, что построение каждой такой отдельной части может снова оказаться сложной задачей, так что для данной части задачи потребуется дальнейшее разбиение.
Некоторые могут счесть описанный метод разбиения на части недостаточно прямолинейным и слишком извилистым путем достижения конечной цели. Мое собственное мнение я лучше всего могу выразить так: я твердо уверен, что царских дорог в математике нет, или, другими словами, что у меня очень маленькая голова, и я вынужден обходиться ей. Поэтому я рассматриваю технику разбиения на части как базовый прием человеческого мышления и считаю, что стоит попробовать создать условия, в которых она может быть наиболее плодотворно применена.
Предположение о том, что программист сделал подходящее разбиение, находит подтверждение в том, что становится возможным выполнить первые два этапа: спецификацию частей и проверку, что они совместно решают задачу. Здесь элегантность, точность, ясность и тщательное понимание задачи являются необходимыми предпосылками. Но в целом техника разбиения основывается на том, что обсуждалось значительно меньше, а именно на том, я назвал бы принципом невмешательства. На втором этапе подразумевается, что правильная работа целого может быть установлена путем рассмотрения только внешних спецификаций частей, без деталей их внутреннего строения. На третьем этапе принцип невмешательства всплывает снова; здесь подразумевается, что отдельные части могут быть поняты и построены независимо друг от друга.
Возможно, здесь уместно заметить, что если я правильно понял нынешнее отношение к проблеме определения языка, при несколько более формальном подходе состоятельность техники разбиения подвергается сомнению. Те, кто выдвигает возражения, аргументируют свою точку зрения следующим образом. Когда вы используете механизм, подобный описанному двухэтапному, во-первых, должны быть созданы спецификации, а во-вторых, описано, как все это работает. При этом вы вынуждены в лучшем случае сказать дважды одно и то же, но вероятнее всего, вы придете к противоречию. С точки зрения статистики, как ни грустно мне об этом говорить, последнее замечание достаточно серьезно. Единственный ясный путь к определению языка, возражают они, это просто определение механизмов, потому что все, что они будут делать, следует из этого. Мой вопрос: А как оно следует? мудро оставляют без ответа, и я боюсь, что это тонкое, но порой значительное различие между понятиями определено и известно сделают их работу интеллектуальным упражнением, которое ведет в тупик.
/Эдсгер Вайб Дейкстра. Программирование как вид человеческой деятельности. В переводе. Отрывок/
После этого читать статью не стал. Как бы главразраб вряд ли дурак и предусмотрел возможности для масштабирования. Просто раньше масштабировать было не нужно, а сейчас достаточно взять людей и «открыть кран» для потоков данных. Современная литература давно содержит фразы типа «распределённые системы», «высоконагруженные приложения», «создание микросервисов» и др. Суть статьи: высосали причину из пальца и уволили. Может даже дело в деньгах, т.к. главразраб не последний человек и посягает на кусок в бизнесе.
Агент Microsoft детектед