Сильная команда — это среда усиления
Когда я пришёл в финтех, первое время мне было тяжело. Не потому, что задачи были запредельно сложными, а потому, что команда оказалась сильной. Понял я это не сразу.
Сначала мне казалось, что ко мне придираются. В код-ревью было много замечаний, обсуждение домена уходило глубже, чем я ожидал, а на некоторые вещи команда тратила слишком много внимания. Почему сценарий проходит именно так? Где границы процесса? Какие здесь инварианты? Что будет в исключениях? Не ломаем ли мы соседний участок системы? На старте всё это воспринимается как лишнее давление. Кажется, что задача понятна, код работает, тесты зелёные — значит, всё нормально.
Со временем я увидел, что это были не придирки, а планка. Сильная команда не даёт тебе остаться на том уровне мышления, с которым ты в неё пришёл. Она заставляет смотреть шире: не только на код, но и на домен; не только на локальную задачу, но и на процесс целиком; не только на реализацию, но и на то, правильно ли вообще понята сама задача.
Позже меня подключали к соседним командам, чтобы помочь реализовать часть процессов в других сервисах. И вот там контраст стал особенно заметен. Разница была не в интеллекте отдельных людей, а в среде.
В одной команде нормой было сначала обсуждать домен: какой процесс мы реализуем, где границы ответственности, какие ограничения и побочные эффекты нужно учесть. В другой разговор почти сразу уходил в техническую реализацию: какие поля добавить, какой метод вызвать, как быстрее провести интеграцию. В одной команде ревью помогало увидеть слабые места решения, в другой часто сводилось к косметике: нейминг, форматирование, локальные замечания без разговора о смысле. Даже отношение к дежурству отличалось. Где-то это была часть инженерной ответственности, а где-то — неприятная обязанность, которую нужно просто пережить.
Именно тогда я особенно чётко увидел простую мысль: сильная команда — это не просто набор компетентных людей. Это среда, которая усиливает каждого, кто в неё попадает.
Она усиливает через норму. Через планку качества. Через ритм. Через культуру обсуждения. Через внимание к домену. Через привычку сначала проверять правильность решения на уровне смысла, а уже потом смотреть на код.
Главное здесь вот что: сильная команда делает видимыми слабые места, которые в одиночку можно долго не замечать. В слабой среде человек может годами жить с ощущением, что развивается. Он закрывает задачи, пишет код, участвует в обсуждениях, и внешне всё выглядит нормально. Но если среда не требует глубины, мышление постепенно упрощается.
Сильная команда работает иначе. Она быстрее проявляет твой реальный уровень: в ревью, в обсуждении домена, в дежурстве, в ответственности за решение. Там сложнее спрятаться за формулой «код же работает», потому что вопрос всегда шире: ту ли задачу ты вообще решил, не сломал ли инварианты, не упростил ли процесс до потери смысла, не переложил ли проблему на соседний сервис.
Именно поэтому такая среда ускоряет развитие. Она не даёт долго жить в комфортной иллюзии роста. Она показывает, где ты мыслишь поверхностно, где путаешь реализацию и смысл, где защищаешь код вместо того, чтобы перепроверить модель.
Мы часто выбираем работу по стеку, зарплате, бренду компании или названию роли. Всё это важно. Но есть фактор, который влияет на рост не меньше: среда, в которой ты работаешь. Если рядом команда, которая держит высокую планку, умеет обсуждать домен, серьёзно относится к ревью и к ответственности за общее решение, даже сложный период в такой среде даёт очень много. Если же среда не требует глубины, можно долго оставаться на одном уровне и не замечать этого.
Поэтому сильная команда ценна не только тем, что делает хороший продукт. Её настоящая сила в другом: она меняет качество мышления своих участников.
Слабая команда нормализует посредственность. Сильная команда нормализует рост.
Когда я пришёл в финтех, первое время мне было тяжело. Не потому, что задачи были запредельно сложными, а потому, что команда оказалась сильной. Понял я это не сразу.
Сначала мне казалось, что ко мне придираются. В код-ревью было много замечаний, обсуждение домена уходило глубже, чем я ожидал, а на некоторые вещи команда тратила слишком много внимания. Почему сценарий проходит именно так? Где границы процесса? Какие здесь инварианты? Что будет в исключениях? Не ломаем ли мы соседний участок системы? На старте всё это воспринимается как лишнее давление. Кажется, что задача понятна, код работает, тесты зелёные — значит, всё нормально.
Со временем я увидел, что это были не придирки, а планка. Сильная команда не даёт тебе остаться на том уровне мышления, с которым ты в неё пришёл. Она заставляет смотреть шире: не только на код, но и на домен; не только на локальную задачу, но и на процесс целиком; не только на реализацию, но и на то, правильно ли вообще понята сама задача.
Позже меня подключали к соседним командам, чтобы помочь реализовать часть процессов в других сервисах. И вот там контраст стал особенно заметен. Разница была не в интеллекте отдельных людей, а в среде.
В одной команде нормой было сначала обсуждать домен: какой процесс мы реализуем, где границы ответственности, какие ограничения и побочные эффекты нужно учесть. В другой разговор почти сразу уходил в техническую реализацию: какие поля добавить, какой метод вызвать, как быстрее провести интеграцию. В одной команде ревью помогало увидеть слабые места решения, в другой часто сводилось к косметике: нейминг, форматирование, локальные замечания без разговора о смысле. Даже отношение к дежурству отличалось. Где-то это была часть инженерной ответственности, а где-то — неприятная обязанность, которую нужно просто пережить.
Именно тогда я особенно чётко увидел простую мысль: сильная команда — это не просто набор компетентных людей. Это среда, которая усиливает каждого, кто в неё попадает.
Она усиливает через норму. Через планку качества. Через ритм. Через культуру обсуждения. Через внимание к домену. Через привычку сначала проверять правильность решения на уровне смысла, а уже потом смотреть на код.
Главное здесь вот что: сильная команда делает видимыми слабые места, которые в одиночку можно долго не замечать. В слабой среде человек может годами жить с ощущением, что развивается. Он закрывает задачи, пишет код, участвует в обсуждениях, и внешне всё выглядит нормально. Но если среда не требует глубины, мышление постепенно упрощается.
Сильная команда работает иначе. Она быстрее проявляет твой реальный уровень: в ревью, в обсуждении домена, в дежурстве, в ответственности за решение. Там сложнее спрятаться за формулой «код же работает», потому что вопрос всегда шире: ту ли задачу ты вообще решил, не сломал ли инварианты, не упростил ли процесс до потери смысла, не переложил ли проблему на соседний сервис.
Именно поэтому такая среда ускоряет развитие. Она не даёт долго жить в комфортной иллюзии роста. Она показывает, где ты мыслишь поверхностно, где путаешь реализацию и смысл, где защищаешь код вместо того, чтобы перепроверить модель.
Мы часто выбираем работу по стеку, зарплате, бренду компании или названию роли. Всё это важно. Но есть фактор, который влияет на рост не меньше: среда, в которой ты работаешь. Если рядом команда, которая держит высокую планку, умеет обсуждать домен, серьёзно относится к ревью и к ответственности за общее решение, даже сложный период в такой среде даёт очень много. Если же среда не требует глубины, можно долго оставаться на одном уровне и не замечать этого.
Поэтому сильная команда ценна не только тем, что делает хороший продукт. Её настоящая сила в другом: она меняет качество мышления своих участников.
Слабая команда нормализует посредственность. Сильная команда нормализует рост.
👍8🔥5❤3💯1
И если ты действительно хочешь расти, стоит смотреть не только на задачи, стек и деньги. Стоит задать себе ещё один вопрос: моя команда делает меня сильнее — или просто даёт мне комфортно оставаться на текущем уровне?
👍9
Микросервисы — это не про Go. Это про процесс
Сегодня общался с учеником по курсу. У него есть сомнение: сможет ли он осилить Go после Java.
И я понимаю, откуда это идет. У Go есть устойчивый образ языка для инфраструктуры и почти системного программирования. Из-за этого разработчику, который до этого писал enterprise-приложения на Java, начинает казаться, что вместе с Go ему придется резко уйти в какой-то другой мир: меньше бизнеса, больше низкого уровня.
Но в продуктовой разработке вопрос обычно не в этом.
Микросервисы и продуктовые команды — это в первую очередь не про язык. Это про процессы. Про то, как в системе двигается заявка, поездка, платеж, скоринг или заказ. Про то, какие у процесса есть состояния, какие переходы допустимы, где нужна идемпотентность, где нужны блокировки, а где транзакция.
Язык здесь — только инструмент.
И вот Go в этой роли мне нравится не потому, что он быстрый и не потому, что на нем написаны инфраструктурные сервисы вроде Prometheus. Это правда, такие проекты на Go есть. Но в контексте бизнес-приложений его сила в другом. Он позволяет описывать процесс прямо, без лишнего шума.
Например, у нас есть команда PublishTrip. Нам нужно обеспечить, чтобы поездка перешла в Published. Для этого мы открываем транзакцию, читаем текущее состояние с блокировкой, проверяем, допустим ли переход, и либо возвращаем текущее состояние, либо обновляем его.
Вот это и есть обычная прикладная логика микросервиса.
Мы не пишем драйвер, не работаем с памятью вручную, не решаем низкоуровневую задачу. Мы описываем бизнес-переход. Берем состояние, проверяем правило, выполняем изменение, возвращаем результат.
Это можно сделать на любом языке. Но Go здесь удобен тем, что у него очень ограниченный синтаксис и нет магии. Поэтому внимание остается на самом важном — на поведении системы. Не на сложной иерархии абстракций, не на фреймворке, не на “красоте конструкции”, а на самом процессе.
Именно поэтому я смотрю на Go в микросервисах не как на язык для инфраструктуры, а как на удобный инструмент для продуктовой разработки. Если команда мыслит состояниями, переходами и инвариантами, Go ложится туда очень естественно.
Сегодня общался с учеником по курсу. У него есть сомнение: сможет ли он осилить Go после Java.
И я понимаю, откуда это идет. У Go есть устойчивый образ языка для инфраструктуры и почти системного программирования. Из-за этого разработчику, который до этого писал enterprise-приложения на Java, начинает казаться, что вместе с Go ему придется резко уйти в какой-то другой мир: меньше бизнеса, больше низкого уровня.
Но в продуктовой разработке вопрос обычно не в этом.
Микросервисы и продуктовые команды — это в первую очередь не про язык. Это про процессы. Про то, как в системе двигается заявка, поездка, платеж, скоринг или заказ. Про то, какие у процесса есть состояния, какие переходы допустимы, где нужна идемпотентность, где нужны блокировки, а где транзакция.
Язык здесь — только инструмент.
И вот Go в этой роли мне нравится не потому, что он быстрый и не потому, что на нем написаны инфраструктурные сервисы вроде Prometheus. Это правда, такие проекты на Go есть. Но в контексте бизнес-приложений его сила в другом. Он позволяет описывать процесс прямо, без лишнего шума.
Например, у нас есть команда PublishTrip. Нам нужно обеспечить, чтобы поездка перешла в Published. Для этого мы открываем транзакцию, читаем текущее состояние с блокировкой, проверяем, допустим ли переход, и либо возвращаем текущее состояние, либо обновляем его.
func (s *Domain) PublishTrip(
ctx context.Context,
tripID int64,
clientID int64,
) (*Trip, error) {
trip, err := s.repo.GetTripForUpdate(ctx, tripID)
if err != nil {
return nil, err
}
if trip.DriverID != clientID {
return nil, ErrForbidden
}
if trip.Status == Published {
return trip, nil
}
if trip.Status != Draft {
return nil, ErrInvalidTransition
}
return s.repo.UpdateTripToPublished(ctx, tripID)
}
Вот это и есть обычная прикладная логика микросервиса.
Мы не пишем драйвер, не работаем с памятью вручную, не решаем низкоуровневую задачу. Мы описываем бизнес-переход. Берем состояние, проверяем правило, выполняем изменение, возвращаем результат.
Это можно сделать на любом языке. Но Go здесь удобен тем, что у него очень ограниченный синтаксис и нет магии. Поэтому внимание остается на самом важном — на поведении системы. Не на сложной иерархии абстракций, не на фреймворке, не на “красоте конструкции”, а на самом процессе.
Именно поэтому я смотрю на Go в микросервисах не как на язык для инфраструктуры, а как на удобный инструмент для продуктовой разработки. Если команда мыслит состояниями, переходами и инвариантами, Go ложится туда очень естественно.
👍9
1 апреля
Пришлось сделать резерв сообщества в максе.
Общий чат https://max.ru/join/536L4xlhzoubVchlrMpSB504E9O5i35rs2KhfPj4EWk
Канал https://max.ru/join/nJbgkY6r_dZI_3eiSAQ-b1r9Qz3bbHaNS29FNatBwgA
Пришлось сделать резерв сообщества в максе.
Общий чат https://max.ru/join/536L4xlhzoubVchlrMpSB504E9O5i35rs2KhfPj4EWk
Канал https://max.ru/join/nJbgkY6r_dZI_3eiSAQ-b1r9Qz3bbHaNS29FNatBwgA
MAX
MAX – быстрое и легкое приложение для общения и решения пов…
MAX позволяет отправлять любые виды сообщений и звонить даже на слабых устройствах и при низкой скорости интернета.
😢5👍2👎1
Mock interview — это не подготовка. Это проверка готовности
Недавно ко мне обратился человек, который сейчас возвращается на рынок после паузы. Запрос у него на первый взгляд был вполне стандартный: понять, что сейчас востребовано, как скорректировать roadmap и провести mock interview. Но как раз в таких разговорах и видно, где у рынка искажено само понимание подготовки к собеседованиям.
Далее https://job4j.ru/article/view/15
Недавно ко мне обратился человек, который сейчас возвращается на рынок после паузы. Запрос у него на первый взгляд был вполне стандартный: понять, что сейчас востребовано, как скорректировать roadmap и провести mock interview. Но как раз в таких разговорах и видно, где у рынка искажено само понимание подготовки к собеседованиям.
Далее https://job4j.ru/article/view/15
👍4❤3🔥2
Прошел почти месяц мини-групп — и уже видно результат
1 марта я запустил мини-группы для тех, кто хочет корректно завершить обучение в старой программе. Задача была простая: помочь людям не зависнуть в состоянии «когда-нибудь доделаю», а спокойно и последовательно дойти до конца.
Прошел почти месяц, и результат уже заметен.
Ребята, которым действительно важно завершить обучение, включились в работу. Появился ритм, регулярность, движение вперед. Задачи перестали лежать мертвым грузом, а обучение снова стало живым процессом.
Для меня это еще одно подтверждение простой мысли: когда есть рамка, темп и небольшая группа, людям проще держать фокус и не выпадать из процесса.
Отдельно хочу похвалить тех, кто сейчас идет в этих мини-группах. Видно, что вы пришли не просто формально закрыть этап, а реально хотите завершить его достойно. Это чувствуется по вашей работе.
И для меня это важный вывод: формат с ритмом и групповой динамикой работает.
1 марта я запустил мини-группы для тех, кто хочет корректно завершить обучение в старой программе. Задача была простая: помочь людям не зависнуть в состоянии «когда-нибудь доделаю», а спокойно и последовательно дойти до конца.
Прошел почти месяц, и результат уже заметен.
Ребята, которым действительно важно завершить обучение, включились в работу. Появился ритм, регулярность, движение вперед. Задачи перестали лежать мертвым грузом, а обучение снова стало живым процессом.
Для меня это еще одно подтверждение простой мысли: когда есть рамка, темп и небольшая группа, людям проще держать фокус и не выпадать из процесса.
Отдельно хочу похвалить тех, кто сейчас идет в этих мини-группах. Видно, что вы пришли не просто формально закрыть этап, а реально хотите завершить его достойно. Это чувствуется по вашей работе.
И для меня это важный вывод: формат с ритмом и групповой динамикой работает.
🔥14👍8❤5🕊1
Definition of Done
Сейчас я активно работаю над курсом про процессное мышление. В одном из уроков я рассказываю про термин Definition of Done. DoD — это зафиксированное состояние завершения задачи. Проще говоря, это ответ на вопрос: что именно заказчик или команда хотят увидеть в результате.
И в какой-то момент я поймал себя на другой мысли: а куда именно я веду учеников этим курсом?
Далее https://job4j.ru/article/view/16
Сейчас я активно работаю над курсом про процессное мышление. В одном из уроков я рассказываю про термин Definition of Done. DoD — это зафиксированное состояние завершения задачи. Проще говоря, это ответ на вопрос: что именно заказчик или команда хотят увидеть в результате.
И в какой-то момент я поймал себя на другой мысли: а куда именно я веду учеников этим курсом?
Далее https://job4j.ru/article/view/16
❤🔥3👍3💯2
4 апреля встреча в мини-группах
Напоминаю, что сегодня общая встреча в мини-группах.
Ссылки на эфир в чатах мини-групп.
BigTech + Go в 14:00. Проведет Петр
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.
Всем спасибо и хороших выходных.
Напоминаю, что сегодня общая встреча в мини-группах.
Ссылки на эфир в чатах мини-групп.
BigTech + Go в 14:00. Проведет Петр
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.
Всем спасибо и хороших выходных.
Меняем мышление от монолита к микросервисам
В прошедшую субботу я проводил встречу в мини-группах, где рассказывал ребятам, какие структурные ошибки допустил в блоке по микросервисам.
Сейчас на работе мне дали большую задачу: перевести сервисы из одного контура Kubernetes в другой. Эта задача дает мне возможность глубже понять архитектурные решения, принятые в команде. В этой статье я расскажу, что именно упустил, и дам ссылки на темы, в которых стоит разобраться.
Далее https://job4j.ru/article/view/17
В прошедшую субботу я проводил встречу в мини-группах, где рассказывал ребятам, какие структурные ошибки допустил в блоке по микросервисам.
Сейчас на работе мне дали большую задачу: перевести сервисы из одного контура Kubernetes в другой. Эта задача дает мне возможность глубже понять архитектурные решения, принятые в команде. В этой статье я расскажу, что именно упустил, и дам ссылки на темы, в которых стоит разобраться.
Далее https://job4j.ru/article/view/17
👍4👀4
Метрики и трасы
В этой статье я продолжу описывать то, что упустил в материалах курса.
Во-первых, хочу объяснить, как я нахожу эти недочеты. Сейчас 80% информации я черпаю из текущей работы. Когда у тебя много команд, много сервисов, много ответственности и рисков, в приоритете становятся правила и политики компании. Я смотрю, как ребята решают инциденты, как общаются и выясняют причины проблем, как выстроены мониторинг и профилактика, как проводят code review и доменное review. Я сравниваю это со своим курсом по процессному мышлению и отражаю нужные изменения в материале. Но в то же время мне хочется делиться некоторыми инсайтами и с теми, кто уже проходил у меня обучение, чтобы они тоже двигались дальше по своему пути.
Как говорится, у самурая нет цели — есть только путь.
Далее https://job4j.ru/article/view/18
В этой статье я продолжу описывать то, что упустил в материалах курса.
Во-первых, хочу объяснить, как я нахожу эти недочеты. Сейчас 80% информации я черпаю из текущей работы. Когда у тебя много команд, много сервисов, много ответственности и рисков, в приоритете становятся правила и политики компании. Я смотрю, как ребята решают инциденты, как общаются и выясняют причины проблем, как выстроены мониторинг и профилактика, как проводят code review и доменное review. Я сравниваю это со своим курсом по процессному мышлению и отражаю нужные изменения в материале. Но в то же время мне хочется делиться некоторыми инсайтами и с теми, кто уже проходил у меня обучение, чтобы они тоже двигались дальше по своему пути.
Как говорится, у самурая нет цели — есть только путь.
Далее https://job4j.ru/article/view/18
🔥7
Сегодня (2 мая) общая встреча в мини-группах.
Ссылки на эфиры в плашке job4j.ru
BigTech. Процессинговое мышление в 14:00. Проведет Петр.
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.
Ссылки на эфиры в плашке job4j.ru
BigTech. Процессинговое мышление в 14:00. Проведет Петр.
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.
👍3
Отключены уведомления в Telegram
Сервер платформы Job4j находится в Москве, поэтому работать с Telegramm он не может.
Используйте внутреннюю систему уведомлений.
Сервер платформы Job4j находится в Москве, поэтому работать с Telegramm он не может.
Используйте внутреннюю систему уведомлений.
🤝6😭5❤2🤬1
9 мая встреча в мини-группах
BigTech. Процессинговое мышление в 14:00. Проведет Петр. Эфир.
Java 1 уровень в 14:30. Проведет Стас. Эфир.
Java 2 уровень в 15:00. Проведет Алексей. Эфир.
Java 3 уровень в 15:30. Проведет Стас. Эфир.
BigTech. Процессинговое мышление в 14:00. Проведет Петр. Эфир.
Java 1 уровень в 14:30. Проведет Стас. Эфир.
Java 2 уровень в 15:00. Проведет Алексей. Эфир.
Java 3 уровень в 15:30. Проведет Стас. Эфир.
telemost.yandex.ru
Звонок в Яндекс Телемосте - 8309 0172 0032 77
По ссылке вы сможете подключиться к звонку
👍4
SDD, AI-агенты и новый сдвиг в обучении программистов
В этой статье хочу поделиться своими наблюдениями за тем, как меняются подходы в программировании с появлением AI.
На днях в рабочем треде я увидел переписку коллег. Они обсуждали, что делать с техническими файлами в репозитории.
Сначала я подумал: “Технические файлы? Это что, мусор?” Но оказалось, что речь идет о файлах, необходимых для работы AI-агента. И тут я понял: ага, значит, это уже внедряют и у нас.
Далее https://job4j.ru/article/view/19
В этой статье хочу поделиться своими наблюдениями за тем, как меняются подходы в программировании с появлением AI.
На днях в рабочем треде я увидел переписку коллег. Они обсуждали, что делать с техническими файлами в репозитории.
Сначала я подумал: “Технические файлы? Это что, мусор?” Но оказалось, что речь идет о файлах, необходимых для работы AI-агента. И тут я понял: ага, значит, это уже внедряют и у нас.
Далее https://job4j.ru/article/view/19
SDD на практике: создаём сервис уведомлений через Cursor AI
В этой статье я хочу поделиться новым способом создания проектов — SDD, Spec-Driven Development.
В предыдущей статье я уже начал говорить об этой методологии, а здесь покажу её на практическом примере. Такой же подход к созданию программы я буду просить использовать учеников в курсе по процессному мышлению, в разделе «Микросервисы».
Почему именно там?
Далее https://job4j.ru/article/view/20
В этой статье я хочу поделиться новым способом создания проектов — SDD, Spec-Driven Development.
В предыдущей статье я уже начал говорить об этой методологии, а здесь покажу её на практическом примере. Такой же подход к созданию программы я буду просить использовать учеников в курсе по процессному мышлению, в разделе «Микросервисы».
Почему именно там?
Далее https://job4j.ru/article/view/20
👍4
16 мая встреча в мини-группах
Завтра (16 мая) общая встреча в мини-группах. Отчеты
BigTech. Процессинговое мышление в 14:00. Проведет Петр. Эфир.
Java 1 уровень в 14:30. Проведет Стас. Эфир.
Java 2 уровень в 15:00. Проведет Алексей. Эфир.
Java 3 уровень в 15:30. Проведет Стас. Эфир.
Завтра (16 мая) общая встреча в мини-группах. Отчеты
BigTech. Процессинговое мышление в 14:00. Проведет Петр. Эфир.
Java 1 уровень в 14:30. Проведет Стас. Эфир.
Java 2 уровень в 15:00. Проведет Алексей. Эфир.
Java 3 уровень в 15:30. Проведет Стас. Эфир.
GitHub
GitHub - job4j/flows
Contribute to job4j/flows development by creating an account on GitHub.
Восстановил оповещение о проверках в телеграме
Решение такое:
1. Купил VPS в https://beget.com/
2. Сервер находится в Латвии.
3. Настроил на нем tinyproxy.
4. Настроил на главном сервере в Москве поход к api.telegram через прокси сервер в Латвии.
5. Стоимость сервера в 690 рублей в месяц.
Решение такое:
1. Купил VPS в https://beget.com/
2. Сервер находится в Латвии.
3. Настроил на нем tinyproxy.
4. Настроил на главном сервере в Москве поход к api.telegram через прокси сервер в Латвии.
5. Стоимость сервера в 690 рублей в месяц.
Beget
Beget — Хостинг и облачные сервисы | Аренда IT-инфраструктуры
Beget — это российский облачный провайдер ☁️ Аренда облачных сервисов для бизнеса и IT-проектов : выделенные серверы, VPS/VDS, S3-хранилище, DBaaS, хостинг, регистрация доменов ⚡️ Высокая скорость⚡️Гарантированный UpTime 99.98% ⚡️ Поддержка 24/7
👍16❤🔥6❤2
Завтра (1 июня) встречаемся онлайн в телемосте в 20:00.
Ссылка на эфир.
Темы:
1. Итоги мини-потоков.
2. План подготовки на лето.
3. Презентация потока "BigTech: От CRUD к процессинговому мышлению".
Жду всех.
Ссылка на эфир.
Темы:
1. Итоги мини-потоков.
2. План подготовки на лето.
3. Презентация потока "BigTech: От CRUD к процессинговому мышлению".
Жду всех.
telemost.yandex.ru
Звонок в Яндекс Телемосте
По ссылке вы сможете подключиться к звонку
👍10
Июнь - месяц мок-собеседований
Как я обещал мы делаем целый месяц мок-собеседований.
Все желающие могут принять участие в мок собеседовании. Пишите мне в личку @parsentev.
В субботу первая встреча в 11 00 по 12 00. Тема собеседования: структуры данных, алгоритмы.
Пока желающих по быть в роли кандидатов нет, есть только слушатели. Если никого не окажется, то порешаем вместе задачи по яндексу, у меня как раз собеседование к ним 15 июня.
Как я обещал мы делаем целый месяц мок-собеседований.
Все желающие могут принять участие в мок собеседовании. Пишите мне в личку @parsentev.
В субботу первая встреча в 11 00 по 12 00. Тема собеседования: структуры данных, алгоритмы.
Пока желающих по быть в роли кандидатов нет, есть только слушатели. Если никого не окажется, то порешаем вместе задачи по яндексу, у меня как раз собеседование к ним 15 июня.
👍10