Этот материал мы подготовили для JavaScript-программистов, которые только начинают разбираться с «Promise». Обещания (promises) в JavaScript – это новый инструмент для работы с отложенными или асинхронными вычислениями, добавленный в ECMAScript 2015 (6-я версия ECMA-262).

Автор: Юрий Цыганенко, Senior QA

Тестирование новых функций часто проводят на данных, взятых с уже функционирующей системы. В этом случае тестировщикам порою приходится строить запросы для хитрых случаев. Например, нужно протестировать новую функциональность интернет-магазина, причём играют роль интервалы между покупками. Нам доступны данные с работающей версии — можно загрузить их на тестовый стенд и проверить работу новой версии продукта. (NB!: конечно, имея дело с «живыми» данными, нужно исключить из них приватную информацию и обеспечить возможность логина интересующим нас пользователям).

Для выбора интересных нам пользовательских аккаунтов нужно сопоставить максимальные интервалы между покупками у разных пользователей.

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

Аналогичные задачи и их разбор — под катом.

Как устроена MySQL-репликация

Андрей Аксенов (Sphinx), shodan

Мой доклад предназначен для тех людей, которые знают слово «репликация», даже знают, что в MySQL она есть, и, возможно, один раз ее настроили, 15 минут потратили и забыли. Больше про нее они не знают ничего.

Мы немного пройдемся по теории, попытаемся объяснить, как это все работает внутри, а после этого вы с утроенными силами сможете сами нырнуть в документацию.

Что такое репликация, в принципе? Это копирование изменений. У нас есть одна копия БД, мы хотим с какой-то целью еще одну копию.

Репликация бывает разных видов. Разные оси сравнения:

• степень синхронизации изменений (sync, async, semisync);
• количество серверов записи (M/S, M/M);
• формат изменений (statement-based (SBR), row-based (RBR), mixed);
• теоретически, модель передачи изменений (push, pull).

Давайте представим, что вас перевели на новый проект. Или вы сменили работу и о проекте максимум только слышали. Вот вы садитесь за рабочее место, к вам приходит менеджер, жмёт руку и… прямо сходу открывает страницу проекта, тыкает пальцем в монитор и просит вставить «информер о предстоящем событии Х». На этом вы расстаётесь… Что делать? С чего начать? Как создать «информер»? Где найти нужный шаблон? И море других вопросов.

Под катом будет рассказ, как мы стараемся организовать эти процессы, какие инструменты создаём для препарирования SPA. Кроме этого, мы поговорим о технических подробностях реализации Live Coding / Hot Reload и чуток о VirtualDom и React с Angular.

Селекторы имеют очень важное значение. Большинство JQuery методов требуют выбора элементов для использования. К примеру, перед тем как прикрепить событие click к кнопке, нужно выбрать саму кнопку.

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

Давайте перейдем к списку!

Иногда при разработке программного обеспечения требуется встроить дополнительную функциональность в уже существующие приложения без модификации исходного текста приложений. Более того, зачастую сами приложения существуют только в скомпилированном бинарном виде без наличия исходного текста. Широко известным способом решения указанной задачи является т.н. “сплайсинг” – метод перехвата функций путем изменения кода целевой функции. Обычно при сплайсинге первые байты целевой функции перемещаются по другим адресам, а на их исходное место записывается команда безусловного перехода (jmp) на замещающую функцию. Поскольку сплайсинг требует низкоуровневых операций с памятью, то он осуществляется с использованием языка ассемблера и С/C++, что также накладывает определенные ограничения на реализацию замещающих функций – они обычно также реализованы на С/C++ (реже на ассемблере).

Метод сплайсинга для перехвата API-функций в Windows широко описан в Интернете и в различных литературных источниках. Простота указанного перехвата определяется следующими факторами:

1. целевая функция является статической – она сразу присутствует в памяти загруженного модуля;
   
2. адрес целевой функции легко определить (через таблицу экспорта модуля или функцию GetProcAddress).
   

Реализация замещающих функций на C/C++ при перехвате API-функций является оптимальным вариантом, поскольку Windows API реализовано, как известно, на языке C, и замещающие функции могут оперировать теми же понятиями, что и заменяемые.

Дорога длинна и трудна, но интересна и полезна!

Статья задумывалась как практическое руководство для желающих стать профессиональным веб-разработчиком. Я уже более 20 лет пишу код для веба. Я ежедневно работаю с веб-разработчиками и помогаю им. В статье я опишу, что вам нужно выучить, когда вам нужно это выучить и где взять информацию (чаще всего даже бесплатно). Затем я дам совет по получению реального опыта, и что самое важное – по получению денег за написание кода.

По статье разбросано множество ссылок на бесплатные и важные ресурсы. Для простоты я собрал их в PDF и разбил по категориям. Мне не платят за упоминания сайтов, ссылки на которые я привёл – я всего лишь хочу порекомендовать вам лучшие ресурсы, чтобы помочь вам достичь вашей цели.

Что нужно помнить:

1. Статью разрешается пролистывать

Руководство может помочь вам вне зависимости от вашего положения на дороге к профессиональной разработке. Прокрутите его к тому заголовку, который лучше всего описывает ваше сегодняшнее положение, и читайте оттуда. Если вы только начали этот путь, или пока размышляете об этом – последуйте совету Короля из «Алисы в стране чудес»:

Начните с начала, и продолжайте, пока не дойдёте до конца; и там уже остановитесь.

Все фотографии в этой статье взяты из трилогии Кристофера Нолана «Тёмный рыцарь». Это всё же Бэтмен!

Давайте сыграем!

При подготовке вы хорошо поработали с телефоном. Интервью в офисе этим утром проходили занятно. После общего обеда сотрудник отдела кадров сел за стол напротив вас. Он спросил: «Какую зарплату вы бы хотели?».

Что вам делать? Что же вам делать?!

Что бы вы ни делали, не называйте ему конкретную цифру. Как только у него появится цифра, он сможет задать тон при продолжении переговоров. Эта цифра будет потолком — самое высокое предложение, которое вы сможете получить на этом месте. Но, скорее всего, вы получите меньше.

Или, возможно, он попробует другой подход, чтобы подтолкнуть вас назвать цифру: «Какая зарплата у вас сейчас?».

Этот вопрос звучит вполне резонно. Разве не надо отвечать на этот вопрос?

Какая-то «не здоровая пьянка» пошла последнее время на хабре про собеседования. Люди, хватит уже, нет ничего страшного и особенного в собеседованиях, я уже несколько лет провожу их с IT-шниками, и в 95% случаев это адекватные и приятные люди. Потому хочу поделиться с вами «дзеном» о том, как лучше проводить именно техническое собеседование, да и вообще оценивать навыки тех. специалистов, так как вопрос оценки компетентности технического специалиста может быть довольно сложным, особенно если вы не хотите проводить собеседование на 3 часа к ряду. С данной моделью вы вполне можете уложить тех. собеседование в 40-50 минут (а то и быстрее) и быть уверенным в решении на 80-90%. Если про оценку эмоционального интеллекта, базовой мотивации и просто уровня адекватности, информации довольно много, то вот про то, как эффективно оценивать технические навыки специалиста, зачастую, «кто в лес, кто по дрова». Данная статья может быть также полезна и тем, кто просто хочет эффективно расти как специалист, потому как именно их знания и рассматриваются.

Оказывается, в свободном доступе есть интересная информация от HeadHunter о повышении фонда оплаты труда (ФОТ) в 2015 году. Со страницы проекта "Банк данных заработных плат" идет ссылка "Сравнивайте зарплаты вашей компании с рынком".

Прямая ссылка на pdf: Зарплаты в России. Итоги 2015 года.


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

И вообще, многим придут на ум уже затертые шаблоны:

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

Но эти выводы и советы слишком уж лежат на поверхности.
We need to go deeper.
Давайте посмотрим, насколько же глубока эта не кроличья нора…

Уже через две с половиной недели в Питере пройдет большая .NET-конференция DotNext.

Предыдущая конференция DotNext прошла в декабре в Москве. В этом посте я, по уже сложившейся традиции, расскажу о ее лучших докладах (по мнению участников).

Конференцию посетило около 450 человек, и еще около 100-150 смотрели ее онлайн. Свои отзывы нам оставили более 400 человек — это около 70% участников. Такой процент позволяет нам говорить о том, что наша выборка релевантна, а рейтинг — довольно объективен.

10 место

Александр ControlFlow Шведов, JetBrains — Дизайн и эволюция C# на примере свойств
Средняя оценка: 4.41



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

Обработка ошибок в JavaScript — дело рискованное. Если вы верите в закон Мёрфи, то прекрасно знаете: если что-то может пойти не так, именно это и случится! В этой статье мы рассмотрим подводные камни и правильные подходы в сфере обработки ошибок в JS. А напоследок поговорим об асинхронном коде и Ajax.

Я считаю, что событийная парадигма JS добавляет языку определённое богатство. Мне нравится представлять браузер в виде машины, управляемой событиями, в том числе и ошибками. По сути, ошибка — это невозникновение какого-то события, хотя кто-то с этим и не согласится. Если такое утверждение кажется вам странным, то пристегните ремни, эта поездка будет для вас необычной.

Все примеры будут рассмотрены применительно к клиентскому JavaScript. В основу повествования легли идеи, озвученные в статье «Исключительная обработка событий в JavaScript». Название можно перефразировать так: «При возникновении исключения JS проверяет наличие обработчика в стеке вызовов». Если вы незнакомы с базовыми понятиями, то рекомендую сначала прочитать ту статью. Здесь же мы будем рассматривать вопрос глубже, не ограничиваясь простыми потребностями в обработке исключений. Так что когда в следующий раз вам опять попадётся блок try...catch, то вы уже подойдёте к нему с оглядкой.

С момента появления тасков в .NET прошло почти 6 лет. Однако я до сих пор вижу некоторую путаницу при использовании Task.Run() и Task.Factory.StartNew() в коде проектов. Если это можно списать на их схожесть, то некоторые проблемы могут возникнуть из-за dynamic в C#.

В этом посте я попытаюсь показать проблему, решение и истоки.

Проблема

Пусть у нас есть код, который выглядит так:

static async Task<dynamic> Compute(Task<dynamic> inner)
{
    return await Task.Factory.StartNew(async () => await inner);
}

Вопрос знатокам: есть ли в данном примере проблема? Если да, то какая? Код компилируется, возвращаемый тип Task на месте, модификатор async при использовании await — тоже.

Думаете, речь идет о пропущенном ConfigureAwait? Хаха!

В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

Вообще многие говорят о CQRS как о паттерне проектирования. На мой взгляд он слишком сильно влияет на общую архитектуру приложения, что бы называться просто “паттерном проектирования”, поэтому я предпочитаю называть его принципом или подходом. Использование CQRS проникает почти во все уголки приложения.

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS

Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

Описание системы

Большинство продуктов Тинькофф Банка создаются полностью силами наших разработчиков. Один из таких продуктов — система Pds (predictive dialing system). Pds – это робот, который обзванивает клиентов вместо операторов. Причем, если клиент ответил, звонок переводится на оператора. Если клиент не ответил, робот фиксирует неуспешный звонок.

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

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

Архитектура системы схематично представлена на риcунке.

В известной игре «Казаки: Снова Война» присутствует баг, сводящий удовольствие от сетевой игры к нулю: Нечеловеческая скорость игрового процесса на современных компьютерах. При этом изменение скорости игры в настройках, прекрасно работающее в режиме одиночной игры, никак не влияет на происходящее в игре по сети. Этот вопрос обсуждается на множестве форумов, но самые популярные советы это:

1. Искусственно загрузить ядро процессора, на котором запущена игра
2. Запускать игру в виртуальной машине с ограниченными ресурсами
3. Играть не по локальной сети, а по интернету — там задержки побольше

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

Если вы из тех, кто «работал ещё Там-То!» и «делал ещё То-То!», а сейчас счастливо отдыхаете на пенсии — эта статья не для вас. Просто спасибо за труд и примите мои поздравления. Но если же вы, как и я, даже став немного старше всё ещё ощущаете страсть к программированию, радуетесь виду кода и не можете устоять перед желанием написать ещё что-нибудь, тогда продолжайте читать.

Большую часть моей жизни я проработал разработчиком программного обеспечения. Но однажды, уже под конец моего четвёртого десятка, я попался на удочку предпринимательской наживы. Я тогда поверил, что создавать собственные компании — это круто. Я нашел немного венчурного капитала и организовал пару небольших стартапов для реализации собственных идей. И вот я стал, как мне казалось, нормальным CEO и не таким уж плохим менеджером. И, хотя я уже не писал код лично, я мог нанимать хороших программистов, управлять качеством проектов и внедрением инноваций.

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.