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

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

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

Выход нашелся довольно быстро — это использование технологии виртуальных частных сетей Virtual Private Network (VPN) и ее свободной реализации OpenVPN. Эта реализация доступна практически для всех распространенных платформ, в том числе для планшетов и смартфонов. История развития OpenVPN насчитывает уже 12 лет (компания OpenVPN Technologies, Inc. была создана Francis Dinha и James Yona в 2002 году), так что это надежное и проверенное временем решение.

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

Теме OpenVPN посвящены многочисленные статьи и сообщения на форумах. Тем не менее, нужную информацию мне пришлось собирать по частям из разных мест. Попутно приходилось разбираться с многочисленными терминами и технологиями. В качестве серверов OpenVPN были использованы VDS на базе FreeBSD и Debian Linux, в качестве клиентов — рабочие станции FreeBSD, Debian Linux, Ubuntu и Microsoft Windows.

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

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

А что, если подняться на уровень выше? От анализа конкретных экземпляров вредоносных программ (что само по себе непросто) перейти к комплексному исследованию компьютерных инцидентов? Этим у нас занимается подразделение Global Research and Analysis Team (GReaT). К ним я недавно обратился с похожим вопросом: какие книги они могут порекомендовать другим специалистам по компьютерной безопасности (имея в виду, что азы программирования и прочие базовые вещи уже освоены)? В результате получился список из пяти книг — а на самом деле из десяти :-), — с которым можно ознакомиться под катом.

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

Под катом истории таких компаний, как Dropbox, Reddit, Quora, Foursquare, Groupon, Tinder и Airbnb.

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

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

Принципы условно сгруппированы в три группы: принципы принятия решений; принципы, направленные на повышение качества кода; принципы, направленные на повышение производительности кода.

• Принятие решений
  • Любое техническое решение должно быть обосновано
  • Ответственность за принятое решение всегда лежит на том или тех, кто принял данное решение
  • При принятии технических решений необходимо учитывать их действие во времени и их соответствие потребностям бизнеса
  • Одним из основных критериев при принятии технических и иных решений должна быть их наибольшая эффективность
  • Смело отступать от правил, методологий, шаблонов и прочих ограничений, если эффект от такого отступления превышает возможные потери (Special cases aren't special enough to break the rules, although practicality beats purity)
  • При необходимости сделать работающее, но, возможно, не наилучшее, решение сразу, а позднее улучшить его (Now is better than never, although never is often better than *right* now)
  • Если сложно выбрать между двумя альтернативными техническими решениями, то нужно выбрать любое и двигаться с ним дальше, когда появится больше инфорации, то можно будет сделать рефакторинг, если решение оказалось неоптимальным
  • Гибкость технических решений крайне желательна, а универсальность не обязательна
• Качество исходного кода
  • Качество кода следует оптимизировать на базе сформированной системы критериев, сбалансированной по отношению к затратам в краткосрочном и долгосрочном периодах
  • Писать оптимальный код сразу, если это не увеличивает его сложность и сроки разработки (Beautiful is better than ugly)
  • Самодокументируемый код имеет приоритет над хорошо прокомментированным (Beautiful is better than ugly)
  • Писать TODO и FIXME в коде
  • Давать переменным, функциям, методам, классам и другим объектам исходного кода имена точно отражающие их назначение, несмотря на увеличение длины названий (Explicit is better than implicit)
  • Меньшее число строк и объем кода предпочтительнее, при сохранении прежней читабельности кода (Simple is better than complex)
  • Применять инспекцию кода (code review) как инструмент обнаружения ошибок, выравнивания стиля разработки, знакомства с чужим кодом и обучения в команде
  • Применять повторное использование своего и чужого кода
  • Использовать специализированные библиотеки для решения конкретных задач, вместо разработки своего аналогичного кода
• Производительность
  • Производительность разработки кода имеет приоритет над производительностью исполнения кода
  • Оптимизация производительности исполнения кода должна быть обоснована соответствующей потребностью
  • Оптимизация производительности исполнения кода должна выполняться за счет устранения наиболее серьезных узких мест
  • В первую очередь должны быть использованы наиболее эффективные методы оптимизации производительности исполнения кода

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

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

Храните мелкие картинки, которые нельзя засунуть в спрайты, в data:image base64 в CSS — это экономит кучу запросов к вебсерверу.

Нам нужно:

1. Установить на сайте собственные иконки с помощью SVG.
2. Они должны управляться с помощью CSS (форма, размер, заливка, эффекты в том числе и их поведение).
3. Они должны иметь маленький вес и находиться в одном месте для экономии http запросов.
4. Работать во всех основных современных браузерах.

демо

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



При этом чек уносит с собой каждый наш покупатель, и это попросту глупо не использовать. Равно как стоит добавить бумажке немного полезности.

Доброго времени суток, уважаемые хабравчане!

Возникла передо мной сегодня задача генерации GET-параметров и всего URL в целом, на стороне клиента, прям вот щас, без возможности «поговорить» с сервером. Сразу оговорюсь, про этот пост я узнал вот прям перед написанием данной статьи ибо сначала закончил писать, а потом уже прибег к поиску, да и пост тот — не со всем про то же самое, что у меня.

Итак, к делу.

Задача и проблемы

Проблемы — те же что и в посте, который я привел выше:

• Невозможность использовать window.location для «приготовления» URL;
• Нельзя работать сразу с несколькими window.location в силу политики безопасности браузеров;
• Отсутствие известных готовых решений ( да и сейчас, уже апосля, я не нашел подобного кода )

Задачи которые я поставил перед собой:

• Удобный синтаксис
• Возможность как читать части URL так и изменять их
• Работа с GET-параметрами
• Кроссбраузерность и универсальность

Писал я на чистейшем JavaScript, причем без использования prototype.__defineGetter__ или prototype.__defineSetter__ в угоду кроссбраузерности ибо IE < 9 такого не умеет. Более подробно про getters/setters написано в этом посте.

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

Приступим! Раньше сядем — раньше выйдем.

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

Доброго времени суток, Хабр!

Так уж завелось, что подавляющее большинство веб-дизайнеров создают макеты сайтов в Adobe Photoshop. И каждый раз, мы, бедные верстальщики, испытываем на себе все минусы и проблемы PS. И нам всегда приходилось с ними мириться, либо использовать всяческие плагины костыли, и сторонние приложения костыли. Даже новомодный и перспективный Sketch создан, в первую очередь, для создания макетов, а не для извлечения информации для верстки.

Но темные времена прошли, и тучи начинают рассеиваться над миром фронтенд-разработчиков. Итак, встречайте: Avocode!

В прошлом году хабраюзерам был представлен Codeo — минималистичный аналог Pastebin. За последний месяц я полностью переписал сервис, добавил в него ряд новых возможностей, и перенёс его на новый домен (code.re).

Очередной приступ паранойи был вполне обоснован — он наступил после прочтения статьи о методах анонимности в сети, где автор на примере браузера FireFox рассказывал о потенциальных утечках идентификационной информации. И стало интересно — а на сколько озвученные решения применимы, скажем, к браузеру Google Chrome?
Скрыть реальный IP — используем разные VPN сервера, отключить львиную долю отслеживающих скриптов — Adblock Plus и Ghostery, убрать Referer — не вопрос, что то ещё забыли… Ах да — User-Agent — своеобразный «отпечаток», по которому (в связке, скажем, с IP) легко идентифицировать пользователя. И с этим надо было что-то делать. Найденные решения лишь статично изменяли значение User-Agent, чего было явно недостаточно. Тогда и было решено написать плагин для скрытия реального User-Agent'a, а если быть точнее — подменять его на рандомный. Или почти рандомный.

Для нетерпеливых сразу: исходники на GitHub и расширение в Google Webstore.

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

В данной статье описывается процесс создания персонажа для игрового движка. Статья в первую очередь адресована тем, кто интересуется процессом разработки next gen моделей, а также всем, кто хочет заглянуть за кулисы современного игродела. Персонажа я делал для портфолио, на персонажей переключился совсем недавно, можно сказать, что это первый доведенный до ума персонаж. Поскольку данная работа — мой личный проект, то я установил ограничение треугольников в 20 000, текстуры в 2048*2048, работа планировалась под PBR.

Введение

В данные статье я хочу вам рассказать о моем способе загрузки файлов на сервер Node.js с помощью JQuery Ajax. Да, я понимаю что есть уже и другие решения, например JQuery File Upload, но все таки иногда хочется сделать что-то уже существующее, для того чтобы понять как это все устроено. Данное решение является учебным примером, все замечания по поводу кода или предложения по его улучшению оставляйте в комментариях.

Что будем использовать

1. Bootstrap
2. JQuery
3. Модуль для Node.js Multiparty

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

Zephir — Ze(nd Engine) Ph(p) I(nt)r(mediate). Зефир — это компилируемый высокоуровневый язык программирования, предназначенный для написания PHP расширений без использования C. Проект от создателей Phalcon (скомпилированный PHP MVC Framework). О Zephir на Sitepoint
   

JSDB.IO — большая и качественная база нужных скриптов/библиотек/фреймворков на JavaScript. Все распределено по категориям: Animation, Application, Audio, Video, Games и др. Дабы собрать все популярные .js воедино добавлю еще три ссылки: Microjs (множество маленьких полезностей до 5кб), а еще jsdelivr и cdnjs, которые позволяют добавлять собственные скрипты.

Snap.svg — продукт от Adobe Webplatform. Недавно я рассказывал про "достойного конкурента Raphaël" и в комментариях оспоривали эту фразу из за отсутствия поддержки такого же множества браузеров. В разработке Snap участвует автор Raphaël — Дмитрий Барановский, а причина создания новой библиотеки для работы с SVG — невозможность поддерживать все возможности SVG в старых браузерах.

At.js — очень юзабельный скрипт для автозаполнения (в демо используется Emojify). А еще есть более функциональная библиотека для автозаполнения — Typehead от Twitter.

$('.atwho-inputor').atwho({
  at: "@", data: ["one", "two", "three"],
});

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

Привет, username. Свой первый пост я хочу посвятить актуальной проблеме, связанной с появлением большого количества новых форматов дисплеев и непрекращающейся гонкой за плотностью пикселей. В свете появления таких устройств, как очки дополненной реальности, смартчасов, 4к-мониторов и еще более широкого спектра планшетов и ноутбуков, возникает вопрос: какой размер графического элемента/текста следует считать оптимальным и в чем его измерять. Android-разработчики, несомненно, тут же воскликнут: «Да, конечно, в dp!». Но практика показывает, что дела обстоят несколько сложнее.