Голосование

Как мы делали сложный интерактив с нуля в сжатые сроки - тонкости и подводные камни. Почему полагаться на легаси - плохо? Как выбрать между DOM и Canvas и какую пользу этим можно нанести? Как не запутаться в иерархии связанных компонентов? Нюансы оптимизации перфоманса на интерактивном вью.

Что такое начинающий разработчик и что он скрывает? Какие тайны он приносит с собой после того, как заканчивает обучение? Что он придумывает на собеседовании и почем он так их боится? К чему нужно быть готовым при работе с джуниорами, какие задачи нужно ему давать и как погружать в работу? Мы давно работаем только с джуниорами и готовы рассказать об этом во всех подробностях.

Не переделывать код - круто. Как разработчику отстоять свое мнение на ревью? Как мотивировать остальную команду писать классно, одинаково и одинаково классно? История о том, как мы избавились от однотипных замечаний и снизили порог входа в свои проекты. Почему субъективный ревьюер - плохо, зачем контрибьютить в бест практики и как разработчику наладить такой процесс в команде.

Новичкам хорошо, их много учат, им много дают материала. Но почему после обучения не все из них не становятся разработчами? Даже те, кто показывает неплохой уровень вёрстки. Они не умеют работать в команде, в режиме дедалйнов, не переваривают правки. Они никогда не работали в среде, которая прокачивает все эти необходимые навыки. Как и зачем мы это делаем и почему для новичков это необходимо?

- Сейчас обучение — это уже не чтение книжек и походы в библиотеку, сейчас учиться можно онлайн. В том числе и программированию

- Расскажу, какие технологии использует наша команда интерактивных курсов, как мы проверяет код студентов (вёрстку, стили, js-код, как проверяем работоспособность программ студентов), какие технологии для этого используем, поделюсь интересными кейсами

Люди учатся архитектуре по старым книжкам, которые писались для Java. Книжки хорошие, но дают решение задач того времени инструментами того времени. Время поменялось, C# уже больше похож на лайтовую Scala, чем Java, а новых хороших книжек мало.

В этом докладе Максим расскажет о критериях хорошего кода и плохого кода, как и чем мерить. Сделает обзор типовых задач и подходов, разберет плюсы и минусы. В конце даст рекомендации и best practices по проектированию web-приложений.

Если тебе часто нужно создавать новые блоки большого приложения или сервисы в составе сложной архитектуры, то в конце концов встает вопрос, как сделать этот процесс проще, как не вдаваться в долгие и сложные объяснения новому разработчику, как у тебя тут все работает, и не впадать в ступор в тот момент, когда видишь абсолютно дикий и непонятный код твоего, вроде бы умного, коллеги.

В докладе пойдет рассказ про варианты избавления от боли при интеграции, создании и сопровождении проектов с SOA с помощью стандартизации кода, строгих контрактах взаимодействия компонентов и грамотного выделения ресурсов.

iOS-разработчик должен в равной степени владеть двумя языками программирования: проверенным временем Objective-C и активно развивающимся Swift. Языки совместимы и допускают создание проектов, содержащих файлы, написанные на любом из них. Но взаимодействие двух языков, позволяющее легко вносить изменения в проект и поддерживать достаточную гибкость - задача нетривиальная и требующая пристального внимания.

В докладе поговорим о создании приложений на разных языках и о принципах их взаимодействия.

- У новичков много страхов: им страшно менять привычную сферу на IT — вдруг не получится, они боятся совершить ошибку и не знают, как подобраться к большой задаче

- Дам практические советы, как эффективно учиться программировать

Что рассмотрим в ходе выступления:

• Какие задачи стоят перед предприятиями, какие инструменты используются
• Эволюция поиска: что было, как есть, что будет
• Что такое «Когнитивная система»?
• Как когнитивный поиск может быть использован? Какое отношение когнитивистика имеет к e-learning?
• Кейс использования когнитивных технологий в обучении, в работе, в коллаборации
• Что нужно начать делать для построения когнитивного поиска у себя, для себя?

Нельзя открыто хантить на инженерных конференциях и митапах. Людям будет некомфортно, и вместо закрытой вакансии получишь испорченную репутацию компании.

Делать свои собственные мероприятия — это дорого. Продешевишь на кейтеринге и мёрче, и все будут думать, что твоя компания бедная, и больше не придут.

Сформулировать Employee Value Proposition — это полгода, минимум.

Или нет?

HR-маркетинг — относительно новая дисциплина, но уже успела обрасти негласными правилами, вроде тех, что выше. Список примеров можно продолжать: сотрудник сходил на конференцию, пусть потом доложится коллегам; число вовлечённых в HRM сотрудников — не больше 20%. Корпоративная библиотека, компенсация за конференции, внутреннее обучение, хакатоны, длинный список через запятую.

На практике многие из этих правил оказываются не более, чем стереотипами. Можно и нужно поступать иначе, в зависимости от обстоятельств. Мы даже придумали универсальное правило, которое помогает регулярно ломать устои, но добиваться целей HR-бренда. Что-то вроде контрольного вопроса.

Как это работает — расскажу в докладе, на примерах из жизни.

Это вторая инкарнация моего доклада о том какие ошибки допускают разработчики при работе с Postrges'ом.

Я с моими коллегами из Data Egret являемся Postgres-консалтерами и регулярно наблюдаем как команды разработки осознанно или нет, но допускают ошибки при работе с Postgres'ом.

В этом докладе я постараюсь разобрать разные ситуации, которые допускают команды разработки, и даже иногда видят их как решение своих задач, но при этом DBA видят в них источник потенциальных проблем здесь и сейчас либо в обозримом будущем.

В докладе я рассмотрю:

- проблемы, связанные с планированием, мониторингом и дефолтными конфигурациями, которые встречаются практически везде и всегда;

- антипаттерны, связанные с проектированием схем данных;

- проблему длинных транзакций, которая часто становится сюрпризом;

- еще будет про самописные системы очередей, HTAP workload, "бигдату", docker/kubernetes.

По ходу доклада слушатели узнают про некоторые best и worst practices при работе с СУБД и, уже смотря на свои базы, смогут заранее спрогнозировать возникновение неприятных ситуаций и предпринять меры.

Доклад будет полезен широкому кругу технических специалистов, вовлеченных в разработку ПО и обслуживание баз данных.

- Что такое сквозная аналитика

- Какие уровни анализа бывают

- Почему не каждый дашборд или отчет можно назвать сквозной аналитикой

- Как выбрать уровень анализа для своего проекта и что для этого потребуется сделать

- Блогеры - просто хайп или эффективный инструмент продвижения

- Кому и зачем нужны блогеры

- Где найти блогера?

- Топы или микро - муки выбора

- Вычисляем фейка: полезные сервисы и инструменты

- Деньги VS Бартер - сколько стоит реклама у инфлюенсеров

- Что можем считать - анализируем итоги размещений.

- 10 советов, как не сливать бюджет при работе с блогерами

- Кейсы (Читай Город, BAYER, Movavi, Lamoda, Kiko Milano)

- Разберем что такое Serverless и с чем его "едят"

- Рассмотрим основные проблемы с которыми вы можете столкнуться во время разработки

- Поделюсь своим опытом и практиками

Пять лет мы жили с самописной шиной для обмена данными — теряли сообщения и страдали от однопоточного импорта. Сегодня мы используем Apache Kafka и Golang для обмена данными между сервисами.

Расскажу, как механизм «отложенных данных» помог нам организовать сбор информации от десятка команд. От десятка команд, чья очередность выгрузки непредсказуема. Поделюсь, как нам удалось построить зависимости и поставлять данные констистентно и в срок.

Незаметно для самих себя мы в Ecwid доросли до 100Gb (и 200 миллионов строк) логов каждые сутки. Unix-утилиты, конечно, дают жару, но grep/sed/awk на таких объемах увы, не справляются. Мы запихнули все эти десятки терабайт за несколько месяцев в ClickHouse, написали свой простой язык запросов, подкрутили тут, там и получилась очень простая и быстрая система работы с логами. В докладе я объясню как за пару дней на коленке построить себе такое же счастье.

1. 80% российских компаний теряют клиентов. В чем причина?

2. Как изменить подход к взаимодействию с клиентами в компании

3. Почему все больше компаний хотят автоматизировать свои бизнес-процессы?

4. CRM не инструмент, а процесс. Почему CRM-система ничего не меняет после внедрения? Как добиться от нее максимальной эффективности

Кто из нас не верстал html-рассылку? Наверняка, вы помните тот средневековый код, переполненный жуткими таблицами и инлайновыми стилями.

По прошествии лет письма стали краше, начали прилично отображаться на мобильных устройствах, в них даже появился интерактив. Расскажу, как готовить рассылки в 2019 году, победить Outlook и не завязнуть в вечном багфиксе.

Волонтерство: альтруизм или бизнесс?

Наставничество как метод развития себя

Последствия 4 индустриальной революции, миф или реальность?

Опыт который не смыть.

История про успешную SAFe трансформацию в важнейшем бизнес юните и запуск первого Agile Release Train (ART).

Как выстраивать потоки ценности, вовлекая в процесс сотни сотрудников? Как с помощью SAFe сблизить "бизнес" и "разработку", синхронизировать работу над десятком информационных систем и снизить Сycle Time? Почему в основе всего должны быть опытные кросс-функциональные фиче команды, работающие по Scrum? Как SAFe помогает распространять Agile и Lean принципы в промышленных масштабах? О чем важно помнить, если вы действительно хотите трансформировать систему?

На эти вопросы я отвечу в своем докладе и расскажу, как SAFe помог нам сделать еще один шаг на пути к организационной гибкости.

На сегодняшний день ClickHouse одна из самых динамично развивающихся СУБД.

Давайте посмотрим как менялся ClickHouse за последние пару лет и на примерах разберем документированные, так и недокументированные возможности, которые позволяют создавать более эффективные приложения.

В докладе расскажу о практиках работы с Postgres в сервисах на Go. Поговорим о преимуществах и недостатках основных инструментов, которые принято использовать при работе с Postgres в Go. Конечно, коснёмся нюансов, которые нужно учитывать, когда ваши сервисы работают внутри Kubernetes облака. Также расскажу об опыте Avito в предоставлении базы данных разработчикам продукта. Доклад будет интересен разработчикам, которые хотят избежать проблем при работе с Postgres и полезен DBA, которые хотят узнать с какими трудностями сталкиваются клиенты их базы данных.

В докладе расскажу, что можно и что нельзя говорить клиенту SEO-компании, как избежать и нейтрализовать негатив. Как презентовать результаты работы и добиться согласования по всем задачам разными способами.