Если спросить айтишников, для чего в компании внедряется CRM-система, то немалая доля собеседников ответит, что, в основном, для мучений и пыток системного администратора. Кто-то ещё расскажет, что для издевательств над любым штатным айтишником или хотя бы несчастным продвинутым гиком в компании. Это, конечно, всё шутки. А если серьёзно, то порой даже сами компании, выбравшие CRM, не могут ответить на этот вопрос. Из популярного: «программа для продаж» и «система, которая продаёт». Вопрос «Для кого внедряется CRM?» вызывает ещё больший разброс мнений, среди которых лидируют «для босса», «для продажников» и, полагаем, где-то в списке «для галочки» и «для понтов». Между тем CRM-система адресована вполне конкретным сотрудникам, которые могут с её помощью явить чудеса профессионализма и эффективности — хоть в офисе, хоть на удалёнке. Если они этого, конечно захотят. Так кто эти люди, ради которых стараются сисадмины, программисты и сами разработчики CRM?

Кто эти трое? Трое ли их на самом деле? 

Введение

Тема искусственного интеллекта сегодня — одна из самых обсуждаемых. Перспектива «обеспечить монополию в сфере искусственного интеллекта и стать властелином мира» заставила всех соревноваться в данной области. IT-гиганты, финансовые компании, бизнес-аналитики, университеты и научное сообщество предлагают собственное видение инструментов и методологии решения основных задач при их создании. Однако результаты удручают, особенно в сфере LegalTech.

Что такое настоящий LegalTech, а что скрывается под громкими рекламными слоганами? Почему никому из IT-разработчиков не удалось создать действительно прорывной и функциональный продукт, близкий к цифровому юристу? Какой подход позволил нам решить данные задачи и существенно приблизиться к созданию настоящего юридического искусственного интеллекта?

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

Я еще помню времена, когда принудительное ООП было доминирующим паттерном. Сейчас это очевидно не так, и все современные ЯП предлагают намного больше парадигм. Однако в области веб-разработки тотально (и на мой взгляд неоправданно) доминирует реактивность, которая в свое время эффективно решила проблему несовершенного DOM API, попутно создав несколько архитектурных проблем вроде централизованного хранилища данных (что вообще-то нарушает принципы SOLID), или переусложненного механизма взаимодействия компонентов. В условиях современных WEB-стандартов, реактивность нуждается как минимум в некотором переосмыслении. Например, реактивная парадигма прекрасно выглядит, если наш стейт централизован (не случайно самый популярный стек это react / redux), а если он распределен по дереву компонентов (что архитектурно правильней), то зачастую нам нужно меньше реактивности, а больше аккуратной императивности.

Свои проекты я пишу на ванильных веб-компонентах, в стиле императивного ООП, с минимальным количеством библиотечного кода, и очень редко действительно скучаю по реактивности. Если бы чистая реактивность покрывала все потребности разработчика, не пришлось бы в каждом фрейморке создавать императивные лазейки, позволяющие модифицировать компонент вместо его пересоздания (рефы, неуправляемые формы, $parent и т.д.). А когда стоит задача получить экстремально-отзывчивое приложение, то волей-неволей приходится думать (и вручную контролировать) момент и способ обновления DOM, как собственно и сделано в большинстве хороших PWA (например Twitter) и не сделано в менее хороших PWA (например VK). Так, большие списки выгодней формировать методом insertAdjacentHTML(), который вполне способен работать с текстово-параметризуемыми веб-компонентами, но вряд-ли применим к управляемым компонентам, и таких примеров достаточно.

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

В прошлом году мы публиковали перевод небольшого обзора web UI для Kubernetes, приуроченного к анонсу веб-интерфейса Kubernetes Web View. Автор той статьи и самой утилиты — Henning Jacobs из компании Zalando — как раз позиционировал новинку в качестве «kubectl для веба». Он хотел создать инструмент с удобными возможностями для взаимодействия в формате техподдержки (например, быстро показать проблему веб-ссылкой) и для реакции на инциденты, поиска проблем во многих кластерах одновременно. Его детище развивается и в настоящее время (в основном, силами самого автора).

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

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

Владимир Китов, работающий с ИТ более полувека, возглавлял команды программистов в ГВЦ Минморфлота СССР и ЦНИИ «Монолит», руководил разработкой ПО для международной системы космического спасения КОСПАС-SARSAT и созданием мультитерминального монитора для ЕС ЭВМ. Он работал топ-менеджером в компаниях DEC, SIEMENS, «Техносерв», IBS, Fujitsu, написал учебник по системному программированию и несколько монографий, а теперь занимается историей информатики.

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

кдпв — Reuters

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

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

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

Современный мир дает возможность многим работать из дома. Особенно сейчас, в «короновирусную» эпоху еще больше людей работают удаленно и перестали ездить на работу. Это значит, что в домашней обстановке в основном сидят, долго сидят и смотрят в монитор. Справедливости ради, надо сказать, что и офисная жизнь не располагает к подвижности. Про вред долгого смотрения в монитор я пока не готова рассказать, а вот долгое сидение точно приводит к проблемам с ЖКТ (желудочно-кишечный тракт). Плюс многие не пьют достаточное количество воды, не едят клетчатку, стрессуют, а это все приводит к некоторым проблемам, которые могут длиться годами. Рано или поздно многие приходят к необходимости сделать колоноскопию. Если хотите узнать про это деликатное исследование подробнее – добро пожаловать под кат. В статье есть описание многих физиологических тем, которых принято стесняться, кому-то может быть просто неприятно, также есть немного ужастиков, так что впечатлительным особам лучше воздержаться от чтения.

Docker Swarm, Kubernetes и Mesos являются наиболее популярными фреймворками для оркестровки контейнеров. В своем выступлении Арун Гупта сравнивает следующие аспекты работы Docker, Swarm, и Kubernetes:

• Локальный девелопмент.
• Функции развертывания.
• Мультиконтейнерные приложения.
• Обнаружение служб service discovery.
• Масштабирование сервиса.
• Run-once задания.
• Интеграция с Maven.
• «Скользящее» обновление.
• Создание кластера БД Couchbase.

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

Арун Гупта — главный технолог open-source продуктов Amazon Web Services, который уже более 10 лет развивает сообщества разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет большой опыт работы в ведущих кросс-функциональных командах, занимающихся разработкой и реализацией стратегии маркетинговых кампаний и программ. Руководил группами инженеров Sun, является одним из основателей команды Java EE и создателем американского отделения Devoxx4Kids. Арун Гупта является автором более 2 тысяч постов в IT-блогах и выступил с докладами более чем в 40 странах.

Docker Swarm, Kubernetes и Mesos являются наиболее популярными фреймворками для оркестровки контейнеров. В своем выступлении Арун Гупта сравнивает следующие аспекты работы Docker, Swarm, и Kubernetes:

• Локальный девелопмент.
• Функции развертывания.
• Мультиконтейнерные приложения.
• Обнаружение служб service discovery.
• Масштабирование сервиса.
• Run-once задания.
• Интеграция с Maven.
• «Скользящее» обновление.
• Создание кластера БД Couchbase.

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

Арун Гупта — главный технолог open-source продуктов Amazon Web Services, который уже более 10 лет развивает сообщества разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет большой опыт работы в ведущих кросс-функциональных командах, занимающихся разработкой и реализацией стратегии маркетинговых кампаний и программ. Руководил группами инженеров Sun, является одним из основателей команды Java EE и создателем американского отделения Devoxx4Kids. Арун Гупта является автором более 2 тысяч постов в IT-блогах и выступил с докладами более чем в 40 странах.

"Кто ни разу не ошибался в индексировании цикла, пусть первый бросит в деструкторе исключение."

— Древняя мудрость

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

В конце концов, это просто некрасиво.

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

Данная работа ставит своей целью пролить свет на отнюдь не новую, но пока что не слишком распространённую идею, которая вполне способна произвести очередной прорыв в области написания программ на языке C++.

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

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

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

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

Привет! Меня зовут Владимир Олохтонов, я старший разработчик в команде автоматической модерации Авито. Осенью 2019 мы запустили сервис поиска похожих изображений на основе библиотеки faiss. Он помогает нам понимать, что фотографии уже встречались в другом объявлении, даже если они достаточно серьёзно искажены: размыты, обрезаны и тому подобное. Так мы определяем потенциально фейковые публикации.

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

На Хабре есть не только айтишники. Тут и электрики, и схемотехники, и химики, и маркетологи и кого только нет. И возможность переезда в другую страну в качестве специалиста широкого профиля интересна и им тоже. В довесок к истории Дудя и аналогичным статьям я хочу рассказать свою историю про переезд в США, на противоположный от Калифорнии берег с противоположной от IT профессии. Про жизнь, траты, поиск и смены работы и перспективы. Мне 36, я по образованию биотехнолог, семья — два человека, английский язык — так себе. Живу в Северной Каролине почти два года.

Поскольку написанного вышло много, вот короткая версия. При переезде практически гарантировано снижение социального статуса. Прожить можно на $1500. Средняя зарплата «неайтишника» $30к-50к в год. Средняя стоимость дома $200к. Получить медицинскую страховку бесплатно можно. Много плюшек от государства. Поиск нормальной работы очень нетривиален. Язык сам не учится, но есть бесплатные курсы. Жить комфортно. Наше образование никому не нужно. Очень многие мечтают о карьере в IT.

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

Недавний пост «Вы видели людей, которые пользуются мобильными контент-подписками?» опять всколыхнул внутреннее недовольство отношением Мегафона ко мне и я решил рассказать про свою «войну» с зелёно-фиолетовым оператором и попытками оградиться от рекламы и вмешивания в мой HTTP-трафик.

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

Мотивация от оператора:

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

Вместо выполнения Федерального Закона «О Рекламе», статья 18, п. 1, при обращениях к оператору с требованием прекратить распространять рекламу в мой адрес:

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

Мегафон подключает дополнительные услуги «отказа от рекламы» (у меня их с десяток), которые иногда не работают, и реклама продолжает приходить.



Например, после скриншота выше, сегодня получил очередную зелёно-фиолетовую рекламу.

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

С подписками, как оказалось, разобраться проще всего. Расскажу под катом про свой опыт и с ними, и с вмешательством в HTTP-трафик:

• почему вы видите сайты с подписками, даже если кликнули по объявлению в выдаче Google,
• размышления, много ли мобильные подписки приносят денег оператору,
• как Мегафон вмешивается в HTTP-трафик,
• про рекламу, от которой вы не можете отказаться,
• чеклист того что можно сделать, для минимизации рекламы, подписок и вмешательств в HTTP-трафик.

В 2017 году мы с семьёй переехали в Иннополис.

За 3 года жизни эйфория прошла и сформировалось какое-то устойчивое мнение об этом городе.

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

Меня никто не просил писать эту статью и тем более не платил за неё. В общем, это не заказная «приезжайте к нам, у нас тут классно». Пишу всё так, как вижу своими глазами.

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

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

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

Amazon S3 (Simple Storage Service, сервис простого хранилища) — очень мощный онлайн сервис файлового хранилища, предоставляемого Amazon Web Services. Думайте о нем, как об удаленном диске, на котором вы можете хранить файлы в директориях, получать и удалять их. Компании, такие как DropBox, Netflix, Pinterest, Slideshare, Tumblr и многие другие, полагаются на него.

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

Первый квартал 2020 года я провел за подготовкой к экзамену OSCP. Поиск информации в Google и множество «слепых» попыток отнимали у меня все свободное время. Особенно непросто оказалось разобраться в механизмах повышения привилегий. Курс PWK уделяет этой теме большое внимание, однако методических материалов всегда недостаточно. В Интернете есть куча мануалов с полезными командами, но я не сторонник слепого следования рекомендациям без понимания, к чему это приведет.

Мне хочется поделиться с вами тем, что удалось узнать за время подготовки и успешной сдачи экзамена (включая периодические набеги на Hack The Box). Я испытывал сильнейшее ощущение благодарности к каждой крупице информации, которая помогала мне пройти путь Try Harder более осознанно, сейчас мое время отдать должное комьюнити.

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

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