Вложенные циклы ограниченно вкладываются. Два уровня вложения, три, четыре, число конечно и известно во время компиляции. Рекурсия раскручивается в теории бесконечно: её ограничивает лишь доступная память.
Суть - указатели на методы. Помогают вызывать методы в рантайме, например. Крайне полезны при разработке плагинов. Я иногда их использую при тестировании: создаю наследника тестируемого класса, переопределяю методы, заменяя логику вызовом делегата, если тот не null. В тестовых методах достаточно прописать необходимый метод делегату, чтоб тест спокойно проходил. В результате получается читаемый код.
Еще один пример - нужно вызвать метод в зависимости от выбранного значения в выпадающем списке. Можно сделать здоровеный case, а можно предзаполняемый словарик . Сам dropbox заполнить из словарика через DataSource, и методы вызывать через делегат.
Пусть modulo = остатку от деления n на 6. Пусть k= результат целочисленного деления n на 6. Короче, n = 6k + modulo.
IF modulo == 0: n = 6k = (6+6+6+...+6).
IF modulo == 1: n = 6k + 1 = 6(k-1) + 6 + 1 = 6(k-1) +7 = 6(k-1) + 5 + 2.
IF modul0 > 1: n = 6k+modulo.
Интересно. Если работать по первому варианту и пытаться добавить записи, то будут выскакивать ошибки. При этом, значения счетчика будут увеличиваться.
То есть, если я создал таблицу с ограничением {id, myInt}, id - счетчик, и добавляю
"insert into myTable values(12), (12)",
"insert into myTable values(7)",
в итоге добавится одна лишь запись (3,7).
Дмитрий Королёв: Тогда в чем проблема? Списки вопросов есть, на "официальные" ответы - плевать.
Возможно, Вам стоит поискать списки вопросов с краткими ответами (как "базовыми", так и "хитрыми"), что-то вроде шпаргалок. Только вот, детальное изучение подобного списка займет слишком много времени, да и ЦА (по факту, опытные разработчики, уже знающие особенности языка\платформы\фреймворка) слишком маленькая. Так что, вероятность успешного поиска и освоения довольно мала.
Дмитрий Королёв: Я в этом не уверен. Специфика тестов по программированию (да и по многим другим дисциплинам) - почти всегда на вопрос можно несколькими, казалось бы, противоположными способами. Например: "можно ли изменять readonly-поля в C#?" - "можно, если извратиться". Тесты составляются из расчета на стандартные ситуации, но вопрос, какую именно ситуацию считать стандартной - открыт. И это если автор не придумал ""вопрос с хитринкой".
По этой причине тесты я смотрю как список вопросов, ответы на которые стоит знать. Как их оценит система - в большинстве случаев не важно, важнее, как свои знания оценишь ты сам (разумеется, это не касается ЕГЭ, и тестов на том же upworks, если ты ищешь клиента).
Сергей Протько: Положим, мы пишем тесты. Надо много всего мокать. Мы начинаем рефакторинг. Тратим время на изменение системы. Поскольку рефакторить без тестов ненадежно и страшно - тратим много времени. Если повезет разбить рефакторируемый код на модули - еще ничего. Если же мы работаем с кодом, состоящим из спагетти - мы убьем кучу времени на фактическое переписывание модуля. Надо ли оно было - не факт.
"Необходимость покрывать тесты увеличивает потребность в соблюдении всяких принципов типа SOLID". Вы исходите из того, что соблюдение SOLID - благо. Если предположить, что SOLID не несут значимой пользы - мы вынуждены руководствоваться лишними принципами при разработке архитектуры\программы, что зло.
В целом, Ваш ответ достаточно точный. Не хватает лишь двух моментов: недостатков TDD и области применения методики. За фразу "(пусть и не на 100%, обычно хватает и 20% что бы можно было жить, все зависит от сроков жизни проекта и требуемого уровня надежности)" отдельный респект. Неофитам стоит высекать её в камне, чтоб запомнили.
otetz Спасибо за ссылку. К сожалению, под парсером я подразумеваю программу, которая просматривает диапазон страниц, выдирая с каждой из ник конкретные данные.
Эрвин Мартиросян: Не совсем полный. Заполняем пустую доску рекурсивно. Как только при добавлении доминошки сумма в одном из рядов\столбцов\диагоналей больше 6 - прекращаем исследование этой ветки.
Заранее составьте порядки, в которых будут укладываться доминошки (все вертикально, все горизонтально, и т.д.).
Перед заполнением очередной ячейки просчитайте суммы всех рядов\диагоналей\столбцов, на которые она повлияет. Проверяйте новые суммы лишь для этих рядов.
Не забудьте поворачивать доминошки в обе стороны.
Можно учитывать, что общая сумма цифр равна 6*4=24. Позволит быстро исключать доминошки из перебора. Выберите доминошки с минимальными весами. Полагаю, вариантов будет очень мало. :)
Евгений Елчев: Размеры файлов для данных машин выделяются? Объемы записей?
В принципе, у Вас уже есть костыльное решение: написать скрипт, который будет раз в n минут открывать этот файл в блокноте, и тут же процесс блокнота закрывать (плюс закинуть скрипт в автозагрузку).
"они утверждают, что проблема не в софте, а в системе" - на основании чего они делают такое заявление? Пока причина проблемы не выяснена, оно не может быть истинным.
Я уточню сценарий.
1. Запускается сервер. Что-то пишет в клиентский файл (на той же машине, что и сервер).
2. Запускается клиент. Подсоединяется к клиентскому файлу через сетевой диск, читает данные.
3. Сервер каждую секунду ищет обновления. Если нашел - дозаписывает их в файл.
4. Что именно делает клиент? Каждую секунду пытается считать новую строку? Как именно определяется, что файл доступен, а клиент не видит новые данные? Возможна ли ситуация, когда новые данные пришли, клиент их не прочитал, и без выключения клиента можно открыть файл в блокноте и увидеть новые данные?
Евгений Елчев: Точно! Потери пакетов! Столкнулся с подобным разик, когда в нашей транспортной проге начали отваливаться узлы. Клиенты начали отваливаться с ростом числа соединений и нагрузки. Проблема была в том, что отклик от сервера шел дольше разрешенного времени.
Железно помогали перезапуск клиентов\сервера и снижение максимального размера передаваемых файлов.
Евгений Елчев: Вы, случайно, не в корпорации зла работаете (был подобный пост на Хабре)? Если серьезно, 3-5% машин от 5000 - это 200 штук. Проблема (как я понял) возникает регулярно, есть стабильно косячные машины. Итого у Вас воспроизводимый баг в ПО. Найдите способ обратиться к разработчикам. Аргумент "менять архитектуру" не используйте - вместо этого попросите добавить логирование в прогу. Логирование каждой строчки (возможно) поможет выявить багу и понять причины её возникновения.
Итого, вы должны убедить свое начальство, что в софте неизвестная хня, из-за которой не работают 200 компов. В идеале было устроить подобный баг начальнику, но, полагаю, Вы на это не пойдете. Для того, чтобы эта хня стала известной (и решаемой), нужно попросить отдел разработки "написать 10 строчек". 10, Карл! Не всю систему переделывать. Тут стоит заметить, что данный случай как входит в категорию "поддержка" системы, то есть, отдел разработки как раз и должен заниматься подобными ситуациями.
