Помни: сила рыцаря-джедая — это сила Вселенной.
Но помни: гнев, страх — это всё ведет на темную сторону Силы.
Как только ты сделаешь первый шаг по темному пути,
ты уже не сможешь с него свернуть…

Добрый день, уважаемый галактический сенат! На связи снова Денис Мельский, и сегодня на повестке дня — определение теоретического минимума познания *nix систем для юного падавана web-мастерства.

Хотелось бы начать с того, что все мы прекрасно знаем: на 67.4 % наши любимые интернеты крутятся на *nix-based-серверах, а в жизни среднестатистического web-разработчика в вакууме — так и на все 90 %.



Для любителей пруфов — welcome.

Т. ч. в нашем ремесле без знания *nix-систем никак. Давайте проведем экскурс в мир *nix и поймем, какими знаниями должен обладать юный падаван.

Предлагаю рассмотреть три юниорских степени познания дзена управлением шайтан-машиной ака *nix-сервак на примере всеми любимой ubuntu.

Доброго времени суток. В этот раз поговорим на тему, в которой начинал разбираться каждый уважающий себя адепт языка C# — асинхронное программирование с использованием Task или, в простонародье, async/await. Microsoft проделали хорошую работу — ведь для того, чтобы использовать асинхронность в большинстве случаев нужно лишь знание синтаксиса и никаких других подробностей. Но если лезть вглубь, тема довольно объемная и сложная. Ее излагали многие, каждый в своем стиле. Есть очень много классных статей по этой теме, но все равно существует масса заблуждений вокруг нее. Постараемся исправить положение и разжевать материал настолько, насколько это возможно, не жертвуя ни глубиной, ни пониманием.

В наше время развернуть в облаке свой вебсайт с доменным именем второго уровня можно бесплатно. Вам интересно как? Читайте дальше.

Предлагаю вам разобрать то, как можно создать гостевую книгу на ASP.NET Core (с reCAPTCHA) и захостить ее бесплатно на довольно известном облачном хостинге (да, с ограничениями, но для персонального вебсайта с не особо большим трафиком годится вполне)

На конференции connect(), мы объявили, что .NET Core будет выпущен полностью как программное обеспечение с открытым исходным кодом. В этой статье мы сделаем обзор .NET Core, расскажем, как мы собираемся его выпускать, как он соотносится с .NET Framework и что это все означает для кросс-платформенной разработки и разработки с открытым кодом.

Этот пост родился из нашего опыта переноса существующего проекта с ASP.NET MVC на ASP.NET Core. Мы постарались собрать в одно целое весь процесс миграции в структурированном виде и описать различные узкие места, чтобы разработчики в дальнейшем могли опираться на этот материал и следовать дорожной карте при решении подобных задач.

Пара слов о нашем проекте. Мы open-source eCommerce платформа на ASP.NET, которая к моменту переноса успешно существовала уже 9 лет. Мы делали миграцию 2 года назад — но руки дошли написать об этом только сейчас. На тот момент мы были одним из первых крупных проектов, кто решился на подобный шаг.

Почему стоит перейти на ASP.NET Core

Прежде чем приступить к разбору шагов по переходу с ASP.NET MVC на ASP.NET Core, несколько слов о преимуществах этой платформы.

Пытаясь разобраться с библиотекой от Facebook ReactJS и продвигаемой той же компанией архитектурой «Flux», наткнулся на просторах интернета на две занимательные статьи: «ReactJS For Stupid People» и «Flux For Stupid People». Решил поделиться с хабравчанами переводом первой (а чуть позже и второй) статьи. Итак, поехали.

ReactJS для глупых людей

TL;DR В течении долгого времени я пытался понять, что такое React и как он вписывается в структуру приложения. Это статья, которой мне в свое время не хватало.

Что такое React?

Чем отличается React от Angular, Ember, Backbone и других? Как управлять данными? Как взаимодействовать с сервером? Что, черт возьми, такое JSX? Что такое «component»?

СТОП.

Остановитесь прямо сейчас.

React — это ТОЛЬКО УРОВЕНЬ ПРЕДСТАВЛЕНИЯ.

Источник

Всем привет! Сегодня хотим поговорить об облачных базах данных, а точнее о тех проактивных и разовых мероприятиях, которые непосредственно обеспечивают их производительность.

Облачные базы данных давно решили вопрос быстрого прироста мощностей и запуска новых баз данных, и сегодня стали практически насущной потребностью компаний любого размера, благодаря переносу задач по администрированию и мониторингу на сторону провайдера.

Мы проделали большую работу, запуская и оптимизируя свою новую услугу облачной базы данных на собственной платформе Техносерв Cloud и, конечно же, столкнулись с рядом проблем и выработали свои подходы к их решению. Сейчас, когда сервис протестирован и работает, мы хотим поделиться с вами своим опытом – уверены, что прочитав этот материал, вы сможете избежать повторения чужих ошибок или откроете для себя что-то новое.

В Технопарке я преподаю студентам курс «Базы Данных». Уже из названия ясно, что речь идет о неотъемлемой части современной IT-грамотности — без этой дисциплины сегодня трудно представить себе компьютерную специальность. Базы данных в том или ином виде сегодня окружают нас повсюду — в самом обычном смартфоне их сотни, что, разумеется, далеко не предел.

Очередной пост в рамках нашей постоянной рубрики «Лекции Технопарка». В этот раз предлагаем вашему вниманию лекции, посвящённые базам данных. Цель курса — получение студентами знаний в области проектирования реляционных баз данных, эффективной работы с базами данных, оптимизации запросов и схем данных, изучение особенностей использования баз данных в проектах с высокой нагрузкой и/или использующих большие массивы данных, noSQL и его применение для решения прикладных задач в WWW.

В этой статье я хотел бы рассказать о том, как с помощью утилиты Quick Maintenance & Backup for MS SQL настроить автоматическое восстановление баз данных из бэкапов на тестовом экземпляре SQL Server в сети. При этом создавать бэкапы будет штатный План обслуживания. Потребность в автоматизированном восстановлении может возникнуть в следующих случаях:

1. Если требуется регулярно актуализировать базы данных на тестовых серверах.
2. Если требуется периодически проверять через восстановление созданные бэкапы: полный, разностный и журналы транзакций.

В сети можно найти примеры скриптов позволяющие в той или иной мере автоматизировать эти задачи. Но большинство решений требуют хорошего понимания T-SQL, предметной области и скорее всего потребуют изменения ваших Планов обслуживания. Я покажу как это сделать за 15-20 минут с помощью утилиты Quick Maintenance & Backup for MS SQL (QMB). Мы задействуем механизм XML планов восстановления — это XML файл с последовательностью бэкапов, который умеет создавать утилита. По информации в XML файле программа получит последовательность бэкапов, сформирует T-SQL скрипт для восстановления и запустит его на выполнение. Подробнее об этой возможности можно почитать здесь.

Настройка производительности базы данных — разработчики обычно либо любят это, либо ненавидят. Я получаю удовольствие от этого и хочу поделиться некоторыми методами, которые я использовал в последнее время для настройки плохо выполняющихся запросов в PostgreSQL. Мои методы не является исчерпывающими, скорее учебником для тех, кто просто тащится от тюнинга.

Поиск медленных запросов

Первый очевидный способ начать тюнинг — это найти конкретные операторы, которые работают плохо.

pg_stats_statements

Модуль pg_stats_statements — отличное место для начала. Он просто отслеживает статистику выполнения операторов SQL и может быть простым способом поиска неэффективных запросов.

Как только вы установили этот модуль, системное представление с именем pg_stat_statements будет доступно со всеми своими свойствами. Как только у него будет возможность собрать достаточный объем данных, ищите запросы, которые имеют относительно высокое значение total_time. Сначала сфокусируйтесь на этих операторах.

SELECT *
FROM
  pg_stat_statements
ORDER BY
  total_time DESC;

Неожиданное поведение приложения в отношении работы с базой приводит к войне между DBA и разработчиками: DBA кричат: «Ваше приложение роняет базу», разработчики — «Но ведь до этого всё работало!». Хуже всего, что DBA и разработчики не могут помочь друг другу: одни не знают про нюансы работы приложения и драйвера, другие не знают про особенности, связанные с инфраструктурой. Было бы неплохо такой ситуации избежать.

Надо понимать, часто недостаточно полистать go-database-sql.org. Лучше вооружиться чужим опытом. Еще лучше, если это будет опыт, полученный кровью и потерянными деньгами.

Time series данные или временные ряды — это данные, которые изменяются во времени. Котировки валют, телеметрия перемещения транспорта, статистика обращения к серверу или нагрузки на CPU — это time series данные. Чтобы их хранить требуются специфичные инструменты — темпоральные базы данных. Инструментов — десятки, например, InfluxDB или ClickHouse. Но даже у самых лучших решений для хранения временных рядов есть недостатки. Все time series хранилища низкоуровневые, подходят только для time series данных, а обкатка и внедрение в текущий стек — дорого и больно.



Но, если у вас стек PostgreSQL, то можете забыть о InfluxDB и всех остальных темпоральных БД. Ставите себе два расширения TimescaleDB и PipelineDB и храните, обрабатываете и проводите аналитику time series данных прямо в экосистеме PostgreSQL. Без внедрения сторонних решений, без недостатков темпоральных хранилищ и без проблем их обкатки. Что это за расширения, в чем их преимущества и возможности, расскажет Иван Муратов (binakot) — руководитель отдела разработки в «Первой Мониторинговой Компании».

В качестве короткого дополнения к статье Попытка создать аналог ASH для PostgreSQL.

Задача

Необходимо связать историю представлений pg_stat_statemenets, pg_stat_activity. В результате, используя историю планов выполнения из сервисной таблицы log_query, можно получить очень много полезной информации, для использования в процессе решения инцидентов производительности и оптимизации запросов.

Предупреждение.
В связи с новизной темы и незавершением периода тестирования, статья может содержать ошибки. Критика и замечания всячески приветствуются и ожидаются.

Примерно год назад передо мной и моими коллегами была поставлена задача разобраться с использованием популярной системы мониторинга сетевой инфраструктуры — Zabbix. После изучения документации мы сразу же перешли к нагрузочному тестированию: хотели оценить с каким количеством параметров может работать Zabbix без заметных падений производительности. В качестве СУБД использовали только PostgreSQL.

В ходе тестов были выявлены некоторые архитектурные особенности разметки БД и поведения самой системы мониторинга, которые по умолчанию не позволяют выйти системе мониторинга на свою максимальную мощность работы. В результате были разработаны, проведены и апробированы некоторые оптимизационные мероприятия в основном в части настройки БД.

О результатах проделанной работы я и хочу поделиться в данной статье. Статья будет полезна как администраторам Zabbix, так и PostgreSQL DBA, а также всем желающим лучше понять и разобраться в популярной СУБД PosgreSQL.

Небольшой спойлер: на слабой машине при нагрузке в 200 тысяч параметров в минуту нам удалось снизить показатель CPU iowait с 20% до 2%, уменьшить время записи порциями в таблицы первичных данных в 250 раз и в таблицы агрегированных данных в 32 раза, уменьшить размер индексов в 5-10 раз и ускорить получение исторических выборок в некоторых случаях до 18 раз.

В прошлой статье об инструменте для мониторинга Foglight for Databases мы рассказывали о возможностях контроля из единого интерфейса SQL Server, Oracle, PostgreSQL, MySQL, SAP ASE, DB2, Cassandra и MongoDB. Сегодня разберём подходы к быстрому выявлению причин нештатной работы Microsoft SQL Server:

• Поиск источника блокировки;
• Сравнение настроек БД «было-стало» с привязкой к метрикам производительности;
• Поиск изменений в структуре БД, из-за которых снизилась производительность.

Подробности под катом.

Привет, Хаброжители! В недрах популярных социальных сетей — Twitter, Facebook, LinkedIn и Instagram — скрыты богатейшие залежи информации. Из этой книги исследователи, аналитики и разработчики узнают, как извлекать эти уникальные данные, используя код на Python, Jupyter Notebook или контейнеры Docker. Сначала вы познакомитесь с функционалом самых популярных социальных сетей (Twitter, Facebook, LinkedIn, Instagram), веб-страниц, блогов и лент, электронной почты и GitHub. Затем приступите к анализу данных на примере Twitter. Прочитайте эту книгу, чтобы:

• Узнать о современном ландшафте социальных сетей;
• Научиться использовать Docker, чтобы легко оперировать кодами, приведёнными в книге;
• Узнать, как адаптировать и поставлять код в открытый репозиторий GitHub;
• Научиться анализировать собираемые данные с использованием возможностей Python 3;
• Освоить продвинутые приемы анализа, такие как TFIDF, косинусное сходство, анализ словосочетаний, определение клика и распознавание образов;
• Узнать, как создавать красивые визуализации данных с помощью Python и JavaScript.

При первом знакомстве с квазиньютоновскими методами можно удивиться дважды. Во-первых, после беглого взгляда на формулы охватывают сомнения, что это вообще может работать. Однако же они работают. Дальше кажется сомнительным, что они будут работать хорошо. И тем удивительнее видеть то, насколько они превосходят по скорости разнообразные вариации градиентного спуска, причем не на специально построенных задачах, а на самых настоящих, взятых из практики. И если после этого еще остаются сомнения вперемешку с интересом — то нужно разбираться в том, почему вообще работает это нечто.

Введение

Здравствуйте, уважаемые хабровчане!

Последние два года моей работы в компании Synesis были тесно связаны с процессом создания и развития Synet — открытой библиотеки для запуска предварительно обученных сверточных нейронных сетей на CPU. В процессе этой работы мне пришлось столкнуться с рядом интересных моментов, которые касаются вопросов оптимизации алгоритмов прямого распространения сигнала в нейронных сетях. Как мне кажется, описание этих моментов было бы весьма интересным для читателей Хабрахабра. Чему я и хочу посвятить цикл своих статей. Продолжительность цикла будет зависеть от вашего интереса к данной теме ну и конечно же от моей способности побороть лень. Начать цикл хочется с описания самого велосипеда фреймворка. Вопросы алгоритмов, которые лежат в его основе будут раскрыты в последующих статьях:

1. Сверточный слой: методы оптимизации основанные на матричном умножении
2. Сверточный слой: быстрая свертка по методу Шмуэля Винограда

Привет всем

Я решил начать цикл статей на тему обучения программирования в .NET, а именно на C#. Я не претендую на авторство всего, что здесь и далее будет написано, я всего лишь хочу дать знания тем, кто этого желает.
На Хабре много раз могли заметить мои комментарии по поводу того, что я очень хотел бы обучать людей, но никак не мог придумать как это сделать. После цикла статей MaxElc я подумал, что тоже могу паралельно с ним начать писать.
Пожалуй начнём!

Архитектура .NET

.NET — это среда исполнения или платформа. Она располагается между кодом и Windows, позволяя предоставлять нужные службы. Платформа .NET состоит из двух основных компонентов. Это Common Language Runtime и .NET Framework Class Library.

Common Language Runtime (сокращенно CLR) можно назвать «двигателем» платформы .NET. CLR занимается управлением памятью, компиляцией и выполнением кода, работой с потоками управления, обеспечением безопасности и т.п.

.NET Framework Class Library — это набор классов на все случаи жизни.