PowerPoint отлично умеет такие штуки собирать. Диаграмма такого типа рисуется либо через "Солнечные лучи", либо через "Лепестковую" - смотря, что больше понравится.
Заголовок, конечно, можно трактовать по-всякому, но все же он не отражает сути статьи. Да, есть «часть 1», но масштабирование команды - это не просто объёмный найм. Тут нужно, чтобы эта конструкция заработала.
Вы предполагаете, что «Сеньор ведет тестовую документацию, передает ее в разработку. Это человек, который влияет на проект, может быть ментором для начинающих специалистов». Через что он влияет? В чем его «сеньорность»? Тут кроме менторства скорее некий аналитик вырисовывается, который в пару раз дешевле сеньора.
как мы за 5 месяцев набрали 28 начинающих специалистов, обучили и через 3 месяца получили миддлов.
Middle определяется опытом, а не объёмом умных фраз, вброшенных в голову джуна. За три месяца можно существенно продвинуться в сторону Middle-а, но на рынке это будет всё тот же джун. Да, он/она может научиться решать типовые задачи в рамках вверенной области кода. Но кто будет проверять качество, потенциал роста и тп? На 28 джунов нужно как минимум ещё 14 менторов, чтобы они могли направлять и растить, а ещё не давали превратить продукт в кодовую помойку. И получается, что масштабирование джунами - это не такой уж и дешёвый путь.
Круто разделять статьи на части, когда каждая часть несёт некую ценность. А тут пока outcome в том, что Вы быстро набрали толпу джунов, что влияет на продукт в основном тратой его бюджета.
Может быть, у Вас есть рабочая модель, которая подтверждена цифрами. Но стоит тогда её доносить более цельно.
Итак, за зиму заморочился с оборудованием, и теперь пишу уже с нового интернета в своей глухой деревне :)
В качестве антенны выбрал таки параболическую сетку, зная, что вокруг леса — не стал рисковать с панельными. Выбор пал на Vika-24 Box. Роутер в ней самый обычный — Huawei 3372h.
В итоге поймал вышку аж в 12.7 км от дома. Хотя производители антенны во множестве обзоров уверяли, что она с земли отлично работает, у меня, видимо, сказалось наличие леса на пути, поэтому поймал сигнал с высоты около 5 метров (окно второго этажа).
Сейчас DL 110Mbit/s, UL 30Mbit/s
SINR: 16-17db — сильнее пока не получилось выжать, но и этого достаточно.
RSSI: -81db
Крутой тест! А есть понимание ландшафта на тех 8км отдаления?
В этом году решал ту же самую проблему. Деревня имеет три вышки LTE/3G через лес без прямой видимости
Две в 9.2 км по относительной равнине
Одна в 4 км, но с высоким холмом между деревней и вышкой
Вторая вышка потребовала бы подъёма штанги метров на 20 над домом, что не очень приятное решение. В итоге ловлю вышку с отдалением в 9км.
Выбор пал на HitePro Hybrid (нет, не реклама). Внутри там Huawei 3372. Ловит в итоге только 3g с RSSI в районе -78дб. В топе — около 7мбпс на вход, средняя — 4-5. Примерно столько же на выход. LTE оно не ловит вообще.
Имеет смысл взять на тест Zyxel-евское решение? Или будет то же самое?
Возраст — это скорее оправдание, нежели преграда :)
Можно. Главное — понимать, ради чего хотите войти в IT. Мотивация «ради денег» не всегда отрабатывает. Можно перегореть и понять, что оно не нравится, да и в деньгах можно потерять.
Почитайте, например, «Путь программиста», чтобы сформировать общее видение, цель, скорректировать ожидания.
Хорошо, в такой ситуации — ОК. Но предположим, что этот процесс внедряется в команде, где пока оценка ставится под сомнение. И мой вопрос касается как раз такого расклада.
Это хорошо, что продуктовый офис идёт навстречу. Ведь нередки случаи, когда этот самый офис говорит: «Да, рефакторинг — это круто. Но нам надо быстренько...».
Как мне показалось, эта статья больше про то, как продавать бэкенд его клиентам, в числе которых явно не только люди, участвующие в покере. Таким образом, может получиться ситуация, что и оценку 4 тоже надо продать, так как клиенты спросят «А чего так долго?».
В компании много продуктовых команд и почти все работают по Agile.
«Работают по Scrum», судя по контексту, наверное, корректнее будет сказать?
Agile можно следовать, так как это манифест+набор принципов. А Scrum — это уже конкретный подход к работе, фреймворк. Интерфейс и его реализация, если позволите так выразиться.
Демонстрировать новый функционал стало проще, но только внутри компании, потому что решение не выглядит презентабельным.
А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию? Ведь этот самый интерфейс пользователя никак не поменяется.
Логично, как и для любой другой технологии. Тем не менее, когда я сам столкнулся с этим стеком (как и другие люди, интересующиеся serverless, я полагаю), я увидел большую нехватку «рецептов» в этой области и определенный недостаток документации. Что и побудило собрать все воедино.
Лично мне кажется, что Serverless сейчас несколько опережает время своего появления на рынке. Но с другой стороны это вариант вполне каноничного микросервиса. То есть, он развивает эту идею.
Если говорить про применимость здесь и сейчас, то я бы говорил о том, что serverless подход от облачных платформ хорош для быстрой сборки здесь и сейчас некоего продукта для проверки гипотезы, например, там, где совсем нет времени на работу с инфраструктурой. Даже настроенная по умолчанию виртуалка или дефолтный контейнер также потребуют какого-то мониторинга, организации логов. А тут это всё даётся с ходу.
На самом деле, за отсутствие экспертизы как раз и платятся деньги. По сути-то здесь надо один раз научиться это всё собирать воедино, поставить на рельсы и дальше пилить. А если не хочется, то платить за тот же API Gateway.
Дело не столько в экономии, сколько в быстром решении задач — serverless же как раз про это. А экономия вторична — в этом вебинаре я решил параллельно рассказать рецепт того, как платить меньше за практически ту же скорость решения.
Правда, как всегда, где-то посередине. MVP у нас про что? Про то, что надо быстренько сваять то, конечный вид чего есть в лучшем случае у 1-2 человек. И простенький монолит тут будет быстро и легко закрывать какие-то базовые вопросы, давая возможность сосредотачиваться больше именно на запуске.
Микросервисы же требуют более глубокого понимания бизнес-модели. Ведь часто они именно её и отражают. Ведь (правильные) микросервисы состоят не просто в том, чтобы хоть как-то распилить монолит и раскидать его по контейнерам/виртуалкам/Raspberry PI, а выделить некие области задач этими сервисами решаемые. И на этапе MVP часто этого понимания просто нет.
Скорее тут больше тема про MVP, когда подготовка инфраструктуры по времени сопоставима со временем начала разработки. Например, надо под какое-то событие быстренько бота набросать. И непонятно, сколько там пользователей будет, чтобы определить, куда его выделить, сколько мощности выделить, чтобы в случае хабраэффекта он не упал, и прочее. А тут быстренько получается скалируемая площадка, где о непосредственном скалировании задумываться просто не нужно.
Было бы интересно сопоставить финансовые затраты в сравнении с FaaS от того же Amazon. Ведь в варианте самостоятельной подготовки и поддержки инфраструктуры нужен, как минимум, хороший инженер, тогда как Lambda вполне работает без него.
Я могу ошибаться, но свой собственный FaaS будет востребован либо для очень больших компаний, где внутри IT есть несколько слоёв сервисов, оказывающих друг другу услуги, либо для компаний закрытых, которые вот совсем никак не доверяют вендорам.
Интересный подход. По поводу целостности: были ли реальные прецеденты нарушения целостности при бэкапе volume?
Мне кажется, с Lambda тут небольшой оверхед вышел. Ведь можно использовать AWS API, который довольно много умеет. Например, то же создание снэпшотов или бэкапирование виртуалки целиком как AMI вместе с состоянием, что по идее должно сохранять состояние и обеспечивать целостность (но это неточно). Через него же можно ротировать бэкапы.
А потом, спустя N этапов, на каждом из которых ты фиксируешь эту историю, "мы готовы предложить Х - 30%". Простите, личный опыт, наболело.
Тестовые точно брать не надо.
PowerPoint отлично умеет такие штуки собирать. Диаграмма такого типа рисуется либо через "Солнечные лучи", либо через "Лепестковую" - смотря, что больше понравится.
Заголовок, конечно, можно трактовать по-всякому, но все же он не отражает сути статьи. Да, есть «часть 1», но масштабирование команды - это не просто объёмный найм. Тут нужно, чтобы эта конструкция заработала.
Вы предполагаете, что «Сеньор ведет тестовую документацию, передает ее в разработку. Это человек, который влияет на проект, может быть ментором для начинающих специалистов». Через что он влияет? В чем его «сеньорность»? Тут кроме менторства скорее некий аналитик вырисовывается, который в пару раз дешевле сеньора.
Middle определяется опытом, а не объёмом умных фраз, вброшенных в голову джуна. За три месяца можно существенно продвинуться в сторону Middle-а, но на рынке это будет всё тот же джун. Да, он/она может научиться решать типовые задачи в рамках вверенной области кода. Но кто будет проверять качество, потенциал роста и тп? На 28 джунов нужно как минимум ещё 14 менторов, чтобы они могли направлять и растить, а ещё не давали превратить продукт в кодовую помойку. И получается, что масштабирование джунами - это не такой уж и дешёвый путь.
Круто разделять статьи на части, когда каждая часть несёт некую ценность. А тут пока outcome в том, что Вы быстро набрали толпу джунов, что влияет на продукт в основном тратой его бюджета.
Может быть, у Вас есть рабочая модель, которая подтверждена цифрами. Но стоит тогда её доносить более цельно.
В качестве антенны выбрал таки параболическую сетку, зная, что вокруг леса — не стал рисковать с панельными. Выбор пал на Vika-24 Box. Роутер в ней самый обычный — Huawei 3372h.
В итоге поймал вышку аж в 12.7 км от дома. Хотя производители антенны во множестве обзоров уверяли, что она с земли отлично работает, у меня, видимо, сказалось наличие леса на пути, поэтому поймал сигнал с высоты около 5 метров (окно второго этажа).
Сейчас DL 110Mbit/s, UL 30Mbit/s
SINR: 16-17db — сильнее пока не получилось выжать, но и этого достаточно.
RSSI: -81db
Так что ещё раз огромное спасибо за рекомендации!
В этом году решал ту же самую проблему. Деревня имеет три вышки LTE/3G через лес без прямой видимости
Вторая вышка потребовала бы подъёма штанги метров на 20 над домом, что не очень приятное решение. В итоге ловлю вышку с отдалением в 9км.
Выбор пал на HitePro Hybrid (нет, не реклама). Внутри там Huawei 3372. Ловит в итоге только 3g с RSSI в районе -78дб. В топе — около 7мбпс на вход, средняя — 4-5. Примерно столько же на выход. LTE оно не ловит вообще.
Имеет смысл взять на тест Zyxel-евское решение? Или будет то же самое?
Можно. Главное — понимать, ради чего хотите войти в IT. Мотивация «ради денег» не всегда отрабатывает. Можно перегореть и понять, что оно не нравится, да и в деньгах можно потерять.
Почитайте, например, «Путь программиста», чтобы сформировать общее видение, цель, скорректировать ожидания.
А вообще, подход классный!
«Работают по Scrum», судя по контексту, наверное, корректнее будет сказать?
Agile можно следовать, так как это манифест+набор принципов. А Scrum — это уже конкретный подход к работе, фреймворк. Интерфейс и его реализация, если позволите так выразиться.
А как быть с необходимостью, например, рефакторинга или обоснованием расширения срока под ту или иную технологию? Ведь этот самый интерфейс пользователя никак не поменяется.
Всегда рад :)
Логично, как и для любой другой технологии. Тем не менее, когда я сам столкнулся с этим стеком (как и другие люди, интересующиеся serverless, я полагаю), я увидел большую нехватку «рецептов» в этой области и определенный недостаток документации. Что и побудило собрать все воедино.
Если говорить про применимость здесь и сейчас, то я бы говорил о том, что serverless подход от облачных платформ хорош для быстрой сборки здесь и сейчас некоего продукта для проверки гипотезы, например, там, где совсем нет времени на работу с инфраструктурой. Даже настроенная по умолчанию виртуалка или дефолтный контейнер также потребуют какого-то мониторинга, организации логов. А тут это всё даётся с ходу.
Дело не столько в экономии, сколько в быстром решении задач — serverless же как раз про это. А экономия вторична — в этом вебинаре я решил параллельно рассказать рецепт того, как платить меньше за практически ту же скорость решения.
Микросервисы же требуют более глубокого понимания бизнес-модели. Ведь часто они именно её и отражают. Ведь (правильные) микросервисы состоят не просто в том, чтобы хоть как-то распилить монолит и раскидать его по контейнерам/виртуалкам/Raspberry PI, а выделить некие области задач этими сервисами решаемые. И на этапе MVP часто этого понимания просто нет.
Я могу ошибаться, но свой собственный FaaS будет востребован либо для очень больших компаний, где внутри IT есть несколько слоёв сервисов, оказывающих друг другу услуги, либо для компаний закрытых, которые вот совсем никак не доверяют вендорам.
Я не уверен, создаёт ли он Maintenance Window на это время. Но что мешает создать его параллельно?
Основная плюшка — у него есть параметр Retention, который снимает необходимость создания лямбды для удаления старых бэкапов.
Мне кажется, с Lambda тут небольшой оверхед вышел. Ведь можно использовать AWS API, который довольно много умеет. Например, то же создание снэпшотов или бэкапирование виртуалки целиком как AMI вместе с состоянием, что по идее должно сохранять состояние и обеспечивать целостность (но это неточно). Через него же можно ротировать бэкапы.
Вот тут тоже на тему бэкапов довольно интересно.