Блог компании DevExpress → Сторонние компоненты — деньги на ветер или экономия средств?
Многие их тех, кто использует .NET, Delphi и другие средства разработки, рано или поздно сталкивались с выбором: разработать что-то недостающее самому, или приобрести готовое? И со спокойной душой отправлялись писать свои собственные компоненты, неприятно поразившись стоимостью существующих. А так ли велика их цена на самом деле? Вот небольшая история, которая заставила меня взглянуть на стоимость компонентов другими глазами.
JavaScript → Притча об автоматическом менеджменте виджетов
— Здравствуй…
— А-а-а! Памагите! Убивают! \(0_0)/
— Дружок, спокойно, я свой :-\
— Свои незаметно сзади не подкрадываются! \(@_@)/
— А я динамически добавился В-]
— Э-э-э \(~_~)/
— Ясно, не знаешь, как реагировать на такие ситуации? XD
— Ну… как бы… есть мысли… \(=_=)/
— Покажи-ка свой исходник %-)
— Я… эта… стесняюсь… \(._.)/
— Давай, не боись, я же свой ;-)
— Лаааадно \(-_-)/
— А-а-а! Памагите! Убивают! \(0_0)/
— Дружок, спокойно, я свой :-\
— Свои незаметно сзади не подкрадываются! \(@_@)/
— А я динамически добавился В-]
— Э-э-э \(~_~)/
— Ясно, не знаешь, как реагировать на такие ситуации? XD
— Ну… как бы… есть мысли… \(=_=)/
— Покажи-ка свой исходник %-)
— Я… эта… стесняюсь… \(._.)/
— Давай, не боись, я же свой ;-)
— Лаааадно \(-_-)/
<body>
<script>
$(function(){
$('.c-example').wrapInner( '<span class="wrapper" />' )
})
</script>
<div class="c-example">epic</div>
</body>Персональные блоги → Jython vs Groovy vs JRuby vs …
Господа, внезапно — сабж!? Вопрос вызван тем, что какое-то довольно продолжительное время я был вдалеке от Java-технологий, писал на C++ и Python (и продолжаю писать), но один из курсов университета (конкретнее — component based software development) будет требовать либо одного из JVM-based языков (Java отпадает за неинтересностью) либо .NET языков (отпадает по определению так как Windows у меня нет и не будет). Немного изучив вопрос, пришел к выводу что:
Пока начал играться с Groovy и он мне, в принципе, нравится — но возможно, я упускаю что-то существенное, ограничивая себя этим языком?
Всем хабралюдям заранее спасибо за мнения!
- Преимущества в пользу Jython — по большому счету, это Python, который я хорошо знаю и люблю, с возможностью использовать Java классы. Но, если верить слухам, сейчас он почти не развивается. Хотя опять же, кому верить-то?
- Преимущества Groovy — новый язык, активно развивающийся, комбинирующий в себе достоинства многих языков и парадигм (тот же Python и Ruby в них входят). Недостатки — новый язык, активно развивающийся ;-) Сравнительно мало документации и кода по сравнению с Python
- Преимущества JRuby… я что-то весь в затруднениях, но все о нем говорят. Полная совместимость с Ruby, да. Но Руби я все равно не знаю, так что учить с нуля, так же как и Groovy.
Пока начал играться с Groovy и он мне, в принципе, нравится — но возможно, я упускаю что-то существенное, ограничивая себя этим языком?
Всем хабралюдям заранее спасибо за мнения!
symfony framework → Кеширование в Symfony. Идеология HTML-кеширования. Components & partials
За 2.5 года использования symfony мне постоянно приходится сталкиваться с проблемой недопонимания программистами на symfony идеи html-кеширования. Цель этого поста — донести до светлых умов symfony-девелоперов осознание парадигмы использования partials & components.
Delphi → Delphi: Как избавиться от published свойств
Вводная
Работая над PostgresDAC'ом наша комманда встречалась с этой проблемой дважды. И оба раза изменения затрагивали компонент TPSQLDump, как наиболее интенсивно изменяющийся. Это и понятно, каждый серьезный релиз сервера PostgreSQL вносит порой в параметры pg_dump существенные изменения. А нашей задачей является полная совместимость TPSQLDump с pg_dump.
JavaScript → Контекстное меню на javascript: небольшое, но мощное
Вы наверняка не раз видели javascript-реализации контекстных меню на базе популярных библиотек, таких как jQuery и prototype. А значит обязательно сталкивались с основными их недостатками: неудобностью API, большим количеством кода, требовательностью к ресурсам, любовью к генерации огромного количества html кода. В один прекрасный момент эти проблемы пересилили мою лень и я решил бороться с ними, поставив следующие задачи:
UPD: разместил проект в google code, пользуйтесь, развивайте:
- Минимум html кода, генерируемого для меню (зачем нам засорять ДОМ)
- Лаконичность js кода для создания меню (API вызова без копипасты)
- Оптимум гибкости при работе (многоуровневые, динамически модифицируемые меню)
- Как можно меньше кода в реализации библиотеки (6302 байта в несжатом виде)
- Минимальное количество jQuery-вызовов (чтобы можно было легко от них отказаться тем, кто jQuery не использует)
- Inline-события где это возможно вместо биндов (меньше ресурсов сожрет)
UPD: разместил проект в google code, пользуйтесь, развивайте:
svn checkout js-cmenu.googlecode.com/svn/trunk/ js-cmenu-read-onlyPHP → frontier — фреймворк для php 5.1
В общем, начинаю постепенно выкладывать троды плудов на суд общественности. На http://www.frwk.net появились уже трак проекта и блог, куда я мало-помалу буду постить информацию о фреймворке.
Вкратце: Frontier предоставляет связи между компонентами, легко помогает подключать различные прикладные библиотеки, а сам предлагает только структуру приложения, общую конфигурацию и т.п. Краткое описание оформлено одним из постов там же: http://www.frontierframework.net/blog/20…
Основная мотивация изобретения этого велосипеда была в том, что очень уж надоели тяжёлые фреймворки, которые навязывали свои решения по многим поводам, хотелось в первую очередь свободы: не перекраивая модель мышления писать разные приложения с использованием разных же библиотек. Сначала думал, что буду делать с его помощью только мелкие вещи, но на серьёзных проектах "Фронтир" тоже проявил себя неплохо.
Буду рад всяческим комментам.
По просьбе: http://www.frontierframework.net/release… — это минимальное приложение с комментариями на русском.
Вкратце: Frontier предоставляет связи между компонентами, легко помогает подключать различные прикладные библиотеки, а сам предлагает только структуру приложения, общую конфигурацию и т.п. Краткое описание оформлено одним из постов там же: http://www.frontierframework.net/blog/20…
Основная мотивация изобретения этого велосипеда была в том, что очень уж надоели тяжёлые фреймворки, которые навязывали свои решения по многим поводам, хотелось в первую очередь свободы: не перекраивая модель мышления писать разные приложения с использованием разных же библиотек. Сначала думал, что буду делать с его помощью только мелкие вещи, но на серьёзных проектах "Фронтир" тоже проявил себя неплохо.
Буду рад всяческим комментам.
По просьбе: http://www.frontierframework.net/release… — это минимальное приложение с комментариями на русском.