После моего недавнего выступления на MoscowJS #17 с одноимённым докладом у многих возник интерес к этому инструменту. В рамках 11-го выпуска RadioJS, Миша Башкиров bashmish рассказал, что решился попробовать его в своём новом проекте, об успешном опыте и множестве положительных эмоций. Но были озвучены вопросы и возникла дискуссия, в результате которой я решил написать эту статью, чтобы раскрыть основные тезисы с доклада и рассказать о том, что тогда не успел.
Статья ориентирована, как на профессионалов, так и на тех, кто с похожими технологиями ещё не сталкивался.
Итак, начнём.

Добрый день, уважаемые читатели.

В последнее время на Хабре всё чаще упоминается такой замечательный фреймворк, как React.js. Я работаю с ним уже 4 месяца, поэтому решил поделиться опытом использования. Решено было сделать небольшую серию статей, которые должны стать максимально кратким полным руководством по фреймворку. Это моя первая публикация на Хабре, поэтому прошу не судить слишком строго. Моя главная задача – рассказать о подходах и практиках, второстепенная – узнать у людей, использовавших React, как они работают с ним и как они решали те или иные кейсы. Ну и, конечно, расширить сообщество фреймворка. Начало я оформил в виде небольшого конспекта-шпаргалки. А дальше только практика.

Предоставляемая информация верна для любой платежной системы. В том числе для систем DSS PCI, простого эквайринга (прием платежей банковскими картами), виртуальных платежных систем (яндекс.деньги, вебмани, робокасса и др).

Обсуждение статьи «Скомпрометированы транзакции плательщиков RBK Money» показало критичную безграмотность некоторых комментирующих. Обычно свет знаний у невежества вызывает страх и раздражение, что интересно отследить по комментариям. Я попытался дать разъяснения там в обсуждениях, за что и поплатился.

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

Привет, Хабр.

В этой статье пойдет речь о том, из чего состоит Marionette.js, и о возможности не писать свой велосипед.

Статья рассчитана в первую очередь на работавших с Backbone.js и/или Marionette.js.
Для вновь знакомящихся будет полезна первая, обзорная, часть и ссылки в конце статьи.

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

Главная новость — это глина! Та самая глина, к которой Opportunity шел три года, искал пол года, а найдя не смог толком изучить. Curiosity ее нашел и изучил на 200 сол своей марсианской карьеры, просто пробурив первую, пробную скважину. Я думал интрига еще год будет сохраняться, т.к. ближайшие залежи глины со спутника обнаружены в 3 км ближе к горе, но тут даже NASA не ожидало такого подарка/подвоха. А подвох серьезный — жизни нет, хотя органика есть.

Итак, как и обещал в первой части, продолжаем упрощать бытовую жизнь хабражителя. Сегодня 8 марта (кстати, девушки, поздравляю!) и части мужчин хочется порадовать своих женщин и освободить их от «рабского труда» на кухне, а другой части – приготовить для себя не традиционные пельмени\вареники\сосиски, а что-то посущественней.
Вот несколько проверенных рецептов, которые пригодятся и первым, и вторым.

Осторожно, много картинок. Голодным не входить!

Работать где-то мечтают не все. Работать в компании Google мечтают многие, кто решил связать свою жизнь с IT.

Google — компания-гигант, одна из крупнейших IT-корпораций. Сотрудники такой компании нужны постоянно (новые области, текучка кадров).

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

Шаг 1 — резюме.

В компании Google к резюме особое отношение. Получая миллионы заявок в год, компания выбирает несколько сотен сотрудников. Именно поэтому отличное резюме — первый шаг к работе мечты.
Что писать в резюме нужно обязательно:

• e-mail, телефон для связи
• все места учёбы (ВУЗы), дополнительное образование
• Опыт работы*
• Личные качества (придумайте что-то оригинальнее отзывчивости, стрессоустойчивости, коммуникабельности)
• Хобби
• Reference — люди, которые могут дать вам рекомендации
• Знание языков

*Опыт работы в резюме для Google (и вообще для западных компаний) — это не только должность, компания, но и те успехи и достижения, которых вы добились на позиции. Если вы продажник — покажите цифры. Если программист — то как именно ваша работа улучшила работу компании. Работу рекомендуется указывать всю, а не только по профилю (если работали в МакДоналдсе, то даже такое стоит указать).

Что не нужно писать в своём резюме:

• Дату рождения, личные данные
• Есть ли водительские права
• Семейное положение
• Прочую «шелуху», которая только отвлечёт рекрутера

Как-то знакомый преподаватель английского языка рассказал, что вчера был на вечеринке и услышал анекдот:

— Ложась спать программист ставит рядом на столик 2 стакана.
— Один с водой — если захочет пить, второй пустой — если не захочет.

Смеялись только программисты, а остальные и он, в том числе, анекдот не поняли. Пришлось сильно постараться, чтобы объяснить гуманитарию, что в этом анекдоте смешного.

Программист – относительно новая профессия. Зародилась она по времени где-то между физиком-ядерщиком и космонавтом. Многие «лирики» и даже некоторые «физики» и «космонавты» нас не понимают. И среди этих людей часто находятся наши коллеги, менеджеры, сотрудники коммерческих департаментов, отделов кадров, владельцы бизнеса, заказчики и др. Этот пост для них. Ну и немного для себя (типа, ретроспектива самоанализ).

Disclaimer. Сейчас программистов много. Хороших и разных. Я буду писать про хороших. И то, не про всех, а про большую часть из тех, с кем имел честь вместе разрабатывать ПО.

Всем добрый вечер/день/утро, кому, что ближе в данный момент. Давненько читаю данный ресурс и всегда с особенной любовью относился к статьям, которые так или иначе мотивировали меня, заставляли задуматься и подталкивали что-нибудь изменить в моей жизни. Поэтому, решил попробовать вдохновить или так сказать, морально помочь тем, кто чего-то хочет, но, как и все нормальные люди сомневается. А конкретно рассказать о моей иммиграции в страну Оззи. Сразу оговорюсь, тем кто любит писать что-то вроде: «многобукв»,«неосилил»… заранее приношу извинения, потому как сам «многобукв» люблю, а когда не люблю иду в твиттер, чего и Вам советую.

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

С чего все началось

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

В Flash 10, как оказалось, нельзя программно самому копировать текст в буфер обмена. До его выхода был очень удобный и элегантный способ, например, «Копировать код для вставки изображения в блог» / «Copy embed code» сразу в буфер пользователя. Я не говорю про IE, в котором это всегда раньше было реализуемо (не знаю как в ИЕ8) с помощью javascript-вызова window.clipboardData.setData('text',text);
Речь о том, как это сделать для пользователей альтернативных браузеров.

Введение

Из всех наслаждений, отпущенных человеку в жизни,
самое изысканное — шевелить мозгами.
(Борис Акунин)

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

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

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

С каждым днем пользователи смартфонов занимают все большую долю интернета. По данным LiveInternet доля российских пользователей OS Android уже превысила долю Windows7. В выходные дни пользователи мобильных платформ пользуются интернетом значительно чаще. Та же тенденция наблюдается и в мире. Все это еще раз доказывает необходимость адаптации сайта для смартфонов и планшетов.

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

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

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

Впервые слышите о tornado? Слышали, но боялись асинхронности? Смотрели на него более полугода назад? Тогда я посвящаю эту статью вам.

Пара хитростей которые я использую при работе с ssh

Я стал замечать, что в последнее время build-системам стали уделять всё больше внимания, и, под влиянием этого, их в одночасье стало настолько много, что, честно говоря, уже всех и не упомнить. Последнее время у меня на слуху четыре системы: Grunt, Gulp, Brunch и Gear. Про все что-то где-то было написано, но ни разу не ставился вопрос о том, какие преимущества или недостатки они имеют друг перед другом? И именно поэтому я решил провести сравнительный анализ самых популярных build-систем(по версии google).

Но сперва надо определиться с критериями, по которым мы будем оценивать эти системы:

• Начало работы.
• Производительность. Никто не хочет ждать по минуте после изменения одного coffee-файла.
• Документация. Чем нагляднее и проще — тем лучше.
• Плагины. Ведь мы не хотим столкнуться с проблемой, когда мы начали использовать билд-систему, а в ней нет адаптера, скажем, для jasmine?

Теперь, я полагаю, с вводной частью можно покончить и приступить, наконец, к сравнению.

На хабре уже проскакивала статья про такие замечательные вещи, как Map, WeakMap и Set, но в действительности реальные возможности этих API не были раскрыты (если я все-таки хорошо воспользовался поиском).
Эти API толком не реализованы нигде, кроме firefox (можно включить в chrome canary), но даже там до недавних пор не поддерживалось использование HTMLElement-подобных объектов в качестве ключей. Polymer, например, убрал только три недели назад

	if (navigator.userAgent.indexOf('Firefox/') > -1)

Чем же они так хороши? По сути Map/WeakMap можно воспринимать как обычные хэш-объекты, только в качестве ключей можно использовать только сложные объекты (Object, Function, Array), так как привязка идет не по содержимому, а по адресу в памяти.
Таким образом появляется возможность привязаться на фронтэнде к

• dom-элементу
• XHR-запросу
• File-элементу

Это дает нам возможность работать без id-шников элементов, делать дата-биндинг в разы быстрее, создать безумную альтернативную реализацию promises и так далее.
Мы будем говорить о WeakMap. Даже не так, мы будем говорить о существующих полифиллах для WeakMap.

Ссылка на стандарт: www.w3.org/TR/2013/WD-shadow-dom-20130514

Итак, что же такое shadow DOM:
Shadow DOM (или теневая модель документа) — часть документа, реализующая инкапсуляцию в DOM дереве. Она (теневая модель) является частью документа и встраивается непосредственно внутрь страницы.
Для упрощения отладки shadow DOM, в хроме можно включить отображение в веб-инспекторе (Settings — General — Show shadow DOM).

Надо заметить, что в стандарте реализуемая инкапсуляция называется функциональной, поскольку shadow DOM встраивается в документ и является одной из многих его частей, работающих «независимо» (более-менее независимо) друг от друга. Соответственно, при проектировании реализации, нужно было установить функциональные границы в дереве документа, чтобы как-то оперировать с множеством таких «независимых» фрагментов. Для решения проблемы инкапсуляции, и была введена новая абстракция — shadow DOM, позволяющая создавать несколько DOM деревьев в пределах одного родительского дерева и был разработан документ, описывающий ее.