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

Из руководителей я был такой один, тем самым привлек к себе внимание. Ну и сам удивился – оказывается, когда от тебя не уходят сотрудники, это странно и необычно.

В сумме я работал руководителем лет 7-10 (точно не знаю, какие периоды сюда включать), но нулевая текучка сохранилась. Никто никогда от меня не уходил, никого никогда я не выгонял. Только набирал.

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

У программистов есть разные поговорки о трудных проблемах. Наверное, мой любимый вариант: «В информатике две трудные проблемы: недействительность кэша, присвоение имён и ошибки на единицу».

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

А это очень трудно.

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

Как быть, если дерево поиска разрослось на всю оперативку и вот-вот подопрет корнями соседние стойки в серверной? Что делать с инвертированным индексом, жадным до ресурсов? Завязывать ли с разработкой под Android, если пользователю прилетает «Память телефона заполнена», а приложение едва на половине загрузки важного контейнера?

В целом, можно ли сжать структуру данных, чтобы она занимала заметно меньше места, но не теряла присущих ей достоинств? Чтобы доступ к хэш-таблице оставался быстрым, а сбалансированное дерево сохраняло свои свойства. Да, можно! Для этого и появилось направление информатики «Succinct data structures», исследующее компактное представление структур данных. Оно развивается с конца 80-х годов и прямо сейчас переживает расцвет в лучах славы big data и highload.

А тем временем на Хабре найдется ли герой, способный пересковоговорить три раза подряд
[səkˈsɪŋkt]?

Книга "Say It With Chart" (дословно «Скажи это с помощью диаграммы») написана более 30-ти лет назад (в 1985 году!), однако и сегодня пользуется интересом. Она переведена на главные мировые языки, переиздается вновь и вновь, бизнесмены, маркетологи, аналитики считают её настольной книгой и в 2017-м.

Книгу интересно читать, в ней много полезного, но это было ожидаемо. Неожиданностью стал недостаток информации о её авторе в сети (которому принадлежит еще несколько мировых бестселлеров). О Джине Желязны нет статьи в Википедии (ни на английском, ни на русском), на запросы типа «биография Дж. Желязны» или «кто такой Дж. Желязны» выдаются бесчисленные сайты с одним и тем же текстом — аннотацией к книге «Говори на языке диаграмм». А это, согласитесь, только усиливает интерес, поэтому рецензия будет состоять из двух частей: «О книге» и «Кто такой Джин Желязны?».

******************* Ну и кто из нас читал «Начала» Ньютона? *****************

Беру в руки журнал “Наука и жизнь” №1 2020. На обложке бросается в глаза вопрос “Почему Эйнштейн самый великий физик?”. Действительно, почему? Открываю статью Евгения Берковича “Трагедия Эйнштейна, или счастливый Сизиф”. Начинается она так: “Кто самый великий физик? Спросите об этом кого угодно, любой вам скажет: Альберт Эйнштейн. Не зря строгий академик Лев Ландау поставил его первым в иерархии физиков”.

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

“Спросите об этом кого угодно…”. Господин Беркович берет на себя смелость отвечать за всех. Ну, кого угодно, так кого угодно — мне угодно взять себя. Беру себя. И отвечаю: самый великий физик это Исаак Ньютон.

Наш пост – это возможность узнать об исследованиях в новом подразделении Samsung Research – Центре Искусственного интеллекта (ИИ) в Москве. Он открылся в мае 2018 года и за полтора года собрал лучших профессионалов в области машинного обучения.

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

Переходя от проекта к проекту, мы сталкиваемся, к сожалению, с отсутствием единообразных стандартов проектирования баз данных, несмотря на то, что SQL существует уже несколько десятилетий. Подозреваю, причина отчасти в том, что большинство разработчиков не понимают архитектуру БД. За годы моей работы по найму разработчиков, я лишь несколько раз встречал тех, кто мог корректно нормализовать базу данных. Честно говоря, это бывает сложной задачей, но многие разработчики, которых я собеседовал, даже прекрасно владеющие SQL, не имели навыков проектирования БД.

Эта статья не про нормализацию БД. Если хотите этому научиться, то здесь я вкратце рассказал основы.

Если у вас есть рабочая БД, то нужно ответить себе на вопрос: «какие стандарты можно применить для облегчения использования этой базы данных?». Если эти стандарты применялись широко, то вам будет легко пользоваться БД, потому что не придётся изучать и запоминать новые наборы стандартов каждый раз, начиная работу с новой БД.

Привет, Хабр! Меня зовут Женя Остроумова, и я рекрутёр_ка. Сегодня поговорим с вами про контрофферы.

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

В этой статье мы попробуем взглянуть на архитектуру учетных систем (ERP, CRM, WMS, MES, B2B, ...) с позиций функционального программирования. Существующие системы сложны. Они базируются на реляционной схеме данных, и имеют огромный мутабельный стейт в виде сотен связаных таблиц. При этом единственным «источником правды» в таких системах является хронологически-упорядоченный журнал первичных документов (отпечатков событий реального мира), которые, очевидно, должны быть иммутабельными (и это правило соблюдается в аудируемых системах, где корректировки «задним числом» запрещены). Журнал документов составляет от силы 20% объема БД, а все остальное — промежуточные абстракции и агрегаты, с которыми удобно работать на языке SQL, но которые требуют постоянной синхронизации с документами, и между собой.

Если вернуться к истокам (устранить избыточность данных и отказаться от хранения агрегатов), а все бизнес-алгоритмы реализовать в виде функций, применяемых непосредственно к потоку первичных документов — мы получим функциональную СУБД, и построенную на ней функциональную ERP. Проблема производительности решается благодаря мемоизации, а объем функционального кода будет вполне соизмерим с объемом декларативного SQL, и не сложнее для понимания. В данной статье мы продемонстрируем подход, разработав простейшую файловую СУБД на языке TypeScript и рантайме Deno (аналог Node.js), а также протестируем производительность сверток на примере типичных бизнес-задач.

Почему это актуально

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

Нейросети выросли от состояния академической диковинки до массивной индустрии

За последнее десятилетие компьютеры заметно улучшили свои возможности в области понимания окружающего мира. ПО для фототехники автоматически распознаёт лица людей. Смартфоны преобразуют речь в текст. Робомобили распознают объекты на дороге и избегают столкновения с ними.

В основе всех этих прорывов лежит технология работы искусственного интеллекта (ИИ) под названием глубокое обучение (ГО). ГО основывается на нейросетях (НС), структурах данных, вдохновлённых сетями, составленными из биологических нейронов. НС организуются послойно, и входы одного слоя соединены с выходами соседнего.

Специалисты по информатике экспериментируют с НС с 1950-х годов. Однако основы сегодняшней обширной индустрии ГО заложили два крупных прорыва – один произошёл в 1986 году, второй – в 2012. Прорыв 2012 года – революция ГО – была связана с открытием того, что использование НС с большим количеством слоёв позволит нам значительно улучшить их эффективность. Открытию способствовали растущие объёмы как данных, так и вычислительных мощностей.

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

Это был далекий 2015 год. На тот момент уже был опыт работы в e-commerce разных масштабов и стандартные решения «по популярности» не устраивали. Начались поиски как это сделать наилучшим образом.

Были определены следующие задачи:

• Полная автоматизация
• Разных сегменты товаров по цене (присутствие как дешевых так и дорогих товаров)
• Приоритет по просмотрам
• Приоритет по продажам
• На первые 10 позиций должны приходится все популярные товары по:
  
  • цене
  • просмотрам
  • продажам
  • доходности

В итоге получилась формула которая учитывает все эти данные и считает автоматически.

Вступление: Позапрошлым летом я открыл для себя великолепную книгу SICP — чтение только первого раздела книги открыло для меня новый мир функционального программирования. Анонимные функции, функции, что возвращают функции, функции высших порядков. Во втором разделе книги авторы показали, что возможно с помощью одних только функций создавать различные структуры данных, такие как пара, список, или даже деревья! Сегодня мне бы хотелось реализовать кое-какие идеи из этой книги на языке программирования Python. Конечно же, исключительно с помощью функций.

Привет! Меня зовут Максим, последние 17 лет я работаю в ИТ (аналитик, РП, 11 лет бекенда), а еще я получил второе образование психолога в жанре «гештальт-терапия». Хочу рассказать о том, что для меня психотерапия очень похожа на разработку ПО с помощью дебаггера и как эту схожесть можно применять на практике.



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

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

Продолжаем публикацию наиболее интересных глав из книги Magnus Lie Hetland «Python Algorithms». Предыдущая статья расположена по адресу habrahabr.ru/blogs/algorithm/111858. Сегодня же речь пойдет об эффективной работе с графами и деревьями и особенностях их реализации в Python. Базовая терминология теории графов уже обсуждалась (например здесь: habrahabr.ru/blogs/algorithm/65367), так что я не включил часть главы о терминах в эту статью.

Реализация графов и деревьев

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

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

Мы тоже столкнулись с необходимостью поиска ближайших соседей в задаче распознавания лиц. Там мы формируем векторные представления лиц при помощи нейросети и ищем ближайшие векторы уже известных людей. Изначально для поиска мы выбрали Annoy, как хорошо известный и проверенный алгоритм, используемый в том числе в Spotify. Но быстро поняли, что с его аппетитами по памяти мы либо не вмещаемся в RAM, либо сильно теряем в точности. Это привело к небольшому исследованию. О результатах которого пойдет речь ниже.

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

Написано очень много статей, посвящённых интересным возможностям Python. В них идёт речь о распаковке списков и кортежей в переменные, о частичном применении функций, о работе с итерируемыми объектами. Но в Python есть гораздо больше всего интересного. Автор статьи, перевод которой мы сегодня публикуем, говорит, что хочет рассказать о некоторых возможностях Python, которыми он пользуется. При этом описания этих возможностей, подобного тому, которое приведено здесь, ему пока не встречалось. Возможно, что и вы о них тоже ещё нигде не читали.

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

Еще до конца мая у нас выйдет перевод книги Франсуа Шолле "Глубокое обучение на Python" (примеры с использованием библиотек Keras и Tensorflow). Не пропустите!



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

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

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

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

Шесть лет назад в один такой воскресный вечер я понял, что сил больше не осталось. Работа довела до полного изнеможения. По какой-то причине я был совершенно измотан. Хотя не напрягался физически, но зубы отчего-то сжимались до боли.

Я включил компьютер и сделал что-то невероятное для себя. Попросил помощи. Зашёл на HN и запустил новый тред. Я не знал, что и как сказать, но пальцы сами стучали, пока проблема не вылилась на страницу. Вот что я тогда написал: «Нас могут уволить, и я не знаю, что делать» (тред в разделе 'Ask HN', 114 комментариев).

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