Привет! В эту субботу PHP-чат Нижнего Новгорода проведет свой четвертый офлайн-митап с интерактивной трансляцией. Доклады подготовят Валентин Удальцов из Москвы и Денис Юрьев из Новосибирска. Записаться на митап можно здесь, поставить колокольчик под трансляцией — здесь. Те, кто будут смотреть онлайн, смогут задать вопросы текстом или голосом прямо из браузера.
А под катом небольшое интервью с докладчиками про то, что не вошло в их выступления.
Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые — от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости — те же type juggling, insecure deserialization и local file include.
Чтобы повысить уровень безопасности кода, полезно думать как хакер и тестировщик одновременно, проверяя все возможные лазейки в коде. Сканеры уязвимостей, SSL-сертификаты, аудиты и прочие многочисленные инструменты защиты будут хорошим дополнением. О том, как всё это совместить, Антон Прохоров рассказал в нашем интервью. На конференции PHP Russia 2021 Антон представит в докладе уязвимости PHP-приложений и способы их эксплуатации.
Всем привет, друзья. Меня зовут Alex, я профессиональный разработчик и создатель программных продуктов в веб индустрии. Много лет изучаю языки, делюсь опытом с другими.
Сегодня хочу с вами поговорить про шаблон проектирования Стратегия (Strategy). Постараюсь донести до вас принципы и суть шаблона без воды, и покажу как его применять на практике.
В этой статье хочу рассказать о проблемах, с которыми столкнулся в процессе интеграции с API по HTTP протоколу, и поделиться опытом их решения.
При разработке фронтенд приложений (mobile/web), часто сталкиваешься с тем, что API на бэкенде еще не реализован. Приходится ждать разработчика на бэкенде, когда он предоставит нужные запросы, постоянно напоминая ему о себе. Не редкость и другая ситуация, когда нужные http запросы уже есть, но они реализованы очень плохо и криво.
Возможно, я бы и не писал эту статью. Но мне показался поразительным тот факт, что все приведенные ниже примеры плохой реализации API попались мне в одном-единственном проекте, одновременно!
В этом проекте я разрабатываю мобильное приложение на Flutter, используя пакет Retrofit, который помогает мне сократить время и код, который приходится писать самому, генерируя значительный код автоматически. Так же использую Insomnia, для первоначальной проверки запросов до реализации их в коде.
Итак, начнем.
Если вы один из тех людей, в кодовой базе которых есть разделение (как и у меня) на уровни приложения (прикладной) и домена, то у вас достаточно часто возникает вопрос: в каком уровне должна находиться эта служба: приложения или домена? Иногда это заставляет задуматься, а не является ли различие между этими слоями все-таки чем-то чересчур необстоятельным. Я не собираюсь в очередной раз писать о том, что подразумевают под собой эти уровни, я расскажу вам как решаю, какому уровню принадлежит служба - приложения или домена:
Эта история берет начало у истока 2019 года, когда я заметил, что мое бесполезное пребывание в интернете, социальных сетях и смартфоне стало критичным и я решил вовлечь себя в собственный эксперимент цифровой детоксикации. К слову сказать данный опыт продолжался ориентировочно пол года и он очень сильно повлиял на мои современные взгляды.
В тот момент я искал кнопочный телефон, чтобы заменить им смартфон, который отнимал уйму времени. Так ко мне попал matrix-фон Nokia 8110 с KaiOS на борту и именно с этого момента когда я клал трубку после очередного разговора, приятели шутили, что мне опять звонил тот самый бог сновидений Морфеус.
Всем доброго времени суток! Продолжаю свой рассказ о том, как "Войти в IT" без подгляда. Прошлая часть была посвящена, в основном, обучению. В этой больше расскажу о работе.
Важная информация для всех, кто стремится попасть на стажировку. Набор «антисоветов», которые можно «перевернуть» и применить на практике, чтобы повысить свои шансы на попадание в ту или иную компанию.
Всем привет. Меня зовут Сергей, я работаю в digital-агентстве Convergent лидером команды бэкэнд разработки. Одно из основных направлений работы агентства ⸺ это разработка под заказ веб-приложений. Такая деятельность подразумевает, что зачастую создается достаточно много однотипных проектов. Они могут отличаться механиками, но основные юзкейсы повторяются: регистрация, авторизация, личный кабинет, админка и т. д. В данной статье я хочу рассказать о том, как мы оптимизировали процессы переиспользования кода и пришли в итоге к модульному подходу, ну и затрону еще немного технической стороны вопроса. Основной язык программирования в компании — PHP, так что дальше я расскажу о работе с этим языком. В нашем случае он отлично подходит для создания сайтов различного уровня сложности, различных активаций и промо-кампаний.
Недавно в команде произошел случай, который заставил обратить наше внимание на статью 2013 года. Материал не потерял актуальности, а перевода я не нашел, поэтому решил заполнить пробел. Но сначала немного предыстории.
Комьюнити-менеджеры обратили внимание на редко всплывающий баг в приложении: если пользователь закрепит контент вверху своего профиля, а затем модератор этот контент по каким-то причинам забанит, то у пользователя нет возможности ничего с этим закреплённым и забаненным контентом сделать: открепить его нельзя и другими способами от него избавиться тоже не получится. Типичный краевой случай, который редко встречается в реальной жизни. Я хоть и менеджер, но решил не отвлекать никого из команды на эту мелочь, а пофиксить баг самостоятельно, заодно стряхнуть немного пыль с навыков разработки.
Буквально через два уровня абстракций я оказался в коде, датированном 2016-2017 годами, то есть занялся software archeology. В какой-то момент меня возмутило, что вместо интерфейса репозитория в конструктор класса сервиса была передана реализация. Ещё одним уровнем абстракции ниже оказалось, что это всё-таки был интерфейс, но назывался он просто ContentRepository, а не ContentRepositoryInterface, как написал бы любой адепт ООП и принципов SOLID. Это уже не лезло ни в какие ворота, и я потребовал у архитектора оснований (кстати, рекомендую его статью о том, как мы вдвое ускорили построение лент подписок). Он в свою очередь невозмутимо показал пункт внутренних правил оформления кода, где была проставлена ссылка на статью 2013 года («А» — археология, как и было сказано).
Под катом — перевод этого материала.
Свежая подборка со ссылками на новости и материалы. В выпуске: все про файберы и асинхронный PHP, а также новые лямбды, пересечения типов и другие предложения для PHP 8.1. Ближайшие мероприятия, порция полезных инструментов, статьи, подкасты, видео и PHP Дайджест Стрим.
Приятного чтения!
Перед началом разработки модуля клиент сообщил, что в админке на странице редактирования заказа у него часто/рандомно не работает изменение заказа: У вас нет разрешения на доступ к API!
Изначально я не придал этому значения, так как проблема у клиента была до меня, а сроки по разработке были крайне сжатые (как обычно), а значит ее решение это второстепенная задача, однако на этапе внедрения модуля в интернет-магазин клиента начались проблемы.
Подборка свежих уроков, видео и пакетов по фреймворку Laravel.
В прошлом году я случайно наткнулась на сайт #ЦифровойПрорыв и шутки ради отправила ссылку тимлиду нашей команды: смотри, поучаствуем? Мы как раз успевали на последний региональный Северо-Западный хаб.
Из положения о конкурсе:
Хакатон — ограниченное во времени соревновательное мероприятие для IT-специалистов и специалистов сферы цифровой экономики, в рамках которого участники в составе команд от 3 до 5 человек (программисты, дизайнеры, менеджеры, аналитики) создают прототипы цифровых решений. Сами кейсы ставятся организациями–партнерами хакатона.
Всего в рамках Конкурса планировалось проведение 8 окружных онлайн–хакатонов, которые завершились Финалом.
Принцип Парето
Я не верила, что мы ввяжемся в эту авантюру до последнего — синдром самозванца всегда был моим спутником.
Команду собрали из коллег: тимлид/архитектор/питчер — Илья Шумилов, 2 фуллстек — Дмитрий Николаев и Кирилл Петров, аналитик/тестировщик — Марина Никулина. Так появилась команда IT animals.
Самое смешное, что, предлагая поучаствовать, я не дочитала до пункта про призы, и свято верила, что идем к победе ради ачивки и толстовок.
