Forwarded from SecurityLab.ru
Google Analytics объявлен незаконным в ЕС
Австрийское управление по защите данных заявило, что использование системы сбора статистики Google Analytics нарушает «Общего регламента по защите данных» (General Data Protection Regulation, GDPR) и представляет угрозу конфиденциальности.
Согласно решению суда, сервис Google Analytics признан незаконным для использования на европейских web-сайтах.
Теперь многие компании в Европе должны удалить Google Analytics со своих сайтов или рискуют быть оштрафованными за нарушение GDPR.
https://www.securitylab.ru/news/528944.php
Австрийское управление по защите данных заявило, что использование системы сбора статистики Google Analytics нарушает «Общего регламента по защите данных» (General Data Protection Regulation, GDPR) и представляет угрозу конфиденциальности.
Согласно решению суда, сервис Google Analytics признан незаконным для использования на европейских web-сайтах.
Теперь многие компании в Европе должны удалить Google Analytics со своих сайтов или рискуют быть оштрафованными за нарушение GDPR.
https://www.securitylab.ru/news/528944.php
SecurityLab.ru
Google Analytics объявлен незаконным в ЕС
Компании в Европе должны удалить Google Analytics со своих сайтов или им грозит штраф за нарушение GDPR.
Forwarded from Lil Functor
C4 Model
Меня сильно заинтересовали способы грамотной визуализации архитектуры программных систем, потому что диаграмы уровня
Из того, что нашёл, больше всего понравился фреймворк C4model. Но зачем вообще нужен целый фреймворк для визуализации? Без него каждый раз приходится импровизировать, что нарисовать на диаграмме. А нарисовать хочется многое: юзер-стори, технологии, карту микросервисов и хранилищ, технические ограничения... В итоге получается либо картинка с хаотичным набором стрелочек и квадратиков с перемешанными абстракциями «всё в одном», либо фрустрация и рисование примитивной схемы а-ля «ну тут сервис, тут база, всё понятно вроде».
C4 предлагает решение через разделение уровней детализации: нарисовать несколько схем от взляда на систему с высоты птичьего полёта до всё более подробных представлений отдельных процессов. Cлоёв ровно четыре, и их описание можно прочитать на сайте фреймворка. У себя на сайте я оставил краткий конспект (тут и так слишком много слов для телеграма).
Мне нравится подход C4, но с парой ремарок:
→ Я бы сократил C4 до C3. Визуализация связей внутри кода приложения кажется избыточной: если все сервисы пишутся по единым паттернам в неком подобии гексагональной архитектуры, то и связи между модулями будут типовыми. Лучше инвестировать в выработку организационных стандартов кодирования, чем в рисование/генерацию UML.
→ В микросервисных реалиях одно приложение содержит в себе совсем немного компонент, поэтому на третьем уровне вместо статической диаграммы внутренностей отдельного приложения лучше нарисовать основные процессы, которые оно выполняет. Для этого хорошо подходит диаграмма последовательности из PlantUML.
→ Описание слоёв не является догмой и должно адаптироваться под нужды организации или команды.
Напишите в комментарии, что вы у себя используете для визуализации/документирования разработок?
Меня сильно заинтересовали способы грамотной визуализации архитектуры программных систем, потому что диаграмы уровня
[kafka] → [scala] → [postgresql] порядком поднадоели. Хочется выработать максимально информативный, но в тоже время удобный способ рисовать то, что мы проектируем. Из того, что нашёл, больше всего понравился фреймворк C4model. Но зачем вообще нужен целый фреймворк для визуализации? Без него каждый раз приходится импровизировать, что нарисовать на диаграмме. А нарисовать хочется многое: юзер-стори, технологии, карту микросервисов и хранилищ, технические ограничения... В итоге получается либо картинка с хаотичным набором стрелочек и квадратиков с перемешанными абстракциями «всё в одном», либо фрустрация и рисование примитивной схемы а-ля «ну тут сервис, тут база, всё понятно вроде».
C4 предлагает решение через разделение уровней детализации: нарисовать несколько схем от взляда на систему с высоты птичьего полёта до всё более подробных представлений отдельных процессов. Cлоёв ровно четыре, и их описание можно прочитать на сайте фреймворка. У себя на сайте я оставил краткий конспект (тут и так слишком много слов для телеграма).
Мне нравится подход C4, но с парой ремарок:
→ Я бы сократил C4 до C3. Визуализация связей внутри кода приложения кажется избыточной: если все сервисы пишутся по единым паттернам в неком подобии гексагональной архитектуры, то и связи между модулями будут типовыми. Лучше инвестировать в выработку организационных стандартов кодирования, чем в рисование/генерацию UML.
→ В микросервисных реалиях одно приложение содержит в себе совсем немного компонент, поэтому на третьем уровне вместо статической диаграммы внутренностей отдельного приложения лучше нарисовать основные процессы, которые оно выполняет. Для этого хорошо подходит диаграмма последовательности из PlantUML.
→ Описание слоёв не является догмой и должно адаптироваться под нужды организации или команды.
Напишите в комментарии, что вы у себя используете для визуализации/документирования разработок?
Forwarded from Experimental chill
Метастабильные падения
Я просто обожаю эксплуатацию.
Практически никто о метастабильных падениях не говорит, они достаточно бессистемные, но кажется на своей практике поиска и вот сейчас мап редьюса я столкнулся просто со всем, что написано в статье.
Метастабильные падения это падения, которые вызваны непредвиденными обстоятельствами и даже если их убрать, то система не восстанавливается и продолжает не работать. Скажем, DDOS атака сама по себе не является метастабильным падением. Вы можете её убрать, и система продолжит хорошо работать.
Ретраи
Рассмотрим пример. Скажем, вы пишете сервис Google Maps API для поиска маршрута. Новый релиз разломал бэкенд карт. Надо откатывать, но вот незадача, ваше API используется очень тупыми железками вроде GPS навигаторов. Они перезапрашивают в цикле. В итоге бэкенд карт разломался, вы пытаетесь откатить изменения, а из-за количества запросов бэкенд снова валится. Вы снова пытаетесь поднять инстансы, а они не держат эту нагрузку. В итоге система сломана, надо очень сильно понижать нагрузку уровнями выше.
Кэш
Другой пример. Сундар Пичай рассказывал конгрессу, что в поиске примерно 50% запросов, которые задаются единожды и не повторяются другими пользователями. Когда вы видите, что 50% запросов можно отвечать, не ходя на бэкенд, то вы сделаете себе кэш. Кэш понизит лэтенси, будет крутой оптимизацией. Но...
Скажем, кэш для поиска работает днями, с ним все хорошо, проходят релизы. В один момент формат кэша поменялся и все таки надо его сбросить. Сбрасывайте, а бэкенд не может выдержать нагрузки! А он нужен для того, чтобы набрать кэш. В итоге вы не можете набрать кэш, потому что бэкенд развалился, кэш уже сбросился и невалиден. Как минимум вы застряли в системе, которая не двигается вперёд, как максимум это просто ад восстанавливать из-за многих релизов бекенда.
Сверхоптимизации
Третий пример, которого я страшно боюсь в своей работе. В мапредьюсе надо решить, сколько вы должны заплодить машин, как подробить данные для выполнения работы на той или иной стадии, чтобы минимизировать выполнение. Это моделька машинного обучения, и машинное обучение может ошибаться на высоких квантилях. В итоге приходит пользователь, у него пайплайн работал день, а теперь не может завершиться 10 дней из-за плохих решений автоскейлинга. Да что там говорить, ресурсов всей компании не хватит с такими решениями модельки, чтобы завершить пайплайн за месяц.
Что произошло на самом деле:
1. Мы научились оптимизировать пайплайн очень хорошо, без модельки он завершался
2. Пайплайн вырос в сотню раз, но мы все ещё хорошо его оптимизировали
3. Мы поменяли модельку оптимизации
4. Теперь не хватит ресурсов компании его завершить
В итоге надо руками прописывать как запускать стадии, что противоречит всем моделям эластичности Клауда.
Ближайший простой пример: алгоритмам сжатия не стоит иметь формат, который умеет сжимать в экспоненту раз, а то и в квадрат. Из-за этого есть zip-бомбы.
Все такие примеры очень показательны, что распределенные системы странно ломаются и входят в такой порочный круг, и часто их оптимизации могут привести к таким состояниям, когда они ломаются и сами не починятся. В литературе практически никогда ничего не говорится про такие идеи.
Решения, которые стоит рассматривать при проектировке
* Приоритеты. Делать приоритеты хорошим запросам.
* Лимиты. Если что-то оптимизируете, не оптимизируете это в сотню раз, если можете эту сотню в итоге потерять и не справиться.
* Всегда планировать нагрузку без оптимизаций, которые когда-то могут не работать, в том числе кэши. Пусть оно замедлит на 100ms ответ, но оно хотя бы не упадёт. Учения, стресс тестирование пригодится.
* Деградация. Попытайтесь задизайнить бэкенд, чтобы он эластично деградировал, скажем, не искать лучший маршрут в Google Maps, а рассматривать только X%.
* Следите за системой, одно падение может обнаружить баг, который был годами. Обычно происходит так: система ломается чуть-чуть, что-то подозрительное происходит, на след день что-то ещё хуже, через 2 дня всё падает крахом.
[1] Metastable Failures in Distributed Systems
Я просто обожаю эксплуатацию.
Практически никто о метастабильных падениях не говорит, они достаточно бессистемные, но кажется на своей практике поиска и вот сейчас мап редьюса я столкнулся просто со всем, что написано в статье.
Метастабильные падения это падения, которые вызваны непредвиденными обстоятельствами и даже если их убрать, то система не восстанавливается и продолжает не работать. Скажем, DDOS атака сама по себе не является метастабильным падением. Вы можете её убрать, и система продолжит хорошо работать.
Ретраи
Рассмотрим пример. Скажем, вы пишете сервис Google Maps API для поиска маршрута. Новый релиз разломал бэкенд карт. Надо откатывать, но вот незадача, ваше API используется очень тупыми железками вроде GPS навигаторов. Они перезапрашивают в цикле. В итоге бэкенд карт разломался, вы пытаетесь откатить изменения, а из-за количества запросов бэкенд снова валится. Вы снова пытаетесь поднять инстансы, а они не держат эту нагрузку. В итоге система сломана, надо очень сильно понижать нагрузку уровнями выше.
Кэш
Другой пример. Сундар Пичай рассказывал конгрессу, что в поиске примерно 50% запросов, которые задаются единожды и не повторяются другими пользователями. Когда вы видите, что 50% запросов можно отвечать, не ходя на бэкенд, то вы сделаете себе кэш. Кэш понизит лэтенси, будет крутой оптимизацией. Но...
Скажем, кэш для поиска работает днями, с ним все хорошо, проходят релизы. В один момент формат кэша поменялся и все таки надо его сбросить. Сбрасывайте, а бэкенд не может выдержать нагрузки! А он нужен для того, чтобы набрать кэш. В итоге вы не можете набрать кэш, потому что бэкенд развалился, кэш уже сбросился и невалиден. Как минимум вы застряли в системе, которая не двигается вперёд, как максимум это просто ад восстанавливать из-за многих релизов бекенда.
Сверхоптимизации
Третий пример, которого я страшно боюсь в своей работе. В мапредьюсе надо решить, сколько вы должны заплодить машин, как подробить данные для выполнения работы на той или иной стадии, чтобы минимизировать выполнение. Это моделька машинного обучения, и машинное обучение может ошибаться на высоких квантилях. В итоге приходит пользователь, у него пайплайн работал день, а теперь не может завершиться 10 дней из-за плохих решений автоскейлинга. Да что там говорить, ресурсов всей компании не хватит с такими решениями модельки, чтобы завершить пайплайн за месяц.
Что произошло на самом деле:
1. Мы научились оптимизировать пайплайн очень хорошо, без модельки он завершался
2. Пайплайн вырос в сотню раз, но мы все ещё хорошо его оптимизировали
3. Мы поменяли модельку оптимизации
4. Теперь не хватит ресурсов компании его завершить
В итоге надо руками прописывать как запускать стадии, что противоречит всем моделям эластичности Клауда.
Ближайший простой пример: алгоритмам сжатия не стоит иметь формат, который умеет сжимать в экспоненту раз, а то и в квадрат. Из-за этого есть zip-бомбы.
Все такие примеры очень показательны, что распределенные системы странно ломаются и входят в такой порочный круг, и часто их оптимизации могут привести к таким состояниям, когда они ломаются и сами не починятся. В литературе практически никогда ничего не говорится про такие идеи.
Решения, которые стоит рассматривать при проектировке
* Приоритеты. Делать приоритеты хорошим запросам.
* Лимиты. Если что-то оптимизируете, не оптимизируете это в сотню раз, если можете эту сотню в итоге потерять и не справиться.
* Всегда планировать нагрузку без оптимизаций, которые когда-то могут не работать, в том числе кэши. Пусть оно замедлит на 100ms ответ, но оно хотя бы не упадёт. Учения, стресс тестирование пригодится.
* Деградация. Попытайтесь задизайнить бэкенд, чтобы он эластично деградировал, скажем, не искать лучший маршрут в Google Maps, а рассматривать только X%.
* Следите за системой, одно падение может обнаружить баг, который был годами. Обычно происходит так: система ломается чуть-чуть, что-то подозрительное происходит, на след день что-то ещё хуже, через 2 дня всё падает крахом.
[1] Metastable Failures in Distributed Systems
Forwarded from Technologique
Some absolutely great software - a tools, written in Rust, which can improve your daily workflow and can help get things done faster:
Terminal emulator:
https://github.com/alacritty/alacritty
File managers:
https://github.com/ranger/ranger
https://github.com/ranger/ranger/wiki/Similar-software#hunter-rust
https://github.com/rabite0/hunter
#Rust
Terminal emulator:
https://github.com/alacritty/alacritty
File managers:
https://github.com/ranger/ranger
https://github.com/ranger/ranger/wiki/Similar-software#hunter-rust
https://github.com/rabite0/hunter
#Rust
GitHub
GitHub - alacritty/alacritty: A cross-platform, OpenGL terminal emulator.
A cross-platform, OpenGL terminal emulator. Contribute to alacritty/alacritty development by creating an account on GitHub.
Forwarded from CyberYozh
Подборка популярных и малоизвестных сервисов проверки email адресов на утечки пароля по слитым базам данных.
https://haveibeenpwned.com
https://leakedsource.ru
https://leakcheck.io
https://monitor.firefox.com
https://dehashed.com
https://breachalarm.com
https://sitecheck.sucuri.net
https://intelx.io/
Обсудить в чате 👉 https://news.1rj.ru/str/+jrxm2KHbIl9kMDQy
https://haveibeenpwned.com
https://leakedsource.ru
https://leakcheck.io
https://monitor.firefox.com
https://dehashed.com
https://breachalarm.com
https://sitecheck.sucuri.net
https://intelx.io/
Обсудить в чате 👉 https://news.1rj.ru/str/+jrxm2KHbIl9kMDQy
Основы_Big_Data_Концепции,_алгоритмы_и_технологии.PDF
28.8 MB
посоветовали книгу для начинающих
Big Data - концепции, алгоритмы и технологии
Оригинал - https://www.amazon.com/exec/obidos/ASIN/0134291077/managementc09-20/
Глава 1 - Понимание больших данных. = Концепты и терминология. Хараткеристики. Типы данных
Глава 2 - Бизнес-мотивация и стимулы для перехода к обработке больших данных. Динамика рынка. бизнес-архитектура
Глава 3 - переходд к большим данным и вопросы планирования
Глава 4 - корпоративные технологии и BI для Big Data = OLTP, OLAP, ETL, Storages, Data Mart, BI
Глава 5 - Концепции хранения Big Data = Кластеры, NoSQL, Шардинг, Репликация, Теория CAP, ACID, BASE
Глава 6 - Концепции обработки больших данных = Паралелизация, распледеление, Hadoop, Кластер, Пакетная обработка, Транзакционная обработка, Обработка в реалтайме
Глава 7 - Технологии хранения Big Data. Дисковые устройства, Системы хранения в RAM
Глава 8 - Основные методы анализа больших данных = Количественный, Качественный, data-mining, Статистический, МЛ, Семантический, Визуальный анализ
Big Data - концепции, алгоритмы и технологии
Оригинал - https://www.amazon.com/exec/obidos/ASIN/0134291077/managementc09-20/
Глава 1 - Понимание больших данных. = Концепты и терминология. Хараткеристики. Типы данных
Глава 2 - Бизнес-мотивация и стимулы для перехода к обработке больших данных. Динамика рынка. бизнес-архитектура
Глава 3 - переходд к большим данным и вопросы планирования
Глава 4 - корпоративные технологии и BI для Big Data = OLTP, OLAP, ETL, Storages, Data Mart, BI
Глава 5 - Концепции хранения Big Data = Кластеры, NoSQL, Шардинг, Репликация, Теория CAP, ACID, BASE
Глава 6 - Концепции обработки больших данных = Паралелизация, распледеление, Hadoop, Кластер, Пакетная обработка, Транзакционная обработка, Обработка в реалтайме
Глава 7 - Технологии хранения Big Data. Дисковые устройства, Системы хранения в RAM
Глава 8 - Основные методы анализа больших данных = Количественный, Качественный, data-mining, Статистический, МЛ, Семантический, Визуальный анализ
🔥1
нашел шикарный плейлист по
Бизнес и Системный анализ в жизненном цикле разработки ПО
скоро досмотрю
https://youtube.com/playlist?list=PLS2k5aJRMxzRBRPtNBreyxZWHeJ-kZAv7
1) БиСА вводная
2) БиСА Концепции архитектуры ПО
3) БиСА в продуктовой и сервисной разработке
4) Заинтересованные Лица
5) БиСА. Бизнес модеь. ценность продукта
6) БиСа. Анализ и определние проблемы
7) БиСа. Документирование требований
8) БиСА. Моделирование использования
9) БиСА. Атрибуты качества
10) БиСА. Концептуальная модель
11) БиСА. Построение архитектуры
1. БиСА в продуктовой и сервисной разработке
https://youtu.be/1bBNVWr_pEw
Модели
- Сервисная
- Ценностная
ВНЕ ЗАВИСИМОСТИ ОТ ВИДА ТРУДА. Эффективность для бизнеса будет во многом зависит от того за что именно нам платят деньги
Сервисная модель (покупатиль платит за время работы)
- самая бедная модель (выгода составляет разница между зарплатой и тем что платит клиент)
- повышение эффективности труда не влечет повышение заработка (а наоборот)
- повышение эффективности продукта не влечет повышение заработка
+ выгода только в низкооплачиваемых сотрудниках. ЧЕМ МЕНЬШЕ РАБОТОДАТЕЛЬ ПЛАТИТ ЗА РАБОТУ ТЕМ ВЫШЕ ЕГО ПРИБЫЛЬ
Ценностная модель (покупатель платит за то сколько стоит для него результат труда)
+ эффективная работа становится выгодной
+ высокоценные сотрудники ТЕ которые БОЛЬШЕ ЗНАЕТ
+ платят столько сколько ценности приносит человек в компанию
- чем выше прибыль тем выше необходимые затраты. и тем меньше спрос!
Архитектору платят за то что он знает как сделать эффективно
Два варианта роста по ЗП
- вертикальный (чем большим количеством людей вы управляете тем больше вам платят)
- горизонтальный (чем больше вы знаете, тем больше вам платят)
Если результат не увеличивает ценности - то не важно сколько часов вы отработали !!!! Трудоголизм оправдывается только в обучение (для ценностной модели)
Чем выше вы поднимаетесь в стоимости ваших услуг, тем меньше компаний готовы за вас заплатить
Продуктовая модель
= Компания зарабатывает на тиражируемости продукта
ДОХОД = ТИРАЖ * (ЦЕНА_продукта - ЗАТРАТЫ_вложенные) - ЗАТРАТЫ_пост
+ чем больше людей купило КАЧЕТСВЕННЫЙ продукт тем больше прибыли
+ Для повышения ценности решения одновременно со снижением индивидуальной стоимости необходимо РАЗДЕЛИТЬ ТРУДОЗАТРАТЫ на создание продукта
- чем больше пользователей тем сложнее создавать продукт соответствующий потребностям
- потенциальный рынок продукта имеет свой предел
+ В ОТЛИЧИЕ ОТ УСЛУГИ ПРОДУКТ ПРИОБРЕТАЕТСЯ ОДИН РАЗ
Продуктовая (услуга) модель
ДОХОД_в_мес = К-ВО_подписчиков * ЦЕНА_подписчики - ЗАТРАТЫ_поддержка - ЗАТРАТЫ_создание_платформы / Амортизация
Овертаймы окупаются лишь в первый раз ! среднее количество ошибок при работе в овертайм постоянно ростет с каждым часом
Бизнес и Системный анализ в жизненном цикле разработки ПО
скоро досмотрю
https://youtube.com/playlist?list=PLS2k5aJRMxzRBRPtNBreyxZWHeJ-kZAv7
1) БиСА вводная
2) БиСА Концепции архитектуры ПО
3) БиСА в продуктовой и сервисной разработке
4) Заинтересованные Лица
5) БиСА. Бизнес модеь. ценность продукта
6) БиСа. Анализ и определние проблемы
7) БиСа. Документирование требований
8) БиСА. Моделирование использования
9) БиСА. Атрибуты качества
10) БиСА. Концептуальная модель
11) БиСА. Построение архитектуры
1. БиСА в продуктовой и сервисной разработке
https://youtu.be/1bBNVWr_pEw
Модели
- Сервисная
- Ценностная
ВНЕ ЗАВИСИМОСТИ ОТ ВИДА ТРУДА. Эффективность для бизнеса будет во многом зависит от того за что именно нам платят деньги
Сервисная модель (покупатиль платит за время работы)
- самая бедная модель (выгода составляет разница между зарплатой и тем что платит клиент)
- повышение эффективности труда не влечет повышение заработка (а наоборот)
- повышение эффективности продукта не влечет повышение заработка
+ выгода только в низкооплачиваемых сотрудниках. ЧЕМ МЕНЬШЕ РАБОТОДАТЕЛЬ ПЛАТИТ ЗА РАБОТУ ТЕМ ВЫШЕ ЕГО ПРИБЫЛЬ
Ценностная модель (покупатель платит за то сколько стоит для него результат труда)
+ эффективная работа становится выгодной
+ высокоценные сотрудники ТЕ которые БОЛЬШЕ ЗНАЕТ
+ платят столько сколько ценности приносит человек в компанию
- чем выше прибыль тем выше необходимые затраты. и тем меньше спрос!
Архитектору платят за то что он знает как сделать эффективно
Два варианта роста по ЗП
- вертикальный (чем большим количеством людей вы управляете тем больше вам платят)
- горизонтальный (чем больше вы знаете, тем больше вам платят)
Если результат не увеличивает ценности - то не важно сколько часов вы отработали !!!! Трудоголизм оправдывается только в обучение (для ценностной модели)
Чем выше вы поднимаетесь в стоимости ваших услуг, тем меньше компаний готовы за вас заплатить
Продуктовая модель
= Компания зарабатывает на тиражируемости продукта
ДОХОД = ТИРАЖ * (ЦЕНА_продукта - ЗАТРАТЫ_вложенные) - ЗАТРАТЫ_пост
+ чем больше людей купило КАЧЕТСВЕННЫЙ продукт тем больше прибыли
+ Для повышения ценности решения одновременно со снижением индивидуальной стоимости необходимо РАЗДЕЛИТЬ ТРУДОЗАТРАТЫ на создание продукта
- чем больше пользователей тем сложнее создавать продукт соответствующий потребностям
- потенциальный рынок продукта имеет свой предел
+ В ОТЛИЧИЕ ОТ УСЛУГИ ПРОДУКТ ПРИОБРЕТАЕТСЯ ОДИН РАЗ
Продуктовая (услуга) модель
ДОХОД_в_мес = К-ВО_подписчиков * ЦЕНА_подписчики - ЗАТРАТЫ_поддержка - ЗАТРАТЫ_создание_платформы / Амортизация
Овертаймы окупаются лишь в первый раз ! среднее количество ошибок при работе в овертайм постоянно ростет с каждым часом
YouTube
1. БиСА в продуктовой и сервисной разработке
Технопарк Mail.ru Group, МГТУ им. Н.Э. Баумана
Курс "Бизнес и системный анализ для архитекторов (осень 2014)
Лекция №1 - "Бизнес и системный анализ в продвинутой и сервисной разработке"
Лектор - Дмитрий Безуглый
Другие лекции курса | https://www.youtub…
Курс "Бизнес и системный анализ для архитекторов (осень 2014)
Лекция №1 - "Бизнес и системный анализ в продвинутой и сервисной разработке"
Лектор - Дмитрий Безуглый
Другие лекции курса | https://www.youtub…
The Power Spectrum
==Part1
https://mark-kramer.github.io/Case-Studies-Python/03.html
- Visual inspection
- Mean, variance, and standard deviation
- The autocovariance
- Power spectral density
- The spectrum
- The discrete Fourier transform in Python
- The Nyquist frequency
- The frequency resolution
- Decibel scaling
- The spectrogram
== Part2
https://mark-kramer.github.io/Case-Studies-Python/04.html
- Visual inspection
- Spectral Analysis: The Rectangular Taper and Zero Padding
- Beyond the Rectangular Taper—the Hanning Taper
- Beyond the Hanning Taper—the Multitaper Method
- Confidence Intervals of the Spectrum
==Part1
https://mark-kramer.github.io/Case-Studies-Python/03.html
- Visual inspection
- Mean, variance, and standard deviation
- The autocovariance
- Power spectral density
- The spectrum
- The discrete Fourier transform in Python
- The Nyquist frequency
- The frequency resolution
- Decibel scaling
- The spectrogram
== Part2
https://mark-kramer.github.io/Case-Studies-Python/04.html
- Visual inspection
- Spectral Analysis: The Rectangular Taper and Zero Padding
- Beyond the Rectangular Taper—the Hanning Taper
- Beyond the Hanning Taper—the Multitaper Method
- Confidence Intervals of the Spectrum
mark-kramer.github.io
The Power Spectrum (Part 1)
The Power Spectrum (Part 1) <div class=
Forwarded from Scala программирование (MainBot)
В чем разница между машинным обучением и AI?
— Если это написано на python, то это машинное обучение.
— Если это написано на PowerPoint, то это AI.
— Если это написано на python, то это машинное обучение.
— Если это написано на PowerPoint, то это AI.
== Factorio Is The Best Technical Interview We Have
https://erikmcclure.com/blog/factorio-is-best-interview-we-have/
https://erikmcclure.com/blog/factorio-is-best-interview-we-have/
Erik McClure
Factorio Is The Best Technical Interview We Have
There’s been a lot of hand-wringing over The Technical Interview lately. Many people realize that inverting a binary tree on a whiteboard has basically zero correlation to whether or not someone is actually a good software developer. The most effective programming…
== Ranger — лучший файловый менеджер
https://youtu.be/T6qthSaOBas
https://youtu.be/T6qthSaOBas
YouTube
Ranger — лучший файловый менеджер
Учи GNU/Linux тут: https://go.yodo.im/linux-devops-c0dc9d
Промокод на скидку 20% BTRIANGLE22
=======
Все ссылки по теме: https://news.1rj.ru/str/black_triangle_tg/2085
=======
"Спасти мир" и поддержать канал можно тутЬ:
Анонимно криптовалютами: https://notabug.o…
Промокод на скидку 20% BTRIANGLE22
=======
Все ссылки по теме: https://news.1rj.ru/str/black_triangle_tg/2085
=======
"Спасти мир" и поддержать канал можно тутЬ:
Анонимно криптовалютами: https://notabug.o…
== Learn Makefiles. With the tastiest examples
https://makefiletutorial.com/
https://makefiletutorial.com/
АААААААААА
== Анатомия асинхронных фреймворков в С++ и других языках
https://habr.com/ru/company/yandex/blog/647853/
https://www.youtube.com/watch?v=9fBriAl7PZI&t=329s&ab_channel=%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0
== Анатомия асинхронных фреймворков в С++ и других языках
https://habr.com/ru/company/yandex/blog/647853/
https://www.youtube.com/watch?v=9fBriAl7PZI&t=329s&ab_channel=%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0
Хабр
Анатомия асинхронных фреймворков в С++ и других языках
Привет! В этой статье я расскажу об устройстве асинхронных движков с корутинами и без них. Для начала сосредоточимся не на конкретном движке, а на том, почему во всех популярных языках...
прикольный сервис что бы сгенерировать лицо несуществующего человека
== Generated Photos. Unique, worry-free model photos
https://generated.photos/
https://generated.photos/face-generator/new
== Generated Photos. Unique, worry-free model photos
https://generated.photos/
https://generated.photos/face-generator/new
generated.photos
Generated Photos | Unique, worry-free model photos
AI-generated images have never looked better. Explore and download our diverse, copyright-free headshot images from our production-ready database.
== Регистровая машина и язык ассемблера
https://youtu.be/BSN2x7blg6o
https://youtu.be/BSN2x7blg6o
YouTube
Регистровая машина и язык ассемблера
== Две задачи для машины Поста
https://youtu.be/2tFgsIAqM-Q
https://youtu.be/2tFgsIAqM-Q
YouTube
Две задачи для машины Поста
Тьюринг-полнота, машина Тьюринга - несложные, хотя и фундаментальные концепции в computer science, которые полезны и как для просто понимания компьютерной литературы, так и для углубления постижения области вообще, её оснований.
В этом видео об этом не рассказывается…
В этом видео об этом не рассказывается…