Почему так важно запретить самому себе отладку руками?

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

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

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

Предлагаю вашему вниманию перевод статьи «Becoming PHP professional. Missing link».

Введение

Когда я читаю различные блоги, связанные с PHP, вопросы на Quora (англоязычный сервис вопрос-ответ, прим. переводчика), сообщества в Google+, газеты и журналы, я часто замечаю крайнюю поляризацию навыков программирования. Вопросы бывают или уровня «А как же мне подключиться к базе данных MySQL», или что-то из области «Как мне лучше распределить ресурсы моей почтовой системы для того, чтобы отправлять более одного миллиона писем в час без использования нового сервера?»

Лично я выделяю 4 четких уровня «славы» в PHP (применимо так же и для любого другого языка или профессии): новичок, среднячок, профессионал и элита.

Content Security Policy (CSP, политика защиты контента) — это механизм обеспечения безопасности, с помощью которого можно защищаться от атак с внедрением контента, например, межсайтового скриптинга (XSS, cross site scripting). CSP описывает безопасные источники загрузки ресурсов, устанавливает правила использования встроенных стилей, скриптов, а также динамической оценки JavaScript — например, с помощью eval. Загрузка с ресурсов, не входящих в «белый список», блокируется.

Интро

Не так давно я выступал на конференции FrontendConf 2015 (РИТ++) с темой данной статьи. И при подготовке доклада начал искать информацию, а кто вообще выступал на данную тему и что есть в Сети на данный момент.

Оказалось, что информации совсем немного, более-менее можно было бы отметить доклад mikewest.org/2013/09/frontend-security-frontendconf-2013 от Mike West из компании Google, но какой-то «непентестерский» взгляд и уж совсем мало материала. И www.slideshare.net/eoftedal/web-application-security-in-front-end где тема раскрыта более детально, но выступление 2011 года. А за 4 года технологии и атаки на месте не стояли.

Долго и сложно выбирая темы, что же все-таки рассказать разработчикам фронтендов про безопасность, при этом минимум касаясь бекэнда (местами все-таки это неделимо), получился доклад, а здесь — его текстовый пересказ.

О чем вообще разговор?

А действительно, о чем тут вообще можно разговаривать? Говоря про взломы и безопасность невольно приходят в голову тезисы — слили базу, получили доступ к выполнению команд ОС на сервере, прочитали чужую переписку. Но это все — server side код. А что ж может «нагородить» фронтэндер? Главная опасность, конечно же, в обходе атакующим SOP — Same Origin Policy, главной политики безопасности браузеров, которая регулирует работу в разных Origin. Но не только, давайте разбираться.

У JS есть несколько концепций, связанных с областью видимости (scope), которые не всегда ясны начинающим разработчикам (и иногда даже опытным). Эта статья посвящена тем, кто стремится погрузиться в пучину областей видимости JS, услышав такие слова, как область видимости, замыкание, “this”, область имён, область видимости функции, глобальные переменные, лексическая область видимости, приватные и публичные области… Надеюсь, по прочтению материала вы сможете ответить на следующие вопросы:

— что такое область видимости?
— что есть глобальная/локальная ОВ?
— что есть пространство имён и чем оно отличается от ОВ?
— что обозначает ключевое слово this, и как оно относится с ОВ?
— что такое функциональная и лексическая ОВ?
— что такое замыкание?
— как мне всё это понять и сотворить?

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

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

Разрешение экрана в наши дни колеблется от 320px (iPhone) до 2560px (большие мониторы) или даже выше. Пользователи больше не просматривают сайты только на настольных компьютерах. Теперь пользователи используют мобильные телефоны, небольшие ноутбуки, планшетные устройства, такие как iPad или Playbook для доступа в интернет. Поэтому, традиционный дизайн с фиксированной шириной больше не работает. Дизайн должен быть адаптивным. Структура должна автоматически изменяться с учетом всех разрешений дисплеев. Эта статья покажет вам как создавать кросс-браузерный адаптивный дизайн при помощи HTML5 и CSS3 media queries.

В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.

Похоже, все эти люди без устали стараются заставить каждого программировать так, как они считают нужным. Эта статья написана, чтобы поделиться прагматичным взглядом на PHP-программирование. Взглядом, продиктованным опытом и практическими последствиями, а не популярными тенденциями, теориями или академическими догмами. Материалы, представленные на сайте PHP — The Wrong Way, будут обновляться по мере появления новой информации. Приглашаем всех поучаствовать в этом.

На Хабре уже был перевод с обзором несколько месяцев назад, но недавно вышел первый релиз-кандидат PHP 7.1, а значит никаких существенных изменений больше не будет и можно сказать, какие точно изменения будут в релизе. Я решил немного оживить сухой “changelog” своим вольным переводом изменений, которые принесет нам новая минорная версия 7.х ветки.

Эта статья поможет ответить на вопросы владельцев, разработчиков и системных администраторов PHP-сайтов:

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

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

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

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

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

Для теста выбрана лишь одна составляющая php-хостинга. Мы будем тестировать web-серверы Nginx и Apache2, модули mod_php и php-fpm, версии php php53 и php56, посмотрим, как влияют оптимизаторы apc и opcache на скорость работы сайта.

Давайте представим, что вас перевели на новый проект. Или вы сменили работу и о проекте максимум только слышали. Вот вы садитесь за рабочее место, к вам приходит менеджер, жмёт руку и… прямо сходу открывает страницу проекта, тыкает пальцем в монитор и просит вставить «информер о предстоящем событии Х». На этом вы расстаётесь… Что делать? С чего начать? Как создать «информер»? Где найти нужный шаблон? И море других вопросов.

Под катом будет рассказ, как мы стараемся организовать эти процессы, какие инструменты создаём для препарирования SPA. Кроме этого, мы поговорим о технических подробностях реализации Live Coding / Hot Reload и чуток о VirtualDom и React с Angular.

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

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

О том, насколько печальна ситуация, можно судить по результатам опроса, который я проводил ранее: проблемой доступности вообще не занимаются 84% ответивших. Ещё 12% пытаются делать сайты доступными, но признают, что делают не всё или не так. И только 2% уделяют должное внимание адаптации сайта для людей с ограниченными возможностями.
Честно говоря, я думал, что в других странах с этим лучше, но, судя по статье, там всё так же плохо как и у нас.

Давайте делать веб доступным для всех, коллеги — это важно!

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


ДЕМО

META-теги

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

META-теги имеют два возможных атрибута

— <META HTTP-EQUIV="имя" CONTENT="содержимое">
— <META NAME="имя" CONTENT="содержимое">
META-теги должны находиться в заголовке HTML-документа между <HEAD> и </HEAD> (особенно это важно для документов, использующих фреймы).

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

Решил проводить регулярные лекции и практические занятия со своими сотрудниками по программированию на PHP, MySQL, Javascript. А также другим технологиям необходимым для выпуска качественных сайтов. Начать решил с самого «верха», с HTML тэгов. Буду рад, любым комментариям :)
Сразу оговорюсь, что бОльшая часть информации я нашел в интернете, внизу статьи будут приведены ссылки на источники. Часть информации была переведена совместно с google translate.
Итак:

Почему так важен DOCTYPE

Вроде бы вы сделали все правильно, но ваш сайт почему-то не выглядит или не работает, как ожидалось, в последних версиях броузеров.
Вы написали правильный стандартный XHTML код и стандартный CSS. Вы воспользовались стандартной спецификацией для работы с DOM (Document Object Model), чтобы управлять динамическими элементами на странице. И все-таки, в броузерах, которые казалось бы сделаны с соблюдением именно этих стандартов, ваш сайт не работает. Скорей всего, ошибка кроется в неправильном заголовке DOCTYPE.
Эта небольшая статья расскажет вам о заголовках DOCTYPE, которые работают, а также объяснит практическое и теоретическое значение этого, казалось бы отвлеченного от реальности, тега.

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

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

Содержание

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

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

В прошлом году PHP-FIG приняла стандарт PSR-7, описывающий работу с сообщениями HTTP. Хорошая статья об этом стандарте и его применении была на Хабре. И хотя PSR-7 — большой шаг вперёд, ему не хватает логичного продолжения — общего интерфейса клиентов HTTP. Созданием недостающего компонента занялась группа PHP-HTTP.

Примечание переводчика: визит под кат этого поста означает большие объёмы потреблённого трафика. И это иронично, если учесть поднятую тему. Но всё сразу встаёт на свои места, если помнить, что в оригинале это было выступление в прошлом ноябре в Сиднее длиной почти в час. Чтение поста занимает куда меньше времени. В форме видеозаписи (1280×720) речь занимает два гигабайта. Пост же занимает всего лишь 12 МиБ. Рекомендуется просмотр на широких мониторах.



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

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

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

Но прежде чем перейти к делу, хотим уточнить:

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