Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
Быстрое расширение Robot Framework под свои нужды с использованием Pythonautomated-testing.info
Быстрое расширение Robot Framework под свои нужды с использованием Python, Михаил Поляруш
Когда мы начинаем заниматься автоматизацией тестирования ПО, мы редко знаем и понимаем, что нам надо будет делать, а тем более, как это нужно реализовать. Потому, выбираем самые простые решения, которые иногда даже не подразумевают программирования. Вы считаете, что успешная автоматизация может быть без программирования? Я уверен, что НЕТ, и с уверенностью могу сказать, что процесс автоматизации с помощью python и RobotFramework может значительно упростить Вам жизнь. Убедитесь в том, что архитектура RobotFramework очень гибкая, а python – лучший друг автоматизатора. Вас ждет увлекательная теория и много практики в живую.
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
- почему PHP программисты снискали дурную славу;
- что делать, чтобы стать хорошим программистом;
- как писать идеальный код;
- что такое командная разработка проекта;
- учет позиции бизнеса при разработке проекта;
- основные задачи, который должен решать программист;
Доклад с PUG#2 https://www.facebook.com/events/292457000957088/
Доклад о работе в Shell, исполнении PHP в Shell, использовании REPL в PHP, а также эпический батл между Boris и PsySH.
PHP User Group Ukraine в социальных сетях:
https://www.facebook.com/pug.ukraine
https://vk.com/pug.ukraine
https://www.linkedin.com/groups/PHP-User-Group-Ukraine-6703717
Индустрия меняется прямо на глазах. Технология, еще вчера проходившая по категории "модно, но не нужно", сегодня используется даже бомжами, а завтра выбрасывается на свалку. Что учить, куда смотреть, какие книги читать? Я попробую рассказать свой взгляд на серверное программирование сейчас, в 2016 году.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
Быстрое расширение Robot Framework под свои нужды с использованием Pythonautomated-testing.info
Быстрое расширение Robot Framework под свои нужды с использованием Python, Михаил Поляруш
Когда мы начинаем заниматься автоматизацией тестирования ПО, мы редко знаем и понимаем, что нам надо будет делать, а тем более, как это нужно реализовать. Потому, выбираем самые простые решения, которые иногда даже не подразумевают программирования. Вы считаете, что успешная автоматизация может быть без программирования? Я уверен, что НЕТ, и с уверенностью могу сказать, что процесс автоматизации с помощью python и RobotFramework может значительно упростить Вам жизнь. Убедитесь в том, что архитектура RobotFramework очень гибкая, а python – лучший друг автоматизатора. Вас ждет увлекательная теория и много практики в живую.
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
- почему PHP программисты снискали дурную славу;
- что делать, чтобы стать хорошим программистом;
- как писать идеальный код;
- что такое командная разработка проекта;
- учет позиции бизнеса при разработке проекта;
- основные задачи, который должен решать программист;
Доклад с PUG#2 https://www.facebook.com/events/292457000957088/
Доклад о работе в Shell, исполнении PHP в Shell, использовании REPL в PHP, а также эпический батл между Boris и PsySH.
PHP User Group Ukraine в социальных сетях:
https://www.facebook.com/pug.ukraine
https://vk.com/pug.ukraine
https://www.linkedin.com/groups/PHP-User-Group-Ukraine-6703717
Индустрия меняется прямо на глазах. Технология, еще вчера проходившая по категории "модно, но не нужно", сегодня используется даже бомжами, а завтра выбрасывается на свалку. Что учить, куда смотреть, какие книги читать? Я попробую рассказать свой взгляд на серверное программирование сейчас, в 2016 году.
Мастер-класс: Разрабатываем сайт с нуля на полном стеке БЭМ-технологий — Жека...Yandex
БЭМ упрощает разработку сайтов, которые нужно быстро создать и долго поддерживать. Эту технологию используют во фронтенде почти всех сервисов Яндекса, и она уже успела обрасти множеством библиотек и инструментов, которыми мы хотим с вами поделиться. С обширным арсеналом БЭМ, со всей его модульностью и мощью, вам останется «всего-то» придумать идею и реализовать её. На мастер-классе вы сможете вместе с нами создать то, что мы «только что» придумали. Вы узнаете, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомитесь с готовыми библиотеками блоков и инструментами для автоматизации сборки. Мы покажем, как разные инструменты — например, autoprefixer, css-препроцессор Roole или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки на БЭМ. На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельная часть мастер-класса будет посвящена декларативным шаблонам BEMHTML и BEMTREE, которые позволяют преобразовывать сырые данные во view-ориентированный BEMJSON. Мы вместе напишем серверную часть приложения в БЭМ-методологии и используем данные от разных социальных и поисковых сервисов (RSS с Яндекс.Фоток, API Twitter и Instagram). В результате получится работающий сайт, а вы — на практике познакомитесь с полным стеком БЭМ-технологий. После мастер-класса мы сможем свободно пообщаться на профессиональные темы. Например, вы расскажете о трудностях, с которыми встретились при реализации проекта на БЭМ, и мы вместе подумаем, как воплотить вашу идею в жизнь.
Backend на Swift. Существует и работает! / Роман Мочалов (Improve Digital)Ontico
РИТ++ 2017, App's Conf
Зал Найроби, 6 июня, 13:00
Тезисы:
http://appsconf.ru/2017/abstracts/2712.html
- Рассмотрим случаи, когда нам было бы полезно самим писать backend...на Swift'e, конечно же!
- Разбор open-source библиотек, позволяющих вам писать только Swift-код для работы с реквестами. Остальную REST, OAuth, HTTP-магию они делают сами.
- Напишем с вами API для работы с "юзерами", будем записывать данные в базу, делать Basic-авторизацию. В общем, демо будет максимально приближено к "боевым проектам" )
- Выльем наш бэкенд на Heroku и Digital Ocean (что это за звери, я тоже расскажу).
- Ну и, конечно же, в конце похоливарим на тему: "Зачем вам, как Swift-разработчикам под iOS, писать еще и backend". Дискуссия обещает быть жаркой!
Почему стоит использовать TypeScript в Angular2, какие есть фишки и особенности. Полезем под капот синтаксиса декораторов, разберем Reflect metadata API, и многое другое
Переход с Objective-C на Swift — все ли так просто? / Олег Алексеенко (SuperJob)Ontico
РИТ++ 2017, App's Conf
Зал Найроби, 6 июня, 10:00
Тезисы:
http://appsconf.ru/2017/abstracts/2818.html
Ни для кого не секрет, что Swift — это mainstream: его активно продвигает Apple, на нем пишутся все новые фреймворки, многие разработчики начинают именно с него. Но так ли просто мигрировать c Objective-С, если твоему приложению 5 лет и оно имеет большую аудиторию? В докладе мы расскажем о том, как сделать это без ущерба для бизнеса.
Вы узнаете об этапах такого перехода:
1. Какую бизнес-проблему решали? - Ускоряем разработку, уменьшаем количество багов, проще и быстрее находим новых сотрудников, ограждаем от будущих рисков (старых не поддерживаемых фреймворков, устаревших АПИ).
...
«Continuous Integration — A to Z или Непрерывная интеграция — кто всё сломал?»FDConf
Доклад о том, зачем нужен CI, как он интегрируется в процесс разработки. В докладе есть небольшое демо о весьма известном cloud-based CI сервисе Travis-CI. В процессе демо будет «поломан» билд и затем сразу же починен. Весьма показательно в том плане, что это доказывает простоту всей технологии.
Субъективная точка зрения на фронтенд разработку.
Площадка: IT-бар КЛЮЧ, https://vk.com/event69759919
Видео с доклада: https://www.youtube.com/watch?v=pyAYbbDJjPo
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
2. Что сейчас будет?
Рассказывает Григорий Петров
Специализация Руководство разработкой
Чем занимается Технический евангелист
Опыт Более 15 лет
Время выступления 45 минут
Вопросы В конце выступления, 15 минут
2
11. На что портировали?
TypeScript
- Создан в недрах Microsoft 4 года назад
- От автора Delphi и C#
- Обратно совместим с JavaScript
12. На что портировали?
TypeScript
- Создан в недрах Microsoft 4 года назад
- От автора Delphi и C#
- Обратно совместим с JavaScript
- Тулчейн в экосистеме npm
13. На что портировали?
TypeScript
- Создан в недрах Microsoft 4 года назад
- От автора Delphi и C#
- Обратно совместим с JavaScript
- Тулчейн в экосистеме npm yarn
14. На что портировали?
TypeScript
- Создан в недрах Microsoft 4 года назад
- От автора Delphi и C#
- Обратно совместим с JavaScript
- Тулчейн в экосистеме npm yarn
- Добавляет ES6, ES7 ...
15. На что портировали?
TypeScript
- Создан в недрах Microsoft 4 года назад
- От автора Delphi и C#
- Обратно совместим с JavaScript
- Тулчейн в экосистеме npm yarn
- Добавляет ES6, ES7 ES2016 ...
16. На что портировали?
TypeScript
- Создан в недрах Microsoft 4 года назад
- От автора Delphi и C#
- Обратно совместим с JavaScript
- Тулчейн в экосистеме npm yarn
- Добавляет ES6, ES7 ES2016 ... и типы!
30. Без капкана:
function addUser(name) { …
// где-то в другом месте
addUser(user.name)
С капканом:
function addUser(name: string) { …
// где-то в другом месте
addUser(user.name)
Через полгода:
// жертва рефакторинга
addUser(id)
Через полгода:
// ошибка проверки типов
addUser(id)
31. Без капкана:
function addUser(name) { …
// где-то в другом месте
addUser(user.name)
С капканом:
function addUser(name: string) { …
// где-то в другом месте
addUser(user.name)
Через полгода:
// жертва рефакторинга
addUser(id)
Через полгода:
// ошибка проверки типов
addUser(id)
32. Плюсы и минусы типизаций
Dynamic typing
- Скорость разработки
- Капканы срабатывают не сразу
- Капкан может не поставиться
Static typing
- Скорость разработки
- Нужно думать
- Капканы срабатывают сразу
33. Плюсы и минусы типов
Dynamic typing
- Скорость разработки
- Капканы срабатывают не сразу
- Капкан может не поставиться
Static typing
- Скорость разработки
- Нужно думать
- Капканы срабатывают сразу
TypeScript: Gradual Typing
34. Плюсы и минусы типов
Dynamic typing
- Скорость разработки
- Капканы срабатывают не сразу
- Капкан может не поставиться
Static typing
- Скорость разработки
- Нужно думать
- Капканы срабатывают сразу
TypeScript: Gradual Typing
- Добавляем типы только там, где надо
35. Плюсы и минусы типов
Dynamic typing
- Скорость разработки
- Капканы срабатывают не сразу
- Капкан может не поставиться
Static typing
- Скорость разработки
- Нужно думать
- Капканы срабатывают сразу
TypeScript: Gradual Typing
- Добавляем типы только там, где надо
- Быстрое прототипирование и модификации
36. Плюсы и минусы типов
Dynamic typing
- Скорость разработки
- Капканы срабатывают не сразу
- Капкан может не поставиться
Static typing
- Скорость разработки
- Нужно думать
- Капканы срабатывают сразу
TypeScript: Gradual Typing
- Добавляем типы только там, где надо
- Быстрое прототипирование и модификации
- Защита кода после стабилизации
38. Зачем типы нам в Voximplant
Фиксируем контракты методов
Страхуем себя в мире WebRTC
39. А что будет у клиентов?
А у клиентов будет JavaScript
TypeScript ES2015 ES5
class Foo {
bar = () => {
console.log(this);
}
}
class Foo {
constructor() {
this.bar = () => {
console.log(this);
};
}
}
var Foo = (function () {
function Foo() {
var _this = this;
this.bar = function () {
console.log(_this);
};
}
return Foo;
}());
40. А что будет у клиентов?
С классами тоже все будет хорошо *
TypeScript ES2015 ES5
class Foo {
bar = () => {
console.log(this);
}
}
class Foo {
constructor() {
this.bar = () => {
console.log(this);
};
}
}
var Foo = (function () {
function Foo() {
var _this = this;
this.bar = function () {
console.log(_this);
};
}
return Foo;
}());
* Если не используется что-нибудь атипичное
83. Ловушки для ошибок
Все новое из мира JS
Возможен постепенный переход
Поддерживает Microsoft
84. Ловушки для ошибок
Все новое из мира JS
Возможен постепенный переход
Поддерживает Microsoft
npm экосистема
85. Ловушки для ошибок
Все новое из мира JS
Возможен постепенный переход
Поддерживает Microsoft
npm экосистема
Ловушки нужно ставить вручную
86. Ловушки для ошибок
Все новое из мира JS
Возможен постепенный переход
Поддерживает Microsoft
npm экосистема
Ловушки нужно ставить вручную
Адские сообщения об ошибках
87. Ловушки для ошибок
Все новое из мира JS
Возможен постепенный переход
Поддерживает Microsoft
npm экосистема
Ловушки нужно ставить вручную
Адские сообщения об ошибках
Нужны сильные программисты
88. Ловушки для ошибок
Все новое из мира JS
Возможен постепенный переход
Поддерживает Microsoft
npm экосистема
Ловушки нужно ставить вручную
Адские сообщения об ошибках
Нужны сильные программисты
Не все можно явно переписать
89. Ловушки для ошибок
Все новое из мира JS
Возможен постепенный переход
Поддерживает Microsoft
npm экосистема
Ловушки нужно ставить вручную
Адские сообщения об ошибках
Нужны сильные программисты
Не все можно явно переписать
Не для всего есть готовые типы