Поток сознания
6 дней назаддавно уже конечно было ясно, но теперь с выходом новой версии флеша html5 выглядит как дополнительная функция к cs5.6))
1 неделя назад...если речь о front end. Для back end'а единственно верный выбор - текстовый редактор Midnight Commander'а :) Вообще просто хотел высказать (наверно, банальную) мысль о том, что идеальная IDE должна строиться именно на "максимально быстром" текстовом редакторе. Путь визуализации - хорошая идея, но опасная. На данный момент "визуальность" должна возникать в мозге программиста - и не понимаю, почему все так стараются перенести нагрузку с этого самого ("несчастного"?!) мозга на что-то иное :) - с помощью визуализации, прививания жёстких принципов ООП, шаблонов проектирования и т.д. Необходимо что-то более радикальное, что не будет строить железные заборы на пути свободной мысли... :)
1 неделя назад[URL=http://i.cx/29z7][IMG]http://i069.radikal.ru/1202/03/9f40d01e407f.png[/IMG][/URL] [b]скачать программу рыбалка 1.6 [/b] [b]скачать проигрыватели для компьютера с картинками [/b] [b]окна приветствия для windows xp скачать [/b] [b]скачать miranda русская версия [/b] [b]скачать original soundtrack driver parallel lines [/b] bb.txt open error база велкома скачать 2009 скачать пакет обновления для среды скачать бесплатную игру кто хочет стать миллионером для пк виста хом премиум скачать скачать поезд train 2008/1400 mb скачать драйвера для аудио реалтек section 8 скачать лицензионную скачать wwe legends patch скачать utorrent 1.6.1 rus visual basic 6.0 скачать скачать антихакер касперского скачать catalyst 6.2 win98 евгений немец скачать kassy 071 скачать скачать программу антропометрии http://beta.purifying.info/viewtopic.php?f=2&t=326117 http://dragonphoenix.brinkster.net/phpbb/phpbb3/viewtopic.php?f=1&t=480248 http://www.erotikapromuze.cz/viewtopic.php?f=4&t=131850 http://programaradar.com.br/forum/viewtopic.php?f=2&t=1062486 http://yfb.messageboard.nl/forum/viewtopic.php?f=1&t=59502
2 недели назадСкачал. Посмотрел. CreateJS - фуфел, шейп твин не поддерживает, маски не поддерживает, эффекты не поддерживает и тд. В общем можно только двигать туда сюда, ну и вложенную анимацию поддерживает. К паблишу для air/android добавили пару галочек - молодцы. В общем изменений максимум на adobe flash cs5.6.
2 недели назадВот именно сегодня очень захотелось пощупать функцию экспорта в CreateJS, а именно сегодня беты уже нет, скачать еще нельзя...
3 недели назадПо правду говоря, создается впечатление, что Adobe в последнее время или зарплату подняли или кнуты менеджерам выделили. Последние версии продуктов выглядят так, будто над ними действительно работали. Обновили не только внутренности и алгоритмы, но и над внешним видом неплохо постарались.
3 недели назадХм, я в этом начинающий, буду знать каким редактором лучше верстать, спасибо!
3 недели назад+1 sublim`у достойная замена GVIM. Как текстовый редактор с большим комьюнити и встренным python интерпертатором, и полностью податлев на костоматизации. нет смысла сравнивать IDE с текстовым редактором. Очень удобно писать erlang программы. Есть плагин для Юнитестов.
3 недели назадКол-во строк в файле с кодом - важный параметр. Есть мнение, что оно не должно быть слишком большим. Для удобства навигации по нему.
Легковесные редакторы хороши еще и тем, что в них бытрее появляются инновации. Например, обрати внимание на мини-текст в правом верхнем углу скриншота для Sublime - по нему можно скроллить мышкой, мгновенно перемещаясь в нужное место кода.
Textastic как раз использует тачевые возможности - для этого у него есть клавиши-компасы (есть на скриншоте). Такая клавиша-компас имеет пять значений. Если просто нажать ее - сработает значение по умолчанию (символ посередине). Остальные четыре символа можно выбрать, если нажать и протянуть пальцем в сторону одного из них.
Визуальное программирование -- это очень интересная, но небанальная тема.
Ведь текст имеет иную структуру, чем изображение.
Текст - условно одномерный, линейный. Изображение - фиксированно двумерное (или фиксированно трехмерное).
Кажущаяся одномерность текста обманчива, особенно когда текст становится кодом. За счет функций (замыканий) и условных переходов текст программы становится многомерным. Даже вне программирования существуют многомерные тексты - хорошая книга может содержать внутренние указатели и ссылки на части самой себя. Поэтому текст - очень продвинутый способ работы с сознанием читателя (или компилятором).
Не вижу возможнлости проделать то же самое с изображением. У него другая природа, и визуальное программирование будет похоже на обычное так же, как графика или живопись похожа на литературу.
До сих пор попытки визуального программирования не заходили дальше имитации обычного - надергали компонентов, но потом - все равно пишем код.
Визаульное программирование - это не способ создавать код мышкой (или тачами), а способ программировать другие каналы восприятия - не аналитические (компилируемые), а эмоциональные.
Кстати, ближе всего к этому подошел флэш. Но потом его убили бизнесом, а из трупа сделали геймдев :)
Так визуальное программирование остается мечтой масс и уделом гениев-одиночек.
3 недели назадБрррр... Легковесные редакторы кода хороши только для легковесных (~20 строк кода) программ. Для всего остального - Idea и FDT.
А редакторы для мобильных устройств зачем-то делают такими же, как на десктопах (у которых есть нормальная клавиатура), при этом совершенно не используя возможности тач-скринов. Думаю, через годик-два появятся наконец мобильные редакторы, где можно будет писать программу чисто жестами, без "волшебных" кнопок.
О Code Behind во Flex — еще раз
Наглядные официальные статьи по Code Behind во Flex уже есть, включая статьи о Code Behind на русском и украинском, рекомендующие этот подход новичкам во Flex. Напишем о нем еще раз, так как мы о нем толком еще не писали. Это упущение, ведь Code Behind относится к лучшим практикам!
"Code Behind" означает, что код находится за чем-то. А зачем это нужно?
Code Behind помогает стройно разделить код приложения по задачам. Код, в котором задается дизайн находится в одном классе, а код с собственно логикой работы — в другом, том самом, который "Behind".
Во Flex это выражается в том, что Actionscript находится за кодом MXML. Один из возможных (и хорошо работающих, проверенных подходов) к Code Behind реализуется с помощью т.н. Base-классов. Начнем с главного приложения проекта:
1. Для приложения создается базовый Actionscript-класс, в простейшем случае расширяющий родной флексовый класс Application:
package core
{
public class ApplicationBase extends Application
{
...
}
}2. Этот класс затем и используется как базовый в коде MXML-класса самого приложения:
<?xml version="1.0" encoding="utf-8"?>
<core:ApplicationBase ... >
...
</core:ApplicationBase>
Что мы получили: есть Actionscript-класс ApplicationBase, в котором мы контролируем MXML-приложение. То же самое мы делаем и для всех остальных MXML-компонентов нашего проекта: создаются AS-классы с именами, соответствующими шаблону ComponentNameBase, а MXML-компоненты используют эти классы как базовые — точно так же, как было показано выше для кода Application.
В таком подходе использование тэга Script в MXML-коде сводится к нулю и является, говоря упрощенно, уже плохой практикой.
Таким образом достигается четкое разделение вычислительной логики и дизайна приложения. Логика идет в Actionscript, дизайн — остается в MXML-коде.
Комментарии
Рост, я про це якраз писав - http://noubase.com/flex/how-to-split-view-control-and-model-my-point-of-.... У нас всередині тіми - це стандарт
Це правильний стандарт. До речі, я на твого поста посилаюс на початку цього запису
а пример так и не расширил ) а публика ждет
Лично я против Code Behind )
Как показывает мой опыт кроме геморроя он ничего не приност.
Я уже писал у nouba в блоге:
Вообще я бы отнес кодбехаинд к методу разделения “вью от логики” на простого разделения кода на 2 файла, но никак не к архитектуре и реализации MVC.
На масштабных проктах это только путает (учитывая убогость реализации билдера быстро скакать по чужому коду просто неудобно). Практической выгоды НЕТ! Есть только красивая теория.
В проекте, в котором я сейчас участвую, семь модулей, из которых одни являются библиотеками для других (или всех), с общим количеством классов до трех тысяч, не считая полутыщи MXML-файлов.
И везде юзается описанный Code Behind. Неудобств никаих не заметил (кстати, похоже, что поставленный на Eclipse 3.4.0 плагин Flex Builder 3 рабоатет с этим лучше, чем Flex Builder 3 Standalone, но не могу утверждать этого сейчас на 100%).
Еще сильный аргумент за такой подход -- в нем отсутствуют описанные Racer'ом "прелести" работы блока Script в работе автокомплита...
Так что Code Behind - это лучшая практика. Насчет MVC это или нет — думаю, здесь надо смотреть на конкретные примеры, "your mileage may vary"
Незнаю, незнаю. Может, что "русскому хорошо, то немцу смерть".
Как по мне лишняя, никому ненужная работа да и только. Как не крути на один компонент как минимум приходится 2 файла. MXML и AS приче они просто держат внешний вид в одном файле, а логику (порой пипец какую сложную и перегруженую логику) в другом.
Все это создает красивую иллюзию разделения отображения и логики. На практике, получается очень связаные компоненты.
Незнаю, незнаю. Может, что "русскому хорошо, то немцу смерть".
Как по мне лишняя, никому ненужная работа да и только. Как не крути на один компонент как минимум приходится 2 файла. MXML и AS приче они просто держат внешний вид в одном файле, а логику (порой пипец какую сложную и перегруженую логику) в другом.
Все это создает красивую иллюзию разделения отображения и логики. На практике, получается очень связаные компоненты.
Двумя руками за! Чем хуже наследоваться от МХМЛ реализации и писать функционал поверх?
А листенеры можно изначально вбить пустыми protected методами.
Также очень понравилась позиция насчет дробления МХМЛ. Практика подсказывает что при правильном последовательном мышлении у Flex-программиста МХМЛ получается разбит/гранулирован на достаточно мелкие части. Большие скопления кода в одном файле получаются достаточно редко, и как правило присущи программистам неопытным.
А наследование наверное исключительно из-за code-hinting приплели.
Иначе каким-то легкомысленным кажется наследование во имя того чтобы вынести код в отдельный файл. Задачу то эту можно решить используя банальный include.
Я полностью согласен с Ильей. Считаю, что нужно написать пост-опровержение. Ибо этот пост плохому учит. А на посты из этого блога очень многие равняются.
Рост, не слушай хулителей описанной практики!
Я вот сейчас активно занимаюсь интерфейсами (и пониманием их принципов) - суть тот же Code Behind, так вот это очень удобно.
Таким образом очень удобно работать команде - один занимается дизайном, другой - логикой, третий - БД и etc.
Мне кажется, хулители просто не до конца разобрались в этой практике программирования.
согласен с отрицательными высказываниями. Code Behind колоссально снижает скорость разработки. Допускаю, что это относится к тем проектам, в которых действуют 1-3 продвинутых разработчика, получающих кайф от программного креатива, которым приходится брать на себя львиную долю дизайна помимо прочего. А не к проектам, где десятки программистов реализуют чужие графики схемы цепочки классов.
получающих кайф от программного креатива
Или, например, дизайнеров, получающих кайф от быстрого прототипирования интерфейса. Но если вам нужно будет хоть раз переписать этот код, а в живых проектах его нужно переписывать часто и в т.ч. есть рефакторинг, то на определенном этапе вы захотите разделить код, так как устанете от мешанины MXML + Actionscript.
Креатив и порядок — не исключающие, а дополняющие друг друга явления. Это как работы Дали: совершенная академическая техника умноженная на сильное воображение (не самая удачная метафора, ведь о Дали тоже можно поспорить, но все же думаю, что его значение (и, что еще важнее, эффективность) есть вещи объективные).
И вообще, сейчас упоминание слова "креатив" во флексовом посте заметят труъ флэшеры и высмеют нас всех, ведь, как известно, весь креатив, он во флэше, а флекс не для креатива. Осторожно с этим
Насчет разных проектов... автор первого комментария к этому посту Роман Шупер именно сольный проект сейчас и делает, насколько мне известно. И ему подходит "код бихайнд", он о нем еще раньше меня написал.
Резюмируя: Code Behind дает лучший эффект при системной работе над проектом. А системная работа дает хорошие результаты. Не исключающие креатив, а лишь дополняющая его.
Кстати, вы навеное знаете, что PHP-программистов традиционно ругали именно за то, что вычислительная логика смешана с построением интерфейса.
по поводу дизайнеров-протипистов ничего не могу сказать - не встречал таких
рефакторингом занимался, дизайн не мешал, наборот. Имея код внутри MXML, проект становится более читаемым - видишь компонент и в тот же момент обработчики событий - полную картину.
если говорить о современном цифровом искусстве, у Дали была слабая техника
думается, живи он сейчас, создавал бы интерактивные сюрреальные сайты со своей физикой и нестандартной навигацией
почему бы не назвать креативом хотя бы ту частицу души, что вкладываешь в продукт
или вы считаете, что в development'е нет ни капли творчества - споры не утихают, является ли разработка искусством. У меня был курс в Бауманке - "Творческое обеспечение инженерных форм деятельности"
соглашусь про системную работу - потому, что никогда не пробовал, даже для сложных проектов. Всегда была ближе ставка на раскрытие возможностей разработчика, творческую реализацию, безумные спонтанные идеи
не знаю, кого ругали, может лучше от опыта отталкиваться. PHP можно за разное поругать ))
С# ругаю за строгий Code Behind, заставляющий лазить всё время в другие файлы
Рост тему говорит
Отделение mxml от as это есть гуд.
Чтобы не путаться, вверху страницы писал тег script и в нем АС, а после уже mxml. И все равно как то не уютно было от этого, а тут все ясно и понятно.
Пускай и два файла будет, все удобнее чем все вместе.
Спасибо Рост большое:) буду практиковать
Косяк такого подхода: MyComponentBase.as ничего не будет знать про свойства, созданные с помощью MXML.
Если сделать наоборот: MyComponentBase.mxml от которого наследуется MyComponent.as - то mxml ничего не будет знать про методы, соответвенно нельзя будет приделать обработчики.
Посмотрел вот этот пример: http://noubase.com/labs/splitting/srcview/index.html
Это ж вобще жесть какая-то! Класс, который напрямую обращается к собственному подклассу - это самый настоящий инцест. А значит рано или поздно последует кара.
Да, с обращением к подклассу конкретно порадовало
Но реально этот пример не имеет прямого отношения к code behind, а лишь доморощенная реализация MVC, целиком высосанная из умозрительных теорий 
Хотя, конечно, неплохо бв посмотреть пример с более сложной иерархией визуальных компонент и data flow. Потому как в этом виде приведенный пример не вызывает ничего кроме недоумения…
Мой выбор: modularity over code behind. Всю проблему со сложностью и нечитаемостью больших блоков кода в блоке Script mxml-приложения можно решить адекватным дроблением mxml на подкомпоненты и, соответственно, упрощением кода в блоке Script. А code behind, как написано выше в комментах, лишь красивая теория, лишающая код преимуществ mxml и читаемости. В результате мы приходим к тому же XAML, где эта практика обязательно и в результате имеем предельно убогий binding. Также по части обработчиков событий. В AS-суперклассе мы описываем наши обработчики, на которые ссылка идет ТОЛЬКО из класса-наследника, из его MXML-атрибутов. Получается круто, ага.
Бурные продолжительные апплодисменты.
Кратко и потеме, я полчаса думал как бы красиво описать почему я против кодбихаинда.
Было бы хорошо, если примерчики выложили. Так было бы более понятно
Еще одна неприятность связанная с Code Behind связана с проектированием. А именно нарушение иерархии и инкапсуляции в пользу определенного удобства редактирования.
Вследствие Code Behind мы получаем класс - который, как уже говорили, на самом деле не один, а два иерархических класса - с определенным количеством защищенных (protected) членов класса. И эти методы и/или свойства класса являются защищенными не от того, что их стоит или можно переопределить, а оттого, что MXML отделен от ActionScript. То есть многие из них по сути должны быть закрытыми членами класса.
отнесу себя к "хуителям" описанного Code Behind
Лично я для формы из 10 полей предпочту писать вот так :
Использование base-классов "view" для того что бы спрятать бизнесс логику - под предлогом разделения view от controller, звучит обсурдно? Расширять view имеет смысл только для создания более сложных view, а не для наследования логики , которая в подклассе впринципе может быть и не нужна, особенно если вьюшки заточены подразные модели- объекты. Саму логику внедряем в конечном "нереюзабельном" компоненте, испольюзуя биндинг и mxml - листенеры либо "кашерным" actionscript - подходом, кому как нравится
<mx:TextInput id="nicknameField" change="userPreference.userNickName = nicknameField.text" text="{userPreference.userNickName}"/ >
и вместо создания кучи protected хендлеров и их дальнейшего их переопределения я набросаю ещё 10 таких полей для другой модели.