Сегодня в обзоре речь пойдет о сайтах предоставляющих готовые решения с применением Ajax. Разного рода виджеты, tabs, tooltips, валидаторы форм, галереи, DHTML окна, построение графиков и пр. на любой вкус.
Практически все представленные решения базируются на хорошо известных сторонних AJAX библиотеках, таких как Prototype, Mootools, JQuery. Также есть и независимые разработки, не требующие порой подключения монструозных библиотек. Таких не очень много, но они все таки есть и это радует.
Вообще основной акцент делается именно на широко используемые решения.
В обзор вошли три таких сервиса:
Теперь пройдемся по ним по порядку.
Комментарии (4) Июль 25, 2007
В практически каждодневном спаме от phpclasses.org читаю о новых пополнениях и модификациях крайне полезных классов 
. Вот так в очередной раз просматривая письма наткнулся на перечень сред разработки на php.
Мои глаза сразу заметили редактор, с которым раньше работать не приходилось. А перепробовал я их очень много (большая часть из которых отправились в мусорник).
Полез на официальный сайт этой распрекрасной VS.PHP StandAlone IDE. Приличный кусок текста расписывал ее “неоспоримые” достоинства. В первую очередь поискал, ключевые для меня, моменты касающиеся работы с FTP. Все есть, все прекрасно.
1 комментарий Июль 10, 2007
На одном из блогов наткнулся на обсуждение о больших заработках “золото-шмоточная стадия” и взаимоотношениях между людьми. В частности о друзьях, о том как портятся отношения с ними и о женщинах с которыми серъезные отношения лучше не начинать.
Написано жизненно. Может в некоторых мелочах и не согласен, но с остальных спорить сложно.
Поздравляю ты попал в золото-шмоточную стадию жизни. У меня такая же была 2 года назад, связана была с первыми реальными баклажанами в кармане.
Симптомы: ты начинаешь зарабатывать больше чем твой папа, который 20 лет корячился военным\хирургом\кем нить еще. Ты понимаешь что твоим сверстникам такие заработки ближайшие 10 лет не светят.
Добавить комментарий Июль 6, 2007
Вот сижу и разбираюсь с этой мудреной птицей под названием “Контроль версий”. Никогда раньше с ней работать не приходилось. Но вот жизнь заставила.
Читаю мануал (почти весь на русском), каким-то образом завалявшийся у меня на машине. Откуда я его взял без малейшего нонятия.
Первое впечатление вполне положительное. Но нужно собрать полную картинку всей етой фигни, тогда можна будет говорить о каких то конкретный высказываниях.
Добавить комментарий Апрель 14, 2007
Кто знает как енту скотину прожорливую посадить на оперативную диету. Просьба IE и Opera не предлагать.
Комментарии (6) Март 26, 2007
Постановка задачи следующая - вывести на экран ескизы (thumbnail) галереи. Необходимо чтобы каждый ескиз по ширине и высоте не превышал 100px, а также сохранялись пропорции изображения. Искажений быть не должно. Необходимо чтобы визуально ескизы выглядели максимально одинаково -квадратными.
Возникает вопрос каким образом етого можна добиться, учитывая разные размеры исходных фотографий. Вот об этой математике я и буду рассказывать. Не буду сейчас выкладывать исходники галереи, а остановлюсь на объяснении общего алгоритма.
Добавить комментарий Март 12, 2007
Мда, у весны приход скверный, ее колбасит, плющит, потеки на роже.
Но она старается.
Смывает с себя все зимнее дерьмо.
Мое детище-хобби начаЛО дышать. Если говорить точнее то дышит с перебоями, но в последнее время уверенней.
Freelance отбирает много сил. Но зато сам себе хозяин.
Монитор все никак не отнесу в ремонт. А так все просто отлично.
Добавить комментарий Март 2, 2007
Однако работать, оставаясь исключительно в рамках своей специализации, не получается. Будучи программистом, я естественно концентрируюсь, в основном, на функциональности сервиса, а о том, как выглядят в этот момент страницы, практически не задумываюсь. И раньше я часто совершал одну ошибку, которую, уверен, совершают и многие другие программисты: показывал заказчику то, что наработано, прямо в таком виде…
Представьте себе ситуацию со стороны заказчика. Программист месяц-другой что-то там делает, говоря, что все идет хорошо. Но заказчик нервничает, потому что ему остается только верить на слово человеку, которого он до этого и не знал вовсе. Через некоторое время программист таки говорит, что вот, многое уже обрело форму, и есть, что показать.
Дальше можно сколько угодно убеждать заказчика, что дизайн — это отдельная песня, и что расположение элементов на странице никак не связано с функциональностью приложения, и что там действительно готово уже больше половины. Все тщетно. Потому что картинка явно и недвусмысленно подтверждает все опасения заказчика о том, что этот негодяй даже ничего и не начинал, склепал какой-то кошмар в последнюю ночь, и проект близок к провалу.
И у него есть все основания так думать. Ваш заказчик — не программист. Он не читает ваш код, не следит за коммитами в subversion и за чинящимися багами в багтракинге. И фактически, внешний вид — это даже не первое, а единственное, на чем он может построить свое впечатление от сделанной работы. Поэтому если на экране разрозненный мусор, то это заставляет его думать, что и остальное внутри находится в аналогичном состоянии.
Даже если программа во многом реально работает, для того, чтобы это увидеть, надо уметь декомпозировать в голове понятия “дизайн”, “верстка”, “функциональность” и “содержимое”. А этот аналитический навык у большинства людей просто натренирован существенно хуже, чем у программиста, который занимается такими вещами ежесекундно, включая утренний душ и поездку в транспорте.
По этой же причине, кстати, очень плохо при показе программы выглядят типичные для программиста тестовые данные типа “foo”, “bar”, “тестовая запись” и “asdfgh”. Для заказчика отсутствие функциональности вообще и наличие тестовой функциональности одинаково бесполезно. Ему интересен готовый результат. И поскольку он, опять-таки, не программист, он не может знать, что с вашей точки зрения само появление на экране хоть чего-то после долгого проектирования модели — это большой шаг вперед.
Я сейчас нахожусь как раз в середине двухмесячной разработки того, что мы с заказчиком условились публично называть “Неким Музыкальным Сервисом”. И не далее, как пять дней назад, решение такой проблемы у меня наконец выкристализовалось в четкую концепцию “чернового стайлинга”. Это такой компромиссный вариант, который позволяет инженеру без художественных талантов тем не менее достойно представить результаты своего труда.
))
))
Строится он по таким принципам:
- Раскладка должна быть полностью задана. Несмотря на то, что расположение блоков и вид кнопочек задаются одним и тем же CSS’ом, для тех, кто будет смотреть на ваши страницы, это разные вещи. И юзабилисту потом будет проще давать советы, что куда подвинуть и как поменять, если будет, от чего отталкиваться.
- Чтобы не мучить мозг подбором сочетаний цветов, дизайн делается “черновым” в прямом смысле. То есть, используются черный, белый и градации серого. Помимо легкости исполнени, это еще и создает четко узнаваемый эффект “системы в процессе разработки”. И дизайнеру должно быть впоследствие легче, потому что хорошо видно, что еще недораскрашено.
- Картинки-пиктограммки должны быть нарисованы, и выглядеть некошмарно. Обычно графика, которую рисуют программисты, выглядит убого просто потому, что делается на непрозрачном белом фоне инструментом “карандаш” в одно движение мышкой. Не надо так делать. Возьмите редактор, который умеет делать прозрачность (под Windows я пользовался Microangelo, под Линуксом сейчас — GIMP) и потратьте на черно-белую иконку какое-то время. Честно говоря, в квадратике 16х16 не так много места, чтобы не нарисовать все по точкам, тем более что никакого “леденцового” качества не требуется.
- Вместо многих иконок вообще можно пользоваться Unicode’ными символами. Галочки, стрелочки, карандашики, кружочки и квадратики — все это там есть. И это не то же самое, что раньше было в шрифте Wingdings, теперь это все внесено в стандарт Unicode и есть во многих стандартных шрифтах.
- Чтобы эти символы набирать, я пользуюсь “Character Map”, которая идет с Ubuntu. Точно помню, что есть такая и в Windows, хотя сейчас я ее на соседней XP не нашел. Но в любом случае можно вводить их кодами: ✓
- Даже не надо думать про скругления углов, градиенты и прочее. Вполне можно обойтись CSS’ными border’ами для создания псевдотрехмерных эффектов. (Хотя я и не удержался от двух градиентных картинок )
- Шрифт должен быть меньше стандартного, потому что тот слишком большой обычно. И без засечек. Я обычно ставлю “font:small Tahoma” в качестве основного.
- Не надо тратить время на поддержку многообразия браузеров, работайте в том, в чем привыкли. Просьбу смотреть на черновой дизайн в каком-то определенном браузере заказчики как раз, в большинстве своем, понимают.
И что мне, как не дизайнеру, особенно приятно, реакция тех нескольких людей, которые видели этот черновой стайлинг, была в духе “симпатично!”
Источник: http://softwaremaniacs.org
Добавить комментарий Декабрь 15, 2006
Вот так бывет, что пользуясь каким-то языком программирования довольно долго и не подозреваем о некоторых интересных особеностях или функциях.
В документации вроде как упоминается но внимания на них неакцентируется.
Вчера нашел небольшую заметку с парой интересных шпаргалоок на PHP.
Начну с самой интересной для меня.
Функция glob. Иногда, а комуто и довольно часто, приходится работать с файловой структурой. Пройтись по папке и извлечь из нее файлы с определенным расширением.
$aFiles = glob(’/home/site/upload/{*.jpg,*.jpeg,*.gif}’, GLOB_BRACE);
if (is_array($aFiles))
{
echo “Найденные файлы с изображениями \r\n”;
foreach ($aFiles as $sImage)
{
echo $sImage.” \r\n”;
}
}
else
{
echo ‘Изображений не найдено’;
}
?>
Необходимость в opendir, readdir отпадает.
Функция switch. Все ее прекрасно знают и благополучно пользуються. Вот только у нее есть и не совсем стандартное применение.
Сравнивать можна не только по принципу == или !=, но и вот так
switch (TRUE)
{
case ($iAge < 18)
echo ‘Вам нельзя водить машину’;
break;
case ($iAge == 18)
echo ‘Пора в военкомат’;
break;
case ($iAge > 65)
echo ‘Пора на пенсию’;
break;
default:
echo ‘Работать, работать и еще раз работать’;
break;
}
Ну и на закуску… незнаю насколько она может показаться полезной но знать об етом будет нелишним.
Функция print_r. Используется для вывода отладочной информации на екран.
У етой функции есть второй параметр отвечающий за тип вывода, при значении true, теперь весь вывод можно перенаправлять не на экран, а в переменную, например вот так:
$sDebugInformation = print_r($aVarDump, 1);
Ну пока все.
Добавить комментарий Декабрь 14, 2006
Так уж сложилось что пришлось столкнутся с подобной проблемой. Если магазин небольшой а количество товаров не превышает и сотни (продажа хостинга или еще че нить) тогда все можна смело править ручками или посадить манагера (в обязаности которого будет входить ета работа).
Но вся ета радужная жизнь заканчивается, когда количество товаров переваливает за несколько сотен а то и тысяч. Возникает проблема как обновить цены на товары в базе если их так много. Немного порывшись в Yandex нашел интересную статью. Нет там нет готовых кодов и ссылки для скачивания. Но там есть коечто поважнее. Описание логики и вообще приципиальной схемы работы.
В статье затрагивается проблема как синхронизировать прайс магазина с прайс листами нескольких производителей.
Из схемы видно, что обмен информацией осуществляется посредством внутренней информационной среды, которая имеет специфику для того или иного вида деятельности. Здесь под внутренней средой понимается не только коммуникации внутри организаций, но и между ними, в рамках их совместной деятельности.
В большинстве случаев информационное взаимодействие основывается на обмене прайс-листами, с помощью которых производители и поставщики информируют потребителей о предлагаемых ими товарах и услугах, а последние осуществляют по ним заказ товаров. Поскольку разделение на производителей и поставщиков достаточно условно, то они также могут осуществлять заказ товаров по прайс-листам друг у друга. Таким образом, прайс-лист - носитель информации, с помощью которого осуществляются коммуникационные взаимодействия в данный момент времени. Привязка информации ко времени позволяет оперировать таким понятием как “актуальность информации” и эффективность обмена информацией, поскольку устаревшая информация не имеет ценности для оперативного принятия решений. Действительно, в условиях постоянной динамики рынка и жесткой конкуренции крайне важно оперативно получать информацию для своевременного реагирования на изменения, постоянно происходящие в деловой среде.
Проблема
Задумывались ли Вы над тем, сколько времени затрачивают клиенты на составление заявок, а сотрудники организаций на их обработку и составление по ним счетов на оплату, обновление цен и ассортимента товаров в своих каталогах по прайс-листам поставщиков и т.п.? Много. Однако очень часто ответы на данные вопросы даются с точки зрения самой организации, что не позволяет рассмотреть проблему в целом. Чтобы наглядно продемонстрировать это давайте рассмотрим случай, когда поставщик работает с несколькими производителями и несколькими клиентами. Схема взаимодействия для данного случая показана ниже.
Механизм обмена информацией здесь будет таким:
- Производители составляют свои прайс-листы с перечнем производимых ими товаров
- Поставщик использует прайс-листы производителей для заказа у них товаров и составляет на их основе свой прайс-лист, для информирования своих клиентов о предлагаемых им товарах
- Клиенты используют прайс-лист поставщика для заказа по нему необходимых им товаров
Мы видим, что поставщик должен постоянно осуществлять синхронизацию информации между прайс-листами производителей и своим прайс-листом, в противном случае могут возникнуть проблемы как по ассортименту товаров, так и по ценам на них. Например, поставщик продолжает предлагать клиентам товар, который был снят с производства, или его цена увеличилась.
Основная проблема синхронизации прайс-листов заключается в том, что производители редко сами уведомляют поставщика об изменениях по ценам и ассортименту товаров. Поэтому последним приходится регулярно делать запросы на новые прайс-листы. Добавим сюда тот факт, что немногие производители имеют свой сайт, а уж совсем немногие регулярно обновляют прайс-лист на нем. С другой стороны, поставщик должен оперативно обрабатывать заявки от своих клиентов, которые составляются, во многих случаях, как попало. При небольшом количестве заявок и ассортименте заказываемых товаров данная проблема может показаться несущественной, однако на практике получается так, что составление счета конечному покупателю может происходить в течение нескольких дней. Почему? Для ответа на данный вопрос давайте рассмотрим типичную схему заказа:
- Клиент составляет заявку на приобретение товаров по прайс-листу поставщика или из головы и осуществляет её отправку по факсу или e-mail.
2. Поставщик получает заявку и обрабатывает её. Если в заявке содержится товар, который отсутствует на складе поставщика, то он должен запросить счёта у производителей данных товаров.
3. Производитель получает заявку от поставщика, обрабатывает её и выставляет счет поставщику.
4. Поставщик получает и обрабатывает счета от производителей и выставляет счет своему клиенту.
Предположим, что данные пересылка информации происходят при помощи факса. В этом случае возможны следующие проблемы:
- Плохая передача факса - повторная передача
- Отсутствие реквизитов заказчика - повторная связь
- Искажение или потеря информации, из-за чего невозможно идентифицировать заказываемый товар - повторная связь
- Заказан неходовой товар - связь с поставщиком на предмет уточнения цены и возможности поставки. Поиск производителя или поставщика данного товара.
Добавим сюда то, что очень часто между клиентом и производителем товара может находиться несколько поставщиков-посредников, каждый из которых должен обработать заявку, произвести согласования по ассортименту, ценам и срокам поставки, запросить счёт у вышестоящего поставщика, выписать счет клиенту и т.д. Все эти операции требуют много времени и сил.
Из схемы также видно, что основная информационная нагрузка ложится на поставщика, поскольку он должен осуществлять коммуникации с несколькими производителями товаров и клиентами, т.е. выполнять роль посредника между ними, согласовывая интересы данных сторон за определённое вознаграждение. Поставщик является центральным звеном в нашей схеме, поэтому от качества его работы зависит очень многое. Однако неправильно полагать, что эффективность всей системы зависит только от него. Действительно, если клиент присылает заявки по факсу, то оператор будет обрабатывать её вручную, несмотря на то, что у него установлена высокоэффективная система обработки электронных заказов (подробнее об этом можно узнать здесь).
Электронная почта работает значительно быстрее и качественнее пересылке информации по факсу. Однако она не избавляет операторов от ручной обработки заявок, выставления счетов, обновления прайс-листов, заказа товаров и т.п., что требует значительных усилий и времени. Полагаю, что Вы согласитесь с тем, что в наше время клиенты хотят получать информацию и счета оперативно, поскольку в противном случае высока вероятность того, что они начнут поиск других организаций (конкурентов), которые работают быстрее. Как же увеличить эффективность обмена информацией, которая сводится к следующим операциям:
1. Заказ товаров клиентами и поставщиками.
2. Обработка заказов и составление по ним счетов.
3. Синхронизация собственного прайс-листа поставщика с прайс-листами производителей.
Решение
Решение обозначенных проблем достаточно очевидно - необходимо автоматизировать процесс обмена и обработки информации между производителем, поставщиком и клиентом, что можно реализовать с помощью электронной системы обмена и обработки информации (ЭСООИ). Нетрудно заметить, что ЭССОИ включает в себя две составляющие: систему передачи информации и систему обработки информации. Для передачи информации в электронном виде можно воспользоваться электронной почтой. Таким образом, исходная задача касается вопроса построения автоматизированной системы обработки информации. Для этого необходимо разработать некоторый общий формат данных, наподобие широко используемого штрих-кода, чтобы разные системы могли одинаковым образом производить его обработку.
Реализация
Одним из решений является ключ-кодовая система электронного обмена и обработки информации. Рассмотрим заложенную в неё идею.
Как известно, запись товара в базе данных должна иметь некоторый уникальный признак, который бы позволял оператору её однозначно идентифицировать среди множества других. В большинстве баз данных для этих целей используется уникальный код товара (или артикул), поскольку он наиболее оптимальным образом подходит для этого. Действительно, с помощью только 8-ти символьного кода можно закодировать 100 млн. товаров, что в несколько раз превышает ассортимент любой компании или фирмы. Определив для каждого товара уникальный код, мы можем точно найти товар, код которого указан в заявке клиента. Добавив сюда количество товара, мы получим минимальную структуру данных: код, символ-разделитель, количество, например:
3316#15,
где 3316 - код товара по прайс-листу, # - разделитель, 15 - заказываемое количество.
Данный формат позволяет в несколько раз уменьшить объем передаваемой информации, по сравнению с передачей названий товаров, но не позволяет проверить цену или название товара. Если это необходимо, то в структуру можно добавить дополнительные поля, например: цену товара, валюту, и название товара. Получим следующий формат:
3316#15#10000#руб#Телевизор
Теперь оператор, обрабатывающий заявку, может определить цену, по которой клиент произвёл заказ и название товара, найти расхождения по ним и сообщить об этом клиенту. Вообще говоря, цена, валюта и название товара могут быть лишними в том случае, если поставщик не производит изменение валюты или названия товара под данным кодом, а клиент регулярно обновляет свой прайс-лист. Включение цены в структуру заказа вызывает большие сомнения и в том случае, если для товара определены оптовая и розничная цена.
Таким образом, мы пришли к тому, что для заказа товара необходимыми параметрами являются код товара и его количество.
Теперь рассмотрим ситуацию с синхронизацией прайс-листа поставщика с прайс-листом производителя. Многие организации определяют для товара несколько цен (розничная, мелкооптовая, оптовая и др.). Название товара можно не отслеживать, если поставщик гарантирует его неизменность. В этом случае можно было бы определить следующий формат:
3316#Телевизор#руб#10000#9500#9000, где 10000 - розничная цена, 9500 - мелкооптовая, 9000 - оптовая.
Определив таким образом формат данных, мы может разработать функцию, которая будет производить поиск товара в нашей базе данных по коду в прайс-листе производителя и осуществлять необходимые изменения цены на товар. Кстати говоря, в новых версиях 1С:Торговля и склад данная функция уже реализована.
Нетрудно заметить, что рассмотренные форматы файлов - текстовые файлы с разделителями, которые весьма компактны по сравнению с файлами Word и Excel, и, в отличие от последних, не подвержены заражению макровирусами.
Всё хорошо, но мы не учли одну тонкость. Дело в том, что товары в разных организациях могут кодироваться разными способами: числовым, алфавитно-числовым и т.п. Что будет, если коды товаров пересекутся? Программа не сможет правильно идентифицировать товар, со всеми вытекающими отсюда последствиями. Чтобы этого не произошло необходимо ввести в формат данных еще и уникальный код организации. Тогда формат данных будет таким:
12#3316#15,
где 12 - код организации, 3316 - код товара, 15 - заказываемое количество
Механизм обмена информацией в этом случае будет таким:
1. Клиент быстро составляет заявку с помощью электронного каталога поставщика и направляет её по e-mail поставщику.
2. С помощью автоматизированной системы обработки заказов поставщик обрабатывает заявку. При этом он может:
* Составить счет и отправить его клиенту
* Составить электронное письмо для клиента, в котором перечислить отсутствующие или снятые с производства товары и т.п.
* Проверить актуальность своего прайс-листа на основании заказываемых позиций
* Произвести группировку заказываемого товара по производителям, составить заявки и направить их по e-mail производителям
* Запросить с сайта производителей прайс-листы и быстро обновить свой прайс-лист
Что необходимо для реализации ЭССОИ?
Поставщику:
1. Определить код организации и задать в каталоге уникальные коды для каждого товара.
2. Электронный каталог товаров поставщика, с помощью которого клиенты будут составлять заявки и отправлять их по e-mail.
3. Модуль автоматизированной обработки заявок и составления по ним счетов.
4. Модуль группировки товаров по производителям (поставщикам) и составления заявок.
5. Модуль синхронизации прайс-листа поставщика с прайс-листами производителей.
6. Система администрирования ЭССОИ, поскольку поставщик является центральным звеном между производителями и клиентами.
Производителю:
1. Определить код организации и задать в каталоге уникальные коды для каждого товара.
2. Электронный каталог (прайс-лист с кодами) товаров
3. Модуль автоматизированной обработки заявок и составления по ним счетов.
Для обмена информацией в электронном виде необходимо наличие электронной почты. Наличие сайта у производителя и поставщика не является необходимым условием, однако их отсутствие может существенно снизить эффективность всей системы обмена информацией.
В заключение хочу сказать, что, несмотря на кажущуюся простоту данной системы обмена информацией, ее реализация может потребовать пересмотра информационных коммуникаций внутри организации и, даже, деятельности нескольких отделов с вытекающими отсюда материальными и финансовыми затратами. С другой стороны необходимо уже сейчас закладывать мощный фундамент для того, чтобы в ближайшем будущем построить на нем прочный (и высокий) дом успеха. Что выбрать - каждый решает сам, однако не всегда к финишу первым приходит тот, кто раньше стартовал.
Добавить комментарий Ноябрь 24, 2006
