Когда я был молодым и глупым у меня была идея крутой библиотеки, для работы с протоколом STOMP. Если кто не знает протокол STOMP это просто набор правил для работы с подписками на данные, который работает поверх Websocket. У этого протокола очень простая спецификация и он очень удобен когда нужно что-то сделать быстро и не охото придумывать свой велосипед.
Для бэкенда и фронта есть целый набор готовых решений. Однако для Android готовых решений нет. Хотя конечно есть, но чаще всего это забагованные, неудобные решения, разработчики которых давно забили на поддержку. И вот, казалось бы, я нашел крутую идею для библиотеки, которая решает реальную проблему. Можно просто сделать библиотеку с более менее удобным API и стать вторым Джэйком Вортоном.
Радостный сажусь я пилить эту библиотеку. Разумеется я как хороший разработчик сначала должен разработать крутую архитектуру библиотеки, чтобы не стыдно было показать. Затем желательно не завязываться на rx и корутины, а сделать отельные модули для этого, как у настоящих крутых библиотек.
Я придумал архитектуру. Как мне казалась, учел все принципы SOLID, KISS, YAGNI, FizzBuzz, CQS. После начал придумывать API, ведь библиотекой должно быть максимально удобно пользоваться. Думал очень долго иии так и не придумал. Библиотеку в итоге я так и не сделал.
Причина почему я перестал делать либу, заключается в том, что у меня началась дикая прокрастинация. Садясь разрабатывать либу, я думал не о том как быстрее решить задачу, а том как сделать супер гибкую архитектуру и код который было бы не стыдно показать.
Я кучу времени убил на чтения кода крутых библиотек, и каждый раз я начинал сравнивать свои решения с решениями авторов крутых либ. Разница была похожа на гиганскую пропасть. Казалось что создать такую же крутую библиотеку просто нереально. Код библиотек был очень вылизанный, учитывал миллионы корнер кейсов. Я пытался использовать их решения и в итоге выгорел и сдался.
Я это вот к чему, если начинаете разрабатывать какую-то либу, или вообще вы только обучаетесь не страдайте этой фигней, это так не работает. Если хотите что-то сделать и не знаете как, сделайте как-то, но сделайте и не думайте о том, как этот код будет выглядеть. Если у вас еще мало опыта, сколько бы вы не думали над архитектурой, сколько бы вы не читали чужой вы все равно сделаете хрень.
После я конечно понял почему код тех библиотек был такой крутой и обрабатывал все возможные случаи. Просто эти библиотеки уже долго на рынке и ими пользуется куча людей. Их код переписывался множество раз, и фиксилось куча багов которые прилетали от других разрабов. Серьезно вспомните сколько версий у RxJava, у OkHttp?
Невозможно сразу при создании какого-то решения учесть все, особенно когда у вас нет большого опыта. Поэтому лучше всего сначала что-то сделать, попробовать этим попользоваться. И только потом, если решение багует и оно неудобное начать его улучшать. Только в этом случае вы будете точно представлять что конкретно нужно улучить.
Крутыми разработчиками не становятся думая над архитектурой 3 года и потом выдавая супер мега решение со всеми корнер кейсами. Это работает с религией или философией, но в разработке это происходит так: Сделали какое-то решение -> Обосрались -> Порефлексировали -> Исправили косяки -> Повторили
Причем это работает не только с разработкой библиотек. В бизнесе это называют MVP. Так работает Agile, так развиваются архитектуры в уже существующих проектах. На текущем проекте где я работаю уже 3-я версия архитектуры. Это при том, что это одна из топовых мобильных команд в России.
По этой причине никто не поставит архитектором джуна, насколько бы умным он не был. Архитекторами поэтому и становятся матерые разрабы которые уже видели некоторое дерьмо и проходили этот цикл кучу раз. Их нейронка уже натренирована видеть хорошие решения и плохие которые могут в дальнейшем стрельнуть. И натренировать такую нейронку можно только пробуя и что-то делая.
Подводя некоторый итог. Хотите быстрее двигаться, делайте что-то, даже если не знаете как сделать хорошо все равно делайте.
Когда я был молодым и глупым у меня была идея крутой библиотеки, для работы с протоколом STOMP. Если кто не знает протокол STOMP это просто набор правил для работы с подписками на данные, который работает поверх Websocket. У этого протокола очень простая спецификация и он очень удобен когда нужно что-то сделать быстро и не охото придумывать свой велосипед.
Для бэкенда и фронта есть целый набор готовых решений. Однако для Android готовых решений нет. Хотя конечно есть, но чаще всего это забагованные, неудобные решения, разработчики которых давно забили на поддержку. И вот, казалось бы, я нашел крутую идею для библиотеки, которая решает реальную проблему. Можно просто сделать библиотеку с более менее удобным API и стать вторым Джэйком Вортоном.
Радостный сажусь я пилить эту библиотеку. Разумеется я как хороший разработчик сначала должен разработать крутую архитектуру библиотеки, чтобы не стыдно было показать. Затем желательно не завязываться на rx и корутины, а сделать отельные модули для этого, как у настоящих крутых библиотек.
Я придумал архитектуру. Как мне казалась, учел все принципы SOLID, KISS, YAGNI, FizzBuzz, CQS. После начал придумывать API, ведь библиотекой должно быть максимально удобно пользоваться. Думал очень долго иии так и не придумал. Библиотеку в итоге я так и не сделал.
Причина почему я перестал делать либу, заключается в том, что у меня началась дикая прокрастинация. Садясь разрабатывать либу, я думал не о том как быстрее решить задачу, а том как сделать супер гибкую архитектуру и код который было бы не стыдно показать.
Я кучу времени убил на чтения кода крутых библиотек, и каждый раз я начинал сравнивать свои решения с решениями авторов крутых либ. Разница была похожа на гиганскую пропасть. Казалось что создать такую же крутую библиотеку просто нереально. Код библиотек был очень вылизанный, учитывал миллионы корнер кейсов. Я пытался использовать их решения и в итоге выгорел и сдался.
Я это вот к чему, если начинаете разрабатывать какую-то либу, или вообще вы только обучаетесь не страдайте этой фигней, это так не работает. Если хотите что-то сделать и не знаете как, сделайте как-то, но сделайте и не думайте о том, как этот код будет выглядеть. Если у вас еще мало опыта, сколько бы вы не думали над архитектурой, сколько бы вы не читали чужой вы все равно сделаете хрень.
После я конечно понял почему код тех библиотек был такой крутой и обрабатывал все возможные случаи. Просто эти библиотеки уже долго на рынке и ими пользуется куча людей. Их код переписывался множество раз, и фиксилось куча багов которые прилетали от других разрабов. Серьезно вспомните сколько версий у RxJava, у OkHttp?
Невозможно сразу при создании какого-то решения учесть все, особенно когда у вас нет большого опыта. Поэтому лучше всего сначала что-то сделать, попробовать этим попользоваться. И только потом, если решение багует и оно неудобное начать его улучшать. Только в этом случае вы будете точно представлять что конкретно нужно улучить.
Крутыми разработчиками не становятся думая над архитектурой 3 года и потом выдавая супер мега решение со всеми корнер кейсами. Это работает с религией или философией, но в разработке это происходит так: Сделали какое-то решение -> Обосрались -> Порефлексировали -> Исправили косяки -> Повторили
Причем это работает не только с разработкой библиотек. В бизнесе это называют MVP. Так работает Agile, так развиваются архитектуры в уже существующих проектах. На текущем проекте где я работаю уже 3-я версия архитектуры. Это при том, что это одна из топовых мобильных команд в России.
По этой причине никто не поставит архитектором джуна, насколько бы умным он не был. Архитекторами поэтому и становятся матерые разрабы которые уже видели некоторое дерьмо и проходили этот цикл кучу раз. Их нейронка уже натренирована видеть хорошие решения и плохие которые могут в дальнейшем стрельнуть. И натренировать такую нейронку можно только пробуя и что-то делая.
Подводя некоторый итог. Хотите быстрее двигаться, делайте что-то, даже если не знаете как сделать хорошо все равно делайте.
End-to-end encryption is an important feature in messaging, as it's the first step in protecting users from surveillance. The Standard Channel Select: Settings – Manage Channel – Administrators – Add administrator. From your list of subscribers, select the correct user. A new window will appear on the screen. Check the rights you’re willing to give to your administrator. Add up to 50 administrators There have been several contributions to the group with members posting voice notes of screaming, yelling, groaning, and wailing in different rhythms and pitches. Calling out the “degenerate” community or the crypto obsessives that engage in high-risk trading, Co-founder of NFT renting protocol Rentable World emiliano.eth shared this group on his Twitter. He wrote: “hey degen, are you stressed? Just let it out all out. Voice only tg channel for screaming”.
from us
