Прочитал эту и предыдущую статьи. Во-первых, рад, что нашел что-то "родное", поскольку сам долго искал похожий инструмент, пробовал разные варианты. И вот увидел, что кто-то еще интерисуется этим.
Я остановился на ClickUp. Как по мне, очень мощный инструмент с множеством функций. Пользуюсь примерно полгода и до сих пор нет потребности искать другой сервис.
Статьи понравились тем, что за настройкой технической части стоит идея планирования. Сразу видно, что автор потратил немало времени на выработку своей системы основываясь не только на своем опыте, но и на разных идеях с других ресурсов. Я, например, впервые столкнулся с системой организации дел в книге Стивена Кови "Семь навыков высокоэффективных людей". С тех пор долго искал инструмент, который бы помог реализовать ту идею. Да, я люблю вещи, которые имеют свой смысл и выработаны месяцами или годами. Кстати, та книга одна из немногих, которая, как по мне, как раз и имеет смысл.
Автору успехов в этом направлении, жду новых статей.
Вполне согласен. Сам склонен получать новые знание, которы основаны более-менее научно. Но читать чисто науковые статьи очень трудно. (Они мне напоминают Terms and conditions з сайтов). В результате просто может потерятся интерес к данной области, что совсем не хочется. Побольше бы таких статей. В самом деле и интересно, и полезно. А это редко сочетается.
Я имел в виду полностью новая версия з другим ядром. В таком случае, если это фреймворк, пользователь должен будет полностью переписать свой код. Допустим, ангуляр — это новая версия реакта и он намого лучше реакта в силу своего почти идеального ядра (все это допустим). В ридми пишешь — переходите на ангуляр, он лучше реакта. Какая будет реакция сообщества и много ли людей станет использовать ангуляр зная, что автор может его в любое время бросить. Это просто как мысль.
Если библиотека — то да. Хотя все равно очень трудно будет пользователю перейти на совершенно новую версию (новую в плане изменения апи больше чем на 50%).
Я просто в каком-то смысле развивал мысль, что держась за старое не придумаешь кардинально новое (лучше).
Как по мне, интересный ход мыслей. Минимум емоций и каких то резких выводов. При чтении информация воспринимается не как истина, а как мнение автора. Это редко встречается. Большинство претендуют на истину.
Кроме того, чтение было легким и приносило удовольствие. Виглядит, как беллетристика.
Дальше (учитывая сказанное), автор пишет о неверных ожиданиях и каких-то ошибках в данной ситуации (OS). Что очень интересно. Обычно приходится слышать, как кто-то умен, потому что изобрел то или сделал это. Мало кто говорит, что он сделал не так. Я склонен думать, что всегда есть то, что сделал не так. Скрывание этого факта — идеализирование (со своими недостатками). Например, мне было полезно услышить такого рода историю, так как сам стыкнулся с подобными проблемами. В то время я попытался найти какой-то источник информации, как делать, смотрел примеры из репозиториев. Но это не дало результата. Каждый раз, когда начинал писать документацию, понимал что это набор слов для другого человека. Я, конечно, соченил что-то. Но это вышло далеко от ожиданий.
Касательно непосредственно развития своего OS проекта. Я путь автора не проходил, но были мысли о рекламе своего js фреймворка. До этого дело не дошло, так как появилась другая версия. Я бы даже сказал, полностью другой фреймворк. Потом снова полное обновление. Эти версии не похожи друг на друга. Конечно, чем больше изменений, тем больше пользы. Если бы я выкатил первую версию, я бы не выпустил вторую, потому что мне пришлось би придерживаться принципа обратной совместимости. На данном этапе разрабатываю концепцию новой версии. Не знаю, лучше ли это текущих фреймворков. Но, допустим, да — лучший. То есть, (дальше не уверен в том, том что говорю) как я вижу процесс опен сорс проектов. Перед выходом первой версии планируется архитектура соотвественно текщим технологиям и требованиям. Эта версия выходит. И все — через принцип обратной совместимости не возможно полное изменение проекта. То есть он в какой-то мере обречен. И не только по этой причине. Нововведения будут рассматриваться в контексте текущего проекта (оперируя существующими терминами: «компонент», «сервис», «модель»). Маловероятно полное изменение кода. Почему это нужно? Придерживаясь текущего кода проекта предполагается, что его базис идеален. Хорошо, если так. Но сомневаюсь, что есть идеальный код. Да, ангуляр изменил первую версию. Это указывает на то, что это (полное изменение кода) лучше, чем придерживание старых концепций. Но много ли таких примеров?
Публикация новой версии хорошо. Обычно, это изменение каких-то очевидных вещей. Но мало-кто оценивает опыт проекта как источник иформации. Информации, что и почему не работает идеально и, возможно, как можно это изменить. Изменить не в текущем проекте. А в новом. Что дает полною свободу.
Да, трудно кинуть проект и пойти разрабатывать что-то новое, потому-что есть количество пользователей который ожидают, что проект будет поддерживаться. Но. Согласны ли мы придерживать развитие технологий по этой причине. По крайней мере, можно просто попытаться решить эту проблему или обойти ее.
Отличная статья. Хотя основная тема все таки про микросервисы, я для себя взял извлек и другой смысл. Сам очень много раздумываю, как сразу писать хороший код. Обычно над проектами работаю сам, и в какой то момент замечаю, что код находится не в лучшем состоянии. Спешки на проектах никогда нет, у меня достаточно времени, чтобы думать о том что писать. То есть, ожидалось, что код не будет похож на спагетти, но он почему-то похож. А похож, потому-что, как здесь и говорится, нельзя (трудно) предвидить развитие проекта. Вот начинаешь писать класс, создал несколько методов. Потом в один метод надо добавить еще один аргумент, потом еще одно условие, потом создать дочерний метод. В результате, видиш — это все тянет на отдельный класс. Но как это предвидеть изначально. А есть методы, которые вообще не меняются. Может, это с опытом таких вещей становится меньше, а может так и должно быть.
Вкратце, хочется просчитать все моменты и заложить немного наперед. Но это очень сложно (невозможно). Хотя это, конечно, не значить, что не нужно думать вообще.
Прочитал эту и предыдущую статьи. Во-первых, рад, что нашел что-то "родное", поскольку сам долго искал похожий инструмент, пробовал разные варианты. И вот увидел, что кто-то еще интерисуется этим.
Я остановился на ClickUp. Как по мне, очень мощный инструмент с множеством функций. Пользуюсь примерно полгода и до сих пор нет потребности искать другой сервис.
Статьи понравились тем, что за настройкой технической части стоит идея планирования. Сразу видно, что автор потратил немало времени на выработку своей системы основываясь не только на своем опыте, но и на разных идеях с других ресурсов. Я, например, впервые столкнулся с системой организации дел в книге Стивена Кови "Семь навыков высокоэффективных людей". С тех пор долго искал инструмент, который бы помог реализовать ту идею. Да, я люблю вещи, которые имеют свой смысл и выработаны месяцами или годами. Кстати, та книга одна из немногих, которая, как по мне, как раз и имеет смысл.
Автору успехов в этом направлении, жду новых статей.
Если библиотека — то да. Хотя все равно очень трудно будет пользователю перейти на совершенно новую версию (новую в плане изменения апи больше чем на 50%).
Я просто в каком-то смысле развивал мысль, что держась за старое не придумаешь кардинально новое (лучше).
Кроме того, чтение было легким и приносило удовольствие. Виглядит, как беллетристика.
Дальше (учитывая сказанное), автор пишет о неверных ожиданиях и каких-то ошибках в данной ситуации (OS). Что очень интересно. Обычно приходится слышать, как кто-то умен, потому что изобрел то или сделал это. Мало кто говорит, что он сделал не так. Я склонен думать, что всегда есть то, что сделал не так. Скрывание этого факта — идеализирование (со своими недостатками). Например, мне было полезно услышить такого рода историю, так как сам стыкнулся с подобными проблемами. В то время я попытался найти какой-то источник информации, как делать, смотрел примеры из репозиториев. Но это не дало результата. Каждый раз, когда начинал писать документацию, понимал что это набор слов для другого человека. Я, конечно, соченил что-то. Но это вышло далеко от ожиданий.
Касательно непосредственно развития своего OS проекта. Я путь автора не проходил, но были мысли о рекламе своего js фреймворка. До этого дело не дошло, так как появилась другая версия. Я бы даже сказал, полностью другой фреймворк. Потом снова полное обновление. Эти версии не похожи друг на друга. Конечно, чем больше изменений, тем больше пользы. Если бы я выкатил первую версию, я бы не выпустил вторую, потому что мне пришлось би придерживаться принципа обратной совместимости. На данном этапе разрабатываю концепцию новой версии. Не знаю, лучше ли это текущих фреймворков. Но, допустим, да — лучший. То есть, (дальше не уверен в том, том что говорю) как я вижу процесс опен сорс проектов. Перед выходом первой версии планируется архитектура соотвественно текщим технологиям и требованиям. Эта версия выходит. И все — через принцип обратной совместимости не возможно полное изменение проекта. То есть он в какой-то мере обречен. И не только по этой причине. Нововведения будут рассматриваться в контексте текущего проекта (оперируя существующими терминами: «компонент», «сервис», «модель»). Маловероятно полное изменение кода. Почему это нужно? Придерживаясь текущего кода проекта предполагается, что его базис идеален. Хорошо, если так. Но сомневаюсь, что есть идеальный код. Да, ангуляр изменил первую версию. Это указывает на то, что это (полное изменение кода) лучше, чем придерживание старых концепций. Но много ли таких примеров?
Публикация новой версии хорошо. Обычно, это изменение каких-то очевидных вещей. Но мало-кто оценивает опыт проекта как источник иформации. Информации, что и почему не работает идеально и, возможно, как можно это изменить. Изменить не в текущем проекте. А в новом. Что дает полною свободу.
Да, трудно кинуть проект и пойти разрабатывать что-то новое, потому-что есть количество пользователей который ожидают, что проект будет поддерживаться. Но. Согласны ли мы придерживать развитие технологий по этой причине. По крайней мере, можно просто попытаться решить эту проблему или обойти ее.
Вкратце, хочется просчитать все моменты и заложить немного наперед. Но это очень сложно (невозможно). Хотя это, конечно, не значить, что не нужно думать вообще.