• Простой проект Symfony плюс DDD?

    @dzubchik
    Недавно столкнулся из похожей проблемой, сейчас пробуем применять практики DDD в проекте на symfony. Советую посмотреть на репозитории:

    https://github.com/codeliner/php-ddd-cargo-sample
    https://github.com/dddinphp/blog-cqrs
    https://github.com/TheBigBrainsCompany/symfony-cqr...

    А также почитать статьи и книги:
    Ответ написан
    Комментировать
  • Знания Junior php разработчика?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    что должен знать идеальный джуниор (мое личное мнение):

    - Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
    - GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
    - Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
    - PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
    - Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
    - Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
    - Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
    - Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
    - Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
    - Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
    - Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
    - Уметь дебажить. xdebug, blackfire и тд.

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

    p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

    Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.
    Ответ написан
    12 комментариев
  • Как быстро создавать типовые сайты на Laravel?

    @mamayama
    Смысла лишено.
    Создавать быстро типовые - это к CMS. А выбранная вами технология - это фреймворк. Что предполагает затачивание под конкретную задачу.
    Это не быстрый путь априори.
    Ответ написан
    Комментировать
  • Как вы начинаете вёрстку сайта?

    torrie
    @torrie
    Всё знаю, всё умею
    В первую очередь делаю сброс css-стилей.
    Затем делаю вёрстку общих блоков - просто структура из div'ов с нужными ширинами, высотами согласно макету, залитых разными цветами. Стараюсь все div'ы(когда что-то в строчку) делать inline-block'ами. Получается цветная такая структура будущего сайта. Каркас готов.
    NDrl9VkCyDvemP.jpg

    Начинаю углубляться в каждый блок - располагать в нём нужные элементы. В зависимости от сложности их расположения делаю какие-то блоки position:relative, но чаще всего всё упирается просто в отступы.
    Ответ написан
    3 комментария
  • Как найти бэкдор на взломанном сайте и отследить источник

    KEKSOV
    @KEKSOV
    Буквально вчера занимался подобной проблемой на сайте знакомых с Joomla.

    1. Зайдите по ssh и сделайте архив всего сайта, скачайте его к себе на машину.
    2. Натравите на архив Касперского или Sophos (опыт показал, что они отлично выявляют зловреды, хотя и не все)
    Все обнаруженные уязвимости вычистите прямо на сайте через vi. Если обнаружится, что eval запихали в EXIF картинок, то их просто надо пересохранить и залить обратно на сайт.

    Пока антивирус делает свое дело, займитесь следующим:
    1. Проверьте .htaccess на наличие левых редиректов. В моем случае все пользователи отправлялись на страницу phpinfo.php c какой-то порнухой.
    2. Поищите код, который не найдут антивирусы:
    2.1 В некоторых файлах встроена конструкция, позволяющая сохранить файл в произвольное место на сайте. В моем случае это находилось при помощи команды
    find. -type file | grep php | xargs grep -l "<?php if (@"

    2.2 Поищите и проанализируйте файлы, которые обращаются к exif
    find. -type file | grep php | xargs grep -l exif_read_data

    2.3 Найдите картинки с троянами
    find. -type file | grep jpg | xargs grep -l eval

    2.4 Поищите preg_replace, который потом выполняет код
    find. -type file | grep php | xargs grep -l preg_replace.*\/e

    3. Анитивирусы наверняка найдут какие-то файлы. Загляните в них на хостинге, как правило там идет закодированная хрень и проверка каких-нибудь паролей. Вот эти самые проверки могут дать дополнительные ключи для поиска. В моем случае я нашел еще ряд файлов при помощи команд
    find. -type file | grep php | xargs grep -l 2970d43d7bf4115cdc60e2453bf48b52
    find. -type file | grep php | xargs grep -l security_code

    4. Внимательно проанализируйте файлы, которые находятся рядом с файлами бекдоров, скорее всего именно в них и находится уязвимость.
    5. Слейте дамп базы и поищите в нем eval, preg_replace и прочие прелести
    6. После зачистки всей дряни снова сделайте бекапный архив сайта

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

    На сервере, где хостятся мои знакомые есть только cvs, им и воспользуемся. Аналогичные действия можно сделать и при помощи git или svn.

    1. Вышли в домашнюю директорию
    cd

    2. Создали пустую директорию для нашего репозитория
    mkdir cvsroot

    3. Заинитили репозиторий
    cvs -d ~/cvsroot init

    4. Перешли в директорию, где находится корень сайт. Пусть у вас есть такая структура /home/myusername/mysite/htdocs. Тогда
    cd ~/mysite/htdocs

    5. Делаем первичный импорт в репозиторий
    cvs -d ~/cvsroot import htdocs initial_import initial

    6. Сейчас будем удалять старый сайт и забирать его из репозитория
    cd ~/mysite
    mv htdocs htdocs.bak
    cvs -d ~/cvsroot checkout www

    7. Добавляем в .htaccess правило, защищающее служебные файлы
    RedirectMatch 404 /CVS(/|$)

    8. Что это нам дает? Возможно быстрой проверки измененных файлов
    cd ~/mysite/htdocs
    cvs -qn update

    Если все было сделано правильно, то ответ будет
    M .htaccess

    9. Записываем наши изменения в репозиторий
    cvs -q commit -m update

    Далее, включаем в cron команду cvs -q commit -m update, да хоть бы и раз в минуту (если сайт сильно посещаемый), включаем лог файлы и ловим изменения, которые происходят в системе. Определив время и изменившиеся файлы, по логам смотрим что, кто, куда и как делал.
    Ответ написан
    1 комментарий
  • Загрузка изображений и отображение без перезагрузки страницы?

    Стандартное решение:
    — Создаём форму отправки и скрытый iframe.

    <form enctype=multipart/form-data action=index.php method=post name=loadavatar target=hiddenframe> <input type=hidden name=MAX_FILE_SIZE value=64000> <input id=avatarfile name=avatarfile type=file> </form> <iframe id=hiddenframe name=hiddenframe style="width:0px; height:0px; border:0px"></iframe>

    Форма отправки может быть стилизована, как Вам угодно (своя кнопка отправки или выбора файла). На форме нужно обязательно расположить input [type=file] (выбор картинки) и input [name=MAX_FILE_SIZE](ограничитель размера файла). У формы target должен ссылаться на скрытый iframe (в примере hiddenframe). При отправке файла target выполнит перезагрузку (поэтому если не использовать скрытый iframe, то у нас перезагрузиться родительская страница).

    Далее всё предельно просто — либо по нажатию кнопки submit, либо по вызову document.forms["loadavatar"].submit() отправляем форму; скрытый iframe перезагружается и файл оказывается на сервере. После чего его можно запросом получить с сервера (или сразу вернуть в скрытый iframe) и отобразить.
    Ответ написан
    9 комментариев