This presentation is devoted to Scala programming language, its perks and disadvantages, elegant solutions and hidden traps.
This presentation by Dmytro Mantula (Lead Software Engineer, GlobalLogic) was delivered at JEEConf (Kyiv) on May 23, 2015.
Our ride with Snowflake began 4 years ago. We faced the daunting task of building a decentralized data platform that could empower our 50+ engineering and analytical teams with autonomy while complying with international regulations.
Snowflake has quickly become an essential component of our platform, enabling new cross-teams and cross-department data-sharing scenarios that have led to significant time-to-market and cost reductions (up to 2x). Fine-grained RBAC allows us to quickly adapt to rapidly changing local and international compliance regulations.
Nowadays, we are proud to present our distributed data platform based on Snowflake, which adheres to fundamental data-mesh principles.
Kafka is a top-notch industry platform for streaming data processing at scale. No surprise that first-class citizens of the Kafka world are 24/7-running producer/consumer applications (e.g. classical servers, k8s-pods, etc.)
But what about the rapidly rising world of cloud-native Serverless ecosystems?
This talk summarizes the practical experience of Serverless paradigm application for Kafka production/consumption in AWS.
Customers feedback – from data mess to data meshTaras Slipets
Five phases Flixmobilty went through on their journey to decentralized cross-department data analysis and business intelligence on direct customer feedback.
Experiment more, pay less for your AWS ML.pdfTaras Slipets
Review day to day routines of Dara Scientist and/or Data Engineer. Compare resources usage “patterns” and describe possible infrastructure/costs optimization techniques.
This presentation is devoted to Scala programming language, its perks and disadvantages, elegant solutions and hidden traps.
This presentation by Dmytro Mantula (Lead Software Engineer, GlobalLogic) was delivered at JEEConf (Kyiv) on May 23, 2015.
Our ride with Snowflake began 4 years ago. We faced the daunting task of building a decentralized data platform that could empower our 50+ engineering and analytical teams with autonomy while complying with international regulations.
Snowflake has quickly become an essential component of our platform, enabling new cross-teams and cross-department data-sharing scenarios that have led to significant time-to-market and cost reductions (up to 2x). Fine-grained RBAC allows us to quickly adapt to rapidly changing local and international compliance regulations.
Nowadays, we are proud to present our distributed data platform based on Snowflake, which adheres to fundamental data-mesh principles.
Kafka is a top-notch industry platform for streaming data processing at scale. No surprise that first-class citizens of the Kafka world are 24/7-running producer/consumer applications (e.g. classical servers, k8s-pods, etc.)
But what about the rapidly rising world of cloud-native Serverless ecosystems?
This talk summarizes the practical experience of Serverless paradigm application for Kafka production/consumption in AWS.
Customers feedback – from data mess to data meshTaras Slipets
Five phases Flixmobilty went through on their journey to decentralized cross-department data analysis and business intelligence on direct customer feedback.
Experiment more, pay less for your AWS ML.pdfTaras Slipets
Review day to day routines of Dara Scientist and/or Data Engineer. Compare resources usage “patterns” and describe possible infrastructure/costs optimization techniques.
Cloud computing is widely used by industry for more than a decade. There are many patterns, best practices and tools around it including DevOps, despite that, they do not prevent from shouting yourself if misused.
This talk is a summary of practical experience and observations about top-most misuse of DevOps practices when applied to cloud software engineering and operations. AWS Cloud provider is used for cases examples.
Evolution of AWS infrastructure for ML: from Zero to HeroTaras Slipets
Real experience of building and evolution of Machine Learning model using AWS ecosystem – from from scratch to fully-fledged production solution generating 20M predictions per day just in 2 month.
Practical success story for building DevOps culture in Product company within classical development team from scratch: growing t-shaped skills, knowledge sharing practices used, tools to build efficient delivery ecosystem.
https://xpdays.com.ua/programs/devops-applied-survival-guide/
Practical example of simplifying full-stack development and testing routines using containerisation and orchestration techniques.
Sample application: data streaming app with React.js / Apache Kafka / Java SpringBoot / Elasticsearch based on Docker / Kubernetes orchestration.
--
Web Tech Fun 2018 Conference
Chernihiv, Ukraine
This document provides an overview of different classifications for Java developers based on their skills and experience levels. It describes vertical classifications such as Junior, Middle, Senior, Architect, Lead, Manager, and Principal. It also describes horizontal classifications like Core Java Geeks, Optimization Nerds, Legacy Legends, Frameworks Hipsters, and Full-stack Magicians. For each classification, it outlines typical skills and probable career growth paths. The overall message is that a team of developers with diverse skills and classifications is most effective.
The document summarizes a presentation about improving a legacy Java system. It describes receiving a legacy system with no documentation and developers. Effective steps taken included setting up development environments, writing documentation, domain modeling, peer reviewing, testing existing functionality, refactoring using patterns, and extending features where possible. The results were successfully migrating the 11-year old system to use newer technologies and frameworks while maintaining functionality through an iterative process focused on testing, documentation, and continuous integration.
The document describes the experience of improving a legacy system that was 11 years old and written in Java 1.4 without frameworks or documentation. The key steps taken included: setting up testing environments; modeling the domain, workflows and database; conducting peer reviews; adding unit and integration tests; refactoring using patterns like template method and strategy; automating deployment; and adding new features where possible. Lessons learned included not underestimating classical techniques, being agile, and sharing knowledge through documentation. In the end, the improvements resulted in a system with reduced maintenance pain and an automated build pipeline.
What developers can really contribute in DevOps concept?Taras Slipets
This document provides an overview of how developers can contribute to DevOps practices through monitoring applications with Nagios. It discusses using the check_jmx4perl Nagios plugin to monitor Java applications by accessing metrics exposed via JMX, and implementing automatic configuration of monitoring checks using Puppet resources like exec, file, and nagios plugins. The document aims to demonstrate an end-to-end workflow of defining monitoring parameters, exposing them in JMX, adding the Jolokia agent, configuring Nagios checks, deploying the application, and automating monitoring setup with Puppet.
Cloud computing is widely used by industry for more than a decade. There are many patterns, best practices and tools around it including DevOps, despite that, they do not prevent from shouting yourself if misused.
This talk is a summary of practical experience and observations about top-most misuse of DevOps practices when applied to cloud software engineering and operations. AWS Cloud provider is used for cases examples.
Evolution of AWS infrastructure for ML: from Zero to HeroTaras Slipets
Real experience of building and evolution of Machine Learning model using AWS ecosystem – from from scratch to fully-fledged production solution generating 20M predictions per day just in 2 month.
Practical success story for building DevOps culture in Product company within classical development team from scratch: growing t-shaped skills, knowledge sharing practices used, tools to build efficient delivery ecosystem.
https://xpdays.com.ua/programs/devops-applied-survival-guide/
Practical example of simplifying full-stack development and testing routines using containerisation and orchestration techniques.
Sample application: data streaming app with React.js / Apache Kafka / Java SpringBoot / Elasticsearch based on Docker / Kubernetes orchestration.
--
Web Tech Fun 2018 Conference
Chernihiv, Ukraine
This document provides an overview of different classifications for Java developers based on their skills and experience levels. It describes vertical classifications such as Junior, Middle, Senior, Architect, Lead, Manager, and Principal. It also describes horizontal classifications like Core Java Geeks, Optimization Nerds, Legacy Legends, Frameworks Hipsters, and Full-stack Magicians. For each classification, it outlines typical skills and probable career growth paths. The overall message is that a team of developers with diverse skills and classifications is most effective.
The document summarizes a presentation about improving a legacy Java system. It describes receiving a legacy system with no documentation and developers. Effective steps taken included setting up development environments, writing documentation, domain modeling, peer reviewing, testing existing functionality, refactoring using patterns, and extending features where possible. The results were successfully migrating the 11-year old system to use newer technologies and frameworks while maintaining functionality through an iterative process focused on testing, documentation, and continuous integration.
The document describes the experience of improving a legacy system that was 11 years old and written in Java 1.4 without frameworks or documentation. The key steps taken included: setting up testing environments; modeling the domain, workflows and database; conducting peer reviews; adding unit and integration tests; refactoring using patterns like template method and strategy; automating deployment; and adding new features where possible. Lessons learned included not underestimating classical techniques, being agile, and sharing knowledge through documentation. In the end, the improvements resulted in a system with reduced maintenance pain and an automated build pipeline.
What developers can really contribute in DevOps concept?Taras Slipets
This document provides an overview of how developers can contribute to DevOps practices through monitoring applications with Nagios. It discusses using the check_jmx4perl Nagios plugin to monitor Java applications by accessing metrics exposed via JMX, and implementing automatic configuration of monitoring checks using Puppet resources like exec, file, and nagios plugins. The document aims to demonstrate an end-to-end workflow of defining monitoring parameters, exposing them in JMX, adding the Jolokia agent, configuring Nagios checks, deploying the application, and automating monitoring setup with Puppet.
28. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением (реальным
или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
30. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением (реальным
или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
31. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением (реальным
или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
32. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением
(реальным или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
33. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением
(реальным или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
34. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением
(реальным или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
35. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением
(реальным или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
36. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением
(реальным или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
37. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением
(реальным или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
38. Понятие объекта
Объект является конкретным распознаваемым
предметом, сущностью или явлением
(реальным или абстрактным), которое имеет четко
определенное функциональное назначение в
данной проблемной области.
Объекты обладают целостностью, которую не
следует нарушать. Объект может только менять
состояние, поведение, управляться или
становиться в определенное отношение к другим
объектам.
42. Поведение
Характеризует то, как объект воздействует или
подвергается воздействию других объектов с точки
зрения изменения состояния этих объектов и передачи
сообщений.
47. Метод
Операции, выполняемые над данным объектом или
выполняемые данным объектом, называются методами
(методической частью объекта) и входят составной
частью в определение объекта.
48. Основные виды операций
• Модификатор (set-метод)
• Селектор (get-метод)
• Итератор
• Конструктор
• Деструктор
49. Понятие класса
Объект, свойства которого не имеют конкретных значений,
фактически является классом, т.е. класс – это множество
объектов, связанных общностью структуры и поведения.
56. Описание объекта
Математический анализ: Лекция
тема = Понятие многомерного
интеграла. Поверхностный
интеграл
интересность = АГОНЬ
продолжительность= 90 хвилин
Имя объекта
Поля
Абстракция переменных; абстракция регистров и сегментов памяти; прерывания
Абстракция части кода как самостоятельного элемента
Абстракция – это упрощенное описание системы, при котором одни свойства и детали выделяются, а другие опускаются.
Хорошей является такая абстракция, при которой подчеркиваются существенные для рассмотрения и использования детали и опускаются те, которые на данный момент несущественны или отвлекают внимание.
Разумеется, различие между существенными и несущественными характеристиками зависит от решаемой проблемы, т.е. от контекста использования абстракции.
«Абстракция через параметризацию позволяет, используя параметры, представить фактически неограниченный набор различных вычислений одной программой, которая есть абстракция всех этих наборов.»
В абстракции через параметризацию мы абстрагируемся от конкретных используемых данных. Эта абстракция определяется в терминах формальных параметров. Фактически данные связываются с этими параметрами в момент использования такой абстракции. Значения конкретных используемых данных являются несущественными, важно лишь их количество и типы.
Таким образом, всякий раз вызывая подпрограмму с параметрами, мы фактически пользуемся абстракцией через параметризацию.
В абстракции через спецификацию мы фокусируем внимание на особенностях, от которых зависит пользователь, и абстрагируемся от подробностей реализации этих особенностей. Существенным является «поведение» - «то, что делается», а несущественным– то, «как» это делается. Например, в процедуре sort существенным является
факт сортировки массива, а не сам алгоритм сортировки.
Это достигается путем задания для каждой процедуры спецификации, описывающей эффект ее работы, после чего смысл обращения к данной процедуре становится ясным через анализ этой спецификации, а не самого тела процедуры.
Спецификация описывает соглашение между разработчиками и пользователями. Разработчик берется написать модуль, а пользователь соглашается не полагаться на знания о том, как именно этот модуль реализован, т.е. не предполагать ничего такого, что не было бы указано в спецификации. Такое соглашение позволяет разделить анализ реализации от собственно использования программы.
Наиболее известный в программировании тип абстракции - процедурная абстракция. Всякий, кто применял для выполнения функции подпрограмму, которая может быть
использована в других программах, реализовывал тем самым процедурную абстракцию. Процедуры объединяют в себе методы абстракции через параметризацию и спецификацию, позволяя абстрагировать отдельную операцию или событие.
2 свойства:
Локальность
Модифицируемость
Абстракция данных. Какие новые типы данных необходимы, зависит от области применения программы? Синонимом понятия «абстракция данных» является понятие «класс».
Абстракция данных- наиболее важный метод в проектировании программ. … Выбор правильных структур данных играет решающую роль для создания эффективной программы.
Итератор ответственен за получение элемента, а модуль, содержащий цикл, определяет то действие, которое будет над ним выполняться. Итератор может выполняться в различных модулях, которые выполняют разные действия над элементами, и он может быть реализован различными способами, не оказывая влияния на эти модули.
Таким образом, итератор фактически является абстракцией доступа к элементам набора (коллекции).
Преобладающая в настоящее время точка зрения заключается в том, что объекты обладают внутренней структурой и связаны с другими объектами посредством различных отношений. Это хорошо согласуется с нашими непосредственными наблюдениями.
Расчленяя эти объекты на их составные части, мы видим, что казавшиеся единичными объекты имеют сложную структуру, распадающуюся на ряд отношений, существующих между этими более простыми компонентами. Продолжая расчленение, мы, в конце концов, приходим к простейшим объектам, которые уже в данной теории не обладают внутренней структурой и существуют в виде атомарных объектов, связанных отношениями с другими объектами.
Данная модель(концепция) мира получила в программировании название объектно-ориентированного программирования.
К числу свойств объекта относятся присущие ему или приобретаемые характеристики, черты, качества или способности, делающие данный объект самим собой.
Совокупность свойств объекта называется его структурой.
Все свойства объекта характеризуются парой тип-значение. Тип свойства может быть либо встроенным(элементарным) типом, т.е. непосредственно поддерживаться исполняющей средой, либо быть классом.
Таким образом, как правило, объект имеет постоянные характеристики, но может менять свое состояние.
(!) Объекты не существуют изолированно, а подвергаются воздействию или сами воздействуют на другие объекты.
Вы еще ниче не успели рассказать, а за вас все решиили
Это такие свойства объекта, которые имеют уникальное значение, т.е. значение, которое отличает объект от всех других подобных объектов. Например, все люди отличаются
друг от друга рисунком линий на ладони, отпечатками пальцев или сетчаткой глаза.
Слово «операция» предполагает наличие пассивных объектов, т.е. объектов, которые могут изменять свое состояние только под воздействием других объектов, или, другими словами, объектов, над которыми производятся действия. Активный объект в общем случае наоборот– автономен, т.е. он может реализовать свое поведение без воздействия со стороны других объектов, другими словами, он меняется под воздействием внутренних причин. Одну и ту же ситуацию можно описать как в терминах пассивных объектов, так и в терминах активных объектов.
Когда один объект вызывает(активизирует) операцию другого объекта, то об этом еще говорят, что один объект передает сообщение другому объекту.
забить_и_пойти_на_пиво() – к классу на самом деле не относиться
верхнее отделение, содержащее имя объекта и имя класса, разделенные двоеточием; если имя объекта отсутствует, то представлен анонимный объект; имя класса можно опускать в том случае, когда оно очевидно(например, если объект класса Customer имеет имя myCustomer);
в нотации UML объект легко отличить от класса– имя объекта всегда подчеркнуто;
нижнее отделение, содержащее имена свойств и их текущие значения.
Неформально, инкапсуляция (encapsulation) - это механизм, который объединяет данные и методы, манипулирующие этими данными, и защищает и то и другое от внешнего вмешательства или неправильного использования. Когда методы и данные объединяются таким способом, создается объект.
Чтобы пользоваться холодильником, утюгом или, скажем, кондиционером– совсем необязательно знать их внутреннее устройство и принципы работы.
Прежде всего, нас интересует– что делает объект, а не то– как он это делает.
Инкапсуляция реализует принцип сокрытия информации следующим образом:
• отсутствует прямой доступ к свойствам объекта, они доступны только через методы
• объект контролирует доступ к своим данным
• «опубликованный» функциональный интерфейс объекта позволяет другим объектам использовать его поведение
Интерфейсная часть описания класса по способу доступа к ней может быть разделена на четыре составные части:
• Общедоступная или общая (public) – операции, доступные всем остальным классам
• Защищенная (protected) – доступ к таким операциям разрешен только самому классу и его подклассам
• Обособленная или закрытая (private) – операции, недоступные ни одному другому классу
• Пакетная (package) – операции доступны только классам данного пакета.
Наследование– такое отношение между классами, когда один класс повторяет структуру и поведение другого (простое наследование) или других(множественное наследование) классов.
Класс, структура и поведение которого наследуются, называется суперклассом. Производный от суперкласса класс называется его подклассом.
Это означает, что наследование устанавливает между классами иерархическое отношение.
Как правило, подкласс не только наследует структуру и поведение своего суперкласса, но и достраивает или переопределяет их.
Слово полиморфизм- греческого происхождения и означает "имеющий много форм". Полиморфизм- это свойство, которое позволяет одно и тоже имя(действие) использовать для решения нескольких технически разных задач.
Например, «забить мяч» в футболе можно ногой, головой и некоторыми другими частями тела.
Применительно к объектно-ориентированному программированию, целью полиморфизма, является использование одного имени для задания общих для класса действий. На практике это означает способность объектов выбирать внутреннюю процедуру(метод) исходя из типа данных, принятых в сообщении.
Таким образом, полиморфизм позволяет обойтись без операторов выбора, поскольку объекты сами знают свой тип.
Вы еще ниче не успели рассказать, а за вас все решиили