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

Вы хотите чтобы Ваши устройства (Windows\Linux\Android\iOS) начали использовать IPv6, но Ваш провайдер его еще не предоставляет? У Вас есть собственный сервер\VDS\просто компьютер с линуксом и постоянным прямым IPv4 (НЕ IPv6) адресом или даже свой openvpn сервер? Тогда возможно эта статья Вам поможет.
Она не для маститых сетевых гуру, я просто собрал в одном месте набор указаний с целью распространения IPv6 среди масс. Хотя буду благодарен всем маститым гуру, которые меня раскритикуют в комментах и укажут на ошибки. Так как пишу я пост практически сразу после того, как система заработала. Все может быть бесконечно далеко от идеала.

В продолжение вводной части habrahabr.ru/post/196248, в этой статье я обзорно расскажу о механизме компонентной системы реализованной в библиотеке controls.js и используемой в Markdown webdocs для создания и вставки активного контента в текстовый документ.

Добрый день, дорогие хабражители.

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

JavaScript, the winning style

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

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

В отличие от Питона у которого есть единый свод правил «Style Guide for Python Code», у языка JavaScript такого нет. Однако на выбор есть целых 6 популярных гайдов:

• Google JavaScript Style Guide
• npm’s coding style
• Felix’s Node.js Style Guide
• Idiomatic JavaScript
• jQuery JavaScript Style Guide
• Douglas Crockford’s JavaScript coding style

Помимо гайдов, не стоит так же забывать об автоматических анализаторах кода, таких, например, как JSLint и JSHint. И в них уже заложены свои настройки. Вопрос в том, какой же все-таки максимально правильный способ писать код на JavaScript, который был бы актуален и максимально соответствовал бы большинству рекомендаций? Давайте попробуем объединить большинство рекомендаций в этой статье и подумаем как можно оптимизировать процесс проверки качества кода.

Я думаю, что на многих сайтах пользователя спросят его физический адрес. Для доставки ли, для отсылки бумажного спама уведомлений ли. И, в общем-то — это мелочь. Вбил индекс, Москва, область, район, село, улица, дом, квартира. Казалось бы, что тут упрощать, каждый вроде помнит свой адрес, трудно ли его вбить? Но дьявол, как всегда, кроется в мелочах: пользователь опечатывается в адресе, посылка уходит не туда, лучи «добра» идут вам в обратную связь и вообще жизнь плохеет.

Приглядитесь к первой части адреса — индексу. В этом наборе из шести цифр уже есть область, район и город/село. Их можно подставить автоматом. Этим мы убъём сразу двух зайцев:

• Убережём пользователя от ошибок (при вводе неверного индекса он сразу заметит, что город-то не его), что, в случае доставки письма (а то и посылки), может здорово её ускорить (пока её по неверному индексу зашлют, да пока разберутся, что не туда заслали, да отправят туда — пользователь вам всю плешь проест)
• пользователю будет приятно, что о нём заботятся :-)

Дело за малым: нам нужна база почтовых индексов.

И она есть! Всамделишняя, электронная и, главное, официальная база индексов от Почты России.

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

1. Промдизайн: что вообще скрывается под этим словом?
2. Разработка дизайна и конструкции корпуса: из чего состоит проект?
3. Работа с промдизайнерами: как организовать сотрудничество и оценить результаты?

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

В прошлом году я был одним из тех, кто поступил в Школу разработки интерфейсов Яндекса и закончил её, и сегодня хочу рассказать вам о том, каким я увидел учебный процесс в ШРИ, как это бывает и что даёт.

Честно признаюсь, что поводом для поста стал второй набор в Школу разработчиков интерфейсов Яндекса, который проходит сейчас. В этом году занятия Школы будут проходить не только в Москве, но и в Екатеринбурге. Программы курсов немного отличаются, но везде есть как теоретические, так практические занятия. Вести их будут ведущие фронтенд-разработчики Яндекса, которые работают над интефейсами Поиска, Почты, Карт, Маркета и других сервисов.

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



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

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

Новые полезные штуки для веб-дизайнеров за июнь 2013. Остальные подборки доступны по тегу "новое для веб-дизайнера"

Инструменты

Red Pen — сервис позволяет легко получать обратную связь на свои работы в формате PNG: после загрузки картинки любой пользователь может оставлять свои комментарии к файлу

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

Однако в процессе подготовки я понял, что информации по практическим вопросам подготовки и сдачи не достаточно, особенно по прохождению аудита.

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

Vim — уникальный по своей гибкости редактор, который при должной настройке может едва ли не идеально удовлетворять все пожелания работающего с ним. Правда эта настройка может продолжаться месяцы, а то и годы, что является и достоинством, и недостатком vim’а. Существует множество статей и туториалов по использованию Vim для разработки на Python и Django, надеюсь мне удастся рассказать что-то новое. В своей статье я постараюсь по минимуму упоминать плагины общего назначения, вроде NERDTree или surround.vim и опишу несколько более специализированных расширений и настроек, которые существенно упростили процесс работы на Python.

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

Примерно два месяца назад, в апреле 2013 года комапания Sauce labs объявила о поддержке iOS / Mac для CI-сервера Travis. Сам сервис существует уже довольно давно, и пользуется довольно большой популярностью в open-source community благодаря поддержке большого количества языков и удобству использования. Cервис бесплатен для любого пользователя github и открытых репозиториев. На Хабре уже имеется пост о сервисе и его настройки для тестирования Ruby-проектов, поэтому в этой статье я хотел бы рассказать о более специфической стороне сервиса — настройке автоматической сборке билдов iOS проектов на Travis-CI. Основным фокусом этой статьи будет связка CocoaPods + Cedar + Travis CI, однако я постараюсь рассказать немного и о других связанных с темой вещах.

Итак, начнем.

Привет хабра-люди,

Под катом пошаговая инструкция как создать свое приложение с потоковым видео под iOS. Понадобится XCode, СДК с клиентским АПИ, ровные руки (в принципе необязательно) и чашечка кофе.

Американский инженер Бен Коукс (Ben Kokes), собираясь предложить руку и сердце любимой девушке, смастерил обручальное кольцо с резонансным трансформатором и тремя маленькими светодиодами среди драгоценных камней. Идея в том, что кольцо невесты начинает светиться, когда жених берёт её за руку.

Шаг за шагом мы создаем сервис, объединяющий людей вокруг музыки. В рамках этой концепции мы многое переработали в новой версии Tracks Flow. Сегодня мы расскажем вам о наших новых решениях, но для начала немного цифр.

За 1 год альфа-версии:

Регистраций: 36 400
Создано плейлистов: 46 700
Отмеченно любимых треков: 389 600
Прослушано: 8 910 000 треков ≈ 594 000 часов ≈ 68 лет непрерывного воспроизведения
Самые популярные треки:

1. Alex Clare – Too Close 1183
2. Gotye – Somebody That I Used to Know 959
3. Adele – Skyfall 897

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

Уровень подготовки веб-мастера: любой

Теперь наша система поддерживает разметку schema.org для логотипов организаций. Это позволит вам выбрать логотип, который будет представлять ваш сайт в результатах поиска Google.

С помощью этой разметки вы можете указать системе, где находится ваш логотип. Например, если вы – владелец сайта www.example.com, можно использовать следующую разметку элементов на странице:

<div itemscope itemtype="http://schema.org/Organization">
<a itemprop="url" href="http://www.example.com/">Главная</a>
<img itemprop="logo" src="http://www.example.com/logo.png" />
</div>

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

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

Вот чем меня точно не удивишь, так это вопросом, как стать профессиональным независимым разработчиком игр и достичь на этом пути успеха. Если честно, слышать его — по-прежнему большая честь для меня, поэтому сначала я каждый раз благодарю задавшего этот вопрос. Но вот дальше… черт, если я действительно собираюсь помочь человеку стоящим советом, то это потребует от меня немалых усилий. Я, конечно, всегда могу «отмазаться», сказав что-то вроде «Дерзай! Старайся! Следуй только за своим сердцем!» — и, на самом деле, это будет не самый плохой ответ. Впрочем, пользы от него тоже будет немного.

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

Приятного вам чтения!

Привет. В силу специфики, на работе используется Linux с KOI8-R, все коммиты в git репозиторий осуществлялись в локальной кодировке. Через некоторое время было принято решение перекодировать репозиторий в UTF-8. В этой статье я хочу обсудить технологию изменения кодировки существующего git репозитория, а заодно и исправления некоторых ошибок допущенных в определенных коммитах.