Объектно-Ориентированное Программирование на C++, Лекции 3 и 4 Dima Dzuba
Описываются возможности C++ по работе с наследованием (virtual, override, final). Описываются механизмы работы с константными переменными и методами (const, mutable, constexpr). Описываются возможности по перегрузке операторов (operator).
В презентации рассказывается о структурах памяти в JVM: Heap, Non-Heap, Stack, об атомарности операций и о garbage collector. Рассмотрен пример, как работает стек. Также, приведены примеры, как использовать jVisualVM и что она может показать.
Быстрые конструкции в Python - Олег Шидловский, Python Meetup 26.09.2014Python Meetup
В своем докладе Олег расскажет о замене стандартных функций на более быстрые и об ускорении работы python. Также продемонстрирует несколько примеров быстрых конструкций python.
Лекция 12. Быстрее, Python, ещё быстрее.Roman Brovko
Измерение времени работы кода на Python с помощью модулей timeit, cProfile и line_profiler. Немного о NumPy. JIT и AOT компиляция кода на Python на примере Numba и Cython.
Синтаксис объявления классов. Атрибуты, связанные и несвязанные методы, __dict__, __slots__. Статические методы и методы класса. Свойства, декоратор @property. Наследование, перегрузка методов и функция super. Декораторы классов. Магические методы.
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
В презентации рассказывается о структурах памяти в JVM: Heap, Non-Heap, Stack, об атомарности операций и о garbage collector. Рассмотрен пример, как работает стек. Также, приведены примеры, как использовать jVisualVM и что она может показать.
Быстрые конструкции в Python - Олег Шидловский, Python Meetup 26.09.2014Python Meetup
В своем докладе Олег расскажет о замене стандартных функций на более быстрые и об ускорении работы python. Также продемонстрирует несколько примеров быстрых конструкций python.
Лекция 12. Быстрее, Python, ещё быстрее.Roman Brovko
Измерение времени работы кода на Python с помощью модулей timeit, cProfile и line_profiler. Немного о NumPy. JIT и AOT компиляция кода на Python на примере Numba и Cython.
Синтаксис объявления классов. Атрибуты, связанные и несвязанные методы, __dict__, __slots__. Статические методы и методы класса. Свойства, декоратор @property. Наследование, перегрузка методов и функция super. Декораторы классов. Магические методы.
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
31 мая – 1 июня в Киеве состоялась конференция HOTCODE 2013.
Сергей Тепляков, эксперт Luxoft Training по .Net, С++ и архитектуре приложений, выступил с докладом «C# Deep Dive».
Тезисы доклада:
«Когда-то в далеком 2002-м году язык C# был прост, как 2 копейки. Но у любого «живого» языка есть одна особенность, приятная и неприятная одновременно — в язык начинают добавляться новые возможности, чтобы наши с вами типовые задачи решались проще и эффективнее. Но с каждой новой возможностью появляются и свои тонкости, незнание которых может лишить столь нужных в нашей жизни конечностей, причем иногда самым изощренным образом. А поскольку язык C# развивается очень динамично, то за время жизни на его просторах появилось много маленьких грабелек, которые мы с вами и научимся обходить ;)».
noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов НиколайOntico
Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.
Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).
Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.
Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.
Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док
Руслан Гроховецкий "Как Python стал делать погоду в Яндексе"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Руслан Гроховецкий "Как Python стал делать погоду в Яндексе"
О докладе:
Про Python и Django: зачем нужна красота и простота перфекционистам с дедлайнами, на примере Яндекс.Погоды.
Когда число сервисов, которые делаются в Яндексе, стало возрастать, дедлайны — поджимать, а от процесса разработки требовалось стать более гибким, возникла потребность в свежих решениях. В докладе на примере Яндекс.Погоды рассказывается, как в Яндексе делают сервисы с помощью языка Python и веб-фреймворка Django.
'How i came up with my talk' by Yurii Artiukh. OdessaJS'2021OdessaJS Conf
The document describes the process by which someone decided on a topic for their presentation. They initially considered topics like animations or differential equations. After seeing an animation example, they wanted to create one themselves from 0 to 1, but struggled for over a day to get the math right. They eventually landed on an exponential function that achieved the desired animation effect over time. They questioned why they went through so much effort to figure this out.
Олексій Павленко. CONTRACT PROTECTION ON THE FRONTEND SIDE: HOW TO ORGANIZE R...OdessaJS Conf
The document discusses various approaches for performing contract protection on the frontend side such as integration testing, law-driven contract testing, consumer-driven contract testing, and runtime checking. It then focuses on runtime checking, explaining what it is and how it can add an extra step to quality assurance by allowing integration errors to be responded to in real time. Details are provided on Oleksii Pavlenko who is an engineering manager, PhD holder, and former professional basketball player with interests in surfing, snowboarding, and other boardsports.
Андрій Троян. Розробка мікросервісів з NestJS. OdessaJS'2021OdessaJS Conf
This document discusses NestJS, a framework for building Node.js microservices. It introduces microservices and their key characteristics like loose coupling and independent deployment. It then covers how NestJS provides an architecture that allows for highly testable, scalable, and maintainable applications. Specific NestJS features are summarized like modules, controllers, providers, pipes, error handling, and decorators. Finally, it discusses using NestJS for microservices, including different transporters and message styles like request-response and event-based communication.
Олексій Гончар "Використання Electron в розробці корпоративної відео-мессeндж...OdessaJS Conf
This document provides an overview of Electron and its history and principles. It then summarizes the RingCentral MVP platform, including its features and transition to using Electron. Finally, it describes the RingCentral desktop app, its features and technology, and its CI/CD processes. The document contains sections on Electron, the RingCentral MVP platform, and the RingCentral desktop app.
Максим Климишин "Що такого особливого у пропозиції вартості шаблону Micro Fro...OdessaJS Conf
Micro frontends is a design pattern that splits an application into multiple independently deployable frontend applications to reduce dependencies between teams and improve the speed of delivery. This approach can reduce execution and delivery risks like long cycle times and inconsistent user experiences. It allows for more autonomous teams and faster time to market. However, it also introduces some risks around broken user interfaces if components are not built consistently. Adopting a micro frontends approach requires buy-in from engineering leadership as well as change management to shift teams away from old habits.
Павло Галушко. GOOD CODE MYTHS. OdessaJS'2021OdessaJS Conf
The document discusses myths about writing good JavaScript code. Some myths addressed include: that good code is only for aesthetics; that programming is only about writing code; and that principles and patterns from object-oriented programming do not apply to JavaScript. The presentation argues that good code is important for business reasons like maintenance and refactoring costs. It emphasizes writing testable code, following style guides, and applying design principles universally.
'BUILDING ANGULAR APPS WITH NX' by Anastasia NecheporenkoOdessaJS Conf
This document discusses approaches to managing Angular applications, including using multiple repositories versus a monorepository. It notes advantages and disadvantages of each, such as isolation but also hard dependencies with multiple repos, versus easy code sharing but potential messiness with a monorepo. The document then introduces Nrwl Nx as an open-source tool that helps manage monorepos for Angular apps, providing features like dependency graphs, smart rebuilds, and code generators. However, it cautions that using Nx requires following its structure patterns and configurations, and migrating codebases and teams to its approach can also require effort.
'IS THERE JAVASCRIPT ON SWAGGER PLUGINS?' by Dmytro GusevOdessaJS Conf
This document discusses JavaScript plugins for the Swagger API documentation framework. It begins with an overview of Swagger and related tools like swagger-editor. It then covers challenges with customizing Swagger and different approaches tried, like using custom Swagger definitions or closures. The main topics covered are the plugin system architecture, including available React components, Redux state management, and plugin APIs. It asks several questions about how to interact with and extend the plugin system.
'ETHEREUM SMART CONTRACTS ON JS' by Yaroslav DvorovenkoOdessaJS Conf
This document discusses Ethereum, smart contracts, and blockchain technology. It defines Ethereum as a cryptocurrency platform that allows for decentralized services and applications through the use of smart contracts written in the Solidity programming language. Smart contracts are computer programs that automatically execute transactions, actions, and legally relevant events without the need for intermediaries. The document provides examples of how smart contracts could be used for elections, digital currency, and instant money transfers with low fees. It also discusses tools like Ganache, Truffle, and Web3.js that allow for developing, testing, and interacting with smart contracts and decentralized applications.
'MICROFRONTENDS WITH REACT' by Liliia KarpenkoOdessaJS Conf
This document discusses microfrontends architecture. It begins by explaining why an organization may want to use a microfrontends approach, such as when different teams in different locations need to work on the same project simultaneously. It then discusses some of the downsides of a monorepo approach and when a monorepo may be preferable to microfrontends. The document outlines some of the challenges microfrontends can present and why they can also be a good choice. It provides examples of how to divide an app into microfrontends, such as by routes, features, or a combination, and options for using different frameworks within microfrontends like web components, module federation, and iframes. It concludes by discussing testing and development
'Web performance metrics' BY ROMAN SAVITSKYI at OdessaJS'2020OdessaJS Conf
Let's brainstorm web-productivity? It's easy to get lost in different sources - so how to choose them wisely? Main topics: Metrics, best practices, problems and solutions
Вебпродуктивність. Що ще тут розповісти? Всі ми знаємо, що це важливо, як не отримувати таких проблем і до чого це призводить. Але якщо необхідно вирішити проблему серед тонни ресурсів важко обрати потрібний. Моя доповідь не тільки про рішення проблеми, а про находження інструментів та метрик для рішення проблеми. Чому саме ці метрики варто використовувати і як з цим жити. Метрики, практики, проблеми, рішення. Які різні поняття, а насправді це цепочки, які нам разом необхідно виставити в логічний ряд. Запрошую Вас побрейнштормити разом!
'JavaScript was invented in Odessa' by DMITRIY GUSEV at OdessaJS'2020OdessaJS Conf
JavaScript is wild and dangerous. I’ve been using it for years and time to time faced with the same issues.
Also being an interviewer I talked to lots of people.
And most of them able to answer the questions correctly, but can not explain why it works so. In my talk, I prepared examples of ‘what is wrong with JS’ and explained why it works so based on ECMA specifications.
'Why svelte' by BORYS MOHYLA at OdessaJS'2020OdessaJS Conf
I'll tell you why I chose Svelte. What I like about Svelte and what not. Let's talk about when to use Svelte in production and why.
The technology shows new possibilities of the composition of high-level abstractions and high-performance low-level code.
'Effective node.js development' by Viktor Turskyi at OdessaJS'2020OdessaJS Conf
How to develop NodeJS apps effectively? I will tell you all details and share his personal experience on the whole process: from the very start and up to the production stage.
You will also learn more about Docker, SDLC and 12 Factor App. Save the date!
9. JavaScript – это интерпретируемый язык:
исходный код (текст программы) является и исполнимым кодом.
Это позволяет легко переносить программы на различные устройства:
ПК, планшеты, смартфоны, телевизоры.
Мне показалось или там было «телевизоры»?
Нет, не показалось, есть такой инструмент Samsung SDK специально для
Samsung SmartTV
Кросс-платформенный
10. JavaScript — это самый быстрый из интерпретируемых языков:
PHP, Ruby, Python и др.
Интерпретатор для JS разрабатывался в конкурентной борьбе – «войне
браузеров», тогда как другие языки – плоды спокойной работы
отдельных групп разработчиков.
Еще скажите, что JavaScript быстрее С++…
По некоторым тестам – да. Мощь JavaScript «съедается» браузером.
А вот без него, например в NodeJS, сомнения отпадают
Быстрый
11. Концепция Full Stack JavaScript
• browser (JavaScript)
• server (Node.js)
• database (MongoDB)
JavaScript является одним из наиболее востребованных языков на
рынке вакансий IT.
По данным рынка Европы JavaScript уверенно занимает первое место.
Популярный
13. Я знаю С/С++, С#, сам изучил Pascal
Что мне стоит разобраться с JS!?
14. В браузерах основное предназначение JS — манипуляции с DOM.
10 перестроек 1 перестройка
Именно DOM не дает JavaScript проявить свою скорость…
Особенность 1. DOM
Вариант 1 Вариант 2
for( i=0; i<10; ++i )
label.innerHTML += i
str = ""
for(i=0; i<10; ++i) str += i
label.innerHTML = str
15. Переменные не нужно объявлять. Переменная создается
автоматически при первом обращении на запись. Это же касается и
полей в классах
Тип указывать не нужно – он будет автоматически определен
О чудесах динамической типизации Вы уже, наверняка, слышали
Особенность 2. Динамическая типизация
С / С++ / С# Pascal / Delphi JavaScript
int x;
x = 10;
var x:integer;
begin
x := 10;
x=10
или
var x=10
16. // установит красный фон для «element»
element.style.backgroundColor="red"
// создаст новое поле «BackgroundColor», ошибки нет
element.style.BackgroundColor="red"
// а эту «ошибку» я исправлял у каждого второго…
$.ajax({ url: "site.html",
sucsess: function(){...} })
Удобно, но…
17. JavaScript получает все данные от пользователя или из НТТР-пакета в
символьном (строковом) виде, даже если для этого применяются
элементы числового типа.
Z = X + Y // Z = 311
W = X – Y // W = -8
X.value > Y.value // true
Особенность 3. HTML, HTTP: Т – значит текстовый
18. С/С++ есть разница: объект - obj.field ссылка - ref->field
В JavaScript создание объектов – это создание ссылок на объекты. Хотя
для доступа применяется оператор «.» (точка)
a = { x:10, y:20 } // а – ссылка на объект { x:10, y:20 }
b = a // b – ссылка на тот же объект, что хранится в а
// казалось бы, меняем значение «b»
b.x = 30 // но…
console.log(a) // а={x: 30, y: 20}
Особенность 4. Ссылочные типы
19. ООП в JavaScript на более высоком уровне, чем у С/С++ или Pascal.
var f = function(){ alert( "f" ) }
f() // сообщение "f"
f.x = 10 // поле x объекта f
f() // работает как и раньше
f = 20 // новое значение f
f() // ошибка: f – не функция
Особенность 5. Функции – это объекты
20. Параметрический полиморфизм в JavaScript отсутствует.
А попроще? Функции не перегружаются
А по-человечески? Функции с разными параметрами – это одна и та же функция
function f(){ … } // определяем f
function f(x){ … } // переопределяем f
// в такой форме понятнее, почему f переопределяется
f = function(){ … }
f = function(x){ … }
И из-за того, что функции – это объекты…
21. Как думаете, какое сообщение выведет последняя строка кода?
f = [] // конструктор массива
for( i=0; i<3; ++i ) // заполнение массива функций
f[i] = function(){ alert(i) }
f[1]() // вызов функции из массива (с индексом 1)
Функция хранится как текст. Обращение к «i» произойдет в момент
вызова, так что i=3. Интерпретация – не компиляция…
И еще о функциях – позднее связывание
22. А вот тут начинается самое интересное…
Традиции взяли верх – указатель «this» показывает на тот объект,
которому принадлежит функция
a = {
name: "object a",
thisLogger: function(){ console.log( this ) }
}
a.thisLogger() // {name: "object a", thisLogger: ƒ}
Функция – объект. Значит «this» указывает на нее?
23. Если функция хранится как текст, то действует ли на «this» позднее
связывание? – Еще и как действует!
<div id="div1" ></div>
<script>
div1.onclick = a.thisLogger // а – описан слайдом выше
</script>
Что мы увидим в консоли, когда кликнем по блоку?
Правильно,
ведь функция будет вызвана из блока "div1"
А если добавить позднее связывание…
24. Функции, как объекты, могут иметь свои поля. Для того чтобы к ним
обратиться нужно…
Именовать анонимные функции – все просто!
f = function self( ) { // named function expression
alert( self.x ) // обращение к «своему» полю х
}
f.x = 10 // поле х объекта f
f() // сообщение – 10
Если «this» это не this, то как добраться до this?
25. Вариант 1 Вариант 2 Вариант 3
<form onsubmit="handler()">
<input type="submit" value="Go" />
</form>
<script>
function handler(){ return false; }
</script>
<form id="form1">
<input type="submit" value="Go" />
</form>
<script>
form1.addEventListener("submit",
function() { return false; } )
</script>
<form id="form1">
<input type="submit" value="Go" />
</form>
<script>
form1.onsubmit =
function() { return false; }
</script>
Необходимо
onsubmit="return handler()"
Необходимо
function(e){ e.preventDefault(); …
Без дополнений,
все работает
Простая задача - предотвратить отправку HTML-формы
Особенность 6. Обработчики событий
26. Все определения переменных оператором «var» и функций
перемещаются (поднимаются) в начало области видимости.
Особенность 7. Поднятие определений (hoisting)
Мы пишем А определения поднимаются
for(var i=0; i<3; ++i)
console.log(i)
var i
for(i=0; i<3; ++i)
console.log(i)
27. Во-первых, это удобно. Не нужно объявлять прототипы функций до
того, как они будут использованы. Функцию можно описать в любом
месте – как до, так и после места первого вызова.
Во-вторых, это необычно. Переменные присутствуют ДО их
объявления.
В-третьих, это опасно. Не запрещено написать «var х» несколько раз. А
значит, можно подменить ранее описанную переменную.
И что такого в этом поднятии?
28. Для «var» их две – глобальная и функциональная (тело функции)
console.log(i) // udefined
console.log(j) // error
for(var i=0; i<3; ++i) console.log(i)
console.log(i) // 3
В современном стандарте введена инструкция «let i»,
ограничивающая область видимости текущим блоком, однако,
следует помнить и о поведении инструкции «var»
А где границы области видимости?
29. Что мы увидим в консоли в каждом из вариантов?
function f() {
return 1
}
console.log( f() )
function f() {
return 2
}
console.log( f() )
function f() {
return 1
}
function f() {
return 2
}
var f = function() {
return 1
}
console.log( f() )
var f = function() {
return 2
}
console.log( f() )
var f = function() {
return 1
}
var f = function() {
return 2
}
? ? ? ?
И где тут можно ошибиться программисту?
30. Что мы увидим в консоли в каждом из вариантов?
function f() {
return 1
}
console.log( f() )
function f() {
return 2
}
console.log( f() )
function f() {
return 1
}
function f() {
return 2
}
var f = function() {
return 1
}
console.log( f() )
var f = function() {
return 2
}
console.log( f() )
var f = function() {
return 1
}
var f = function() {
return 2
}
2 2 1
(поднимается только var f)
Uncaught TypeError:
f is not a function
Уверен, Вы так и подумали