Если я распакую каждый архив из 105-гигайбайтовой утечки исходников Twitch-а, у меня ФС загнётся от количества файлов. Зачем, если можно архиватором вытаскивать нужные подпапки?
“Вот понаберут глупых новичков, а мне потом за ними РАЗГРЕБАТЬ!”. Что это за инженер с 10-летним опытом, вынужденный исправлять ошибки за сокомандником? Почему крутые специалисты просто не откажут неадекватным кандидатам, не пустив их в свой продукт?
Так, стоп. Разве это не гейткипинг? Т.е. вся остальная статья не имеет смысла? Почему спрашиваю: потому что для меня это основной (если не единственный) аргумент заливать про Таненбаума, CS и всё прочее. Хочется в какой-то момент перестать подтирать за человеком, а он пока даже не понимает, а почему, собственно, за ним подтёрли.
Самый эффективный инструмент для трудоустройства и зарплатного роста в IT
Чтобы контент приносил результат, его надо выпускать регулярно. Только так вы добьетесь нужного количества касаний с нужной аудиторией. Это значит, что делать одну висишку раз в полгода — это не контент-маркетинг.
Как-то всё это грустно. Про «регулярно», про «касания». Когда автор прибегает к помощи редакторов/писателей/прочих специалистов по выражению мыслей и идей в достойном виде — тогда и результат достойный. А вот когда делается наоборот, потому что нужны «касания» — такое себе.
Впрочем, о чём это я, я же просто не с той стороны рта нахожусь. Люди работу работают, а мы потом будем выискивать сокровища в информационной свалке.
А вот за эту статью спасибо! Вот её как раз писали именно те люди, которые «кто ручками каждый день в ней [теме] ковыряется».
Как скоро они выгорят от не своей работы?
Неужели хороших авторов настолько мало и они настолько недоступны, что не вариант идти по пути их выращивания и менторства?
что тестирование не гарантирует правильность программы и вообще не является инструментом разработки
По большей части с вами согласен. В том числе поэтому считаю статическую типизацию (например) куда более важным инструментом, чем тесты. Те же модульные тесты нужны прежде всего чтобы: а) дать самодокументацию в виде каких-то кейсов, чтобы на ревью или при рефакторинге читающий не спрашивал "а вот это будет работать?", "а вот такой кейс предусмотрели?". Все ответы уже заготовлены в виде тестов, а если что-то пропущено - то лучше в виде очередного теста и добавить. Это по сути одна из самых лучших форм документации - никогда не устаревает, в отличие от просто рукописного текста. б) "заткнуть" какие-то краевые ситуации, которые не может покрыть статическая типизация. Обычно если в языке с типизацией не очень, тестов приходится писать намного больше. И с другой стороны, если типизация очень сильная, то язык программирования превращается в язык доказательства теорем, и в таком языке модульные тесты и не нужны, потому что если программа компилируется - скорее всего она корректна.
Я скорее говорил о том, что никто не будет выводить в прод написанный за полчаса алгоритм или структуру данных без должного тестирования, а тестирование отдельных алгоритмов это в 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-кодировании ещё и с регулярными бэкапами. Вопрос только в том, что всем лень этим заниматься, ну и в дорогу взять сложнее (нужно что-то куда-то там копировать/синхронизировать и т.д.).
Вот искать новую музыку на стримингах - это другое дело, это действительно удобно.
Если я распакую каждый архив из 105-гигайбайтовой утечки исходников Twitch-а, у меня ФС загнётся от количества файлов. Зачем, если можно архиватором вытаскивать нужные подпапки?
Так, стоп. Разве это не гейткипинг? Т.е. вся остальная статья не имеет смысла? Почему спрашиваю: потому что для меня это основной (если не единственный) аргумент заливать про Таненбаума, CS и всё прочее. Хочется в какой-то момент перестать подтирать за человеком, а он пока даже не понимает, а почему, собственно, за ним подтёрли.
Всё понятно. Рад знакомству (нет).
Как-то всё это грустно. Про «регулярно», про «касания». Когда автор прибегает к помощи редакторов/писателей/прочих специалистов по выражению мыслей и идей в достойном виде — тогда и результат достойный. А вот когда делается наоборот, потому что нужны «касания» — такое себе.
Впрочем, о чём это я, я же просто не с той стороны рта нахожусь. Люди работу работают, а мы потом будем выискивать сокровища в информационной свалке.
А вот за эту статью спасибо! Вот её как раз писали именно те люди, которые «кто ручками каждый день в ней [теме] ковыряется».
Неужели хороших авторов настолько мало и они настолько недоступны, что не вариант идти по пути их выращивания и менторства?
Как раз два года опыта с момента релиза классики!
Что вы имеете в виду? В одном случае это бинраный оператор, в другом - унарный.
По большей части с вами согласен. В том числе поэтому считаю статическую типизацию (например) куда более важным инструментом, чем тесты. Те же модульные тесты нужны прежде всего чтобы:
а) дать самодокументацию в виде каких-то кейсов, чтобы на ревью или при рефакторинге читающий не спрашивал "а вот это будет работать?", "а вот такой кейс предусмотрели?". Все ответы уже заготовлены в виде тестов, а если что-то пропущено - то лучше в виде очередного теста и добавить. Это по сути одна из самых лучших форм документации - никогда не устаревает, в отличие от просто рукописного текста.
б) "заткнуть" какие-то краевые ситуации, которые не может покрыть статическая типизация. Обычно если в языке с типизацией не очень, тестов приходится писать намного больше. И с другой стороны, если типизация очень сильная, то язык программирования превращается в язык доказательства теорем, и в таком языке модульные тесты и не нужны, потому что если программа компилируется - скорее всего она корректна.
Я скорее говорил о том, что никто не будет выводить в прод написанный за полчаса алгоритм или структуру данных без должного тестирования, а тестирование отдельных алгоритмов это в 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-кодировании ещё и с регулярными бэкапами. Вопрос только в том, что всем лень этим заниматься, ну и в дорогу взять сложнее (нужно что-то куда-то там копировать/синхронизировать и т.д.).
Вот искать новую музыку на стримингах - это другое дело, это действительно удобно.