Возникла передо мной такая задача: сделать мониторинг Raspberry PI. И требования:
Неделя Spring на Хабре, судя по всему, открыта. Хочется сказать спасибо переводчику и комментаторам статьи "Почему я ненавижу Spring", которая не смотря на сильный негативный посыл в названии вызвала ряд интересных дискуссий, а так же тем, кто отреагировал на мою прошлую статью Как писать на Spring в 2017. Во многом благодаря комментариям к прошлой статье и появилась эта.
В этот раз мы погрузимся в пучины Spring фреймворка, разоблачим его магию, посмотрим как базовое веб приложение выглядит изнутри, и разберемся, какую-же задачу и как решает Spring Boot.
В прошлом посте мы остановились на том, что мы умеем добавлять массив входных погодных данных, а точнее данные "Время + температура", слегка попробовали использовать Behavior и разобрались с концептами.
Пришло время делать что-то полезное, ведь пока все, что мы реализовали, можно было реализовать на любом другом языке, за исключением прикольного синтаксиса.
Первым делом, введем ограничения на время. Сейчас мы ограничим его, чтобы часы были в пределе 0-24, а минуты 0-60, иначе будет выдаваться ошибка компиляции.
Constraints это аспект языка, который отвечает за валидность реализации концепта. В нашем случае нам нужно ограничить property hours и minutes, поэтому мы создаем Constraints аспект концепта Time.
Здесь мы видим 3 пункта, которые отвечают за структуру AST.
can be ancestor: все то же самое, что с parent, но более вложенно: в данном случае мы можем идти как угодно выше по AST, дословно — может ли узел быть предком
Пару недель назад я опубликовал “дорожную карту” по развитию для iOS-разработчиков. Теперь, как и обещал, — подобная подборка ресурсов для тех, кто работает с Android. Важный момент — разных источников много, но я выбрал именно те, что постоянно читаю сам, и в чём нахожу пользу. Итак, регулярные рассылки, блоги (личные, коллективные и в видеоформате), подкасты, живые чаты на русском языке, telegram-каналы и огонь-события — всё здесь, под катом.
Читать полностью »
Привет! На первый взгляд название этой статьи может показаться вам странным: Java и Visual Studio – что между ними общего? Зачем вообще Visual Studio, когда есть множество других классных инструментов для разработки на Java: Eclipse, NetBeans, IntelliJ IDEA и прочих (холивар устраивать не будем). На самом деле, Visual Studio сейчас – это не просто среда для разработки, а целое семейство продуктов, где IDE Visual Studio лишь один из инструментов. Под катом мы поговорим о Microsoft Visual Studio Team Services (VSTS).
Спасибо всем за критику в комменте под первым постом, где я хотел попробовать написать про MPS, не затрагивая важные темы, чтобы можно было потом более качественно начать писать по порядку.
В комментариях к 1 посту было следующее высказывание
С этой точки зрения, DSL — это как фреймворк, только с более удобным интерфейсом. Ясное дело, под один проект фреймворк делать никто не будет, за исключением совсем уж монструозных случаев. А сделать его под конкретную предметную область — почему бы и нет?..
В принципе, так оно все и работает. Хорошие языки похожи по сути на хорошие фреймворки: они позволяют писать что-то важное, не заморачиваясь о том, что мы не хотим писать. По ходу повествования я буду периодически обращаться к другим языкам для аналогий и сравнений.
Язык Weather, который мы хотим реализовать, должен выполнять следующую задачу: мы должны уметь лаконично выражать условия (погода сегодня, например) и следствия (погода завтра, послезавтра...).
В языке Weather мы будем делать наши прогнозы отталкиваясь от 1 фактора: от температуры на сегодняшний день(массив объектов время + погодные условия).
Добрый вечер. У нас тут подходит к концу перевод Appium Essentials. Что уже пройдено:
В этой главе:
Я наткнулся на статью Нареша Джоши о копировании и клонировании и был удивлён ситуацией с производительностью. У клонирования есть проблемы с финальными полями. А учитывая тот факт, что интерфейс Cloneable не предоставляет метод clone, то для вызова clone вам необходимо будет знать конкретный тип класса.
В начале своей карьеры я реально влюбился в Spring. Я так долго ждал его. Я использовал его во всех своих проектах. Вдобавок мне даже удалось впихнуть туда кучу всякой всячины из Spring Integration. Я был кем-то вроде короля XML. Я делал RPC-слой на основе JMS, protobufs и Kaazing для всего нашего отдела и банка в целом. Я думал: «Это так конфигурируемо. Всего-то пара XML-файлов — это действительно гибко». Я был очень доволен собой.
Но некоторые мои коллеги были склонны не согласиться. У них возникали проблемы, когда они пытались связать всё так, как им хочется; они не знали, где какие XML-файлы им нужны. Были проблемы с версиями Spring, с тем, как подружить их (я, к тому же, далеко зашел с модульностью: у нас было 5 или 6 разных модулей с разными номерами версий, и нельзя было просто так взять и понять, какой из них использовать, не спросив меня). Это были тревожные звоночки, но я их не замечал; я думал, что нужно больше документации или что те ребята просто тупые. Такая ситуация типична сама по себе: мольбы пользователей одного из самых нелюбимых и трудных в использовании фреймворков о помощи часто разбиваются о «да там один файл и немного параметров, это не так уж и тяжело», в то время как все остальные целыми днями пытаются найти магическую комбинацию файлов и параметров, чтобы хоть что-нибудь как-нибудь заработало.
Я всё ещё работаю в той же организации, но теперь я пользователь своего старого фреймворка. В результате этого питания кормом своей собаки я стал ненавидеть Сэма (автор имеет в виду себя — прим. пер.) 2009-2010 годов по нескольким причинам, но в основном — за Spring. Spring — это зло в хорошую погоду, но когда его включают в состав библиотеки или API, которым пользуются другие программисты, — это уже другой уровень зла: как плод любви Гитлера и дьявола. Не позволяйте Spring торчать из вашего API наружу.
В конце мая я оказался среди слушателей конференции Scala Days в Копенгагене. Одним из ключевых спикеров был создатель языка Scala Мартин Одерский. Он рассказал о развитии языка и, в частности, о разработке компилятора, названного Dotty. Планируется, что на основе Dotty будет разработан новый компилятор для версии 3.0.
Мартин не раз выступал на эту тему, и я бы хотел собрать здесь всю актуальную информацию о Dotty – новые ключевые возможности и элементы, удаленные за ненадобностью.
Мартин Одерский. План развития Scala на ближайшие несколько лет
Этот пост будет полезен и знатокам, и совсем новичкам, для которых разговор о Dotty я предваряю рассказом об особенностях Scala, а также о том, что лежит в его математической основе.
Читать полностью »
