Чистый Си очень прост. И глядя на код довольно легко понять, во что примерно он будет развернут.
Ну, это как писать :)
Особенно, с учётом возможностей препроцессора. Реально, на практике астречается много "заумно эффективного" кода, особенно, в программировании микроконтроллеров
Замечу, что высшая математика вполне применима в инженерных дисциплинах, например концепция комплексных чисел сильно облегчает расчёты в электротехнике.
Я охотно использую python для быстрого прототипирования сервисов и систем, но когда речь заходит о продакшен-версиях, многое переписывается на плюсы именно из-за выигрыша в быстродействии и памяти. В итоге, получаем продукт, где верхнеуровневые грабли, в целом, пойманы и ликвидированы, а производительность в разы выше, чем в прототипе.
Что до С в С++, то "портабельный ассемблер" часто удобен, просто требует, как и любой инструмент, грамотного обращения. Например, аккуратных оберток для вызова из плюсов.
Так это не препятствие для подготовленной службы поддержки иностранной разведки. Сначала на собесы ходят кандидаты, задача которых - собрать типовые задания и понять приоритеты. Потом целевой шпион просто прокачивается на эти кейсы :) Но, на самом деле, проверки СБ - совсем другая история.
А вообще, "расколоть" товарища, который не сам написал код, на очном собеседовании как нефиг делать совсем несложно.
З.Ы. у вас тестовое на какую позицию в плаане уровня джун миддл синьор?
Ну, в последний раз я искал миддла с желанием/умением разбираться в незнакомых технологиях. Поэтому задачки были в стиле "REDIS знаете? Нет? Отлично, вот вам задача и три дня срока, потом снова встречаемся".
IMHO, главная задача собеседования - не найти спеца, который за 15 минут выдаст оптимальное решение, а понять, как этот специалист думает. Покрыть тестами всю область компетенции кандидата всё равно не удастся, да и само собеседование для многих - стресс, при котором показать свой максимум нереально.
Я обычно даю задачку на дом с условием на интервью подробно рассказать как именно работает решение и какие ещё варианты возможны. Ну и потрепаться на тему. Т.е. тестовое задание - не фильтр, а затравка для разговора.
У нас это только началось, а Time4VPS ещё в 2022-м написал: "Ребята, у нас охрененно подорожало электричество, и мы поднимаем цены на 50%, без обид" :)
"Со скриптами" ли, "без скриптов" ли, всё равно выполняются тесты, для которых кто-то должен придумать и логику, и исходные данные, и эталонные результаты. Собственно, именно в этом и состоит бОльшая часть автоматизации тестирования.
Плюсы это очень нишевая вещь, когда ты точно знаешь зачем тебе такой спец
Плюсы у нас появились ровно в тот момент, когда стали понятны требования по нагрузке и задержкам. Прототипирование выглядело совсем иначе. Что касается ноды, то в текущем основном проекте она оправдана в силу несложного, в общем-то, бэка веб-интерфейса. В команду набирали изначально "широких" спецов с 2-3 языками, ибо проект в 2019-м был стартапный и шёл "от R&D", многое придумывалось и менялось по ходу исследований.
В целом, по моему опыту, проработка структур данных от базы во многих случаях оказывается хоть более затратным, но и более эффективным подходом, если, конечно, вы не добавляете в системе по 3 новых класса в день. Но тут всё зависит от задач и жизненного цикла системы.
Стойкость системы к взлому дожна коррелировать с ценностью хранимой там информации. Грубо говоря, нет смысла бороться bruteforce-взломом паролей на асиках, если защищается набор картинок с котиками, стянутый из интернета.
Для банка двухфактор - маcт хэв, а если сделать двухфакторную авторизацию на блог-платофрме, будет отток пользователей в сторону сервисов, где всё попроще.
Для обычных сайтов с паролями вообще лучше не связываться. Для них это сложно. Делать авторизацию через Гугл, Яндекс, Сбер и далее по вкусу. Надежно и просто.
И, главное, перекладывает вопрос защиты паролей (и возможных манипуляций, включая действия органов власти) с вас на Гугл, Яндекс, Сбер и далее по вкусу :)
Time-to-market, конечно, суровая реальность современного бизнеса, но я всегда был сторонником закладывания правильной основы на этепе раннего дизайна, потом отыгрывать ошибки очень дорого. У меня есть пара долгоживущих проектов, которые очень тянет переписать полностью, так как за время их жизни стало понятно, что надо было делать "не так".
Архитектура данных - важная часть общей архитектуры, требующая детальной проработки, а не "мы сейчас по-быстрому накидаем через ORM". Но, возможно, это профессиональная деформация, растущая из пачки сертификатов DB Admin/Architect :)
А можно вас спросить о вашем основном стеке технологий? Просто любопытно. Возможно он тоже служит своего рода призмой восприятия.
Основной стек во времена работы в "тяжёлом энтерпрайзе" - Oracle (как RDBMS и Data Integrator, так и прикладные продукты - CBRM, OFA, EBS, Siebel и много другого), TIBCO BW, IBM WebSphere, DB2, Postgres, Neo4j, J2EE, Apache Camel, разные MOM-ы. Там я работал в качестве архитектора интеграции всего энтерпрайзного зоопарка и ряда своих компонентов. Область бизнеса - TELCO, авиация, аналитика разного рода.
Сейчас занимаюсь системами массового обслуживания, в которых основной абоонент - не человек, а устройства (электронные ценники, умные вещи). Текущий стек - Postgres, Redis, C/C++, NodeJS и Angular (для web-интерфейсов с относительно небольшим количеством пользователей-людей). Концепция федеративной реляционной БД на уровне ядра и оперативной NoSQL на уровне middleware тут работает "на ура", а микросервисы с собственными БД избыточны. В то же время, поддерживается модульность API, а изменчивость и согласованность обеспечивается через централизованное управление метаданными.
Чистый Си очень прост. И глядя на код довольно легко понять, во что примерно он будет развернут.Ну, это как писать :)
Особенно, с учётом возможностей препроцессора. Реально, на практике астречается много "заумно эффективного" кода, особенно, в программировании микроконтроллеров
Замечу, что высшая математика вполне применима в инженерных дисциплинах, например концепция комплексных чисел сильно облегчает расчёты в электротехнике.
Каждому овощу - свой фрукт :)
Я охотно использую python для быстрого прототипирования сервисов и систем, но когда речь заходит о продакшен-версиях, многое переписывается на плюсы именно из-за выигрыша в быстродействии и памяти. В итоге, получаем продукт, где верхнеуровневые грабли, в целом, пойманы и ликвидированы, а производительность в разы выше, чем в прототипе.
Что до С в С++, то "портабельный ассемблер" часто удобен, просто требует, как и любой инструмент, грамотного обращения. Например, аккуратных оберток для вызова из плюсов.
LOL, мне как-то за технические комментарии в совершено техническом же топике прилетело два минуса с пометками "политика" и "личная неприязнь" :)))
"Я устал, я ухожу" ?
Можно было бы это сделать чуть менее по-хамски.
Линусу, говорящему об исторической памяти, тогда было бы логично выгнать из мейнтейнеров всех шведов, раз уж на то пошло :)
Так это не препятствие для подготовленной службы поддержки иностранной разведки. Сначала на собесы ходят кандидаты, задача которых - собрать типовые задания и понять приоритеты. Потом целевой шпион просто прокачивается на эти кейсы :)
Но, на самом деле, проверки СБ - совсем другая история.
А вообще, "расколоть" товарища, который не сам написал код, на очном собеседовании
как нефиг делатьсовсем несложно.Ну, в последний раз я искал миддла с желанием/умением разбираться в незнакомых технологиях. Поэтому задачки были в стиле "REDIS знаете? Нет? Отлично, вот вам задача и три дня срока, потом снова встречаемся".
В питоне f-строки появились из PEP498, это 2014-2015 год. Template strings в JS - ES6, это тоже 2015-й. Идеи витают в воздухе :)
f-строки оказались настолько хороши, что их близкий аналог включили в C++ 20 :)
IMHO, это не очень разумное решение, повышающее вероятность ошибок. Но Гвидо виднее :)
IMHO, главная задача собеседования - не найти спеца, который за 15 минут выдаст оптимальное решение, а понять, как этот специалист думает. Покрыть тестами всю область компетенции кандидата всё равно не удастся, да и само собеседование для многих - стресс, при котором показать свой максимум нереально.
Я обычно даю задачку на дом с условием на интервью подробно рассказать как именно работает решение и какие ещё варианты возможны. Ну и потрепаться на тему. Т.е. тестовое задание - не фильтр, а затравка для разговора.
Да кто ж его знает... :)
Но ценник подняли, факт.
Не ушёл, но сократил количество серверов.
У нас это только началось, а Time4VPS ещё в 2022-м написал: "Ребята, у нас охрененно подорожало электричество, и мы поднимаем цены на 50%, без обид" :)
Там, правда, списание помесячное.
"Со скриптами" ли, "без скриптов" ли, всё равно выполняются тесты, для которых кто-то должен придумать и логику, и исходные данные, и эталонные результаты. Собственно, именно в этом и состоит бОльшая часть автоматизации тестирования.
"Специалисты без глубоких знаний" - это пять :)
Плюсы у нас появились ровно в тот момент, когда стали понятны требования по нагрузке и задержкам. Прототипирование выглядело совсем иначе. Что касается ноды, то в текущем основном проекте она оправдана в силу несложного, в общем-то, бэка веб-интерфейса.
В команду набирали изначально "широких" спецов с 2-3 языками, ибо проект в 2019-м был стартапный и шёл "от R&D", многое придумывалось и менялось по ходу исследований.
В целом, по моему опыту, проработка структур данных от базы во многих случаях оказывается хоть более затратным, но и более эффективным подходом, если, конечно, вы не добавляете в системе по 3 новых класса в день. Но тут всё зависит от задач и жизненного цикла системы.
Стойкость системы к взлому дожна коррелировать с ценностью хранимой там информации. Грубо говоря, нет смысла бороться bruteforce-взломом паролей на асиках, если защищается набор картинок с котиками, стянутый из интернета.
Для банка двухфактор - маcт хэв, а если сделать двухфакторную авторизацию на блог-платофрме, будет отток пользователей в сторону сервисов, где всё попроще.
И, главное, перекладывает вопрос защиты паролей (и возможных манипуляций, включая действия органов власти) с вас на Гугл, Яндекс, Сбер и далее по вкусу :)
Time-to-market, конечно, суровая реальность современного бизнеса, но я всегда был сторонником закладывания правильной основы на этепе раннего дизайна, потом отыгрывать ошибки очень дорого. У меня есть пара долгоживущих проектов, которые очень тянет переписать полностью, так как за время их жизни стало понятно, что надо было делать "не так".
Архитектура данных - важная часть общей архитектуры, требующая детальной проработки, а не "мы сейчас по-быстрому накидаем через ORM". Но, возможно, это профессиональная деформация, растущая из пачки сертификатов DB Admin/Architect :)
Основной стек во времена работы в "тяжёлом энтерпрайзе" - Oracle (как RDBMS и Data Integrator, так и прикладные продукты - CBRM, OFA, EBS, Siebel и много другого), TIBCO BW, IBM WebSphere, DB2, Postgres, Neo4j, J2EE, Apache Camel, разные MOM-ы. Там я работал в качестве архитектора интеграции всего энтерпрайзного зоопарка и ряда своих компонентов. Область бизнеса - TELCO, авиация, аналитика разного рода.
Сейчас занимаюсь системами массового обслуживания, в которых основной абоонент - не человек, а устройства (электронные ценники, умные вещи). Текущий стек - Postgres, Redis, C/C++, NodeJS и Angular (для web-интерфейсов с относительно небольшим количеством пользователей-людей). Концепция федеративной реляционной БД на уровне ядра и оперативной NoSQL на уровне middleware тут работает "на ура", а микросервисы с собственными БД избыточны. В то же время, поддерживается модульность API, а изменчивость и согласованность обеспечивается через централизованное управление метаданными.