Прикольно. У меня приятель тоже ходит в марксистский кружок и очень похожие взгляды. Правда не думаю что общественное движение марксистского толка кажется текущему государству опасным, скорее даже наоборот. Поэтому думаю что повода для тревоги нету, в отличие от другой протестной деятельности.
А касательно изучения истории и материализма – тоже заметил у приятеля, что как бы пропускает явный треш мимо себя, смотрит на ситуацию сверху. С одной стороны плюс, нервы спокойнее. С другой стороны как по мне теряется базовая человеческая эмпатия. Условно мочит милиця человека, а он говорит что "неправильно вы митингуете, глупые просто". Вроде и прав, а слушать противно.
Ну и истории что "счас по всему миру начнется", мне лично все еще кажутся смешноватыми и больше похожими на религию, т.к. марксисты твердят об этом в каждом ютуб ролике и уже довольно давно. А обоснование очень общее и не выглядит достаточно убедительным (смотрел Семина и еще парочку). Но тут время покажет.
Где-то с полгода назад мы пробовали перевести крупный .NET проект с 12-летней историей на Mono. В связи с плавным переходом на микросервисную архитекруту, просто завораживала возможность ранать и деплоить все единообразно(docker, kubernetes, все дела).
За несколько человеко-недель удалось собрать проект под моно и поправить невероятно странные ошибки, которые возникали из-за отличий работы неоторых библиотек на .NET и Mono(в частности ReLinq просто собирал разные expression trees под обеими платформами). Потом запустили перформанс тесты, которые у нас есть в неплохом количестве. Результаты оказались удручающими. Некоторые сервисы просели в разы. У нас в проекте много бизнес-логики, но также очень много работы с деревьями выражений, свой QueryProvider. Пытались разобраться какие места конкретно тормозят, но оказалось не так-то просто. Профайлер под моно грустный(как и monodevelop). Пытались вырезать из конкретного сервиса логику, до тех пор пока не доберемся до места где происходит различие, но не особо получилось. Кажется, что рефлексия, работа со строками, сборка мусора под mono проседает, но 100% до конца не разобрались. В общем провал.
Ждем нативного докера под windows.
Зачетный набор советов.
У нас на проекте больше тысячи функциональных тестов. Используем Selenium(WebDriver). Запускается все это чудо на Jenkins, где подготовлено около 30 виртуальных машин. В сумме от от нажатия кнопки «build» до получения готового к релизу билда (на котором все юнит и функциольные тесты зеленые) проходит минут 40-50.
Пока тесты писали только тестировщики, у нас всегда была проблема с нестабильностью, которую и описывает автор статьи. По началу проглядывали красные тесты и запускали их руками на своих машинах. Было грустно. Код тестов был тоже грустный. Все-таки писать автоматические тесты на .NET это уже полноценное программирование, а люди занимающиеся автоматическим тестированием как правило не имеют достаточной квалификации.
Как-то собрались все вместе и решили, что функциональность-то наша, и будем сами покрывать ее этим самым минимальным набором тестов, при этом постепенно приведем тестовый фреймворк в порядок. Стало полегче.
При этом осталась проблема нестабильных тестов. Договорились что каждый день один из программистов будет «ответсвенный» за билд. Если тест упал, и упал по нестабильности, разработчик его чинит. В команде 7 человек, так что это было не так напряжно. Сначала тесты было чинить непросто, т.к. проблемы выявлялись повсюду (то в Selenium, то сам тест был очень хитер). По немногу выделили многие паттерны нестабильности, сейчас без причины падает каждый 5-ый а то и 10-ый билд. Кстати в красный билд комитить нельзя:-)
Выводы думаю понятны. А вот от себя могу добавить важный итог — когда я делаю довольно серьезные изменения в коде, я без страха смотрю в будущее, т.к. цвет билда буквально через часок подмигнет мне о том, что же такого я накодил. Стало действительно легче и быстрее делать серьзеные изменения.
P.S. Релизы выпускаем где-то раз в месяц. Стоит признать что продукт уже довольно устоявшийся, мы скорее добавляем новые области, чем серьезно меняем существующие.
Каждый объект — сам себе жнец, швец, на дуде игрец.
Довольно спорное утверждение. И хотя уже на эту тему не мало было высказываний добавлю: это явное противоречие одному из принципов ООП дизайна — Single responsibility principle. Я ни в коем случае не предлагаю слепо следовать утверждениям парням из книжек (тот же Robert C. Martin, который выделил этот принцип, в одной из своих презентаций говорит что самый лучший метод состоит из одной строки :-)). Но на мой взгляд Single responsibility principle как раз-таки очень правильный подход к проектированию системы классов. Не нужно бояться иметь много классов и много файлов. Как раз наоборот, если каждый класс имеет делает свою специфическую работу, то правильно назвав его вы как раз упростите систему. Также это позволяет строить более простые иерархии.
А по поводу тетрадки для записей и мелких этюдов — эту проблему уже давно решили за нас, придумав юнит тесты. А вообще могу порекомендовать BDD как продолжение TDD. Там сценарии (то бишь тесты) пишутся в текстовом виде и имеют формат позволяющий записывать требования к системе. Т.е. на выходе вместо тетрадки и этюдов вы будете иметь набор требований к системе, которые к тому уже отлично тестируют ваш код. Если же речь идет о документирвании алгоритмов, то тут мне тоже больше нравятся старые добрые блок схемы. Хотя опять же семантически правильно написанный код избавляет вас от нужды в блок схемах, ибо там все и так читается легко и просто.
Статью как вводную для новичков не советовал бы. Уж больно спорные утверждения
Кстати мне кажется что сама идея ASP.NET Ajax контролов с разделенной логикой(сервер-клиент) как-то не особо. Доводилось мне юзать кое-чего из их тулкита и даже писал extender-ы для всей этой бодяги. Получается довольно сложно и не особо-то удобно.
Конечно можно возразить что в итоге получается цельный контрол, довольно красивый. Но в своем приложении я бы не стал такое внедрять. Это сразу удар по производительности и рассадник разных невероятных ошибок. Да и весь ajax от Microsoft на построенный на Update Panel это не особо-то настоящий ajax.
То ли дело приложение с толстым клиентом (построенным на Jquery, ExtJS или еще каком framework) и веб-сервисами. Вот это я понимаю!!! :-) Можно делать действительно красивые и быстрые вещи.
Прикольно. У меня приятель тоже ходит в марксистский кружок и очень похожие взгляды. Правда не думаю что общественное движение марксистского толка кажется текущему государству опасным, скорее даже наоборот. Поэтому думаю что повода для тревоги нету, в отличие от другой протестной деятельности.
А касательно изучения истории и материализма – тоже заметил у приятеля, что как бы пропускает явный треш мимо себя, смотрит на ситуацию сверху. С одной стороны плюс, нервы спокойнее. С другой стороны как по мне теряется базовая человеческая эмпатия. Условно мочит милиця человека, а он говорит что "неправильно вы митингуете, глупые просто". Вроде и прав, а слушать противно.
Ну и истории что "счас по всему миру начнется", мне лично все еще кажутся смешноватыми и больше похожими на религию, т.к. марксисты твердят об этом в каждом ютуб ролике и уже довольно давно. А обоснование очень общее и не выглядит достаточно убедительным (смотрел Семина и еще парочку). Но тут время покажет.
За несколько человеко-недель удалось собрать проект под моно и поправить невероятно странные ошибки, которые возникали из-за отличий работы неоторых библиотек на .NET и Mono(в частности ReLinq просто собирал разные expression trees под обеими платформами). Потом запустили перформанс тесты, которые у нас есть в неплохом количестве. Результаты оказались удручающими. Некоторые сервисы просели в разы. У нас в проекте много бизнес-логики, но также очень много работы с деревьями выражений, свой QueryProvider. Пытались разобраться какие места конкретно тормозят, но оказалось не так-то просто. Профайлер под моно грустный(как и monodevelop). Пытались вырезать из конкретного сервиса логику, до тех пор пока не доберемся до места где происходит различие, но не особо получилось. Кажется, что рефлексия, работа со строками, сборка мусора под mono проседает, но 100% до конца не разобрались. В общем провал.
Ждем нативного докера под windows.
У нас на проекте больше тысячи функциональных тестов. Используем Selenium(WebDriver). Запускается все это чудо на Jenkins, где подготовлено около 30 виртуальных машин. В сумме от от нажатия кнопки «build» до получения готового к релизу билда (на котором все юнит и функциольные тесты зеленые) проходит минут 40-50.
Пока тесты писали только тестировщики, у нас всегда была проблема с нестабильностью, которую и описывает автор статьи. По началу проглядывали красные тесты и запускали их руками на своих машинах. Было грустно. Код тестов был тоже грустный. Все-таки писать автоматические тесты на .NET это уже полноценное программирование, а люди занимающиеся автоматическим тестированием как правило не имеют достаточной квалификации.
Как-то собрались все вместе и решили, что функциональность-то наша, и будем сами покрывать ее этим самым минимальным набором тестов, при этом постепенно приведем тестовый фреймворк в порядок. Стало полегче.
При этом осталась проблема нестабильных тестов. Договорились что каждый день один из программистов будет «ответсвенный» за билд. Если тест упал, и упал по нестабильности, разработчик его чинит. В команде 7 человек, так что это было не так напряжно. Сначала тесты было чинить непросто, т.к. проблемы выявлялись повсюду (то в Selenium, то сам тест был очень хитер). По немногу выделили многие паттерны нестабильности, сейчас без причины падает каждый 5-ый а то и 10-ый билд. Кстати в красный билд комитить нельзя:-)
Выводы думаю понятны. А вот от себя могу добавить важный итог — когда я делаю довольно серьезные изменения в коде, я без страха смотрю в будущее, т.к. цвет билда буквально через часок подмигнет мне о том, что же такого я накодил. Стало действительно легче и быстрее делать серьзеные изменения.
P.S. Релизы выпускаем где-то раз в месяц. Стоит признать что продукт уже довольно устоявшийся, мы скорее добавляем новые области, чем серьезно меняем существующие.
В любом случае поздравляю! Резонанс Ваша статья вызвала неплохой. Читать комменты очень интересно :-)
Довольно спорное утверждение. И хотя уже на эту тему не мало было высказываний добавлю: это явное противоречие одному из принципов ООП дизайна — Single responsibility principle. Я ни в коем случае не предлагаю слепо следовать утверждениям парням из книжек (тот же Robert C. Martin, который выделил этот принцип, в одной из своих презентаций говорит что самый лучший метод состоит из одной строки :-)). Но на мой взгляд Single responsibility principle как раз-таки очень правильный подход к проектированию системы классов. Не нужно бояться иметь много классов и много файлов. Как раз наоборот, если каждый класс имеет делает свою специфическую работу, то правильно назвав его вы как раз упростите систему. Также это позволяет строить более простые иерархии.
А по поводу тетрадки для записей и мелких этюдов — эту проблему уже давно решили за нас, придумав юнит тесты. А вообще могу порекомендовать BDD как продолжение TDD. Там сценарии (то бишь тесты) пишутся в текстовом виде и имеют формат позволяющий записывать требования к системе. Т.е. на выходе вместо тетрадки и этюдов вы будете иметь набор требований к системе, которые к тому уже отлично тестируют ваш код. Если же речь идет о документирвании алгоритмов, то тут мне тоже больше нравятся старые добрые блок схемы. Хотя опять же семантически правильно написанный код избавляет вас от нужды в блок схемах, ибо там все и так читается легко и просто.
Статью как вводную для новичков не советовал бы. Уж больно спорные утверждения
Конечно можно возразить что в итоге получается цельный контрол, довольно красивый. Но в своем приложении я бы не стал такое внедрять. Это сразу удар по производительности и рассадник разных невероятных ошибок. Да и весь ajax от Microsoft на построенный на Update Panel это не особо-то настоящий ajax.
То ли дело приложение с толстым клиентом (построенным на Jquery, ExtJS или еще каком framework) и веб-сервисами. Вот это я понимаю!!! :-) Можно делать действительно красивые и быстрые вещи.