Эти способы не являются ноу-хау или чем-то в этом духе. Тем не менее, они могут помочь начинающим дизайнерам и web технологам в реализации задуманных ими идей. Каждый из предложенных вариантов можно обыграть по-своему.

Проверял лично и убедился в том, что исправно работает под следующими браузерами:

IE7+, Opera 10.5+, FF 3.6+, Chrome 12+ (linux), Chrome 13+ (windows), Safari 5+(win) исходя из личного опыта, предполагаю о том, что работать исправно будет во всех свежих версиях Safari, FireFox, Opera и Chrome.

С помощью CSS можно построить вот такие вот симпатичные варианты:

Ни для кого не секрет, что значительная часть стартапов во всем мире (и Россия, Украина — не исключение) являются копиями существующих проектов, получившими дополнительное развитие на наших просторах.

У вас есть шанс узнать о новых идеях, которые только будут реализованы в следующем году! Как? Читайте под катом.

Часто приходится «насыщать» интерфейсы с помощью JavaScript. В основном работаю через jQuery, всё нравится, но одна беда – валидация. Постоянно приходится изобретать «велосипед», искать в сети обрывки кода; а ведь хочется написать пару строчек без углубления в детали. Радость не заставила себя ждать: нашёл библиотеку Valid8 (произносится как validate), и, наконец, решил проблему написания кода валидации.

Как пользоваться

Пользоваться библиотекой оказалось очень просто, чего не скажешь о склеивании jQuery «обрезков» из интернета. Чтобы подключить библиотеку, нужно зайти сюда и нажать заветный Download. Скачается архив, в котором особый интерес представляет файл jquery.valid8.js, его копируем в папку с js файлам нашего проекта и подключаем библиотеку в html:

<script src="/js/jquery-1.6.3.js" type="text/javascript" charset="utf-8"></script>
<script src="/js/jquery.valid8.js" type="text/javascript" charset="utf-8"></script>

Допустим у нас есть форма:

<form><ul>
<li><input type="text" id="inputSome" /></li>
</ul></form>

Добавляем валидацию (по умолчанию только проверка обязательности заполения), передавая в качестве параметра строку с сообщением об ошибке. Работаем в стиле jQuery:

$('#inputSome').valid8("Заполни это поле!");

После того как поле получит фокус и вы из него выйдете не заполнив, объемлющий тег (в нашем случае li) получит класс стиля error.
Для визуализации ошибок добавим CSS в head нашего документа:

<style>
.error input { background:pink; }
</style>

Валидация готова. Все.

Введение

Всех приветствую!

Совсем недавно мне пришлось немного расширить функционал редактора одного проекта. Но как оказалось в моем случае я наткнулся на некие трудности. В этой статье я поделюсь с читателями как я вышел из сложившийся ситуации.

Несколько книг по разным темам, которые находятся в открытом доступе.

Основы программирования

• codebetter.com/karlseguin/2008/06/25/foundations-of-programming-ebook
• pine.fm/LearnToProgram
• netlib.bell-labs.com/cm/cs/pearls
• www.faqs.org/docs/artu
• savannah.nongnu.org/projects/pgubook

Я не люблю Django. Я не люблю Django ORM, Django templates, Django forms и еще множество вещей в Django. Но у Django есть определенное преимущество — многие используют Django, практически любой python-программист знаком с джанго. Поэтому приходится мириться с недостатками этого фреймворка, но никто не мешает облегчать себе жизнь, используя действительно хорошие python библиотеки, например SQLAlchemy.

Что в SQLAlchemy лучше чем в Django ORM? Это главный вопрос, который я слышу от Django guys¹, и у меня есть на него ответ — SQLAlchemy может выразить любой SQL запрос (ну 80-90%), в отличие от Django ORM, в котором можно выразить только весьма простые вещи.

И в некоторых Django проектах возникает необходимость в сложных запросах, на которые стандартный ORM неспособен. Условно предположим, что в момент создания проекта считалось, что Django ORM вполне хватит. Для решения можно писать чистый SQL или воспользоваться SQLAlchemy. Я за второй подход, так как чистый SQL плохо поддается DRY-фикации.

App Engine полным ходом идёт к светлому будущему и новой методике расчёта за ресурсы. Паника и хаос вселились в ряды разработчиков под AE — слишком многое держится в строжайшем секрете (или в компании тоже толком не знают что как будет). Но сегодня мы не будем обсуждать, будет ли blobstore включен в бесплатные квоты, или за один лишь доступ к нему придётся платить. Не обсудим куда податься, если новые цены совсем не по карману и не будем говорить о $50 «халявы», которыму гугъл пытается смягчить переход на новые рельсы (тем более, что эту радостную весть разослали всем администраторам приложений).

Сегодня речь будет идти об оптимизации приложений. Вы же уже оптимизировали своё приложение на минимальное потребление процессорного времени и памяти? Забудьте об этом, теперь это вторично и Ваши кровные будут сниматься по другим меркам.

Представляю вашему вниманию вольный перевод статьи под названием "A Simple Chat using the Channel API". Так же я решил немного добавить своего кода.

Сегодня мы представляем вам новую статью для Google App Engine посвященную Сhannel API, которое появилось в декабре 2010 года в релизе 1.4. С этого момента стала возможной отправка сообщений напрямую с сервера клиенту и обратно без использования polling.
Поэтому стало достаточно просто реализовать чат на Google App Engine. Процесс реализации описан под катом.

Намба 0: Вступление

Однажды, задумчиво листая башорг, я вдруг понял, что большинство цитат довольно длинные и очень часто их просто лень читать. В наш век всеобщей спешки — на это уходит много времени. Таким образом родился новый формат: Шортики (от английского слова Short — короткий). Шортик — это короткая (из одного-двух предложений) шутка, жестко ограниченная 255 символами (чтобы не повадно было).

Как раз в этот момент я хотел подучить программирование и искал несложную задачу. Сайт я накидал довольно быстро — за пару вечеров, рассказал о нем коллегам по работе и паре знакомых в IRC, и собирался уже о нем забыть, как вдруг обнаружил, что за два дня сайт посетило 500 человек, из которых чуть ли не треть подписалась на RSS. Стало понятно, что концепция людям понравилась. Немного прилизав сайт внешне, я решился показать его Хабрасообществу — Шортики — короткие и смешные, прошу любить и жаловать.

P.S. Учитывая то, что это не совсем стартап (проект пока некоммерческий, да и «стартап» — слишком громкое слово для моей поделки), приобретенная за годы пребывания на сайте хабрасовесть не позволила мне написать нетехническую статью. Поэтому, под катом вас ждет занимательная история о том, как мы готовили Шортики к Хабраэффекту.

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-май 2011.

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

Разрешение экрана в наши дни колеблется от 320px (iPhone) до 2560px (большие мониторы) или даже выше. Пользователи больше не просматривают сайты только на настольных компьютерах. Теперь пользователи используют мобильные телефоны, небольшие ноутбуки, планшетные устройства, такие как iPad или Playbook для доступа в интернет. Поэтому, традиционный дизайн с фиксированной шириной больше не работает. Дизайн должен быть адаптивным. Структура должна автоматически изменяться с учетом всех разрешений дисплеев. Эта статья покажет вам как создавать кросс-браузерный адаптивный дизайн при помощи HTML5 и CSS3 media queries.

Читатели хабра, наверняка, помнят предыдущую итерацию конкурса 10k Apart, проводимого Mix Online совместно с An Event Apart. Для тех, кто хочет освежить память, рекомендую пройтись по ключевым словам 10k и 10k apart.

Новый конкурс посвящен идее отзывчивого дизайна (Responsive Design), разработке сайтов, хорошо подстраивающихся под различные внешние условия — от мобильных устройств до планшетов и десктопов.

На этот раз максимальный объем всех используемых ресурсов (кроме особо обозначенных популярных библиотек) не может превышать 10k в сжатом виде.

Сайт должен одинаково хорошо работать в последних версиях IE10 Platform Preview, свежей версии Firefox и свежей версии браузера, основанного на WebKit (на ваш выбор Chrome или Safari).

Подача заявок — до 12 сентября.

Дополнительные подробности и подача заявок — на сайте соревнования и в блоге MIX Online.

Вчера была опубликована хорошая статья «Веб-дизайн. Каждому устройству свое представление». Несмотря на неплохие размышления, к сожалению, вывод в ней довольно глупый. А именно:

«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление.»

Почему это глупо

Во-первых, никто не сможет предугадать, какими устройствами будут пользоваться ваши посетители. Нужно ориентироваться не на устройства, а на разрешения.



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

Совсем недавно в авторитетном журнале Wired была опубликована интереснейшая статья «In the Next Industrial Revolution, Atoms Are the New Bits», описывающая революционные процессы, происходящие в настоящее время в промышленности, сходные с теми, которые происходили в Интернет. Ниже приводится перевод первой части статьи.

Дверь, похожая на вход в прачечную, в индустриальном парке Ворхема, штат Массачусетс, не очень-то и напоминает ворота в будущее американского машиностроения, но на самом деле таковым является. Это штаб квартира Local Motors, первой open source компании, которая производит автомобили. Стоит только зайти внутрь и мы увидим шокирующий пример того, что можно делать на микрозаводах.

Натолкнулся в разделе QA на интересный вопрос. Ответ на него заставил написать эту статью как бОлее полный ответ на вопрос «как организовать поиск по множеству параметров, как в Яндекс-маркете, например».

Я знаю, что на Хабре, да и вообще есть много сторонников noSQL решений (сам не без греха), но все же я сторонник сначала подумать, а уже потом выбирать решение.

Итак, что имеем в «ДАНО»

• Имеем 120 чекбоксов — вариант 1/0
• Имеем 30 «радио» с выбором «да/нет/не важно»
• Имеем 2-3 слайдера для указания диапазона цен/размера чего нить
• Имеем самое главное: 12 млн записей в БД.
• Имеем Select * From tovar Where (wifi=true) and (led=false) and (type=3) and ….остальные параметры …; со временем выполнения близкому к истерике клиента.

Несмотря на то, что данная социалка «горячо любима» аудиторией хабра, я всё же решил рискнуть и опубликовать небольшие заметки посвящённые разработке приложений на Джанге под неё.

Предупреждаю, некоторые из них вполне капитанские, а некоторые вообще не имеют отношения к Вконтакте или даже Джанге, в общем, не обессудьте.

Под катом:

• django-vkontakte-iframe и vkontakte
• Загрузка приложения на стену
• Флеш-заглушка
• Сессия в горячо любимом IE
• Все «flashVars» передаются GET запросом
• Работа во фрейме
• Доступ к информации пользователя
• Проверка валидности вёрстки
• JSLint ваш друг и товарищ
• Генерирование миниатюр
• Модерация через прокси-модель
• Импорт настроек
• Оптимизация

На правах рекламы: Приложение называется «Коллекционер» и предназначено для людей занимающихся коллекционированием монет, марок, карт и других предметов. В данный момент наполнен лишь каталог карт MTG, но в будущем будут созданы и наполнены каталоги для других предметов. Разумеется, мы с радостью выслушаем все ваши предложения и конструктивную критику.

Play! framework набирает популярность и на Хабре уже есть следующие топики:
Отличный Java MVC фреймворк — Play Framework
‘Hello World’ tutorial — Ваше первое приложение на Play framework (Часть 1)
‘Hello World’ tutorial — Ваше первое приложение на Play framework (Часть 2)
Мои 5 любимых фишечек в Play Framework

Одна из замечательных возможностей Play! — развертывание приложения в облачную инфраструктуру App Engine от Google.

На приложения, которые исполняются в GAE накладываются довольно жесткие (по сравнению с обычными Play! приложениями) ограничения, в основном, это связано с модулем сохранения данных (JPA / Hibernate). Для того, чтобы приложение без проблем заработало в GAE следует отказаться от JPASupport/Model хелперов и использовать только базовые возможности JPA.
Альтернативой также может стать использование модуля Siena.

В данном топике я пошагово опишу процесс развертывания приложения Play! в Google AppEngine.
Процесс установки и использования описан применительно к ОС Linux, но существенных различий при использования других ОС возникнуть не должно.

www.youtube.com/watch?v=NisCkxU544c

Посмотрев презентацию Юрия (yrashk) с Erlang Conference о веб-фреймворках в эрланге я заинтересовался и решил сделать сайтик не на node.js, как намеревался изначально, а используя какой-нибудь эрланговский фреймворк.

В итоге я наткнулся на фреймворк Chicago Boss. Про сам фреймворк я слышал и раньше, но пользоваться пока не довелось.

В прошлой моей статье я затронул единицы измерения и тут же в комментариях начались на эту тему споры и обсуждения, поэтому я решил вынести этот вопрос в отдельный пост. Вот теперь и обсудим :)