Глубина стека - всего 16 элементов? Тут же в рекурсии в любой момент времени уменьшается или n, или m - значит, в любой момент времени глубина стека не более n+m.
Такая задача может по времени обламываться, т.к. без кэширования результатов "дерево" получается очень широкое.
Конкретно для этой задаче - не проще сделать мэп с [m,n] -> value, и если в мэпе уже есть значение - возвращать его, а если нет - вызываться рекурсивно?
Грозоразрядник. Если к вашему дому подведена воздушная/наземная проводка, где-то (обычно в коробке снаружи) устанавливается грозоразрядник.
Наведённое (молнией) высокое напряжение в проводе или (для проводов с экраном) в экране, нужно разрядить на землю. При этом, разумеется, слышен щелчок разряда - который физически происходит куда ближе к вам, и вы его слышите почти одновременно с ударом молнии.
Я пару раз дежурил на ж.д. станциях в помещении дежурного по станции, где грозоразрядник (по-моему, на антенну поездной радиосвязи) был установлен в помещении внутри. Разряд внутри помещения и молния снаружи были почти синхронны, по крайней мере я разницы не заметил.
Скорее всего сойдут практически любые параметры. Начиная с определённого времени (гуглите LBA) диски перестали обращать внимание на параметры сектор/цилиндр/головка или что ещё там, и просто преобразовывало эти данные в линейный номер сектора.
Понятно, что IDE-конвертор CF-карт делает то же самое.
Т.е. достаточно подобрать такие параметры, чтобы размер диска был не больше размера карты.
Вообще-то есть такие компании. Делают ПО для прямого управления АЭС, железнодорожной автоматикой, авионикой, энергетикой, медицинским оборудованием. Но - ценник конский, работают медленно, свистелки и перделки не добавляют, к интернету подключать запрещают...
Вообще-то тот софт, который реально управляет системами, от которых зависит жизнь и здоровье людей - он как раз лицензированный, доказанный и чрезвычайно дорогой. И обновляется редко и с большим скрипом. А антивирус на такое в принципе не ставят - идиотов нет.
Всё, что упало сегодня - это сервисы, от которых ничего существенного не зависит.
Обратите внимание: обломались системы резервирования авиабилетов, но вот диспетчера связь с самолётами не потеряли, и самолёты экстренно не садились.
Ага. Молодые и горячие студенты годик поработают, и убегут куда-нибудь. А 50-летний разработчик под Турбо паскаль будет работать в этой конторе ещё лет 20.
Это всё-таки промышленность, а не вебка - тут не переписывают ПО каждые полгода из-за того, что модной стала другая технология.
Единственный 100% надёжный вариант защиты данных - это текущий лог изменений (например, в SQL-базу) перенаправлять через односторонний интерфейс (диод данных) в хранилище, которое никаких других связей с любыми сетями не имеет.
Самое забавное: вот такой промпт - это ведь не чёткое программирование, что можно - и что нельзя. По определению, нейросетка всегда может наплевать/игнорировать вот так заложенные ограничения. Т.е всё это - благие пожелания.
Ну например, выложив в Perforce бинарный файл (который не получиться смержить) вы сможете поставить ему тип "binary+l". Так как Perforce - система централизованная, после этого данный файл сможет редактировать только один человек за один раз. Соответственно, необходимости "сливать" конкурентные изменения - не будет.
Разумеется, скорее всего для git можно сколхозить что-то подобное. Или использовать отдельную систему "управления документацией" - но это, как надеюсь вы понимаете, набор из резиновых костылей.
Ещё раз - в git можно сделать всё. Но предназначен git для специфической модели разработки и специфических целей - как только вы пытаетесь его приспособить за пределы его исходной концепции - получается хреново.
Кстати, с этой точки зрения точно то же самое и в Perforce. Разрабатывать классический опенсоурсный продукт в Perforce - с получением патчей от неопределённого круга лиц, с разработчиками работающими независимо и самостоятельно - ну, больше всего похоже на мазохизм.
Perforce, например. Разумеется, изменения в бинарных файлах произвольного типа просмотреть/объединить сама система не может (точнее, может для ограниченного количества форматов, в основном картинки) - но если есть внешние средства - можно использовать их.
При этом, например, хранение проектной документации в том же Word/Autocad/Visio - запросто. Одна возможность хранить историю изменений бинарных файлов (и сами файлы) - это уже очень много.
Концепция гит: куча ветвей, сделанная программистами неизвестного качества, которые интегрирует в мастер-ветвь гуру продукта. В принципе, неплохо ложиться на процесс разработки в компании, которые постоянно нанимают джунов, немного их эксплуатируют и заменяют на новых. Плохо ложиться на организацию, которая нанимает опытных программистов, в случае, когда над отдельным подпродуктом работает 1-2 программиста максимум.
Распределённая разработка в гит не имеет особого смысла для корпоративного применения (скорее, опасна и неудобна для корпораций), но очень востребована в опенсоурсе.
Концепция гит: один репозитарий - один продукт. Ветвление репозитария целиком. Отлично подходит для опенсоурсной разработки, но в корпоративной среде возникают проблемы с зависимостями: продукты не являются независимыми. Т.е. крупные организации очень редко разрабатывают самодостаточный продукт, использующий только "чужие" библиотеки. Обычно он состоит их кучи библиотек и кучи экзешников, каждый из которых - отдельные подпродукты с собственным циклом выпуска релизов. В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях.
Гит может работать с бинарными файлами. Но - всегда криво и с косяками, с дополнительными нашлёпками.
В общем и целом, гит отлично подходит для компаний, чьи разработки не требуют системы управления конфигурации (сonfiguration management).
Т.е. если версия вашего продукта "живёт" полгода, релизы выпускаются часто-часто, долгосрочной поддержки нет, цена ошибки низкая - гит для этого отлично подходит.
Отлично гит подходит для веб-разработки, когда конечный продукт вы же и поддерживаете (т.е. предоставляете доступ к своему хостингу, но не даёте клиенту автономный хостинг).
Если ваш цикл технической поддержки продукта - десятилетия, если продукты сложные и взаимно-зависимые, если вам в любой момент может понадобиться точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик, и вы не можете заставить заказчика обновиться на текущую версию продукта, потому что обновление стоит очень больших ресурсов, если вместе с продуктом вы разрабатываете документацию в разных форматах (бинарных форматах редакторов и CADов) - гит не для вас.
С моей точки зрения, идеальной системой управления версиями была бы централизованная система с кластером серверов, похожая на Perforce или SVN, но с возможностью выделять/маркировать отдельные папки/подпродукты/каталоги так, чтобы слияние изменений можно было выполнять только на папку целиком.
По крайней мере, я пойму, что операционная система проверяет/ремонтирует файловые системы. Что она не зависла наглухо, что прогресс идёт, и можно оценить, что это займет ещё час/день/неделю.
Пользователи (и я тоже) в таких ситуациях довольно часто просто не дожидаются завершения процесса - и, например, перезагружают машину питанием. Что, естественно, проблему усугубляет.
Скорее всего у немцев тоже были проблемы сделать абсолютно взаимозаменяемые магазины. Это реально непростая задача.
А чем исходно было обоснованно требование о запрете сверления в стволе отверстия для газоотвода?
Ведь для этого должен был быть какой-то повод, обоснование, причина.
Глубина стека - всего 16 элементов? Тут же в рекурсии в любой момент времени уменьшается или n, или m - значит, в любой момент времени глубина стека не более n+m.
Такая задача может по времени обламываться, т.к. без кэширования результатов "дерево" получается очень широкое.
Конкретно для этой задаче - не проще сделать мэп с [m,n] -> value, и если в мэпе уже есть значение - возвращать его, а если нет - вызываться рекурсивно?
В вашем примере кандидат реально ответил на вопрос с очень высокой точностью навскидку.
Это означает, что у него хорошо развит здравый смысл.
Грозоразрядник. Если к вашему дому подведена воздушная/наземная проводка, где-то (обычно в коробке снаружи) устанавливается грозоразрядник.
Наведённое (молнией) высокое напряжение в проводе или (для проводов с экраном) в экране, нужно разрядить на землю. При этом, разумеется, слышен щелчок разряда - который физически происходит куда ближе к вам, и вы его слышите почти одновременно с ударом молнии.
Я пару раз дежурил на ж.д. станциях в помещении дежурного по станции, где грозоразрядник (по-моему, на антенну поездной радиосвязи) был установлен в помещении внутри. Разряд внутри помещения и молния снаружи были почти синхронны, по крайней мере я разницы не заметил.
В общем-то логично. Анонимности в сети и так нет, это иллюзия.
А так люди хотя бы будут это осознавать.
Скорее всего сойдут практически любые параметры. Начиная с определённого времени (гуглите LBA) диски перестали обращать внимание на параметры сектор/цилиндр/головка или что ещё там, и просто преобразовывало эти данные в линейный номер сектора.
Понятно, что IDE-конвертор CF-карт делает то же самое.
Т.е. достаточно подобрать такие параметры, чтобы размер диска был не больше размера карты.
Вообще-то есть такие компании. Делают ПО для прямого управления АЭС, железнодорожной автоматикой, авионикой, энергетикой, медицинским оборудованием. Но - ценник конский, работают медленно, свистелки и перделки не добавляют, к интернету подключать запрещают...
У них наверняка правильно, юридически корректно сформулированы условия лицензии на ПО. Полностью снимающее всю ответственность с фирмы-разработчика.
Вообще-то тот софт, который реально управляет системами, от которых зависит жизнь и здоровье людей - он как раз лицензированный, доказанный и чрезвычайно дорогой. И обновляется редко и с большим скрипом. А антивирус на такое в принципе не ставят - идиотов нет.
Всё, что упало сегодня - это сервисы, от которых ничего существенного не зависит.
Обратите внимание: обломались системы резервирования авиабилетов, но вот диспетчера связь с самолётами не потеряли, и самолёты экстренно не садились.
Нет такой страны, что не ведёт войну. Или ведёт, или является шестёркой того, кто воюет.
А если найдёшь такую - вот на неё и нападёт, например, США с гуманитарными бомбардировками. Или какой ИГИЛ подтащат, для удобства.
Для информации: в США собираются восстановить призыв, т.к. добровольцев чегой-то маловато.
Ага. Молодые и горячие студенты годик поработают, и убегут куда-нибудь. А 50-летний разработчик под Турбо паскаль будет работать в этой конторе ещё лет 20.
Это всё-таки промышленность, а не вебка - тут не переписывают ПО каждые полгода из-за того, что модной стала другая технология.
Единственный 100% надёжный вариант защиты данных - это текущий лог изменений (например, в SQL-базу) перенаправлять через односторонний интерфейс (диод данных) в хранилище, которое никаких других связей с любыми сетями не имеет.
Самое забавное: вот такой промпт - это ведь не чёткое программирование, что можно - и что нельзя. По определению, нейросетка всегда может наплевать/игнорировать вот так заложенные ограничения. Т.е всё это - благие пожелания.
Ну например, выложив в Perforce бинарный файл (который не получиться смержить) вы сможете поставить ему тип "binary+l". Так как Perforce - система централизованная, после этого данный файл сможет редактировать только один человек за один раз. Соответственно, необходимости "сливать" конкурентные изменения - не будет.
Разумеется, скорее всего для git можно сколхозить что-то подобное. Или использовать отдельную систему "управления документацией" - но это, как надеюсь вы понимаете, набор из резиновых костылей.
Ещё раз - в git можно сделать всё. Но предназначен git для специфической модели разработки и специфических целей - как только вы пытаетесь его приспособить за пределы его исходной концепции - получается хреново.
Кстати, с этой точки зрения точно то же самое и в Perforce. Разрабатывать классический опенсоурсный продукт в Perforce - с получением патчей от неопределённого круга лиц, с разработчиками работающими независимо и самостоятельно - ну, больше всего похоже на мазохизм.
Слышали и пробовали. Не работает в качестве системы управления конфигурацией.
Perforce, например. Разумеется, изменения в бинарных файлах произвольного типа просмотреть/объединить сама система не может (точнее, может для ограниченного количества форматов, в основном картинки) - но если есть внешние средства - можно использовать их.
При этом, например, хранение проектной документации в том же Word/Autocad/Visio - запросто. Одна возможность хранить историю изменений бинарных файлов (и сами файлы) - это уже очень много.
Концепция гит: куча ветвей, сделанная программистами неизвестного качества, которые интегрирует в мастер-ветвь гуру продукта. В принципе, неплохо ложиться на процесс разработки в компании, которые постоянно нанимают джунов, немного их эксплуатируют и заменяют на новых. Плохо ложиться на организацию, которая нанимает опытных программистов, в случае, когда над отдельным подпродуктом работает 1-2 программиста максимум.
Распределённая разработка в гит не имеет особого смысла для корпоративного применения (скорее, опасна и неудобна для корпораций), но очень востребована в опенсоурсе.
Концепция гит: один репозитарий - один продукт. Ветвление репозитария целиком. Отлично подходит для опенсоурсной разработки, но в корпоративной среде возникают проблемы с зависимостями: продукты не являются независимыми. Т.е. крупные организации очень редко разрабатывают самодостаточный продукт, использующий только "чужие" библиотеки. Обычно он состоит их кучи библиотек и кучи экзешников, каждый из которых - отдельные подпродукты с собственным циклом выпуска релизов. В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях.
Гит может работать с бинарными файлами. Но - всегда криво и с косяками, с дополнительными нашлёпками.
В общем и целом, гит отлично подходит для компаний, чьи разработки не требуют системы управления конфигурации (сonfiguration management).
Т.е. если версия вашего продукта "живёт" полгода, релизы выпускаются часто-часто, долгосрочной поддержки нет, цена ошибки низкая - гит для этого отлично подходит.
Отлично гит подходит для веб-разработки, когда конечный продукт вы же и поддерживаете (т.е. предоставляете доступ к своему хостингу, но не даёте клиенту автономный хостинг).
Если ваш цикл технической поддержки продукта - десятилетия, если продукты сложные и взаимно-зависимые, если вам в любой момент может понадобиться точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик, и вы не можете заставить заказчика обновиться на текущую версию продукта, потому что обновление стоит очень больших ресурсов, если вместе с продуктом вы разрабатываете документацию в разных форматах (бинарных форматах редакторов и CADов) - гит не для вас.
С моей точки зрения, идеальной системой управления версиями была бы централизованная система с кластером серверов, похожая на Perforce или SVN, но с возможностью выделять/маркировать отдельные папки/подпродукты/каталоги так, чтобы слияние изменений можно было выполнять только на папку целиком.
По крайней мере, я пойму, что операционная система проверяет/ремонтирует файловые системы. Что она не зависла наглухо, что прогресс идёт, и можно оценить, что это займет ещё час/день/неделю.
Пользователи (и я тоже) в таких ситуациях довольно часто просто не дожидаются завершения процесса - и, например, перезагружают машину питанием. Что, естественно, проблему усугубляет.