В нулевых только начинала подниматься проблема кроссплатформенной разработки, а теперь - это чуть ли не стандартное решение. Кроссплатформенность - кормовая база для абстракций. Тут без них никак. Декларативные описания UI - тоже самое. Что же касается алгоритмов, то - да, тут очень полезно попробовать написать свою реализацию для объективного восприятия чужих реализаций.
Я разработчик, иногда приходится писать ТЗ самому, чаще получаю ТЗ от аналитика. Так, вот, полностью согласен с автором, что вода в спецификации на доработку только мешает быстрому включению разработчика в процесс. И автор постоянно напоминает о том, что упрощенный подход эффективнее при описании именно доработок системы. Полностью согласен!
PS: важно понимать, что обилие аббревиатуры в тексте - сокращает его длину, но при этом усложняет восприятие.
Брал планшетный ноут lenovo yoga 14arr. Больше никогда не возьму lenovo. Мнение о производителе резко негативное. Хотите качественный ноут - берите apple (пока еще) - не устареет лет 10. Дважды брал, оба раза доволен. До сих пор работает первый от 2011 года на linux
Библиотека богатая, интересная, НО с таким ценником, вы отрезаете целый пласт разработчиков. На инди-проетах вы бы могли прокачать популярность своей библиотеки, а с бизнеса уже стричь по 100к за лицензию. С такими ценами вы крошите привлекательность dotnet ui стека, что мы видим в комментариях к вашим статьям. Хотите продавать - делите аудиторию на инди и бизнес. В энтерпрайзе, именно, мы - разработчики влияем на принятие решения о покупки качественных инструментов. Но дайти нам либу использовать в опенсорс-проектах, чтобы на практике оценить инструмент.
В сегодняшних же реалиях бизнесу нафиг не нужна ваша либа, а целевая аудитория инди-разрабов никогда не окупит стоимость либы и не будет иметь убедительных аргументов к покупке именно вашей либы бизнесом. Так и будете раз в год стыдливо о себе на хабре упоминать...
Интересно) Ведь в логику бэка все равно не реализовать на одном is, т.к. у большой системы куча микросервисов под капотом, причем реализованных не просто на разных языках, но и порой на разных поколениях стэков. В идеале, конечно не плохо бы писать на одном стеке, но это часто остаётся лишь мечтой.
Отличная статья, коррелирует с моим опытом миграции крупной БД Axapta 3.0 в "нереально сжатый срок простоя продуктива", но плюс пересчет RecId int32 (кто работал знает проблему с ограничением maxint на компанию).
Если погружение в задачи не включает в себя "приставания" к программистам в виде обязаловки рассказывать всё, что сделал и почему, а лишь чтение итоговой документации по задаче, тогда норм.
В противном случае, программист устанет от такого внимания к себе.
На счет "черных ящиков" - хорошо сказано. У техлида не должно оставаться черных ящиков на проекте.
Вы гораздо больше времени убиваете в вытягивании себя из трясины ошибок и исключений. А могли бы просто сесть на пенёк, съесть пирожок внимательно прочитать мануал и пройти не наступив в самые топкие места.
Теперь понятно, почему вы в 30 лет задумываетесь о старости... вы устали... ошибаться. Может быть, таки последуете советам тех, кто в 30-40+ не замечал усталости?
Ну и, самое важное, после осознания важности зрелого и профессионального подхода к программированию, раз имеете контакт и влияние на маленьких программистов - учите их правильным вещам.
Ну да, конечно... зачем читать дорожные знаки, на 1002-ю, а может быть 1003-ю попытку получится)) С таким подходом вы до продуктива ничего не додеплоите.
Профессиональный программист должен наращивать теоретическую базу в качестве не зыбкого (песочного) фундамента, но прочного (железобетонного). На такой фундамент уже надежно укладывается получаемый опыт слой за слоем, образуя цитадель разума.
Построив одно надежное строение, вы также должны поступать и с новыми стеками.
Поддержка C# нужна (без воды)
В нулевых только начинала подниматься проблема кроссплатформенной разработки, а теперь - это чуть ли не стандартное решение. Кроссплатформенность - кормовая база для абстракций. Тут без них никак. Декларативные описания UI - тоже самое. Что же касается алгоритмов, то - да, тут очень полезно попробовать написать свою реализацию для объективного восприятия чужих реализаций.
Я разработчик, иногда приходится писать ТЗ самому, чаще получаю ТЗ от аналитика. Так, вот, полностью согласен с автором, что вода в спецификации на доработку только мешает быстрому включению разработчика в процесс. И автор постоянно напоминает о том, что упрощенный подход эффективнее при описании именно доработок системы. Полностью согласен!
PS: важно понимать, что обилие аббревиатуры в тексте - сокращает его длину, но при этом усложняет восприятие.
Брал планшетный ноут lenovo yoga 14arr. Больше никогда не возьму lenovo. Мнение о производителе резко негативное. Хотите качественный ноут - берите apple (пока еще) - не устареет лет 10. Дважды брал, оба раза доволен. До сих пор работает первый от 2011 года на linux
Библиотека богатая, интересная, НО с таким ценником, вы отрезаете целый пласт разработчиков. На инди-проетах вы бы могли прокачать популярность своей библиотеки, а с бизнеса уже стричь по 100к за лицензию. С такими ценами вы крошите привлекательность dotnet ui стека, что мы видим в комментариях к вашим статьям. Хотите продавать - делите аудиторию на инди и бизнес. В энтерпрайзе, именно, мы - разработчики влияем на принятие решения о покупки качественных инструментов. Но дайти нам либу использовать в опенсорс-проектах, чтобы на практике оценить инструмент.
В сегодняшних же реалиях бизнесу нафиг не нужна ваша либа, а целевая аудитория инди-разрабов никогда не окупит стоимость либы и не будет иметь убедительных аргументов к покупке именно вашей либы бизнесом. Так и будете раз в год стыдливо о себе на хабре упоминать...
Интересно) Ведь в логику бэка все равно не реализовать на одном is, т.к. у большой системы куча микросервисов под капотом, причем реализованных не просто на разных языках, но и порой на разных поколениях стэков. В идеале, конечно не плохо бы писать на одном стеке, но это часто остаётся лишь мечтой.
Отличная статья, коррелирует с моим опытом миграции крупной БД Axapta 3.0 в "нереально сжатый срок простоя продуктива", но плюс пересчет RecId int32 (кто работал знает проблему с ограничением maxint на компанию).
Проблема людей в том, что лоукод ныне можно считать очередным панацелином.
Это конечно же не так... Ничего личного, только маркетинг.
Лоукод решения применяются уже давно в нишевых инструментах, но не везде и всюду. Всему своё место.
В SAP (ABAP) прекраснейше реализован ООП :)
Если погружение в задачи не включает в себя "приставания" к программистам в виде обязаловки рассказывать всё, что сделал и почему, а лишь чтение итоговой документации по задаче, тогда норм.
В противном случае, программист устанет от такого внимания к себе.
На счет "черных ящиков" - хорошо сказано. У техлида не должно оставаться черных ящиков на проекте.
Вы гораздо больше времени убиваете в вытягивании себя из трясины ошибок и исключений. А могли бы просто сесть на пенёк,
съесть пирожоквнимательно прочитать мануал и пройти не наступив в самые топкие места.Теперь понятно, почему вы в 30 лет задумываетесь о старости... вы устали... ошибаться. Может быть, таки последуете советам тех, кто в 30-40+ не замечал усталости?
Ну и, самое важное, после осознания важности зрелого и профессионального подхода к программированию, раз имеете контакт и влияние на маленьких программистов - учите их правильным вещам.
Ну да, конечно... зачем читать дорожные знаки, на 1002-ю, а может быть 1003-ю попытку получится)) С таким подходом вы до продуктива ничего не додеплоите.
Профессиональный программист должен наращивать теоретическую базу в качестве не зыбкого (песочного) фундамента, но прочного (железобетонного). На такой фундамент уже надежно укладывается получаемый опыт слой за слоем, образуя цитадель разума.
Построив одно надежное строение, вы также должны поступать и с новыми стеками.
В 40 лет задумываться о возрасте некогда, изучаешь что-то ежедневно допом к работе.
Думаю, что "выгорание" и "возрастные комплексы" исключительно от лени и прокрастинации.
Причем, чем зеленее поколение, тем чаще слышится нытьё и тогда думаешь, а что с тобой то не так?