23 мая в Слёрм стартует курс «Архитектура приложений: пиши как разработчик, думай как архитектор».
Вы познакомитесь с разными видами архитектуры, научитесь писать чистые управляемые проекты и организовывать код. Уже на курсе получите реальный опыт — детально проработаете архитектуру приложения, опишите её формальную документацию и подготовите к реализации.
Мы запускаем новый практический интенсив «Чистая архитектура приложения на Go», который пройдет 15-17 июля.
За три дня вы изучите, что такое чистая архитектура на языке Golang, и под руководством опытного спикера создадите сервис по работе с контактами и возможностью их группировки.
Чистая архитектура — концепция архитектуры систем, предложенная Робертом Мартином. Предполагает построение приложения в виде набора независимых слоёв, что упрощает тестирование, уменьшает связность и делает код более простым для понимания.
Если архитектура выстроена правильно, приложение легко расширять, поддерживать и обновлять. Если же оставить продумывание архитектуры на второй план, со временем цена внесения изменений в проект будет расти.
21 июля прошёл внешний гибридный митап управления разработки клиентских приложений X5 Технологии с приглашением спикера из Skillbox. Рассказываем (и показываем) как это было.
Проектирование архитектуры — одна из тем, которые обязательно необходимо освоить, чтобы стать действительно хорошим разработчиком: сеньором, лидом, архитектором (по-честному, а не на бумажке).
26 сентября в Слёрме стартует новый курс «Архитектура приложений: пиши как разработчик, думай как архитектор». Вы научитесь писать чистые и управляемые проекты, выйдите на новый уровень в разработке ПО и сможете больше зарабатывать.
В четверг, 15 сентября в 19:00 мск, Слёрм проведёт бесплатный вебинар, где подробно расскажет о часто встречающихся ошибках при проектировании приложений, к чему они приводят и как их избегать.
Бизнесу неважно, как спроектировано и написано приложение. Но бизнесу важно, чтобы продукт удовлетворял потребности пользователей и приносил прибыль.
Если архитектура выстроена правильно, приложение легко расширять, поддерживать и обновлять. Если же оставить продумывание архитектуры на второй план, со временем цена внесения изменений в проект будет расти. Рассказываем о том, почему бизнесу стоит вкладываться в специалистов, занимающихся архитектурой приложений.
Разработка нового функционала для существующего приложения может озадачить любого, поскольку всегда есть различие между изначальным дизайном и текущей реализацией.
Новые архитектурные инструменты в Visual Studio Team System 2010 помогут вам понять имеющееся приложение, спроектировать необходимую вам новую функциональность и проверить что ваша реализация соответствует вашему дизайну.
Самое сложное в любой работе — это начать её. Итак, с чего же начать наше огромное клиентское приложение? В этой части я расскажу с чего начать и затрону три темы: Как организовать код, Что такое фасад, как его построить, что такое компоненты (и, конечно, как их начать писать).
В предыдущей статье мы затронули такие темы: как организовать код, что такое фасад, как его построить и что такое компоненты.
В этой мы коснёмся трёх вещей: продолжим наш разговор об архитектуре компонент, узнаем, что такое плагины и как они помогают в архитектуре, а также, как итог, я дам несколько советов.
В дополнение статейoddy про архитектуру RIA-приложений на основе ExtJS хочу предложить свой, альтернативный подход к данной проблеме. Он состоит в использовании ZendFramework-подобного каркаса xFrame, написанного на JavaScript. Под катом — описание ключевых элементов системы, ссылки на демо приложение и исходный код.
Программные объекты — это обыкновенные классы из ООП. Под взаимодействием программных объектов я буду подразумевать передачу управления из одного класса в другой.
Это можно сделать двумя способами. Далее я буду называть их: объектный и событийный. Названия взяты из объектно-событийной парадигмы, подразумевающей наличие объектов, запускающих и обрабатывающих какие-то события. Но в моем случае, смысл другой. Так же, чтобы не путаться, назовем первый класс, из которого управления передается управляющим, второй класс, принимающий управление, соответственно, исполнителем.
Все разработчики информационных систем сталкиваются с периодической информацией, т.е. данными изменяющимися во времени. Например:
— Цены на товары
— Курсы валют
— Должности
и т.п. Также, одна периодическая информация меняется часто, другая — редко. К редко меняющейся информации можно отнести, например:
— Фамилия и имя
— Адрес проживания
— Статус семьи
Так вот, в большинстве случаев, нет необходимости хранить историю изменения этой редко меняющейся информации, т.к. никто и никогда не будет строить отчет задним числом, чтобы в нем отображалась эта информация, действующая на дату отчета.
В таких случаях достаточно хранить просто факт изменения информации, предыдущее значение и дату изменения — это понадобиться в самых редких случаях.
Дальше пойдет разговор о способе хранения периодической информации в реляционной базе данных для случаев, когда такие отчеты заведомо нужны в системе и они требуют получения актуальных данных на определенную дату.
Масштабируемость, удобство обслуживания и гибкость приложений во многом определяются качеством архитектуры приложения. К сожалению, архитектуру приложения часто относят к второстепенным факторам. Концепты и прототипы превращаются в массовые приложения, а примеры кода копируются и вставляются «как есть» в фундамент многих приложений. Вы можете захотеть двинуться лёгким путём из-за быстрого прогресса, который вы видите в начале проекта.
Разработчики часто просят рассказать о моём опыте использования Backbone.
Многие слышали об этом MVC-фреймворке, смотрели примеры и документацию, но не решаются начать с ним работать. Поэтому вчера я сделал мини-доклад на встрече MoscowJS, призванный рассказать о том, как мы построили базовую архитектуру и какие получили плюсы. И сегодня в этой статье я публикую слайды, схемы и краткое описание.
Существует много разных взглядов на разработку архитектуры и дизайна современных приложений. Некоторые архитекторы стремятся продумать все до мелочей, разрисовать use case-ы всех классов и модулей, проанализировать миллион возможных способов их использования, все их обязательно задокументировать и уже потом приступить к этапу кодирования.
Другие, наоборот, считают, что «думать уже поздно» и давным-давно пора «делать», поэтому они кидаются на баррикады с криками «Ура», выдавая на гора тонны никому не нужного кода. Как и любая крайность, такой подход не приводит ни к чему хорошему. Но, как и во многих других случаях, существует промежуточный вариант, когда проектированию и архитектуре уделяется должное внимание, когда они не ставятся во главу угла, а используются для выявления правильных абстракций и поиска компромиссов в противоречивых требованиях заказчика.
Мой опыт разработки в основном строится вокруг разнообразных сетевых cервисов под Windows и Linux. Я обычно стремлюсь добиться максимальной кроссплатформенности вплоть до бинарной совместимости. И конечно, накопилось некоторое количество стабильных решений связанных с логированием.
Топик написан как продолжение к этой статье и будет полезен в первую очередь начинающим программистам.
Здесь я собираюсь осветить следующие вопросы:
Внутреннее свойство логгера и примеры софта который его использует.
Объемы, уровни и детализация сообщений лога.
Общие правила конфигурации в разработке, в бою и в расследовании.
Уже довольно давно решая задачи проектирования веб-приложений, или веб-ресурсов я использую подход при котором проектирую логику работы исходя из предметной области к которой будет относится веб-приложение. Этот подход ни разу меня не подводил, и зачастую результат работы всегда меня удовлетворял (насколько вообще результат работы может удовлетворять — ведь всегда кажется, что можно сделать еще чуть чуть лучше, и процесс улучшения может быть бесконечным). Однако иногда среди коллег мне приходится встречать мнение, что проектирование с использованием CMS гораздо эффективнее. После последней такой беседы я решил написать статью и поделится своими мыслями с хабра-сообществом.
Я постарался описать оба подхода проектирования и как можно шире раскрыть тот подход, который использую сам.
Этой статьей я не пытаюсь доказать что использование CMS не эффективно. Оно эффективно, но по моему мнению только тогда, когда в будущий ресурс новый функционал вносить не предполагается. И когда изначальный функционал не выходит за пределы «сайта-визитки» (хотя и «визитка» порой может быть достаточно технологичной и требовать для реализации того, чего с ограниченными возможностями CMS добиться достаточно трудоемко).
В этой статье мы рассмотрим архитектуру Android-приложений.
Откровенно говоря, официальную статью Google по этой теме я считаю не очень полезной. Детально отвечая на вопрос «как», она совсем не объясняет «что» и «почему». Итак, вот моя версия, и, я надеюсь, она внесёт некоторую ясность. Да, кстати, я полностью одобряю чтение статей Google, поскольку они содержат полезную информацию, повторять которую я не собираюсь.
В этой статье мы поговорим об архитектурных шаблонах, используемых в Android-приложениях.
Почему важно понимание шаблонов, реализованных в рамках некой архитектуры? Потому что таким образом изучаемая нами новая архитектура укладывается в контекст нашего предыдущего опыта и позволяет нам более эффективно использовать накопленные знания и навыки.
Возможно, я плохо искал, но в документации Android нет упоминания о каких-либо шаблонах. Не смотря на это, в Android реализованы некоторые шаблоны и архитектурные стили, о которых мы сейчас и поговорим.
