Java Dev.
Продолжаем работать с 10.3.
КМБ.- Двойная жизнь.- Восстание мертвецов.- Ошибка в документации.- Ужасающие подробности из The Rustonomicon.- Архитектурные озарения.- Развязка.
В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам "Дядя Боб" пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).
Сейчас же я хочу рассказать, что такое монады на самом деле, чем они полезны для обычного практикующего разработчика, и приведу примеры, почему недостаточная поддержка их в распространенных языках приводит к копипасте и ненадежным решениям.
Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?
Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.
Получается, что первые обычно полезны тем, кто и так знает обсуждаемую тему, а вторые даже не знаю на кого рассчитаны: сколько я их не прочитал, ничего полезного понять из них мне не удалось.
Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.
Я, Георгий Меликов, являюсь контрибьютором проектов OpenZFS и ZFS on Linux. Также я занимаюсь разработкой IaaS в команде облачной платформы Mail.ru Cloud Solutions. Хотя в продакшене нашего подразделения мы и не используем ZFS, но хозяева подкаста SDCast пригласили меня рассказать именно о нём. Из выпуска и родилась эта статья, а вот тут можно послушать аудиоверсию.
Итак, сегодня я рассказываю про ZFS. Как устроена файловая система ZFS, из каких компонентов она состоит и как работает, а также про новые фичи, которые появились или скоро появятся в последних релизах.
Здравствуй, в данной статье я хочу в максимально сжатой форме познакомить тебя с основами создания простых 2d платформеров на движке Godot. Иногда мы будем останавливаться на некоторых важных моментах, а иногда пропускать ненужную тебе на начальном уровне информацию. Надеюсь из этой статьи ты сможешь извлечь максимум пользы. Приятного прочтения!
На Хабре очень много статей про прокрастинацию, её уже закрывали, хоронили… но все они очень технические — конечно, это Хабр, сэр!
На мой взгляд, GTD и всякие планы спасения не работают, а чаще усиливают прокрастинацию. Они не решают фундаментальную причину, а пытаются сгладить последствия. Я же хочу предложить вам совсем другой взгляд, основные причины и другие методы решения.
TL;DR> Наш мозг поделен между отдельными и самостоятельными Человеком и Зверем. Разлад между ними — причина прокрастинации, выгорания и случаев, когда мы выбираем не то, что хотим на самом деле. Зверь отвечает за очень многие процессы, а мы не привыкли его слушать.
Я поделюсь своими методами работы со Зверем. Если интересно — добро пожаловать под кат.
EXPLAIN [ANALYZE].
Никакой воды в этой статье, только описание конкретного плана действий в случае если вы перегорели, у вас дедлайн, прокрастинация, депрессия, а также методики и советы, помогающие привести этот план в действие.
Эта статья содержит лишь малую часть информации по заявленной теме. Рассматривайте ее как вводный курс перед началом всестороннего изучения предмета. Надеюсь, вы найдете в ней полезную информацию. Знание дискретной математики помогает описывать объекты и задачи в информатике, особенно когда дело касается алгоритмов, языков программирования, баз данных и криптографии. В дальнейшем я планирую подробнее раскрыть темы, затронутые в этой статье. Приятного чтения!
Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».
Полтора килограмма термоядерного Тринидадского Скорпиона я в итоге собрал с одного куста на гидропонике.
У меня было много довольно странных хобби. Некоторые приводили к странным эффектам, вроде массового домашнего производства домашнего порошка для посудомойки. В список к этому странному ряду я решил добавить еще один пункт. Теперь я развлекаюсь еще и с гидропоникой. Причем эффект получился еще более адовый, чем я ожидал.
Тема чудовищно огромная, охватить ее за один пост вряд ли получится, поэтому я постараюсь ограничиться описанием принципа, почему это вообще работает и дать максимально исчерпывающий мануал, чтобы каждый смог из желудей и спичек повторить мой эксперимент. В самом начале будет много теории. Можете ее проскочить и сразу перейти к нужным покупкам, а вернуться к ней позже.
Книга Мир после капитала американского инвестора немецкого происхождения Альберта Венгера — один из наиболее значимых текстов об экономике после капитализма.
Этот перевод мы делаем сообществом энтузиастов совершенно бесплатно.
Привет, Хаброжители! Книга Джейсона Грегори не случайно является бестселлером.Двадцать лет работы автора над первоклассными играми в Midway, Electronic Arts и Naughty Dog позволяют поделиться знаниями о теории и практике разработки ПО для игрового движка. 
При создании программного обеспечения все мы, как команда, соглашаемся следовать набору рекомендаций, которые обычно считаются лучшими практиками. Но во время разработки разработчики могут нарушить эти правила по незнанию или нежеланию. Обычно мы полагаемся на ревью кода или инструменты проверки качества кода, такие как SonarQube , PMD и т.д. для проверки таких нарушений. Но некоторые из рекомендаций могут быть решениями, которые нельзя автоматизировать с помощью SonarQube, PMD и т.д.
Например, обычно я хочу следовать приведенным ниже рекомендациям для моих приложений на основе Java:
1. Следуйте трехуровневой структуре (уровни веб, сервис, репозиторий), где любой уровень может взаимодействовать только с непосредственным нижним уровнем, а нижний уровень не должен взаимодействовать с верхним уровнем. т.е. веб-уровень может взаимодействовать с уровнем сервиса, уровень сервиса может взаимодействовать с уровнем репозитория. Но уровень репозитория не может взаимодействовать с сервисным или веб-уровнем, сервисный уровень не может взаимодействовать с веб-уровнем.
2. Если приложение большое, мы могли бы захотеть следовать структуре Package-By-Feature, где только компоненты Web и Service являются public, а остальные компоненты должны быть package-private.
3. При использовании внедрения зависимостей Spring не используйте внедрение на основе поля и предпочитайте внедрение на основе конструктора.
Таким образом, может быть много правил, которым мы хотим следовать. Хорошая новость заключается в том, что мы можем проконтролировать выполнение этих рекомендаций с помощью JUnit тестов с использованием ArchUnit.
