что тестирование не гарантирует правильность программы и вообще не является инструментом разработки
По большей части с вами согласен. В том числе поэтому считаю статическую типизацию (например) куда более важным инструментом, чем тесты. Те же модульные тесты нужны прежде всего чтобы: а) дать самодокументацию в виде каких-то кейсов, чтобы на ревью или при рефакторинге читающий не спрашивал "а вот это будет работать?", "а вот такой кейс предусмотрели?". Все ответы уже заготовлены в виде тестов, а если что-то пропущено - то лучше в виде очередного теста и добавить. Это по сути одна из самых лучших форм документации - никогда не устаревает, в отличие от просто рукописного текста. б) "заткнуть" какие-то краевые ситуации, которые не может покрыть статическая типизация. Обычно если в языке с типизацией не очень, тестов приходится писать намного больше. И с другой стороны, если типизация очень сильная, то язык программирования превращается в язык доказательства теорем, и в таком языке модульные тесты и не нужны, потому что если программа компилируется - скорее всего она корректна.
Я скорее говорил о том, что никто не будет выводить в прод написанный за полчаса алгоритм или структуру данных без должного тестирования, а тестирование отдельных алгоритмов это в 99% случаев именно unit-тестирование.
В-третьих, есть испытательный срок, специально придуманный для отсева некомпетентных сотрудников.
Полагаю, этот механизм сейчас работает плохо из-за высокой доли вкатунов и откровенных самозванцев. Ну т.е. человек проходит фильтр, и сразу приносит компании минус 300-500к. А лишние деньги у всех закончились.
в js префиксный плюс, это устоявшаяся идиома для конвертации в number, кстати, можно и про неё поговорить
Не нужно про неё говорить. Её нужно оставить для JS-квестов типа "посчитайте среднее по массиву за 8 символов" и в таком духе. В реальном коде абсолютно нечитаемая магия, особенно если JS/TS для вас - очередной-язык-на-котором-приходится-прогать, а не мечта всей жизни.
Т.е. в реальной жизни задача, на которую на собесе выделяется полчаса может решатся и сутки-двое и бизнес это вполне устроит.
Вот только вчера об этом говорили с коллегами. Что куда важнее написать тесты вдоль и поперёк, особенно если это какой-то новый алгоритм (а зачем повторно реализовывать существующие?).
Мне вообще непонятно, каким образом алгоритмические, а точнее спортивно-олимпиадные задачки заехали в большинство собесов. У вас ещё более-менее адекватная задача, а зачем красно-чёрные деревья реализовывать на листке бумаги, я откровенно не понимаю.
А обычный сеньор, который оказывается звездой на letitcode вызывает вопросы. Когда он нашёл время на все эти задачки?
А на этот вопрос вы сами себе отвечаете:
О! А я её на собесе яндекса решал
Захочешь в Яндекс — и не так, простите, задницу рвать начнёшь. Добро пожаловать в чеболизацию по-русски. Я честно пытался найти ДРУГИЕ причины, но мне кажется пора перестать делать вид, будто они есть. Причина одна и стара как мир: если у тебя столько бабла, что люди стоят в очереди чтобы хоть как-то прильнуть к нему, то ты можешь делать что хочешь. Это касается как людей, так и компаний.
Мы вот рады, когда кандидат понимает, как работает flow-sensitive typing в TS, хотя бы просто на конкретных примерах. И то редко такие встречаются.
Люди будут видеть примеры и изучать по ним, как работает ваш инструмент. Именно так и учатся люди!
Не все и не всегда. Например, мой друг терпеть не может, когда обучение идёт через примеры и по паттернам. У него сугубо структурный тип мышления, и ему нужна эта концептуальная структура, а не готовые примеры, которые можно менять. Я в принципе и сам такой же.
Сейчас я своим коллегам читаю лекции по Git. И вот что любопытно: на подготовку этих лекций меня сподвигло то, что я пришёл к выводам, абсолютно противоположным выводам в статье. Интернеты забиты примерами и быстрыми туториалами по Git, а вот толкового курса о том, как действительно он работает, так вот быстро и не найдёшь. Потому что большинство так и поступает: это же не язык программирования, а просто вспомогательный инструмент, я быстренько разберусь как там выполнять основные команды, а если начнутся проблемы, то лид разберётся, ему же больше платят. Поэтому в своих лекциях я как бы изобретаю Git заново со своими слушателями, чтобы объяснить те весьма простые концепции, на которых он построен, а не зубрить хаотичный CLI Git-а.
Если современная разработка много где превратилась в потогонку вида «в прод нужно было ещё вчера», и все занимаются stackoverflow-oriented/ChatGPT-oriented programming, то это скорее проблема менеждмента, а может даже и экономики/рынка.
Нет! Нужно назвать его функцией!
А вот это хороший совет. Только есть другая проблема: этот понятийный аппарат сначала нужно как-то получить. Тут мы и вспоминаем, зачем же на самом деле нужно полноценное образование — чтобы понимать людей, и чтобы тебя понимали.
Избегайте перегрузки концепциями
Ну тут автор изобрёл бритву Оккама, нечего добавить.
и даже боссы часто бывают друзьями - ну не такими прям что пиво пить идти вечером, но вполне себе друзьями, могут потом годами звать на всякие мероприятия и чисто в офисе за НГ тяпнуть коньячку
Мне кажется тут более уместен термин «приятели», в том числе в случае пива вечером. Друг это тот, кто займёт вам на три месяца платежей по ипотеке, пока вы меняете работу.
Многие скажут, что это вкусовщина, но мне кажется нет смысла индексный хедер класть внутрь header namespace (т.е. внутрь поддиректории). Хочется подключать как #include <libnumerixpp.hpp> ну или #include <libnumerixpp/all.hpp>, но не #include <libnumerixpp/libnumerixpp.hpp>.
И кстати да, стандартные и библиотечные инклуды должны использовать угловые скобки #include <>, т.к. кавычки на большинстве компиляторов подразумевают поиск сначала в директории проекта, а инклуд с угловыми скобками ищет только по дирам из списка include paths. Из этого кстати следует, что в публичных хедерах могут быть только инклуды с угловыми скобками, а инклуды с кавычками могут быть только в приватных хедерах и файлах реализации.
Спасибо за статью! Dangerous Dave in the Haunted Mansion заигран до дыр. На самом деле приятно почитать реальную историю. В 1997-1998 году, когда играл в Дейва, было совершенно непонятно, что это за имена на заставке, что за Gamer's Edge, что за Ромеро. И узнать не было никакой возможности - игру дал друг знакомого друга, который откуда-то её привёз (или скачал с BBS-ки).
Пока одни пытались хайпануть на блокчейне и идее distributed ledger, Valve просто зарабатывала на коммиссиях. Как мы видим, большинству плевать на то, что БД с записями о владении виртуальными предметами централизована - главное чтобы сохранялась ценность предметов.
просто не имеет чаще всего достаточно времени и мотивации что-бы надрачивать этот литкод
У меня есть семья, я уже около 14 лет не живу за счёт родителей, но и семья и родители перестали меня видеть дома т.к. я торчу на работе по 12 часов. Надо бы эту работу поменять, но без надрочки литкод/codewars ничего толкового не найдёшь, эти самые «фильтры» тупо тебя не пропустят (особенно если пытаться поменять техстек, как пытаюсь сделать я). Работать вместо 12 часов положенные трудовым договором 8 часов с риском быть уволенным за «недостаточную производительность» (с), НО оставшиеся 4 часа (а лучше - 2 часа) потратить на литкод, готовясь в любой момент «хлопнуть дверью» - очень хорошая мотивация.
Вы говорите про какую-то идеальную ситуацию, когда человек спец в суперпопулярном стеке, этот стек ему самому нравится, и 40 компаний готовы взять такого человека к себе, надо лишь как-то пройти отбор. Это далеко не всегда так. Бывает когда хочется поменять специализацию (сразу +50 к недоверию соискателю - а чего это ты на бэк захотел?), бывает когда город проживания - не Москва и компаний не так много, а удалёнка - 100% не вариант для вас.
Я, например, отказываю тем у кого есть литкод секция.
И я, который считает, что ему придётся "набить" себе литкод-очков для прохождения этих самых фильтров.
То есть это такая бесконечная попытка обмануть друг друга - в одних компаниях говорят "Ну и как ты готовился к собесу, если даже литкод не порешал? Несерьёзно ты относишься к нашей вакансии.." (в лицо вам это не скажут, это будет реализовано через "алгоритмический" этап собеса, где вы за 90 секунд не успеете написать балансировку красно-чёрного дерева), а у вас - "А зачем тебе литкод решать, если ты и так крутой спец? Подозрительно...".
Можно конечно решать литкод, но не показывать в резюме - это несколько контринтуитивный вывод, надо сказать.
Вообще не понимаю, как стриминговый сервис может заменить локальную коллекцию музыки. События последних лет напоминают нам, что музыка на стримингах лишь временно сдаётся вам в аренду. Все ваши подборки и плейлисты могут запросто стать недоступными из-за того, что какие-то важные дяди в костюмах разошлись во мнениях по вопросам авторских прав, или вообще по политическим соображениям. iTunes похоже скоро умрёт окончательно, и это весьма печально. Хорошо что есть Bandcamp, спаси его и сохрани.
Это, разумеется, касается не только музыки, но и фильмов, и книг. Да и вообще любых ваших данных, которые вам не принадлежат и хранятся не у вас. Просто одно дело - история поездок в такси или покупок в магазине (лучше бы её вообще не было), а другое - любимые треки.
Стоимость гигабайта сейчас настолько упала, что всем по карману локально хранить всю их коллекцию в lossless-кодировании ещё и с регулярными бэкапами. Вопрос только в том, что всем лень этим заниматься, ну и в дорогу взять сложнее (нужно что-то куда-то там копировать/синхронизировать и т.д.).
Вот искать новую музыку на стримингах - это другое дело, это действительно удобно.
Люто плюсую. Far никогда не обманет, не запустит случайно никакого кода, просто покажет что внутри файла. А с Проводником на чужие флешки ходить как-то стрёмно. И даже если речь не идёт о малвари - куда быстрее глянуть Far-ом, что там за файл и что от него ожидать.
С ним вообще вся файловая система как на ладони. Адекватные дефолты "для ойтишнека" - не нужно настраивать показ расширений файлов, скрытых файлов и вот это вот всё что делается каждый раз на свежем профиле в Винде. Впрочем, это наверное актуально для любого приличного файлового менеджера, а вот "консльность" и быстрый просмотр - кмк, киллер-фичи.
Кажется никто не упомянул в комментариях интересный и важный юзкейс для Far - работа по SSH на виндовых машинах. С учётом того, что OpenSSH теперь есть в поставке Винды, то консольность файлового менеджера выглядит как киллер-фича.
Ну и второй огромный плюс, лично для меня - быстрый просмотр/редакторование по F3/F4. РЕАЛЬНО быстрый, никакой, даже самый лёгкий редактор так быстро не запустится. А для меня часто очень важно знать, что "внутри" файлов, и быстро по ним переходить. Не встречал HEX-редакторов, где это было бы так же удобно и быстро (потому что по сути нужен файловый менеджер и HEX-просмотровщик/редактор в одном флаконе).
а вот для винды сама концепция такого доступа к сожалению не прижилась
А вот я обнадёжу вас, очень даже прижилась, с тех пор как в Винде появился OpenSSH (что клиент, что сервер). Теперь на виндовые билд-машины в 97% случаю захожу по SSH, только если какая-то странная авария - тогда уже через SPICE или ещё какой гуёвый протокол.
Ну а если по SSH - то что, если не FAR, не так ли?
Как раз два года опыта с момента релиза классики!
Что вы имеете в виду? В одном случае это бинраный оператор, в другом - унарный.
По большей части с вами согласен. В том числе поэтому считаю статическую типизацию (например) куда более важным инструментом, чем тесты. Те же модульные тесты нужны прежде всего чтобы:
а) дать самодокументацию в виде каких-то кейсов, чтобы на ревью или при рефакторинге читающий не спрашивал "а вот это будет работать?", "а вот такой кейс предусмотрели?". Все ответы уже заготовлены в виде тестов, а если что-то пропущено - то лучше в виде очередного теста и добавить. Это по сути одна из самых лучших форм документации - никогда не устаревает, в отличие от просто рукописного текста.
б) "заткнуть" какие-то краевые ситуации, которые не может покрыть статическая типизация. Обычно если в языке с типизацией не очень, тестов приходится писать намного больше. И с другой стороны, если типизация очень сильная, то язык программирования превращается в язык доказательства теорем, и в таком языке модульные тесты и не нужны, потому что если программа компилируется - скорее всего она корректна.
Я скорее говорил о том, что никто не будет выводить в прод написанный за полчаса алгоритм или структуру данных без должного тестирования, а тестирование отдельных алгоритмов это в 99% случаев именно unit-тестирование.
Полагаю, этот механизм сейчас работает плохо из-за высокой доли вкатунов и откровенных самозванцев. Ну т.е. человек проходит фильтр, и сразу приносит компании минус 300-500к. А лишние деньги у всех закончились.
Не нужно про неё говорить. Её нужно оставить для JS-квестов типа "посчитайте среднее по массиву за 8 символов" и в таком духе. В реальном коде абсолютно нечитаемая магия, особенно если JS/TS для вас - очередной-язык-на-котором-приходится-прогать, а не мечта всей жизни.
Вот только вчера об этом говорили с коллегами. Что куда важнее написать тесты вдоль и поперёк, особенно если это какой-то новый алгоритм (а зачем повторно реализовывать существующие?).
Мне вообще непонятно, каким образом алгоритмические, а точнее спортивно-олимпиадные задачки заехали в большинство собесов. У вас ещё более-менее адекватная задача, а зачем красно-чёрные деревья реализовывать на листке бумаги, я откровенно не понимаю.
А на этот вопрос вы сами себе отвечаете:
Захочешь в Яндекс — и не так, простите, задницу рвать начнёшь. Добро пожаловать в чеболизацию по-русски. Я честно пытался найти ДРУГИЕ причины, но мне кажется пора перестать делать вид, будто они есть. Причина одна и стара как мир: если у тебя столько бабла, что люди стоят в очереди чтобы хоть как-то прильнуть к нему, то ты можешь делать что хочешь. Это касается как людей, так и компаний.
Мы вот рады, когда кандидат понимает, как работает flow-sensitive typing в TS, хотя бы просто на конкретных примерах. И то редко такие встречаются.
Не все и не всегда. Например, мой друг терпеть не может, когда обучение идёт через примеры и по паттернам. У него сугубо структурный тип мышления, и ему нужна эта концептуальная структура, а не готовые примеры, которые можно менять. Я в принципе и сам такой же.
Сейчас я своим коллегам читаю лекции по Git. И вот что любопытно: на подготовку этих лекций меня сподвигло то, что я пришёл к выводам, абсолютно противоположным выводам в статье. Интернеты забиты примерами и быстрыми туториалами по Git, а вот толкового курса о том, как действительно он работает, так вот быстро и не найдёшь. Потому что большинство так и поступает: это же не язык программирования, а просто вспомогательный инструмент, я быстренько разберусь как там выполнять основные команды, а если начнутся проблемы, то лид разберётся, ему же больше платят. Поэтому в своих лекциях я как бы изобретаю Git заново со своими слушателями, чтобы объяснить те весьма простые концепции, на которых он построен, а не зубрить хаотичный CLI Git-а.
Если современная разработка много где превратилась в потогонку вида «в прод нужно было ещё вчера», и все занимаются stackoverflow-oriented/ChatGPT-oriented programming, то это скорее проблема менеждмента, а может даже и экономики/рынка.
А вот это хороший совет. Только есть другая проблема: этот понятийный аппарат сначала нужно как-то получить. Тут мы и вспоминаем, зачем же на самом деле нужно полноценное образование — чтобы понимать людей, и чтобы тебя понимали.
Ну тут автор изобрёл бритву Оккама, нечего добавить.
Спасибо за перевод!
Мне кажется тут более уместен термин «приятели», в том числе в случае пива вечером. Друг это тот, кто займёт вам на три месяца платежей по ипотеке, пока вы меняете работу.
А вы кто?
Многие скажут, что это вкусовщина, но мне кажется нет смысла индексный хедер класть внутрь header namespace (т.е. внутрь поддиректории). Хочется подключать как
#include <libnumerixpp.hpp>ну или#include <libnumerixpp/all.hpp>, но не#include <libnumerixpp/libnumerixpp.hpp>.И кстати да, стандартные и библиотечные инклуды должны использовать угловые скобки
#include <>, т.к. кавычки на большинстве компиляторов подразумевают поиск сначала в директории проекта, а инклуд с угловыми скобками ищет только по дирам из списка include paths. Из этого кстати следует, что в публичных хедерах могут быть только инклуды с угловыми скобками, а инклуды с кавычками могут быть только в приватных хедерах и файлах реализации.Спасибо за статью!
Это вопрос идентификации прямых — что такое разные прямые и что такое одна и та же прямая) Но задать его стоит, конечно.
Спасибо за статью! Dangerous Dave in the Haunted Mansion заигран до дыр.
На самом деле приятно почитать реальную историю. В 1997-1998 году, когда играл в Дейва, было совершенно непонятно, что это за имена на заставке, что за Gamer's Edge, что за Ромеро. И узнать не было никакой возможности - игру дал друг знакомого друга, который откуда-то её привёз (или скачал с BBS-ки).
Всегда считал, что это оборотни.
Сейчас мы тут в комментариях список составим, а потом компетентные люди этим списком займутся.
Пока одни пытались хайпануть на блокчейне и идее distributed ledger, Valve просто зарабатывала на коммиссиях. Как мы видим, большинству плевать на то, что БД с записями о владении виртуальными предметами централизована - главное чтобы сохранялась ценность предметов.
У меня есть семья, я уже около 14 лет не живу за счёт родителей, но и семья и родители перестали меня видеть дома т.к. я торчу на работе по 12 часов. Надо бы эту работу поменять, но без надрочки литкод/codewars ничего толкового не найдёшь, эти самые «фильтры» тупо тебя не пропустят (особенно если пытаться поменять техстек, как пытаюсь сделать я).
Работать вместо 12 часов положенные трудовым договором 8 часов с риском быть уволенным за «недостаточную производительность» (с), НО оставшиеся 4 часа (а лучше - 2 часа) потратить на литкод, готовясь в любой момент «хлопнуть дверью» - очень хорошая мотивация.
Вы говорите про какую-то идеальную ситуацию, когда человек спец в суперпопулярном стеке, этот стек ему самому нравится, и 40 компаний готовы взять такого человека к себе, надо лишь как-то пройти отбор. Это далеко не всегда так. Бывает когда хочется поменять специализацию (сразу +50 к недоверию соискателю - а чего это ты на бэк захотел?), бывает когда город проживания - не Москва и компаний не так много, а удалёнка - 100% не вариант для вас.
И я, который считает, что ему придётся "набить" себе литкод-очков для прохождения этих самых фильтров.
То есть это такая бесконечная попытка обмануть друг друга - в одних компаниях говорят "Ну и как ты готовился к собесу, если даже литкод не порешал? Несерьёзно ты относишься к нашей вакансии.." (в лицо вам это не скажут, это будет реализовано через "алгоритмический" этап собеса, где вы за 90 секунд не успеете написать балансировку красно-чёрного дерева), а у вас - "А зачем тебе литкод решать, если ты и так крутой спец? Подозрительно...".
Можно конечно решать литкод, но не показывать в резюме - это несколько контринтуитивный вывод, надо сказать.
Вообще не понимаю, как стриминговый сервис может заменить локальную коллекцию музыки. События последних лет напоминают нам, что музыка на стримингах лишь временно сдаётся вам в аренду. Все ваши подборки и плейлисты могут запросто стать недоступными из-за того, что какие-то важные дяди в костюмах разошлись во мнениях по вопросам авторских прав, или вообще по политическим соображениям. iTunes похоже скоро умрёт окончательно, и это весьма печально. Хорошо что есть Bandcamp, спаси его и сохрани.
Это, разумеется, касается не только музыки, но и фильмов, и книг. Да и вообще любых ваших данных, которые вам не принадлежат и хранятся не у вас. Просто одно дело - история поездок в такси или покупок в магазине (лучше бы её вообще не было), а другое - любимые треки.
Стоимость гигабайта сейчас настолько упала, что всем по карману локально хранить всю их коллекцию в lossless-кодировании ещё и с регулярными бэкапами. Вопрос только в том, что всем лень этим заниматься, ну и в дорогу взять сложнее (нужно что-то куда-то там копировать/синхронизировать и т.д.).
Вот искать новую музыку на стримингах - это другое дело, это действительно удобно.
Люто плюсую. Far никогда не обманет, не запустит случайно никакого кода, просто покажет что внутри файла. А с Проводником на чужие флешки ходить как-то стрёмно. И даже если речь не идёт о малвари - куда быстрее глянуть Far-ом, что там за файл и что от него ожидать.
С ним вообще вся файловая система как на ладони. Адекватные дефолты "для ойтишнека" - не нужно настраивать показ расширений файлов, скрытых файлов и вот это вот всё что делается каждый раз на свежем профиле в Винде. Впрочем, это наверное актуально для любого приличного файлового менеджера, а вот "консльность" и быстрый просмотр - кмк, киллер-фичи.
Кажется никто не упомянул в комментариях интересный и важный юзкейс для Far - работа по SSH на виндовых машинах. С учётом того, что OpenSSH теперь есть в поставке Винды, то консольность файлового менеджера выглядит как киллер-фича.
Ну и второй огромный плюс, лично для меня - быстрый просмотр/редакторование по F3/F4. РЕАЛЬНО быстрый, никакой, даже самый лёгкий редактор так быстро не запустится. А для меня часто очень важно знать, что "внутри" файлов, и быстро по ним переходить. Не встречал HEX-редакторов, где это было бы так же удобно и быстро (потому что по сути нужен файловый менеджер и HEX-просмотровщик/редактор в одном флаконе).
А вот я обнадёжу вас, очень даже прижилась, с тех пор как в Винде появился OpenSSH (что клиент, что сервер). Теперь на виндовые билд-машины в 97% случаю захожу по SSH, только если какая-то странная авария - тогда уже через SPICE или ещё какой гуёвый протокол.
Ну а если по SSH - то что, если не FAR, не так ли?