Реклама →
Виджет комментариев Cackle: релиз-кандидат
45 дней назад мы запустили beta версию виджета комментариев — Cackle. За это время нас просто «закидали» письмами с пожеланиями и доработками. Самые значимые и важные из них были отобраны, рассмотрены, приоритизированы и сделаны. В итоге у нас получился релиз-кандидат, который мы хотели бы предоставить вашему вниманию.
Будущее сегодня →
Шаг в будущее
Тогда ими был проведен конкурс на написание статьи о видении человеком будущего, т.е. каким оно должно быть по его мнению. Я решил поучаствовать. Хотя я и не победил (случайно ли, или нет, но тот конкурс выиграл небезызвестный товарищ Пумпурум), свою статью я все-таки сохранил, и спустя почти два года, наткнувшись на нее среди различных хранящихся на моем ПК документов, перечитав её (и поймав себя на мысли о том, что из нее сбылось, а что нет), решил поделиться ею с вами.
Итак, на дворе 2009-й год, дата создания документа: "Thursday,
Научно популярное →
Скорость нейтрино перепроверили
В следующем году эксперимент будет дополнительно проверен на двух других детекторах, Borexino и Icarus.
Источники:
РИА Новости (рус.)
PaperBlog (ит.)
Cornell University Library (англ.)
im →
Тестирование веб-клиентов ICQ
Не знаю почему, но меня всегда привлекало доминирование веб-приложений над десктопными. Наверное, потому что это будущее, а все любят будущее и кто-то хочет пробовать его сейчас. Думаю, что через лет 10 (а то и раньше) на компьютере у среднестатистического юзера будет стоять что-то вроде Chrome OS и работать в роли терминала. Увидим. Сейчас, печатая эту статью в Google Docs, слушая музыку через Google Music и отвлекаясь на сообщения из Imo.im, я буду рад за такой исход событий. Для себя в веб-приложениях я вижу три основных преимущества: мобильность (быстрый запуск в любое время, в любом месте) и специфическая требовательность к ресурсам (на первое место выходит память) и простота.
Реклама →
Пока McAfee и Intel разрабатывали, мы уже сделали
Цитата с этой страницы звучит так: "McAfee и Intel объединяют усилия с целью кардинального изменения ситуации в отрасли информационной безопасности".
Пока McAfee и Intel объединяли усилия, мы вдвоём взяли и сделали то, над чем они до сих пор трудятся. Мы зарелизили наш Rootkit Detector, над которым работали 4 года.
Ни о чём →
Дополненная реальность наоборот
Видно, что ребят активно волнуют новые способы взаимодействия с техникой. Помимо этой игрушки у них ещё можно отметить карточные чернильные бои, настольных пиратов с более менее традиционной дополненной реальностью и забаркоденую «Ночь живых мертвецов».
Песочница →
Увеличение эффективности службы поддержки
Но это добро надо найти и
суметь им воспользоваться.
На мысль написать эту статью меня навели очередные глобальные проблемы в Рунете, случившиеся в прошедшие выходные. Утром в субботу обнаружил, что лицо приятеля в скайпе дёргается, а голос дрожит и прерывается. Появились и другие признаки плохой связи. Естественно, прежде чем звонить в техподдержку, протрассировал подозрительные адреса и понял, – звонить бесполезно, проблема в Москве. Там в сети пробки, как на улицах. Скорее всего, опять чей-то кортеж пропускают.
Ни о чём →
Начинаем перевод туториалов по Max
pattr.ru/forum/perevod-oficialnyh-tutorialov-maxmsp/spisok-otkrytyh-perevodov
Ни о чём →
Быстрый старт в разработке дополнений Firefox
Ни о чём →
JSS – Google Chrome расширение для встраивания собственного JavaScript и CSS кода в любую веб-страницу
Хочу поделиться с вами расширением для Google Chrome, которое я недавно написал. Расширение помогает с легкостью внедрять JavaScript или CSS код в любые веб-страницы. Создавал его в первую очередь для себя, но буду рад, если кому-то пригодится.
Ссылка на расширение
Юмор →
Достали злые соседи? Выбирай подходящий инструмент!
Язолъ →
HP: caveat emptor
На официальном сайте http://hp.co.uk/ моё внимание привлекло спецпредложение: Compaq Presario CQ56-102SA за
Песочница →
Трассировка пути на GPU, часть 1
Железо и рендеринг
Наиболее популярные, на сегодняшний день, архитектуры процессоров — x86-64. Их относят к CISC. Они обладают огромным набором команд, что привело к большой площади ядра на кристалле. Это, в свою очередь, повлекло за собой сложность в реализации нескольких ядер на чипе. Процессоры x86 не идеальны для многопоточных вычислений, где требуются многократное выполнение небольшого набора команд (RISC).
В свою очередь, рендеринг — алгоритм, который отлично распараллеливается практически на неограниченное количество ядер.
Unbiased renders
В виду того, что производительность железа неуклонно растет — технические вопросы (например семплинг отражений материалов в V-Ray, количество биасов при антиалиасинге, размытии в движении, глубине резкости, мягких тенях) все больше переходят на плечи железа. Так, несколько лет назад появился первый коммерческий рендер «без допущений» (unbiased render) — Maxwell Render.
Основным его преимуществом было качество финальной картинки, минимум настроек, всевозможных «биасов». С течением времени качество картинки приближается к «идеальному». А недостатком было и есть — время рендеринга. Ждать, пока шум сойдет, приходилось очень долго, и многие люди после нескольких проб сразу от него отказались. Еще хуже обстояли дела с анимацией (по понятным причинам).
Песочница →
Обработка заполняемой пользователем формы: как уменьшить сложность кода?
Сегодня хотелось бы обсудить вопрос обработки ошибок ввода форм в веб-приложениях. Как, вы все еще всецело доверяете вводимым пользователем данным и считаете сидящее по ту сторону монитора существо священной коровой? Не бойтесь, это пройдет после первой же атаки, если принципы контроля ввода не станут вам ясны раньше. Впрочем, к делу.
Программирую я на PHP, поэтому примеры серверного кода будут на этом языке.
Представим, что мы решили дополнить свой проект формой для заказа обратного звонка. Мало ли — линии часто перегружены, клиент хочет почувствовать свою весомость, мода такая… ну в общем надо. Быстро накидываем простейший html, пишем обработчик — данные красиво легли в базу, в общем — практически готово. Осталось сделать самую малость — написать обработку ошибок. (Конечно, порядок разработки весьма условен). Каким образом можно это проверить введенную пользователем информацию на правильность и уведомить его о результате?
В случае с правильно заполненной формой работы минимум. А вот если пользователь допустил ошибку и данные некорректны, вы вынуждены снова сгенерировать страницу и отправить ее пользователю. При этом крайне желательно значения всех заполненных полей сохранить, что увеличивает ваш код.
Рассмотрим базовую обработку ошибок (считаем что пользовательские данные уже прошли основные проверки и фильтрации):
<?php $errors = array(); if ( empty($person) || empty($phone) || empty($question) ) { $errors[] = 'Не заполнены обязательные поля'; } if ( count($errors) ) { $template->assign_switch('errors', 1); $template->vars(array( 'ERRORS' => implode(' ', $errors), 'PERSON' => $person, 'PHONE' => $phone, 'QUESTION' => $question ) ); $template->send(); } ?>
Нам хочется привнести некоторые удобства для клиента. И на помощь нам приходит…
JavaScript
<script language="text/javascript"> <!-- // function form_submit() { if ( ( document.forms['callback'].person.value == '' ) || ( document.forms['callback'].phone.value == '' ) || ( document.forms['callback'].question.value == '' ) ) { alert('Не заполнены обязательные поля'); } return; } // --> </script>
Функция alert использована лишь в качестве учебного примера, по статистике часть пользователей закроет его не читая, потому что выводится оно в дизайне ОС и не воспринимается как часть веб-страницы.
Еще раз обращу внимание на то, что серверная проверка все равно необходима.
Каждый раз, когда меня просят рассказать зачем это нужно, я вспоминаю примерно год 2004, когда я, начинающий веб-разработчик, познакомился по переписке со славным парнем с Украины, бывшим тогда автором собственной CMS. Пытаясь перенимать опыт, я как-то поинтересовался у него, как он производит обработку ошибок. Выяснилось, что делает он это только при помощи JavaScript. Пришлось уже самому делиться опытом о том, что можно сохранить страницу на компьютер, подменить адрес обработчика формы и отправить данные без валидации. И если валидации не будет уже на сервере, некорректные данные будут восприняты как нормальные, а дальше все будет зависеть от логики приложения. Позже в процессе работы я часто встречал подобные уязвимости. Вывод напрашивается сам собой — если веб-приложение пишется без понимания особенностей взаимодействия браузера клиента и сервера, результат может быть разным.
Проходит время, сложность форм растет и я обращаю свой взор на следующую технологию.
AJAX
Теперь проверка для удобства вынесена в отдельный метод и немного дополнена, в результате получаем примерно такой код:
<?php $errors = array(); if ( empty($person) || empty($phone) || empty($question) ) { $errors[] = 'Не заполнены обязательные поля'; } $ajax = isset($_REQUEST['ajax']); if ( count($errors) ) { if ( empty($ajax) ) { $template->assign_switch('errors', 1); $template->vars(array( 'ERRORS' => implode(' ', $errors), 'PERSON' => $person, 'PHONE' => $phone, 'QUESTION' => $question ) ); $template->send(); } else { $ajax_handler->send(array( 'errors' => 1, 'error_text' => implode(' ', $errors), ) ); } } else { $ajax_handler->send(array( 'errors' => 0, 'error_text' => '', ) ); } ?>
Далее в браузере клиента мы можем показать тот же самый алерт или вывести сообщение любым другим удобным для нас способом. Юзабилити на высоте — не требуется перезагрузка страницы, удобство дальнейшей поддержки кода тоже — вся обработка ошибок собрана в одном месте.
Вредный совет
Пока форма состоит из небольшого количества полей, не так сложно при добавлении очередного поля модифицировать вывод после приема ошибочных данных. А если данных много? В этом случае есть желание облегчить себе работу и отказаться от такой полной поддержки старых браузеров, убрав вывод данных и получив вот такой код:
<?php if ( count($errors) ) { if ( empty($ajax) ) { header('Location: form.php?error_code=1'); exit(); } } ?>
Мы существенно упростили себе работу по дальнейшей поддержке кода, при этом сознательно отказавшись от полной поддержки устройств с отключенным JavaScript. Чем-то пришлось жертвовать в угоду собственному удобству. Но такой подход не оправдан, если упор идет на качество разработки.
Заключение
На данный момент я продолжаю экспериментировать с проверками данных. Все еще ищу идеальное решение, которое было бы еще более оптимальным. С удовольствием выслушаю критику и обсужу все аспекты различных подходов с читателями.
Реклама →
DrupalSN: свободная регистрация!
В связи с тем, что друпал.ру лежит четвёртый день и неизвестно когда поднимется, DrupalSN объявляет об открытой регистрации на проекте. Вам не потребуются инвайты, просто регистрируйтесь, участвуйте в дискуссиях, задавайте вопросы.
Особое предупреждение за спам и троллинг: аккаунты пользователей будут немедленно удалены.
Песочница →
Личные сообщения в MODx Revolution
Итак, необходимо реализовать “социальный” элемент в виде личных сообщений юзеров. Поиски готовых дополнений для MODx ничего толкового не дали, как и гугление на эту тему. Правда, некие проблески все-таки были, но явно не в том направлении. Ну совсем не хотелось использовать ресурсы (которые документы) не по назначению. И тут я обратил внимание на то, что в самом MODx, что называется “из коробки”, уже реализована система сообщений, с одним маленьким “но”: пользоваться ими можно только в админке, куда пускать юзеров вообще не предполагается. Даже никаких намеков на сниппеты для использования во фронтэнде. Тут-то я и решил копнуть глубже.
Энергия →
Велосипед с USB-подзарядкой
Немецкая фирма Silverback начала массовое производство велосипедов с USB-питанием.
В моделях Starke 1 и Starke 2 динамо-машина крепится на переднем колесе. Производителем динамо-колёс является компания Supernova. Компактный генератор электричества в сборе со втулкой весит 370 грамм (на фото справа), тогда как обычная втулка без генератора весит 130 граммов, так что «лишний» вес совсем небольшой. Масса всего колеса с ободом из углепластика составляет 850 или 939 граммов, в зависимости от крепления обода.
Ни о чём →
Мобильные телефоны станут технически сложными товарами
Ни о чём →
Единая информационная среда в вузе. Прошлое и настоящее
В систему входили:
единый каталог авторизации на базе LDAP, куда загружались данные по всем пользователям и через который происходил процесс авторизации на все сервисы
свой почтовый сервачок (оно и понятно, для чего он служит)
группа социальных сервисов (форум, фотогалерея, свой видеохостинг, файловое хранилище)
группа учебных сервисов (Wiki, Система управления процессом обучения, Библиотека)
группа вспомогательных-развлекательных сервисов (оповещение о днях рождения студентов и преподавателей, свой цитатник, аналитический сервис и т.п.)
Система позволяла решать достаточно широкий спектр задач, так или иначе связанный с процессом обучения. В Wiki велись совместные проекты, LMS собирала отчётность по студентам (благодаря ей удалось избежать огррромного количества бумажной волокиты, связанный с домашними и лабораторными работами студентов, а так же сделать образовательный процесс более прозрачным) и в ней же хранились материалы по всем курсам. Ну а библиотека, как вы сами понимаете, хранила в себе достаточно большой объём оцифрованных материалов разных лет.
Интеграция различного рода веб-сервисов основывалась на едином требовании — снять все ограничения. В те времена многие веб-сервисы серьёзно ограничивали пользователей по размеру/качеству заливаемого контента. К примеру, во многих бесплатных фотохостингах качество фотографий существенно урезалось, объём файлового хранилища до сих пор является серьёзно ограниченным для большинства пользователей. В созданной среде этого не было.
Год-два, пока система собиралась по кусочкам, энтузиазма в её использовании у большинства было действительно мало. Но тут стоит учитывать, что образовательная среда по умолчанию является весьма инерционной. Т.е. процессы, инициированные вчера, могут дать свои плоды через пару лет. Стоило лишь немного потерпеть — и теперь созданная среда стала неотъемлемой частью образовательного процесса на кафедре. Это привело к действительно серьёзному росту сплочённости коллективов внутри единицы вуза, созданию инициативных групп, мультидисциплинности курсовых проектов. Благодаря этой же среде в рамках нашей кафедры родилась серьёзная связь между курсами. Проекты, инициированные студентами 5-го курса, поддерживались на различных уровнях студентами всех других курсов. Многим становилось это интересно и вот уже который год на большинстве профильных предметов у нас нет типовых проектов. Каждый курсовой проект является, в том или ином роде, разработкой, уже начиная с 3-го курса. Пакет этих разработок с каждым годом растёт и это не перестаёт радовать.
Конечно, у построенной среды выявились и свои минусы. Основным минусом являлась необходимость поддерживать все имеющие ресурсы. Для поддержки всех ресурсов необходимо постоянно создавать пул квалифицированных кадров. Этот минус, в своё время, переродился в плюс — студенты, начиная с 1-го курса, имели возможность попробовать свои силы в администрировании и поддержки этих сервисов. Что, правда, привело к тому, что к 3-му курсу большинство студентов уже уходили работать в техподдержку различных крупных и не очень фирм.
В результате, около года назад, мы пришли к мнению, что необходимо искать подходящий способ снять процесс техподдержки со студентов и перевести всю ЕИС на внешнюю платформу. Безусловно, есть огромный пул платных платформ, но, поскольку мы делаем всё скорее вопреки, а не благодаря, то необходимо было выбрать наиболее удобную платформу для этого. И решили попробовать для этого сервисы Google, которыми пользуемся давно лично, но на поток мы их не пускали пока.
Для этого мы за 1 день зарегистрировали на наш домен (miem.edu.ru) академический аккаунт Google на 5 000+ пользователей. После уже началась работа по формированию поддоменов для разграничения рабочих зон. Ещё при создании первой версии ЕИС, наш коллектив пришёл к следующему виду аккаунтов и, соответственно, доменных зон: name.surname@год_выпуска.кафедра.основной_домен. Эту же структуру мы решили применить и при интеграции в Google. Естественно, в Google-доменах есть свои понятия о группах пользователей, которые мы использовали для разграничения пользовательских политик (студенты, аспиранты, старосты групп и т.п.)
Собственно, мы получили достаточно большое количество плюсов от перехода на Google. Помимо классической почты и доков, мы получили групповые календари (с расписаниями для каждой группы), календари событий вуза, автоматически синхронизирующиеся с аккаунтами студентов, доступ к Youtube, Picassa и т.п.
В данный момент, мы занимаемся разработкой приложения для Android (кстати, насколько я рассматривал пару месяцев назад этот рынок в России — у нас не было ни одного приложения для вуза под какую-либо мобильную операционную систему), которое позволит студентам получать различную информацию через свой телефон. По данным соц. опроса, более 30% студентов уже сейчас используют Android в качестве ОС для своих мобильных устройств. Доля Симбы пока ещё велика (около тех же 30%), но они постепенно переходят на тот же андройд. Но об этом приложении я напишу подробнее уже в конце года, когда будет заведена бета-версия.
К чему весь этот пост? К тому, что внедрение информационных технологий в современный образовательный процесс не требует вложений в технику или покупку софта. В людей — да, безусловно. Но разве не приятно получать на выпуске специалистов, подготовленных к работе в реальном мире? Которые уже после 4-го курса (бакалавры) будут конкурентноспособными спецами в различных областях. ИТ не заменяют очный образовательный процесс. Это не дистанционка. Это расширение очного образовательного процесса. Это объединение студентов не только внутри кафедр, но и, более глобально, по вузу. Открытость лабораторий и доступность мощностей вуза приводит к тому, что, помимо образовательной функции, вуз укрепляет подготовку специалистов с широкими знаниями в кроссдисциплинных областях.