Глубина стека - всего 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, но с возможностью выделять/маркировать отдельные папки/подпродукты/каталоги так, чтобы слияние изменений можно было выполнять только на папку целиком.
По крайней мере, я пойму, что операционная система проверяет/ремонтирует файловые системы. Что она не зависла наглухо, что прогресс идёт, и можно оценить, что это займет ещё час/день/неделю.
Пользователи (и я тоже) в таких ситуациях довольно часто просто не дожидаются завершения процесса - и, например, перезагружают машину питанием. Что, естественно, проблему усугубляет.
Фигня!
Американские астронавты уже были на Луне, и бегали, и прыгали - и никакие "роборуки" им были не нужны.
Более того, эти крутые парни даже не горбились под тяжестью системы жизнеобеспечения на спине, полностью игнорируя необходимость поддерживать проекцию центра тяжести внутри периметра ступней.
Так что бессмысленную задачу решает, не нужно этого на Луне.