В общем, начинаю постепенно выкладывать троды плудов на суд общественности. На www.frwk.net появились уже трак проекта и блог, куда я мало-помалу буду постить информацию о фреймворке.
Вкратце: Frontier предоставляет связи между компонентами, легко помогает подключать различные прикладные библиотеки, а сам предлагает только структуру приложения, общую конфигурацию и т.п. Краткое описание оформлено одним из постов там же: www.frontierframework.net/blog/2008/03/29/the-travel-begins

Основная мотивация изобретения этого велосипеда была в том, что очень уж надоели тяжёлые фреймворки, которые навязывали свои решения по многим поводам, хотелось в первую очередь свободы: не перекраивая модель мышления писать разные приложения с использованием разных же библиотек. Сначала думал, что буду делать с его помощью только мелкие вещи, но на серьёзных проектах «Фронтир» тоже проявил себя неплохо.

Буду рад всяческим комментам.

По просьбе: www.frontierframework.net/release/hello.tar.gz — это минимальное приложение с комментариями на русском.

Вы наверняка не раз видели javascript-реализации контекстных меню на базе популярных библиотек, таких как jQuery и prototype. А значит обязательно сталкивались с основными их недостатками: неудобностью API, большим количеством кода, требовательностью к ресурсам, любовью к генерации огромного количества html кода. В один прекрасный момент эти проблемы пересилили мою лень и я решил бороться с ними, поставив следующие задачи:

• Минимум html кода, генерируемого для меню (зачем нам засорять ДОМ)
• Лаконичность js кода для создания меню (API вызова без копипасты)
• Оптимум гибкости при работе (многоуровневые, динамически модифицируемые меню)
• Как можно меньше кода в реализации библиотеки (6302 байта в несжатом виде)
• Минимальное количество jQuery-вызовов (чтобы можно было легко от них отказаться тем, кто jQuery не использует)
• Inline-события где это возможно вместо биндов (меньше ресурсов сожрет)

UPD: разместил проект в google code, пользуйтесь, развивайте:
svn checkout js-cmenu.googlecode.com/svn/trunk js-cmenu-read-only

Вводная

Работая над PostgresDAC'ом наша комманда встречалась с этой проблемой дважды. И оба раза изменения затрагивали компонент TPSQLDump, как наиболее интенсивно изменяющийся. Это и понятно, каждый серьезный релиз сервера PostgreSQL вносит порой в параметры pg_dump существенные изменения. А нашей задачей является полная совместимость TPSQLDump с pg_dump.

За 2.5 года использования symfony мне постоянно приходится сталкиваться с проблемой недопонимания программистами на symfony идеи html-кеширования. Цель этого поста — донести до светлых умов symfony-девелоперов осознание парадигмы использования partials & components.

Господа, внезапно — сабж!? Вопрос вызван тем, что какое-то довольно продолжительное время я был вдалеке от Java-технологий, писал на C++ и Python (и продолжаю писать), но один из курсов университета (конкретнее — component based software development) будет требовать либо одного из JVM-based языков (Java отпадает за неинтересностью) либо .NET языков (отпадает по определению так как Windows у меня нет и не будет). Немного изучив вопрос, пришел к выводу что:

1. Преимущества в пользу Jython — по большому счету, это Python, который я хорошо знаю и люблю, с возможностью использовать Java классы. Но, если верить слухам, сейчас он почти не развивается. Хотя опять же, кому верить-то?
2. Преимущества Groovy — новый язык, активно развивающийся, комбинирующий в себе достоинства многих языков и парадигм (тот же Python и Ruby в них входят). Недостатки — новый язык, активно развивающийся ;-) Сравнительно мало документации и кода по сравнению с Python
3. Преимущества JRuby… я что-то весь в затруднениях, но все о нем говорят. Полная совместимость с Ruby, да. Но Руби я все равно не знаю, так что учить с нуля, так же как и Groovy.

А какие еще мнения есть? Я пока еще не совсем понял, что именно мне нужно для этого курса (хотя ясно, что это что-то должно поддерживать хорошую умную компонентную модель для работы в распределенных средах), но язык, в конце концов, вторичен — хочется чего-то интересного, нового и необычного (не сказать “странного”). Кто что думает? Вопрос довольно практический, потому что 18 января надо начинать писать курсовой проект на этом языке, который я выберу — а его надо еще и изучить хотя бы минимально до этого момента ;-)

Пока начал играться с Groovy и он мне, в принципе, нравится — но возможно, я упускаю что-то существенное, ограничивая себя этим языком?

Всем хабралюдям заранее спасибо за мнения!

— Здравствуй…
— А-а-а! Памагите! Убивают! \(0_0)/
— Дружок, спокойно, я свой :-\
— Свои незаметно сзади не подкрадываются! \(@_@)/
— А я динамически добавился В-]
— Э-э-э \(~_~)/
— Ясно, не знаешь, как реагировать на такие ситуации? XD
— Ну… как бы… есть мысли… \(=_=)/
— Покажи-ка свой исходник %-)
— Я… эта… стесняюсь… \(._.)/
— Давай, не боись, я же свой ;-)
— Лаааадно \(-_-)/

<body><br>    <script><br>        $(function(){<br>            $('.c-example').wrapInner( '<span class="wrapper" />' )<br>        })<br>    </script><br>    <div class="c-example">epic</div><br></body>

Многие их тех, кто использует .NET, Delphi и другие средства разработки, рано или поздно сталкивались с выбором: разработать что-то недостающее самому, или приобрести готовое? И со спокойной душой отправлялись писать свои собственные компоненты, неприятно поразившись стоимостью существующих. А так ли велика их цена на самом деле? Вот небольшая история, которая заставила меня взглянуть на стоимость компонентов другими глазами.

Привлекая внимание на проблемы, описанные в статье — «Шаблон MVC — это тупик для разработки приложений?», я считаю, что недостаточно подробно объяснил сам механизм MVC. И для колоритности в этой статье хотел бы осветить и MVP. Думаю, что важно понимать различия между MVC и MVP и общие моменты этих двух парадигм.

Чтобы понять разницу, давайте сначала посмотрим, в каких условиях прижился MVC и какие преимущества он давал приложениям.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

При создании большого и сложного приложения, обычным подходом является разделение функциональности по отдельным модулям. Также желательно минимизировать количество статических ссылок между этими модулями. Благодаря этому, модули можно будет независимо разрабатывать, тестировать, развёртывать и обновлять. Всё это ведёт к необходимости модулей взаимодействовать друг с другом слабо связанным образом.

При построении модели взаимодействия между модулями, необходимо знать отличия между подходами, чтобы знать, какой из них применить в конкретном сценарии. Библиотека Prism предоставляет следующие подходы:

• Использование команд (Solution commanding). Используйте для реагирования на действия пользователя.
• Контекст региона (Region context). Используйте для передачи контекстной информации от host-элемента управления к представлениями в регионе. Этот подход в некотором роде аналогичен DataContext, но не полагается на него.
• Общие службы (Shared services). Вы можете вызвать метод на сервисе, который, в свою очередь, сгенерирует событие, на которое могут быть подписаны получатели. Используйте этот подход в том случае, если все остальные подходы не применимы.
• Агрегация событий (Event aggregation). Для передачи сообщений между моделями представлений, презентерами, или контроллерами при отсутствии ожиданий о непосредственной реакции на сообщение.

Для загрузки стал доступен Firefox для десктопов. Что нового в этой версии:

«Ага!», подумал я, когда прочитал у Paul Tyma про то, что строить бизнес на продаже средств разработки, может быть не самой лучшей идеей.

Пол высказал мысль, что разработчики привыкли к тому, что большинство средств разработки доступно бесплатно, а значит продать разработчикам что-либо может быть сложно. В некоторых областях, таких как Java-разработка, якобы вообще не принято ничего покупать. С другой стороны, разработчики для Windows / .NET более склонны платить.

Эта статья о том, как написать универсальный JavaScript-компонент, который можно будет использовать

• как React-компонент;
• как Preact-компонент;
• как Angular-компонент;
• как Web Component;
• как jQuery функцию для рендеринга в DOMElement;
• как нативную функцию для рендеринга в DOMElement.

Зачем и кому это нужно

Мир JavaScript-разработки очень фрагментирован. Есть десятки популярных фреймворков, большая часть из которых абсолютно несовместима друг с другом. В таких условиях разработчики JavaScript-компонентов и библиотек, выбирая один конкретный фреймворк, автоматически отказываются от очень большой аудитории, которая данный фреймворк не использует. Это серьезная проблема, и в статье предложено ее решение.

В этой статье хочу поделиться переводом интересных размышлений на тему прошлого и настоящего в архитектуре фронтенда.

В то время как все больше и больше фронтенд-разработчиков перенимают подходы с однонаправленной архитектурой, возникает вопрос — есть ли будущее у классического MVC? Чтобы понять, как мы дошли до такого вопроса, давайте немного проанализируем эволюцию архитектуры фронтенда.

В прошедшую субботу в офисе Avito прошел SPA Meetup. Это митап-сателит Moscow.js, ориентированный на фронтенд-разработчиков, которым интересна тема веб-приложений (Single Page Application), и сочувствующих им. Это уже третья встреча, которая получилась весьма насыщенной: 3 доклада, 2 блица, свободный микрофон, панельная дискуссия и, конечно же, живое общение. В этом посте мы немного расскажем о том, как это было, и поделимся видеозаписями докладов.

Речь в данной статье пойдет о довольно необычном сочетании технологий: Vue.js + TypeScript + Webpack, в разрезе single-file компонентов. Решение данной задачи отняло у меня приличное количество времени с первого захода, поскольку исчерпывающее объяснение того, как использовать все это вместе, да и еще с рядом ограничений (NPM предоставляет нам runtime-only build Vue.js), найти в цельном виде практически невозможно. Если вас заинтересовала данная тема, то приглашаю к дальнейшему чтению.

Объектное Реактивное Программирование

Дмитрий Карловский из SAPRUN представляет… ммм...

Это — текстовая версия одноимённого выступления на FrontendConf'17. Вы можете читать её как статью, либо открыть в интерфейсе проведения презентаций, либо посмотреть видео.

Надоело..	Чем поможет ОРП?
… писать много, а делать мало?	Пиши мало, делай много!
… часами дебажить простую логику?	Реактивные правила обеспечат консистентность!
… асинхронщина?	Синхронный код тоже может быть неблокирующим!
… что всё по умолчанию тупит?	ОРП оптимизирует потоки данных автоматом!
… функциональные головоломки?	Объекты со свойствами — проще некуда!
… что приложение падает целиком?	Позволь упасть его части — само поднимется!
… жонглировать индикаторами ожидания?	Индикаторы ожидания пусть сами появляются, где надо!
… двустороннее связывание?	Двустороннее связывание нужно правильно готовить!
… пилить переиспользуемые компоненты?	Пусть компоненты будут переиспользуемыми по умолчанию!
… вечно догонять?	Вырывайся вперёд и лидируй!

Меня зовут Сергей, я работаю старшим дизайнером в компании Acronis. В отделе дизайна продуктов для бизнеса я отвечаю за разработку и внедрение единой библиотеки компонентов.

Так как у нас много продуктов и сервисов, а дизайн в этих продуктах и сервисах сильно отличается, мы решили его унифицировать и привести к единому UI. Зачем? Все просто: такой подход дает возможность оптимизировать работу отдела, сосредоточить дизайнеров на UX, ускорить процесс разработки и запуск новых продуктов, снизить нагрузку на отделы тестирования и значительно сократить количество багов на стороне front-end. В этой статье я расскажу о нашем опыте, остановлюсь на инструментах и покажу, как устроена библиотека изнутри.

Меня зовут Сергей, и я все еще работаю старшим дизайнером в компании Acronis. Мы продолжаем оптимизировать работу отдела дизайна продуктов для бизнеса и все больше интегрируемся в процессы на стороне front-end разработки.

В прошлой статье я рассказывал о создании библиотеки компонентов, выборе инструментов и взаимодействии с разработчиками. В этой статье я сделаю акцент на мелочах. Расскажу про SVG шрифты, работу с иконками и приправлю рассказ толикой автоматизации с использованием Gulp.

Тестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Всё время смущали вопросы простоты поддержки и применения, но в большей степени — пропускная способность решений. Хотелось, чтобы это было что-то простое в использовании и быстрое в работе. Готовые решения не подошли, и мы взялись делать свое.

Под катом расскажем, что из этого вышло, какие задачи решали, и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов. Этот пост — расшифровка доклада, который прозвучал на HolyJS 2017 Moscow. Видео можно посмотреть по ссылке, а почитать и посмотреть слайды — далее.

Hello Habr! I'm Miloš from Badoo, and this is my first Habr post, originally published in our tech blog. Hope you like it, and please share and comment if you have any questions

So… React, amirite???

It appeared in the middle of the decade (plagued by the endless JavaScript framework wars), embraced the DOM, shocked everyone by mixing HTML with JavaScript and transformed the web development landscape beyond recognition.

All those accomplishments, without even being a framework.

Love it or hate it, React does one job really well, and that is HTML templating. Together with a great community and a healthy ecosystem, it’s not hard to see why it became one of the most popular and influential JavaScript libraries, if not the most popular one of all.