На днях я прошёл Т1 Академию. Было очень круто. AOP, Spring Boot Starters, интеграционные тесты, и многое другое. Прошёл, кстати, очень хорошо - 85% по ДЗ. Ожидал, как всегда, худшего (не со стороны курса, а именно со своей стороны - я не считаю себя крутым челом по Java), но ничего - я начал активно использовать практики оттуда в своих проектах. Особенно в плане тестирования кода - интеграционное тестирование позволило найти серьёзные ошибки в моих заброшенных пет-проектах, и сделать возможным автоматическую проверку изменений в коде через тот же GH Actions.
Ну и есть небольшой шанс, что я попаду (с их точки зрения) в список лучших кандидатов, и попаду к ним на работу. Хотя >=80% для них это считается отличным показателем (я это спрашивал в чате), и шансы будут вроде как выше. Но это не точно. Мне кажется, что тот, кто чекал моё ДЗ, сто процентов заглядывал и в остальные уголки моего гитхаба, и не удивлюсь, если это сильно повлияло как раз на оценку.
Если сотрудник работает сверхурочно, потому что хочет продемонстрировать лояльность и ценность, логичнее сделать так, чтобы единственный результат переработки — это деньги, а не карьерные бонусы. Тогда переработки станут осознанным выбором, а не скрытым способом выслужиться.
Мне в рамках обучения в колледже пришлось поставить 1С. Ох как я намучился с ним. На арче - обязательно GTK2 (без него инсталлятор не работает), потом ещё зависимости, и только тогда 1С заработает. Ладно, ставлю Distrobox и Podman, разворачиваю там Дебиан, настраиваю contrib и non-free (на всякий случай), запускаю инсталлятор (пакета у них нету, только ранфайл) - всё поставилось, кроме webkit2gtk. Ладно, пришлось тянуть мне его вручную, и только тогда всё заработало.
Но это ещё не всё - захотелось мне поставить полный учебный комплект, вместе с частями из ИТС, демобазой, и прочей фигнёй. Но для этого пришлось Etersoft@WINE поставить (линукс-версии оного нету), а это одно мучение. В частности, он не прописывает нормально иконку приложения (PATH содержит двоеточие, что решается с помощью вайновского drive_c), плюс ему надо только определённые дистрибутивы (на арч официально его не поставить). В итоге проблему кое-как решил, но понял, что полный комплект мне не нужен, и поставил нативный 1С в контейнер с Дебианом.
Сейчас 1Ска работает более-менее, учу, конфигурацию делаю, все дела. Гита в 1С-мире, походу, нету. Поэтому облака наше всё. Хотя бы можно экспортировать конфигурацию в один файл без БД, и на том спасибо.
Причём, судя по всему, минимальное работоспособное приложение (со справочниками и простыми отчётами) можно сделать вообще без кода - можно сказать, что это вполне себе low-code-платформа.
"О, великие принципы SOLID, благословите мой код на чистоту и ясность. Пусть функции мои будут едины в своей ответственности, как воины в строю, и не возьмут на себя бремя чужих забот. Пусть классы мои будут открыты для расширения, но закрыты для изменения, как крепость, стойкая против врага. Да не нарушит новый код работу старого! Пусть заменяются мои подтипы без нарушения порядка, как звенья одной цепи. Пусть интерфейсы будут разделены, как ветви дерева, и зависимости инверсированы, как отражение в зеркале. Пусть будет так, как завещал Мартин, и код мой будет чист, как ряса, как помыслы мои."
Все знают про канареечные релизы (canary deployment). Это когда новую версию сначала выкатывают на небольшую группу пользователей, чтобы проверить, не задохнется ли канарейка. Но что делать, когда нужно релизить много и регулярно? Тут нам на помощь приходят петушиные релизы!
Что такое петушиные релизы?
Петушиные релизы - это когда все обновления выкатываются рано утром, пока пользователи еще спят. Как петух, который встает с первыми лучами солнца, команда разработки поднимается засветло, чтобы подготовить свежую версию продукта к началу рабочего дня.
Преимущества подхода:
Более высокий когнитивный ресурс у инженера с утра - "утро вечера мудренее"
Минимальное влияние на пользователей (они еще спят)
Время на "настаивание" релиза перед началом активного использования
Возможность быстро откатиться, если что-то пошло не так
Предсказуемый график релизов
Возможность обновить все сервисы системы одновременно в тихий утренний час (даже если релиз не будет бесшовным, это вряд ли кто-то заметит - все полусонные)
Когда это особенно полезно?
Когда бизнесу нужны новые фичи "еще вчера"
При работе с микросервисной архитектурой
Когда команда распределена по разным часовым поясам
Исторический контекст
Как петухи исторически помогали людям вовремя просыпаться и спасали от пожаров своим криком, так и петушиные релизы помогают командам поддерживать здоровый баланс между скоростью доставки и стабильностью системы.
И помните: лучше регулярные петушиные релизы, чем ждать, пока жареный петух клюнет!
Я долго не писал статьи на Хабре, ибо я не вижу каких-либо идей для этого, которые бы взорвали Хабр. Про Java писать точно не могу - моей квалификации недостаточно для относительно хорошей статьи.
Хотел ещё про (SCO/Xinuos) OpenServer и UnixWare (которые самые свежие, Defenitive 2018, c Maintenance Pack 1) что-то написать, но чего можно написать про, по сути, обычный SysV для x86? Линукс образца середины 90-х будет куда лучше (и богаче по функционалу) OpenServer 6 из 2005 года. Единственный плюс - это обилие GUI для настройки всего на свете (погуглите про scoadmin - будет интересно). Но терминал - фу, без history и autocomplete мне не удобно вообще.
Red Hat Linux 0.9? Тоже будет интересно. Но ранние Линуксы тоже не шибко прям интересные - пакетов мало, GUI - обычный FVWM/TWM, интернет хоть и работает, но чисто чтобы пингануть ya.ru, да может ньюсы (Usenet news) где-то достать с оставшихся ньюс-серверов. Ну может ещё почту принять по SMTP. И всё, по сути.
Может Red Hat Linux 5.2? Ну, обычный Linux с FVWM95, и тоже с гуёвым конфигуратором (как в RHL0.9 и SCO - тогда было модно обмазывать гуём всё, что попадётся в руки).
Позвольте представить вам концепцию эллинского подхода в архитектуре.
Она черпает вдохновение из древнегреческих устных традиций и философского подхода к обмену знаниями. Как известно, Сократ выступал против письменной фиксации философских идей, полагая, что письмо не может передать всю глубину и сложность мысли так, как это делает устное общение.
Вот некоторые потенциальные преимущества такого подхода в контексте программной архитектуры:
Личное взаимодействие: Устный обмен информацией подразумевает тесное общение, что может способствовать лучшему пониманию и командной работе.
Гибкость: Отсутствие строгой документации может сделать процесс более адаптивным и гибким.
Быстрое принятие решений: Устное общение обычно быстрее письменного, что может ускорить процесс принятия решений.
Фокус на главном: Отсутствие необходимости в документации может позволить команде сосредоточиться непосредственно на разработке.
Представьте, какими чудесными были бы наши рабочие встречи! Никаких утомительных записей - только живой диалог в лучших традициях античной Греции.
Однажды Диоген увидел, как разработчик читает требования и плачет, а слёзы смывают грязь с его лица. Диоген перестал ходить к реке умываться, сказав: «Мальчик превзошёл меня в простоте жизни».
В мире разработки программного обеспечения, как и в философии, существуют различные школы мысли, подходы и мировоззрения. Каждый архитектор и разработчик — осознанно или нет — следует определённым принципам, которые, для нужд этой статьи, удивительным образом перекликаются с древними философскими учениями. Давайте рассмотрим эти параллели.
Я нагуглил некоторое количество философских школ и спешу предложить вам такую аналогию:
Киники — просто и минималистично.
Платоники — невыносимо сложно и идеалистично.
Стоики — надёжно, но рано или поздно всё упадёт.
Софисты — красиво, но непрактично.
Прагматики — работает, и ладно.
Схоласты — бесконечные обсуждения архитектуры, но ни одной строчки кода.
Теперь давайте остановимся подробнее на каждой школе мысли.
Киники
«Зачем нам фреймворк? Есть же bash!»
Документация? «Читайте код».
CI/CD? git push --force решает все проблемы.
Docker? systemd нам в помощь.
Намеренно пишут неортодоксальный код, чтобы «встряхнуть» команду.
Проводят демонстрации багов прямо на проде.
Платоники
Реальный код — это лишь несовершенная тень идеального дизайна.
Каждый баг — это лишь тень несовершенства реального кода.
Нам нужен ещё один слой абстракции между абстракциями.
Простое решение не может быть правильным по определению.
В идеальном мире каждый метод — это интерфейс.
Настоящая архитектура существует только в UML-диаграммах.
Стоики
Падение прода неизбежно, а каждая ошибка может стать последней.
Стремление важнее результата — «Ничего не получилось, но мы сильно старались».
Никто не ощущает баги — о них только думают.
Не облекай свой код в пышные абстракции.
Люди пишут код с багами невольно.
Являюсь ли я частью проблемы или её решения?
Если вы слышите, как кто-то читает молитву о безмятежности, то перед вами стоик: «Боже, дай мне душевный покой принять тот код, который я не могу изменить, мужество изменить тот, что могу, и мудрость отличить одно от другого».
Софисты
Красота кода важнее его практичности.
На код-ревью больше обсуждают стиль, чем функциональность.
«Да, это медленнее работает, зато посмотрите, какая архитектура!»
Могут убедить заказчика, что баг — это фича.
На код-ревью побеждает не самый правый, а самый красноречивый.
Прагматики
«Работает? Не трогай. Не работает? Почини как можешь».
Документация? «Код сам себя документирует».
Архитектура — это то, что получилось в итоге.
Технический долг? «Будущие проблемы решим в будущем».
«Лучшее — враг хорошего, а рефакторинг — враг работающего».
Схоласты
Команда может месяцами обсуждать «идеальную архитектуру».
Создаются сложные диаграммы и документация.
Проводятся бесконечные митинги по дизайну.
Каждое решение требует согласования на архитектурном комитете.
Но реальный код так и не пишется.
Заключение
Возможно, главный урок, который мы можем извлечь из этой аналогии — это то, как много вокруг людей с неправильными подходами и мировоззрениями. Но не унывайте и помните мудрые слова Марка Аврелия:
Сегодня мне придётся столкнуться с людьми навязчивыми, неблагодарными, заносчивыми, коварными, завистливыми, неуживчивыми. Эти свойства проистекают от незнания ими добра и зла. Я же, познавший прекрасную природу добра и постыдную — зла, понимаю и природу тех, кто заблуждается.
Я наконец-то отказался от join fetch, и перешёл на Entity Graphs. Это позволило сделать HQL-код более красивым, и при этом не доводить обратно до N+1. Плюс это банально удобнее, нежели join fetch.
Здравствуйте, дорогие хабрачане! Недавно закрылся Хабр Фриланс, возможно единственной фриланс-площадкой с адекватным комьюнити. Итак я предлагаю вместо неё другое решение больше подходящие тематике сайта (т.к. в основном здесь сидят программисты-энтузиасты описывающие свои ощущения) и возможно, представляющая другой подход к экономике как например эта
В современном мире, где информационный шум и высокая конкуренция становятся неотъемлемой частью нашей жизни, найти единомышленников и ресурсы для реализации своих идей становится настоящим вызовом. Каждый день мы сталкиваемся с потоком информации, который затрудняет поиск тех, кто разделяет наши ценности и стремления. Гении, творцы и новаторы часто остаются непризнанными, их идеи теряются в океане шума, а талант — не находит должного признания.
Представляю вам уникальную площадку startdelu.ru, созданную моим знакомым специально для энтузиастов у кого есть много свободного времени, но не знает как эффективно его потратить не только для себя, но и для пользы всего сообщества, кто ищет поддержку и вдохновение. Здесь вы сможете не только найти единомышленников, но и привлечь необходимые ресурсы для реализации своих проектов, указав что у вас уже имеется, а что ещё нужно привлечь.
Делается это просто. Регистрируемся на сайте. Выбираем тип идеи (коммерческая или некоммерческая/волонтёрская). Описываем свою идею и указываем свои свои "способности и потребности". Дизайн сайта настолько прост, что с ним справится может даже ребёнок! Ещё одной отличительной особенностью сайта есть наличие личных сообщений с автором поста, что делает его своего рода социальной сетью.
Пока у сайта небольшое комьюнити состоящая только из знакомых его автора, да и он ещё сырой и нуждается в доработке, например, отображение статуса текущего проекта и т.п. Но я думаю что он не умрёт и ещё заслужит нашего внимания, пока существуем мы!
Я пока не знаю, стоит ли рассказывать про то, как я вообще впервые, вживую, столкнулся с N+1 в хибернейте (если точнее - в Spring Data JPA), пока писал своё подобие nodehist.wfido.ru (там ещё очень много работы придётся проделать с этим - да, это тот самый NodehistJ), и как я "отучил" Hibernate от этого, доведя всё это до минимально необходимого для данного проекта количества запросов в БД вообще? Честно говоря, это пока единственное, что пришло в голову, когда захотелось написать что-то, в чём сейчас имею свой личный опыт.
Привет всем. Это снова Егор Гаврилов. И я недавно запилил библиотеку для парсинга нодлистов Фидонета.
Сейчас я делаю второй свой проект по Фидо на Java - NodehistJ. Это аналог nodehist.wfido.ru, но на Java. Часть кода я уже написал, пока оно работает чисто как "текущий нодлист по REST API". Скоро будет и S3, и Redis, и полноценный браузинг по нодлистам разных эпох Фидонета, и даже подобие микросервисной архитектуры (загрузка архива нодлистов будет происходить через отдельный сервис, который будет работать через спринговый шедуллер).
Пока проект недоступен публично, но в ближайшее время оно будет готово.
Сейчас задам один простой вопрос - вы хотите ещё больше контента про Фидонет? Или сделать что-то прикольное - например, про старые дистрибутивы Linux. Или вообще хотите кулсторию про меня?
Я вернулся на Хабр, уже под новым ником @oldzoomer. То удаление аккаунта было моей ошибкой, так как это был один из самых топовых аккаунтов - оно было на 110 месте по рейтингу Хабра, благодаря статьям про Фидонет.
Может кто-то из читателей продаст 3.5" дисплейчик-шилд рублей за 500? С алика дороговато (аж тыщу рублей!) и долго. Протокол или SPI, или 8080 8-битный (не 16!).
Уважаемые хаброжители. Нам нужна ваша помощь! Наш мастер имеет великую цель, цель связанную с созданием своей успешной геймстудии . И эта цель очень перспективная с любой точки зрения. Мы будем заниматься разработкой очень глубокой и главное рабочей во всех смыслах игры, на которую нам могут дать неплохой фонд с очень высокой вероятностью. Нам нужен человек, пока на правах разработчика на вольных началах. Человек, который умеет строчить на юнити, или анреал эджин. Второй вариант предпочтительнее.
Не знаю, что должно быть в таких постах, поэтому расскажу обо всем понемногу. Вот 5 фактов обо мне:
Дополнительный факт: люблю разные шутки и каламбуры
1. Я родился и вырос (не сильно, всего 176см) в Ярославле. Уже пятый год живу в разных городах, но все равно скучаю по родным местам.
2. Очень люблю театр. Настолько, что получил образование театрального критика, чтобы ходить на спектакли “по работе”. А еще мы с женой создали театр “Облака” и даже показали мини-спектакль на театральном фестивале в Центральном Вьетнаме.
3.Музыкант-самоучка. Вырос на песнях Тома Уэйтса и White Stripes, в более сознательном возрасте открыл для себя Ивана Дорна, Noga Erez и других классных музыкантов. Сначала пробовал повторять за ними, потом нашел свой стиль, но все еще люблю экспериментировать. Сейчас пою в проекте kultura и развиваю личный проект Yorzay. А еще я пишу музыку для игр, приложений и рекламных роликов. Говорят, получается отлично.
4. Очень люблю животных. В том числе поэтому уже более 10 лет не ем мясо. И, конечно, не могу пройти мимо уличных котов и собак: и если не могу забрать к себе, то хотя бы подкармливаю. Сейчас у меня дома живут кот БаньСео и пес Пупа. Животные становятся моим “домом”, где бы я ни был.
5. Очень люблю учиться, но с трудом нахожу на это время и силы. Поэтому я часто нахожусь в поиске ленивых, но эффективных методов обучения. Мое недавнее открытие - система интервального повторения. Это крутая техника, которая помогает запоминать слова, фразеологизмы, художников, понятия - да что угодно. Если вы, как и я, пользовались приложениями вроде Memrise, Drops, Anki или Quizlet, то скорее всего тоже неплохо прокачались, а потом стали “забывать” тренироваться (я сдался через 25 дней). Чтобы точно заниматься каждый день, я решил геймифицировать систему интервального повторения под себя. Так я придумал образовательный телеграм-тамагочи TamaPupaBot с полезными квизами. Теперь я каждый день кормлю и убираю какашки не только в жизни, но и в Телеграме). Смешно, но факт: даже виртуальное животное, которому необходим уход, дисциплинирует (Пупу жалко!), а прохождение квизов дает быстрый дофамин и помогает запоминать те же английские фразеологизмы. До апреля планирую сделать еще пару квизов (хочу копнуть в сторону философии и продолжить учить английский), а также разработать обучающую настольную игру. Посмотрим, куда меня это приведет!
Если тебе интересно читать меня дальше, буду рад познакомиться поближе! Напиши в комментариях как ты изучаешь что то новое!
Сегодня утром увидел чудо чудное. Курьер на электровелосипеде ехал с адекватной скоростью, включенной фарой и (о боже!) на переходе слез с велика и перешел дорогу пешком! Захотелось догнать его и подарить шоколадку.
А что, если бы в приложении доставки была возможность лайкнуть любого курьера? Не того, который привез ваш заказ, а именно чужого, встреченного на дороге.
Форма простая: галочки "ехал аккуратно", "включил фару", "перешел дорогу правильно". Ниже - окно для ввода номера курьера (они сейчас есть у всех) и кнопка для сабмита. Главная киллер-фича - можно только одобрить курьера, но не нажаловаться.
Что сервис будет делать с такими данными? Ну, доску почета организует, может :), мотивация - великая вещь. Скама и накруток можно не бояться, т.к. гео с приложения доставки есть и можно смэтчить - действительно ли я нахожусь рядом с курьером, которого лайкаю.
Единственную проблему, которую я вижу - это невозможность глобального взаимодействия. То есть в приложении Яндекс.Еды нельзя будет лайкнуть курьера "Самоката". Т.к. обмен данными между двумя крупными конкурирующими компаниями - всегда бюрократия и трэш. А пилить независимый сервис, который бы транслировал компаниям-доставщикам лайки для их курьеров - экономически невыгодно.
Идея бесплатная - дарю: X5, @powertothepeople, @kuper_tech (не знаю, есть ли на Хабре представители других сервисов доставки)
