Холодным февральским утром случился наш очередной InterLink Tech Talk.
Интересные темы, приправленные отборными шутками, тут же заставили нас проснуться. Мы с головой погрузились в первую презентацию от Ивана, в которой он напомнил нам о базовых вещах, а именно сетевых протоколах, используя простые и запоминающиеся аналогии :).
Еще пару месяцев назад я даже не знал о существовании такого языка программирования как Rust. В рамках работы над новый проектом мне довелось познакомиться с этим прекрасным языком. Данный язык обладает целым рядом преимуществ, которые не оставили меня равнодушным.
В данной статье хотелось бы осветить некоторые моменты работы с языком, а также рассказать о простоте его использования.
Rust приветствовал меня простейшим процессом установки своего rustup toolchain. Rustup дает возможность без труда установить нужную версию Rust, переключение между stable и nightly сборками происходит в одну команду. При выходе обновления достаточно ввести команду rustup update и toolchain сделает за вас всю работу.
В Rust присутствует встроенный менеджер зависимостей Cargo. Для Rust существует множество пользовательских библиотек размещенных на Crates.io. Для того чтобы использовать одну из них, достаточно добавить зависимость в Cargo.toml файл. При следующем запуске или билде проекта Cargo скачает все необходимые файлы, а используя команду cargo doc вы получаете документацию по всем используемым библиотекам.
По умолчанию все переменные в Rust иммутабельные. На первый взгляд иммутабельность может показаться весьма неудобной, однако со временем начинаешь замечать, что довольно редко возникает необходимость делать переменную мутабельной. В итоге используя иммутабельные переменные мы повышаем безопасность своего кода, а также облегчаем поиск мест где изменение значения переменной могло привести к ошибке.
Рассмотрим простой пример: объявим иммутабельную переменную, проинициализировав её каким-то значением,
Первый день осени у нас был отмечен тройным праздником. Вместе с общенациональным днем знаний мы провели наш очередной Tech Talk – в этот раз выездной, а также отметили всех ребят, которые на протяжении года делились своими знаниями с коллегами. Окруженные деревьями и Днепром, интерлинковцы наслаждались природой, дышали свежим воздухом, общались друг с другом и жадно впитывали новую интересную информацию.
Наступили солнечные яркие весенние деньки, и вместе с этим наступил наш очередной InterLink TechTalk! Улыбки, юмор и, конечно же, серьезные технические темы 😉.
Начали мы с темы, которая может одновременно быть новой и в то же время навевать знакомые нотки. Reactive Systems – это не какой-то конкретный фреймворк или язык, это в какой-то мере обобщенное видение построения систем и приложений, в которых прослеживаются достаточно конкретные шаблоны проектирования. А вся суть сводится, как и полагается, к тому, чтобы конечные пользователи были довольны :).
Затем мы окунулись в мир сказочных существ-дефектов, которые с огромным удовольствием заселяют наши системы при любой удобной возможности 😀. Представитель the Ministry of QA classification of “magical defects” выступила с увлекательным отчетом, поведав нам о самых распространённых существах и даже парочке редчайших из них. Все было приправлено советами по отлову подобных безобразий в производственных или академических целях 😉.
Мы поинтересовались у Мирославы о ее впечатлениях и насколько сложно или легко ей было готовить Tech Talk speech
Півроку тому була розповідь про те, що таке serverless та AWS Lambda. А на початку осені, минулого року відгремів потужний InterLink Tech Talk, де також піднімалась тема амазонівських сервісів. І ось, нарешті, продовження. Цього разу мова піде про деякі особливості роботи з AWS Lambda та Serverless Framework. Розглянемо деякі наші помилки, що були допущені при роботі із serverless технологіями. Також буде трішки теорії стосовно того, як відбувається розгортання проекту, побудованого на основі AWS Lambda. Зазирнемо під капот Serverless Framework, так би мовити.
Переходячи до суті, давайте поміркуємо, що життєво необхідно для девелопера, крім кількох кружок кави на день, щоб ефективно працювати над розробкою проекту? Які функції повинна мати технологія для розробки, щоб девелоперу було комфортно з нею працювати? Як мінімум – це можливість запускати проект локально та дебажити його. Здавалося б, банальні та очевидні речі. Але serverless технології вміють здивувати.
Ну вот и отгремел очередной InterLink Tech Talk. Как всегда, спикеры порадовали нас отличными и задорными докладами.
В этот раз с нами снова был гость из нашего львовского офиса – Ярослав, что дает нам основания полагать, что это начинание плавно переходит в традицию. Посмотрим, что будет дальше :). Ну а пока краткое содержание наших тем.
Forget about bitcoin, it’s all about blockchain – YaroslavP
У кого-то осень началась с нового учебного года, у кого-то со смены настроения, кому-то досталось погодное межсезонье в виде, увы, простуды, а у нас осень началась с очередного InterLink Tech Talk! В этот раз изюминкой программы стало наличие аж двух дебютантов! С чем мы их еще раз поздравляем 😉
Одними із найважливіших рішень, що приймаються на початкових етапах життевого циклу будь-якого проекту, є вибір майбутньої архітектури, стеку технологій, засобів тестування тощо. Також складне питання на цьому етапі – це вибір належної інфраструктури. Тобто, як та за допомогою яких інструментів буде побудовано той мікросвіт, у якому буде жити ще ненароджений проект. Проект може бути розгорнутий на власних потужностях, або з використанням хмарних платформ, або взагалі бути побудованим на основі serverless технології. Власне, знаннями в сфері serverless технологій ми і хочемо поділитися у даній статті. А саме про AWS Lambda, що використовується на одному із наших проектів.
Короткая демонстрация использования GitLab CI с целью показать, что настройка CI – это просто.
(5 мин текста, 10 мин демо)
Сегодня уже никого не удивить темой CI. Да и трудоемкая, тонкая, хрупкая настройка какого-нибудь выделенного CI сервера под конкретный проект уже тоже отходит в прошлое, когда “поднять CI” было прям “подвигом” каким-то. Про само понятие Continuous Integration мы говорить сейчас не будем, если кто еще не знаком с этим, то ожидайте отдельной статьи. Давайте лучше бегло пройдемся по одному из вариантов простейшей настройки CI на проекте, ради эффекта “лучше один раз увидеть”, даже если останется куча вопросов :). Ну, и сразу стоит раскрыть главный секрет этой простоты – это замечательный программный комплекс GitLab. Это open source проект, который интегрирует в себя очень много элементов разработки ПО: code repository, issue tracking, task planning, time tracking, project wiki, etc. GitLab поставляется в двух вариантах: CE (Community Edition) и EE (Enterprise Edition). EE вариант содержит закрытые расширения к CE и, соответственно, является платным решением. GitLab можно развернуть у себя в корпоративной среде (on-premise) или можно воспользоваться SaaS решением по аналогии с GitHub. Ладно, хватит про GitLab, ну, или самое уж последнее… он содержит встроенное CI решение! Мы в нашей компании активно используем GitLab и его CI, ибо это сильно упрощает многие моменты в разработке ПО. Установка и настройка GitLab CI – это отдельная тема, давайте вернемся к обещанному примеру…
Отгремел наш очередной InterLink Tech Talk Jul’2017! Захватывающие доклады, концентрация “2 айтишника на квадратный метр”, смех и улыбки, beer&snack, афтепати и даже афтеафтепати 😀 А изюминкой в этот раз стал приезд наших коллег со львовского офиса! Давайте вспомним что и как происходило.
