Джед Шмидт, Томас Фухс и Дастин Диаз — достаточно известные в JavaScript-коммьюнити ребята в последнее время нашли себе новую развлекуху — писать полезные штуки размером не больше одного твита, то есть 140 байт. Даже домен зарегали — 140byt.es, куда приглашаются все желающие попробовать свои силы в написании супер-компактных функций.

Естественно, в ход идут все самые изощренные способы и техники уменьшения размера исходника. У них есть вики-страничка с советами, которую я и решил перевести.

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

От переводчика: Я только начинаю присматриваться к Node.js, и, обнаружив это руководство, сильно пожалел, что оно не попалось мне на глаза раньше. Надеюсь, что этот перевод поможет многим разобраться, что же такое Node, и с чем его едят.

У вас уже чешутся руки попробовать Node.js и пора начинать обрабатывать начальство? Не торопитесь! Для некоторых компаний, которые я консультировал на предмет того, подходит ли им Node.js, правильный ответ был — «Нет!»

Это руководство — набор основанных на моём личном опыте советов для тех, кто хочет узнать, имеет ли смысл применять Node у себя в компании, и, если да, то как убедить в этом начальство.

От переводчика: Я думаю многие читали статью Rey Bango — What to Read to Get Up to Speed in JavaScript, но до хабра обсуждение так и не докатилось. Предлагаю закрыть этот пробел и поговорить о хороших книгах, блогах, тренингах и конференциях, посвященных в первую очередь клиентскому JavaScript и клиентской веб-разработке. Чтобы не копипастить оформляю статью в виде перевода.

Сейчас в рассылке JSMentors JavaScript идет обсуждение книг, который стоит прочитать, чтобы улучшить свои знания. Там было много позитивных отзывов и предложений. Я хочу показать вам те книги и интернет-ресурсы, который я считаю важными и которые помогут вам в обучении. На этой странице я перечислил большое количество источников, разделенных по уровням.

Учтите, что некоторый ресурсы могут принадлежать нескольким уровням и охватывают широкие аспекты языка. Если вы считаете, что я что-то упустил, пожалуйста, дополните меня в комментариях.

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

CSSO (CSS Optimizer) является минимизатором CSS, выполняющим как минимизацию без изменения структуры, так и структурную минимизацию с целью получить как можно меньший текст.
CSSO написан на Javascript, выполняется как в браузере, так и в командной строке (с помощью NodeJS).
Распространяется под лицензией MIT.

Ну что, начнем? Давайте напишем какой-нибудь небольшой, но законченный проект. Выделим на это ровно 1 час. Предлагайте название. Книжный магазин? Если других идей нет, то будем писать блог :)

Постановка проблемы

Некоторое время назад по долгу службы работы, встал на обсуждение вопрос «А нужно ли делать на новом проекте авторизацию через сторонние сервисы?». Мозг, взбудораженный красивыми всплывающими окошками, виджетами и прочими украшательствами, призывно требующими «Войди через меня!», конечно же обеими руками был за, да и современные вебдванольные (а то и, тьфу тьфу, вебтринольные, быть может?) тенденции развития крупных порталов, как бы, намекают. Однако, я не зря сказал, что началось всё с обсуждения, ибо, где есть споры, там есть и камни преткновения. Такой камень мы нашли и здесь.

Предположим, на сайте имеется красивая панелька, как, например, у логинзы, или просто отдельные виджеты авторизации, например, через контакт, твиттер, фейсбук и иже с ними. Легко войти на сайт? Безусловно. Но при этом, если человек войдет сразу со всех этих аккаунтов (одновременно или нет, не суть), для системы это будут разные люди, а следовательно, клоны одного и того же человека, учётной записи которого, быть может, и вовсе нету на сайте.

Казалось бы, какая разница, регистрировать аккаунт на сайте, или входить через внешние ресурсы?

Представляю вашему вниманию перевод статьи "Mobile Form Design Strategies" от Chui Chui Tan. Перевели в компании UXDepot. Специально для пользователей Хабрахабра с одобрением издания UX Booth.

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

Интернет на экране мобильного телефона находится под влиянием нескольких важных факторов:

• Окружающей среды — человек может пользоваться гаджетом в толпе, в режиме цейтнота или на ярком свету (соответственно, качество изображения на экране ухудшается)
• Сети — соединение может быть медленным и ненадежным
• Особенностей девайса — например, маленького экрана устройства

В очередной раз ковыряясь в чужом коде, понимаю насколько больная тема — стандарты кодирования в PHP…

Задрало.
Настолько плотно прижилась кругом эта дрянь, что и не встретить уже человеческого отношения к себе, как к пользователю.

Около пяти месяцев назад я завязал с zend framework и пересел на рельсы. Тогда же начал переписывать свой проект www.okinfo.ru. Сейчас он уже закончен и sloccount показал что количество строк в проекте уменьшилось с 15000 до 4000. Мои знакомые php разработчики попросили success story и в итоге родилась эта статья. В ней я опишу как оно было, а так же немного расскажу о своем переходе на ruby.

Преамбула

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

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

И мой ответ — можно. И нужно!

На хабре уже писали про OAuth 1.0, но понятного объяснения того, что такое OAuth 2.0 не было. Ниже я расскажу, в чем отличия и преимущества OAuth 2.0 и, как его лучше использовать на сайтах, в мобильных и desktop-приложениях.

Что такое OAuth 2.0

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

Xpath — это язык запросов к элементам xml или xhtml документа. Также как SQL, xpath является декларативным языком запросов. Чтобы получить интересующие данные, необходимо всего лишь создать запрос, описывающий эти данные. Всю «черную» работу за вас выполнит интерпретатор языка xpath.
Очень удобно, не правда ли? Давайте посмотри какие возможности предлагает xpath для доступа к узлам веб-страниц.

Парадигмы программирования

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

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

• инструкция (императивное программирование, FORTRAN/C/PHP),
• функция (функциональное программирование, Haskell/Lisp/F#/Scala),
• прототип (прототипное программирование, JavaScript),
• объект (объектно-ориентированное программирование, С++/Java),
• факт (логическое программирование, PROLOG).

Стоит заметить, что в общем случае язык программирования однозначно не определяет используемую парадигму: на том же PHP можно писать как императивные, так и объектно-ориентированные программы.

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

О чем пойдет речь?

Мне очень часто приходится проводить собеседования, нанимая на работу PHP-программистов. 2-3 человека в день — это вполне нормально, хотя и на грани выносливости.

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

Во-первых они совершенно не интересуются развитием языка, на котором пишут, и вопрос «А что нового в PHP 5.3» ставит их в тупик, а уж предложение порассуждать на тему «Чтобы Вы добавили в будущие версии языка» — просто пугает.

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

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

Таким кандидатам и посвящается этот топик. С уважением к их нелегкой доле (а быть программистом на самом деле непросто) и с надеждой, что он подтолкнет их вперед по пути самосовершенствования.

Что мы будем делать?

Давайте попробуем сделать интерпретатор Форта на PHP!

Форт меня всегда манил, как далекая галактика из антиматерии. Стек, слова в словаре, обратная польская нотация… Это только кажется сложным, но на самом деле очень просто, зато здорово «просветляет» и расширяет кругозор.

Давайте сделаем наше приложение консольным, никаких браузеров и серверов. Давайте писать его на PHP 5.3, стараясь использовать язык на 100%. И, конечно же, попробуем изначально сделать так, чтобы пришедшие после нас не повесились от нашего кода в первый же день.

Многие наверняка используют индикаторы процесса, например, когда передаете/получаете какие-нибудь данные через AJAX.

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

Делать специальный GIF под каждую ситуацию довольно глупо. Поэтому правильное решение — использовать Canvas.

Ниже предлагается перевод статьи, обращающей внимание на, на мой взгляд, довольно острую проблему в эпоху web 2.0, а именно чистоту URL-адресов.

На примере сайта Lifehacker.com показано какими проблемами может обернуться слепое следование state-of-the-art технологиям, погоней за SEO и отрицание принципа «прогрессивного улучшения» (progressive enhancement).

На прошлой неделе, в понедельник, сайт Lifehacker.com был недоступен по причине неработающего JavaScript. Lifehacker.com, наряду с остальными сайтами компании Gawker, отображали пустую главную страницу без контента, рекламы и всего остального. Переход с результатов поиска Google на подстраницы переправлял обратно на главную.

Javascript-зависимые URL

Gawker, как и Twitter до него, перестроил свои сайты на полную зависимость от JavaScript'а, включая URLы его страниц. JavaScript не смог загрузиться, что привело к отсутствию контента и сломаным URLам.

Новые адреса страниц выглядят теперь следущим образом: http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker. До понедельника, адрес был тем же, только без #!..

Здравствуйте, этим постом я хотел бы попытаться приблизить светлое будущее, в котором все используют «кошерную» кодировку UTF-8. В частности это касается наиболее близкой мне среды – веба и языка программирования – PHP, а в конце серии мы подойдём к практической части и разработаем ещё одну велосипедную библиотеку.

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

Дастин Московиц (технический основатель Facebook) и Джастин Розенштайн (в прошлом продакт-менеджер в Google и Facebook) подняли порядка $10 млн финансирования и готовят смерть Basecamp, Trac, Bugzilla и всем остальным популярным решениям в этом сегменте.



www.asana.com

Основные возможности

(Сорри за качество скринов.)

<sup>Приятный, неброский интерфейс :-)


Риалтаймовые обновления с точностью до буквы (хорошо видно на видео ниже)</sup>