Первые 70% курса по SQL кажутся довольно простыми. Сложности начинаются на остальных 30%.

С 2015 по 2019 годы я прошёл четыре цикла собеседований на должность аналитика данных и специалиста по анализу данных в более чем десятке компаний. После очередного неудачного интервью в 2017 году — когда я запутался в сложных вопросах по SQL — я начал составлять задачник с вопросами по SQL средней и высокой сложности, чтобы лучше готовиться к собеседованиям. Этот справочник очень пригодился в последнем цикле собеседований 2019 года. За последний год я поделился этим руководством с парой друзей, а благодаря дополнительному свободному времени из-за пандемии отшлифовал его — и составил этот документ.

Есть множество отличных руководств по SQL для начинающих. Мои любимые — это интерактивные курсы Codecademy по SQL и Select Star SQL от Цзы Чон Као. Но в реальности первые 70% из курса SQL довольно просты, а настоящие сложности начинаются в остальных 30%, которые не освещаются в руководствах для начинающих. Так вот, на собеседованиях для аналитиков данных и специалистов по анализу данных в технологических компаниях часто задают вопросы именно по этим 30%.

Удивительно, но я не нашёл исчерпывающего источника по таким вопросам среднего уровня сложности, поэтому составил данное руководство.

Осенью прошлого года в московском офисе Яндекса прошла первая Школа бэкенд-разработки. Мы сняли занятия на видео и сегодня рады поделиться на Хабре полным видеокурсом Школы. Он позволит вам научиться промышленной разработке на Python. Авторы лекций — опытные разработчики в Яндексе. К каждому видео приложены ссылки на примеры и полезные материалы.

Для изучения курса нужно знать основы Python и понимать, как приложения развёртываются на серверах. Мы ждём, что вы умеете делать запросы к базам данных и знаете, как создаются веб‑приложения, — хотя бы на начальном уровне.

Мы в фирме 1С широко используем собственные разработки для организации работы компании. В частности, «1С:Документооборот 8». Помимо управления документами (как следует из названия) это ещё и современная ECM-система (Enterprise Content Management — управление корпоративным контентом) с широким набором функциональных возможностей – почта, рабочие календари сотрудников, организация совместного доступа к ресурсам (например, бронирование переговорных), учёт рабочего времени, корпоративный форум и многое другое.

В фирме 1С документооборотом пользуется более тысячи сотрудников. База данных стала уже внушительной (11 млрд. записей), а это значит, что она требует более тщательного ухода и более мощного оборудования.

Как устроена работа нашей системы, с какими сложностями при обслуживании базы мы сталкиваемся и как их решаем (в качестве СУБД мы используем MS SQL Server) – расскажем в статье.

Для тех, кто впервые читает про продукты 1С.
1С:Документооборот — это прикладное решение (конфигурация), реализованное на базе фреймворка для разработки бизнес-приложений — платформе 1С:Предприятие.

Привет, Хабр! Сегодня мы продолжаем нашу классическую серию статей про то, как с использованием методов обработки изображений и распознавания образов сделать что-то полезное с практической точки зрения. Сегодня речь пойдет о задаче распознавания ценников. Обычных ценников товаров, которые каждый может встретить в любом магазине. Только для обеспечения должной практичности мы добавим важное требование в постановку задачи: распознаваемые изображения получают при помощи малоформатной цифровой камеры, а вычислительное устройство имеет существенные ограничения по ресурсам. Другими словами, мы расскажем, как распознавать ценники на вычислительно слабом мобильном устройстве (кстати, здесь речь идет не столько о дешевом китайском смартфоне, сколько о специальных промышленных терминалах сбора данных, которые в силу ряда причин тоже обладают достаточно слабыми “мозгами”). Итак, если Вам интересна тема автоматизации ритейла, добро пожаловать под кат!

У каждого сотрудника Леруа Мерлен есть корпоративный телефон. Там два слота под симки: один — под корпоративную с пакетом в 100 минут и трафиком для корпоративных приложений и 3 Гб на мобильный интернет-трафик, во второй можно втыкать личную. На телефонах — мессенджеры, соцсети, личные звонки и корпоративный EMM с двумя десятками корпоративных же приложений. То есть если надо сказать что-то сотруднику в магазине, то он получит сообщение в Ватсапе. Заболел ребёнок — тоже жена дозвонится в рабочее время.

А я расскажу про то, как мы это внедряли. Потому что есть там несколько неочевидных моментов вроде того места, где вся эта прорва телефонов вдруг решит одновременно ломануться за обновлением.

Я с командой провела исследование на 1000 человек про то, можно ли перенести наши основные процессы в мобильность, тогда ещё было не ясно нужен нам терминал или телефон. И если да — какой он должен быть. Будут ли сотрудники использовать свой личный телефон или устройство должно быть предоставлено компанией? Какой личный аппарат сейчас у сотрудника? После этого мы смотрели на мировые практики. В итоге выбор пал в сторону телефона от компании, чтобы не поддерживать зоопарк устройств. Телефон — потому что устройство должно быть у каждого в руках и доступно в любой момент, что нельзя обеспечить с терминалом.

В жизни каждого аналитика и программиста наступает такой день, когда он узнает о существовании шаблонов (паттернов) проектирования XML-схем и его жизнь меняется. Для меня, например, с этого знания началось постижение красоты проектирования.

Сегодня хочу поговорить о том, какие есть шаблоны проектирования XSD, о преимуществах и недостатках каждого, и почему мы для своих задач выбрали «Райский сад».

Недавно у наших добрых друзей из крупной розничной сети возникла задача ускорения поиска в 1С.

Во-первых, искать нужно было по клиентам (три справочника, 9 текстовых полей, поиск типа %like%) и всего-то по 2,5 млн записей. Сразу скажем, что полнотекстовый поиск и морфология — это пока не про Tarantool. В результате ряда экспериментов мы остановились на ElasticSearch, но т.к. он не в тему статьи, то можем написать отдельную, если будет интерес. Скажем только, что скорость выросла на порядок по сравнению с тем, что мы могли выжать из полнотекстового поиска MS SQL.

Во-вторых, нужен был поиск и подбор по товарам с выводом остатков по всем складам без дополнительных запросов. Скорость поиска должна была быть сопоставима с обычным откликом интерфейса, то есть около 0,2 сек вместо текущих 5-12 секунд в 1С (в зависимости от уровня нагрузки). 90 тысяч строк, список номенклатур меняется не часто, примерно по 10-50 позиций в день.

Exchange — обменник или точка обмена. В него отправляются сообщения. Exchange распределяет сообщение в одну или несколько очередей. Он маршрутизирует сообщения в очередь на основе созданных связей (bindings) между ним и очередью.

Exchange не является Erlang-процессом. Из соображений масштабируемости exchange — это строка (ссылка на модуль с кодом, где лежит логика маршрутизации) во встроенной базе данных mnesia. 1 тысяч обменников будут потреблять всего 1МБ памяти.

Много строк исписано про интеграцию Телеграма и 1С. Но нигде не увидел полной инструкции по установке и настройке вебхуков. Попробую её написать.

Для всего этого нам понадобится (или правильнее будет сказать, что было использовано мной):

1. Apache 2.2.24
2. OpenSSL (входящий в установку апача)
3. 1C (с модулями веб-сервера)
4. Свой домен
5. Созданный бот в Телеграм (не буду описывать его создание, т.к. оно достаточно тривиально)

Предполагается, что весь софт у вас установлен.

Очереди сообщений используются для выполнения: отложенных операций, взаимодействия сервисов между собой, «batch processing» и т.д. Для организации подобных очередей существуют специализированные решения, такие как: RabbitMQ, ActiveMQ, ZeroMQ и тд, но часто бывает, что в них нет большой необходимости, а их установка и поддержка причинит больше боли и страданий, чем принесет пользы. Допустим, у вас есть сервис, при регистрации в котором пользователю отправляется email для подтверждения, и, если вы используете Postgres, то вам повезло — в Postgres, почти из коробки, есть расширение PgQ, которое сделает всю грязную работу за вас.

В этой статье я расскажу об организации очередей сообщений (задач) в PostgreSQL с использованием расширения PgQ. Эта статья будет полезна, если вы еще не использовали PgQ или используете самописные очереди поверх Postgres.

Зачем вообще нужен PgQ, если можно просто создать табличку и записывать туда задачи? Казалось бы, можно, но вам придется учесть паралельный доступ к задачам, возможные ошибки (что будет, если процесс обрабатывающий задачу, упадет?), а также производительность (PgQ очень быстрый, а самописные решения, как правило, нет, особенно если транзакция в базе не закрывается во время всего выполнения задачи), но самое главное, почему на мой взгляд надо использовать PgQ, это то, что PgQ уже написан и работает, а самописное решение еще надо написать (UPD: про то, почему не стоит использовать самописные очереди, можно почитать, например, тут).
(UPD: т.к. PgQ работает поверх Postgres, все прелести транзакций можно использовать и в нем)

Но у PgQ есть один огромный минус — отсутствие документации, этот недостаток я и пытаюсь компенсировать этой статьей.

Этой статьи не должно было быть: вроде как и Хабр не жалобная книга, и у меня частная история далеко не хабровской компании. Но именно на Хабре я получил не очень корректное отношение одной компании и познакомился аж с двумя другими в самый подходящий момент — в момент, когда я искал хелпдеск. Я протестировал и перебрал 15 разных хелпдеск-систем и не смог выбрать из них ни одну! Уже прочувствовали всю драму? Рано! В общем, я перекипел, выпустил пар, заставил потестировать своих коллег, немного выдохнул и решил не бомбить на эмоциях, а написать текст — о том, как требования могут соотноситься с ПО и о том, что разработчики иногда несколько оторваны от реальности. Хотя без эмоций не получится, потому что я был по обе стороны софта: и заказчиком, и разработчиком, а значит, понимаю обоих. Но никого не хочу оправдывать. Простите, если будет лонгрид. Может и лонг, но зато экшен!

Duran (вроде бы)

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

Следом за ТСД, на рынок мобильных устройств пришли смартфоны, которые в значительной мере превзошли существующие терминалы, как в аппаратной части, так и в функциональных возможностях операционных систем. Лишь относительно недавно, терминалы сбора данных получили ОС Android, однако их стоимость совершенно не сопоставима со стоимостью смартфонов.

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

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

Нарастающий (накопительный) итог долго считался одним из вызовов SQL. Что удивительно, даже после появления оконных функций он продолжает быть пугалом (во всяком случае, для новичков). Сегодня мы рассмотрим механику 10 самых интересных решений этой задачи – от оконных функций до весьма специфических хаков.

Привет, Хабр! Представляю вашему вниманию перевод статьи «JavaScript Async/Await and Promises: Explained like you’re five years old» автора Jack Pordi.

Каждый, кто считает себя JavaScript-разработчиком, в какой-то момент должен был столкнуться с callback-функциями, промисами или, с недавних пор, с синтаксисом async/await. Если вы пробыли в игре достаточно долго, вы, вероятно, застали времена, когда вложенные callback-функции были единственным способом достижения асинхронности в JavaScript.

Когда я начал изучать и писать на JavaScript, уже существовало миллиард руководств и туториалов, объясняющих, как добиться асинхронности в JavaScript. Тем не менее, многие из них просто объясняли, как преобразовать callback-функции в промисы или промисы в async/await. Для многих этого, вероятно, более чем достаточно, чтобы они «поладили» с ними и начали использовать их в своем коде.

Однако если вы, как я, действительно хотите понять асинхронное программирование (а не только синтаксис JavaScript!), то, возможно, вы согласитесь со мной, что существует нехватка материалов, объясняющих асинхронное программирование фактически с нуля.

Руководство для абсолютных чайновичков.
(Прим. пер.: это советы от автора-индуса, но вроде дельные. Дополняйте в комментах.)



Месяц — это много времени. Если тратить на обучение по 6-7 часов каждый день, то можно сделать дофига.

Цель на месяц:

• Ознакомиться с основными понятиями (переменная, условие, список, цикл, функция)
• Освоить на практике более 30 проблем программирования
• Собрать два проекта, чтобы применить на практике новые знания
• Ознакомиться хотя бы с двумя фреймворками
• Начать работу с IDE (средой разработки), Github, хостингом, сервисами и т. д.

Так вы станете младшим разработчиком (джуном) Python.

Теперь план по неделям.

Продолжение перевода небольшой книги:
«Understanding Message Brokers»,
автор: Jakub Korab, издательство: O'Reilly Media, Inc., дата издания: June 2017, ISBN: 9781492049296.

Предыдущая часть: Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka. Глава 1. Введение

Необходимое вступление

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

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

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL

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

Вот почему это руководство по SQL предоставит вам небольшой обзор некоторых шагов, которые вы можете пройти, чтобы оценить ваш запрос:

• Во-первых, вы начнете с краткого обзора важности обучения SQL для работы в области науки о данных;
• Далее вы сначала узнаете о том, как выполняется обработка и выполнение запросов SQL, чтобы понять важность создания качественных запросов. Конкретнее, вы увидите, что запрос анализируется, переписывается, оптимизируется и окончательно оценивается.
• С учетом этого, вы не только перейдете к некоторым антипаттернам запросов, которые начинающие делают при написании запросов, но и узнаете больше об альтернативах и решениях этих возможных ошибок; Кроме того, вы узнаете больше о методическом подходе к запросам на основе набора.
• Вы также увидите, что эти антипаттерны вытекают из проблем производительности и что, помимо «ручного» подхода к улучшению SQL-запросов, вы можете анализировать свои запросы также более структурированным, углубленным способом, используя некоторые другие инструменты, которые помогают увидеть план запроса; И,
• Вы вкратце узнаете о time complexity и big O notation, для получения представления о сложности плана выполнения во времени перед выполнением запроса;
• Вы кратко узнаете о том, как оптимизировать запрос.

Когда я разговариваю с Linux инженерами и говорю им о проблемах Kubernetes кластера на Windows, на меня смотрят очень подозрительно. Некоторые даже не верят что это законно такое бывает. Контейнеры на Windows не так распространены и востребованы, как на Linux. Но я думаю, что поговорить об этой теме стоит, хотя бы для того, что бы понимать общую концепцию и основные отличия контейнеров Windows и Linux. Первой записью я пройдусь по полотну широкой кистью, а затем, в последующих постах, попробую постепенно углубиться в нюансы.

Недавно в одном стартапе я решал задачу генерации билетов в формате PDF. На тот момент уже был готов сайт с устоявшимся стеком технологий, поэтому я искал подход, который бы не потребовал использования дополнительных инструментов. В итоге я предложил сперва создавать билеты в формате HTML, а затем конвертировать в PDF с помощью браузера Chrome. Как оказалось, данным способом можно генерировать не только билеты, богато декорированные CSS, но и самые разные отчеты с графиками на JavaScript. В этой статье я расскажу о том, как для этих целей запустить Chrome, дам несколько советов по настройке CSS, а так же обсужу недостатки данного решения.