Здравствуйте, Vlad_SP, Вы писали:
R>> Фанател от DN и The Bat! Ну реально качественные продукты: писал своё по образу и подобию. Но сейчас что? Сейчас в Ритлабсе полторы калеки работают, которые не хотят прислушиваться к пожеланиям пользователей (точнее, к моим пожеланиям) Поэтому фиг им, а не покупка. V_S>Ээээ..... DN еще жифф???
Конечно же нет. Речь про текущую ситуацию, а у Ритлабса сейчас лишь один единственный продукт.
$>Давно ещё, на собеседовании в одной компании спрашивали по diamond inheritance. Может показаться, давали "синтезированный концентрат говнокода". Но потом я узнал, это был типичный кусок из их кодовой базы. Так что, если лично меня попросят прочитать кусочек отборного г-кода, это будет red flag.
ты просто еще не работал в америки
такого говнокода как здесь я не встречал не в РФ ЮАР Китаи
при этом 99% попыток погворить с тимлидером заканчиваеться — я начальник ты мудак, аргументация к авторитетма американского же CS не работает
из личного списка треша
файл больше 50000 строк, VS торомозила так что все операции занимали секунды те нажал кнокпу символ появлися через несколько сек
функции больше 5000 строк, этим здесь многие грешат, особый пипец if for на всю функцию
функция больше 200 параметров тк что компилятор начинает говорить что не может ее скомпилировать
класс больше чем 1000 (почти полторы тыс) функций и мемберов, наазвание класса Rome
серилизация больше 200 лассов в ручную с запретом использования темплейтов и наследования
самописные list и vector которые не доятгивают даже длл 20% их функционала
сборка проекта на VS6 для платформы win xp 32 в 2019 году (старушка используеться через 20 лет после выхода SP6 для нее, я фанат 6 студии но не для десктопных приложений)
Здравствуйте, Rhino, Вы писали:
R>Здравствуйте, Vlad_SP, Вы писали:
R>>> Фанател от DN и The Bat! Ну реально качественные продукты: писал своё по образу и подобию. Но сейчас что? Сейчас в Ритлабсе полторы калеки работают, которые не хотят прислушиваться к пожеланиям пользователей (точнее, к моим пожеланиям) Поэтому фиг им, а не покупка. V_S>>Ээээ..... DN еще жифф??? R>Конечно же нет. Речь про текущую ситуацию, а у Ритлабса сейчас лишь один единственный продукт.
DN стал open source и иногда релизят (я использую когда пишу на tandy 1000)
а VC досихпор продаеться и пусть несколько раз в год но его покупают
вообше оглядываясь назад вовремена DOS и Win 31 продукты были еще относительно простыие и их можно было написать силами 1-3 человек
тееперь к сожалению нет
Здравствуйте, SkyDance, Вы писали:
G>>Конкретно в моем посте был вопрос про специфику работы деструкторов в .NET. Опытный разработчик должен понимать, что будет в случае брошенного в деструкторе исключения. А может быть, он даже ловил такие ситуации на практике. Это вопрос на понимание работы платформы
SD>Так и что будет-то? И эт... а разве сложно нагуглить ответ? Просто если это занимает 5 минут (нагуглить), то вопрос попросту не имеет смысла.
Любой ответ можно нагуглить. Но наверно тяжело делать это в ходе интеревью, не так ли?
А ответ лично я ожидал бы такой:
Мы вообще не контролируем ни время ни поток выполнения деструктора, потому что они выполняются рантаймом в специально выделенном потоке c наивысшим приоритетом. Необработанное исключение в этом специальном потоке может привести к повреждению состояния приложения. И вообще, деструкторы нужно реализовавать редко и крайне осторожно, например, для работы с неуправляемыми ресурсами.
Понимаешь, это всего лишь пример. Можно напридумывать массу других вопросов.
Здравствуйте, $$, Вы писали:
G>>>И он при прочих равных сначала сходит в те компании, которые не требуют предварительных ласк.
$>>Кандидат, надувающий губки на кодерскую задачку, вызывает вопросы, а любит ли он кодить, или научился надувать щёки?
Я ничего не писал про надувание губок.
При чисто прагматическом подходе кандидат пойдет на собеседование туда, где сразу можно говорить о деле. И только, если во всех других компаниях его отшили, потратит время на ваши задачки.
И ты так и не ответил, что ваша компания предлагает такого, чего нет у конкурентов, кроме требования потратить время до собеседования?
Впрочем, понятное дело, вы можете искать как вам хочется. Это же ваш бизнес ))
G>>>Еще лучше. Человек потратит на вас свое время, а потом "Его очередь может долго не подходить"! Браво!
$>>В Яндекс тоже затягивают пылесосом всех подряд? Или в Касперского?
В Яндексе не был.
В Касперском был года 3 назад, получил оффер.
Собеседование назначили дня через три после созвона. Никто там не давал домашних задачек. Никто не заставлял проходить идиотские опросники. Ребята сумели запихнуть все этапы собеседования в один день.
А теперь скажи, только честно, допустим у нас есть хороший разраб. Вот он поговорил по телефону с Касперским, и его приглашают на очное интервью. Потом он поговорил с твоей компанией, ты выдал ему домашнее задание, и только после выполнения этого задания можно начать договариваться об интервью.
На какое интервью он пойдет?
Здравствуйте, Gradiens, Вы писали:
G>Конкретно в моем посте был вопрос про специфику работы деструкторов в .NET. Опытный разработчик должен понимать, что будет в случае брошенного в деструкторе исключения. А может быть, он даже ловил такие ситуации на практике. Это вопрос на понимание работы платформы.
Э... деструкторов в .NET??? Ты платформой не ошибся случаем?
Здравствуйте, Gradiens, Вы писали:
G>Мы вообще не контролируем ни время ни поток выполнения деструктора, потому что они выполняются рантаймом в специально выделенном потоке c наивысшим приоритетом. Необработанное исключение в этом специальном потоке может привести к повреждению состояния приложения. И вообще, деструкторы нужно реализовавать редко и крайне осторожно, например, для работы с неуправляемыми ресурсами.
Ты, вроде, исключение в Dispose в исходном посте упоминал. А теперь про финализатор почему-то заговорил (который зачем-то деструктором обозвал). Может все-таки стоит сначала самому с терминологией определиться, а потом вопросы задавать?
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, Gradiens, Вы писали:
G>>Мы вообще не контролируем ни время ни поток выполнения деструктора, потому что они выполняются рантаймом в специально выделенном потоке c наивысшим приоритетом. Необработанное исключение в этом специальном потоке может привести к повреждению состояния приложения. И вообще, деструкторы нужно реализовавать редко и крайне осторожно, например, для работы с неуправляемыми ресурсами.
L>Ты, вроде, исключение в Dispose в исходном посте упоминал. А теперь про финализатор почему-то заговорил (который зачем-то деструктором обозвал). Может все-таки стоит сначала самому с терминологией определиться, а потом вопросы задавать?
Сорри, термины попутал.
В исходном посте говорил про обе вещи: Dispose и финализатор.
И вопрос (ну просто один из вопросов который приведен навскидку для того, чтобы проиллюстировать мой субъективный подход) был в том, что произойдет если исключение будет выброшено из Dispose и что изменится если исключение будет выброшено из финализатора.
L>Ты, вроде, исключение в Dispose в исходном посте упоминал. А теперь про финализатор почему-то заговорил (который зачем-то деструктором обозвал). Может все-таки стоит сначала самому с терминологией определиться, а потом вопросы задавать?
Здравствуйте, Gradiens, Вы писали:
G>И вопрос (ну просто один из вопросов который приведен навскидку для того, чтобы проиллюстировать мой субъективный подход) был в том, что произойдет если исключение будет выброшено из Dispose и что изменится если исключение будет выброшено из финализатора.
Если искл. в финализаторе, то срубит приложение. Если Dispose, то смотря какой поток будет его вызывать.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Lexey, Вы писали:
L>>Ты, вроде, исключение в Dispose в исходном посте упоминал. А теперь про финализатор почему-то заговорил (который зачем-то деструктором обозвал). Может все-таки стоит сначала самому с терминологией определиться, а потом вопросы задавать?
S>Не все так однозначно -- https://habr.com/ru/post/122639/
S>Если не ошибаюсь, то финализатор вызывет Dispose, если он есть, есть ли нет -- то деструктор ~MyClass{}
~MyClass{} — это и есть финализатор, деструкторов в c# нет. dispose никто сам ниоткуда не вызывает, ты должен делать это руками (если нужно, а нужно не всегда).
Здравствуйте, Gradiens, Вы писали:
G>$>>Кандидат, надувающий губки на кодерскую задачку, вызывает вопросы, а любит ли он кодить, или научился надувать щёки?
G>Я ничего не писал про надувание губок. G>При чисто прагматическом подходе кандидат пойдет на собеседование туда, где сразу можно говорить о деле. И только, если во всех других компаниях его отшили, потратит время на ваши задачки.
Я думаю давать 1 задачку на 5 строк кода. В литкоде помечена "easy".
Хорошего кандидата (в моём понимании) она не отпугнёт.
Здравствуйте, SkyDance, Вы писали:
KP>>Я бы вопросы по паттернам закапывал за исключением "почему синглтон это зло?".
SD>Эти слова бы, да всем ФП-разработчикам на лбу высечь, дабы отучились "а мы сейчас это в ETS-таблицу сложим и будет вам shared state".
Ну... а если запихать в ETS-таблицу к которой обращается единственный GenServer? Или ты за Агенты? Я к тому, что состояние всяко хранить приходится даже в функциональных языках, а если язык реализует концепт let it crash, то вопрос надежного сохранения состояния как никогда важен. Или речь про давайте класть всё в ETS-таблицу и отовсюду в неё лазить за данными?
Самый ад с синглтонами в C++, где нет гарантии на порядок инициализации статических объектов в рамках разных модулей трансляции. Участвовал в C++ проекте который так густо порос синглтонами, что в конце концов все синглтоны были помещены в убер-синглтон дабы обеспечить гарантию порядка их инициализации
Здравствуйте, Gradiens, Вы писали:
G>Сорри, термины попутал. G>В исходном посте говорил про обе вещи: Dispose и финализатор. G>И вопрос (ну просто один из вопросов который приведен навскидку для того, чтобы проиллюстировать мой субъективный подход) был в том, что произойдет если исключение будет выброшено из Dispose и что изменится если исключение будет выброшено из финализатора.
в нормальном коде никаких финализаторов не будет, неуправляемые ресурсы должны использоваться с using что-бы разрушать их сразу после выполнения необходимых действий, а не висеть в памяти пока класс не подберет GC
Здравствуйте, kaa.python, Вы писали:
KP>Самый ад с синглтонами в C++, где нет гарантии на порядок инициализации статических объектов в рамках разных модулей трансляции. Участвовал в C++ проекте который так густо порос синглтонами, что в конце концов все синглтоны были помещены в убер-синглтон дабы обеспечить гарантию порядка их инициализации
Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить.
Корректный порядок инициализации гарантирует DI. И по устройству DI (какие алгоритмы и структуры данных там применяются) можно поспрашивать. Но много народа слов таких не слышало.
Здравствуйте, $$, Вы писали:
>>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить. >>Корректный порядок инициализации гарантирует DI. И по устройству DI (какие алгоритмы и структуры данных там применяются) можно поспрашивать. Но много народа слов таких не слышало.
Не вижу, так как я описал только одну, самую злобную проблему. Куча других проблем, таких как появление неявных зависимостей, появление дополнительного, внешнего состояния, появление неявной точки синхронизации никуда не деваются. В идеале поведение кода вообще не должно зависеть от состояний, только от входных данных (ага, привет функциональное программирование).
Да и DI ваше тоже говно, зависимости надо передавать явно.
Здравствуйте, kaa.python, Вы писали:
>>>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить. >>>Корректный порядок инициализации гарантирует DI. И по устройству DI (какие алгоритмы и структуры данных там применяются) можно поспрашивать. Но много народа слов таких не слышало.
KP>Не вижу, так как я описал только одну, самую злобную проблему. Куча других проблем, таких как появление неявных зависимостей, появление дополнительного, внешнего состояния, появление неявной точки синхронизации никуда не деваются. В идеале поведение кода вообще не должно зависеть от состояний, только от входных данных (ага, привет функциональное программирование).
KP>Да и DI ваше тоже говно, зависимости надо передавать явно.
KP>Короче, завалил собеседование
Ты натянул сову на глобус. Понятно, что ООП это плохо, а ФП хорошо. Но ты и другие отметившиеся тут топите, что паттерны знать вредно при ООП. При этом вспоминаешь про ФП. При этом, если чел действительно мыслит категориями ФП, то проблемы написать через рекурсию или развернуть хвостовую рекурсию, у него не должно возникнуть. Как например, и отсортировать массив. Как и написать топологическую сортировку на доске (что лежит в основе корректной инициализации DI).
$>Ты натянул сову на глобус. Понятно, что ООП это плохо, а ФП хорошо. Но ты и другие отметившиеся тут топите, что паттерны знать вредно при ООП. При этом вспоминаешь про ФП. При этом, если чел действительно мыслит категориями ФП, то проблемы написать через рекурсию или развернуть хвостовую рекурсию, у него не должно возникнуть. Как например, и отсортировать массив. Как и написать топологическую сортировку на доске (что лежит в основе корректной инициализации DI).
сколько раз в жизни ты писал топологическую сортировку?
я один раз
Поэтому фиг им, а не покупка.
