Архив рубрики: Adobe Flex 3, 4

Для каждого языка программирования свои задачи, или выводы «9 лет спустя»

Окидывая взглядом последние 9 лет практики программирования, я пришел к ряду интересных и, думаю, полезных выводов. Свою историю изучения языков программирования (далее «ЯП») проиллюстрировал ниже. Где-то отметил фреймворки на этих ЯП. Отмеченные фреймворки, как правило, давали новую мотивацию и открывали новые горизонты в изучении и использовании этих ЯП.

Языки программирования по жизни

Языки программирования по жизни

Вывод 1: для разных классов задач – разные языки программирования

В действительности, достаточно хорошо изучив какой-либо язык, кажется, что на нём надо писать не только профильные приложения. Но будьте осторожны! На этом пути вы можете впасть в состояние «вбивания гвоздей микроскопом». Так рождаются демоны (постоянно висящие процессы, типа серверов) на PHP, веб-сервера на JavaScript, веб-приложения на C++ и прочее. В качестве эксперимента – это прекрасно, но всё становится гораздо ужасней, когда что-то в силу своей популярности в другой области становится частым решением в других.

Хорошим примером иллюстрирующим первый вывод является node.js и Erlang. На node.js с радостью накинулось большое число веб-разработчиков, ведь все знают JavaScript! Попробовав домашние проекты на этой платформе, многие начали использовать node.js в реальных проектах и в итоге столкнулись с большими проблемами, решение которых затрачивало всё больше сил. Например, отказоустойчивость таких приложений. Стоит вылезть ошибке в одном из потоков выполнения, и весь сервер падает, если только вы не оградились везде, где только можно try-catch блоками. Или горизонтальное масштабирование. Тут вообще беда. И рождаются костыли-костыли-костыли.

Другое дело Erlang, который изначально «by-design» создавался для больших телекоммуникационных систем. Писать на нём серверное приложение — сплошное удовольствие. Хотите постоянно работающий сервер, которым можно управлять по telnet? Да легко! Держите встроенный пакет gen_tcp. Горизонтальное масштабирование существующего приложения? Вам скорей всего придется поменять пару строчек, где описывается передача сообщений другим функциям, — добавить в них отправку сообщений на другие ноды. Тоже и с отказоустойчивостью (привет супервизорам), обработкой бинарных данных и пр. пр.

Вывод 2 – не упускайте возможности изучать новые ЯП и/или их популярные фреймворки

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

Существует две основные когорты ЯП:

  1. Си-подобные: С++, С#, Java, PHP, JavaScript, ActionScript и др.
  2. LISP-подобные: Erlang, Python, Ruby, Perl и др.

Если вы знаете хотя бы один язык из каждого класса, то считайте, что вы знаете и все остальные ЯП.) Исключениями можно считать Assembler и языки-приколы, типа Brainfuck. Кстати, часто различить эти классы ЯП можно по наличию/отсутствию кортежей и обрамлению условных операций и циклов в фигурные скобки.

Я не стал разбивать на группы ООП, функциональные и процедурные парадигмы программирования, т.к. по большому счету почти любой подход можно использовать почти в любом языке (например, функциональный подход в Java). Другое дело, что язык изначально для этого не создавался (см. вывод 1;-) и такие извороты выглядят крайне противоестественно. Исключение Python. Он изначально разрабатывался мульти-парадигмальным.

Мой топ-рейтинг открытий типа: «А-а-а! Так вот с помощью чего это надо было делать!»:

1.  Zend Framework (на PHP)

Ну нафига я писал свою глючную библиотеку для работы с БД? О боги, а зачем я каждый раз придумывал новую архитектуру для каждого нового веб-приложения? MVC, Zend_Db, Zend_Action даруют возможность писать веб-приложения быстрее, а код делать надежным!

2.  Erlang

Боже! Ну почему я потратил кучу времени на написание этого простого демона на Java, если в Эрланге это можно было сделать парой десятков строчек, да и работало бы безотказно, да и масштабировать было бы проще!

3.  Octave

Так, надо бы быстрое преобразование Фурье… О, Matlab! Ну что, пошли на страшное преступление в ближайший торрент-трекер. Хотя ладно, вот есть бесплатная библиотечка для любимого PHP. Эхх…что-то как-то всё грустно и медленно. Octave? Octave… Octave! Мега-удобный синтаксис работы с матрицами, встроенные функции для кучи математических задач, да тут еще и графики с пол пинка строятся! Да оно еще совместимо с MatLab! А еще open-source!

4.  KnockoutJS (на JavaScript).

Как же мне надоели эти простыни с кодом, запутанная логика работы с объектами на странице, эти бесконечные onSomeEvent функции. Как бы хотелось MVC, но вот только на клиенте. Чтобы вот есть у тебя модель данных и при её изменении автоматически всё само менялось на странице. Добавил к ней объект «Задача», а на странице возьми и появись соответствующий блок для новой задачи.

KnockoutJS, как ты вовремя!

5.  Django (на Python)

Да-да, Zend Framework, ты не плох, но ты… рутинный. Каждый раз надо писать свою админку, прикручивать авторизацию, свои однотипные операции добавления, редактирования и удаления сущностей, расписывать формы ввода данных, писать однотипные виды для типичных задач, типа показа по 10 новостей на одной странице и разбивках остальных новостей по страницам. Copy-paste, copy-paste…

Ммм… что-то зачастили на хабре со своими дифирамбами во славу Django и Python.  Да давно уже поют, который год. Что ж они всё никак не угомонятся?) Ну попробуем и мы.

Так-так… значит я раскомментирую вот тут и вот тут, еще одна команда в консоли и… у меня готова полноценная админка?! Вы издеваетесь?) Так просто! А вот еще бы хотелось, чтобы в админке было удобно приписывать к разным авторам разные статьи, чтобы было красивая связь многим-ко-многим. Добавить одну строку в модель?! Ну-у, у вас совсем нет совести! Зачем же я столько времени тратил на эту рутину в зенде?»

Для этой записи хватит выводов, а то, ведь, до конца не дочитаете!) Оставим еще парочку на будущее.)

Пользовательский интерфейс системы документооборота «Документатор»

Это из раздела «работы, не увидевшие свет».

Была как-то задача создать систему, агрегирующую документы лаборатории в едином хранилище с удобным интерфейсом поиска и управления документами. Погуглив, я нашел просто прекрасный сервис Dropbox, которым пользуюсь до сих пор. Он позволял хранить файлы из определенной папки на ПК в интернете, при этом можно пользоваться программой на разных устройствах, тем самым, имея отовсюду доступ к этим файлам, там же присутствует функция общего использования папок.

И, вроде, всем хорош Dropbox, только:

  • Для удобной работы нужно устанавливать специальное приложение на ПК, которое всегда загружает всю папку на жесткий диск.
  • Веб-интерфейс Dropbox довольно топорный, больше всего не хватает добавления и скачивания файлов перетаскиванием.
  • И самое главное, документы хранятся неизвестно где.

Поэтому было принято решение о создание собственного приложения с такими ключевыми особенностями:

  • Быстрый и удобный доступ к документам
  • Поиск по названию и содержимому документов
  • Функция предпросмотра документов (аналогичная Quick Look в Mac OS X) (кстати, она всё-таки была реализована в Документаторе 2.0, но об этом как-нибудь в следующий раз)
  • Единовременный импорт/экспорт множества файлов и папок
  • Поддержка версий документов

В качестве технической реализации планировалось использовать Adobe Flash Flex и для настольной  версии – Adobe Air, сервер – Java, а название – «Документатор».

Но, как это часто бывает, стало совсем не до этого, поэтому разработка остановилась на этапах исследования и прототипирования. Прототип я постарался детализировать, потому что… да просто так, захотелось.) Тогда я как раз только осваивал Mac OS X и в интерфейсе это заметно.

Документатор – "Ментальный" вид

Документатор – Стандартный вид

В общих чертах интерфейс вполне обычный, но есть в нём «изюминка» –  «ментальное» представление, от понятия ментальных моделей из «Проектирования интерфейсов» Купера. Ментальные модели – это модели, имеющие связь с объектами реального мира.

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

Такая модель повторяет обыкновенный путь сотрудника к нужному документу: нужен, например, план финансирования на прошлый год – идем в бухгалтерию, находим ящик в шкафу с архивом за 2010 год и там ищем нужную папку с документом.

Интерфейсы выкладываю в свободное пользование. Если будете использовать их в работе, просто укажите на меня ссылку, этого хватит 😉

Flex: Тотальный контроль над загружаемым swf-клипом во Flex-приложении

Задачи:

  1. В Flex-приложении динамически подгрузить swf-анимацию и flv-видео (то есть разнотипный медиа-контент)
  2. Запускать воспроизведение медиа-контента по нажатию кнопки в приложении
  3. Проигрывать анимацию один раз

Читать далее

Flex 4: Вывод текущий даты в DateField

Задача: выводить в форме уже заполненное поле с текущей датой и с выбранным форматированием.

Решение:

<mx:Form>
	<mx:FormItem label="Дата теста">
		<mx:DateField id="date"
					  formatString="YYYY-MM-DD"
					  editable="true"
					  showToday="true"
					  selectedDate="{new Date()}"/>
	</mx:FormItem>
</mx:Form>

Flex 3, 4: Создаем диалоги с подтверждением

Задача: средствами фреймворка Flex создать диалог, подтверждающей выполнение действия пользователя. При этом необходимо перевести кнопки подтверждения на русский язык («Yes» и «No»).

Решение:

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/halo">

	<fx:Script>
		<![CDATA[
			protected function deleteSportsman_clickHandler(event:MouseEvent):void
			{
				Alert.yesLabel = "Удалить";
				Alert.noLabel = "Не надо";
				Alert.show("Удалить спортсмена?",
						   "Подтверждение удаления",
						   Alert.YES|Alert.NO,
						   this,
						   deleteSportsmanDialogHandler);
			}
			protected function deleteSportsmanDialogHandler(e:CloseEvent):void {
				if (e.detail == Alert.YES) {
					//Действия по удалению информации
				}
			}
		]]>
	</fx:Script>

	<mx:Button id="deleteSportsman"
	  	   label="Удалить информацию о спортсмене"
		   click="deleteSportsman_clickHandler(event)"/>

</s:Application>

Выглядит это примерно так:

Диалог подтверждения в flex 4

Диалог подтверждения в flex 4

Flex 4: Включаем тень и цвет для границ tooltip

Проблема: в Flex 4 с помощью стилей не получается одновременно включить отображение и тени для ToolTip, и границ (border).

Решение:


mx|ToolTip {
  font-size: 12;
  background-color: white;
  background-alpha: 0.9;
  border-skin: ClassReference('mx.skins.halo.HaloBorder');
  border-style: solid;
  border-thickness: 1;
  border-visible: 1;
  border-color: #CCCCCC;
  corner-radius: 5;
  drop-shadow-enabled: true;
  drop-shadow-color: #666666;
  shadow-distance: 1;
  shadow-direction: 90;
  padding-left: 10;
  padding-right: 10;
}

.errorTip {
  color: #ffffff;
  background-color: #CE2929;
  font-size: 10;
  font-weight: "bold";
  shadow-color: #666666;
  shadow-distance: 0;
  padding-bottom: 4;
  padding-left: 4;
  padding-right: 4;
  padding-top: 4;
}

PS: Как показала практика в Flex SDK 4.0 при использовании этих стилей у errorValidatorTooltip (то есть подсказок, возникающих при ошибки ввода) пропадают указывающее место расположение стрелки. Если же убрать свойство «border-skin: ClassReference(‘mx.skins.halo.HaloBorder’);» то пропадут границы у tooltip. Не знаю, может это из-за статусы beta происходят такие чудеса, попробовать на последнем nighty build не получилось — там сразу вываливается куча ошибок и какая-то петрушка происходит с пространствами имен (namespaces).