Я недавно посчитал, что нашему проекту исполнилось 250 человеко-месяцев. Это почти 21 человеко-год или почти 28 рожденных детей, если бы мы занимались рождением детей (мужики, вы чего? — прим. ред.).

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

В интернете пишут, что первая версия Minecraft была разработана “буквально за выходные”. Я оставлю эту оценку на совести авторов, просто констатирую факт, что на первую версию было потрачено меньше 250 человеко-месяцев. 

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

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

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

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

Вы можете найти сотни людей выкладывающих фото и видео на дорогих машинах, в окружении красоток и красавцев из США/Милана/Англии и т. д. Такие материалы чаще всего сопровождаются подписью «ещё одна успешная сделка +80% к капиталу» или «поднял за месяц 40%, можно и отдохнуть».

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

Пара слов обо мне. У меня никогда не было серьезного плана делать свой продукт, открывать под это дело компанию, погружаться в custdev и вот это вот всё. Днем я работал в сеньёр девелопером, по вечерам - делал pet-проекты типа онлайн версии настольной игры или онлайн-редактора пиксель-арта, и все было хорошо.

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

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

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

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

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

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

1. Can’t Unsee

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

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

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

Мы ежедневно работаем с информацией из разных источников и поэтому имеем интуитивные представления о том, что означает, когда один источник является более информативным, чем другой. Однако далеко не всегда понятно, как это правильно определить формально. Не всегда большое количество текста означает большое количество информации. Например, среди СМИ распространена практика, когда короткое сообщение из ленты информационного агентства переписывают в большую новость, но при этом не добавляют никакой «новой информации». Или другой пример: рассмотрим текстовый файл с романом «Война и мир» в кодировке UTF-8. Его размер — 3.2 Мб. Сколько информации содержится в этом файле? Изменится ли это количество, если файл перекодировать в другую кодировку? А если заархивировать? Сколько информации вы получите, если прочитаете этот файл? А если прочитаете его второй раз?

По мотивам открытой лекции для Computer Science центра рассказываю о том, как можно математически подойти к определению понятия "количество информации".

Об этом спрашивают на собеседованиях. Структурированное понимание этого может помочь вам, даже если вы давно строите сложные архитектурные процессы или кодите 20-ый год подряд. Я — программист уже много лет, последние пару из которых пишу на Go в Каруне. Работа работой, а внутренний исследователь не дремлет. И вот я наконец-то решил привести в порядок информацию, разбросанную по разным закоулкам чертогов разума, по добротным книгам и статьям на тему сетевых технологий.

Хочу представить краткую выжимку о работе протоколов. А если тема окажется интересной, могу продолжить работать с ней более детально. Рассмотрим простейший пример: вы ввели некоторый url в адресную строку. Поехали.

Это четвертая статья с этой картинкой для привлечения внимания. Она каким-то удивительным образом опять подошла по смыслу.

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

Забегая вперед, скажу, что от идеи до рабочего решения на продакшене прошло пять часов.

Исходная ситуация такова: таблица в MS SQL базе, 50 миллионов записей, записи добавляются постоянно, удаляются или обновляются крайне редко. Средняя длина названия товара составляет 64 символа. Поиск по неточному совпадению работает, для этого используются триграммы и полнотекстовый индекс по столбцу с триграммами. Ранжирование результатов осуществляется при помощи функции CONTAINSTABLE. Результаты получаются релевантные, но поиск работает откровенно медленно, 2-5 секунд на запрос, в зависимости от длины запроса. Мы хотим ускорить его раз в 20, а лучше в 100 подручными средствами.

Эта статья дает возможность познакомиться с такой методикой получения и восстановления сигнала, как Compressive Sensing.

Знакомство с виртуальными ассистентами Салют, а также с платформой SmartMarket и SmartApp.

Путь от chat app до canvas app или как создать canvas app на платформе SmartMarket.

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

• Обрабатываются только 32-битные ключи и такие же значения.
• Хэш-таблица имеет фиксированный размер.
• И этот размер должен быть равен двум в степени.

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

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