Началась эта история еще в докоронавирусное время, еще тогда когда в моем LAB66 была всего пара тысяч подписчиков и работал бот-автоответчик. И вот в этот бот как-то постучался русскоговорящий парень из Чили и задал вопрос про слезоточивый газ. Про то, как жить вообще, когда по улицам ездят автомобили и распыляют «просроченный слезоточивый газ из Бразилии». Тогда я клятвенно пообещал вопросом этим заняться. Прошло… а прошло всего лишь полгода (хотя из-за обилия событий в 2020 кажется, что прошло 20 лет :) и я решил наконец написать парню ответ. Извини за задержку, Sergio из Чили, я был занят коронавирусом… Читай ответ под катом!

Продолжаю публикацию решений отправленных на дорешивание машин с площадки HackTheBox.

В данной статье мы покопаемся в LDAP, декодируем VNC пароль, декомпилируем приложения dotNet, легко расшифровываем AES и восстанавливаем удаленные объекты Active Directory.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ.

*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".

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

Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.

Наш идеал почти 9 лет был такой: собрание стоя, 15 минут максимум, минимум людей. И лучше вообще в коридоре. Не можешь решить за 15 минут — значит, что-то пошло не так. Звучит круто, правда?

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

Механика, которую нам предложили — это совещание по специальному протоколу. Оно занимает невероятно дохрена времени (4 часа на вопрос, где ушло бы наши 15 минут), навевает скуку и тоску, но если проходить по этапам, появляется ощущение, что решение всё же есть. И его можно реализовать. И оно, скорее всего, получится очень качественное: будет учитывать больше нюансов, будет поддержано теми, кому его исполнять. А это существенно сокращает срок внедрения.

Лучше пару часов потерпеть, но потом внедрить на месяц быстрее.

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

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

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

Практика показывает, что далеко не каждый человек знает, что такое острота зрения. Например, если вы узнаете, что курица видит на 300%, то есть точно лучше каждого из нас, и глаза у нее видят по-разному — то вы удивитесь.

В древние времена остроту зрения проверяли по созвездию Большой Медведицы в ночном небе. Это созвездие напоминает «ковш с ручкой» и практически всегда видно на ночном небе. Так рядом со второй звездой от конца «ручки ковша» (Мицар) находится малозаметная небольшая звезда Алькор («забытая, незначительная»). Способность видеть эту малозаметную звезду считалась традиционным способом проверки зрения, условной нормой. То есть, система была бинарная – «вижу» и «не вижу».


Эра починки зрения началась несколько столетий назад, использовать для этого лазер стали всего пару десятилетий назад и совершили технологический скачок до эндоскопической коррекции зрения ReLEX SMILE, о ней писала здесь.

В мире с 1985 года выполнено более 60 миллионов процедур по лазерной коррекции зрения! И все эти люди счастливы, что получили 100% зрение, спросите вы? А теперь самое интересное – нет, не все счастливы. И уж точно не у всех 100%.

Что может быть причиной не 100% зрения, почему люди «щурятся», как оценивать показатели приборов, которые измеряют параметры глаза, в том числе после лазерной коррекции, можно ли им доверять, как избежать багов при тестировании, какие исследования, зачем и когда необходимы, чтобы прояснить картину?

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

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

В прошлой статье мы познакомились со стеком ELK, из каких программных продуктов он состоит. И первая задача с которой сталкивается инженер при работе с ELK стеком это отправление логов для хранения в elasticsearch для последующего анализа. Однако, это просто лишь на словах, elasticsearch хранит логи в виде документов с определенными полями и значениями, а значит инженер должен используя различные инструменты распарсить сообщение, которое отправляется с конечных систем. Сделать это можно несколькими способами — самому написать программу, которая по API будет добавлять документы в базу либо использовать уже готовые решения. В рамках данного курса мы будем рассматривать решение Logstash, которое является частью ELK stack. Мы посмотрим как можно отправить логи с конечных систем в Logstash, а затем будем настраивать конфигурационный файл для парсинга и перенаправления в базу данных Elasticsearch. Для этого в качестве входящей системы берем логи с межсетевого экрана Check Point.

Синопсис

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

Немного прошерстив Habr удивился тому, что очень мало опубликовано статей на тему (beta-)фичи GitHub'а — Actions.

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

Вместо предисловия

или как так получилось, что появилась эта статья

в котором рассказывается, зачем и почему проводилось это тестирование

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

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

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

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

CheckiO

Проект из Украины «Чекио» сфокусирован на Python и JavaScript. Это сборник игровых задач по программированию для тех, кто уже не новичок. Большой упор на геймификацию, симпатичную графику и общение в сообществе. В самом решении задач игрового процесса нет, но есть общий сценарий для прохождения платформы. Полезная фича — смотреть другие решения и подсказывать студентам как их можно улучшить.

leetcode

Сборник задач по программированию на разных языках. Цель сервиса — готовить программистов к заданиям, которые встречаются на интервью. Платформа сразу даёт фидбэк на правильность и эффективность решения, показывает варианты решений и позволяет обсудить их с другими участниками. В платной версии можно пройти автоматизированное интервью в Google, Facebook или Amazon: робот подберёт вопросы, засечёт время и даже поможет оценить.

Сегодня разговор пойдет о DevOps, а точнее — в основном об Ops. Говорят, что существует очень мало людей, которые довольны уровнем автоматизации своего operations. Но, кажется, ситуация исправима. В этой статье Николай Рыжиков расскажет о своем опыте расширения Kubernetes.



Материал подготовлен на основе выступления Николая на осенней конференции DevOops 2017. Под катом — видео и текстовая расшифровка доклада.

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

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

У многих неюристов при виде очередного договора страниц на 20-30 появляется некий взгляд беспомощности. Немудрено, люди много лет учатся во всём этом разбираться, а потом ещё и практикой оттачивают. Поэтому нередко договоры подписывают не читая, просто посмотрев условия оплаты. Авось пронесёт.

Но эта проблема рукотворная. Приведу аналогию. Если вам нужно быстро сделать корпоративный сайтик, то берёте Wordpress и скачиваете любую из тем. На кой вам нужен Битрикс или уж тем более собственный движок? Или, к примеру, ту же тему надо подправить, хотелок у вас появилось. Но, не хватает знаний. Эту работу сделает большинство фрилансеров из самого низкого ценового диапазона. Зачем вам спец по 50 долларов в час?

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

Почему договоры большие

— Видишь SSAS-суслика?
— Нет…
— И я не вижу. А он есть!


(Кадр из к/ф «ДМБ»)

Поддержка относительно новой табличной (табулярной) модели данных, в противовес устоявшейся многомерной OLAP, встроена в целый ряд продуктов компании Microsoft. Начиная с SQL-сервера (SS) и заканчивая Excel. И если с SS всё понятно – в нём содержится отдельный сепаратный продукт SQL Server Analysis Services (SSAS). А как же решена поддержка языка DAX-запросов и прочей табулярной функциональности в Power BI, SharePoint или Excel? Поищем «суслика» на примере Power BI Desktop.

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

В наших решениях мы используем интеграцию и с помощью Kafka, и с помощью gRPC, и с помощью RabbitMQ.

В этой статье мы поделимся нашим опытом кластеризации RabbitMQ, ноды которого размещены в Kubernetes.



До RabbitMQ версии 3.7 его кластеризация в K8S была не очень тривиальной задачей, со множеством хаков и не очень красивых решений. В версии 3.6 использовался autocluster плагин из RabbitMQ Community. А в 3.7 появился Kubernetes Peer Discovery Backend. Он встроен плагином в базовую поставку RabbitMQ и не требует отдельной сборки и установки.

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

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