Войти через соцсеть:
Войти через email:
По этим критериям поиска ничего не найдено
- Убьёт ли ИИ фотостоки?
- На каких стоках всё ещё стоит размещаться?
- Как стоки уменьшают авторские вознаграждения?
- Что изменилось для российских контрибьюторов в 2022?
- Тренды на фотостоках в 2023 году: чего больше всего ждут от авторов?
- Бюджет маркетинга - «достаточно» это сколько;
- Кроссфункциональная вовлеченность - зачем она нужна;
- Как выглядит план-капкан;
- Убийственные аргументы защиты бюджета
Расскажем о том, как сделать отказоустойчивый кластер MySQL для высоконагруженного проекта, где на каждый сервер можно писать и читать одновременно и безопасно на основе Galera Cluster.
зачем в соц.сетях нужен именно живой, недушный, несухой контент (Диалог с аудиторией, отстройка от конкурентов, Личный бренд)
примеры сухих текстов по нишам
разбор примеров по основным типам ошибок (канцеляризмы, клише, многомыслие и тд)
приемы, как отредактировать сухой текст до живого
3 приема небанальных продающих схемы текстов, которые сейчас в тренде
7 золотых правил, чтобы текст получился загляденье (писать о том, что реально интересно самому, выделить основную мысль и довести ее до конца, писать в потоке без цензуры, обязательно редактировать, применять образы и метафоры, разговорный стиль, Tone of Voice)
Мы разберем типовое web приложение со стороны backend на компоненты, определим категорию и зону ответственности этих компонентов и посмотрим на их составные части. Основой архитектуры будет использование паттерна Clean Arch, который хорошо себя зарекомендовал. Мы будем предполагать, что работа по выделению доменных областей проведена, стек технологий и сервисы для интеграции выбраны. Если посмотреть на уровни моделью декомпозиции [С4](https://c4model.com/), мы будем проектировать 3 уровень - диаграмму компонентов приложения.
Операционные системы нам кажутся уже устоявшимся миром, но это не так. Требования надежности и безопасности постоянно повышаются, и старые ОС такие как macOS, Windows и Linux здесь безсильны. На сцену выходят ОС на основе микроядра: безопасная операционка KasperskyOS от Лаборатории Касрерского, идущая на смену Андроида Fuchsia от Google и ветеран seL4. Но что такое микроядро и как оно устроено?
Давайте разберем что такое ОС в целом, как работают “монолитные” и новые микро-ядра. Что такое модель MILS. Заглянем под капот и разберемся с базовыми блоками на которых строятся современные микроядра. Разберем на пальцах такие основополагающие механизмы как: capability, message passing и конечно же что делает KasperskyOS более защищенной ОС.
Как рассказывать о своем опыте и шарить экспертизу коллегам?
От скучных daily scrum meeting к интересным стендапам и зажигательным митапам?
Как погружать в контекст, но не перегружать?
Расскажу об опыте моем и компании по подготовке митапов и спикеров.
Остановимся на форматах стендапов, что они дают спикерам и командам. Как это влияет на «пороки команды».
Рассмотрим инструмент обучения спикеров для выступлений внутри команды, донесения информации для топов, работы с внешней аудиторией.
Нередко мы сталкиваемся в работе с трудностями, которые раз за разом не получается эффективно решить. Например:
- откладываем до последнего важную задачу,
- не можем отказать и берем повышенные обязательства,
- сами хватаемся за задачи, которые очевидно не вмещаются в рабочую неделю,
- не можем сказать, что сроки уже точно будут сорваны и из-за этого работаем ночами,
- стесняемся заговорить о повышении,
- не можем справиться с эмоциями, вступаем в конфликт и проигрываем по форме, будучи правыми по сути.
Иногда от злости или обиды становится настолько тяжело работать, что мысли об увольнении вызывают облегчение.
У всех практик тайм-менеджмента, эффективной коммуникации и управления есть общий секрет: без совладания с эмоциями они не работают.
Нельзя просто так встать и сказать: "Мы сорвали сроки". Нельзя оставаться спокойным, когда коллеги подводят или манипулируют. Не так просто взять и сесть за работу, когда сама мысль о ней вызывает тошноту.
О прокрастинации и эффективной коммуникации написано много статей и книг. Подробно разобраны когнитивные искажения, которые приводят к неверным решениям. И всё равно часто возникает проблема: "Головой я всё понимаю, но всё равно не могу сделать так, как запланировал".
В докладе я расскажу о рационально-эмотивном поведенческом подходе Альберта Элиса. Поговорим о том, как иррациональное мышление заставляет нас раз за разом ходить по одним и тем же граблям. И как научиться думать и действовать по-новому.
Существует много докладов, статей и подкастов про то, что должны делать тимлиды, и какими качествами обладать.
Но на мой взгляд нельзя так просто утверждать что должен или не должен делать тимлид, не понимая контекста и ситуации, в которой находится бизнес.
Где-то вам нужно собрать команду с нуля, где-то расширить команду с 5 до 50 человек за 3 месяца, а где-то вывести команду из кризиса за те же 3 месяца, иначе все компании конец. Везде нужен тимлид, но везде нужен разный тимлид, с разными скиллами и разными сферами деятельности.
В своем докладе я классифицирую тимлидов на несколько категория и объясню когда какие нужны. Этот доклад будет полезен и тем, кто тимлидов нанимает, и самим тимлидам, чтобы сматчить свои скиллы и потребности бизнеса.
Очень часто тимлиду приходится не только управлять команду, но и участвовать в процессе найма и отбора кандидатов. Поговорим о том, как эффективно настроить этот процесс и сэкономить время при отборе.
- Какая технология в описании вакансии, увеличила количество откликов в 3 раза?
- Как составить сценарий разговора, чтобы рекрутёр мог без вас выявить все красные флаги за первые 15 минут скрининга? Действуем по принципу Fail Fast.
- Какие вопросы задавать на собеседовании, чтобы понять, что кандидат действительно хорош в работе, а не просто умеет проходить собеседования?
Также расскажу о тех лайфхаках, которые нашел для себя за 2 года проведения собеседований.
Бонусом расскажу об особенностях найма в международную команду.
Язык Swift - главный язык разработки мобильных приложений для iOS. Он был представлен 9 лет назад и за это время никогда не останавливался в развитии. Только в его пятой версии за последние годы появились макросы, некопируемые структуры, property wrappers и result builders, инструменты работы с многопоточностью, регулярными выражениями и много что еще. При этом многие новые фишки языка из-за все увеличивающегося темпа работы часто ускользают от программистов и не становятся частью ежедневной рутины.
В докладе я покажу, как развитие Swift уже упростило наш код: сделало проще имплементацию MVVM и классических паттернов проектирования, сериализацию и десериализацию данных, кодогенерацию на примере моков и другие рутинные задачи.
⁃ подход к подбору команды, «роли по Сереже» vs «роли по стандартным типологиям»
⁃ Чем топ-команда отличается от команды разработки
⁃ Цикл жизни команды наложенный на цикл развития ее лидера
⁃ Враги и друзья команды
⁃ Мои ошибки при формировании команды
⁃ 5 советов тем, кто завтра окажется в моей роли
В течение нескольких лет мы спрашивали разные команды, с которыми работали, какие факторы, на их взгляд, могут разрушить доверие. В результате мы собрали и проанализировали множество ответов и сгруппировали их в более короткий список из 23 основных факторов, разрушающих доверие в команде.
Расскажу про инструменты, которые помогает выстраивать обсуждения вокруг существующих или потенциальных проблем с доверием и находить возможные решения.
Микросервисный подход бешено разгоняет разработку, но вдогонку плодит кучу сущностей с бесконечными зависимостями. Как в этом не потонуть?
Я расскажу о том, как мы в Cloud изменили стандартные подходы к проектированию приложения...
Из доклада вы узнаете:
* какие боли несет в себе микросервисный подход;
* как не создать микросервисный монолит;
* оптимизации, оптимизации и еще раз оптимизации;
* как работать с консистентностью и Bus-фактором;
* как следить за качеством;
Приходите, скучно не будет.
Доклад основан на реальных событиях.
Когда программа стабильно работает, линтеры не находят багов, код всё равно может слабо поддерживаться и трудно масштабироваться. Часто проблема связана с неэффективным неймингом.
Поговорим о том, как добиться чистого кода и внедрить непротиворечивые практики нейминга в разработке.
Внутри доклада подсветим вопросы:
1. Половина времени код-ревью уходит на разъяснения и комментарии, касающиеся названий сущностей в коде. То, как будут поименованы объекты, переменные, влияет не только на сам процесс ревью, но и на предсказуемость работы ПО при развитии и масштабировании. Даже если программа работает, но читаемость её кода на низком уровне, со временем такой код приходится переписывать из-за сложной поддержки.
2. Чистый код равно литературный код. Требования к написанию кода сильно изменились. Если раньше программисту было важно разбираться в том, как устроено “железо”, то сегодня во главе угла — умение чётко формулировать: насколько точно разработчик умеет выражать свои мысли, насколько код легко читать и воспринимать.
3. Самодокументируемый код. В идеальном мире хорошему коду не требуется документация. Соблюдение унифицированных и общих правил для выбора названий переменных, коммитов и мёрдж-реквестов позволяет писать код и ориентироваться в нём быстрее.
Практика:
— основные ошибки и проблемные моменты, которые часто встречаются на ревью.
— список рекомендаций по неймингу: подбор терминов (с примерами), внедрение политик по единообразному неймингу в компании и др.
В этом докладе мы поговорим про надежность программного обеспечения, которое мы создаем. И обсудим такие вопросы
- надо ли нам думать о надежности нашей системы и от чего это зависит
- как оценить надежность существующей системы
- почему надежность сложно добавить в существующую систему
- какие существуют принципы для проектирования надежных систем
- как выстроить процессы для ее достижения
При найме инженера в компанию каждый участник процесса проходит 5 стадий: отрицание, гнев, торг.. ну вы знаете. А если вы находите того самого идеального кандидата, но он не принимает оффер или уходит через полгода работы... Хуже может быть только, когда уходят лояльные и самые производительные программисты.
Я не понаслышке знаю о всех ситуациях ведь ни раз сталкивался с ними лично. В докладе, основанном на собственном опыте и ошибках, расскажу:
- чем привлекать первоклассных специалистов в свои команды;
- как выстроить доверительную коммуникацию между отделами;
- как выстроить процессы, чтобы сотрудники развивались, расходы сокращались, а лояльность к компании увеличивалась.
Скажете, что это утопия? А я отвечу, что реальность.
Оптимизация web-приложения является важной частью его разработки, о чем многие, к сожалению, забывают. Быстрый сайт дает приятный пользовательский опыт, увеличивает конверсию и экономит ресурсы машины. Но когда разработчиков спрашиваешь об оптимизации, очень часто, в лучшем случае, можно услышать что-то о мемоизации или минификации кода. Однако это только вершина айсберга.
В докладе мы поговорим о том, как еще можно увеличить скорость загрузки и работы сайта, как добиться 100 баллов в метрике производительности Google Lighthouse, как сделать такую скорость работы, чтобы пользователи этого даже не видели никаких загрузок, и многое другое.
В докладе будут затронуты такие темы как:
- Оптимизация изображений и других медиа файлов
- Оптимизация оптимизаторов картинок
- Виды рендеринга страницы и как их выбирать
- Ленивый паттерн (но не разработчик)
- Алгоритмы сжатия файлов
- Разделение кода
- Виды кэширования для различных задач
- Оптимизация данных для пререндеринга
- Оптимизация мультиязычных сайтов
И многое другое.
Я регулярно вижу, как руководители в IT сталкиваются с задачами, которые требуют от них смелости и решительности:
-заявить о себе и достижениях своей команды внутри компании или вовне;
-преодолеть кризис смыслов и после выгорания понять, куда двигаться дальше;
-взять на себя ответственность за непопулярные решения в турбулентные времена и помочь команде их пережить.
Все эти вопросы объединяет один механизм: сначала нам становится очень тревожно, затем мы сталкиваемся с другими неприятными эмоциями и начинаем прокрастинировать, чувствуем неудовлетворенность и еще больше откладываем решение проблемы.
В своем докладе расскажу о том, почему так происходит, а также о лайфхаках, которые помогают руководителям справиться со сложными ситуациями и продолжить движение, а не замирать.
- Цена проблемы. Сколько теряем мы и другие компании на ранних увольнениях;
- Как предсказать текучку и срок жизни сотрудника еще на этапе найма (19 параметров для оценки кандидатов).
- Best practice (не наступайте на наши грабли): как мы адаптировали оценку под себя, внедрили ее в рамках компании и какие получили результаты;
- Готовый к применению чек-лист рекрутера или нанимающего менеджера для оценки срока жизни будущего сотрудника.
— С чего начать коммуникацию с заказчиком
— Определение внутренней стратегии ведения проекта
— Тактика презентации решения в зависимости от типа клиента
— face-to-face с заказчиком (Как не зря сходить в гости к клиенту)
С фразы «Ставьте задачу досконально» часто начинается путь мучений в отношениях между тем, кто ставит задачу — заказчиком, менеджером продукта или аналитиком — и разработчиками. Этот путь обычно заканчивается тупиком. В докладе я расскажу, почему это происходит, и что делать, чтобы выстроить беспроблемный процесс постановки и передачи задач в разработку.
— Подробно и с примерами расскажу про проблемы стыковки постановщика и разработчика.
— Расскажу, как организовать диалог между ролями и закрыть пробелы в экспертизе и ответственности.
— С организационной стороны обсудим зоны ответственности ролей за проектные решения. Покажу, как может выглядеть процесс передачи задач в разработку.
— С технической стороны напомню об инструментах для совместного проектирования и постановки задач Impact mapping, сценарии пользователя, User story mapping, 4 context architecture. Расскажу, как наиболее эффективно пользоваться этими инструментами.
⁃ Зачем?
⁃ У нас есть практики менеджмента, значит у нас есть менеджмент?
⁃ Как? Первые шаги!
⁃ Практические кейсы.