Оказывается, что есть отличная книжка по поисковым технологиям (Information Retrieval) от Cambridge University Press. Html и pdf версии лежат в свободном доступе. Работа над ней то ли еще ведется, то ли недавно закончена (последнее обновление — 7 апреля 2009). Книжка написана отличным английским языком, есть хорошие упражнения. В общем, рекомендую всем кому интересно как устроены Google и Yandex!

Html-версия — nlp.stanford.edu/IR-book/html/htmledition/irbook.html
PDF-версия (очень красивая, рекомендую!) — nlp.stanford.edu/IR-book/pdf/irbookonlinereading.pdf

А вот про Information Retrieval в википедии — en.wikipedia.org/wiki/Information_retrieval

Как-то я уже писал тут о переезде из Азии в Европу, а теперь хочу написать, что я в этой Европе делаю. Есть такая профессия — DevOps, точнее нет, но так получилось, что это именно то чем я сейчас занимаюсь. Сейчас для оркестрации всего что бежит в докере мы используем rancher, о чем я тоже уже писал. Но вот случилось ужасное, вышел ранчер 2.0 который переехал на kubernetes (дальше просто k8s) и поскольку k8s сейчас действительно стандарт для управления кластером, возникло желание тоже построить всю инфраструктуру заново с блекджеком и библиотекаршами. Что еще добавляет пикантности это то что компания постоянно нанимает разных специалистов из разных стран и с разными традициями и кто-то и собой приносит puppet, кому-то милее ansible, а кто-то вообще считает что Makefile + bash — наше все. Поэтому однозначного мнения как все должно работать просто нет, а очень хочется.

Предварительно был собран такой зоопарк технологий и инструментов:

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

«Изменения неизбежны. Рост не гарантирован».
— Джон Максвелл

Хотя цитата Максвелла и может показаться чрезмерно обобщённой, но она абсолютно применима и к разработке приложения.

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

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

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

Написано в Alconost

2,4 ГГц — это плохо. 5 ГГц — это хорошо. 6 ГГц — это ещё лучше, но послезавтра. Все это знают, кого я тут учу, в самом деле. Всё это хорошо, только делать-то что, когда ты такой, как умный, открываешь какой-нибудь Wi-Fi Explorer, а там сатанизм и этажерки, как на скриншоте?



Шаг первый — поплакать. Шаг второй — нырнуть под кат. Вопрос простой, а ответ — нет.

Вводная

Ранее на Хабре очень подробно освещалась тема Автоматизации десктопных GUI приложений на Python. В то время меня очень сильно привлекла эта статья, потому что в ней раскрываются элементы, схожие с элементами создания роботов. А так как по роду своей профессиональной деятельности я занимаюсь роботизацией бизнес-процессов компании (RPA — область, в которой не было полнофункциональных OpenSource аналогов до недавнего времени), данная тема была очень актуальна для меня.

Как-то раз, наткнувшись на схему развития областей знаний тимлида, подумала, что это прекрасный способ систематизации и для HR в IT. Теперь хочу поделиться тем, что у меня получилось со всеми, кто знает эту область компетенций пятнами и без особой систематизации:



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

Сегодня в названиях вакансий всё чаще появляются приставки «продуктовый» — дизайнер, аналитик, разработчик… Компании, придерживающиеся продуктового подхода, ожидают от кандидатов определённого образа мышления, хороших технических скиллов бывает недостаточно. Меня зовут Михаил Мазеин, я тот самый продуктовый разработчик в ManyChat, занимаюсь бекэндом и участвую в процессе найма. Давайте расскажу, как это выглядит изнутри.

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


@innubis

Введение

Умение реализовать грамотное REST API — полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.
В настоящее время многие онлайн системы с помощью API передают приватные данные пользователей, такие как медицинские или финансовые. Текущая же ситуация с безопасностью в веб-приложениях весьма печальна: по данным Comnews порядка 70% содержат кри­тичес­кие уязвимости. Поэтому всем, кто участвует в проектировании, реализации и тестировании онлайн систем, важно иметь общую картину по существующим угрозам и способам обеспечения безопасности как всей системы, так и используемого REST API.

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

Согласно PMI 90% времени руководитель проекта тратит на общение с заинтересованными сторонами. Цель такого общения — обсудить и принять решение по ряду вопросов. Собрание посвященное обсуждению каких-либо вопросов является определением совещания.

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

В декабре прошлого года(2019) вышел выпуск Comedy Club с постановкой «Очень важное совещание в очень крупной компании». Моя лента в фейсбук пестрила репостами этого ролика со словами «смотри прям как у нас», «главное чтобы опять вот так не получилось» или «ничего не напоминает?». На хабре появилась статья с разбором постановки.

Задолго до Comedy club совещания стали одной из ключевых тем популярного комикса Скотта Адамса «Дилберт». Это как раз тот случай, когда и смешно и грустно одновременно.

Думаю не только у меня в то время возник риторический вопрос «Если все в курсе об этой проблеме и описано столько способов ее решения, то почему она до сих пор так актуальна?»

Моя любимая книга на эту тему «Смерть от совещаний» Патрика Ленсиони. Когда я ее прочитал пару лет назад, то решил, что обязательно попробую ее внедрить слово в слово.

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

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

О себе

Здравствуй, Хабр! Меня зовут Павел, я работаю техническим директором в компании, занимающейся производством IoT устройств. Производим много чего — начиная от контроллеров для умных домов, заканчивая умными приборами учёта на своём запатентованном протоколе сенсорных сетей.

Также исполняют обязанности генерального директора ит-компании. В прошлом полуфиналист ЧМ по программированию ACM ICPC.

Мотивация

Пишу я это статью потому, что наша команда убила около месяца на поиск решения (ещё недели две на реализацию и написание тестов) для хранения и эффективного поиска распознанных лиц в базе данных, с целью сэкономить время вам в ваших проектах. Спойлер: ничего готового вроде классного плагина для существующей СУБД не нашли, а сроки полыхали, по этому написали свою СУБД именно для этой задачи (хранения огромного количества эмбендингов лиц). Моя статья ни в коем случае не претендует на звание исчерпывающего руководства, но, я надеюсь, что она даст точку старта для дальнейшего изучения и развития наших мыслей.

Эмбеддинг – это отображение из дискретного вектора категориальных признаков в непрерывный вектор с заранее заданной размерностью.

Краткое вступление

Как правило, для того чтобы добраться до интересующего нас поля сериализованного свойства, мануальная терапия советует нам использовать метод FindPropertyRelative(), в который прокидывается название переменной.

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

Итак, давайте же разберёмся как из сериализованного свойства получить объект, с которым мы работаем, а также все его родительские объекты, и не навернуться по дороге сериализации, полной подводных камней.

Внимание. Данная статья подразумевает, что вы уже умеете работать с UnityEditor’ом, хотя бы раз писали кастомные PropertyDrawer’ы и хотя бы в общих чертах понимаете, чем сериализованное свойство отличается от сериализованного объекта.

Привет, Хабр! Я руковожу отделом закупки трафика для мобильных и десктопных проектов в Mail.ru Group. Сегодня в этом посте я подробно расскажу про трафик для игр. Он написан по мотивам моего доклада на конференции The Big Deal. Но сначала немного о себе. Я работал с огромным количеством проектов по различным маркетинговым задачам, последние полтора года работаю исключительно с мобильными приложениями. За это время успел поработать с несколькими десятками приложений, большинство из которых в soft launch, часть из них выпущена в global, а несколько «раскачали» более чем на $1 млн оборота в месяц. За время работы у меня сформировалось некое видение, как с точки зрения трафика проекта проанализировать метрики и понять, может ли ваш проект расти, развиваться и пропускать через себя огромный объем трафика.

Каждый проект требует жертвы. Главное, чтобы не слишком большой. Команда Mail.Ru Cloud Solutions перевела статью Алекса Стейвли про минусы технического долга и его способность уничтожить даже самый успешный проект. Предупреждение автора: в этой статье не так много практики, как хотелось бы, но она может натолкнуть на размышления.

Введение от автора обзора

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

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

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

Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.

В общем суть метода уже изложена, ниже лишь немного подробностей.

Пару недель назад я играл в A Plague Tale студии Asobo Studio (и прошёл её). Меня очень захватила эта игра, благодаря не только красивой графике, но и сюжету с локациями. Я решил немного изучить технологии, использовавшиеся при её разработке, и был удивлён, обнаружив, что игра создавалась на собственном движке относительно небольшой студии. Я знаю, что некоторые компании используют собственные движки, но очень сложно найти подробное маркетинговое исследование с подобной информацией. Поэтому я написал эту статью.

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

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

TL;DR: рассказываю о задаче оценки вклада сотрудника в общий результат и новой open source системе проведения круговой оценки сотрудников, разработанной в нашей компании, на базе метода оценки 360 градусов.

Здравствуйте, меня зовут Иван Кудрявцев — я технический директор и совладелец компании, которая занимается контрактной разработкой. В 2016 году мы начали разрабатывать систему поощрения достижений для инженеров.

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

• разработчик ⟶ руководитель проекта;
• сотрудник ⟶ топ-менеджер;
• участник проекта ⟶ клиент.

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

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

Привет, Хабр!

Представим, что у нас есть задача построить новую дорогу. Можно построить магистраль с двумя полосами в каждую сторону, но что, если этого будет недостаточно? Или, наоборот, окажется, что хватило бы и одной полосы, но для реализации проекта пришлось выкупать множество земельных участков? В обоих случаях принятое решение будет неэффективным. Чтобы минимизировать подобные риски, транспортные планировщики обращаются за помощью к компьютерному моделированию. Эта статья – краткий экскурс в мир мультиагентного моделирования.

Предлагаю ознакомиться с расшифровкой доклада 2017 года Игорь Стрыхарь «ClickHouse – визуально быстрый и наглядный анализ данных в Tabix».

Веб-интерфейс для ClickHouse в проекте Tabix.
Основные возможности:

• Работает с ClickHouse напрямую из браузера, без необходимости установки дополнительного ПО;
• Редактор запросов с подсветкой синтаксиса;
• Автодополнение команд;
• Инструменты графического анализа выполнения запросов;
• Цветовые схемы на выбор.