PHP → Массивы моделей в MVC — вкусно и тяжело?
Парадигма MVC во многом позволяет упростить поддержку кода за счет разделения логики и создания абстракций, однако часто, следуя принципу Thick Model & Thin Controller (он же Fat Model & Skinny Controller), разработчикам приходится упираться в краеугольный камень использования любого объекта-модели, а именно — в потребление памяти. Что особенно актуально при работе с моделями, которые реализуют ORM (или ActiveRecord паттерн).
В данной статье хочу вкратце продемонстрировать стандартные подходы к решению данной проблемы.
JAVA → JTable и Serializable или таблицы в Java и танцы с бубном при сохранении объектов в файлы из песочницы
Введение
Так получилось, что как дизайнеру, мне необходим простор для творчества при реализации любых зачач в написании программ. Давно я положил глаз на такую платформу как Java, так-как всегда мечтал о кроссплатформенном программном обеспечении. И вот недавно, я решил освоить такой прекрассный компонент в Java, как JTable, ну и по той причине, что всегда любил использовать таблицы в своих программах.
В общем, я поставил перед собой не сложную задачу — создать таблицу, которую мог бы сохранять в файл как объект и паралельно отслеживать введенные пользователем данные подсвечивая ошибки и упрощая общение с таблицей моей программы путем подсвечивания наиболее важных элементов таблицы. Так-как я сторонник программирования по принципу пошаговой отладки при написании кода, наличие готовых кусков стабильного кода в сети Интернет, было для меня очень важным… Но… После тщательных поисков, экспериментально было установлено
JavaScript → Три подхода к методологии построения сложного клиентского приложения
Наверно, не существует единого рецепта, который бы всех устроил. Это касается любой проблемы. Для разработчиков этот тезис самоочевиден, и вовлеченность в использование и проектирование отдельных инструментов определяется, главным образом, лишь профессионализмом. Изобретение велосипедов романтично и неизбежно.
Особо вероятно изобретение велосипеда, когда рост сложности приложения происходит постепенно и в некотором смысле незаметно. Сложное приложение обычно является богатым приложением (rich), его элементы и особенности специфицированы W3C www.w3.org/TR/backplane/. Известный JavaScript-евангелист Addy Osmani так дополнительно определяет сложное приложение: “По-моему, крупное JavaScript приложение есть нетривиальное приложение, требующее значительных усилий разработчика для поддержки, причем наиболее сложное оперирование обработкой и отображением данных ложится на браузер” (http://addyosmani.com/largescalejavascript/).
Особо вероятно изобретение велосипеда, когда рост сложности приложения происходит постепенно и в некотором смысле незаметно. Сложное приложение обычно является богатым приложением (rich), его элементы и особенности специфицированы W3C www.w3.org/TR/backplane/. Известный JavaScript-евангелист Addy Osmani так дополнительно определяет сложное приложение: “По-моему, крупное JavaScript приложение есть нетривиальное приложение, требующее значительных усилий разработчика для поддержки, причем наиболее сложное оперирование обработкой и отображением данных ложится на браузер” (http://addyosmani.com/largescalejavascript/).
Node.JS → Маршрутизация запросов в Autodafé
Autodafé — node.js фреймворк, начало читайте в этой статье: habrahabr.ru/blogs/nodejs/135089/
Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.
Начнем со схемы, отображающей подключение клиентов к приложению:
На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)
В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.
Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.
Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.
Откуда берется пыль
Начнем со схемы, отображающей подключение клиентов к приложению:
На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)
В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.
Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.
Node.JS → Autodafé
Autodafe — node.js фреймворк для разработки веб приложений
Самые вкусные плюшки из коробки:
- архитектура: MVC + подключаемые модули
- Mysql ORM (ActiveRecord с поддержкой отношений, асинхронное подобие того, что предлагает Yii framework для PHP )
- HTTP сервер
- WebSockets ( обертка для socket.io )
- удобное перенаправление запросов и человеко понятные УРЛ
- управление пользователями
- аутентификация и авторизация, сессии
- система управления правами ролей пользователей
- почта ( обертка для emailjs )
- логирование в консоль, фс и на почту
- юнит тестирование ( обертка для vows )
- шаблонизатор ( расширенный dust )
Ложка дегтя:
- очень малая часть задокументирована
- задокументированная часть плохо задокументирована
- плохо задокументированная часть задокументирована только на русском языке
- тестами покрыт не весь фреймворк
Блог компании Ciklum → На Сиклум .NET Субботник в Харькове соберутся гуру .NET-разработки!
Обмен опытом, новинками, лучшими практиками и просто неформальное общение — становится все больше популярным. Так, недавно мы проводили .NET Субботник в Минске, а еще немного раньше в Киеве. В этот раз в Харькове 10 декабря на Ciklum .NET Субботник соберутся крутые подкастеры и спикеры по .NET с огромным опытом, которым всегда рады во всех городах Украины. Приглашаем всех, кому интересна разработка в .NET на мероприятие с уникальной возможностью посмотреть и послушать их всех в один день!
По традиции наших Сиклум Субботников участники мероприятия смогут неформально пообщаться, обменяться знаниями и поделиться опытом не только во время докладов на технологические темы по разработке в .NET, но и на протяжении всего мероприятия.
По традиции наших Сиклум Субботников участники мероприятия смогут неформально пообщаться, обменяться знаниями и поделиться опытом не только во время докладов на технологические темы по разработке в .NET, но и на протяжении всего мероприятия.
Программирование → Синхронизация представления с коллекцией из песочницы
Во многих современных языках программирования и фреймворках есть специальные классы коллекций, которые умеют оповещать клиентов при каждом своем изменении. Во Flex этот класс носит имя ArrayCollection, в .Net — ObservableCollection, в ExtJS — Ext.util.MixedCollection и Ext.data.Store, в jWidget — JW.Collection. Такие структуры данных просто необходимы при разработке приложений по схеме MVC (Model, View, Controller). Наиболее часто они применяются в качестве модели для разного рода UI-компонентов: списков, таблиц, аккордионов и пр. В сложных приложениях коллекции нужны для связи нескольких слоев системы между собой.
Сегодня расскажу вам об одном оригинальном способе работы с коллекциями.
Сегодня расскажу вам об одном оригинальном способе работы с коллекциями.
Блог компании Intel → История развития форматов видеосжатия
Далёкий 1988й год был полон удивительных событий. В этом году увидел свет 4й альбом группы Metallica «...And justice for all», а СССР запустил в свой первый и единственный полёт многоразовый космический корабль «Буран». В этом же году началась история видеосжатия – появился самый первый стандарт видео-кодека.
Самые известные стандарты видеосжатия появились благодаря двум конторам: VCEG и MPEG. Нельзя назвать их конкурентами: некоторые стандарты были выпущены комитетами поодиночке, некоторые стали плодом ихзапретной любви коллективной работы в составе объединённых групп. По иронии судьбы именно эти «совместные» форматы и получили наибольшее распространение.
Итак, 1988 год. H.261 стал первым полноценным форматом видеосжатия, получившим широкое распространение. Это был «классический» стандарт, работающий в цветовом пространстве YCbCr, базирующийся на дискретном косинусном преобразовании блоков и сжатии Хаффмана. Поднимите руку те, кто слышал о нём? А ведь именно в этом стандарте впервые появились такие понятия, как макро-блок, целопиксельный вектор движения и де-блокинг (или пост-процессинг). А еще именно тогда, 23 года назад, появилась концепция опорных кадров. H.261 предусматривал кадры 2х типов: I(ntra) – полностью независмый кадр, и P(redicted) – кадр, зависимый от предыдущего. Максимальное разрешение CIF (пример приведён слева), поддерживаемое H.261, сейчас не впечатлит даже любителей смотреть видео на телефоне. И тем не менее, для своего времени это был очень прогрессивный, весьма «продвинутый» стандарт. Все последующие стандарты видеосжатия базируются на идеях, берущих свое начало в H.261, и де-факто являются результатом его эволюционного развития.
Самые известные стандарты видеосжатия появились благодаря двум конторам: VCEG и MPEG. Нельзя назвать их конкурентами: некоторые стандарты были выпущены комитетами поодиночке, некоторые стали плодом их
1988 год – H.261
Итак, 1988 год. H.261 стал первым полноценным форматом видеосжатия, получившим широкое распространение. Это был «классический» стандарт, работающий в цветовом пространстве YCbCr, базирующийся на дискретном косинусном преобразовании блоков и сжатии Хаффмана. Поднимите руку те, кто слышал о нём? А ведь именно в этом стандарте впервые появились такие понятия, как макро-блок, целопиксельный вектор движения и де-блокинг (или пост-процессинг). А еще именно тогда, 23 года назад, появилась концепция опорных кадров. H.261 предусматривал кадры 2х типов: I(ntra) – полностью независмый кадр, и P(redicted) – кадр, зависимый от предыдущего. Максимальное разрешение CIF (пример приведён слева), поддерживаемое H.261, сейчас не впечатлит даже любителей смотреть видео на телефоне. И тем не менее, для своего времени это был очень прогрессивный, весьма «продвинутый» стандарт. Все последующие стандарты видеосжатия базируются на идеях, берущих свое начало в H.261, и де-факто являются результатом его эволюционного развития.Блог компании Ciklum → Собираемся на новый Ciklum Субботник в Минске — теперь по .NET! Присоединяйтесь!
Если вам интересны новинки, лучшие практики в разработке на NET и ASP .NET и просто общение с коллегами — все это сможете увидеть и услышать и активно принять участие во время Ciklum .Net Субботника, который состоится 12 ноября (уже в эту субботу) в минском офисе Ciklum.
Напомним, что в наших офисах как по всей Украине, так и в Беларуси постоянно проходят Ciklum Saturdays, собирающие разработчиков по различным технологиям
Напомним, что в наших офисах как по всей Украине, так и в Беларуси постоянно проходят Ciklum Saturdays, собирающие разработчиков по различным технологиям