Вас понял, спасибо за поднятие вопроса. Black, де-факто стандарт. Так же вам более не нужно устраивать джихад внутри команды за то какой формат лучше. Да и поддержка pre-commit из коробки. В black почти нет конфигурации.
Подскажите, будет ли в DataSpell интеграция с нормальным, современным, конфигурируемым code formater, например black(как в vscode) или же будет та же грусть и печаль что в чармах через external tool?
Улыбнуло, напомнило мне одну компанию которая мне дала долгое, совершенно неприменимое на практике, но интересное тех задание на дом. Поскольку они искали разраба на Scala и я искал такую позицию, пришлось потерпеть пару тройку вечеров. Задание выполнил, этап прошел, на след этапе выяснил что на самом деле Scala просто крупицы, а 99% процентов работы делается на Java 7(шел 2019 год). Как же я был зол ....
Прежде всего спадёт бум программирования и компании начнут диктовать свои условия
Не спадет ничего, если не произойдет какого либо глобального потрясения с далеко идущими последствиями(пандемия бубонной чумы или война индии с китаем).
Если развитие в данном направлении будет так же продолжатся, мне придется перейти с пай-чарма на вску. Уж очень в чарме поддержка юпитера хромает. Молодцы!
Обычно, когда работодатель хочет хардкора, он так и говорит, "запили на ванильных шарпах". Если ничего такого не говорят, то вы вольны выбирать сторонние библиотеки на ваш выбор. Это кстати тоже может быть частью проверки ваших навыков на "велосипедность".
Я имел в виду только оптимизацию с ГОТО. Не уверен, что в вашем случае получилось бы заменить ГОТО на более элегантное решение с двойной взаимоисключающей хвостовой рекурсией. Как в данной статье: - http://sharp-gamedev.blogspot.com/2011/08/forgotten-control-flow-construct.html
Раз уж речь зашла про монады, почему бы не попробовать хвостовую рекурсию(с ее оптимизацией) вместо ГОТО.
Классно, но меня все же смущает GOTO, это по Кнуту преждевременная оптимизация в случае тестого задания. Интересно, как бы автор подошел к данной части если бы использовал F#.
Тут ведь тоже не наблюдается наследование, полиморфизм, инкапсуляция и работа с паттернами.
У меня такое впечатление, что вы не готовы конструктивно воспринимать критику в адрес вашего подхода к решению поставленной задачи. Ваш опрос в конце статьи не конструктивен и ориентирован в вашу пользу.
Что касается сравнения вашего решения и классов платформы, то я считаю его не уместным. Именно по этому полагаю что мы продолжаем общение, пребывая в разных измерениях.
Взгляните на определение самого класса и на его методы:
``` internal sealed class RegexParser { internal static RegexTree Parse(String re, RegexOptions op) {} //.... } ```
Класс является сугубо внутренним и объявлен как статический. Он намертво интегрирован в более глобальный модуль для работы с регулярными выражениями. Если мне не изменяет память, то вас не просили написать подобный модуль для интеграции в какую либо системную утилиту. Вас попросили запилить простенький парсер а-ля CRON-таб выражений.
Работодатель ждал от вас что-то вроде(в гораздо более простом исполнении): - https://github.com/atifaziz/NCrontab/blob/master/NCrontab/CrontabSchedule.cs - https://github.com/HangfireIO/Cronos/blob/master/src/Cronos/CronExpression.cs
Оба представленных класса не являются эталоном оформления кода или дизайна решений, но дают богатую пищу для размышлений как следует оформлять и тестировать(!) простенькие, самописные парсеры.
Давайте. Начнем с длинны методов, ` ScanReplacement` или `AddConcatenate` выходят под 30-40 строчек, что неплохо. Читаемость нормальная, есть избыточность, но это скорее всего из-за того что коду лет так 20. Облагораживанию подлежит. Код процедуральный, а значит, с душком, не идеален. Но все же в разы лучше вашего творчества.
А вот методы парсинга у них так себе конечно, например `ScanRegex`, с другой стороны такие вещи, не обязательно, должны писаться руками, а могут быть сгенерированы из грамматики(см Ragel State Machine Compiler). Хотя в целом код оптимален, для парсинга регулярок потянет.
В том то и дело, все это имело место, что бы проверить как вы пишите код в повседневной среде. Лично мне было бы стыдно показывать такой код, как у вас, кому-либо.
Мне бы помогла обратная связь с заказчиком, но в ней было отказано.
Мне кажется обратной связи не было потому что заказчик и вы живете в совершенно разных измерениях, но заказчик это понял сразу, а вы наверное нет.
Согласен с комментарием выше. Ваш конструктор просто жесть, на 3 км (как и все важные методы), каша из валидации и инициализации. Если вы говорите про читаемость кода, тогда пишите методы которые по длине не превышают трети вашего экрана. Вложенность условий просто выносит мозг. Если вы говорите про читаемость кода, тогда откажитесь от вложенных условных блоков и от веток `else`, от слова совсем. Я в целом согласен с работодателем, неуд.
Это своего рода облегченная версия Unit Types из F#.
Вас понял, спасибо за поднятие вопроса. Black, де-факто стандарт. Так же вам более не нужно устраивать джихад внутри команды за то какой формат лучше. Да и поддержка pre-commit из коробки. В black почти нет конфигурации.
Подскажите, будет ли в DataSpell интеграция с нормальным, современным, конфигурируемым code formater, например black(как в vscode) или же будет та же грусть и печаль что в чармах через external tool?
Улыбнуло, напомнило мне одну компанию которая мне дала долгое, совершенно неприменимое на практике, но интересное тех задание на дом. Поскольку они искали разраба на Scala и я искал такую позицию, пришлось потерпеть пару тройку вечеров. Задание выполнил, этап прошел, на след этапе выяснил что на самом деле Scala просто крупицы, а 99% процентов работы делается на Java 7(шел 2019 год). Как же я был зол ....
Давно пора норм. поддержку ноутбуков добавить, а то тек. мягко говоря устарела лет 5 назад.
Подскажите пож. будет ли JetBrains DataSpell включен в подписку JetBrains All Products Pack? Спасибо.
Не спадет ничего, если не произойдет какого либо глобального потрясения с далеко идущими последствиями(пандемия бубонной чумы или война индии с китаем).
Если развитие в данном направлении будет так же продолжатся, мне придется перейти с пай-чарма на вску. Уж очень в чарме поддержка юпитера хромает. Молодцы!
Попробуйте, вас же не о том просят в задании.
Обычно, когда работодатель хочет хардкора, он так и говорит, "запили на ванильных шарпах". Если ничего такого не говорят, то вы вольны выбирать сторонние библиотеки на ваш выбор. Это кстати тоже может быть частью проверки ваших навыков на "велосипедность".
Я имел в виду только оптимизацию с ГОТО. Не уверен, что в вашем случае получилось бы заменить ГОТО на более элегантное решение с двойной взаимоисключающей хвостовой рекурсией. Как в данной статье:
- http://sharp-gamedev.blogspot.com/2011/08/forgotten-control-flow-construct.html
Раз уж речь зашла про монады, почему бы не попробовать хвостовую рекурсию(с ее оптимизацией) вместо ГОТО.
Классно, но меня все же смущает GOTO, это по Кнуту преждевременная оптимизация в случае тестого задания. Интересно, как бы автор подошел к данной части если бы использовал F#.
У меня такое впечатление, что вы не готовы конструктивно воспринимать критику в адрес вашего подхода к решению поставленной задачи. Ваш опрос в конце статьи не конструктивен и ориентирован в вашу пользу.
Что касается сравнения вашего решения и классов платформы, то я считаю его не уместным. Именно по этому полагаю что мы продолжаем общение, пребывая в разных измерениях.
Взгляните на определение самого класса и на его методы:
```
internal sealed class RegexParser {
internal static RegexTree Parse(String re, RegexOptions op) {}
//....
}
```
Класс является сугубо внутренним и объявлен как статический. Он намертво интегрирован в более глобальный модуль для работы с регулярными выражениями. Если мне не изменяет память, то вас не просили написать подобный модуль для интеграции в какую либо системную утилиту. Вас попросили запилить простенький парсер а-ля CRON-таб выражений.
Работодатель ждал от вас что-то вроде(в гораздо более простом исполнении):
- https://github.com/atifaziz/NCrontab/blob/master/NCrontab/CrontabSchedule.cs
- https://github.com/HangfireIO/Cronos/blob/master/src/Cronos/CronExpression.cs
Оба представленных класса не являются эталоном оформления кода или дизайна решений, но дают богатую пищу для размышлений как следует оформлять и тестировать(!) простенькие, самописные парсеры.
Давайте. Начнем с длинны методов, ` ScanReplacement` или `AddConcatenate` выходят под 30-40 строчек, что неплохо. Читаемость нормальная, есть избыточность, но это скорее всего из-за того что коду лет так 20. Облагораживанию подлежит. Код процедуральный, а значит, с душком, не идеален. Но все же в разы лучше вашего творчества.
А вот методы парсинга у них так себе конечно, например `ScanRegex`, с другой стороны такие вещи, не обязательно, должны писаться руками, а могут быть сгенерированы из грамматики(см Ragel State Machine Compiler). Хотя в целом код оптимален, для парсинга регулярок потянет.
Это вы себе льстите, уж поверьте.
В том то и дело, все это имело место, что бы проверить как вы пишите код в повседневной среде. Лично мне было бы стыдно показывать такой код, как у вас, кому-либо.
Мне кажется обратной связи не было потому что заказчик и вы живете в совершенно разных измерениях, но заказчик это понял сразу, а вы наверное нет.
Согласен с комментарием выше. Ваш конструктор просто жесть, на 3 км (как и все важные методы), каша из валидации и инициализации. Если вы говорите про читаемость кода, тогда пишите методы которые по длине не превышают трети вашего экрана. Вложенность условий просто выносит мозг. Если вы говорите про читаемость кода, тогда откажитесь от вложенных условных блоков и от веток `else`, от слова совсем. Я в целом согласен с работодателем, неуд.
Мне кажется делать порно игры это та же самая грязная студенческая работа. Какое-то дно, ИМХО.
Статья, чистой воды пиар. Мне за 35, в ИТ с 13 лет, но до сих пор не могу сказать - "я все знаю" или "я сеньор".
Это не правда! Документация мутная, в интернетах куча недоделанных примеров, я не встречал ни одного работающего примера.
Бил, смирись, прости и отпусти, прошло столько лет ....
Зачем вы вот таким г-кодом народ смущаете? См здесь:
это понятно
мда печально, конечно