Информационный портал по безопасности

Хотите внедрить или доработать функцию поиска? Вам сюда.

Спросите разработчика: «Как бы вы реализовали функцию поиска в своем продукте?» или «Как создать поисковую систему?». Вероятно, в ответ вы услышите что-нибудь такое: «Ну, мы просто запустим кластер Elasticsearch: с поиском сегодня всё просто».



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



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

Цель статьи

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



Основываясь на опыте работы с универсальными решениями и узкоспециализированными проектами самого разного масштаба (в компаниях Google, Airbnb и нескольких стартапах), я расскажу о некоторых популярных подходах, алгоритмах, методах и инструментах.



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



Переведено в Alconost

Доброго времени суток! У нас открылось совершенно новое направление обучения — BigData, а это значит, что немного расширяется горизонт материалов, которыми мы будем делиться с вами. Сегодня рассмотрим Luigi, как часть того, что раскрывается на нашем курсе.



Luigi — фреймворк на языке Python для построения сложных последовательностей по выполнению зависимых задач. Довольно большая часть фреймворка направлена на преобразования данных из различных источников (MySql, Mongo, redis, hdfs) и с помощью различных инструментов (от запуска процесса до выполнения задач разных типов на кластере Hadoop). Разработан в компании Spotify и открыт в виде open source инструмента в 2012 году.



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



Для выполнения всех этих задач существуют и другие инструменты. Это Oozie, Pinball, Airflow (находится в статусе инкубации в Apache — проходит различные проверки, недавно вышел обзор на хабре). В данной статье рассмотрим только Luigi.

Последние десять дней Хабр с подачи aleshqqa1337 обсуждает ИТ-образование. Публикуем заметку преподавателя, работающего в техническом вузе, о том, как разрабатывалась программа новой дисциплины «Системы электронного документирования и коллективной работы», по каким критериям выбиралось ПО для обучения и какие задания выполняют студенты.



Автор — Стремнев Александр Юрьевич, к.т.н., доцент кафедры информационных технологий, Белгородский государственный технологический университет им. В.Г. Шухова.

Цель: Предоставить инструкцию по сборке динамического модуля, дать понимание принципа сборки динамического модуля для Nginx поставленного из репозитория Debian.



Целевая аудитория: Администраторы серверов, продвинутые администраторы сайтов, сео-оптимизаторы и просто те кто хочет добиться хорошей оценки от сервиса Google PageSpeed.



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



План действий такой:



1. Арендуем vps на час.

2. Собираем на арендованной vps динамический модуль на той же самой версии Nginx что была использована на боевом (это ВАЖНО!!!. Поддержка динамических модулей у Nginx появилась с версии 1.9.11).

3. Перекидываем модуль на новый сервер.

4. Конфигурируем Nginx.

5. Применяем настройки.

6. Замораживаем версию Nginx (Если это не сделать, то при ближайшем обновлении Nginx, произойдёт падение сервера. Причина в том что скомпилированный модуль будет работать только с конкретной версией Nginx. Если захотите обновиться, скомпилируете модуль для новой версии и обновитесь).



Или следим за тем что обновляем и своевременно добавляем новый собранный модуль.



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

Перевод статьи, написанной Scrum.org и DevOps Institute. Ссылка на оригинальный файл

От переводчика

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

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

Ссылки, которые были в основном документе, я поместил сразу в текст, они отделяются скобками и курсивом. Если были сомнения в корректности перевода термина, то я дублировал его в скобках на английском.

Цикл статей про обзор дефектов кода музыкально софта продолжается. Вторым претендентом для анализа выбран аудиоредактор Audacity. Это программа очень популярна и широко используется, как любителями, так и профессионалами в музыкальной индустрии. В этой статье описание фрагментов кода будет дополнительно сопровождаться популярными мемами. Скучно не будет!
Мемасики под катом...

Источник

«С женами спорить бесполезно, с ними даже навигатор соглашается».

(Из памятки молодоженам)

Эта история началась не сегодня и не вчера. И не в России. Просто прошло время, когда ее плоды стали, как говорится, налицо.

Не так давно капитан американского судна, находящегося неподалеку от Новороссийска обнаружил, что спутниковая система глобального позиционирования GPS неверно установила его местоположение и показывает, будто судно находился у шашлычной Жорика Вартанова, что в аэропорту Геленджика. Не найдя изъянов в работе навигационного оборудования, капитан связался с соседними судами и узнал, что все они также «в гостях» у Жорика. И вот уже New Scientist написал, что «сообщения о проблемах со спутниковой навигацией на Черном море наводят на мысль, что Россия, возможно, испытывает новую систему спуфинга (маскировки путем искажения данных)». Применительно к спутниковой системе спуфинг — это фальшивый сигнал с наземной станции, имитирующий работу спутника и вводящий в заблуждение абонентский приемник. Далее было написано, что, по-видимому, «Россия экспериментирует с новой формой электронного оружия. В прошлом году GPS-спуфинг хаотически нарушал работу приемников в приложениях для смартфонов в центре Москвы. Фальшивый сигнал, который, похоже, концентрируется вокруг Кремля, «перебрасывает» всех, кто оказывается неподалеку, за 32 км в аэропорт Внуково. Вероятно, это делается в целях обороны: многие управляемые бомбы, ракеты и беспилотники НАТО руководствуются GPS-навигацией, а успешный спуфинг не даст им поразить цели». Ну а Жорик по-видимому, делает это в маркетинговых целях, расширяя виртуальную клиентскую базу.

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

Machine Learning с каждым днём становится всё больше. Кажется, что любая компания, у которой есть хотя бы пять сотрудников, хочет себе разработать или купить решение на машинном обучении. Считать овец, считать свёклу, считать покупателей, считать товар. Либо прогнозировать всё то же самое.



Формула проста: если цена внедрения ниже, чем ты платишь охраннику — ставь управляемый шлагбаум. Потери от бездельников выше стоимости внедрения биометрической системы учёта времени — внедряй. «Эксперт» берёт взятки за контроль качества продукта? Продублируй его системой контроля качества.

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

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

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

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



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

Если у вас есть опыт создания ПО и вы хотите познакомиться с проектированием цифровых логических схем (digital design), то одна из первых вещей, которые вам нужно понять, — это концепция тактов. Она раздражает многих программных инженеров, начинающих HDL-проектирование. Без использования тактов они могут превратить HDL в язык программирования с $display, if и циклами for, как в любом другом языке. Но при этом такты, которые новички игнорируют, — зачастую один из основополагающих элементов при проектировании любых цифровых логических схем.

Ярче всего эта проблема проявляется именно при рассмотрении первых схем, созданных начинающими HDL-разработчиками. Я недавно общался с некоторыми из них. Новички опубликовали свои вопросы на форумах, которые я читаю. Когда я проанализировал то, что они делают, от увиденного волосы встали дыбом.