▍ Предисловие. Флейта хулуси

▍ Дисклеймер

О том, как сделать прозрачную синхронизацию заметок Obsidian между устройствами (Desktop, Android, iOS) через GitHub:

1. Без сторонних приложений (вроде iCloud, SyncThing, Termux и пр)
2. Бесплатно
3. Бонусом — резервная копия: как самих заметок, так и истории изменений.

В результате получается полноценная замена Notion: структурированные заметки с автоматической синхронизацией между устройствами.

«Не читайте интернет, не занимайтесь самолечением» — слышу я от врачей, и это приводит меня в бешенство. Если бы я этим не занимался, то был бы сейчас хромым, слепым и глухим «овощем» с больными почками.

Я просто опишу несколько случаев, и станет ясно, «почему».

Случай 1. В детстве у меня был обширный ожог на груди от кипящей воды. Мать хотела улучшить мою внешность — уменьшить размер шрамов. Мы пошли с ней к доктору (мне было 6 лет), он вырезал мне большой кусок кожи, от правого плеча до локтя левой руки, а оставшуюся кожу стянул и сшил. Всю жизнь я ходил с этим шрамом от скальпеля, который был ужасно жестким. Для рассасывания шрама мне кололи лидазу, но это не помогло. В результате вместо мягкого шрама от ожога я получил очень жесткий шрам от скальпеля, сейчас он имеет длину в полметра, стянул мои плечи и перекосил положение грудных сосков. В 45 лет этот шрам превратился во что‑то типа кости. Эта «кость» прорвала кожу, вылезла наружу и мне пришлось делать операцию по удалению «кости» с помощью лазера. Та часть шрама от ожога, которая не была тронута скальпелем, осталась мягкой и никогда мне не мешала. Я не знаю, но думаю, моя мать много заплатила хирургу, чтобы он сделал лучше. Это было в 1960 году, прошло только 15 лет после войны, было ведь много раненых и обожженных. Неужели хирург не знал, что получится в результате?

Что я могу думать о врачах после этого? Они лечат или калечат?

Случай 2. В 19 лет у меня появились боли в области сердца, несколько лет не мог спать на левом боку. Пошел к терапевту, сняли ЭКГ — ничего не нашли. При описании жалобы я говорил: «странно, но у меня эти боли проходят после того, как позанимаюсь с гирей». Терапевт и кардиолог, снимавший ЭКГ, посмеялись и отпустили меня ни с чем.

— Ты должен вкручивать по 10 лампочек в минуту! Зачем иначе наша компания закупила подписку на LightGPT? Мы потратили 20 ср*ных долларов на человека! Мне кажется, я сам бы быстрее вкрутил, чем весь ваш отдел…

Как разработчик TeaVM, компилятора байт-кода JVM в JavaScript и WebAssembly, я часто рекомендую пользователям, почему-то жаждущим сгенерировать WebAssembly, начать с JavaScript. Если честно, бэкэнд WebAssembly я очень давно не развиваю, не реализую в нём недостающих фич и не фикшу баги. Меня спрашивают: а почему так? Обычно, я просто игнорирую подобные вопросы, потому что в двух предложениях ответить на них невозможно, а для того, чтобы писать больше предложений, у меня нет времени. Обычно если я встречаю чьи‑то попытки объяснить, чем WebAssembly плох для реализации JVM (а так же, CLR, JavaScript и прочих динамических сред), то они сводятся к следующему: «Java (.NET, JavaScript, ваш вариант) — это управляемый язык со сборкой мусора и исключениями, так что приходится тащить с собой гигантский рантайм». Что же, на самом деле, ситуация несколько сложнее, а размер рантайма вовсе не такой страшный и не является основным источником бед.

Для обеспечения статических проверок каждый метод и аргумент метода должны быть обозначены аннотациями @Nullable и @Nonnull. Чтобы не утонуть в этих аннотациях, можно прийти к соглашению, что аннотацию @Nonnull не нужно указывать, т.е. она станет неявной. Чтобы научить Idea определять отсутствие аннотации как аннотацию @Nonnull нужно выполнить простую настройку.

Началось всё с того, что, покупая какие-то вещи на барахолке, увидел у продавца разные симпатичные дисплейчики от мобильных телефонов и не только за небольшую цену. Решил взять за компанию в количестве трёх штук - "куда-нибудь пригодится". Шло время, делались разные проекты, а дисплеи мирно ждали своего часа где-то на полке. Но вот настал день, когда я добрался до них и решил всё-таки их оживить. Однако вот незадача, о данной модели экрана почти ничего неизвестно... Вот и обратная разработка на подходе. Интересно? Тогда поехали!

Привет, Хабр! Сегодня мы расскажем, как делали в нашей группе анализа данных прототип для уже успешно работающего внутри DLP-системы Solar Dozor движка детектирования графических объектов на изображениях. Покажем это на примере одного его представителя - оттисков печатей на изображениях документов. Вспомним о противоречивых требованиях к решению задачи и очертим бизнес-метрики, определяющие успешное решение. В процессе подберем фильтр наличия печатей из арсенала компьютерного зрения и сравним подходы к детектированию объектов - популярных движках CNN, SIFT и их вариациях. А также поведаем об интересных находках в части создания датасетов. Здесь, как оказалось, немало места для творчества и экспериментов. В общем, запасайтесь попкорном.

• как оценить, насколько успешен портфельный управляющий (посчитать связь доходности портфеля с доходностью рынка);
• кто такая «альфа», и почему все её ищут (доход, превышающий обычную премию за систематический риск);
• какой из участвовавших в сравнении фондов российских акций показал лучший результат (личный портфель автора!);
• какой фокус позволил автору заработать «альфу» (ставка на конкретный систематический риск, который не видит наивная модель).

• как составить оптимальный с точки зрения риска и доходности портфель, не углубляясь в суровую математику (посмотреть на рыночную капитализацию активов);
• как заработать что-то сверх безрисковой процентной ставки (взять на себя риск и на дистанции заработать премию за этот риск);
• любой ли риск вознаграждается премией (нет, только систематический);
• от чего зависит ожидаемая будущая доходность отдельной акции (главным образом, от ковариации со всем рынком);
• сколько зарабатывали инвесторы в рынок акций США (порядка 7–9% в год сверх безрисковой ставки);
• почему так много (возможно, люди не полностью рациональны и преувеличивают рискованность акций);
• можно ли предсказать будущую доходность рынка акций (скорее всего, нет);
• как осадить трейдера на коктейльной вечеринке (спросить, какой у него Шарп).

1. Начальная отрисовка: сколько времени требуется, чтобы пользователь увидел хоть что-то
   
   • Сократить запросы, блокирующие рендеринг
     
   • Избегать последовательных цепочек
     
   • Повторно использовать соединения с сервером
     
   • Сервис-воркеры для мгновенного рендеринга
2. Загрузка приложения: сколько времени требуется, чтобы пользователь смог использовать приложение
   
   • Разбить пакет приложения на части. Загружать только необходимые ресурсы. Максимизация попаданий в кэш
     
   • Проверить, что хэши частей пакета не меняются без необходимости
     
   • Запрашивать данные для страницы до загрузки всего приложения
     
   • Не блокировать рендеринг загрузкой второстепенных данных
     
   • Рассмотреть рендеринг на стороне сервера
3. Следующая страница: сколько времени требуется для перехода на следующую страницу
   
   • Запрашивать дополнительный код до того, как он понадобится
     
   • Кэшировать и повторно использовать данные на клиенте