Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)

Межсайтовый скриптинг (XSS) — пожалуй, самый типичный вид уязвимостей, широко распространённых в веб-приложениях. По статистике, около 65 % сайтов в той или иной форме уязвимы для XSS-атак. Эти данные должны пугать вас так же, как пугают меня.

На днях я читал материалы на MDN и наткнулся на некоторые довольно интересные возможности и API JavaScript, о существовании которых я не знал. Хочу сегодня о них рассказать.

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

Приближается 2018 год, и технари — в частности веб-разработчики — должны отбросить многие старые методики и верования в сфере разработки защищённых PHP-приложений. Особенно это относится ко всем, кто не верит, что такие приложения вообще возможны.

Это руководство — дополнение к электронной книге PHP: The Right Way с сильным уклоном в безопасность, а не общие вопросы программирования на PHP (вроде стиля кода).

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

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

PHP очень далёк от других технологий. Например, в Java очень активно используются потоки выполнения, ещё они могут встречаться в пользовательских программах. В PHP такого нет. И тому есть причины.

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

Мы собрали форк MySQL от Facebook с движком RocksDB вместо InnoDB и потестировали его с реальными приложениями: Drupal, Wordpress, Redmine.

Это офигенная штука. При низкой нагрузке выигрыш маленький, десятки процентов. Зато при высокой нагрузке выигрыш в разы. Когда RocksDB добавят в стабильный релиз в MariaDB, я уверен, что в течение полугода половина народа перейдет с InnoDB на RocksDB. Особенно, небольшие сайты на cloud/VPS и выделенных серверах.

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

Я собрал в статью результаты тестирования реальных сценариев Redmine, добавил анализ результатов и выводы. Redmine на MySQL с RocksDB оказался быстрее, чем с InnoDB — от 20% при минимальной нагрузке до 3 раз при максимальной. Позже подготовлю материалы по Drupal и другим PHP-приложениям.

Вы сможете проверить работу MyRocks и самостоятельно — в конце статьи есть ссылки на инсталляторы и виртуальные машины с LAMP/LEMP/Ruby стеками, собранные с MyRocks вместо MySQL.

Эта заметка навеяна мелькавшими последнее время на хабре постами двух тематик — «интересные команды unix» и «как я подбирал программиста». И описываемые там команды, конечно, местами интересные, но редко практически полезные, а выясняется, что реально полезным инструментарием мы пользоваться и не умеем.
Небольшое лирическое отступление:
Года три назад меня попросили провести собеседование с претендентами на должность unix-сисадмина. На двух крупнейших на тот момент фриланс-биржах на вакансию откликнулись восемь претендентов, двое из которых входили в ТОП-5 рейтинга этих бирж. Я никогда не требую от админов знания наизусть конфигов и считаю, что нужный софт всегда освоится, если есть желание читать, логика в действиях и умение правильно пользоваться инструментарием системы. Посему для начала претендентам были даны две задачки, примерно такого плана:
— поместить задание в крон, которое будет выполняться в каждый чётный час и в 3 часа;
— распечатать из файла /var/run/dmesg.boot информацию о процессоре.

К моему удивлению никто из претендентов с обоими вопросами не справился. Двое, в принципе, не знали о существовании grep.



Поэтому… Лето… Пятница… Перед шашлыками немного поговорим о grep.

171 слово, которое должен понимать любой программист

Лицензия MIT – самая популярная лицензия для программ с открытым кодом. Здесь приводится одно из её прочтений, с построчным разбором.

Читаем лицензию

Если вы разрабатываете программы с открытым кодом, и не читали эту лицензию подробно – а она состоит всего из 171 слова – вам нужно этим заняться. Особенно, если вы не занимаетесь лицензиями на ежедневной основе. Отметьте всё, что вам непонятно. А я повторю все эти слова, по порядку и по кусочкам, вместе с контекстом и комментариями. При этом важно представлять себе её целиком.

Окончательно решив завести блог на Хабре, мы составили для себя тематический план. Посовещавшись, включили в него полезные вопросы о различных бизнес-процессах, работе с ТЗ, KPI, законах работы с корпоративным заказчиком… И как-то сразу отмели идею объяснять, как же этот софт устроен. Но комментарии к постам заставили нас пока ровно на один раз отступить от задуманного.

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

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.

Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

Содержание

• Трюки с URL
• Горячие клавиши
• Тикеты и пулл-реквесты
• Github markdown
• Аккаунт
• Работа с репозиториями
• Поиск кода
• Командная строка и Github
• User scripts
• Github-вандализм
• Дополнительные Github-ресурсы
• Полезные ссылки

Много пик сломано в мире на тему того, можно ли и как создавать многопоточность в PHP. Чаще всего все сводится к тому, что так делать нельзя или дискуссия материализуется в какие-то ужасные костыли (ох, сколько я их уже повидал). Я хочу изложить свою точку зрения на этот вопрос. Легко догадаться, что если бы моя позиция была “так нельзя” или “это зло”, то я бы не писал эту статью. Вот только погодите, не спешите доставать тухлые яйца и вооружаться мелкими бытовыми предметами для рукопашной схватки. Я постараюсь дипломатично изложить тему и максимально объективно раскрыть ситуацию. Так что самые смелые из моих читателей могут прочитать молитву от ереси и открыть статью.

Привет, Хабр! Сегодня я хочу представить вам огромную коллекцию из 51 набора бесплатных векторных иконок. Да, есть потрясающие ресурсы Flaticon или Iconfinder, но бывают случаи, когда необходима именно группа иконок в едином стилистическом оформлении. Определиться с выбором, вам поможет эта подборка. Я старался собрать не как можно больше, а действительно самое лучшее.

Среди веб-разработчиков существует много споров о том, что лучше: иконочный шрифт или SVG спрайты? Четкого ответа на этот вопрос нет. Каждый выбирает свое. Данные наборы иконок вас неограничиывают в выборе, поскольку представлены в различных форматах: @font-face, SVG, EPS, AI, PSD, Sketch.

В целом данная подборка содержит более 10 000 иконок, охватывающих множество категорий: интерфейсы, технологии, наука, спорт, маркетинг, среда, транспорт и тд. Полые, заполненные, цветные, во Flat, Material, Elegant, Cartoon, Hand drawing стилях.

Responsive Icons (100 иконок, PSD, AI, EPS, SVG)

CSS Refresher

Это большая коллекция практических советов и заметок по вёрстке. Своеобразная памятка для тех, кто каждодневно использует CSS. Освещаются самые разные темы, от деталей поведения плавающих элементов до использования SVG и спрайтов. Проект постоянно обновляется, активное сообщество github также принимает в нем участие, там добавляются интересные замечания, о которых, возможно, вы и не слышали.

От переводчика

Приветствую всех, меня зовут Максим Иванов, и сегодня я подготовил для вас перевод заметок разработчика из Сан-Франциско Васанта Кришнамурти (Vasanth Krishnamoorthy) «CSS Refresher». Web-программирование одна из самых быстро развивающихся отраслей в наше время. Казалось бы, возьми какой-нибудь видеокурс на tuts+ и освой html-верстку, однако, как говорил разработчик Opera Software Вадим Макеев, выступая на конференции CodeFest, они все равно это делают плохо. Но давайте посмотрим, может мы итак все это знаем.

Содержание

1. Позиционирование (position)
2. Отображение элемента в документе (display)
3. Плавающие элементы (float)
4. CSS селекторы
5. Эффективные селекторы
6. Переотрисовка и перерасчет
7. CSS3 свойства
8. CSS3 медиа-запросы
9. Адаптивный web-дизайн
10. CSS3 переходы
11. CSS3 анимации
12. Масштабируемая векторная графика (SVG)
13. CSS спрайты
14. Вертикальное выравнивание
15. Известные проблемы

Друзья, вы мне, конечно [1] [2], не поверите, но вышел Drupal 8. В последнее время поступает достаточно много вопросов на тему того, что почитать, посмотреть, послушать для изучения восьмерки. Очень многие чувствуют себя не вполне уверенно и задаются вопросами: переходить на неё или не переходить, жив Drupal или нет, и всем прочим.

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

Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker — «Understanding docker».

Что такое докер?

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

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

После того, как у меня появился новый монитор на рабочем месте, я начал новую итерацию улучшения своего «безмышечного» (mouse-less, прим. пер.) опыта. Вы же знаете, что это значит, не так ли? Это значит, что каждый раз, когда вы беретесь за мышку, убирая руку с клавиатуры, вы тратите немного времени и энергии. Если вам нужно набирать много текста (а я много пишу кода), это становится существенным.

Так же существует следующий уровень «безмышечного» опыта, когда вы стараетесь избежать труднодоступных клавиш, например Delete, Backspace, Escape или даже Enter.

Если вы держите руки в стандартной позиции для 10-пальцевой слепой печати, более удобно нажать Ctrl-m вместо того, чтобы тянуться мизинцем к энтеру.

Как известно, есть только один способ изучить иностранный язык – начать им пользоваться. Но как это сделать, если общение на нужном языке недоступно? Один из возможных вариантов — читать, причем, чем больше, тем лучше. Понятно, что это еще не все, но, по крайней мере, хоть что-то. Однако чтение обычных источников только на иностранном языке имеет ряд трудностей. В первую очередь, это конечно всем известная тема, когда все слова понятны, а смысл фразы так и остается загадкой. Ну, тот же «How do you do?» или «Да нет, наверное», если переводить все дословно. В этом случае очень помогает наличие параллельного перевода на родной язык. Тема не нова и давно используется: метод Франка, или просто параллельные переводы (билингва). Есть множество литературы в данных форматах, бери и читай, но…

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

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

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

Статья подойдет читателям, только начинающим знакомство с Symfony2. А людей, активно использующих этот фреймворк, попрошу поделиться замечаниями.