Что такое энерго-эффективность в применении к мобильным платформам? Простыми словами это возможность сделать больше, затратив при этом меньше энергии.

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

Хоть мы тут в большинстве своем и не юристы, но с договорами, думаю, сталкивались все. Как минимум, это договор аренды квартиры, договор о предоставлении тех или иных услуг, трудовой договор и так далее. При этом, считается вполне нормальным, что документы эти представляют из себя «темный лес» терминов, за которыми едва ли видна сама суть соглашения.

90% контрактов, с которыми я сталкивался, это никуда не годная макулатура. Они многословно и вычурно описывают то, что и так понятно всем, обходя вниманием важные аспекты. Очень редко встречаются хорошие документы, которые действительно страхуют риски обеих сторон и мотивируют их выполнять свои обязательства.

Итак, пришло время раскрыть некоторые карты и рассказать о том, как устроен Tactoom изнутри.

В этой статье я расскажу о разработке и выведении в production веб-сервиса с использованием:
NodeJS (fibers), MongoDB, Redis, ElasticSearch, Capistrano, Rackspace.

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

Вы знаете, какое значение выведет этот код на JavaScript?

var foo = 1; 
function bar() { 
    if (!foo) { 
        var foo = 10; 
    } 
    alert(foo); 
} 
bar();

Стэнфордский университет выложил в онлайн лекции и сопроводительные материалы к курсу по цифровой фотографии (CS 178). Курс знакомит студентов с научным, художественным и компьютерным аспектами цифровой фотографии — как работает камера, как делать хорошие снимки, как обрабатывать фотографии.

Кроме лекций, есть подробный план занятий, список необходимых учебников и программного обеспечения и интерактивные материалы (флэш-апплеты), которые иллюстрируют каждую лекцию. Есть также список еженедельных практических заданий, а в заключение — список вопросов на экзамене и анализ решений. В качестве бонуса — анимация сборки камеры Canon 10D. В принципе, всех этих материалов достаточно, чтобы пройти курс самостоятельно, а потом сдать экзамен и проверить свои ответы.

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

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

JavaScript, как никакой другой язык, нуждается в именно таком объяснении. Функциональная природа, скрытая за Си-подобным синтаксисом, и непривычная прототипная модель наследования поначалу сильно сбивают с толку. Давайте мысленно понизим уровень JavaScript до простого процедурного, наподобие Си. Отталкиваясь от этого «недоязыка», переизобретем функциональное и объектно-ориентированное программирование.

Представляю вашему вниманию перевод статьи под названием "Innovative Techniques To Simplify Sign-Ups and Log-Ins" от Anthony T. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением издания Smashing Magazine.

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



Форма авторизации на сайте Basecamp

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

Регулярные выражения (РВ) это, по существу, крошечный язык программирования, встроенный в Python и доступный при помощи модуля re. Используя его, вы указывается правила для множества возможных строк, которые вы хотите проверить; это множество может содержать английские фразы, или адреса электронной почты, или TeX команды, или все что угодно. С помощью РВ вы можете задавать вопросы, такие как «Соответствует ли эта строка шаблону?», или «Совпадает ли шаблон где-нибудь с этой строкой?». Вы можете также использовать регулярные выражения, чтобы изменить строку или разбить ее на части различными способами.

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



Можно скачать pdf и можно заказать

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

Итак, задача довольно тривиальная, и к её решению приступил с изучения предметной области.

Вслед за первой частью, призванной в первую очередь показать, что «не так страшен чёрт, как его малюют»

Статья об архитектуре части проекта, которая занимается он-лайн платежами. Намеренно не хотелось бы сейчас подробно описывать API конкретного биллинга или процедуру регистрации в нём. Тонкости конкретных биллингов нужно обсуждать отдельно, иначе тему просто не раскрыть. Цель статьи: обсудить вариант архитектуры, позволяющий нанизывать новые виды биллингов и типы платежей, с наименьшей головной болью.

Я хочу поделиться простым взглядом на сложные вещи.
Отлично помню своё первое столкновение с on-line платежами. Тогда меня такая задача морально напрягала: мало того что на мне ответственность за чьи-то деньги, так я ещё и не понимаю даже обычной банковской системы, что уж говорить о виртуальной.

Хотим представить вашему вниманию русскоязычную версию руководства tornado server 0.2

Разрабатывая интерфейс для очередного сайта, основной аудиторией которого будут люди не очень продвинутые технически, я задумался над вопросом об обязательных для регистрации полях и минимизации их количества.

В голову пришли следующие варианты:

0 полей: при загрузке страницы незалогиненный пользователь получает сгенеренный аккаунт, который ему предлагают использовать, вот еще один пример такого подхода.
— удобно для узкоспециализированных задач и мне не подходит. По функционалу уже недалеко от куки, если бы не привязанность последних к конкретному хранилищу в браузере или по :)

1 поле: email
Пользователь оставляет email, id создается автоматически, на email он получает пароль, авторизация либо по ID либо по email, username задается пользователем уже в профиле

+ Черт, это все таки одно поле! По умолчанию может быть сгенерен устойчивый к перебору пароль.
± username свободно меняются, и могут оставаться пустыми. Учитывать пользователей по айдишникам мне не хочется
— ЧПУ приобретают вид ufosite.nl/users/18567, скорее всего пользователь захочет сменить свой пароль. При ЧПУ вида ufosite.nl/users/customusername наступает ад для поисковиков. Строить ЧПУ на основе email, который, к тому же, далеко не все захотят публиковать — это подарок спамерам и ЧПУ становятся не совсем ЧПУ.

Этот топик — приглашение к обсуждению. В конце обещаю очень полезную вещь.

В последнее время, все больше появляется бесплатного и открытого. Все понятно, когда Google делает великолепный инструмент на котором можно было бы много заработать (SketchUp) — бесплатным — все понимают, что компания и так зарабатывает много денег и ей важнее заполучить больше пользователей. Хотя и есть платная версия. Однако все больше и больше из нас придумывают новые идеи, такие как YubNub (сервис не мой), и подобные, которые облегчат жизнь пользователям. Сделать — день-два, отладить неделя-десять, донести до ума пользователей — год.

Однако встает вопрос — тратить время на развитие сервиса — это терять деньги. Элементарно — сервер, люди, личное время — все деньги отнимает. Раньше эту проблему могла бы решить реклама…