Поток сознания
1 неделя назаддавно уже конечно было ясно, но теперь с выходом новой версии флеша html5 выглядит как дополнительная функция к cs5.6))
1 неделя назад...если речь о front end. Для back end'а единственно верный выбор - текстовый редактор Midnight Commander'а :) Вообще просто хотел высказать (наверно, банальную) мысль о том, что идеальная IDE должна строиться именно на "максимально быстром" текстовом редакторе. Путь визуализации - хорошая идея, но опасная. На данный момент "визуальность" должна возникать в мозге программиста - и не понимаю, почему все так стараются перенести нагрузку с этого самого ("несчастного"?!) мозга на что-то иное :) - с помощью визуализации, прививания жёстких принципов ООП, шаблонов проектирования и т.д. Необходимо что-то более радикальное, что не будет строить железные заборы на пути свободной мысли... :)
2 недели назад[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 недели назадХм, я в этом начинающий, буду знать каким редактором лучше верстать, спасибо!
4 недели назад+1 sublim`у достойная замена GVIM. Как текстовый редактор с большим комьюнити и встренным python интерпертатором, и полностью податлев на костоматизации. нет смысла сравнивать IDE с текстовым редактором. Очень удобно писать erlang программы. Есть плагин для Юнитестов.
4 недели назадКол-во строк в файле с кодом - важный параметр. Есть мнение, что оно не должно быть слишком большим. Для удобства навигации по нему.
Легковесные редакторы хороши еще и тем, что в них бытрее появляются инновации. Например, обрати внимание на мини-текст в правом верхнем углу скриншота для Sublime - по нему можно скроллить мышкой, мгновенно перемещаясь в нужное место кода.
Textastic как раз использует тачевые возможности - для этого у него есть клавиши-компасы (есть на скриншоте). Такая клавиша-компас имеет пять значений. Если просто нажать ее - сработает значение по умолчанию (символ посередине). Остальные четыре символа можно выбрать, если нажать и протянуть пальцем в сторону одного из них.
Визуальное программирование -- это очень интересная, но небанальная тема.
Ведь текст имеет иную структуру, чем изображение.
Текст - условно одномерный, линейный. Изображение - фиксированно двумерное (или фиксированно трехмерное).
Кажущаяся одномерность текста обманчива, особенно когда текст становится кодом. За счет функций (замыканий) и условных переходов текст программы становится многомерным. Даже вне программирования существуют многомерные тексты - хорошая книга может содержать внутренние указатели и ссылки на части самой себя. Поэтому текст - очень продвинутый способ работы с сознанием читателя (или компилятором).
Не вижу возможнлости проделать то же самое с изображением. У него другая природа, и визуальное программирование будет похоже на обычное так же, как графика или живопись похожа на литературу.
До сих пор попытки визуального программирования не заходили дальше имитации обычного - надергали компонентов, но потом - все равно пишем код.
Визаульное программирование - это не способ создавать код мышкой (или тачами), а способ программировать другие каналы восприятия - не аналитические (компилируемые), а эмоциональные.
Кстати, ближе всего к этому подошел флэш. Но потом его убили бизнесом, а из трупа сделали геймдев :)
Так визуальное программирование остается мечтой масс и уделом гениев-одиночек.
4 недели назадБрррр... Легковесные редакторы кода хороши только для легковесных (~20 строк кода) программ. Для всего остального - Idea и FDT.
А редакторы для мобильных устройств зачем-то делают такими же, как на десктопах (у которых есть нормальная клавиатура), при этом совершенно не используя возможности тач-скринов. Думаю, через годик-два появятся наконец мобильные редакторы, где можно будет писать программу чисто жестами, без "волшебных" кнопок.
К вопросу об архитектурных фреймворках в Adobe AIR
Пишет Адилет Абылов:
Недавно столкнулся с проблемой выбора архитектурного фреймворка для разработки под мобильные устройства на Adobe AIR. У меня довольно большой опыт использования Cairngorm, но терзают смутные сомнения в том, что Cairngorm - это хороший выбор для мобильных приложений, с учетом рекомендаций Adobe по экономии памяти и ресурсов процессора. Поиск в сети на эту тему не дал однозначного результата. Где-то читал, что Mate подходит для мобильных устройств, но Adobe рекомендует меньше использовать mxml, а Mate очень активно использует его. Возможно, мобильные приложения по определению не могут быть большими и сложными, поэтому использование фреймворком и не требуется.
Хотелось бы спросить мнения у более опытных коллег.
С уважением, Адилет Абылов
Комментарии
А чем плох RobotLegs? не использует mxml, минимум обращений.
RobotLegs, к примеру из за этого - [Inject], поскольку metadata учитываються на runtime, то работает механизм reflection, в общем используют describeType, а это тоже не быстрый процесс. (хотя как точно это реализовано в RobotLegs не посмотрел, по этому могу ошибаться).
о как, интересно
После Cairngorm перешел на Swiz - он показался куда более легким для разработки.
использовали в мобильных проектах?
Да, в небольших - пять-семь экранов, кнопочки, прокрутки. Проблем не нашел для себя, может плохо искал.
PureMVC крайне прост и легок в эксплуатации.
К слову - выбор фреймворка определяется архитектурой приложения (тривиально), но навскидку:
1. Cairngorm - для приложений с сложным внешним обменом
2. Mate - для приложений со сложной системой event'ов
3. pureMVC - для приложений с большим количеством видов (views)
и так далее
То есть задача фреймворка снять сложность (о чем в исходной постановке были смутные подозрения ), то есть где просто - там ангелов (фреймворков) со сто
интересная мысль: сделать обзор фреймворков с такой точки зрения
В рамках разработки мобильных приложений рекомендую не просто не использовать архитектурные фреймворки (хотя каюсь, с оными практически не работал), а в целом - не использовать Flex. Pure ActionScript + low level flash. Выигрыш в памяти будет измеряться десятками мегабайт, производительность будет выше в разы (в области формирования визуального контента). Конечно, на начальном этапе будет занижена скорость разработки - пока не обретёт стабильные очертания собственный фреймворк.
+1. Flex в мобильных проектах это СУПЕР ЗЛО!!!!
Не стоит использовать в мобильных проектах крутые большие фреймворки. Аргементирую это следующими пунктами:
1. Чем больше кода тем больше размер выходного файла (IOS APP). У нас есть наша внутренняя библиотека с окнами и т.д.. Она занимает 100кб в скомпилированном виде. при добавлении её к проекту выходной ipa увеличивается на 1.2 мб. Я долго пытался понять почему так - пока не понял.
2. Чем больше кода тем больше время компиляции.
3. Оптимизатор. Я недавно 3 дня воевал с оптимизатором. Он неполностью анализировал код и выкидывал жизнено-важные куски кода. Притом сверхестественного ничего небыло - условие определялось в 2-х вложенных циклах. Для него это было сложно. А в фреймворках очень много умного кода - и потом же эти баги не найдешь.
4. Процессо не такой быстрый. Поэтому лишние нагрузки на него тоже хорошо не сказываются.
5. Да, и конечно же память. К ней нужно осторожно относиться - т.к. при переполнении приложение просто падает и это никак не отследишь.
ИМХО: фреймворк можно использовать и нужно, но он должен быть очень лёгкий без крутых наворотов ООП, и вы должны в нем хорошо ориентироваться чтоб при малейшем сбое (оптимизатора) быстро понять где искать. А то так и проект можно похоронить.
Очень интересно было почитать комментарии... сколько флешеров столько и мнений... И все же
Не могу разобраться, действительно ли много процессорного времени оттъедается mxml, parsley и флексом, или это все невероятные мелочи по сравнению с нагрузкой на проц когда я просто начинаю двигать картинку ? У меня сложилось впечатление что выполнение кода происходит все равно относительно мгновенно.
Выполнение кода... - смотря что в коде. Речь о формировании интерфейса, а не выполнении математических операций. Один и тот же интерфейс можно поднять двумя путями: использовать Flex-компоненты (через MXML или через ActionScript - через MXML по теории будет работать медленнее, но чуток) и использовать чистый Flash (где придётся писать аналоги Flex-компонентов самому - средствами Flash; как альтернатива - вроде видел, есть фреймворки более низкого уровня, чем Flex). То есть вместо spark.components.Image использовать flash.display.Bitmap и т.п.
Если Flex-интерфейс уже создан в памяти, то далее можно повторно использовать созданные объекты - тем самым повышая производительность - обычная практика, расписанная в доках Adobe.
Так вот если юзать чистый флеш - всё летает, по сравнению с Flex. Как небо и земля. Но Flex - он и есть Flex - существует для того, чтобы сократить время разработки приложений, в этом плане это добро. Но не для мобилок. Даже если брать Galaxy S2 - Flex'у пока тяжеловато.
Чистый Flash - это своего рода дзэн (но и особый кайф для программиста). Ну и десятки выигранных мегабайт памяти и разы производительности, поверьте.
Двигать картинку - особо неважно где, во Flex или Flash. Во Flash должно быть по любому быстрее - Flex должен пересчитывать layout'ы и т.п. - но не так чтобы шибко быстрее. А вот создание экземпляра картинки наверняка сожрёт больше памяти и времени во Flex, и существенно.
Двигать картинки наверно тоже в разы быстрее во Flash. Для отображения спутникового покрытия во Flex-ГИС я переписался на flash.display.Bitmap, и получил турбо-ускорение. Но когда писал насыщенную интерактивную анимацию во Flash/Flex для другого проекта - вроде особого различия не заметил.
Для десктопных приложений по прежнему использую AIR Flex Spark, считая, что это лучшее, что было создано человеком для разработки софта.
почитав ответы, ушел писать на Obj C
ObjC же не модно.
С# под все платформы
http://xamarin.com/
objc -- бееее... java хотя б
расскажите почему? Я вот начал изучать Obj C, не фонтан конечно, но терпимо