Новости • События • Публикации

Новости ITSupportMe

post image

Разработка

Для тех, кто любит «пожестче»: о hardware-проектах ITSupportMe

Мы говорим IT-компания в Беларуси, подразумеваем — разработка ПО, мы говорим разработка ПО в Беларуси, подразумеваем — IT-компания! И не удивительно, ведь еще во времена наших пращуров эта страна считалась своеобразной «Силиконовой долиной», даже сам русскоязычный термин «программное обеспечение» появился именно здесь. А еще на этой территории производилось более 50% советских компьютеров и комплектующих к ним. А это значит, страсть к «железу» у нас в крови. И яркое подтверждение тому — немало успешных hardware-проектов ITSupportMe. Для реализации многих из них нам пришлось не только организовать полноценное конструкторского бюро, но и примерить на себя роль настоящего центра инженерных исследований (R&D) и прототипирования (металлообработка, пластик, электроника и др.). Мы уже рассказывали вам про наш портативным глюкометр. Настало время новой истории. Слово нашему разработчику Владимиру Заворотному, который согласился рассказать нам, чем сейчас занимается его команда. Над чем вы сейчас работаете? В аквапарках, на горнолыжных курортах, различных аттракционах часто можно заметить камеры, которые автоматически фотографируют летящих на полной скорости отдыхающих, а затем эти снимки можно получить, например, на стойке регистрации. Вещь, кажется, вполне простая, но если обратить внимание, такие устройства частенько выходят из строя, и вообще непонятного происхождения. Мы решили исправить это недоразумение и разработать надежную, точную и быструю систему с полной гарантией качества: от железа до софта, которое будет эти фотографии отдавать. Сколько времени вы работаете над проектом? Большая ли команда? Для создания прототипа и начала его тестирования потребовалось два с половиной месяца. На этом этапе было задействовано три разработчика. После создания самой камеры мы начали развивать сервис дальше. Нам понадобился магазин, взаимодействие с Амазоном. Сейчас над проектом трудятся уже пять человек. Насколько это самостоятельная разработка? Техническое задание к проекту было довольно свободным. Нам описали только функции, которые должно выполнять устройство, и железо, на котором все должно работать. Архитектуру и технологии выбирали сами. Интересно работается? Очень. Самое интересное в проекте для нас — широта решаемых задач. У нас не только была возможность строить устройство с нуля, но и самим проводить испытания «в поле». И если где-то косячили, карма настигала нас мгновенно :) Такие разработки — когда имеешь свободу принятия решений и сразу видишь/чувствуешь, насколько они удачны/стабильны — и приносят больше всего опыта на единицу потраченного времени. Особенно приятно, когда результат работы можно подержать в руках. А с какими вызовами столкнулись вы как специалисты? Hardware-проекты всегда очень интересны, в первую очередь, тем, что, помимо менеджеров и программных багов, приходится сражаться еще и с законами физики. Много сложностей возникало, когда собирали в одно устройство все модули, над которыми работали разные члены команды. Непонятные ошибки появлялись в самых неожиданных местах, когда все вроде собрано по схемам, но не работает. А проблемы крылись или в слишком длинном кабеле, который соединял блоки устройства, или в случайно убитой статикой микросхеме. В наш набор для hardware-разработки, кроме таких стандартных элементов, как мультиметр, блоки питания и т.д., вошел также SDR-приемник. Почему это важно? Дело в том, что в проекте задействованы радиопередающие модули, предназначенные для работы в Северной Америке. Они используют частоты, которые мы не можем использовать в нашей стране. Поэтому пришлось придерживаться ближайших разрешенных и внимательно следить за тем, чтобы случайно не выйти в эфир на запрещенном диапазоне. Какие планы на будущее? Как ни печально, когда-нибудь все веселье подходит к концу. Так что в планах у нас успешный релиз. Ну, и в будущем хотелось бы пожелать нам больше hardware-проектов для выполнения ответственных задач: транспорта, медицины.

ITSupportMe

20 января, 2021

post image

Разработка

Frontend-разработка: роскошь или залог выживания бизнеса?

Прошли те времена, когда одной гениальной идеи было достаточно, чтобы свернуть целые горы, а наличие надежного бухгалтера и четкого плана гарантировало плавучесть вашего бизнеса в море финансовых колебаний и рыночных перемен. Предугадать последнее сегодня задача не из простых, поэтому любое успешное предприятие, независимо от своих размеров и направленности, старается быть максимально гибким и мобильным. Как этого добиться в ХХI веке? Конечно же, поставив на IT-рельсы! И если с бэкенд-частью программного обеспечения более-менее понятно: придут умные ребята и напишут все, как надо, а под капот водителю нынче лазить не обязательно, а то и небезопасно — то как же быть с его «лицевой частью»? Стоит ли вкладываться в разработку интерфейса приложения или это очередной способ «утяжелить» проект и выбить из вас побольше денег? Разбираемся в вопросе вместе с тимлидом отдела Frontend-разработки ITSupportMe Владимиром Марковым. Насколько сегодня востребована frontend-разработка бизнесом? Очень востребована. Современный бизнес хочет иметь максимально гибкие приложения, адаптированные к экранам любого разрешения. Современный бизнес ожидает от своих веб-приложений максимальной производительности. Современный бизнес хочет, чтобы его приложения были SEO friendly. Эти и многие другие задачи призван решить современный фронтенд-разработчик. Все основные фреймворки сегодня бесплатны, за что же платит заказчик? За время разработки, которое опытные специалисты тратят, чтобы сделать его приложение быстрым, стабильным в работе и привлекательным для пользователей. Не секрет, что хорошее веб-приложение повышает прибыль почти любого бизнеса, а, следовательно, стоимость разработки — это инвестиция в его будущее. На чем сейчас нужно делать приложения, чтобы они не устарели еще несколько лет? React и Vue — мое предпочтение. При старте новых проектов разработчики обычно решают многие типовые задачи: от определения архитектуры до реализации функционала по заказу клиента (бизнес-логика). Какие из них ваши разработчики могут решить в течение нескольких минут? У нас в команде не любят тратить время впустую. Чтобы максимально повысить свою производительность, мы разработали общие правила по код-стайлу, а также подходы к проектированию и разработке веб-приложений, создали темплейты для быстрого старта новых проектов. Что же касается собственно разработки, почти все задачи мы можем решить крайне быстро, если заказчик ставит условие сделать всё быстро и плохо. Наша команда не про «быстро», наша команда про «качественно», но с наиболее возможной скоростью, чтобы не терять в качестве. Исключением из этого правила может быть только стадия MVP (минимально жизнеспособный продукт — прим.) для приложения. Но даже в таком случае вопрос не в минутах, конечно, а в часах. От frontend до full-stack разработчика один шаг или пропасть? Сколько специалистов нужно нанять: одного или нескольких, где каждый отвечает за свою часть? На самом деле между frontend и full-stack разработчиками лежит много часов учебы и практики. Что касается количества разработчиков для frontend-части, многое зависит от того, на какой рынок ориентируется компания. Большие и сложные проекты нуждаются в опытных специализированных разработчиках. Маленькие проекты тяготеют, как правило, к «универсальным солдатам». Фулстек специалистам больше прощается, если у них просадка по каким-то вопросам во фронте/бэкенде. Привлечение каких специалистов обязательно, чтобы фронтенд-разработчик максимально эффективно выполнил свою задачу? Зависит целиком и полностью от задач клиента. Иногда достаточно только фронтенд-разработчика. Так, например, с опытом так или иначе ты начинаешь разбираться в UI/UX, то есть при острой необходимости можно сэкономить на дизайнере. Но на серьезных, масштабных проектах, конечно, каждый должен заниматься своим делом. Что значит понять пользователя для фронтенд-разработчика? Понять конечного пользователя — иметь возможность посмотреть на приложение его глазами — ценный скилл для фронтенд-разработчика. В итоге же мы все пользователи, только пользуемся иногда разными приложениями. Доработка существующих проектов или разработка с нуля? Важно ли как профессионалу не отказываться от первого? Я за оба варианта. Конечно, любому разработчику комфортнее начинать с нуля, но участие на уже существующих проектах обогащает тебя в плане подходов к проектированию и умения разбираться в чужом коде и логике — это важная часть роста. Как фронтенд-разработчик влияет на разработку бизнес-логики и backend-системы для поддержки продукта? Как правило, фронтенд согласовывает, какую информацию сервер будет отдавать по определенным запросам с фронта. Зарплата фронтенд-разработчика прямо пропорциональна количеству навыков? Если, помимо количества, присутствует качество этих самых навыков, то в большинстве случаев это верно. За счет чего сильно может вырасти эффективность разработки? Весь вопрос в людях, не в инструментах. Мотивированные разработчики найдут нужные инструменты, чтобы повысить эффективность процесса. На счету нашего довольно молодого отдела уже более 30 проектов, и ни к одному из них мы не подходили как к «типовому». Каждая бизнес-задача уникальна, а следовательно, индивидуальными должны быть и подходы к ее реализации.  Вообще мощнейший инструмент фронтенд-разработчика — эмпатия. Этим мы и руководствуемся, создавая «лицо» любого приложения или веб-платформы. Мы делаем его именно таким, каким оно и должно быть в ХХI веке: чертовски привлекательным, с многообещающей улыбкой и визитной карточкой, предвещающей скорую встречу.

ITSupportMe

27 ноября, 2020

post image

Разработка

19 глупых и не очень вопросов о Frontend-разработке, за которые нам не стыдно

19 глупых и не очень вопросов о Frontend-разработке, за которые нам не стыдно IT-индустрия не стоит на месте, а вслед за ней растет и развивается ITSupportMe. Так, в этом году в нашей компании из горнов разработки ПО вышел новый Frontend отдел. Причин этому более чем достаточно, но давайте дадим слово тимлиду новоиспеченного подразделения Владимиру Маркову, а заодно узнаем получше, что это за профессия такая — фронтенд разработчик. 1. Буквально в двух словах, кто такой фронтенд-разработчик? Это разработчик, который занимается программированием интерфейсов. Все страницы, кнопки, поля для ввода текста и что угодно, с чем ты взаимодействуешь как пользователь на сайте, было спроектировано и создано фронтенд-разработчиком. Стоит уточнить, что над дизайном часто работает все-таки дизайнер, но вот как дизайн перенести и «оживить» на странице — это уже обязанность фронтенд-разработчика. 2. Привет от нубов! Давай попробует сравнить зеленое и круглое, или в чем главное различие и сходства фронтенд-разработчика и его PHP-коллеги? Честно говоря, все различия и сходства, которые приходят мне в голову, будут сильно притянуты за уши. Фронтенд-разработчик занимается только интерфейсом веб-приложений, в то же время PHP-разработчик занят преимущественно программированием серверной части приложения. 3. Каким багажом знаний должен обладать фронтенд-разработчик на старте? Если говорить о разработчике джуниор-уровня, то я бы сказал, что это знание основ HTML, CSS, JavaScript плюс какой-нибудь популярный JS-фреймворк. Очень большим плюсом (хоть это и не обязательное требование) будет знание английского языка на хорошем уровне (B2+). Ну, и желание развиваться и впитывать новый опыт, конечно. 4. Как понять, что ты уже достаточно крут в своей области? Сложный вопрос. Отвечу, когда пойму, что я крут в своей области). 5. Твой самый интересный проект? Проект, на котором я работаю сейчас. Прекрасная англоязычная команда мотивированных ребят, современные технологии и возможность непосредственно влиять на конечный продукт — я определенно рад быть частью всего этого. 6. О каком проекте ты мечтаешь? Сложно сказать. Меня устраивает проект, на котором я нахожусь сейчас. 7. Правда ли, что фронтенд-разработчик постоянно учится? Что нового в своей области ты узнал за последнее время? Это справедливо для специалиста любой области, который хочет оставаться «на рынке», и фронтенд-разработчики здесь не исключение. Я постоянно работаю над своим уровнем. В частности, сейчас я уделяю больше внимания оптимизации производительности веб-приложений, а также вопросам архитектуры приложений. 8. Из личного опыта: какие фреймворки дают прирост скорости, качества и снижение стоимости разработки? Любой фреймворк по сути решает эти вопросы. Я не работал со всеми существующими решениями. Активно использовать мне приходилось только React и Vue — очень доволен этими инструментами. 9. А React или Angular?) React) Почему Владимир так уверен? Читай здесь. 10. Как относишься к бурчанию джавистов по поводу того, что JavaScript — это такая недоJava? С пониманием. Главное, чтобы на людей не кидались. 11. Практически любой современный популярный фреймворк достаточно хорош, чтобы на нём создать практически любое приложение, актуальное для современного бизнеса. Согласен? Абсолютно. 12. Не секрет, что в программирование частенько приходят из других областей. Из каких? Какие варианты наиболее/наименее болезненные? Мне кажется что здесь всё слишком индивидуально. Если человек готов работать над собой, любой бэкграунд не помеха. 13. А что насчет возраста? Когда уже поздно или когда еще рано? Никаких ограничений по возрасту. 14. Разнообразие технологий vs унифицированный стек — что выбираешь ты как тимлид? Разнообразие технологий. 15. Нужна ли креативность фронтенд-разработчику? Что делать, если в душе ты дизайнер? Креативность не помешает в любом деле. Фронтенд-разработчик нередко сам принимает решения по дизайну интерфейсов. Даже на проектах, где есть отдельная команда дизайнеров, к твоему мнения обязательно прислушаются, ведь ты в конечном итоге будешь переносить дизайн в код. «Что делать, если в душе ты дизайнер?» — работать дизайнером. 16. Как понять, где твои полномочия заканчиваются и пора позвать смежного специалиста? С какими спецами фронтенд обычно взаимодействует? Я думаю, если ты видишь, что есть задача, где твоих знаний недостаточно, чтобы решить ее наиболее эффективно для заказчика, можно «дергать» профильных спецов. Фронтенд-разработчик взаимодействует преимущественно с бэкенд-разработчиками, дизайнерами, devOps-разработчиками, тестировщиками, проектными менеджерами и бизнес-аналитиками. В некоторых случаях можно пообщаться с заказчиком приложения или даже с конечными пользователями. 17. Какой путь развития фронтенд-разработчика тебе по душе: горизонтальный (совершенствоваться как специалист); вертикальный (расти по карьерной лестнице); диверсификационный (освоение смежных специальностей, превращение в фулстака и переквалификация)? Пока что мне сложно ответить на этот вопрос ввиду малого опыта «тимлидства». Но думаю, мои предпочтения будут где-то между первым и вторым вариантами. 18. Как появилась идея создания отдела? Какие у вас планы на будущее? Идея создания отдела существовала уже достаточно давно. Компания развивается, и старается расти в том числе качественно. Фронтенд отдел — это повышение экспертизы компании в области фронтенд-разработки и, следовательно, увеличение рынка предоставления услуг. Планы на будущее: продумать систему онбординга в рамках команды, разработать общие правила по код-стайлу и подходу к проектированию и разработке веб-приложений, создать темплейты для быстрого старта новых проектов. На уровне отдельно взятого разработчика мы выделили места, над которыми планируем работать, чтобы становиться лучше и гибче как отдел. 19. Какой самый главный софт скилл в твоей профессии, который ты бы хотел видеть в своих коллегах? Эмпатия

ITSupportMe

14 октября, 2020

post image

Разработка

Из варяг в греки, или зачем нам Котлин

Дисклеймер Данный материал ни в коем случае не претендует на серьезное исследование, а является коротким видением того, почему мы выбираем (или нет) Kotlin для своих проектов. Выводы представлены на основе двухлетнего опыта работы команды ITSupportMe с этим языком программирования. Из варяг в греки, или зачем нам Котлин Немного истории В 2011 году в океане информационных технологий стало на один остров больше. Российская компания JetBrains представила свою новую разработку – язык программирования Kotlin, по аналогии с Java названный в честь участка суши, на этот раз Финского залива. Через каких-то шесть лет этот довольно смелый и амбициозный проект достиг поразительных результатов. Так, на конференции Google I/O 2017 Kotlin стал одним из трех языков, по стандарту включенных в Android Studio 3.0 (первые два — Java и C++). Whyyyyyyyyyy? (что в переводе с английского означает «немного оптимистичной теории») В чем же секрет популярности детища JetBrains, и почему многие программисты обращаются именно к его инструментарию при решении тех или иных IT-задач. Причина номер раз: Java уже не та? Kotlin был придуман командой, которая создала большое количество продуктов на Java и хорошо ориентируется в новейших технологиях разработки. Для них, как и для многих других специалистов, не секрет, что сегодня Java развивается очень медленно. Новый функционал добавляется в нее с большим скрипом. В некотором роде это связано с тем, что «большая» Java, также известная как Java EE, накапливает колоссальный объем проектов, и их важно сохранить при обновлении системы. Такая ситуация, а также ряд других причин, породила потребность в новом, JVM-адаптированном языке программирования, с одной стороны, не нуждающемся в обратной совместимости, а с другой – свободно взаимодействующем с обширным диапазоном инструментов, плагинов и библиотек Java. Таким языком программирования и стал Kotlin. Причина номер два: это просто? Два главных достоинства Kotlin, с точки зрения многих его сторонников, это простота работы поверх JVM. JetBrains задумали свое детище как статический типизированный объектно-ориентированный язык индустриального уровня, который лаконичнее и типобезопаснее, чем Java, проще чем Scala, и при этом свободно компилируется для Java и JavaScript, что позволяет постепенно перейти со старой платформы на новую. Одним из примеров простоты и гибкости Kotlin является специфика его интеграции с системой Android, куда он встраивается посредством Gradle. В дальнейшем это позволяет внедрять новый функционал для Kotlin без переписывания Android-приложения целиком. Причина номер три: оно тебе надо? Kotlin представляет большой интерес для всех разработчиков, имеющим дело с Java-машиной или любыми языками со сборщиком мусора в целом. Упомянутая выше простота и адаптивность эксплуатации дает возможность почти любому Java-специалисту, готовому посвятить полчаса своего времени изучению туториала и спецификации языка, начать применять его в своей практике, а обратная совместимость решает проблему использования  Kotlin в уже действующем проекте. И еще N-цать технических причин Null-безопасность Система типов в Kotlin направлена на искоренение проблемы, в Java известной как NullPointerException (NPE). Она возникает при попытке отсылки к null значению. Kotlin избегает такой ситуации, выдавая ошибку компиляции. Конечно, это не идеальное решение (а какие идеальные?), и все равно остаются лазейки для «ошибки на миллион»: этому могут способствовать как внутренние (прямое указание throw NullPointerException() или использование оператора !!), так и внешние (например, ошибки самого Java-кода) причины. Гибкость и простота синтаксиса В Kotlin код выглядит менее громоздким и намного более читабельным, так как в нем простые подпрограммы, функции и структуры можно объявить одной строкой. При этом геттеры и сеттеры задаются за кулисами для полного взаимодействия с Java. Добавление же аннотации базы данных к классу позволяет генерировать различные шаблоны автоматически. Классы данных Разработчики Kotlin добавили специальные классы для хранения данных и генерирования различных шаблонов: equals(), hashCode(), toString(), геттеров и сеттеров и др. Функции-расширения Kotlin обеспечивает расширение функционального диапазона имеющихся классов без наследования, что достигается посредством функций-расширений. Чтобы объявить такую функцию, к ее имени нужно добавить префикс в виде расширяемого типа. Умные преобразования типов Компилятор Kotlin весьма удобен для приведения типов. Во многих случаях вам не нужно будет явно указывать операторы преобразования, так как эту работу за вас выполнит оператор is. Функциональное программирование Важно отметить, что Kotlin – это действенный инструмент функционального программирования, в вооружении которого широкий спектр полезных возможностей: функции высшего порядка, перегрузка операторов, лямбда-выражения и многое другое. Сравнение скорости Java и Kotlin При чистой сборке Java превосходит Kotlin на 15–20%. Однако чаще разработчики прибегают к частичной сборке, где благодаря активному демону Gradle и включенной инкрементальной компиляции Kotlin даже немного быстрее Java. Таким образом, языки приблизительно равны по скорости компиляции. А мы что? Как вспоминает наш специалист Иван Брель, опыт работы ITSupportMe с Kotlin начался с любопытства. Затем ребята убедились, что это работает — и понеслось. На самом деле в компании не так много проектов, написанных на этом языке, во многом из-за бытующего в среде разработчиков скептицизма по поводу всего нового. — Если стартует новый проект, то, мол, нужно использовать проверенные вещи, куда там Kotlin! Но как показывает время, в освоении он очень легок, а профитов больше, — замечает Иван. Наш собеседник подчеркивает, что зачастую ошибки в использовании Kotlin связаны с тем, что разработчики пишут на нем как будто это Java, только кода меньше. Однако постепенно приходит понимание общей концепции — и тогда становится ясно, что это совсем другое. Хорошая иллюстрация такой эволюции — внутренний проект компании ITSM Portal, где при детальном осмотре можно найти и «первый блин комом», и примеры хорошего кода: «на этом проекте мы попробовали все», — поясняет Иван. Разработчик добавляет, что его команда в своей работе использует как новые фичи и фреймворки, так и нативные вещи типа сертификатов от Sun — и ни с чем не было проблем: В целом Kotlin сильно облегчает жизнь: код краток, конструкции понятнее, многие вещи уже сделаны — и можно просто их использовать, плюс полная совместимость с Java. То есть все написанное ранее также будет работать, как и сторонний код на Java. Для Василия Писпанена текущий проект компании — первый опыт использования Kotlin с нуля с целью создания крупномасштабной и сложноархитектурной системы. — Проект — сущий ад с точки зрения архитектуры: больше десятка амазоновских сервисов, блокчейн, лицензирование кода, приличная нагрузка и отсутствие права на ошибку, так как через платформу будут гонять большие деньги, — то ли сетует, то ли восхищается наш собеседник. — Чтобы комфортно девелопить конкретно этот проект 16 гигов оперативки уже маловато. Интеграционные тесты поднимают два десятка докер-контейнеров — в такой момент уже мало что можно делать за компом. В таких условиях Kotlin видится нашему специалисту отличным решением: «в целом более функциональный стиль, крутые лямбды, компактный код и много мелких плюшек из коробки вроде extension functions или интерполяции строк». Есть и неудобные для разработчика моменты. Например, не поддерживаются repeatable annotations из Java. Многие стандартные для Java вещи задуманы как самостоятельные библиотеки (serialization, coroutines), и не всегда можно безболезненно обновить их вслед за версией самого языка. Конечно, можно использовать котлинские библиотеки из Java, но декомпилированный Kotlin класс выглядит не лучше обфусцированного кода. Некоторые синтаксические конструкции, вроде разных видов конструкторов, выглядят для Василия очень странно. — А ещё idea часто нещадно тупит в плане анализа кода и подсветки синтаксиса (JetBrains, алло, ну как так!), — эмоционально добавляет он. Имеет свое веское мнение о Kotlin и Алексей Метлицкий. Еще со времен тренингов в ITSupportMe, которые посещал молодой специалист, прежде чем прочно обосноваться в штате компании, стало ясно, что Kotlin очень приятный в использовании язык, и при старте новых проектов, если заказчик не настаивает на Java, есть смысл отдать предпочтение именно ему. На данный момент в эффективности детища Jetbrains Алексей убедился в рамках как минимум трех проектов. Как оказалось, на этом языке ему как программисту проще и комфортнее выражать свои намерения: — Создатели позаботились о том, чтобы максимально сократить количество букв в выражениях, которыми пользуются программисты, и добавили много «плюшек», позволяющих быстрее и читать, и писать код. Главным плюсом Kotlin для нашего собеседника является его полная совместимость с библиотеками Java. — А еще то, как язык работает «под капотом», мало чем отличается от Java. Это позволяет Java-разработчикам в очень краткие сроки добавить Kotlin в своё портфолио, — добавляет Алексей. — А тот факт, что язык гораздо моложе своего предшественника, означает, что можно начать его создание практически с чистого листа, не цепляясь за неудачные решения и ошибки, которые накопились в Java за  годы её существования. Кроме того, в JetBrains поработали над вопросами безопасности кода в плане его защищенности от ошибок. Еще одно очевидное достоинство Kotlin — это более простой в чтении и написании, современный, продвинутый, развивающийся (а значит и перспективный), свободный от проприетарных лицензий язык программирования. — Я считаю, что он мог бы стать нашим основным инструментом разработки, вот так, — уверенно подытоживает Алексей. Перечисление достоинств Kotlin можно продолжать еще долго. Равно как бесконечно обсуждать плюсы и минусы (конечно же, фундаментальные :)) использования этого языка при разработке. Однако на сегодняшний день команде ITSupportMe ясно одно: пора бы уже перестать скептически относиться к любому новому продукту. Ведь главное в разработке не то, на каком языке вы пишете. Гораздо важнее ваши трудозатраты на решение той или иной задачи. Программисты пишут код. И если на этом этапе удастся сэкономить время, то быстрее пройдет стадия тестирования и больше останется для разработки бизнес логики продукта. Как достичь такой цели — решать вам.

ITSupportMe

29 мая, 2020

post image

Разработка

Наши на Joker 2019

Осень пришла — учиться пора! Свежий прохладный воздух, затяжные дожди и падающие листья — идеальный сеттинг для приобретения новых знаний и навыков. Возможно, именно поэтому много крутых IT-событий проводят в это время. Например, международная Java-конференция Joker 2019, прошедшая 25–26 октября 2019 в здании Экспофорума в Питере. Это крупное событие в среде опытных разработчиков и тимлидов растянулось на целый уикенд и включило в себя четыре talk-трека, сорок технических докладов разных уровней сложности (уже знакомая нам классификация — будет подгорать, введение в технологию, для практикующих инженеров и хардкор) и около 2000 коллег-участников, с которыми прямо на месте можно было обсудить весь этот размах. Понятное дело, пропустить такое мероприятие ITSupportMe не могли. Первый день конференции таил в себе немало противоречий. С одной стороны, он был более лайтовым — большинство тем носило вводный или практико-ориентированный характер — с другой — именно после этого относительного ровного информативного потока слушателей ждала настоящая пуканоподгорающая дилемма в конце вечера. Но обо всем подробнее. Joker 2019 открыл один из основателей Spring Framework Юрген Хеллер, который вместе со своим коллегой из компании Pivotal Джошем Лонгом продолжил свою миссионерскую практику введения в мир Spring Framework and Spring Boot. Лучший спич, кстати, по версии наших программистов. К слову, введением в технологию лекторы не ограничились и подготовили ещё по одному докладу, на этот раз для практикующих инженеров. Так, к концу этого вечера Джош Лонг продемонстрировал всем желающим свой взгляд на тестирование Spring приложений и сервисов. Ну, а на ночь грядущую не лишним было послушать выступление Юргена Хеллера, посвященное детальному разбору функционала Spring Framework 5.2. Но вернемся к началу. Если первая тема давно набила вам оскомину, и ничего нового именитый разработчик рассказать вам не мог, то, возможно, параллельные спикеры могли как-то исправить ситуацию: Геррит Грюнвальд (Karakun AG) и его попытки убедить, что Джава на рабочем столе не мертва, Томас Вюртингер (Oracle), рассказывающий и показывающий, как улучшить производительность с GraalVM, ну, и куда же без хардкора — Владимир Озеров (Hazelcast), раскрывающий общие подходы к организации многопоточности в распределенных системах, а также конкретные архитектурные решения своей команды. Два введения в технологию ждали слушателей и в следующей порции выступлений: Саймон Риттер (Azul Systems) обсудил с присутствующими важные функции, добавленные в Java со времен JDK 9, а также рассмотрел состояние долгосрочных фьючерсов; Берр Саттер (Red Hat) показал, как Java оптимизирована для микросервисных и серверных архитектур. Кроме того,  практикующие инженеры получили возможность улучшить производительность реактивного сервиса вместе с Олегом Докукой (Netifi, Inc), а любители немного посушить мозги над сложной задачкой открывали мир компиляторов и HotSpot «C2» JIT вслед за Клиффом Кликом. После обеденного перерыва (к слову, отлично организованного: просто, но со вкусом, а главное, никаких очередей) слушатели с новыми силами окунулись в мир интеллектуального чиллинга. Три информативных введения в технологию ожидали их: Себастьян Дашнер (IBM) поговорил о том, как сделать более продуктивные рабочие процессы разработки, Юрий Артамонов (JetBrains) предложил пройти краш-курс по IntelliJ IDEA Plugin DevKit, а Роберто Кортез (Talkdesk) показал, как GraalVM может помочь интегрировать MicroServices и другие части вашего приложения. Это помимо уже упомянутого доклада Джоша Лонга. Ближе к вечеру градус сложности докладов немного повысился — Никита Коваль (JetBrains) рассказал, как Lincheck помогает в тестировании многопоточных алгоритмов, а Алексей Андреев (Delightex) пожаловался на трудности перевода из Java в JavaScript. Были и просто информативные выступления двух представителей технологических китов: Марк Хеклер из Pivotal о Spring Security для N00bz и Далиа Або Шеаша из IBM об особенностях Java 8 и специфике перехода на Java 11 или 12. Ну, и последняя связка — помимо отмеченного выше доклада от ведущего специалиста Pivotal Юргена Хеллера, практикующих инженеров могло заинтересовать выступление Дмитрия Константинова (Netcracker), посвященное Apache Cassandra, её производительности, внутренним проблемам и преимуществам. Кроме того, Кей Хорстманн из университета Сан-Хосе представил вниманию собравшихся эволюцию Java 13 и выше. Ну, и одна хардкорная штука ожидала тех, кто не боится бессонницы — Ионут Балосин (Raiffeisen Bank International AG)  вместе со всеми желающими проверил эффективность нового современного JIT-компилятора GraalVM по сравнению с  JIT C2. Наконец, последнее выступление — Барух Садогурский (JFrog), который и предложил участникам Joker 2019 похоливарить на довольно щекотливую тему «DevOps для разработчиков (или против них?!)». На этой шумной ноте можно было и заканчивать, но организаторы пошли дальше — вечеринка с пивом и музыкой, различными зонами для отдыха, общения и обсуждения ждала всех, кто хотел разгрузить голову после такой насыщенной пятницы. Для наших же ребят финал первого дня особенно запомнился возможностью лично поговорить с одним из основателей Spring Framework Юргеном Хеллером и его коллегой по компании Pivotal Марком Хеклером, которых они случайно встретили в зале после конференции. Наши разработчики поделились своим впечатлением от выступлений именитых спикеров, задали им пару вопросов про «потенциальное развитие Java как языка программирования, реактивного программирования, RSocket и Spring WebFlux и поделились, что бы хотели услышать в их докладах в будущем». Примечательно, что эта незапланированная встреча прошла максимум информативно и позитивно: как отмечает Сергей Волосович, «они очень дружелюбные были и на любой вопрос старались развернуто отвечать и подробно». Второй день Joker-а оставил шутки в сторону и сконцентрировал внимание участников на практических задачах и проблемах Java технологий. Только считанные темы выступлений были посвящены введению в технологию. Так, в 12.30 Трастин Ли из LINE+ Corporation рассказал про микросервисную структуру Armeria, его сменили Яцек Куницкий из SoftwareMill в 14.30, поведавший собравшимся про ScalaTest, и Симонe Бордет из Webtide, в 16.30 продемонстрировавший эффективность одновременных сборщиков мусора: ZGC & Shenandoah. Произвел же впечатление на наших разработчиков завершающий доклад Стивена Чина «Расшифровка технохайпа для занятого кодера» — о последних тенденциях сегмента: блокчейн, чат-боты, конвейеры CD, AI, машинное обучение и др. Как замечает Сергей Волосович, «помимо новых инструментов, я встретил и те, которые использую сейчас, что не может не порадовать». В целом же большинство выступлений второго дня были ориентированы на практикующих инженеров и, как правило, на примере конкретных кейсов рассматривали определенные проблемы и сложные моменты в технологии. Так, Кирилл Толчакев (ЦИАН) и Евгений Борисов (Naya Technologies) рассказали о том, как безболезненно внедрить React в свой проект и какие проблемы стоит учитывать при рефакторинге. Гуннар Морлинг из Red Hat представил практические варианты использования потоковых данных с Apache Kafka и Debezium. Тагир Валеев (JetBrains) поделился наблюдениями над «маленькими оптимизациями» Java 9-14. Никита Сальников-Тарновский (Plumbr) разоткровенничался на тему «Потоковое приложение — это не только код, но и 3–4 года поддержки в проде». Сергей Егоров из Pivotal поведал о подробностях релизов Testcontainers и провел краткий экскурс по теме для новичков. Наконец, Олег Ненашев (CloudBees) рассказал и показал, как его команда внедряла поддержку Java 11 в Jenkins. В общем, интересных тем было хоть отбавляй, а это помимо обилия хардкорных направлений (Valhalla; Alibaba Dragonwell; плагин TornadoVM для OpenJDK; эффективные микросервисы; новые функций JVM и изменения в последней версии JDK). И это при всей бренности тела человеческого, ставящего непреодолимый физический лимит — не более 5 докладов в день! Конечно же, на конференции нашлось место и массе оффтопных ивентов. Были традиционные стенды работодателей, где предлагались призы на решение какой-нибудь головоломки. Привлекли наше внимание и Demo Stage, на которых разработчики (как правило, представители спонсоров) выступали с небольшими докладами и делились опытом. Ну, и закуски в течении дня, чай и кофе не давали нашим ребятам отвлекаться на проблемы житейские. В целом поездка получилась очень продуктивной. Масса впечатлений, новые знакомства, горы заметок и пара-тройка черновых набросков на будущее и, конечно же, глоток свежего питерского воздуха — ради этого стоило потратить выходные и окунуться с головой в приключение!

ITSupportMe

30 октября, 2019

post image

Разработка

Что нового на J-Point-2019, или ITSupportMe в Москве

JPoint — одна из самых масштабных Java-конференций в России, да и всей Европе, посещение которой давно стало доброй традицией для программистов ITSupportMe. Прошлая неделя не стала исключением: 5–6 апреля 2019 года наши ребята провели в Москве, в Конгресс-центре ЦМТ, где более тысячи участников встретились, чтобы прослушать 43 доклада (вернее, попытаться прослушать хотя бы четверть из представленных: четыре параллельных трека — это вам не шутки!) от самых именитых спикеров из России, Великобритании, Германии, Нидерландов, Польши, Румынии, США, Швейцарии, Эстонии. Основные темы, затронутые на мероприятии: производительность, concurrency, тестирование, распределенные системы и высокие нагрузки в мире Java, а также будущее платформы. На закуску — фирменные фичи мероприятия — BoF-сессии (обсуждения, где нет ведущих и спикеров) по четырем направлениям: «Microservices, cloud и куда всё это двигается»; «Reactive — today’s need and future perspectives», «Rumble in the Java jungle (Oracle JDK, your own OpenJDK build, alternatives)», «Why does Java run slow?», а также дискуссионные зоны, вечеринка и различные оффтопные ивенты. В этом году организаторы ввели новую категорию в личном классификаторе докладов: помимо старых добрых «введения в технологию», «для практикующих инженеров» и «хардкора», в расписании появился варнинг «Готовьтесь, будет подгорать», что, конечно, же, привлекло особое внимание любителей дискуссий и батхертов касаемо спорных моментов в технологии. К слову, «огнеопасным» было всего одно выступление: открывающий конференцию спич Антона Кекса из Codeborne под названием, которое говорит само за себя, «The world needs full-stack craftsmen» (на русском языке, кстати). И, как отмечает программист ITSupportMe Иван Брель, это действительно нужно было слышать, особенно если ты втайне мечтаешь стать настоящим software craftsman и не только писать код, но и решать проблемы. Или хотя бы хочешь разобраться, что это за принцип и почему он работает. Кроме того, отдельно Иван выделил таких спикеров, как Олег Докука (Netifi) — «Протокол RSocket — будущее реактивных приложений», Кирилл Толкачёв (ЦИАН) и Евгений Борисов (Naya Technologies) — «Reactive или не reactive, вот в чем вопрос». Первый поведал всем собравшимся про RSocket и подробно объяснил, почему это новаторское решение для межсервисных взаимодействий, а также показал, как создать современный мультиплеерный Pac-Man или улучшить gRPC с помощью упомянутой технологии. Вторые ребята представили доклад, где на примере системы, в которой есть проблемы, попробовали ответить на вопрос: как внедрить React и избежать сломанных пальцев и разбитых молотком вещей? Конечно же, на протяжении двух дней с четырех сцен прозвучало и много других годных выступлений. В целом конференцию можно назвать практико-ориентированной: 21 доклад был посвящен тем или иным проблемам, с которыми может столкнуться опытный инженер в своей работе. Немало было и вводных лекций — 14, но кто считает :) Хардкор, как водится, лучше всего воспринимается дозированно. Этого принципа и придерживались организаторы, предложив вниманию аудитории всего 4 доклада на сверхсложные топики, требующие максимального погружения в технологию и даже больше. Чаще всего спикеров волновали такие темы, как реактивное программирование; производительность; Spring-приложения; уже ставший традиционным для подобного рода конференций Kotlin (расположившийся в разных весовых категориях — были доклады как для начинающих, так и практикующих и гиперопытных специалистов); Kafka как платформа потоковой обработки данных; работа с байткодом и др. Помимо насыщенной программы лекций и воркшопов, ребята из ITSupportMe во всю оторвались между выступлениями спикеров, поучаствовав во многочисленных конкурсах от спонсоров конференции. Впрочем, слово нашему «охотнику за трофеями» Евгению Лукашкину: «Отличная поездка. Было много чего почерпнуть для себя, для общего развития и что-то на будущее. А еще было много фана. Как и в прошлом году, на каждом стенде от спонсоров можно было взять задачки, за решение которых были памятные призы: майки, чашки, блокноты, etc. Из необычного, Red Hat дал майку за историю жизненного пути. Они были немного в стороне, мы подошли, спросили «есть че порешать?», нам ответили, что нет, но можно рассказать свою историю и получить подарок. Ну, наверное, наши байки были норм)»

ITSupportMe

12 апреля, 2019

post image

О компании

Разработка

Про хлеб с маслом, хороший код и истоки ITSupportMe: наш PHP отдел

В начале был PHP и PHP был ITSupportMe… Шутки шутками, но именно этот отдел — старейший в компании, а еще один из самых многочисленных, организованных и самобытных. За годы совместной работы эти ребята накопили столько совместных идей, историй и инсайтов, что мы просто не можем скрывать их больше от вас. Итак, встречайте, наши PHP-шники! А помогут нам разобраться, что к чему, наши крутые собеседники старожилы ITSupportMe, профи своего дела и просто интересные люди — Константин Литвинов, Евгений Шмыговский и Виктор Штанзе. И как это часто бывает с профессионалами, первый вопрос приводит нас к… О PHP замолвите слово Многим известно выражение, что PHP — один из немногих языков программирования, владея которым, можно заработать себе на хлеб, $ало и воду. Согласны? Константин Литвинов: Ну, да. Иногда даже на масло с икрой :) А вообще это простой язык. Есть две крылатых фразы (кто знает, поймет): во-первых, что это язык домохозяек, а во-вторых, очень часто говорят «так исторически сложилось», в других языках я не встречал такого выражения. Сам PHP уже не молодой и берет свое начало со времен, когда сайты делались статическими на html. Он и был задуман для того, чтобы простой человек мог себе сделать динамический сайт. То есть когда ты регистрируешься, и после тебе прилетает «Здравствуйте, Константин» — и все твои данные динамически подгружаются. Сейчас это все в порядке вещей, а тогда это был настоящий прорыв. Плюс PHP не компилируемый, а интерпретируемый, что проще. Можно заниматься отладкой во время девелопмента. Вносишь какие-то изменения в коде, выполняется запуск скрипта — и  эти нововведения сразу принимаются, не нужно ждать, когда у тебя тесты пройдут, приложение соберется, как с Java языком, например, или Delphi, С и т. д. Он прост в понимании, прост во вхождении, многие студенты осваивают PHP одним из первых. Виктор Штанзе: Да, я хорошо помню, как примерно в 2005 году началась активная волна с фрилансом. И тогда одна моя одногруппница неплохо зарабатывала для студента: днем универ, а вечерочком у нее под бутылочку пива хорошо заходили эти самые фриланс проекты на PHP. Притом человек проучился всего два курса, получил, считай, азы программирования, а PHP она в тот момент уже освоила и лабала на нем очень так конкретно. В общем, тут главное, чтобы была какая-то логика, представление желательно об ООП — и в освоении этого языка у тебя никаких проблем не будет. В интернете можно найти много критики PHP, вернее, не столько самого языка, сколько некоторых людей, которые на нём пишут. Что посоветуете PHP разработчику, чтобы тот был достойным представителем своего рода? Константин Литвинов: В простоте этого языка есть свои подводные камни, конечно. Можно накосячить много в чем. Я помню свои этапы эволюции: сначала начинаешь развиваться, используя какие-то CMS-ки, после этого переходишь на фреймворк, и когда ты уже понимаешь первый, второй, третий фреймворк, начинаешь на нем писать, работать и зарабатывать деньги, то уже не хочется возвращаться на CMS, но иногда поностальгировать можно. Тут каждый сам себе выбирает. А насчет  плохого кода... когда ты что-то пишешь, и потом через полгода-год возвращаешься к тому, что сделал, читаешь — и если тебя все устраивает в том, что ты когда-то написал, значит, ты не растешь. А если ты видишь, что это г...окод, значит, ты вырос. То есть плохой код неизбежен. Главное — идти дальше. Виктор Штанзе: Фишка в том, что если ты знаешь только PHP, то, считай, ты только на хлеб себе и заработаешь. Потому что в данный момент на чистом PHP ничего толкового не сделать. То есть тебе обязательно нужно знать какие-то фреймворки, понимать какие-то свои нюансы, которыми обладает каждый из них, тебе нужно будет учить какие-то дополнительные технологии: twig и т.п. Знание всего этого позволяет тебе котироваться как специалисту и быть востребованным. Ну, а если ты знаешь только PHP — сорян, чувак, этого уже мало, это уровень школьника. Та же банальная работа с базой требует от тебя знаний не только PHP, но и знаний SQL того же самого. Да, ты сможешь сделать простую выборочку, но когда начинаются какие-то большие сложные выборки, огромная база, в которых нужно понимать, как по индексам набирать и все остальное — для этого нужно углубляться в предметную область, поэтому одной только пыхой не отделаешься. Евгений Шмыговский: PHP — это один из инструментов веб-разработки. А дополнительных технологий, инструментов, фреймворков сотни, плюс постоянно появляются новые, веб динамично изменяется. Одного знания PHP недостаточно. Чем больше ты знаешь о всевозможных технологиях, сопряженных с веб-разработкой, тем более ценный ты специалист. Виктор Штанзе: Классно переходить на PHP с языков, где присутствует строгая типизация. Тогда ты понимаешь, с чем ты работаешь, ты привыкаешь к тому, что у тебя одна переменная должна быть строкой, вторая — числом и т.п. — и ты работаешь в этом контексте, иначе у тебя компилятор сразу ругнется. PHP этого не делает. В нем есть приведение типов просто так называемое, оно не такое, конечно, дурное как в JavaScript. PHP более мягкий, более лояльный язык, поэтому он закрывает глаза на некоторые ошибки. Евгений Шмыговский: Хотя сейчас PHP идет в сторону строгой типизации, что есть в других языках. Потому что, когда много людей вовлечено в процесс разработки, читают код, важно, чтобы все они четко понимали друг друга и не оставалось недосказанности. Виктор Штанзе: Я думаю, что Zend ведут PHP к тому, чтобы превратить его из какого-то серверного языка, который на начальных уровнях был довольно-таки простым, в полноценный язык, который умел бы почти все, как та же самая Сишка. Это было бы очень классно. Если бы PHP мог самостоятельно орудовать памятью и знал бы, как это все дело делать — вообще было бы шикарно, как мне кажется. Ты представляешь, что такое пыха, которая следит за тем, сколько памяти она жрет? Пыха, у которой есть гарбич коллектор и которая после выполнения зачищает после себя все следы и высвобождает память и все такое. Ну, это из серии «если бы…». Админы бы просто пищали от удовольствия, сколько сразу оперативки высвобождается. Короче, будет классно, если PHP станет еще круче, чем Сишка. Евгений Шмыговский: Ну, опять же, PHP однопоточный, то есть он не может сохранить свое состояние. Запустился — выполнился — очистился — закрылся. Каждый раз заново. В Java, скорее всего, по-другому: там приложение, которое постоянно работает и, соответственно, со временем может забивать память. Но это уже совсем другая история. С чего начинается ITSupportMe Это правда, что PHP — одно из старейших направлений в компании? Константин Литвинов: Да, с отдела PHP все началось. А вот когда все началось — уже никто, наверное, и не вспомнит. Андрей (обращаясь к Андрею Куликову), ты каким пришел? Третьим, четвертым? Семь лет белорусскому офису, в общем, ну, и нашему отделу, получается, тоже. Каким образом вы координируете такое большое количество людей? Константин Литвинов: Ну, смотри, с год назад мы нанимали специалиста, коуча по скраму. И вообще Леша (предыдущий тимлид) пришел с идеей сделать Nexus Scrum — это такой фреймворк, надстройка над стандартным скрамом. Когда у тебя много команд, то нужно их как-то правильно координировать. Но там идея не задалась по началу. В результате я уже перенял эту мысль, почитал, мне понравилось, в итоге мы уже месяцев восемь как это все построили — связи между командами, специфику взаимодействия внутри и т.д. — все это придумано до нас, мы велосипеда не изобретали. Просто взяли, чуть-чуть подредактировали — и используем. Ведь скрам не диктует какие-то моменты, которым нужно следовать от и до, а предоставляет, скажем так, скелет, на основании которого ты работаешь. Из таких вещей, которые мы с Женей Шмыговским адаптировали и что-то свое привнесли: мы немного изменили ITSM по работе, перепилили scrum dashboard, buildlog, и вот уже закончили prioritization — теперь тоже можно команды объединять на какие-то определенные проекты, и соответственно, на основании капасити этих команд и проектов можно уже приоритезировать задачи внутри. Виктор Штанзе: Например, основные средства координации в нашей команде Charlie — стендапы, синки. Стендап — это процедура, пришедшая к нам из скрама, когда человек в течение пары минут отвечает на три вопроса: что я делал вчера, что я буду делать сегодня и есть ли у меня проблемы. Да, мы, как сектанты, становимся в кружок и каждый день в одно и то же время выполняем этот ритуал. В 10.45. Этот стендап хорош тем, что проговаривая всю схему действий, ты настраиваешься на работу. Ну, и это небольшое средство контроля, конечно. Синк (sync — от англ. synchronize) — продукт собственного производства, такой сидячий стендапчик. Ты говоришь, чем ты занимаешься и какие у тебя планы до конца дня. Мы проводим его в середине рабочего процесса. Например, в начале дня у тебя были планы, а в середине ты рапортуешь: все ли у тебя хорошо идет, может, тебе надо обсудить что-то, попросить совета или помощи. Если ты завис на каком-то таске, бился над ним полдня и мозг был слишком загружен, чтобы оторваться и сказать: «Ребята, есть трабла», то синк — это лишний повод, чтобы это сделать. Он уже никак не относится к аджайл или скраму, это уже чисто наша хотелка, которая вышла из наших ретроспектив. Так мы работаем эффективнее. Синк идет в более произвольной форме, зачастую содержит какие-то технические детали. Когда ты засинкиваешь все в конце спринта, существует большой риск не успеть справиться с глобальной задачей. Поэтому есть смысл синхронизироваться каждый день, чтобы держать руку на пульсе — и не придется мчаться потом навстречу локомотиву, поджав ягодицы, с  криком: «Я успею закрыть этот спринт!» Зачем тянуть до последнего, если мы можем синхронизироваться в том, что мы сделали для спринта, например, сегодня, каждый день — и таким образом процесс разработки становится еще более прозрачным, все проблемы поднимаются раньше и решаются быстрее. И, конечно, это помогает немного отвлечься на пару минут, если ты, например, был загружен. Об организации и самоорганизации  Когда начинается и заканчивается рабочий день у отдела? Есть ли какие-то нюансы в распорядке? Константин Литвинов: Распорядок как у всех в компании. Есть, конечно, такое понятие, как свободный график, но у меня немножко другой подход к нему. Да, я знаю, что некоторые выбирают себе определенные часы пересечения, допустим, все в команде присутствуют с 12 до там 3, а в остальное время как хочу так и хожу, главное — отработать 8 часов. Но я к этому не очень положительно отношусь, хотя да, свободный график есть, но у нас он не совсем свободный, а просто смещен. Народ оформляет дополнительное соглашение, и допустим, если я хочу приходить в 8 часов и работать до 5–6 вечера — ок, но только ты постоянно ходишь по этому графику. Ты можешь даже для каждого дня недели прописать определенный график, допустим, в понедельник с 10, во вторник с 11, в среду там с 9 и так далее. Это тоже нормально, просто, ориентируясь на этот график, я всегда знаю, когда человек на работе. Ну а в остальном все ходят с 10.30. Я лично никогда себе не беру отдельный график, хотя у меня двое детей, прихожу как все и ухожу как все. Иногда ребята задерживаются на работе, но я этого не приветствую. Как говорила одна из моих руководительниц на одной из моих прошлых работ, если ты не справился с поставленной задачей за рабочий день, то ты плохой работник. Надо все успевать. Евгений Шмыговский: У нас аналогичная ситуация. Все, в принципе, приходят и уходят в одно время. Есть один человек, у которого тренировки, и он в какие-то дни приходит и уходит немного пораньше, но это частный, не особо выделяющийся случай. На выходных отдыхаем? Константин Литвинов: Работаем. Над собой. Программисты не отдыхают. Ну, как, отдыхают и не отдыхают одновременно. Есть и тимбилдинги, есть и просто отдых с семьей, есть и посидеть чуток покодить для себя. Какие в отделе традиции? Евгений Шмыговский: Раньше была хорошая традиция — гусей писать (наказывать сотрудника, забывшего залочить компьютер, смешной записью в общем чате от его имени, например, «Я люблю гусей»). Константин Литвинов: Да тут от команды зависит. У нас, по сути, один отдел Bravo, состоящий из 4 команд, плюс Charlie Жени — и в каждой команде свои разработчики, тестировщики и бизнес аналитики со своими тимбилдингами и другими интересными событиями. Виктор Штанзе: Charlie, например, не матерится. А все почему? Потому что не так давно решили вместе, что будем за каждый мат штрафовать сами себя на 50 копеек. Деньги шли в наш общий фонд. Мы себе тогда такой пуфик купили... Женя очень долго противился и доказывал, что есть еще и литературные слова: «Семерых ощенила сука…» — все цитировал он. В общем, это было тяжело примерно неделю. У всех счетчик долгов в копилочку все тикал и тикал, а потом как-то полегче стало внезапно, а затем и надобность в штрафах пропала за неимением преступных намерений — и мы недавно прекратили этот эксперимент. Евгений Шмыговский: Мы еще штраф за опоздание вводили, опять же не с целью наказать, а с целью дисциплину что ли ввести, точнее самодисциплинироваться. Это не был запрет, все единогласно решили и подписались под этим, несмотря на то, что люди знали, что у них есть проблемы с приходом на работу точно в срок. И вот там мы уже знатно копилку команды пополнили, ведь за каждую минуту опоздания — рубль. (Кстати, именно эта самая копилка во многом и помогла воспитанникам Гомельского приюта получить в подарок от ITSupportMe новенький телевизор https://www.itsupportme.by/news/18) Виктор Штанзе: Все это почерпнуто у американцев. Я как-то прочитал историю мэра Джулиани, узнал о его теории разбитых окон — и вдохновился.

ITSupportMe

29 марта, 2019

post image

Разработка

HolyJS 2018 в Москве

24–25 ноября 2018 года в Москве прошла очень крутая конференция JavaScript-разработчиков HolyJS, на которой побывали наши ребята Владимир Марков, Евгений Лукашкин и Александр Степовиков. Более 600 JS-специалистов собрались под крышей конгресс-парк гостиницы «Рэдиссон Ройал Москва», чтобы послушать около трех десятков докладов о фронтенде и не только, обсудить новости постоянно развивающейся экосистемы, актуальные инструменты, фреймворки, паттерны, etc. с ведущими  экспертами в данной области. Не остались без внимания и бэкенд и десктоп. По причине своей многочисленности все доклады на конференции были разделены на три параллельных потока. Среди направлений — введение в технологию; для практикующих инженеров; хардкор. Настоящим гвоздем программы в первый день должно было стать выступление Научно-Технического Рэпа — единственной группы в России, играющей нердкор, или интеллектуальный хип-хоп и воспевающей реалии жизни IT-специалистов, биографии знаменитых ученых и популярные теоремы. Под занавес — три параллельных BoF-сессии по актуальных вопросам — State on client side (EN); What about Node.js? (EN); Инструменты разработчика (RU).; Но обо всем по порядку. И чтобы полностью представить себе весь размах мероприятия, узнать побольше об инсайтах, впечатлениях и просветлениях наших ребят, последуем за нашим рассказчиком и непосредственным участником мероприятия Владимиром Марковым: 1 ДЗЭН Конференция проходила в самом центре города, напротив Дома Правительства Российской Федерации. Мы по возможности старались охватить все события, но это было непросто, учитывая наш напряженный график. Для меня это был первый опыт участия в подобном мероприятии. Очень хотелось там побывать, посмотреть, как проходят подобного рода ивенты, послушать умных людей. Не могу сказать, что я лично ехал ради какого-то конкретного спикера, думаю, что у ребят, в принципе, те же ощущения. Была пара целевых докладов, которые мне было интересно послушать. В основном ориентировался на категорию «для практикующих». Было также пару «введений в технологию» и «хардкоров». Прямо с вокзала утром, не заселяясь в гостиницу, мы примчались на конференцию и успели как раз к первому, общему, выступлению в 10.30 Мишеля Вестстрата из Mendix. Доклад был очень занятным, спикер рассматривал много интересных концепций, в частности такую штуку, как MobX — альтернативу для react разработчика. Есть такая библиотека Redux для управления глобальным состоянием приложения. А MobX — альтернатива. Он рассказывал, как она работает под капотом, в чем ее преимущества перед Redux. Конечно, он был максимально тактичным и в лоб не говорил, что вот, мол, моя библиотека лучше. Он говорил, что это новый взгляд на управление состоянием — и это было достаточно интересно. Далее в 12.00 я решил посетить выступление Камиля Мысливца «Revealing framework fundamentals: NestJS behind the curtain». Конечно, доклад был более актуальным для бэкенд разработчиков, а я фронтенд. Но учитывая мои планы впоследствии сместиться в сторону бэкенда, может, даже в сторону full-stack разработчика, это выступление было интересным и для меня. В 14.00 я слушал Стаса  Курилова о глубоком погружении в webpack. Хороший доклад и также интересная для нас как практикующих фронтенд разработчиков тема. Было интересно углубиться в webpack — как средство собирать воедино все зависимости, которые есть в приложении, все модули — и с ними работать. Это неотъемлемая часть работы фронтенд разработчика. Также докладчик приводил в пример свой кейс, с которым он столкнулся, рассказал, как он решал проблемы, показал много технических моментов. 16.00 — время Павла Черторогова и его доклада “Строим GraphQL-сервер” GraphQL — это специальная библиотека, которая помогает взаимодействовать бэкенд и фронтенд разработчикам. То есть стандартный механизм общения на основе Ajax-запросов. В классической схеме это работает так: фронтенд делает запрос бэкенду: «Пришли мне информацию о человеке». У бэкенда прописано, что на такой запрос ему нужно прислать следующую информацию: имя, пол, возраст, место учебы, работы, дата смерти и т.п. Фишка GraphQL в том, что ты не просто отправляешь запрос «Пришли мне информацию о человеке», а моделируешь изначально уже на фронтенде вариант ответа, который ты хочешь получить. И бэкенд учитывает эти особенности. То есть ты пишешь: «Пришли мне информацию о человеке» и указываешь, допустим, что тебя интересует только пол. На такой запрос бэкенд может, в принципе, даже всю информацию прислать, но по факту ты получишь только одно поле «пол». Так легче контролировать данные, с которыми ты работаешь, и это сильно упрощает жизнь. Вот это был интересный опыт. С 14 до 16 был еще один немаловажный момент конференции — обед. Кормили довольно неплохо, сытно и вкусно, а что еще нужно разработчику. На выступление в 17.30 я, к сожалению, не попал по причине заселения в отель. Но успел на обсуждение после доклада, и, судя по услышанному, я немного потерял, ведь именно в дискуссионных зонах зачастую звучит все самое актуальное и интересное. Спикером был Теодор Вориллас, который рассказывал об accessibility. Это был доклад для начинающих. И возможно, если бы я попадал на само выступление, то эта тема не была бы для меня приоритетной. Но на обсуждение я попасть очень хотел по той причине, что я как веб-разработчик вижу, что маловато внимания уделяется именно accessibility. И мне кажется, что в современных веб-приложениях нужно идти в том числе и в эту сторону. Просто это огромный кусок работы, и часто в наших краях считают: нет, давайте сделаем хотя бы для людей, у которых нет проблем с восприятием информации, а потом уже по остаточному принципу будем думать о других. Это такой аутсорсинговый менталитет, когда хочешь сделать, сделать, сделать, выкинуть в продакшн, а потом уже, если будет желание, accessibility и все остальное добавить. В общем, такая опциональная вещь для большинства приложений, если не брать в расчет какие-то мега-приложения — большие, международные, где accessibility уже идет стандартом и выполнена на высоком уровне. Поэтому интересно было послушать. Я не сказал бы, что для себя я вынес какую-то кардинально новую информацию, но было приятно послушать людей со схожим мнением. Там не столько было рассуждение о технологиях, которые помогают достичь accessibility, сколько высказывались тезисные утверждения, что нужно больше уделять этому времени, внимания, не нужно думать, что если это не касается тебя и твоих близких, то это где-то там, в параллельной вселенной существует. Мы должны больше на этом концентрироваться и двигаться, в том числе, и в эту сторону. На этом мой первый, такой напряженный и насыщенный день закончился. Как я ни пытался этому противиться — утомительный переезд, обилие информации и усталость дали о себе знать — и я отправился в отель. 2 ДЗЭН Начало второго дня не обошлось без небольшого происшествия. Я потерял пропуск. Выселяемся из гостиницы, а его нигде нет. Такое со мной очень редко случается. Но на стойке регистрации конференции мне быстро помогли, распечатали новый документ. Второй день был полегче первого. Не было BoF-ов, а вот я, хорошенько выспавшись и отдохнув, как раз бы сходил на них с радостью. В 10.30 я решил послушать Виктора  Грищенко о децентрализованном вебе. Доклад меня, скажем так, удивил. Даже странно, что ему дали категорию «для практикующих инженеров». Это было что-то вроде персонального взгляда в будущее, там даже были какие-то кейсы реальные, но в целом человек представил свое видение альтернативного интернета. В 12.00 я решил копнуть поглубже и посетил выступление Лукаса да Коста «There is a bluebird in my talk that wants to get out», после которого у меня не осталось вопросов, почему докладу поставили «звездочку». Там поднимались многие высокоуровневые вопросы, связанные с высшей математикой: примеры различных функций, выражений, лямбда-исчислений и др. В 14.00 Вячеслав Шебанов рассказал о системах типов «в двух словах». Правда, в двух словах у докладчика явно не получилось. Он говорил об истории систем типов, анализе текущего состояния языков, демонстрировал свой взгляд в будущее системы типов. Лямбда-исчисление Черча. Лямбда-куб. Линейные типы. Хадкор, в общем. В 16.00 я посетил, как мне кажется, самую интересную лекцию — Эрика Расмуссена «Final Form: Form state management via Observers». Докладчик — человек, который написал react-form library. Это библиотека, которую ты подвязываешь к своему приложению. У тебя, допустим, есть очень много полей для ввода данных пользователей, допустим, анкетирование, а лучше личный кабинет пользователя. Многие поля там требуют максимально особого контроля: например, нельзя некоторые графы оставлять пустыми, в другие можно вводить только определенные символы и т. д. И всем этим делом достаточно сложно управлять. Хотя, конечно, можно, но я считаю, что это большое упущение не использовать библиотеку react-form. Можно справляться своими силами, но на фоне этой библиотеки это все выглядит как написание велосипеда. Я для себя сделал пометочки, потому что react-form library существует в нескольких вариациях, и я лично собираюсь ознакомиться с этой библиотекой намного ближе, чем было раньше. Я когда-то про нее слышал, но не придавал значения. Эрик Расмуссен продемонстрировал некоторые кейсы, показал, где это все может быть полезно, и я понял, что это очень круто. У меня до этого уже было пару проектов, где мне не хватало чего-то такого. Подключить эту библиотеку — и очень сильно облегчить себе жизнь. Это круто. Это желание любого разработчика. Да и сам спикер мне очень понравился. В 17.00 спикер Ари Лернер вводил нас в технологию Flutter.io. Для меня она нова. Сегодня набирает популярность концепция написания одного приложения, которое будет работать на мобильных телефонах под разными платформами. Сейчас в большинстве случаев делают так: тебе нужен один разработчик, например, под iOS и один разработчик, скажем, под android. В большинстве случаев все-таки это два разных человека, потому что достаточно большой объем информации нужно знать. Соответственно, траты возрастают пропорционально количеству человек на проекте, и такие проблемы решает наличие таких библиотек, как Flutter.io. Либо популярный на данный момент ее аналог React Native. Не то чтобы аналог, это просто альтернатива, которая появилась раньше, хорошо зарекомендовала себя на рынке, и большинство разработчиков, которые ввязываются в разработку таких кросс-платформенных приложений, как правило, используют React Native. Но  Flutter.io вроде как тоже пытается набирать популярность, но с ним все не так однозначно, поэтому мне было интересно послушать, что скажет докладчик. Если честно я ожидал, что я приду — и человек скажет: «Вот Flutter.io, вот React Native, давайте их сравним». Наверное, это мои проблемы, потому что этого не было даже в программе заявлено. Но я ожидал чего-то подобного, потому что две технологии находятся очень близко и все понимают, что они конкуренты. Но спикер больше рассказывал о Flutter.io, о языке Dart. В итоге меня не особо убедили, и я очень вряд ли буду развиваться в сторону Flutter. Наконец, последний прослушанный мной доклад в 19.00 — «Маленький Data Science для большого фронтенда» от Романа Дворнова. И снова вектор моих ожиданий и содержание доклада немного не совпали. Тут такая тема — Data Science, которая сейчас на подъеме в IT, ее даже выделили в отдельную область. Эти яйцеголовые ребята из гугла, которые сидят днем и ночью и что-то там вычисляют. Мне было так интересно, как это можно встроить во фронтенд. А по факту нам больше показали, где мы можем видеть Data Science во фронтенде. Например, вот, у нас размер нашего финального файла. Приложение — это же постоянно несколько модулей, если это более-менее крупное приложение. Эти несколько модулей потом вебпаком, про который я говорил раньше, сжимаются в один здоровенный файл — и эта штука называется бандл. И получается мы как фронтенд разработчики можем анализировать размер этого финального файла — бандла — и тем самым работать над оптимизацией процессов. И… я ожидал другого. Что-то крутое, что мы может встроить во фронтенд, может даже построить прикольные графики, основываясь на огромных, невероятных массивах данных, подключить дополнительную библиотеку, как-то это проанализировать. А все было немного попроще, приземленно, но все-таки практически применимо. Еще интересный момент — спикер прямо на конференции представил свою библиотеку, над которой он работал много месяцев, и прямо при нас загрузил ее на GitHub. Было очень приятно, что он решил разделить это событие с нами. У него даже руки дрожали. Поразительный момент. Вот адрес этой разработки: В целом конференция для меня была мега продуктивная. Я для себя вынес очень много полезного материала. Глупо ожидать, что человек, будучи ограничен форматом часового выступления, сможет тебе объяснить всю суть какой-нибудь вопроса. Поэтому мы приходили, слушали, записывали — и я приехал из Москвы с таким вот небольшим списочком технологий, на которые мне стоит обратить внимание, потому что я вижу, что это интересно людям, разработчикам, большинство вещей и сейчас уже в тренде, некоторые же тенденции сегодня едва различимы, но складывается ощущение, что за ними хорошее будущее. Еще один наш коллега, посетивший HolyJS, Евгений Лукашкин соглашается, что конференция была супер информативная и, в свою очередь, отмечает также огромное количество интересных задач от спонсоров, решений которых в персональной копилке Евгения немало — около 50. Хитроумные вопросы для участников звучали повсюду: со сцены во время докладов, в дискуссионных зонах и просто в холле, не обязательно на знание технологий или высшей математики, но и на простую логику. За правильное решение были небольшие призы. Примеры простых задач: сколько чисел от 1 до 1000 имеют в себе цифру три; или рыбак купил удочку, длинной в 5 м, его не пустили в автобус, так как туда нельзя предметы длиннее 4 метров, как рыбаку официально пронести удочку в автобус? Но чтобы получить приз, таких задач нужно было решить несколько. А вот трофей Евгения за вопрос «со звёздочкой»: Впечатлил также нашего коллегу и стенд от Иннополиса: «там было все лайтовое, милые девушки, теплые призы и вот такие задачи, без всякого кода». В общем, это была действительно впечатляющая конференция, из которой каждый вынес много полезной информации и целый багаж впечатлений (а Евгений еще и призов). Спасибо организаторам за теплый прием, спикерам за гипер полезные доклады, а ITSM — за возможность посещать подобные мероприятия и развиваться. Хотим еще :) PS: СПОЙЛЕР-ответ на задачки Евгения: 271 и удочку вложить в коробку 4 на 3 по диагонали.

ITSupportMe

30 ноября, 2018

post image

Разработка

ITSupportMe на Symfony Camp 2018

27 Октября 2018 года группа разработчиков ITSupportMe посетила конференцию Symfony Camp 2018 в Киеве, посвященную разработке веб-приложений с использованием PHP Framework Symfony. Своими впечатлениями от поездки и самого ивента делятся Александр Красов и Юрий Солтыс. Александр Красов: Такие мероприятия однозначно важны. Они дают возможность пообщаться с комьюнити, узнать что-то новое для себя, применить эти знания в своих проектах. Конференция была разделена на два потока, и чтобы послушать все доклады нам приходилось делиться на группы. Теперь, конечно, нужно время, чтобы все переварить, изучить некоторые вопросы, чтобы knowledge transfer для коллег был максимально полезным и информативным. Среди наиболее интересных выступлений я бы отметил доклады Юрия Сергеева о том, как писать универсальный код на Symfony для работы с очередями и/или файловой системой, ну, и конечно, Николаса Грекаса (он выступал на двух потоках, но особенно запомнился его рассказ про эффективность работы Symfony на PHP 7 версии). Юрий Солтыс: Да, последний спикер был особенно хорош. Мы работает на Symfony, а он был один из тех, кто внес большой вклад в развитие этой платформы. Его выступление было важно посетить, ведь это практически инсайдерская информация. Правда, когда путешествует большая компания (а на конференцию, напомним, отправилось 7 наших разработчиков), без приключений обойтись просто невозможно, а помощь может прийти не только от друзей, но и совершенно неожиданных людей. Так, например, одного из ребят на вокзал подвезли… сотрудники ГАИ, которые, узнав, что парень спешит на поезд, просто не смогли остаться безучастными. А Виталию Лосеву пришлось быстро метнуться в другой конец города на машине, чтобы помочь коллеге, забывшему свой паспорт дома. В общем, хорошо то, что хорошо кончается. Мы же искренне рады вашему возвращению, ребята, и с нетерпением ждем ваших докладов по актуальным вопросам проектирования и разработки на фреймворке Symfony.

ITSupportMe

30 октября, 2018

post image

Разработка

JFuture-2018: Technologies. Art. ITSupportMe

Осень-2018 выдалась для сотрудников ITSupportMe необычайно богатой на всевозможные ивенты — развлекательные и образовательные. Но только немногим удалось сочетать в себе и то, и другое. Приятное исключение — конференция JFuture, которая прошла 13 октября 2018 года в Минске и куда отправились пять наших специалистов — Вадим Измайлов, Евгений Лукашкин, Михаил Кравченко, Максим Красюк, Василий Писпанен. И мероприятие это их весьма впечатлило. Во-первых, не может не радовать география проведения мероприятия — Беларусь, в адрес которой в последние годы все чаще можно услышать красноречивый эпитет “Силиконовая долина Восточной Европы”. Это, конечно же, связано с огромным техническим потенциалом страны, о чем свидетельствую, помимо прочего, и подобные конференции. Во-вторых, организаторы JFuture решили собрать всех участников в одном из старейших и самых красивых мест Минска — Национальном театре имени Янки Купалы. И не прогадали, ведь самые актуальные вопросы современных технологий и науки прозвучали… с театральных подмостков, что выглядело, как минимум, необычно, как максимум — потрясающе. Кроме того, сразу после последнего лейбла и короткого перерыва с напитками и закусками слушателей пригласили на еще одно угощение — аутентичное шоу в исполнении лучших белорусских актеров. Ну, и наконец, тематика и разнообразие докладов также были на высоте. Для более чем 300 Java разработчиков, инженеров и энтузиастов, использующих Java в работе и других проектах, было организовано 2 трека. Основной поток был сфокусирован на обновлениях Java и популярных фреймворках, когда как второй стрим был посвящен развивающимся технологиям, а также гибким навыкам разработчиков. Среди спикеров — ведущие специалисты из Германии, Франции, США, Дании, России, Украины, Эстонии, Польши, Нидерландов и Беларуси. Порадовали посетителей и три содержательных воркшопа — “Интеграция облачных сервисов с Apache Camel” от Клауса Ибсена, “Глубокое погружение в Apache Spark” от Алексея Зиновьева, “OPENRNDR” от Бойда Ротганса и Габора Керекса. Напоследок на сцену позвали всех спикеров и разыграли среди слушателей… самокат. И хоть нам не повезло с главным призом, домой мы отправились не с пустыми руками, а с массой ярких впечатлений, полезной информации и новых знакомств.

ITSupportMe

17 октября, 2018

post image

Разработка

Наши на JPoint-2018

Пожалуй, самым интересным Java-событием этой весны стала шестая по счету конференция JPoint, прошедшая 6–7 апреля в Центре Международной Торговли в Москве. Мероприятие собрало более 1000 разработчиков, для которых на 4 параллельных треках было представлено 38 докладов по самым передовым аспектам технологии: производительность, concurrency, тестирование, распределенные системы и высокие нагрузки, будущее платформы и др. Компания ITSupportMe просто не могла пропустить такое масштабное мероприятие. Четыре наших представителя отправились на JPoint, чтобы встретиться со знаменитыми программистами из Европы, Канады, России, США, узнать об их уникальном опыте работы с Java, задать вопросы на актуальные темы, проконсультироваться по поводу тех или иных проектов и просто поболтать о жизни. Кроме того, в гомельском офисе компании для всех сотрудников была организована видео трансляция мероприятия в конференц-зале в режиме реального времени. Надо отметить, что эта поездка была для нас чрезвычайно продуктивной. Организаторы, спикеры и слушатели были на высоте, как и всегда! Синьорность русской публики просто зашкаливала, тяга к хардкору была высочайшей, а жажда новых знаний и профессионального общения непреодолимой. Иногда доклад вызывал такую бурю обсуждений, что невольно появлялся вопрос: что важнее для настоящего джависта: обед или холивар? И, как вариант, родилась идея для следующей конференции: подавать горячее прямо в дискуссионных зонах, чтобы не отвлекаться на мирское :) Кстати, последнее также было на высшем уровне. Столы ломились от угощений. На обед не предлагали разве что икру. Хотя, возможно, мы ее просто не нашли. Ужин был более скромным, но душевно-тематическим: пиво, чипсы, кальмары и орешки. Под конец дня Михаил Гельфанд накормил еще и молекулярной «кухней». Его доклад «Большие данные в современной биологии» был немного неожиданным в рамках конференции, но довольно интересным и информативным. Примечательно, что в этом году организаторам JPoint удалось по максимуму реализовать свою идею собрать под одной крышей всех звёзд мира виртуальных машин и рантаймов. Так, открыл конференцию Юрген Холлер, сооснователь Spring Framework, с докладом на английском о наиболее актуальных моментах работы платформы Spring Framework 5.0 для JDK 8 & 9. Ряд хадкорных докладов прозвучало в первый день от Тоби Аджила про внутренности OpenJ9, Дугласа Хокинса – основного разработчика Zing. Для практикующих инженеров было интересно послушать прикладной доклад про модули Рабеи Грансбергер, выступление про back pressure и Akka от непосредственного разработчика Akka в LightBend Кристофера Батея. Много полезного рассказал также коммитер в Vert.x, ApacheMQ, Camel Клаус Ибсен о том, как начать делать облачные приложения. Во второй день эстафету международного сотрудничества продолжили Санхонг Ли (про то, как в Alibaba делают свою JDK), Чарли Грейси (глубокое погружение в технологии Eclipse OpenJ9 GC), Саша Гольдштейн (профилирование приложения в Docker), Дэвид Делабасси (доклад на тематику энтерпрайза) Сандер Мак (Java модули), Маркус Биль (проектирование чистой архитектуры). В целом диапазон англо- и русскоязычных докладов был настолько широк, а поток спикеров настолько интенсивный, что можно было и не надеяться увидеть воочию все выступления. Тут, конечно, приходит на помощь подкаст выступлений, щедро загруженный на сайт мероприятия. В тематическом плане стоит отметить, что спикеры JPoint представили большое количество практических примеров с поля боя: элементы неэффективного кода, типичные ошибки и изъяны – а также познакомили публику с новациями в области Java разработки. Чего только стоят доклады об аппаратной транзакционной памяти в Java от Никиты Коваля, разбор семантики «exactly-once» Apache Kafka Виктора Гамова, мастер-класс по профилированию с точностью до микросекунды Сергея Мельникова и многое другое. Профессионально-прикладным опытом поделились также Антон Ленок (реактивное программирование на Vert.x), Андрей Когунь (как создать простое приложение с применением Active Annotations) и мн. др. Традиционно отличились доклады на грани театрального выступления дуэтов Виктора Гамова и Баруха Садогурского «Боремся с "Russian Hackers"™ с помощью Kafka Streams и Firehose», Евгения Борисова и Кирилла Толкачева «Boot yourself, Spring is coming» и, конечно же, завершающие конференцию костюмированные «Приключения Сеньора Холмса и Джуниора Ватсона в мире разработки ПО» от Баруха Садогурского и Евгения Борисова. А еще под конец конференции нам стало окончательно понятно, что Kotlin — это всерьез и надолго (ведь целых 4 доклада было посвящено этой теме), и чем быстрее на Святой Руси примут факт, что домашнее не всегда плохое, тем лучше. Общая атмосфера, царившая на JPoint, тоже заслуживает особого внимания. Среди официальных партнеров конференции отличился Райффайзен банк со своей фотобудкой, собравшей большую очередь желающих «тестировщиков». Довольно мило смотрелся стенд Хедхантера, Люксофт потчевал посетителей волшебными эликсирами, а конкурсы с призами были буквально на каждом углу. Вечер первого дня завершился вечеринкой с настольными играми. А потом приехал Михаил Скипский, чтобы провести ЧГК. Кстати, команд набралось гораздо больше, чем планировалось. В целом можно сказать, что JPoint-2018 был однозначно самым лучшим из всей шестерки – конференция действительно растет и развивается, привлекая все более именитых спикеров и поднимая только самые актуальные темы в мире Java. Помимо этого, стоит отметить ценность дискуссионных центров, общения в кулуарах, бофах, unconference и распития чая за стойкой. Это то, ради чего приезжаешь. Спасибо организаторам за эту массу впечатлений и нового опыта.

ITSupportMe

12 апреля, 2018

Начните жить жизнью ITSupportMe

Подпишитесь на нашу E-mail-рассылку, чтобы быть в курсе всех интересных событий и новостей нашей компании!

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