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

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

Система доменных имён разрабатывалась как замена hosts файлам, и в то время, в ограниченной среде университетских сетей никто не думал о безопасности. Всё основывалось на доверии. Ещё буквально лет 8-10 назад никто не думал о том, что трафик между сервером DNS и клиентом можно записывать для продажи, либо заменять для достижения своих целей. Но уже в то время существовали трояны, добавляющие записи в локальный файл hosts, чтобы перенаправлять пользователей на подконтрольные серверы. В последние несколько лет появилось несколько новых протоколов, которые помогают устранить перехват или подмену трафика DNS. Но это только смещение точки доверия от одной группы провайдеров, к другой.

Но есть способ сделать создание и синхронизацию доменных имён и записей DNS очень простыми, да ещё и безопасными и не подверженными цензуре.

Я так проникся «клиентоориентированным» отношением операторов связи к своим абонентам, что сделав 4 расследования по скрытым мобильным подпискам, решил пойти дальше и проверить: а как они относятся к персональным данным абонентов? 

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

Вы ещё не слышали, как профессор Гарвардской школы бизнеса «наживается» на своих студентах? Тогда вам, наверное, будет интересно узнать о том, как продать 20 долларов за гораздо большую сумму. Скажем, долларов за 200.

Профессор Макс Базерман придумал эксперимент, который демонстрирует необъяснимое иррациональное поведение будущих профессиональных бизнесменов и менеджеров в их родной стихии — управлении проектами. Кстати, в эту же ловушку попадают и топ-менеджеры крупных компаний, с которыми профессор проводит свои семинары.

Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...

Каждая карьера развивается от Жопы к Жопе, и никак иначе. Хочешь повышения - ищи Жопу и принимай, как говорят в Америке, "challenge". Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.

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

Вдохновением для этих занятий послужила замечательная статья из Science, которая убедила меня и многих других в том, что к таким задачам в принципе можно подступиться. Как и у авторов статьи, наш пример будет немного игрушечным, хоть и для совсем другой физической системы. Более того, мы ещё сильнее ограничим пространство поиска (до формул, что тоже немало), зато обойдёмся без 32 процессорных ядер и без GPU, а решение получим меньше чем за минуту против десятков минут или даже пары дней, как в статье. Для всего этого нам понадобится лишь 300 строк кода на C — и никаких фреймворков.

Всё началось с мема, который вы видите выше.

Сначала я посмеялся. А потом задумался: может ли быть так, что скриншот базы равноценен её снэпшоту?

Для этого у нас должно быть такое графическое представление базы, которое 1 к 1 отображает данные и структуру. Если сделать скриншот такого представления, из него можно восстановить базу.

Или... графическое представление и должно быть базой!

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

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

Если вам приходилось задумываться о построении эффективной экосистемы проекта и определении ролей тимлида и разработчика — статья Артема Прозорова из ZeBrains для вас.

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

Какая из команд может реализовать более технически стабильный продукт? 

Команда №1: Проектный менеджер, аналитик, тестировщик и несколько разработчиков, у каждого из которых за плечами минимум три года опыта. Все работают в одном офисе, посвящая свое время одному проекту в режиме fulltime.

Команда №2: Один сильный разработчик. Ему помогают множество не знакомых между собой людей из разных часовых поясов. У каждого — свой набор компетенций и уровень опыта. Работой над проектом участники занимаются в свободном режиме, по несколько часов в неделю.

* * *

Ответ на этот вопрос получим к концу статьи.

Привет, Хабр. Меня зовут Макс. Я специализируюсь на реконструкции и развитии процессов. Сегодняшняя история про баги. Не баги вообще, а про вполне конкретную их категорию.

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

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

Возможно Вам доводилось слышать про протокол журнала событий syslog, в котором можно насчитать аж 8 уровней важности: emergency, alert, critical, error, warning, notice, info, debug. Наверняка Вы, как и я какое-то время назад, думаете, “зачем столько”? А что если я скажу, что количество уровней там просто идеально? И использовать можно все - даже debug - для продакшн. Во всяком случае, каждому из них можно придать формальный критерий. Это особенно иронично для меня самого, так как всего пару месяцев назад я написал статью в духе “зачем так сложно!”. Так что если Вам интересно посмотреть на пример технического “переобувания” или оценить строгий алгоритм ранжирования уровней важности событий в системе - прошу.

Познакомившись впервые с языком Котлин после продолжительной работы с Java меня воротило от одной мысли, что null-safety может быть полезен и вообще переменная без null - не примитив, но я сам этого не осознавал.

Когда я работаю с файлами в Node.js, меня не оставляет мысль, что я пишу очень много однотипного кода. Создание, чтение и запись, перемещение, удаление, обход файлов и подкаталогов, всё это обрастает неимоверным количеством бойлерплейта, который еще усугубляется странными названиями функций модуля fs. Со всем этим можно жить, но меня не оставляла мысль, что можно сделать удобнее. Хотелось, чтобы такие элементарные вещи, как, например, чтение или запись текста (или json) в файл можно было написать в одну строчку.

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

По некоторым источникам еще в IV до нашей эры Аристотель задался одним простым вопросом — Что было раньше? Курица или яйцо? Сам он в итоге пришел к выводу, что и то, и другое появилось одновременно — вот это поворот! Не правда ли?

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

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

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