Наконец-то кто-то тоже понял, что не обязательно закупаться Mac Mini!) Недавно поднимал на raspberry, но было полно проблем при подключении браузера (плюс там нет полноценного хрома, для Firefox тоже не завелось), у вас получилось его завести?
Базовый пользователь ПК? Уверены, что поняли о чем комментарий? Дайте "базовому пользователю ПК" подписку на модную нейронку и поставьте задачу собрать веб приложение сложнее чем todo-list (не говоря о десктопе, мобилке и тем более прошивки для разной встройки и умных устройств) узнаете много интересного. Да и слегка охладите уровень ваших впечатлений. Вот вам небольшой инсайд, даже джуны не всегда справляются в паре с мощной нейронкой. Знания архитектуры, накопленный опыт разработки, понимание языков, памяти, бизнеса, UX, основы безопасности и много чего ещё придется впитать "базовому пользователю ПК", чтобы собрать с нейронкам нечто стоящее и жизнеспособное. Просто чтобы хоть что-то понять, запуская сгенерированный проект.
Здесь скорее имели в виду просто следующий уровень абстракции над языками в виде прослойки с нейросетями. Некий DSL для общения, который тоже надо будет изучать и уметь пользоваться и развивать.
А со стороны экономики многие уже давно пускают слюну на супер автоматизированную разработку, когда можно будет урезать ФОТ до уровня подписки на Claude. Но пока эти прекрасные времена не наступили, а когда наступят, все равно нужны будут опытные инженеры, чтобы подтирать косяки генерации, проектировать архитектуру и управлять пулом агентов, чтобы ничего лишнего не натворили.
На полном серьёзе автор написал абзац про совесть и использовал подобное сравнение. А про совесть и ответственность нанимающей стороны?
Для начала. Если автор не в курсе, то почти у каждого разработчика по мере прохождения собеседований, переходов между компаниями, копится свой набор "шпор", с темами или конкретными вопросами - это нормально, мозг не резиновый, чтобы держать все в голове. Освежить память при подготовке всегда полезно. Плюс, оказывается, некоторые технологии и подходы могут забываться со временем, в зависимости от задач на текущей работе. А ещё нормально обмениваться этими шпорами с коллегами и знакомыми из сообщества, представляете? Через какое-то время у многих появляются такие контакты, люди общаются, делятся знаниями, интересуются как дела в команде в других компаниях, это тоже нормально. И из-за этого надо думать о совести? Я так не считаю. Так что не все волки вокруг.
В качестве продолжения. Ещё пару-тройку лет назад уже было мало шансов попасть на адекватный процесс отбора/найма. И уже тогда был смысл подготовки по шаблонам, но не для того, чтобы "волчить", а для того, чтобы пройти этот фильтр бесполезных вопросов как можно быстрее. Пораньше перейти к нормальной части собеседования. Чем быстрее и чётче ты отвечаешь на стандартный список вопросов, тем раньше собеседование перейдет в адекватное русло и начнется разговор о реальном опыте (если конечно у интервьюера есть что спросить, кроме заранее собранной анкеты), копание в твоих актуальных знаниях и навыках, интересные задачи на подумать, по которым тебя можно оценить адекватно. И это не раз было проведено на личном опыте.
Звучит очень даже неплохо, подскажите пожалуйста свой стек и направление в целом? Backend/Frontend или что-то другое? Правда интересно, потому что сейчас наблюдаю очень разный уровень "понимания" со стороны нейронок в зависимости от того, в каком направлении разработки и с какими фреймворками проект
Видел) В паре проектов за последние лет пять. Но есть нюансы.
Первый без этих подходов просто не работал бы. Сложность логики подразумевала, что нахрапом и тем же KISS не решить, в итоге первые пару недель ты плюешься от этого кода и его структуры, а когда все понял, осознаешь, что по-другому это просто невозможно написать. Первый раз в жизни, когда желание отрефачить чей-то код полностью пропало.
Второй - проект с нуля с очень сильной командой, начали с основательной проработки архитектуры и подходов, что помогло нам через полгода. Скорость поддержки и починки багов отличалась местами в несколько раз, по сравнению с аналогичной старой фичей, чисто за счёт грамотной, хоть и сложной архитектуры.
За шутки автору конечно спасибо. Но в целом, суть поста, можно уложить в одну мысль - чистота/архитектура должны быть применимы к конкретной задаче и условиям, а не раскатываться повсеместно по принципу чисто/красиво, потому что так надо или в умной книжке написано. Код должен быть максимально понятным и простым, насколько это позволяет задача, соблюдая баланс между чистотой - простотой поддержки - читаемостью. Надо писать так, что если завтра отшибает память, ты сможешь понять то, что ты написал и продолжить поддержку.
Часто вижу критику этих книг от разных авторов, коллег, разработчиков, из-за чего возникает ощущение, что они их не читали или не поняли смысл до конца. Это просто рекомендации и базовые принципы, которые должен знать разработчик, но при этом уметь понимать, когда и какой из этих принципов применим в той или иной ситуации.
Сам не раз в работе видел красиво написанный код, от адептов супер архитектурных подходов с кучей прослоек/абстракций/компонентов/модулей. Только почему-то этот код был написан для решения простейших задач на пару-тройку классов. И без наличия этих адептов в команде все сразу превращалось в абсолютно не поддерживаемую, перегруженную кашу.
Могу слегка помочь автору. Часть боли он уже сказал, это webView и работа с картами. Где ещё могут быть небольшие трудности:
Переезд мышления на парадигму UDF (https://developer.android.com/develop/ui/compose/architecture), имутабельный интерфейс и необходимость привыкнуть к тому, что все изменения UI, это изменение стейта,
Переходный период миграции на Compose в большом проекте. Какое-то время будет зоопарк из классических Fragment + View, и Compose. Все переезжают по-разному, но как по мне, самый безопасный вариант, это не встройка отдельных Compose View, а переписывание всего контента на Compose в рамках одного Fragment.
Часть стандартных компонентов из Compose Material имеют встроенные padding/margin, которые не убрать через modifier.
Не совсем привычная работа с BottomSheet и ему подобными
Работа с modifier (фон, отступы, рамки и прочее), где на внешний вид влияет порядок вызова модификаторов. Первое время надо будет привыкать
Scope родительской Compostable функции, который определяет возможности части modifier вложенных элементов. Для кастомных UI элементов, иногда нужно явно указывать Scope родительского контейнера, чтобы применять нужные модификаторы (modifier)
Но все это решаемо, описано в официальной документации или давно разобрано сообществом. Поэтому больших трудности при миграции не будет. А новый проект/фичу написать на Compose будет ещё проще
Не про тех пиратов ожидал увидеть пост. Если по полочкам:
Автор утверждает, что пишет уже много лет. Возникает вопрос, почему тогда эта статья так трудно и нудно читается. Опыт автора не чувствуется при прочтении
Возможно это взгляд из моего личного пузыря, но что я, что мое окружение часто покупает физические издания понравившихся книг, либо используют тот же ЛитРес с аналогами. Только вот проблема, не всегда нужное произведение есть в наличии или в том же ЛитРес, как читать? Терпеть пока появится?
Проблема современной литературы не в пиратах, а в ее содержании. Художественная или документальная, не важно, часто это просто сложно воспринимать из-за слога и структуры повествования, либо из-за отсутствия свежих идей, качественной переработки старых
Пираты помогают сохранить историю и дать доступ тем, у кого нет возможности покупать книги в цифре или физические, а ещё порой выступают в качестве переводчиков, что тоже немаловажно
Как обычный читатель, я бы порекомендовал автору попробовать либо новые способы распространения контента, либо новые темы для литературного творчества, возможно найти более подходящий жанр. А так, всю историю быть писателем является не таким уж простым призванием. И вот здесь я действительно уважаю ваш выбор
А я просто пришел сказать спасибо за интересную статью. Не со всеми идеями согласен, но в любом случае приятно видеть действительно профильный контент на Хабре.
З.Ы.: Почему не со всем согласен, часто, но далеко не всегда нужно строгое разделение и множество абстракций. Команда должна это отслеживать и держать необходимый для них самих уровень абстракции. В общем как всегда - суть в балансе, который индивидуален для команды/проекта/направления продукта. Повидал не мало кода, где как раз таки чистую архитектуру воспринимали более важной, по сравнению с самой логикой, в итоге через год невозможно было распутать даже простые обращения к серверу или БД
Храбр не жалобная книга, но жалобная публикация появилась. Кажется качество контента постепенно перетекает в филиал Пикабу. А если по теме - Ваша безопасность, это в первую очередь Ваша ответственность, включающая не только знание кредов, но и знание требований/ограничений сервисов и продуктов, которыми пользуетесь. Чем больше в сети менее технически подготовленных пользователей - тем сложнее и муторнее правила безопасности для более подкованных, потому что любые правила будут ориентироваться в первую очередь на самое слабое звено. Если бы до сих пор все было только на кредах, вместо этой публикации появилась бы другая, на тему "У моей тётушки украли пароль от банка, почему безопасники не придумали более надёжный способ входа в аккаунт",
Позволю себе немного ворваться в обсуждение. По прошлому опыту, из наших систем, с точки зрения интеграции, более точной настройки и адекватной поддержки от вендора, имхо, решения от Positive Technologies одни из самых удобных и функциональных. На момент когда работали с ними, параллельно внедряли решения от Check Point и Fortinet, было с чем сравнивать. Но тогда не хватало фичей, по сравнению с зарубежными аналогами
Немного не хватает подробностей основной задачи, которая решается этим железом и описания модулей. Не все знают что и для чего NRF. А так почему бы и нет, кому-то эта статья точно пригодится. В любом случае это лучше, чем переведенные нечитабельные статьи без указания оригинала, которые частенько попадаются на Хабре.
Позволю себе ворваться, т.к. вижу комментарии на тему китайских аналогов, зачем нужна такая если есть мембранки и прочее.
Несколько лет (минимум 4) пользуюсь механикой Keychron K2 с тихими свичами. Металлическая рама - реально решает в плане прочности и устойчивости, все живое до сих пор, стоит уверенно и не сдвигается от порыва ветра или пинка по столу как дешёвые пластиковые варианты. Плата там тоже отличная, никаких косяков по части прошивки, даже пользуюсь фичами с запоминанием устройств, к которым подключается клавиатура. Наличие понимания ОС девайса тоже штука полезная. По беспроводу соединение стабильное. Батарею держит очень хорошо, даже не могу вспомнить насколько часто ее заряжаю.
Китайские аналоги есть - проживут они точно меньше.
В плане дизайна - на вкус и цвет у всех фломастеры будут разные, тут цепляться вообще нет смысла. А если глянуть на "моду", то там как раз возвращаются к старой классике
Разрекламированные игровые и "профессиональные" варианты других брендов будут дороже, а качество такое же.
Так что в целом - Keychron сейчас близко к золотой середине в плане цена-качество-функционал
Спасибо! Попробую с ними повозиться.
Наконец-то кто-то тоже понял, что не обязательно закупаться Mac Mini!) Недавно поднимал на raspberry, но было полно проблем при подключении браузера (плюс там нет полноценного хрома, для Firefox тоже не завелось), у вас получилось его завести?
Базовый пользователь ПК? Уверены, что поняли о чем комментарий? Дайте "базовому пользователю ПК" подписку на модную нейронку и поставьте задачу собрать веб приложение сложнее чем todo-list (не говоря о десктопе, мобилке и тем более прошивки для разной встройки и умных устройств) узнаете много интересного. Да и слегка охладите уровень ваших впечатлений. Вот вам небольшой инсайд, даже джуны не всегда справляются в паре с мощной нейронкой. Знания архитектуры, накопленный опыт разработки, понимание языков, памяти, бизнеса, UX, основы безопасности и много чего ещё придется впитать "базовому пользователю ПК", чтобы собрать с нейронкам нечто стоящее и жизнеспособное. Просто чтобы хоть что-то понять, запуская сгенерированный проект.
Здесь скорее имели в виду просто следующий уровень абстракции над языками в виде прослойки с нейросетями. Некий DSL для общения, который тоже надо будет изучать и уметь пользоваться и развивать.
А со стороны экономики многие уже давно пускают слюну на супер автоматизированную разработку, когда можно будет урезать ФОТ до уровня подписки на Claude. Но пока эти прекрасные времена не наступили, а когда наступят, все равно нужны будут опытные инженеры, чтобы подтирать косяки генерации, проектировать архитектуру и управлять пулом агентов, чтобы ничего лишнего не натворили.
На полном серьёзе автор написал абзац про совесть и использовал подобное сравнение. А про совесть и ответственность нанимающей стороны?
Для начала. Если автор не в курсе, то почти у каждого разработчика по мере прохождения собеседований, переходов между компаниями, копится свой набор "шпор", с темами или конкретными вопросами - это нормально, мозг не резиновый, чтобы держать все в голове. Освежить память при подготовке всегда полезно. Плюс, оказывается, некоторые технологии и подходы могут забываться со временем, в зависимости от задач на текущей работе. А ещё нормально обмениваться этими шпорами с коллегами и знакомыми из сообщества, представляете? Через какое-то время у многих появляются такие контакты, люди общаются, делятся знаниями, интересуются как дела в команде в других компаниях, это тоже нормально. И из-за этого надо думать о совести? Я так не считаю. Так что не все волки вокруг.
В качестве продолжения. Ещё пару-тройку лет назад уже было мало шансов попасть на адекватный процесс отбора/найма. И уже тогда был смысл подготовки по шаблонам, но не для того, чтобы "волчить", а для того, чтобы пройти этот фильтр бесполезных вопросов как можно быстрее. Пораньше перейти к нормальной части собеседования. Чем быстрее и чётче ты отвечаешь на стандартный список вопросов, тем раньше собеседование перейдет в адекватное русло и начнется разговор о реальном опыте (если конечно у интервьюера есть что спросить, кроме заранее собранной анкеты), копание в твоих актуальных знаниях и навыках, интересные задачи на подумать, по которым тебя можно оценить адекватно. И это не раз было проведено на личном опыте.
"уже забыл, когда код руками писал"
Звучит очень даже неплохо, подскажите пожалуйста свой стек и направление в целом? Backend/Frontend или что-то другое? Правда интересно, потому что сейчас наблюдаю очень разный уровень "понимания" со стороны нейронок в зависимости от того, в каком направлении разработки и с какими фреймворками проект
В зависимости от модели и типа аккумулятора корпуса могут немного отличаться, но уже есть проекты для печати. Например вот эти:
https://meshtastic.org/docs/community/enclosures/lilygo-lora32-v2-enclosures/
https://cults3d.com/ru/3d-model/gadzhet/casing-for-ttgo-esp32-lora-board-t22_v1-1-version
https://www.printables.com/model/909635-lilygo-ttgo-t3-case-with-disposable-vaper-battery
https://www.printables.com/model/819584-ttgo-lora32-t3-18650-case
Видел) В паре проектов за последние лет пять. Но есть нюансы.
Первый без этих подходов просто не работал бы. Сложность логики подразумевала, что нахрапом и тем же KISS не решить, в итоге первые пару недель ты плюешься от этого кода и его структуры, а когда все понял, осознаешь, что по-другому это просто невозможно написать. Первый раз в жизни, когда желание отрефачить чей-то код полностью пропало.
Второй - проект с нуля с очень сильной командой, начали с основательной проработки архитектуры и подходов, что помогло нам через полгода. Скорость поддержки и починки багов отличалась местами в несколько раз, по сравнению с аналогичной старой фичей, чисто за счёт грамотной, хоть и сложной архитектуры.
За шутки автору конечно спасибо. Но в целом, суть поста, можно уложить в одну мысль - чистота/архитектура должны быть применимы к конкретной задаче и условиям, а не раскатываться повсеместно по принципу чисто/красиво, потому что так надо или в умной книжке написано. Код должен быть максимально понятным и простым, насколько это позволяет задача, соблюдая баланс между чистотой - простотой поддержки - читаемостью. Надо писать так, что если завтра отшибает память, ты сможешь понять то, что ты написал и продолжить поддержку.
Часто вижу критику этих книг от разных авторов, коллег, разработчиков, из-за чего возникает ощущение, что они их не читали или не поняли смысл до конца. Это просто рекомендации и базовые принципы, которые должен знать разработчик, но при этом уметь понимать, когда и какой из этих принципов применим в той или иной ситуации.
Сам не раз в работе видел красиво написанный код, от адептов супер архитектурных подходов с кучей прослоек/абстракций/компонентов/модулей. Только почему-то этот код был написан для решения простейших задач на пару-тройку классов. И без наличия этих адептов в команде все сразу превращалось в абсолютно не поддерживаемую, перегруженную кашу.
Могу слегка помочь автору. Часть боли он уже сказал, это webView и работа с картами. Где ещё могут быть небольшие трудности:
Переезд мышления на парадигму UDF (https://developer.android.com/develop/ui/compose/architecture), имутабельный интерфейс и необходимость привыкнуть к тому, что все изменения UI, это изменение стейта,
Переходный период миграции на Compose в большом проекте. Какое-то время будет зоопарк из классических Fragment + View, и Compose. Все переезжают по-разному, но как по мне, самый безопасный вариант, это не встройка отдельных Compose View, а переписывание всего контента на Compose в рамках одного Fragment.
Часть стандартных компонентов из Compose Material имеют встроенные padding/margin, которые не убрать через modifier.
Не совсем привычная работа с BottomSheet и ему подобными
Работа с modifier (фон, отступы, рамки и прочее), где на внешний вид влияет порядок вызова модификаторов. Первое время надо будет привыкать
Scope родительской Compostable функции, который определяет возможности части modifier вложенных элементов. Для кастомных UI элементов, иногда нужно явно указывать Scope родительского контейнера, чтобы применять нужные модификаторы (modifier)
Во время миграции могут возникнуть проблемы с влиянием жизненного цикла Fragment/Activity на отрисовку Compose внутри (https://medium.com/@tangkegaga/why-viewcompositionstrategy-compose-and-view-work-together-905933a8ac99)
Для более оптимальной работы Compose ещё стоит получше изучить рекомпозицию и стабильные функции (https://habr.com/ru/companies/yandex/articles/841154/)
Но все это решаемо, описано в официальной документации или давно разобрано сообществом. Поэтому больших трудности при миграции не будет. А новый проект/фичу написать на Compose будет ещё проще
Не про тех пиратов ожидал увидеть пост. Если по полочкам:
Автор утверждает, что пишет уже много лет. Возникает вопрос, почему тогда эта статья так трудно и нудно читается. Опыт автора не чувствуется при прочтении
Возможно это взгляд из моего личного пузыря, но что я, что мое окружение часто покупает физические издания понравившихся книг, либо используют тот же ЛитРес с аналогами. Только вот проблема, не всегда нужное произведение есть в наличии или в том же ЛитРес, как читать? Терпеть пока появится?
Проблема современной литературы не в пиратах, а в ее содержании. Художественная или документальная, не важно, часто это просто сложно воспринимать из-за слога и структуры повествования, либо из-за отсутствия свежих идей, качественной переработки старых
Пираты помогают сохранить историю и дать доступ тем, у кого нет возможности покупать книги в цифре или физические, а ещё порой выступают в качестве переводчиков, что тоже немаловажно
Как обычный читатель, я бы порекомендовал автору попробовать либо новые способы распространения контента, либо новые темы для литературного творчества, возможно найти более подходящий жанр. А так, всю историю быть писателем является не таким уж простым призванием. И вот здесь я действительно уважаю ваш выбор
А я просто пришел сказать спасибо за интересную статью. Не со всеми идеями согласен, но в любом случае приятно видеть действительно профильный контент на Хабре.
З.Ы.: Почему не со всем согласен, часто, но далеко не всегда нужно строгое разделение и множество абстракций. Команда должна это отслеживать и держать необходимый для них самих уровень абстракции. В общем как всегда - суть в балансе, который индивидуален для команды/проекта/направления продукта. Повидал не мало кода, где как раз таки чистую архитектуру воспринимали более важной, по сравнению с самой логикой, в итоге через год невозможно было распутать даже простые обращения к серверу или БД
Храбр не жалобная книга, но жалобная публикация появилась. Кажется качество контента постепенно перетекает в филиал Пикабу. А если по теме - Ваша безопасность, это в первую очередь Ваша ответственность, включающая не только знание кредов, но и знание требований/ограничений сервисов и продуктов, которыми пользуетесь. Чем больше в сети менее технически подготовленных пользователей - тем сложнее и муторнее правила безопасности для более подкованных, потому что любые правила будут ориентироваться в первую очередь на самое слабое звено. Если бы до сих пор все было только на кредах, вместо этой публикации появилась бы другая, на тему "У моей тётушки украли пароль от банка, почему безопасники не придумали более надёжный способ входа в аккаунт",
Позволю себе немного ворваться в обсуждение. По прошлому опыту, из наших систем, с точки зрения интеграции, более точной настройки и адекватной поддержки от вендора, имхо, решения от Positive Technologies одни из самых удобных и функциональных. На момент когда работали с ними, параллельно внедряли решения от Check Point и Fortinet, было с чем сравнивать. Но тогда не хватало фичей, по сравнению с зарубежными аналогами
Немного не хватает подробностей основной задачи, которая решается этим железом и описания модулей. Не все знают что и для чего NRF. А так почему бы и нет, кому-то эта статья точно пригодится. В любом случае это лучше, чем переведенные нечитабельные статьи без указания оригинала, которые частенько попадаются на Хабре.
Простите, но проще читать оригинал статьи, нежели машинный перевод без редактуры. Слишком много этого последнее время на Хабре стало
Позволю себе ворваться, т.к. вижу комментарии на тему китайских аналогов, зачем нужна такая если есть мембранки и прочее.
Несколько лет (минимум 4) пользуюсь механикой Keychron K2 с тихими свичами. Металлическая рама - реально решает в плане прочности и устойчивости, все живое до сих пор, стоит уверенно и не сдвигается от порыва ветра или пинка по столу как дешёвые пластиковые варианты. Плата там тоже отличная, никаких косяков по части прошивки, даже пользуюсь фичами с запоминанием устройств, к которым подключается клавиатура. Наличие понимания ОС девайса тоже штука полезная. По беспроводу соединение стабильное. Батарею держит очень хорошо, даже не могу вспомнить насколько часто ее заряжаю.
Китайские аналоги есть - проживут они точно меньше.
В плане дизайна - на вкус и цвет у всех фломастеры будут разные, тут цепляться вообще нет смысла. А если глянуть на "моду", то там как раз возвращаются к старой классике
Разрекламированные игровые и "профессиональные" варианты других брендов будут дороже, а качество такое же.
Так что в целом - Keychron сейчас близко к золотой середине в плане цена-качество-функционал