До того, как начать работать с SQL Server я толком то и баз данных в лицо не видел… Помню, что мне установили SQL Server Management Studio 2005 и дали задание активно «крутить педали». По прошествии пары недель, как бы так сказать, моя производительность по написанию запросов была явно в районе плинтуса…

Более опытный коллега с недоумением на меня посмотрел и посоветовал поставить пару плагинов для SSMS… после этого работать стало явно веселее.

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

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

В этой обзорной статье я рассмотрю следующие понятия, методы и алгоритмы:

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

Недавно передо мной встала следующая задача: необходимо сравнить множество пар объектов. Но есть один нюанс: объекты — самые что ни на есть object'ы, а сравнивать нужно по всему набору публичных свойств. Причём совершенно необязательно, что типы сравниваемых объектов реализуют интерфейс IEquatable<T>.

Было очевидно, что следует использовать рефлексию. Однако при реализации я столкнулся со множеством тонкостей и в конечном счёте прибегнул к чёрной магии динамической генерации IL. В этой статье я хотел бы поделиться опытом и рассказать о том, как я решал эту задачу. Если Вас заинтересовала тема, то прошу под кат!

Автор оригинала на английском языке — хабраюзер dzeban

Введение

В прошлый раз мы обсудили, как можно искусственно ограничить доступную программе память. В качестве бонуса я заполучил себе libmemrestrict – библиотеку с обёртками функций вроде malloc для отслеживания использования памяти, и ptrace-restrict — инструмент на базе ptrace, перехватывающий вызовы brk, sbrk и mmap с той же целью.

Так зачем нам пытаться организовывать ограничение памяти – так ли это часто встречается? Когда в последний раз ООМ прибил ваше приложение? Вы всегда думаете о потреблении памяти во время программирования? Память – штука дешёвая, и если вам не хватает памяти, добавьте ещё пару гигабайт.

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

И вот я занялся подобными задачами, начав с простой – как отсортировать миллион целых чисел (4 MiB данных) при наличии 2 MiB памяти? Эту задачу можно обобщить на тот случай, когда у вас недостаточно памяти, чтобы вместить все данные.

Дано

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

Программа должна выдавать отсортированный массив на stdout в виде текста

Она должна измерить время работы и вывести его на stderr. Нельзя просто запустить программу через утилиту time, потому что она посчитает время на чтение файла и время на его вывод.

Она должна работать, имея памяти как минимум в два раза меньше объёма файла. Для этого мы применим libmemrestrict или ptrace-restrict.

Для некоторых методов эти утилиты не пригодятся. Например, для mmap они не сработают – придётся физически ограничить использование памяти.

Они будут проверяться для решения оригинальной задачи (сортировки 4 MiB в 2 MiB). Также я запущу их на виртуалке со 128 MiB памяти для сортировки 500 Mb (125 миллионов четырёхбайтных целых).

Приветствуем в первой статье из серии Windows 10 по 10. Мы начнем серию с того, откуда начинается ваше взаимодействие с пользователями — с магазина Windows Store.



Чтобы убедиться, что ваши приложения находятся и запускаются пользователями Windows 10, рекомендуем проделать три упражнения прямо сейчас:

1. Обновить описание в магазине для повышения шансов приложения быть установленным.
2. Начать отслеживать использование приложения с помощь Visual Studio Application Insights и новых отчетов об использовании.
3. Научиться использовать новые возможности магазина для отслеживания успешности проводимых кампаний.

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

В стремлении к быстрому сайту многие разработчики упускают один важный момент: клиентскую (фронтендную) точку отказа (frontend SPOF – single point of failure). Причем, почти все инструменты тестирования скорости загрузки сайта также не выявят потенциальных проблем.

Примеры найденных жучков (источник фото: Интернет)

Дело было еще во Владивостоке.
Знакомые, владельцы турфирмы, рассказали, что однажды уборщица их спросила: «А почему вечером, когда все уходят, у вас сверху, на шкафу что-то мигает?». Полезли на шкаф, а там — чуть ли не автомобильный аккумулятор и рация, прикрученная синей изолентой. Вот такой суровой бывала дальневосточная прослушка.

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

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

Литий-ионные аккумуляторы не столь «привередливы», как их никель-металл-гидридные собратья, но все равно требуют определенного ухода. Придерживаясь пяти простых правил, можно не только продлить жизненный цикл литий-ионных аккумуляторных батарей, но и повысить время работы мобильных устройств без подзарядки.

Не допускайте полного разряда. У литий-ионных аккумуляторов отсутствует так называемый эффект памяти, поэтому их можно и, более того, нужно заряжать, не дожидаясь разрядки до нуля. Многие производители рассчитывают срок жизни литий-ионного аккумулятора количеством циклов полного разряда (до 0%). Для качественных аккумуляторов это 400-600 циклов. Чтобы увеличить срок службы вашего литий-ионного аккумулятора, чаще заряжаете свой телефон. Оптимально, как только показатель заряда батареи опустится ниже отметки 10-20 процентов, можете ставить телефон на зарядку. Это увеличит количество циклов разряда до 1000-1100.
Данный процесс специалисты описывают таким показателем как Глубина Разряда (Depth Of Discharge). Если ваш телефон разряжен до 20%, то Глубина Разряда составляет 80%. В нижеприведенной таблице показана зависимость количества циклов разряда литий-ионного аккумулятора от Глубины Разряда:


Разряжайте раз в 3 месяца. Полный заряд на протяжении длительного времени также же вреден для литий-ионных аккумуляторов, как и постоянная разрядка до нуля.

«Инструкция создания функционального приложения», часть 1.

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

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

Это краткое введение в криптографию под .NET для чайников, как и следует из заголовка. Здесь будут простые вещи и никаких углубленных знаний.

Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

Мнение переводчика может иногда не совпадать с мнением автора, но переводить статью было крайне занимательно.

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

После моего недавнего выступления на MoscowJS #17 с одноимённым докладом у многих возник интерес к этому инструменту. В рамках 11-го выпуска RadioJS, Миша Башкиров bashmish рассказал, что решился попробовать его в своём новом проекте, об успешном опыте и множестве положительных эмоций. Но были озвучены вопросы и возникла дискуссия, в результате которой я решил написать эту статью, чтобы раскрыть основные тезисы с доклада и рассказать о том, что тогда не успел.
Статья ориентирована, как на профессионалов, так и на тех, кто с похожими технологиями ещё не сталкивался.
Итак, начнём.

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

Вот другая задача. Кэширование социальных данных, которых скапливаются сотни миллионов за 2-3 недели, а обслуживать необходимо десятки тысяч read-запросов в секунду.

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

Приходится прибегать к кластеризации: несколько серверов объединяются в кластер; нагрузка между ними распределяется при помощи комплекса специальных методов, называемых балансировкой. Помимо решения проблемы высоких нагрузок кластеризация помогает также обеспечить резервирование серверов друг на друга.
Эффективность кластеризации напрямую зависит от того, как распределяется (балансируется) нагрузка между элементами кластера.

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

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

Как и в любом деле в Интернет есть свои невидимые и незаметные работники, ежедневно, ежечасно… ежемиллисекундно выполняющие свои незамысловатые рутинные операции. Это конечно же маршрутизаторы, коммутаторы и другие устройства доставляющие пакеты данных из одной точки в другую. В них есть собственные регулировщики загрузки, перенаправляющие потоки другим путем в случае образования заторов. Но откуда они все знают куда доставить эти пакеты? Знающий человек скажет — «так там указан IP-адрес» и будет прав. Но обычный веб-серфер, как правило и представления не имеет об IP адресах, но тем не менее несколько миллиардов простых веб-серферов вполне себе успешно «бороздят» Интернет. Такую возможность им, да и «лицо» современной сети Интернет определяет другой «умпа-лумп» — служба DNS.

Недавно на Хабре промелькнула интересная задачка про двух мудрецов. Здесь я хочу предложить свой вариант решения и рассказать, как к этому решению можно прийти. Напомню условие:

У некоторого султана было два мудреца: Али-ибн-Вали и Вали-ибн-Али. Желая убедиться в их мудрости, султан призвал мудрецов к себе и сказал: «Я задумал два числа. Оба они целые, каждое больше единицы, но меньше ста. Я перемножил эти числа и результат сообщу Али и при этом Вали я скажу сумму этих чисел. Если вы и вправду так мудры, как о вас говорят, то сможете узнать исходные числа».
Султан сказал Али произведение, а Вали – сумму. Мудрецы задумались. Первым нарушил молчание Али.
— Я не знаю этих чисел, — сказал он, опуская голову.
— Я это знал, — подал голос Вали.
— Тогда я знаю эти числа, — обрадовался Али.
— Тогда и я знаю! — воскликнул Вали.
И мудрецы сообщили пораженному султану задуманные им числа.
Назовите эти числа.

Ни для кого не секрет, что современные социальные сети представляют собой огромные БД, содержащие много интересной информации о частной жизни своих пользователей. Через веб-морду особо много данных не вытянешь, но ведь у каждой сети есть свой API… Так давай же посмотрим, как этим можно воспользоваться для поиска пользователей и сбора информации о них.

Есть в американской разведке такая дисциплина, как OSINT (Open source intelligence), которая отвечает за поиск, сбор и выбор информации из общедоступных источников. К одному из крупнейших поставщиков общедоступной информации можно отнести социальные сети. Ведь практически у каждого из нас есть учетка (а у кого-то и не одна) в одной или нескольких соцсетях. Тут мы делимся своими новостями, личными фотографиями, вкусами (например, лайкая что-то или вступая в какую-либо группу), кругом своих знакомств. Причем делаем это по своей доброй воле и практически совершенно не задумываемся о возможных последствиях. На страницах журнала уже не раз рассматривали, как можно с помощью различных уловок вытаскивать из соцсетей интересные данные. Обычно для этого нужно было вручную совершить какие-то манипуляции. Но для успешной разведки логичнее воспользоваться специальными утилитами. Существует несколько open source утилит, позволяющих вытаскивать информацию о пользователях из соцсетей.

Хабр, привет.

Не так давно SLY_G опубликовал цикл переводов книги Eloquent Javascript (за что ему большое спасибо). В комментариях раз за разом поднимались вопросы о сборке переводов книги, что, собственно, я и сделал при помощи сервиса Gitbook — «Выразительный Javascript», pdf, ePub, mobi и онлайн версия.

Репозитарий книги, pull requests принимаются.

Открытые вакансии на должность разработчика в Яндексе есть всегда. Компания развивается, и хороших программистов не хватает постоянно. И претендентов на эти должности тоже хоть отбавляй. Главная сложность – отобрать действительно подходящих кандидатов. И в этом плане Яндекс мало чем отличается от большинства крупных IT-компаний. Так что базовые принципы, описываемые в этой статье, могут быть применимы не только к Яндексу.

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

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



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