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

Работа над созданием началась ещё в мае, в июле была неплохая рабочая версия, и вот в декабре у нас:

• Полное соответствие кодов ISO ISO-3166-1 и ISO-3166-2
• Возможность выбора системы деления – ISO, FIPS или GeoNames
• Полное покрытие стран и областей мира русскими переводами
• Логичная изоляция данных от кода, открываем дорогу SDK на других языках
• Официальный сайт с документацией на русском языке

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

В последнее время на Хабре и Гиктаймс появилось много статей (1, 2, 3, 4, 5, 6, 7) о SIM-карте, наделенной невиданными и неслыханными возможностями, что вызвало озабоченность и заинтересованность в различных кругах. Появилось множество скепсиса и споров, а затем различных теорий, порой потрясающих своей фантастичностью. Попробуем приоткрыть завесу тайны с технической стороны. Естественно, эти тесты не были бы возможны без данной SIM-карты, которую нам любезно предоставил MagisterLudi.

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

Начнем по порядку.

Привет, Хабр. В этой статье я расскажу о HTML Notification API.

Какие возможности предоставляет Notification API

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

Поддержка в браузерах

• Safari 6
• Chrome 27
• Firefox 22

Opera 15 beta не работает с Notifications API, несмотря на наличие конструктора Notification.
На мобильных платформах технология не работает.
В движке webkit есть старая нотация в виде webkitNotifications.

Как это работает

Цикл работы следующий:

1. Получить разрешение на отправку;
2. Правило фиксируется для сайта;
3. Отправить уведомление.

Вышел новый релиз блого-социального движка LiveStreet 2.0.

Новые возможности:

• Новая структура файлов движка. Фреймворк полностью отделен от приложения.
• Переработанный фронт на базе компонентов
• Механизм универсальных категорий. Возможность привязки категорий к разным объектам.
• Механизм дополнительных полей (EAV) для различных объектов
• Универсальный механизм управления медиа-файлами
• Управление типами топиков и их кастомизация
• Встроенная поддержка превью-изображений для топиков
• Возможность вставлять в топик несколько опросов
• Система управления правами пользователей
• Центральный крон

В этой статье показывается, как с помощью CSS трансформаций и махинаций с 3d сделать параллакс-эффект на сайте на чистом CSS.

Параллакс почти всегда создаётся с помощью JavaScript и, чаще всего, получается ресурсоёмким, из-за вешания листенеров на событие скролла, модификации DOM напрямую и срабатывания ненужных перерисовок и перестановок. Всё это происходит асинхронно с потоком, в котором браузер рендерит страницу, из-за чего скролл начинает подтормаживать, а картинка рваться на части. Более правильные реализации параллакса отслеживают скролл и используют отложенные обновления DOM с помощью requestAnimationFrame. Получается качественной другой результат, но почему бы вообще не избавиться от JavaScript?

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

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

• Принцип KISS. От англ. «keep it short and simple». Интерфейс должен быть простой и понятный, задачи должны решаться минимальным числом действий, все должно быть понятно и очевидно.
• Не заставляйте думать. Нужно избегать сложных действий, которые заставляют пользователей думать.
• Убираем очевидное. Не стоит показывать очевидные элементы интерфейса, нужно сосредоточиться только на действительно необходимых вещах.
• Соотношение сигнал / шум. В каждом интерфейсе есть важные элементы (сигналы) и маловажные или даже бессмысленные для определенной части системы (шум), естественно, нужно концентрироваться на сигналах и избегать шума.
• Проверенное лучше модного. Не стоит цепляться за моду и делать что-то только потому, что так делают другие, лучше отдать предпочтение проверенным элементам интерфейса.

Уже давно мечтаю об ОС с полностью анонимным трафиком. До недавнего времени я использовал следующий способ.
Виртуальная машина, на которую ставится анонимизируемая система, связана через локальную сеть только с хостовой системой (режим Host-only виртуального сетевого адаптера), на которой стоит Tor. Внутри гостевой ОС у приложений, которым нужен интернет, прописывался адрес прокси-сервера Polipo, установленного вместе с Tor на хостовой системе. Таким образом, выход в интернет с гостевой системы возможен только через Tor. Однако у этого способа есть недостаток. Для каждого приложения необходимо прописывать прокси, к тому же не все приложения имеют такие настойки. Прибегать к использованию программ-проксификаторов не хотелось, т.к. такое решение мне показалось не совсем «естественным». Ниже я расскажу о более «естественном» способе ТОРификации.

Прежде всего хотел бы поблагодарить за более, чем 80 звёзд на GitHub, которые мне дали читатели Хабра по результатам предыдущего поста. И это несмотря на то, что репозиторий был почти пустой, а ссылка была неочевидна. На лицо полезность этого пакета!

Для тех, кто пропустил первый пост, маленькое повторение. Если у Вас в приложении есть что-то вроде:

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

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

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

Телеком-операторы активно рекламируют быструю и дешевую 4G-связь. Но насколько она защищена, знают немногие. Экспертам Positive Technologies в процессе исследования безопасности 4G-коммуникаций удалось найти уязвимости в USB-модемах, позволяющие взять под контроль компьютер, к которому подключён модем, а также аккаунт абонента на портале мобильного оператора. Кроме того, атаки на SIM-карту с помощью бинарных SMS позволяют перехватить и расшифровать трафик абонента, либо просто заблокировать заданную «симку».