Это копия, сохраненная 15 ноября в 01:42.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Предыдущий тред был тут: https://2ch.hk/pr/res/3128808.html (М)
Старые треды тут https://2ch.hk/pr/arch/ (М) (искать по слову php), а также на архиваче и в гугле по словам по словам "клуб изучающих PHP".
С чего начать - основы PHP
Наши уроки по PHP собраны по адресу http://codedokode.github.io/phpbook . Это учебник для изучающих с нуля. Там есть задачи, их нужно решать. Но если этот учебник тебе не нравится, можно читать любой другой. Или официальный справочник ( https://www.php.net/manual/ru/langref.php ). Или все сразу.
Если что-то непонятно, запости код и попроси подсказку или поищи задачу в архиве тредов.
Какой редактор использовать
Простые задачки можно решать в онлайн-песочницах вроде https://onlinephp.io/ , https://paiza.io/en/projects/new?language=php , https://www.programiz.com/php/online-compiler/ , но для программ посложнее лучше установить редактор. Есть (дорогая) IDE PhpStorm, есть бесплатный Netbeans и VSCode, условно-бесплатный Sublime Text. Чтобы в последних получить автодополнение для PHP, нужно установить и настроить PHP language server.
Вот инструкции по установке PHP на компьютер: https://github.com/codedokode/pasta/blob/master/soft/php-install.md
Гайд по командной строке: https://github.com/codedokode/pasta/blob/master/soft/cli.md
Что изучать дальше
Зная лишь основы PHP, сайт ты не сделаешь и работу не найдешь. Обычно от начинающего требуют чуть-чуть больше:
PHP, ООП, основы HTTP, HTML/CSS (основы верстки), JS, SQL, PDO, MVC, git, composer, какой-нибудь фреймворк (Laravel или Symfony), основы автоматического тестирования, основы linux, английский.
Вот неофициальный роадмап (карта того, что можно изучать): https://miro.com/app/board/o9J_lbUUBBQ=/
По многим из этих тем у нас есть уроки или задачки:
- для понимания, что такое веб-сервер, прочти урок https://github.com/codedokode/pasta/blob/master/soft/web-server.md
- для понимая MVC, работы с БД и формами, реши задачу про студентов, в ней много полезных советов: https://github.com/codedokode/pasta/blob/master/student-list.md
- далее есть более сложная задача сделать файлообменник на микрофреймворке Slim: https://gist.github.com/codedokode/9424217
- задача, близкая по сложности к реальным задачам на Laravel/Symfony: https://gist.github.com/codedokode/8733007
- после нее можно изучать автоматизированное тестирование https://gist.github.com/codedokode/a455bde7d0748c0a351a
- если ты все решил, переходи к Symfony или Laravel
- почитать про паттерны можно тут https://designpatternsphp.readthedocs.io/ru/latest/ (если ты не изучил ни одного фреймворка, то это будет рановато). Если хочешь увидеть примеры использования паттернов в реальном коде - ковыряй исходники Симфони, например Symfony Forms. Ну и скажем честно, начинающему без опыта, который не видел сложный код, паттерны понять будет сложно.
- для улучшения английского можно читать news.ycombinator.com - там много статей на тему IT.
Также, у нас есть задачи которые позволят тебе изучить или подтянуть до нормального уровня знания JS/HTML/CSS/SQL. Решай их параллельно с задачами выше.
- задачи на HTML/CSS: https://github.com/codedokode/pasta/blob/master/html/html.md
- хороший учебник по JS: https://learn.javascript.ru/
- задачи на JS: https://gist.github.com/codedokode/ce30e7a036f18f416ae0
- задача на SPA (сложно): https://github.com/codedokode/pasta/blob/master/js/spa.md
- проверялка решений на JS: http://dkab.github.io/jasmine-tests/
- задачки на SQL: https://www.sql-ex.ru/ (нужна регистрация), https://sql-academy.org/ru/trainer и немного наших задачек: https://github.com/codedokode/pasta/blob/master/db/databases.md
Что еще почитать
- Мануал по PHP — http://www.php.net/manual/ru/langref.php
- https://phptherightway.com/
- Книга: Профессиональное программирование на PHP Джордж Шлосснейгл
- Книга: Мэтт Зандстра — PHP: Объекты, шаблоны, методики программирования
- Про Git: https://git-scm.com/book/ru/v2
- Задачи на алгоритмы: https://codeforces.com/problemset
Дополнительно
- скачать учебник: зайди на https://github.com/codedokode/phpbook, нажми зеленую кнопку Code -> Download ZIP, распакуй на рабочий стол и открой index.html
- что будут спрашивать на собеседовании, если 0 опыта - будут гонять по теории, по официальному мануалу PHP, давать дурацкие задачки на переворачивание строк, гонять по SQL (транзакции, внешние ключи, напиши запрос), по JS (как сделать анимацию при нажатии кнопки), ну погугли, не ленись
- сколько времени надо изучать все это? - все зависит от тебя, в районе 24-48 месяцев
Я уверен, что не больше 5.
Ну хз, скачиваю его, убираю только для чтения, запускаю script.sh и ничего, хотя в консоли пишет что сделано
Ты реально думаешь что такому тупорогому ламеру, не осилившему по простейшей инструкции крякнуть свой рабочий инструмент, че-то светит в программировании?
Ни🌶 не понимаю как мне самому написать эти файлы.
Тупо копипастить не хочу, хочу разобраться.
Гайды, которые прошерстил, описывают слишком простые случаи.
Зато при бабле и не ебёт.
Не знаю, ты не описывал свой случай.
>1. add -javaagent:/path/to/ja-netfilter.jar=jetbrains to your vmoptions (manual or auto)
Что это? Как это сделать?
Никак. Это интеллектуальный ценз на становление пхп макакой. Если ты даже такую мелочь осилить не в состоянии, то тебе прямая дорога в пятерочку, лук раскладывать.
Ну все, ты теперь программист. Привыкай сначала думать, а потом пиздеть.
Как выйдет пятая умножайте ещё на 2. Нейронки же экспоненциально растут! 15 лет учёбы - вот это я понимаю порог вхождения.
Расскажи что ты делаешь и что у тебя не получается. Так же проверь версии и сделай чистую установку всех задействованных компонентов
Требования к джунам выросли, а соответственно время для изучения вещей, которые раньше спрашивали у мидла
Делаю по инструкции - прописал путь к ja-netfilter.jar в Help->edit custom vm options
Затем копирую ключ, пишет инвалид
--add-opens=java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED
--add-opens=java.base/jdk.internal.org.objectweb.asm.tree=ALL-UNNAMED
Прописать
Конечно все, написать одну строчку в настройках docker с публичным зеркалом ты не можешь же, да?
Вакансия бэк джун.
Функциональные требования:
На сайте должно быть две страницы: одна со списком книг, другая со списком авторов.
Модель книги должна иметь следующий вид:
Название
Список авторов
Описание
Год публикации
Модель автора должна иметь следующий вид:
ФИО
Список книг, написанных этим автором
Количество книг, написанных этим автором*
Возможности библиотеки:
Добавление книги на странице списка книг
Редактирование книги на странице списка книг (inline-редактирование или во всплывающем окне)
Удаление книги
Получение полной информации по определенной книге
Получения полной информации по определенному автору
В целях упрощения принять, что ФИО для каждого автора уникально. Двух авторов с одинаковым ФИО быть не может.
В списке книг отображать только название, год и первого автора книги.
В списке книг должна быть возможность получить полную информацию по каждой книге во всплывающем окне.
У книги в поле списка авторов выводить только ID и ФИО каждого автора книги.
У автора в поле списка книг выводить только ID, название и год публикации каждой книги.
Вакансия бэк джун.
Функциональные требования:
На сайте должно быть две страницы: одна со списком книг, другая со списком авторов.
Модель книги должна иметь следующий вид:
Название
Список авторов
Описание
Год публикации
Модель автора должна иметь следующий вид:
ФИО
Список книг, написанных этим автором
Количество книг, написанных этим автором*
Возможности библиотеки:
Добавление книги на странице списка книг
Редактирование книги на странице списка книг (inline-редактирование или во всплывающем окне)
Удаление книги
Получение полной информации по определенной книге
Получения полной информации по определенному автору
В целях упрощения принять, что ФИО для каждого автора уникально. Двух авторов с одинаковым ФИО быть не может.
В списке книг отображать только название, год и первого автора книги.
В списке книг должна быть возможность получить полную информацию по каждой книге во всплывающем окне.
У книги в поле списка авторов выводить только ID и ФИО каждого автора книги.
У автора в поле списка книг выводить только ID, название и год публикации каждой книги.
Безыдейная 🌶ня, которая генерится двумя командами на ларавеле или симфони. А раз это дерьмо может любая жпт обезьяна высрать, то будут доебываться до каких-нибудь мелочей: тут не сделал, то забыл.
без фреймворков?
натив пхп + жиес(мож жуквери) - часа за 4, так то норм для джуна. я бы дольше например с модалками колупался.
Symfony/Yii2.
+ сделать авторизацию на действия удалить/добавить/изменить книгу.
+ использовать Docker
+ выложить на хостинг.
А отсосать не надо? Оно конечно выглядело как задание для полного имбецила, но зачем превращать его в задание для имбецила, который не ценит свое время?
Ни джун не ценит своего времени, ни работодатель не ценит времени джуна.
Докер это что-то вроде виртуальной машины (если совсем упрощать). Он позволяет создать контейнер, который изолирован от хост-машины, устанавливать и запускать произвольный софт внутри этого контейнера.
Докер изначально создает тебе пустой контейнер, в него ты берешь и загружаешь "базовый образ", то есть ОС с минимальным набором пакетов, в которой почти ничего не установлено (например: Alpine Linux, Debian, и тд). Затем ты пишешь команды, которые выполняются в этом контейнере и устанавливают там нужные тебе программы. Докерфайл как раз и состоит из таких команд. А docker compose позволяет организовать одноременный запуск нескольких разных контейнеров (например: в одном контейнере nginx, в другом php, в третьем база данных). Обычно при использовании Докера каждый компонент устанавливают в отдельный контейнер.
Соответственно, прежде чем пользоваться Докером, тебе надо изучить командную строку линукса: команды работы с файлами (ls, rm, cat, echo), процессами (ps, kill), базовые команды обработки текста вроде grep, head, sort. Файловые системы, права на файлы, монтирование образов.
Далее тебе надо научиться использовать пакетный менеджер для установки программ. В разных дистрибутивах Линукса они разные: в Дебиане это apt, в Редхат это rpm, в Alpine это apk.
Наконец, часто софт требуется ставить не из пакетов, а собирать вручную. Чтобы научиться это делать, надо прочитать про компиляцию и сборку программ на Си: как использовать компилятор, make, autoconf, configure-скрипты.
То есть, тебе надо стать немного сисадмином для начала. После этого тебе останется лишь прочитать документацию по Докеру и все будет понятно.
Так что начни с установки Линукса с командной сторокой в виртуалку и его освоения. Как ты понимаешь, в коротком гайде ты это не прочтешь.
Красивых дизайнов без усилий не будет. Если хочется сэкономить именно усилия, то бери bootstrap. Он некрасивый и тяжелый.
Задачу про студентов из ОП-поста напоминает. Если вы ее решили, то и это задание сделаете без проблем.
Охуенная помощь - википедию скопипастить. Можешь еще ответы жпт-говна сюда постить. Помощник, ебать.
Если имбецил не в состоянии загуглить как поднять пхп с вебсервером и базой, то ему дорога даже не в макдак, а в пнд - глицин пить.
Хочу укатиться в другой лангуаге. Выбор между нодой и goвном. Говно я не знаю, немного посмотрел, почитал, суть мне понравилась, но это же голая хуйня без ничего, причём, как я понял отсутствие готовых решений преподносится как фича. Хуй знает в общем.
Второй вариант - Нода и нестжс. Нест я знаю, писал на нём несколько проектов. Но блядь, окей, нода это костыль на костыле, вместе со всеми этими тайпскриптами, банами, ярнами и нвмами, похуй. Но там же нет интерфейсов блядь. В том же несте, внедрение зависимостей происходит через токен в виде строки - это же 🍑ц, какой смысол от депенденси инжекшн в таком случае? Там тестирование тоже через костыли как и всё в ноде?
Так и что выбрать? На чем остановиться? В пыхе оставаться не хочу, потому что я не пузатый лысеющий алкаш с немытой головой, а даже шапка треда буквально кричит о том, что её составлял такой чухан с грязью под ногтями
Спасибо...?
>Так что начни с установки Линукса с командной сторокой в виртуалку и его освоения
Чем docker на linux лучше, чем docker на windows (для среднестатического пользователя, пусть даже для php веб-программиста, который не будет активно заниматься деплоем; этим же ведь не заставляют заниматься на работе?)?
<input type="text" name="user[]"
<input type="text" name="user[]"
И на сервер придет массив user с ключами от 0 до ...?
Внутри квадратных скобок можно указать названия ключей и придет ассоциативный массив.
4 года назад докер на виндов был очень тормознутым и пришлось очень долго искать инфу, как заставить его работать шустрее. Не знаю как сейчас.
Также
Жалею, что вкатился в пыху
Легко ли спустить пол зарплаты на кабак, нажраться в хлам, разбить по набуху тачку с лишением и потерять передние зубы выхватив в ебасос от соседа за шум в два ночи?
Вроде суеты дохуя, а надо-то делов: расслабить булки и выключить башку.
Очень легко.
Сложно, тошнить от пэхи будет
Неешь, подумой
какой ларавель, здесь битрикс разработчики сидят
Я не написал тебе устанавливать Докер. Я посоветовал изучить Линукс для начала, без Докера. А когда изучишь, можешь переходить к Докеру.
Докер на линуксе лучше тем, что не использует виртуализацию, и по идее, там будет лучше производительность. Хотя, для разработки, если у тебя не какой-то древний компьютер, разницы скорее всего не будет.
Тем временем рынок - https://career.habr.com/vacancies/1000140914
О, приветствую в русскоязычном интернете. Такой вопрос: у вас же света нет. Как вы там погромируете? В подвалах? В метро?
Кстати. Есть гугл и Яндекс переводчик, если не знаешь нашего языка можешь перевести и написать и тогда нам будет понятно
Апи сервис который будет связывать что-то с чем-то, завернутый в докер.
1) клиент заходит на твой сайт по условиям для рыбалки
host1:8000/home
2) с него отправляет запрос получить на какой-то день/неделю пригодность рыбалки.
host2:8000/api/get-today-info
3) host2 это твой сервис, получаешь местоположение чела и запрашиваешь прогноз погоды по нему в чужой апи
weather-api/запрос_из_документации
4) получаешь обратно в host2 ответ и обрабатываешь его, высчитываешь благоприятность рыбалки по любым своим критериям. После чего ретурнишь результат обратно на host1:8000
Итого:
host1:8000/home сайт с кнопкой получить инфу посылающая запрос на сервис
host2:8000/api/get-today-info получаешь местоположение и обращаешься к
weather-api/метод возвращает тебе погодные условия в
host2:8000/api/get-today-info получив их делаешь вычисления результат, которых возвращается в
host1:8000/home выводишь результат
Просто в начале мало представлений что такое апи, поэтому попытался разъяснить. На самом деле это вообще всё просто. Апи это просто методы на которые посылаются запросы, скажем так. Дедов впечатлишь как новичок и особенно если в докер завернёшь и сайт и сервис
Я хочу создать 3 контроллера:
Первый принимает общие для приложения запросы: показать главную страницу, например.
Второй и третий для конкретных сущностей: добавить, удалить, изменить.
Сделай 1 контроллер на 1 сущность, так правильнее
Контроллерами мыслят только имбецилы. Проектировать нужно экшенами или хэндлерами. На каждый url должен быть свой обработчик. А где этот обработчик хранится, в контроллере или в отдельном файле - всем поебать.
Где я грубил? Я посоветовал иностранцу как лучше поступить, чтобы быть нами понятым и соответственно получить ответ на свой вопрос
Сейчас есть WSL 2, который в целом медленнее родного линукса, но не намного, а в некоторых тестах и быстрее.
Поэтому можно смело хуярить докер под виндой, тем более, если это не продакшен, а для разработки.
Даже если совсем упрощать, контейнер - не виртуалка и нихуя не изолирует.
>>176281
Открой ман и пиши. Если непонятно - сначала смотри ман, потом смотри чужие примеры. dockerfile описывает окружение для хоста в котором можно было бы запустить твоё приложение, compose описывает куда этот хост воткнуть и что должно быть запущено в той же сети
>>180911
Ничем, но чтобы понять как работают контейнеры, лучше иметь возможность следить за происходящим прямо из линукса в котором они запускаются. Особенно если дело касается сети - в win и darwin хостовая сеть с контейнерной очень жопно итегрируется.
- упрощенный клон Ютуба
- клон Пинтереста
- блог-платформа вроде Хабра
- файлообмениик (ну это конечно совсем просто)
Ну то есть, проще всего сделать клон чего-то.
А кто из разработчиков вскода получает бабки чтобы в их иде заебись писалось на пхп?
>шторм охуенчик, а вскод - залупа
Поподробнее. Мне интересно что меня ждёт в будущем если я не пересяду.
Так ты попробуй и узнаешь.
Мб сейчас тебе кажется, что все ок, что тебе удобно.
Но шторм дает такой уровень удобства, что вероятность, что ты на него пересядешь 99%.
Открой предыдущие треды и прочитай. Пиздец вкатун ленивый пошел.
Это как фиксить? Чё-то пытался гуглить, даже примерно по подобному запросу никто не спрашивает.
Может ли это быть как-то связанно с тем что у меня линукс и нет каких-то библиотек нужных(Каких?). Или я где-то жестко натупил?
Сходи в питон или го тред, там подскажут
Тебе смешно, а миллионы программистов плачут по ночам из-за этого.
Ну, я по большей части спрашиваю про проекты которые в шапке предлагают делать и туторы по ним, типа этого https://github.com/codedokode/pasta/blob/master/student-list.md . Понятное дело(ладно, не понятное), что Жквери и прочее очевидно устаревшее говно учить я не буду.
Первый: "объекты инкапсулируют свое внутреннее состояние, а для работы с ним предоставляют вполне определенный внешний интерфейс".
Второй: принцип единственной ответственности.
class Collection {
public function has($key): bool;
public function get($key): mixed;
public function set($key, $value): void;
public function unset($key): void;
}
Класс инкапсулирует свое состояние и, не заглянув внутрь, мы не узнаем, хранит ли он значения в оперативной памяти, базе данных, облачном хранилище и т.д. Однако по интерфейсу класса мы ясно видим, что имеем дело с какой-то коллекцией элементов.
У этого класса ровно одна ответственность (или причина для изменения), если внутри он описывает только логику, которая организует запись и чтение.
Если кроме этого класс Collection, например, описывает низкоуровневую логику sql-запросов, то у класса уже две ответственности (или причины для изменения). Логику работы с базой данных стоило бы вынести в отдельный класс.
Т.е. можно сделать либо так - сущности с полями и сервисы для обработки данных этих сущностей, либо так - объекты инкапсулируют и данные и методы работы с этими данными?
Знакомлюсь с DDD и соответствующими понятиями и пытаюсь понять как анемичная и богатая модели вклиниваются в проектирование.
Почему бы не использовать и сервисы и методы модели одновременно?
Например метод в сервисе использовать функцию модели, которая отвечает за изменение статуса модели и регистрирует кто и когда это сделал.
function activate(Model $model, int $userId, DateTimeImmutable $dateTime)
{
$model->setActive($userId, $dateTime);
$this->repository->save($model);
}
>Логику работы с базой данных стоило бы вынести в отдельный класс.
Ошибка. На самом деле ты выносишь не "логику", а РЕАЛИЗАЦИЮ работы с базой. Тебе все еще нужно вызвать методы лезущие в объект, который будет лезть в базу. Вызвать в нужном порядке, передав в них нужные данные, чтобы получить нужный результат - это и есть ЛОГИКА. И она осталась в коллекции.
У меня было пару задач на собесах.
1) Написать реализацию стека на пхп. По сути класс и два метода.
2) Данн массив с целыми числами, найти только числа, которые повторились как минимум 1 раз
>Знакомлюсь с DDD
В DDD нет никакой анемичной модели. Ты изучаешь не DDD, а какую-то хуйню от хуй пойми кого по мотивам. Здесь уже можно было бы закончить. Но я объясню для тупых что такое "анемичная модель".
Есть такая штука как ФУНКЦИОНАЛЬНОЕ ПРОГРАММИРОВАНИЕ.
Там, внезапно, нет объектов, а есть только функции и структуры данных. У этих структур никаких встроенных методов нет и их передают в функции чтобы с ними что-то сделать. Ничего не напоминает?
Почему в функциональном программировании это работает, а в ооп (и конкретно в пхп) нет?
Да потому что структуры данных в фп ИММУТАБЕЛЬНЫЕ. То есть функция drochitHui(Hui $hui): Hui в фп вернет тот же самый Hui, который получила. Если нужно что-то мутировать то нужно создать НОВУЮ СТРУКТУРУ. drochitHui(Hui $hui): DrocheniiHui В фп это норма жизни - на каждое изменение создавать новый тип. И есть все условия чтобы это делать быстро. В F#, например, это делается одной строчкой: type DrocheniiHui = DrocheniiHui of Hui. И все, одна строчка и у тебя новый подтип, с которым можно работать.
А что в ооп и в пхп?
Функция превращается в целый класс-сервис. Но несмотря на кучу бойлерплейта внутри остается то же самое: drochitHui(Hui $hui): Hui . А что поменялось? То что Hui теперь мутабельный и на самом деле это и Hui и DrocheniiHui в одном лице. Потому что никто не станет писать по классу на каждое изменение. Или как-то наследоваться, чтобы не запутаться окончательно. Это банально неудобно, язык для этого не приспособлен. И что из этого следует? А то что мы не знаем что на самом деле сделал с нашим хуем сервис. Мы больше не контролируем состояние. Если у нас дальше сервис, в который нужно передать только подроченный хуй, то что нам делать? Придется передавать таинственный Hui, а потом делать проверки. Писать кучу проверок в коде, кучу тестов с проверками.
А как это ДОЛЖНО быть сделано в ооп?
Hui должен быть закрытой стейт машиной, по всем заветам ооп. Чтобы никто не мог привести его в неверное состояние. Очевидно что для этого нужно много чего перенести обратно в хуй и никакой функциональной анемичной модели у нас уже не будет.
>Знакомлюсь с DDD
В DDD нет никакой анемичной модели. Ты изучаешь не DDD, а какую-то хуйню от хуй пойми кого по мотивам. Здесь уже можно было бы закончить. Но я объясню для тупых что такое "анемичная модель".
Есть такая штука как ФУНКЦИОНАЛЬНОЕ ПРОГРАММИРОВАНИЕ.
Там, внезапно, нет объектов, а есть только функции и структуры данных. У этих структур никаких встроенных методов нет и их передают в функции чтобы с ними что-то сделать. Ничего не напоминает?
Почему в функциональном программировании это работает, а в ооп (и конкретно в пхп) нет?
Да потому что структуры данных в фп ИММУТАБЕЛЬНЫЕ. То есть функция drochitHui(Hui $hui): Hui в фп вернет тот же самый Hui, который получила. Если нужно что-то мутировать то нужно создать НОВУЮ СТРУКТУРУ. drochitHui(Hui $hui): DrocheniiHui В фп это норма жизни - на каждое изменение создавать новый тип. И есть все условия чтобы это делать быстро. В F#, например, это делается одной строчкой: type DrocheniiHui = DrocheniiHui of Hui. И все, одна строчка и у тебя новый подтип, с которым можно работать.
А что в ооп и в пхп?
Функция превращается в целый класс-сервис. Но несмотря на кучу бойлерплейта внутри остается то же самое: drochitHui(Hui $hui): Hui . А что поменялось? То что Hui теперь мутабельный и на самом деле это и Hui и DrocheniiHui в одном лице. Потому что никто не станет писать по классу на каждое изменение. Или как-то наследоваться, чтобы не запутаться окончательно. Это банально неудобно, язык для этого не приспособлен. И что из этого следует? А то что мы не знаем что на самом деле сделал с нашим хуем сервис. Мы больше не контролируем состояние. Если у нас дальше сервис, в который нужно передать только подроченный хуй, то что нам делать? Придется передавать таинственный Hui, а потом делать проверки. Писать кучу проверок в коде, кучу тестов с проверками.
А как это ДОЛЖНО быть сделано в ооп?
Hui должен быть закрытой стейт машиной, по всем заветам ооп. Чтобы никто не мог привести его в неверное состояние. Очевидно что для этого нужно много чего перенести обратно в хуй и никакой функциональной анемичной модели у нас уже не будет.
анемичная модель это по-моему уже процедурное программирование, а не объектно-ориентированное
Лучше делай по-проще, а тут запутаешься в крутых архитектурах и окружающих запутаешь
Спасибо за информацию.
Да. В итоге оказывается, что классы не нужны и достаточно иметь функции, а ООП это антипатерн.
Вобще вся эта затея, с субъективным пониманием того, что является ответственностью, изначально хуита. Потому что в итоге окажется, что твой банюзерсервис тоже подробить можно (например на чтение и запись), а идеальный класс это класс с одним методом-оберткой над одной нативной функцией языка
Идея в том, что каждый класс имеет какую-то свою зону ответственности, за которую он отвечает, и он не занимается тем, чем должен заниматься другой класс.
Если тебе нужна аналогия, то представь себе разные профессии: кассир пробивает чеки, товаровед решает, как разложить товары на полках, уборщик подметает пол, грузчик разгружает товары, и каждый человек занимается своим делом.
Автор этого принципа написал статью с объяснением (англ.), но она может быть сложной для начинающего: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Ты можешь делить UserService, если он большой и в нем становится слишком много функционала. Если он и так маленький, то деление дальше только ухудшит код.
Классы (точнее, объекты) нужны, не пиши глупости. Классы позволяют представлять различные сущности, например: Пользователь, Заказ, Товар, Платеж и так далее.
ООП еще как используется. Даже если ты возьмешь ядро Линукса, написанное на Си (языке без ООП), ты увидишь, что там имитируется ООП: есть конструкторы определенных структур, если функции для операций над ними, есть полиморфизм через структуры с функциями. Но только вместо имитации ООП было бы лучше использовать язык с поддержкой ООП.
Сама по себе идея "богатой" модели хороо соответсвует концепции ООП. Но богатую модель на практике сделать сложно из-за зависимостей. Допустим, ты хотел бы в определенной ситуации (смена телефона пользователя) отправлять письмо на почту. Но ты не можешь сделать это из модели Пользователя, так как в нем нет ссылки на сервис отправки писем.
Поэтому обычно в модели реализуют только те методы, которые не требуют зависимостей, а все остальное выносят в сервисы.
Также, "богатая" модель может привести к тому, что у тебя будет очень много кода в одном классе, и это будет нарушать принцип единой ответственности.
Ты пишешь какую-то ерунду. В не-функциональных языках (например: Питон) тебе никто не запрещает использовать иммутабельные типы данных. И создавать новые типы.
> В F#, например, это делается одной строчкой: type DrocheniiHui = DrocheniiHui of Hui. И все, одна строчка и у тебя новый подтип, с которым можно работать.
По моему, это бредовый подход. Если ты делаешь 10 преобразований объекта, ты сделаешь 10 типов? И 10 функций для работы с каждой версией объекта? Пользователь, поменявший имя. Пользователь, поменявший email. Пользователь, поменявший аватарку. Пользователь, не подтвердивший email. Пользователь, не подтвердивший телефон. Пользователь, подтвердивший email, но не подтвердивший телефон. Зачем мне это нужно.
Мне интересно, описанный тобой подход используется где-то на практике? Можно код на гитхабе увидеть с 10 вариантами пользователя?
Иммутабельные объекты имеют недостаток, что если у тебя в программе есть 5 ссылок на объект, то после изменения ты должен поменять содержимое в 5 местах. В то время как мутабельные объекты проблемы не имеют. Мне не нужно 5 старых версий объекта Пользователь, мне нужна актуальная версия.
Иммутабельные типы хорошо подходят для представления значений, например: Дата, математический вектор, матрица.
Ну если тебе какая-то технология кажется устаревшей, ты можешь решить задачу с помощью более новой. Сама-то задача остается актуальной.
Контейнер изолирован от хост-системы. Например, в контейнере может быть одна версия библиотеки libc, а в хост-системе другая. Для этого контейнер и нужен.
Блядь какой ты тупой старый дед блядь. По какому принципу ты вынес кассира в отдельную сущность, хуесос? Почему не сущность "персонал" со своими ролями? Аналогию он привёл блядь. Твой кассир, пробивающий чеки, чтобы пробить чек должен сделать кучу действий. Ты будешь эти действия дробить на отдельные классы? По какому принципу? А тебя именно об этом и спросили, ебанько, нахватавшееся пенки с говна
>Ты пишешь какую-то ерунду
>Пользователь, поменявший имя. Пользователь, поменявший email. Пользователь, поменявший аватарку.
Ну ты и кретин канеш. Зачем создавать новый тип если ничего не поменялось? А вот если у тебя есть действие, которое может выполнить только верифицированный пользователь, то у тебя два варианта.
Взять обычный email, запихнуть в него поле verified и дать ВСЕМ доступ на изменение этого поля. Потом взять обычного пользователя, запихнуть в него метод isVerified(): bool, который будет лезть в email и написать где-то хуй пойми где логику проверки уже пользователя.
Или сделать тип VerifiedUser, который может иметь только VerifiedEmail, а твой сервис будет принимать только VerifiedUser.
Только хули толку это обсуждать, если в пхп второй вариант физически невозможен? И нахуя ты приплел питон? И причем тут возможность иммутабельности, если и в пхп вполне можно иммутабельные объекты писать?
Тебе черным по белому написали в чем проблема: в ооп языках и пхп в частности неудобно писать функциональный код. А "анемичная модель" это функциональный код и есть. Поэтому у тебя получается полурак-полухуй, который из ооп взял только бойлерплейт, а из фп выкинул весь контроль состояния. На вопрос: а нахуя? Я могу только предположить что писать так придумали функциональщики, которые хотели писать как им привычно на ооп языке, а остальные тупо каргокультисты и ебланы.
Как раз от хост-системы контейнер не изолирован, у тебя все сисколы пойдут в то же ядро.
Отдельный mount namespace это не изоляция от хост-системы, это более мощная альтернатива chroot, и проёбы там схожие с chroot.
> Или сделать тип VerifiedUser, который может иметь только VerifiedEmail, а твой сервис будет принимать только VerifiedUser.
А если у меня отдельно верифицируется email, телефон и банковская карта? И может быть любое сочетание их?
И ты не написал, где на Гитхабе можно увидеть код, написанный с применением этого подхода.
>А если
Для этого существуют композитные типы. С алгебраической системой типов вообще много чего можно сделать. А пхп вон едва энумы добавили, так местные дебилы два треда понять не могли нахуй они нужны.
К чему эти вопросы дебильные? Тебе нужен мастер класс по функциональным языкам и типизации? Че дальше будешь высирать? Допрашивать как монадой option пользоваться? Открой ютьюб и посмотри каких-нибудь протыков.
>И ты не написал, где на Гитхабе можно увидеть код
В душе не ебу. У нас все репозитории приватные. Какой долбоеб будет тебе в паблик свой домен выкладывать? Разве что какие-нибудь учебные проекты или "примеры".
Я недавно нашел у себя в appdata папку yarn с ДВУМЯ ГИГАМИ КЕША БЛЯДЬ. А я даже не фронтендер и это вообще не рабочий кампуктер.
Оставил во вкладках эту статью от хуй пойми кого 2 месяца назад чтобы прочитать потом. Почитай и скажи че там тогда.
Статья "Непростой принцип единой ответственности"
https://habr.com/ru/articles/449586/
В Битриксе такой хуйни нету
Прочитал. Статья ни рыба, ни мясо.
Автор пишет "определить границы где одна ответственность, а где несколько - это трудная задача", а потом дает определение принципу единственной ответственности как "ответственность должна быть не слишком большой". По моему мнению, наступил в ту же лужу.
Ну, благодаря этой статье ты познал суть солида. Размытые определения, которые каждый долбоеб трактует как ему удобно.
https://youtu.be/GzRfvwo1iNU?si=cK_XvCw93hceMPIP
Вопрос: чем отличаются эти два варианта проектирования Слоя служб?
Даже скину текст из книги:
Другая крайность — в рамках слоя служб представить большую часть логики в виде сценариев транзакции. Нижележащие объекты домена в этом случае могут быть тривиаль-ными; если они сосредоточены в модели предметной области, удастся обеспечить их одно-значное отображение на элементы базы данных и воспользоваться более простым вари-антом слоя источника данных (скажем, активной записью (Active Record, 182)).
Между двумя указанными полюсами существует вариант, представляющий собой больше, нежели "смесь" двух подходов: речь идет о модели "контроллер-сущность" ("controller—entity") (ее название обязано своим происхождением одному общеупотреби-тельному приему, основанному на результатах из [22]). Главная особенность модели за-ключается в том, что логика, относящаяся к отдельным транзакциям или вариантам ис-пользования, располагается в соответствующих сценариях транзакции, которые в данном случае называют контроллерами (или службами). Они выполняют роль входных кон-троллеров в типовых решениях модель-представление-контроллер (Model View Controller, 347) и контроллер приложения (Application Controller, 397) (вы познакомитесь с ними поз-же) и поэтому называются также контроллерами вариантов использования (use case control-ler). Функции, характерные одновременно для нескольких вариантов использования, пе-редаются объектам-сущностям (entities) домена.
Пхп-тред как всегда: мертвый и неэффективный.
Зачем люди тут вообще собираются? Если вообще собираются.
Ну как зачем? Чтобы постить невнятную хуйню в кривом уебанском переводе. Мало того что эту поебень физически читать невозможно, так ты еще и вопрос такой же уебанский задаешь.
Какая хуй разница чем они отличаются? Ты код написал, чтобы тебе вообще было что структурировать? Что вообще такое "слой служб"? Как это в принципе выглядит в коде ты знаешь? О вариантах чего ты спрашиваешь блядь вообще?
>Какая хуй разница чем они отличаются?
Действительно. Читаешь книгу - не понимаешь что в ней написано - игнорируешь этот факт - выходишь после книги с той же пустой головой.
>Ты код написал, чтобы тебе вообще было что структурировать?
И да, и нет. Хочу сначала прочитать теорию, чтобы в дальнейшем писать правильнее.
>Что вообще такое "слой служб"?
Фаулер дает этому определение в том же месте книги, на которое я указал в предыдущем посте.
>Как это в принципе выглядит в коде ты знаешь?
Нет. Пока что читаю, надеюсь что к концу прочтения хоть какая-то целостная картина сложится.
>О вариантах чего ты спрашиваешь блядь вообще?
О вариантах реализации слоя служб, который представляет собой слой бизнес-логики. Там есть и третий вариант, но очевидно чем он отличаются, а эти два варианта очень похожи друг на друга.
>Действительно. Читаешь книгу - не понимаешь что в ней написано
Ты "читаешь" шизофазию. Текст пропустили через мясорубку и сломанный телефон и высрали. Бля, у тебя даже название книги неправильно переведено.
>И да, и нет. Хочу сначала прочитать теорию
Короче кода нет, а ты просто занимаешься хуйней.
>Фаулер дает
Фаулер мужик умный, базару нет. Ставлю анус что он вместо виляния сракой ответил бы на вопрос.
>Нет. Пока что читаю, надеюсь
Открыл книжку-набор из разрозненных паттернов, буквально свалку баззвордов. Надеется на целостную картину. Интересно на какой странице фаулер обещал какую-то целостность вообще? Это буквально перепись его блога, в который он хуярит всякое по случаю.
>О вариантах реализации слоя служб, который представляет собой слой бизнес-логики.
Так это слой служб или слой бизнес-логики? Или это слой курбан-байрам?
Короче как я и думал: ты потратил свое время на хуйню и теперь просто хочешь потратить на хуйню чужое. Какой нахуй пхп, какое нахуй программирование. Тут надо читать учиться. Учиться читать информацию по незнакомой теме. Учиться пользоваться справочной литературой. Учиться составлять глоссарий. Если не с букваря начинать, то где-то очень близко. Нас словарем пользоваться в первом классе учили.
>Короче как я и думал: ты потратил свое время на хуйню и теперь просто хочешь потратить на хуйню чужое. Какой нахуй пхп, какое нахуй программирование. Тут надо читать учиться. Учиться читать информацию по незнакомой теме. Учиться пользоваться справочной литературой. Учиться составлять глоссарий. Если не с букваря начинать, то где-то очень близко. Нас словарем пользоваться в первом классе учили.
Угомони свое эго, пердикс, я просто задал вопрос по книге.
Сложно обсуждать, если книгу не читал. Если хочешь обсудить можешь дальше развернуть его суждения и опровергнуть мои домыслы.
>Они выполняют роль входных кон-троллеров в типовых решениях модель-представление-контроллер (Model View Controller, 347) и контроллер приложения (Application Controller, 397)
Думаю тут речь идет о mvc, который идет в фреймфорках yii, laravel из каропки. Например, контроллер логина, главной страницы - контроеллеры приложения, CRUD контроллеры - контроллеры сущностей.
>Другая крайность — в рамках слоя служб представить большую часть логики в виде сценариев транзакции
Выглядит так, что он тут критикует слой сервисов, потому что люди туда все операции с моделю выводят.
>Между двумя указанными полюсами существует вариант, представляющий собой больше, нежели "смесь" двух подходов: речь идет о модели "контроллер-сущность" ("controller—entity")
И предлагает часть логики писать в контроллерах, а часть в модели ActiveRecord?
>чем отличаются эти два варианта проектирования Слоя служб?
Ну для меня класс службы это сборник методов для изменения состояний ActiveRecord, которые я могу использовать в разных контроллерах. Поэтому я пишу тесты на методы сервиса. С контроллерами нужно будет писать тесты на методы контроллера, ничего тут не меняется особо. Разве что Сервис не ответственнен может быть за сохранение данных в базу и получение данныз оттуда. Повторящийся код из контроллера можно будет выносить в ActiveRecord.
Ну короче, судя по этому одному абзацу я вижу разницу в местах хранения логики (кэп, знаю), и выткающем из этого тестировании.
-
>дайте внимания
>мертвый и неэффективный НУ ДАЙТЕ ВНИМАНИЯ
>Ты вообще о чем читаешь? Что эти термины означают? Зачем ты это читаешь?
>пук среньк ДАЙТЕ ВНИМАНИЯ
Какое вниманиеблядство может быть в треде, в котором постинг один раз в неделю?
Я даже удивлен, что ты вообще мне ответил.
Я сижу в треде по пхп уже почти год и мне как-то грустно, что тут обсуждение как на кладбище. Никто ни у кого не спрашивает, никто не дает совета, не обсуждают нововведения пхп.
>>196148
Мне кажется, что это плохая идея вести диалог об идеях какой-то книги, которую один из участников диалога не читал. Тут придется либо ознакомиться с главами книги, о которой идет речь, либо писать мне длинную пасту о том, что мог подразумевать Фаулер в своей книге, что также не очень, потому что это мое видение книги. Было бы хорошо, если бы каждый собеседник прочитал те главы, сформировал свое представление и посмотрели бы как эти представления между собой соотносятся. Но никто никого не заставляет ничего делать. Так що...раз тут не нашлись люди, которые понимают, то попробую дойти своим умом и дополнительным источниками информации.
>Я сижу в треде по пхп уже почти год и мне как-то грустно, что тут обсуждение как на кладбище. Никто ни у кого не спрашивает, никто не дает совета, не обсуждают нововведения пхп.
Так вы не учитесь нихуя. Код не пишете. Что обсуждать? То что в хуевом переводе фаулера хуево мысль сформулирована? Так ты даже на вопрос "о чем речь идет" ответить не можешь, потому что не понимаешь ни одного термина.
>Что в пхп используют?
Труд инвалидов.
>Скрам, аджаил?
Скрам это аджайл, но не наоборот.
>А для ci-cd?
Редактирование кода прямо на сервере через фтп. Мгновенная доставка кала в ебло пользователю.
Можно. Только тип нужно объявлять как Closure, а не как callable.
Использовали скрам, пробовали аджаил, в итоге всегда подстраивались под заказчика. Эти споры про то, что у нас не по флоу идут задачи, только время тратили на митингах.
На всех работах сервера на AWS были и у него вроде есть свои продукты для ci-cd, но везде использовали деплой на сервер через jenkins.
Один контроллер - один ресурс.
/user
/user/1
/user/1/edit
/user/1/update
/user/1/delete
и тд. Это всё один контроллер
На домашнем проекте сложно заставить использовать тдд, потому что пишу в стол и никому этот проект ненужен. На работе хоть и стали выделять время на написание тестов, мы все равно сначала пишем код.
Пчел, тдд - это развод лохов. Эта хуйня еще худо-бедно работает с языками типа си, в которых вся программа это набор отдельных функций. Но с ооп начинается феерический обсер.
Если кто-то на серьезном ебале утверждает что он пишет на пхп код по тдд, то он либо еблан и занимается какой-то хуйней никакого отношения к тдд не имеющей, либо хитрый жук-пиздабол который сознательно пиздит что че-то там делает, потому что ему с этого идет какой-то профит.
Обычно в один Контроллер помещают связанные друг с другом методы. Например: просмотр поста, добавление лайка, добавление комментария, редактирование комментария, удаление комментария. Так как все эти действия делаются на странице поста.
Инфраструктура для CI-CD обычно не привязана к языку программирования. Ну, к примеру, если ты используешь Github Actions для прогона тестов, то их можно использовать с любым языком, включая PHP.
Ну и к agile/scrum это тоже относится, их можно применять с любыми языками.
Чтобы понять этот фрагмент текста, надо понимать термины из него, которые описаны в других главах книги.
Например: "сценарии транзакции", "объекты домена", "модель предметной области", "слой источника данных", "контроллер-сущность", "контроллеры".
Сначала стоит разобраться с ними.
---------------
Но я все же попробую объяснить концепцию "слоев". Идея заключается в том, что мы делим наше приложение на "слои" и каждый слой взаимодействует только с соседними слоями. Посмотри на рисунок здесь: https://martinfowler.com/eaaCatalog/serviceLayer.html
Там как раз показано, на какие слои можно разделить приложение:
- сервисный слой
- модель предметной области (доменная модель)
- слой источника данных
И видно, что снаружи распогалается код, который использует сервисы: загрузчики данных, контроллеры пользовательского интерфейса, шлюзы API для обмена данными с другими организациями.
Предположим, что мы делаем приложение для заказа пиццы. Пиццу заказать можно несколькими способами:
- через мобильное приложение
- через партнеров, например, компании по доставке продуктов на дом
Несмотря на то, что заказ может поступить из разных источников, через разные API, через разные контролеры, мы не хотим дублировать код и хотим вынести процесс обработки заказа отдельно. Для этого мы помещаем логику обработки заказа в сервис, а контроллеры будут вызывать его, передавая нужные данные.
При оформлении заказа нам нужно получать различную информацию: например, наличие и цена нужного продукта, история заказов пользователя. И нам надо записать новый заказ. Для всего этого наш сервис обращается к слою доменной модели. А слой доменной модели берет и записывает данные в БД, используя "слой источника данных".
То есть, получается в разных слоях будут функции:
- в слое сервисов: обработать заказ (на вход получает список товаров, адрес доставки, телефон клиента итд)
- в слое предметной области: получить продукт по id, получить историю заказов, добавить новый заказ
- в слое источника данных: прочитать данные из таблицы, записать данные в таблицу
Чтобы понять этот фрагмент текста, надо понимать термины из него, которые описаны в других главах книги.
Например: "сценарии транзакции", "объекты домена", "модель предметной области", "слой источника данных", "контроллер-сущность", "контроллеры".
Сначала стоит разобраться с ними.
---------------
Но я все же попробую объяснить концепцию "слоев". Идея заключается в том, что мы делим наше приложение на "слои" и каждый слой взаимодействует только с соседними слоями. Посмотри на рисунок здесь: https://martinfowler.com/eaaCatalog/serviceLayer.html
Там как раз показано, на какие слои можно разделить приложение:
- сервисный слой
- модель предметной области (доменная модель)
- слой источника данных
И видно, что снаружи распогалается код, который использует сервисы: загрузчики данных, контроллеры пользовательского интерфейса, шлюзы API для обмена данными с другими организациями.
Предположим, что мы делаем приложение для заказа пиццы. Пиццу заказать можно несколькими способами:
- через мобильное приложение
- через партнеров, например, компании по доставке продуктов на дом
Несмотря на то, что заказ может поступить из разных источников, через разные API, через разные контролеры, мы не хотим дублировать код и хотим вынести процесс обработки заказа отдельно. Для этого мы помещаем логику обработки заказа в сервис, а контроллеры будут вызывать его, передавая нужные данные.
При оформлении заказа нам нужно получать различную информацию: например, наличие и цена нужного продукта, история заказов пользователя. И нам надо записать новый заказ. Для всего этого наш сервис обращается к слою доменной модели. А слой доменной модели берет и записывает данные в БД, используя "слой источника данных".
То есть, получается в разных слоях будут функции:
- в слое сервисов: обработать заказ (на вход получает список товаров, адрес доставки, телефон клиента итд)
- в слое предметной области: получить продукт по id, получить историю заказов, добавить новый заказ
- в слое источника данных: прочитать данные из таблицы, записать данные в таблицу
>Вообще не понял.
Хули непонятного? Состояние - это деталь реализации. И чтобы тестировать ооп код придется это состояние в каждром тесте собирать. Заполнять данные, мокать зависимости. Прибивая свой тест гвоздями к конкретной реализации.
Первая проблема в том, что само написание такого теста подразумевает "design upfront", в момент написания теста мы всю нутрянку класса уже должны иметь в голове. Что обессмысливает tdd в принципе, потому что вся идея в том что дизайн кода должен "возникать" в попытках удовлетворить тесты.
А вторая проблема в том что ооп тесты очень хрупкие. Любое изменение и они валятся с "false positive" ошибками. То есть код работает как надо, а тест при этом не проходит. Добавлено в объект поле, которое в тесте вообще не учавствует? Ну всё пизда, тест не проходит, потому что внутри дергается конструктор и ему теперь нового поля не хватает. А это означает что? Что тесты тоже нужно рефакторить. А это с точки зрения tdd - смертный грех. Если предыдущая проблема скорее филисофская, курица или яйцо. То переписывание теста чтобы он стал зеленым - это и с практической точки зрения хуйня полная и рушит весь флоу tdd и работу удваивает. Нахуй тогда вообще было писать тест до кода, если любое измениение меняет тест?
Третья проблема чисто техническая - повсеместная приватность. В ооп заебатый клас выглядит так: класс финальный, поля приватные, а верх запаян. Как проверить что в поле попало то что нужно? Писать геттер специально для теста? Использовать рефлексию в итак более медленных тестах? Как ни крути, получается лишняя чисто оопшная ебля. А с приватными методами че? Их тестировать или нет? Ага попался, по tdd о них даже думать нельзя - это деталь реализации. А если там че-то важное? Как убедиться что это "важное" вообще вызывается и покрыто тестом? Да хуй знает как. Tdd придумывалось без учета приватности-хуятности. В си ты то что нужно приносишь на входе и забираешь на выходе, все бля.
А самое главное, что это не какое-то сакральное знание, типа: вот спустя десять лет попыток я понял... Нихуя, ты влетаешь на все эти грабли мгновенно. Просто попробовав недельку пописать в таком стиле ты всего этого говна хлебнешь по полной.
Поэтому, повторяю, человек который утверждает что он так пишет код, в лучшем искренний долбоеб, который просто не понимает нихуя что такое tdd и нахуй оно надо. А в худшем - хитрожопый пидарас, который сидит на чьей-то шее.
>Вообще не понял.
Хули непонятного? Состояние - это деталь реализации. И чтобы тестировать ооп код придется это состояние в каждром тесте собирать. Заполнять данные, мокать зависимости. Прибивая свой тест гвоздями к конкретной реализации.
Первая проблема в том, что само написание такого теста подразумевает "design upfront", в момент написания теста мы всю нутрянку класса уже должны иметь в голове. Что обессмысливает tdd в принципе, потому что вся идея в том что дизайн кода должен "возникать" в попытках удовлетворить тесты.
А вторая проблема в том что ооп тесты очень хрупкие. Любое изменение и они валятся с "false positive" ошибками. То есть код работает как надо, а тест при этом не проходит. Добавлено в объект поле, которое в тесте вообще не учавствует? Ну всё пизда, тест не проходит, потому что внутри дергается конструктор и ему теперь нового поля не хватает. А это означает что? Что тесты тоже нужно рефакторить. А это с точки зрения tdd - смертный грех. Если предыдущая проблема скорее филисофская, курица или яйцо. То переписывание теста чтобы он стал зеленым - это и с практической точки зрения хуйня полная и рушит весь флоу tdd и работу удваивает. Нахуй тогда вообще было писать тест до кода, если любое измениение меняет тест?
Третья проблема чисто техническая - повсеместная приватность. В ооп заебатый клас выглядит так: класс финальный, поля приватные, а верх запаян. Как проверить что в поле попало то что нужно? Писать геттер специально для теста? Использовать рефлексию в итак более медленных тестах? Как ни крути, получается лишняя чисто оопшная ебля. А с приватными методами че? Их тестировать или нет? Ага попался, по tdd о них даже думать нельзя - это деталь реализации. А если там че-то важное? Как убедиться что это "важное" вообще вызывается и покрыто тестом? Да хуй знает как. Tdd придумывалось без учета приватности-хуятности. В си ты то что нужно приносишь на входе и забираешь на выходе, все бля.
А самое главное, что это не какое-то сакральное знание, типа: вот спустя десять лет попыток я понял... Нихуя, ты влетаешь на все эти грабли мгновенно. Просто попробовав недельку пописать в таком стиле ты всего этого говна хлебнешь по полной.
Поэтому, повторяю, человек который утверждает что он так пишет код, в лучшем искренний долбоеб, который просто не понимает нихуя что такое tdd и нахуй оно надо. А в худшем - хитрожопый пидарас, который сидит на чьей-то шее.
>Чем а отличается от б?
>попробую объяснить что такое хуй
Ебать, мастер класс по ответам. Это что-то типо той истории про студента, который выучил только одну тему и на любой вопрос отвечал только то что выучил? Надо взять на заметку, тоже буду блистать умом.
А по сутевой сути смысла, ты просто посоветовал пожрать говна от долбоебов, которые даже название книги перевести не осилили.
А хорошая новость в том, что ты посоветовал это человеку, которому на твои советы поебать. Ему просто было скучно и он пукнул в чат.
Тогда уж и без "мб"
А что такое "библиотека симфони? Она чем от любой другой библиотеки отличается?"
Ларавель использует компоненты Симфони. А тебя ебет?
Дополню. Вот в симфони есть twig, но он как-то неуклюже контачит с фронтенд фреймворками. Создаётся ощущение, будто натягиваю сову на глобус. Вот и дилемма, либо использовать чисто симфони, либо идти по пути API
>Что конкретно является Стандартом?
Стандартов нет, есть просто ЗДРАВЫЙ СМЫСЛ.
>Что лучше: чистый server side rendering или разделить фронт и бэк?
Ну ты эти апи где-то ещё используешь помимо веба? У тебя есть мобильное приложение? У тебя есть десктоп клиент? Сторонние сервисы взаимодействуют с твоим сайтом? Ты кому-то продаёшь апи-доступ за деньги? У тебя есть две команды - одна команда бекендеров, другая фронтэндеров?
Тогда нахуя тебе разделять на фронт и бэк? Чтобы в два раза больше было ебли с хостингом, с деплоем. Чтобы был там был отдельный фреймворк и здесь отдельный фреймворк. Это лишний геморрой который никаких плюсов не даёт. Ну вот ты разделил на фронт и бэк - что это дало сайту!?
Зачем слушать мнение авторитетных васьков с двача, если в этом никакой логики нет.
Это было бы логично, если бы ты делал какой-нибудь маркетплейс. И у этого маркетплейса было мобильное приложение + сторонний доступ у продавцов маркетплейса, чтобы они могли через апи загружать товары.
Тогда да, имеет смысл общий функционал вынести в апи, и сделать мобильное + веб-приложение. А так... просто разделять ради самого разделения - это тупо.
не ебу, вот картинка какая-то
> Состояние - это деталь реализации.
Так в процедурном коде состояние точно так же есть. Обычно работа с процедурной библиотекой начинается как-то так:
$context = deflate_init(ZLIB_ENCODING_GZIP);
В этом $context состояние и прячется (особенно на Си много таких библиотек). Это почти тот же ООП, только синтаксис другой. Но как это мешает тебе тестировать библиотеку? Не мешает.
> И чтобы тестировать ооп код придется это состояние в каждром тесте собирать. Заполнять данные, мокать зависимости.
Это относится и к процедурному коду. Ты в начале теста подготавливаешь нужное тебе окружение.
> Прибивая свой тест гвоздями к конкретной реализации.
Это зависит от того, как ты напишешь тест. Если ты тестируешь библиотеку через API, не залезая внутрь в приватные компоненты, то от изменения реализации (при сохранении интерфейса) твои тесты не сломаются.
> Первая проблема в том, что само написание такого теста подразумевает "design upfront", в момент написания теста мы всю нутрянку класса уже должны иметь в голове. Что обессмысливает tdd в принципе, потому что вся идея в том что дизайн кода должен "возникать" в попытках удовлетворить тесты.
Не согласен. Мы должны иметь представление, какую структуру классов мы сделаем, да, но что у них внутри, тесту не важно.
Но в процедурном коде тебе точно так же надо заранее продумать API, чтобы писать тесты к нему.
То есть, если ты хочешь критиковать TDD, пожалуйста, но говорить, что ООП как-то хуже подходит для TDD, чем процедурный код, неправильно.
> То есть код работает как надо, а тест при этом не проходит. Добавлено в объект поле, которое в тесте вообще не учавствует?
Отлично! Тест нашел баг: ты добавил несовместимые изменения в класс, но код, использующий этот класс, не переделал. Очевидно, что и в коде приложения будет та же ошибка, ведь обычно тесты используют классы точно так же, как само приложение.
> Как проверить что в поле попало то что нужно? Писать геттер специально для теста? Использовать рефлексию в итак более медленных тестах?
Неправильно. Зачем тебе проверять, что в приватном поле? Это тебя не должно волновать. Ты должен проверять, что класс работает, как задумано. Что поведение объекта соответствует описанным в ТЗ требованиям.
Давай конкретный пример: пусть у тебя есть класс, представляющий товар, и в нем есть метод для задания скидки. Ты не проверяешь, что хранится в приватных полях товара и как там сохранилась скидка. Ты создаешь товар ценой 1000 р и проверяешь, что 1) если задать скидку 10%, то цена (полученная через геттер) становится не 1000 р, а 900р. 2) если задать скидку 0%, то цена снова становится 1000 р.
При этом, этот геттер добавлен не ради тестов. Он нужен, чтобы выводить цену на странице товара.
В примере выше я не добавил ни одной строчки кода ради тестов. Хотя, иногда так приходится делать, когда другие варианты более сложные.
Что касается хрупкости тестов, это известная проблема и надо учиться писать тесты так, чтобы они реже ломались. Не полагаться на знание об особенностях реализации, а тестировать публичное API.
> В си ты то что нужно приносишь на входе и забираешь на выходе, все бля.
Нет. В Си точно так же есть приватные поля (представь себе). Можешь погуглить opaque struct/opaque pointer, это паттерн, когда тебе возвращают указатель на структуру, но у тебя нет информации о ней:
struct my_library_context; // объявление без определения
struct my_library_context *ctx;
ctx = my_library_init();
Здесь ты не можешь заглянуть внутрь структуры. Ты можешь лишь передавать ее в другие функции и все.
И напомню, что я не столько защищаю TDD, сколько развенчиваю заблуждение, что ООП как-то хуже подходят для TDD и для тестирования.
И, кстати, если у тебя есть вопросы или непонятные моменты по автоматизированному тестированию (не по TDD, а вообще), могу подсказать что-то.
> Состояние - это деталь реализации.
Так в процедурном коде состояние точно так же есть. Обычно работа с процедурной библиотекой начинается как-то так:
$context = deflate_init(ZLIB_ENCODING_GZIP);
В этом $context состояние и прячется (особенно на Си много таких библиотек). Это почти тот же ООП, только синтаксис другой. Но как это мешает тебе тестировать библиотеку? Не мешает.
> И чтобы тестировать ооп код придется это состояние в каждром тесте собирать. Заполнять данные, мокать зависимости.
Это относится и к процедурному коду. Ты в начале теста подготавливаешь нужное тебе окружение.
> Прибивая свой тест гвоздями к конкретной реализации.
Это зависит от того, как ты напишешь тест. Если ты тестируешь библиотеку через API, не залезая внутрь в приватные компоненты, то от изменения реализации (при сохранении интерфейса) твои тесты не сломаются.
> Первая проблема в том, что само написание такого теста подразумевает "design upfront", в момент написания теста мы всю нутрянку класса уже должны иметь в голове. Что обессмысливает tdd в принципе, потому что вся идея в том что дизайн кода должен "возникать" в попытках удовлетворить тесты.
Не согласен. Мы должны иметь представление, какую структуру классов мы сделаем, да, но что у них внутри, тесту не важно.
Но в процедурном коде тебе точно так же надо заранее продумать API, чтобы писать тесты к нему.
То есть, если ты хочешь критиковать TDD, пожалуйста, но говорить, что ООП как-то хуже подходит для TDD, чем процедурный код, неправильно.
> То есть код работает как надо, а тест при этом не проходит. Добавлено в объект поле, которое в тесте вообще не учавствует?
Отлично! Тест нашел баг: ты добавил несовместимые изменения в класс, но код, использующий этот класс, не переделал. Очевидно, что и в коде приложения будет та же ошибка, ведь обычно тесты используют классы точно так же, как само приложение.
> Как проверить что в поле попало то что нужно? Писать геттер специально для теста? Использовать рефлексию в итак более медленных тестах?
Неправильно. Зачем тебе проверять, что в приватном поле? Это тебя не должно волновать. Ты должен проверять, что класс работает, как задумано. Что поведение объекта соответствует описанным в ТЗ требованиям.
Давай конкретный пример: пусть у тебя есть класс, представляющий товар, и в нем есть метод для задания скидки. Ты не проверяешь, что хранится в приватных полях товара и как там сохранилась скидка. Ты создаешь товар ценой 1000 р и проверяешь, что 1) если задать скидку 10%, то цена (полученная через геттер) становится не 1000 р, а 900р. 2) если задать скидку 0%, то цена снова становится 1000 р.
При этом, этот геттер добавлен не ради тестов. Он нужен, чтобы выводить цену на странице товара.
В примере выше я не добавил ни одной строчки кода ради тестов. Хотя, иногда так приходится делать, когда другие варианты более сложные.
Что касается хрупкости тестов, это известная проблема и надо учиться писать тесты так, чтобы они реже ломались. Не полагаться на знание об особенностях реализации, а тестировать публичное API.
> В си ты то что нужно приносишь на входе и забираешь на выходе, все бля.
Нет. В Си точно так же есть приватные поля (представь себе). Можешь погуглить opaque struct/opaque pointer, это паттерн, когда тебе возвращают указатель на структуру, но у тебя нет информации о ней:
struct my_library_context; // объявление без определения
struct my_library_context *ctx;
ctx = my_library_init();
Здесь ты не можешь заглянуть внутрь структуры. Ты можешь лишь передавать ее в другие функции и все.
И напомню, что я не столько защищаю TDD, сколько развенчиваю заблуждение, что ООП как-то хуже подходят для TDD и для тестирования.
И, кстати, если у тебя есть вопросы или непонятные моменты по автоматизированному тестированию (не по TDD, а вообще), могу подсказать что-то.
Это компоненты. Разработчики Симфони вынесли код, который не привязан намертво к фреймворку, в компоненты, которые можно использовать отдельно от Симфони, в любом проекте на любом фреймворке.
Например, symfony/process позволяет запускать сторонние команды.
Стандарта нет, есть плюсы и минусы.
Плюсы использования SPA:
Можно делать интерактивные приложения, где все пересчитывается, обновляется без перезагрузок страницы.
Можно делать сложные формы, где поля скрываются или меняются в зависимости от состояния других полей, со сложными правилами валидации, подсказками.
Можно делать конструкторы, редакторы.
Минусы использования SPA:
Увеличивается объем работы, надо писать 2 приложения (бек и фронт), как правило, загрузка страницы сильно замедляется (я знаю, что в теории можно сделать без тормозов, но на практике в 99 из 100 случаев в SPA будет крутиться круг при загрузке страницы, в то время как при server side rendering проблемы нет, и эта проблема есть даже у крупных компаний).
Ты можешь так же рассмотреть вариант "SSR с аяксом", когда все рендерится на сервере, но ты используешь аякс, чтобы обновлять страницу без перезагрузки. При этом с сервера ты шлешь куски HTML, которые вставляются в страницу.
И еще есть вариант, когда большая часть сайта рендерится на сервере, но для каких-то особых случаев (сложная форма, конструктор, редактор) используются виджеты на основе SPA.
В общем, если ты делаешь блог/новостной сайт, то server side rendering подходит лучше, а если конструктор рекламной кампании, то SPA удобнее. SPA больше подходит для случаев, когда сайт больше похож на приложение, чем на набор текстовых страниц с информацией.
>На си можно наговнокодить хуйни
Ноу щит шерлок. Tdd для того и применяют чтобы получались нормальные легко тестируемые чистые функции.
>Это относится и к процедурному коду. Ты в начале теста подготавливаешь нужное тебе окружение.
Разница в том что тебе нужно подготовить ВЕСЬ объект. Даже то что ты тестировать не будешь. И даже если замокаешь, то эти моки придется поддерживать и постоянно править под измениения в коде.
>Это зависит от того, как ты напишешь тест.
Давай пример такого теста https://3v4l.org/
>но что у них внутри, тесту не важно.
Как создавать объекты будешь в тесте? Как моки создавать будешь? И вообще чеб не написать тогда тест после класса, один хуй ты этот класс уже в голове держишь.
>код работает как надо, а тест при этом не проходит
>Очевидно, что и в коде приложения будет та же ошибка, ведь обычно
>код работает как надо
Ты еблан?
>Зачем тебе проверять, что в приватном поле?
Метод "public function changeDate(DateTime $newDate): void"
Дата поменялась? Что еще поменялось? Состояние после отработки метода корректно? Вообще похуй при этом как и в каком геттере это будет использоваться ПОТОМ. Может вообще нахуй не будет, а просто в орм улетит, которая умеет приватные поля читать (99% случаев). Есть публичный метод, меняющий состояние, небходимо протестирвать что он делает именно то что нужно.
>Что касается хрупкости тестов, это известная проблема и надо учиться писать тесты так, чтобы они реже ломались.
От создателей "нормально делай", "бездомные купите дома" и "водный мир".
>Нет. В Си точно так же есть приватные поля (представь себе).
Ну есть, и че? Ты пытаешься рассказать что в си можно писать "типа ооп код" и его тоже будет неудобно тестировать? Ты где-то у Кента Бека прочитал: - "Посоны ебашьте приватные поля и неявное состояние, чтобы вы заебались это дерьмо тестировать", или че?
>И, кстати, если у тебя есть вопросы или непонятные моменты по автоматизированному тестированию
Вот тебе вопрос. Как тестировать интерфейс? Вот пример https://3v4l.org/VseOX
Как протестировать только интерфейс, не влезая в детали реализаций? Там ведь придется мокать логгер, мейлер. Еще и тест повторять для каждого класса. Вот как? Только без водяной хуйни типа "сделай заебись", напиши конкретный пример теста.
>На си можно наговнокодить хуйни
Ноу щит шерлок. Tdd для того и применяют чтобы получались нормальные легко тестируемые чистые функции.
>Это относится и к процедурному коду. Ты в начале теста подготавливаешь нужное тебе окружение.
Разница в том что тебе нужно подготовить ВЕСЬ объект. Даже то что ты тестировать не будешь. И даже если замокаешь, то эти моки придется поддерживать и постоянно править под измениения в коде.
>Это зависит от того, как ты напишешь тест.
Давай пример такого теста https://3v4l.org/
>но что у них внутри, тесту не важно.
Как создавать объекты будешь в тесте? Как моки создавать будешь? И вообще чеб не написать тогда тест после класса, один хуй ты этот класс уже в голове держишь.
>код работает как надо, а тест при этом не проходит
>Очевидно, что и в коде приложения будет та же ошибка, ведь обычно
>код работает как надо
Ты еблан?
>Зачем тебе проверять, что в приватном поле?
Метод "public function changeDate(DateTime $newDate): void"
Дата поменялась? Что еще поменялось? Состояние после отработки метода корректно? Вообще похуй при этом как и в каком геттере это будет использоваться ПОТОМ. Может вообще нахуй не будет, а просто в орм улетит, которая умеет приватные поля читать (99% случаев). Есть публичный метод, меняющий состояние, небходимо протестирвать что он делает именно то что нужно.
>Что касается хрупкости тестов, это известная проблема и надо учиться писать тесты так, чтобы они реже ломались.
От создателей "нормально делай", "бездомные купите дома" и "водный мир".
>Нет. В Си точно так же есть приватные поля (представь себе).
Ну есть, и че? Ты пытаешься рассказать что в си можно писать "типа ооп код" и его тоже будет неудобно тестировать? Ты где-то у Кента Бека прочитал: - "Посоны ебашьте приватные поля и неявное состояние, чтобы вы заебались это дерьмо тестировать", или че?
>И, кстати, если у тебя есть вопросы или непонятные моменты по автоматизированному тестированию
Вот тебе вопрос. Как тестировать интерфейс? Вот пример https://3v4l.org/VseOX
Как протестировать только интерфейс, не влезая в детали реализаций? Там ведь придется мокать логгер, мейлер. Еще и тест повторять для каждого класса. Вот как? Только без водяной хуйни типа "сделай заебись", напиши конкретный пример теста.
Так бля. Сначала пиши тесты, а потом обнимания, рукопожатия и передача приветов.
А то так и будете рассказывать что всего-лишь не надо писать "хрупкие тесты", а как таску мерджить, так пол сотни ассертов красные.
Что за пиздец, это годы изучения, ГОДЫ ГОД.
Какие вообще норм вакансии и какие норм зп в пхп сейчас?
за плечами год бека - интеграция верстки от фронтовой команды и апи, ларавель, битрикс, иногда опенкарт.
60к
просто 60к
как тебе такое елон моск?
> Tdd для того и применяют чтобы получались нормальные легко тестируемые чистые функции.
Мне кажется, про чистые функции ты уже от себя додумываешь. TDD или другие методологии тестирования не требуют от тебя писать чистые функции.
> Разница в том что тебе нужно подготовить ВЕСЬ объект. Даже то что ты тестировать не будешь.
Для этого в ООП придумали конструктор.
> Давай пример такого теста
Давай постановку задачи или ТЗ. Я не могу написать тест, не имея хотя бы требований к коду.
> Дата поменялась? Что еще поменялось? Состояние после отработки метода корректно? Вообще похуй при этом как и в каком геттере это будет использоваться ПОТОМ. Может вообще нахуй не будет, а просто в орм улетит, которая умеет приватные поля читать (99% случаев). Есть публичный метод, меняющий состояние, небходимо протестирвать что он делает именно то что нужно.
Если твоя задача протестировать, что после вызова changeDate и flush изменения сохраняются в БД, то я вижу минимум 2 способа это сделать:
- загрузить сущность через ORM и проверить значение через геттер
- напрямую залезть в таблицу и прочесть записанное значение
Ни один не требует доступа к приватным полям. И тест с загрузкой сущности через ORM имеет тот плюс, что он еще протестирует, что ORM правильно сконфигурирована - что настроено сохранение состояния в БД для нужных полей.
>>Что касается хрупкости тестов, это известная проблема и надо учиться писать тесты так, чтобы они реже ломались.
> От создателей "нормально делай", "бездомные купите дома" и "водный мир".
Я пишу и использую тесты на практике, они мне помогают. А что ты хочешь сказать, что это невозможно? Твое представление о реальности с ней не согласуется.
> Tdd для того и применяют чтобы получались нормальные легко тестируемые чистые функции.
Мне кажется, про чистые функции ты уже от себя додумываешь. TDD или другие методологии тестирования не требуют от тебя писать чистые функции.
> Разница в том что тебе нужно подготовить ВЕСЬ объект. Даже то что ты тестировать не будешь.
Для этого в ООП придумали конструктор.
> Давай пример такого теста
Давай постановку задачи или ТЗ. Я не могу написать тест, не имея хотя бы требований к коду.
> Дата поменялась? Что еще поменялось? Состояние после отработки метода корректно? Вообще похуй при этом как и в каком геттере это будет использоваться ПОТОМ. Может вообще нахуй не будет, а просто в орм улетит, которая умеет приватные поля читать (99% случаев). Есть публичный метод, меняющий состояние, небходимо протестирвать что он делает именно то что нужно.
Если твоя задача протестировать, что после вызова changeDate и flush изменения сохраняются в БД, то я вижу минимум 2 способа это сделать:
- загрузить сущность через ORM и проверить значение через геттер
- напрямую залезть в таблицу и прочесть записанное значение
Ни один не требует доступа к приватным полям. И тест с загрузкой сущности через ORM имеет тот плюс, что он еще протестирует, что ORM правильно сконфигурирована - что настроено сохранение состояния в БД для нужных полей.
>>Что касается хрупкости тестов, это известная проблема и надо учиться писать тесты так, чтобы они реже ломались.
> От создателей "нормально делай", "бездомные купите дома" и "водный мир".
Я пишу и использую тесты на практике, они мне помогают. А что ты хочешь сказать, что это невозможно? Твое представление о реальности с ней не согласуется.
> Вот тебе вопрос. Как тестировать интерфейс? Вот пример https://3v4l.org/VseOX
О, наконец-то из тебя удалось вытянуть код.
> Как протестировать только интерфейс, не влезая в детали реализаций?
Тестирование всегда начинается с требований. Какие требования поставлены? Что должен делать код?
Имея требования, мы придумываем сценарии для проверки, что они реализованы. И на их основе уже пишем тесты.
Ты не дал мне ТЗ, поэтому я попробую применить интуицию и навыки реверс-инжиниринга, чтобы восстановить ТЗ по твоему коду.
В начале я вижу интерфейс DoThing, и, как я не ломал голову, я не смог понять, что он должен уметь делать. Что требуется от метода doThing()? Он ничего не принимает и не возвращает, и единственное, что мы можем сделать, проверить, что при вызове метода ничего не падает. Нет требований - нет тестов.
Далее, идут 3 класса-реализации. Так как единственное требование к методу doThing - не падать, мы проверяем это для всех трех классов - создаем объект и вызываем метод. На этом тестирование соответствия реализации интерфейсу закончено.
Но далее мы можем проверить дополнительные требования к классам. Из кода видно, что к классам DoThingAndLog и DoThingAndMail предъявляются дополнительные требования.
Из названия DoThingAndLog можно сделать вывод, что он должен вызывать логгер, когда мы вызываем метод doThing. Если я правильно понял ТЗ, то это можно проверить, передав мок вместо логгера мок и проверив, что он был вызван минимум 1 раз при вызове doThing. Если я правильно угадал ТЗ, конечно.
Аналогично можно поступить с классом DoThingAndMail.
Что касается класса SimplyDoThing, то здесь дополнительных требований нет и тестировать нечего.
> Как протестировать только интерфейс, не влезая в детали реализаций?
Сам интерфейс не тестируют (если я вдруг так написал выше, то я ошибся). Тестируют реализацию и ее соответствие интерфейсу, при этом используя только информацию из интерфейса (описанные в нем методы). То есть, если в интерфейсе написано "при вызове метода X должно происходить Y", то мы это и проверяем.
В идеале мы при этом не смотрим, как именно это делает реализация, а опираемся только на информацию об интерфейсе (метод "черного ящика"). Такой тест будет надежным, и не сломается от смены реализации. Но иногда на практике приодится учитывать особенности реализации.
> Там ведь придется мокать логгер, мейлер
Да, если для работы класса нужен логгер, придется либо мокать, либо использовать NullLogger. Но подготавливать окружение пришлось бы в любом случае, хоть ты процедурщину пиши, хоть функциональщину, хоть ООП. А ты изначально утверждал, что такие сложности есть лишь при использовании ООП-стиля.
> напиши конкретный пример теста.
Если из описания выше непонятно, то вот пример одного теста:
public function testDoThingDoesntCrashWithSimplyDoThing()
{
$simpleImpl = new SimplyDoThing();
$simpleImpl->doThing();
}
Пишем такое же для DoThingAndLog, DoThingAndMail. Далее пишем 2 теста, проверяющих что вызывается логгер и мейлер.
Если правда непонятно, как они будут выглядеть, могу написать и их.
> Вот тебе вопрос. Как тестировать интерфейс? Вот пример https://3v4l.org/VseOX
О, наконец-то из тебя удалось вытянуть код.
> Как протестировать только интерфейс, не влезая в детали реализаций?
Тестирование всегда начинается с требований. Какие требования поставлены? Что должен делать код?
Имея требования, мы придумываем сценарии для проверки, что они реализованы. И на их основе уже пишем тесты.
Ты не дал мне ТЗ, поэтому я попробую применить интуицию и навыки реверс-инжиниринга, чтобы восстановить ТЗ по твоему коду.
В начале я вижу интерфейс DoThing, и, как я не ломал голову, я не смог понять, что он должен уметь делать. Что требуется от метода doThing()? Он ничего не принимает и не возвращает, и единственное, что мы можем сделать, проверить, что при вызове метода ничего не падает. Нет требований - нет тестов.
Далее, идут 3 класса-реализации. Так как единственное требование к методу doThing - не падать, мы проверяем это для всех трех классов - создаем объект и вызываем метод. На этом тестирование соответствия реализации интерфейсу закончено.
Но далее мы можем проверить дополнительные требования к классам. Из кода видно, что к классам DoThingAndLog и DoThingAndMail предъявляются дополнительные требования.
Из названия DoThingAndLog можно сделать вывод, что он должен вызывать логгер, когда мы вызываем метод doThing. Если я правильно понял ТЗ, то это можно проверить, передав мок вместо логгера мок и проверив, что он был вызван минимум 1 раз при вызове doThing. Если я правильно угадал ТЗ, конечно.
Аналогично можно поступить с классом DoThingAndMail.
Что касается класса SimplyDoThing, то здесь дополнительных требований нет и тестировать нечего.
> Как протестировать только интерфейс, не влезая в детали реализаций?
Сам интерфейс не тестируют (если я вдруг так написал выше, то я ошибся). Тестируют реализацию и ее соответствие интерфейсу, при этом используя только информацию из интерфейса (описанные в нем методы). То есть, если в интерфейсе написано "при вызове метода X должно происходить Y", то мы это и проверяем.
В идеале мы при этом не смотрим, как именно это делает реализация, а опираемся только на информацию об интерфейсе (метод "черного ящика"). Такой тест будет надежным, и не сломается от смены реализации. Но иногда на практике приодится учитывать особенности реализации.
> Там ведь придется мокать логгер, мейлер
Да, если для работы класса нужен логгер, придется либо мокать, либо использовать NullLogger. Но подготавливать окружение пришлось бы в любом случае, хоть ты процедурщину пиши, хоть функциональщину, хоть ООП. А ты изначально утверждал, что такие сложности есть лишь при использовании ООП-стиля.
> напиши конкретный пример теста.
Если из описания выше непонятно, то вот пример одного теста:
public function testDoThingDoesntCrashWithSimplyDoThing()
{
$simpleImpl = new SimplyDoThing();
$simpleImpl->doThing();
}
Пишем такое же для DoThingAndLog, DoThingAndMail. Далее пишем 2 теста, проверяющих что вызывается логгер и мейлер.
Если правда непонятно, как они будут выглядеть, могу написать и их.
Кстати, если есть еще что-то, что непонятно как протестировать, я могу помочь. Но, пожалуйста, либо начинай с требований к коду, постановки задачи, либо давай код, из которого можно восстановить требования из комментариев или реверс-инжинирингом.
> Как создавать объекты будешь в тесте? Как моки создавать будешь? И вообще чеб не написать тогда тест после класса, один хуй ты этот класс уже в голове держишь.
Как я понимаю, сначала тебе надо проработать структуру классов и методов, прежде чем писать тесты. При этом, ты можешь использовать интерфейсы для тех частей кода, которые ты пока окончательно не спроектировал (в тесте ты тогда сможешь создать мок).
Наверно, это вакансия для сеньоров, а не для начинающих. С опытом в 3 года там, конечно, делать нечего.
>Мне кажется, про чистые функции ты уже от себя додумываешь. TDD или другие методологии тестирования не требуют от тебя писать чистые функции.
Ну сразу видно что ты не понимаешь что такое tdd, как это работает и зачем это делают. tdd не требует от тебя ничего напрямую. Но применяют tdd чтобы получить код, который можно получить только если ты подстраиваешься под тест. А идеальная для тестирования функция, содержимым (реализацией) которой можно полностью пренебречь - это "чистая" функция. А значит в пределе все функции, которые только возможно, по tdd должны быть чистыми. И их количество должно быть больше, чем без применения tdd. Это база. Нахуй ты лезешь спорить, если не понимаешь о чем споришь?
>Для этого в ООП придумали конструктор.
Ну да. Нужно подготовить все что требутся передать в конструктор, даже если для теста этого не нужно. И для зависимостей нужно подготовить все, даже если это не нужно. И для зависимостей зависимостей... Смекаешь?
>после вызова changeDate и flush
Откуда ты высрал flush()? Вызван только один метод. Никто не вызывал flush(). До flush() может и не дойдет никогда, а упадет с эксепшеном. Потому что в программе баг, не покрытый тестом. У тебя получился не юнит тест, а какой-то интеграционный или даже смоук, который проверяет что программа целиком в принципе выполняется.
>Я пишу и использую тесты на практике, они мне помогают.
Разумеется помогают. Только кода в этих тестах раза в три больше кода, чем кода который тестируется. И при каждом серьёзном изменении тестов десять, которые тестируют что-то другое, краснеют с false-positive и тебе приходится в них лезть и ПОДДЕРЖИВАТЬ. И когда этих тестов становится хотябы тысяча, наступает пиздец и боль. Поэтому единственная тактика в ооп - покрывать тестами действительно важные места и мириться с этим налогом ебучим. А уебок, который щас по tdd тебе насрет пятьсот хуй пойми каких тестов вопринимается как смертельная угроза.
>Как протестировать только интерфейс, не влезая в детали реализаций?
>Пишем такое же для DoThingAndLog, DoThingAndMail.
Бля. Так о том и речь сука.
Mailer и logger это ДЕТАЛИ РЕАЛИЗАЦИИ. От них выполнение того что мы тестируем никак не зависит. И ты мало того что выстрал ТРИ ТЕСТА ОДНОГО И ТОГО ЖЕ ПОВЕДЕНИЯ БЛЯДЬ, так еще и привязал эти тесты к реализации и теперь при изменении этих реализаций тесты править придется. Вот отрефакторит кто-нибудь логгер и в его КОНСТРУКТОР сука надо будет что-нубудь передать. Твой тест наебнется. И переписывать его придется тому кто правит логгер. Читать твою хуйню, разбираться че там происходит, че тестируется, че замокать.
А теперь имаджинируй, что ты в такой манере пол годика тесты по tdd писал. Я когда писал про x3 кода я имел ввиду не количесвто тестов, а что внутри каждого теста кода x3. А у тебя блядь и тестов x3, в куб нахуй возвел. Так вот имаджинируй что в этой хуйне тебе, не дай аллах, понадобилось что-то изменить.
Вопрос: ты ебнешься в тот момент когда увидишь сколько тестов отвалилось или в момент когда поймешь что некоторые тесты замоканы так, что не отвалились, хотя должны?
>Как я понимаю, сначала тебе надо проработать структуру классов и методов, прежде чем писать тесты.
Чем это отличается от "сначала записать структуру классов и методов, прежде чем писать тесты"?
Ну вот такой я шиз, хочу любым способом заставить вас учиться писать код и думать башкой.
Да нормально у меня дела. Зашел бы в дискорд и нормально пообщались, проявил бы немного уважения к старику.
занят, пару откликов по городу на программиста кинул, работаю инженером времени нету :(
Нахуя ты lessons превращаешь в lessonForms, хотя метод при этом saveLessons? Что ты вообще сохраняешь? Формы или уроки?
Нахуя тебе счетчик если у тебя итак есть массив? У каждого элемента массива есть порядковый номер.
Вот так это должно выглядеть. https://3v4l.org/FsVFt
А еще лучше вот так https://3v4l.org/JJMKD в нормальном ооп стиле.
Оба варианта хуйня. Я так предполагаю, там идёт валидация и сохранение в базу данных.
1. В цикле писать в бд крайне неэффективно.
2. У foreach есть встроенный индекс, переменная $number не нужна, можно просто foreach($lessons as $key => $form) и далее использовать $key.
в зависимостях, входных и выходных типах только интерфейсы, так понятнее, дебич?
interface Collection {
public function find(ItemId $itemId): Item;
public function add(Item $item): void;
public function remove(Item $item): void;
}
Item, ItemId - какие-то интерфейсы. Сам Collection тоже можно указывать в качестве входного или выходного параметра в методах других классов.
Другое дело, что зависимость от интерфейсов - это не закон, который нужно слепо соблюдать, а решение, которое в каких-то ситуациях поможет, а в других затруднит разработку.
Необходимо ли для web fullstack изучить ООП ? Если да, то что можете сказать об этой книге?
https://www.youtube.com/watch?v=j0_u26Vpb4w
Я читал. Норм книга. В плане ООП там только синтаксис, насколько я помню, а ООП это не про синтаксис :') - недостаточно знать как объявить класс, нужно уметь мыслить объектами. Для этого советую прочитать 1.6 главы 1 книги "Банда четырех, паттерны проектирования" - хорошо описана философия ООП. А там дальше нужно читать про объектно-ориентированное проектирование, DDD, Solid, гибкую архитектуру, паттерны и т.д.
>Необходимо ли для web fullstack изучить ООП ?
ООП в любом случае нужно. Оно фигурирует в 99% вакансиях. И если не явно указывается, то обычно подразумевается как само собой разумеющееся.
>нужно читать про объектно-ориентированное проектирование, DDD, Solid, гибкую архитектуру, паттерны и т.д.
DDD и архитектуру вычеркивай нахуй. В функциональных программах че, нет архитектуры? К ооп архитектура никакого отношения не имеет.
А DDD это вообще про организацию компании и разработки в целом, а не про то как код писать. Для использования DDD в принципе похуй на каком языке писать, хоть на брейнфаке.
>не про то как код писать
Пол книги о том, что такое сущности, объекты-значения, агрегаты; о том, как инкапсулировать логику создания сложных объектов, логику получения сложных объектов, о том, как явно выражать инварианты в коде; - все это можно выкинуть в мусорку? Согласен, что в книге Эванса уделяется внимание взаимодействию людей - как на этапе моделирования предметной области, так и на этапе разработки, но все же, Эванс ведь и созданию кода уделяет внимание, а с этим, как мне кажется, имеет смысл ознакомиться. Эванс очень хорошо показывает зачем нужны фабрики и репозитории.
А ты больше читай долбоебов, которые слово "ПИСАТЬ" от "РАЗРАБАЫТВАТЬ" не отличают. В оригинале речь идет о написании ТЗ, чем разработчик в принципе не занимается.
>Пол книги о том, что такое сущности, объекты-значения, агрегаты
И че? Книга про вырабатывание специального языка для формирования из требований бизнеса структуры будущей программы. Модель описанная таким языком универсальна. Её нужно просто "записать" с помощью кода на выбранном языке.
Можно все эти невероятные "сущности" записать на функциональном языке? Да конечно можно блядь. Еще и проще будет - там все иммутабельное. Есть идентификатор - сущность, нету - вэлью обджект. А то что уходит в io - агрегат. Все нахуй. Три строчки блядь. Пол книги, ну охуеть теперь.
Сейчас даже мидлы работу найти не могут, какой там вкат в 30
Не, рили, на платформе гугла в топ 100, например. На хакерване, до санкций, тоже в некоторых программах на норм местах был.
>А как глубоко ты в пхп парашу окунался, хакер?
Я сделал задачу на студентов, на файлообменник и начал делать на тестхаб. Потом внезапно нашел баг телеге, который меня бесил, написал их безопасникам, и мне в ответ 500 евро. А дальше уже сам читал репорты, делал всякие лабы на безопасность, и начал уже специально баги искать.
Ну так пиши резюме, пизди про год опыта и сри откликами. Ты думал оно как-то по другому будет?
Ну открыл, и че? А ты там через что срёшь, если у тебя постоянно в очке две подписки на проход в землю и шторм из $ ?
Затем, что код должен быть таким, каким его задумал программист. Если программист задумал, что в переменной name должна быть строка, то там должна быть строка. А лучший способ это обеспечить - объявить тип.
То что ты получаешь тут протянется еще через десяток методов/изменений, а может ваще в объект положишь, сформатируешь данные в xml строку и ты будешь думать откуда x exception, проходясь по каждому.
1) код становится проще читать, когда ты видишь, где какой тип данных
2) защита от ошибок. Чтобы ты не мог передать массив в функцию, которая принимает число. PHP сразу выдаст ошибку и ты легко ее исправишь.
>Зачем так заморачиваются с объявлением типа данных?
Чтобы статический анализатор PHPStan мог найти баг
>>213293
>>213756
>>213904
>>213910
Все вокруг да около.
ЧТОБЫ БЫЛО МЕНЬШЕ ОШИБОК
Какие вообще ошибки можно сделать при написании кода на пхп?
1) Сделать не то что нужно. Надо было разделить, а ты умножил. Для избегания именно таких ошибок пишутся тесты.
2) Опечатки. $Name $naem $nаме Этих ошибок большинство. Именно поэтому используется IDE, которая держит в памяти индекс всего кода и говорит тебе: нет такой переменной. И подсказывает какие есть. Именно поэтому чем больше у тебя ассоциативных массивов, тем больше багов. В $usre['naem'] IDE не проверяет что в названии индекса, для неё это просто текст.
3) Неправильное содержимое переменной. Этих ошибок мало. Но именно они самые сложнонаходимые. Потому что офк мы не видим содержимого переменных, мы можем только предположить. И приходится подключать дебаггер и просматривать всю программу в поисках несоответствий. НЕДЕЛЯМИ.
А как можно получить неправильное содержимое переменной?
1. Ну для начала можно просто не знать. Если тип не объявлен, то придется его угадать. Ну или прочитать код и из кода попытаться понять что же там нужно. И тут уж если понял неправильно, то будет баг.
2. Можно перепутать переменные. Перепутать местами параметры функции или просто взять не ту. Тут опять же - если IDE знает тип переданной переменной и видит что объявленный тип другой, то подскажет тебе про ошибку.
3. Можно просто НЕ ЗАМЕТИТЬ что содержимое поменялось. Потому что в пхп есть механизмы, которые преобразуют содержимое автоматически, даже если ты его об этом не просил. Чтобы избегать таких неявных преобразований тип переменной должен быть четко определен.
Вообще практически все что спрашивают на собесах делается для избежания ошибок. Хорошая архитектура? Чтобы все было понятнее и совершалось меньше ошибок. Солид? Чтобы меньше менять код и совершать меньше ошибок. Паттерны? Чтобы использовать готовые наработки и избегать лишних ошибок. git? Чтобы отслеживать изменения в проекте, избегать путаницы и совершать меньше ошибок.
>>213293
>>213756
>>213904
>>213910
Все вокруг да около.
ЧТОБЫ БЫЛО МЕНЬШЕ ОШИБОК
Какие вообще ошибки можно сделать при написании кода на пхп?
1) Сделать не то что нужно. Надо было разделить, а ты умножил. Для избегания именно таких ошибок пишутся тесты.
2) Опечатки. $Name $naem $nаме Этих ошибок большинство. Именно поэтому используется IDE, которая держит в памяти индекс всего кода и говорит тебе: нет такой переменной. И подсказывает какие есть. Именно поэтому чем больше у тебя ассоциативных массивов, тем больше багов. В $usre['naem'] IDE не проверяет что в названии индекса, для неё это просто текст.
3) Неправильное содержимое переменной. Этих ошибок мало. Но именно они самые сложнонаходимые. Потому что офк мы не видим содержимого переменных, мы можем только предположить. И приходится подключать дебаггер и просматривать всю программу в поисках несоответствий. НЕДЕЛЯМИ.
А как можно получить неправильное содержимое переменной?
1. Ну для начала можно просто не знать. Если тип не объявлен, то придется его угадать. Ну или прочитать код и из кода попытаться понять что же там нужно. И тут уж если понял неправильно, то будет баг.
2. Можно перепутать переменные. Перепутать местами параметры функции или просто взять не ту. Тут опять же - если IDE знает тип переданной переменной и видит что объявленный тип другой, то подскажет тебе про ошибку.
3. Можно просто НЕ ЗАМЕТИТЬ что содержимое поменялось. Потому что в пхп есть механизмы, которые преобразуют содержимое автоматически, даже если ты его об этом не просил. Чтобы избегать таких неявных преобразований тип переменной должен быть четко определен.
Вообще практически все что спрашивают на собесах делается для избежания ошибок. Хорошая архитектура? Чтобы все было понятнее и совершалось меньше ошибок. Солид? Чтобы меньше менять код и совершать меньше ошибок. Паттерны? Чтобы использовать готовые наработки и избегать лишних ошибок. git? Чтобы отслеживать изменения в проекте, избегать путаницы и совершать меньше ошибок.
это просто любопытство, такое не щитается
id юзера
id города
все вместе как большая строка - улица, дом и квартира
индекс отельно как int
Норм? Понятно, что улица и индекс могут повторятся, но если делать отдельно таблицу улиц и таблицу индексов, то вроде больше запросов в базу будет. Сначало надо будет поискать если такая улица в базе, а если нет, то еще и добавить.
Так и хранить, не занимайся хуйней. Если оно кроме как адрес для отправки не используется, то смысл городить огород? Ну город как отдельную колонку в той же таблице можно выделить для какой-то аналитики, но и то нинужно, скорее всего.
Погугли что такое ФИАС.
Вебпак нужен? scss или че-нить? Какая база для бекендера?
JsonResponse - это что в этом случае? класс, но какое определение если он задан через двоеточие у метода? Это же не "замыкание на класс", какое определение верное?
Ты основы сначала освой. Куда ты лезешь бля, раньше времени?
Это тип возвращаемого значения. Объект который вернется через return, будет иметь тип того JsonResponse класса/интерфеса
Судя по JsonResponse, ты уже взялся за фреймворк. Это очень рано. Чел выше прав. Изучи сначала основы. В шапке есть профиль на гитхаб codedocode, у него найдешь много полезных статей в разделе pasta. Узнай хотя бы как работает сервер, что такое HTTP-протокол, что такое HTTP-запрос и HTTP-ответ. Что такое json. Зачем вообще отдавать HTTP-ответ в формате json. Какие типы данных бывают в php. Что такое тайпхинтинг в php. О классах/интерфейсах как типах. Да, банально, если ты взялся за фреймворк, то какого хера не изучил даже основы? Классы Response и Request это база в фреймворке.
@
Садишься делать задачку, думая, что вот ну сейчас используешь знания на деле
@
Твоя задачка это простое CRUD-приложение без бизнес-логики
@
Безнадежно пытаешься выделить объекты предметной области, у которых могло бы найтись поведение, ведь Фаулер и Эванс говорят, что анемичная модель это говно.
>Объект который вернется через return, будет иметь тип того JsonResponse класса/интерфеса
спасибо
Нужно написать код для загрузки файла.
Я так понимаю, сценарий должен быть такой:
Принять файл, проверить первично (ну, например, что это не .htaccess), потом обезопасить файл (дать ему другое имя, например), потом сохранить в файловой системе сервера и в БД.
И вот я придумал несколько классов:
File, FileSecurityChecker, FileProtecter, FilesystemSaver, SaverInRelativeDataBase. На названия и последний класс забейте. Я вот что хотел спросить - как лучше, вынести обязанности по проверке на безопасность и соответствующие действия по очистке файла в отдельные те два класса или оставить эти обязанности у класса File? У класса File нет обязанностей, он вообще как анемичная модель. Следовательно, это не понизит степень зацепления. Функции по проверке и очистке файлов не понадобятся, скорее всего, где-то, кроме файлов. Значит и тут нет проблемы, что какой-нибудь компонент захотел бы использовать это. Что думаешь, анон?
- Меньше воды;
- Систематическая подача информации: причины проблемы, ее следствия и паттерн, который решает эту проблему;
- Примеры на php.
А тебе не приходило в голову сделать неймспейс File и не писать эту хуйню по сто раз в каждом классе?
Я на линуксе работаю, буквально 2 недели назад накатывал на новый ноут. Что у тебя не работает?
Пример подводных? Никаких проблем с симфони небыло никогда. Ты просто пишешь свой код и все.
Ну так напиши правильную архитектуру к моей ситуации, я буду мотать на ус. Было бы что дельное написать - ты бы написал, а так - лишь бы покалякать.
Причем здесь "архитектура" то блядь. Какая нахуй архитектруа если ты либу из трех классов пишешь? Ты хочешь чтобы я эту либу за тебя написал или че?
Ответь лучше на вопрос моего поста: обязанности по обеспечению безопасности при загрузке файла на сервер, лучше оставить в классе файла или вынести в отдельные классы?
>Ты хочешь чтобы я эту либу за тебя написал или че?
Я хочу, чтобы ты оправдал свой гонор.
Как ты заебал.
Так и быть, выделю тебе час моего времени. Кидай контакт для созвона, проведу тебе ликбез по загрузке файлов и проектированию библиотек.
Не я в целом про работу программиста. Просто у меня уже четвертая работа за год и чет везде потогонка. Первые две были битриксовыми галерами, там понятно. Третья была растущим стартапом, там я не прошел испыталку. Сейчас попал на проект нефтяной компании и тут людей "просят" в вызи поработать. Короче везде заеб. Мб у тебя или анонов по-другому?
А с симфони у меня была проблема с вот этой хуетой
https://www.doctrine-project.org/projects/doctrine-orm/en/3.2/reference/native-sql.html#resultsetmappingbuilder
я так и не смог разобраться как там маппинг работает при нативных запросах через доктрину
>Миллиард каких-то ньюансов, подводных и прочей хуйни
ВСЁ ПРОГРАММИРОВАНИЕ ТАКОЕ. Всё программирование - это архищепетильное ремесло. Если ты фронтэнд делаешь, там у каждой кнопочки надо прописать обводочку, закругленьице, фончик, анимации, отступы, потом проверить на десктопе, мобильнике, планшете. В каждом браузере протыкать. Продумать там где какие куки сохраняются, кто как логиниться, оптимизировать под поисковики, замутить аналитику и так далее.
А ещё некоторые спрашивают А ЧЁ ТАК ДОЛГО?
Бля тут надо триллион разных вещей продумать. И ты сидишь днями, неделями и месяцами всё это дрочишь.
Я не знаю чего вы ожидаете приходя в программирования
Тут нет никакой математики - это просто супер кропотливое ремесло и всё
Это какой-нибудь стоматолог зубик полчаса поковырял и десятку содрал или мастер по ноготочкам
А тут иногда чтобы даже простенькую страничку наверстать, надо сидеть карпеть хрен знает сколько
Плюс, всё постоянно меняется и нужно их учить, новые фреймворки чуть ли не каждые полгода-год выходят
>Хули тогда программистов так много развелось, если это явно не для всех?
Потому что всех только деньги интересуют. Из каждого утюга реклама срёт в мозг - вкатись и проста зарабатывай 300к! Если не вкатишься - мы вернём тебе деньги. В хорошие тучные годы можно было сидеть в Пензе или Сыктывкаре, работая при этом на Европку и Омерику. Поэтому сюда перебежали жадные до денег люди - всякие с заводов, с ипотеками, с тремя детьми, разные либерасты, мечтающие свалить по релокации. Им лень работать три смены на заводе, хочется быть кнопкодавом. Шоп просто кнопки жать и получать 300к. Хочется изи лайф, ни с чем не ебаться, а программирование как таковое их мало интересует.
>Просто у меня уже четвертая работа за год и чет везде потогонка.
Давно вкатился, как устроился на первую роботу без опыта?
Мне кажется, что книжки как раз пишут ради воды.
https://refactoring.guru/design-patterns/php
Чего ты удивлешься, что
>А ещё некоторые спрашивают А ЧЁ ТАК ДОЛГО?
Если сам пишешь
>Это какой-нибудь стоматолог зубик полчаса поковырял и десятку содрал или мастер по ноготочкам
Вот сейчас не к тебе конкретно адресовано будет, но надеюсь вы посмотрите на себя, начнете меняться и станете лучше. Иначе вырастите скуфами-мудаками.
>Давно вкатился, как устроился на первую роботу без опыта?
Ну вот чуть больше года. Вкатился отправив резюме в битриксовую галеру - никому не советую, учи что-нибудь нормальное сразу и крути опыт. Битрикс это опыт говна, впустое потраченное время и нервы.
>никому не советую, учи что-нибудь нормальное сразу и крути опыт. Битрикс это опыт говна, впустое потраченное время и нервы.
Не самое худшее что может быть.
Зато в резюме будет реальная строчка, с которой потом на тебя будут смотреть более лояльно.
А говно или нет битрикс, это просто инструмент который решает задачи, хотя и своеобразно.
Какая хуй разница. Просто ты нихуя не понимаешь где находишься, что делаешь и чем пользуешься. Да и вообще есть сомнения что ты кроме синтаксиса что-то о программировании знаешь.
Тому кто знает и умеет офк легче чем профану. Он просто берет и делает то что нужно, а не путается в собственном инструменте и не хуярит по пальцам себе и окружающим.
У Лаврика был курс, но он древний уже
Задавай как тебе удобно.
Если непонятно, значит нельзя.
А ты гуманитарий или технарь?
> Как понять что уже можно искать работу?
У тебя есть деньги? Если да - то не ищи. Если нет - то ищи. То что ты спрашиваешь, это признак того что у тебя всё в жизни нормально. Кредиторы не ломятся, свет не отключают, еды навалом.
Бедняга, вот что бывает когда нет битрикса.
Че ты несешь то блядь? Ну ты хоть минимально рефлексируешь че ты пишешь-то вообще? Вынести код из объекта можно только в другой объект. Че изменится если ты к названию этого нового объекта service или action припишешь? А типа если приписать PIZDA там мудя заколосятся или че?
Архитекторы блядь солевые, так и будете код по папочкам до бесконечности пекладывать.
бизнес-логику выносить в сервис
action если у тебя сервис разросся и его можно разбить на отдельные действия
А "бизнес-логика" это разве не набор действий? Да и вообще программа - это разве не набор действий?
В PHP мире концептуальная шизофрения.В PHP нет своих собстенных концепций и идеологий. Есть PSR но его очень мало. PSR не охватывает все аспекты написания кода на PHP. Часть пхпшников пишет совершенно идиотский спагетти код, другая часть устраивает каргокульт джавы. И все это в одном проекте...
Их тут двое таких. Не обращай внимания.
Да не в этом дело.
Челы просто сыпят бессмысленными определениями. Что вообще такое класс-сервис? Типа экшен выполняет, а сервис исполняет? Или блядь наоборот? Что конкретно это означает? Как отличить сервис от несервиса? Просто кто-то где-то что-то похожее говорил. Это просто иллюзия смысла. А на самом деле это то же самое что "бубубу".
Вот блядь реально заменить эти размытые термины, без конкретного смысла, но выглядящие как что-то осмысленное, на реально белиберду.
>Как лучше выносить "бубубу" из контроллера? Через классы-"пупупу" или классы-"лалала"?
>"бубубу" выносить в "пупупу"
>"лалала" если у тебя "пупупу" пропупался и его можно разбить на отдельные лалки
Получается же реально разговор двух шизов в палате. Только свой бессмысленный лепет они маскируют под что-то имеющее смысл. Но на деле ни они сами, ни их собеседники не могут объяснить что означают слова, которые они говорят. "Разросся". Схуяли он разросся? Как понять когда разросся, а когда еще не разросся? Почему именно когда разросся, а не когда похудел? Просто пизданул хуйню, которая в голову пришла. А тот, который спрашивал, и рад - это ж значит что и он не просто "блаблаба" пизданул, а поднял важнейую архитектурную проблему. Так и ходят по кругу в трех соснах как дебилы, "вкатываются" ебать.
Как подключится к удаленному репозиторию? SSH ключи добавлял, в гите залогонился, но каждый раз при пуше такое выдает.
Надо английский подучить получается.
>remote: Support for password authentication was removed on August 13, 2021.
>remote: Please see https://docs.github.com/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls
>Cloning with HTTPS URLs
>When you git clone, git fetch, git pull, or git push to a remote repository using HTTPS URLs on the command line, Git will ask for your GitHub username and password. When Git prompts you for your password, enter your personal access token.
>Cloning with SSH URLs
>When you git clone, git fetch, git pull, or git push to a remote repository using SSH URLs, you'll be prompted for a password and must provide your SSH key passphrase.
Это кому написано?
Ты не используешь ssh, у тебя http-урл в ориджине.
Поменяй на ssh
git remote set-url origin
Так было, есть и будет всегда в твоей карьере.
Наивно было бы думать, что ИТ - это кнопочки не напрягаясь нажимать.
С подключением!
О, ВЫ ТОЖЕ ФАНАТЫ ЗЕЛЕНОГО СЛОНИКА?
>для тебя наверно даже понятия модель и представление СЛОЖНА
Ну так что такое модель? И как у тебя выглядит объект "представления" если у тебя request-response "модель" (бля и тут модель) и ты объект response возвращаешь из контроллера?
Охуенный вопрос братан, точно стоило его задать сюда а не в гугл или hh
почему все?
челики как пилили прожекты на modx или wp так и пилят, а для них еще есть платные плагины и темы.
есть еще laravel, его тоже любят в вёб-студиях.
без битрикса да, никуда, магазинчики все дела.
Если за денежку, то можешь купить за 2-3к курс у Миши Рудрастых.
Или на бабочке утяни курс от Андрея Кудлай
за пределами россии его и не используют, кек
по сравнению с 2020 кол-во вакух в три раза сократилось
На пикче какой-то пиздец с бедрами, будто задница спереди...
>Почему я не могу вк онструкторе объявить свойства по умолчанию
Но ты можешь. Хз почему ты этого не делаешь. Вот тебе целых три способа как это можно сделать: https://3v4l.org/SAXOb
Другое дело что у тебя в коде явно происходит какая-то хуйня. Какая-то магия с вызовом родителя, какие-то вычисления. Главная, типичная ошибка новичка - это конечно наследование конструктора. Это прям классическая нуб трапа.
Прикол в том что у наследования есть правила. Наследуя функцию ты можешь делать с ней строго определенные вещи, попробуешь сделать какую-нибудь хуйню и сразу получишь ошибку https://3v4l.org/mGLhY Это дает некоторую предсказуемость, можно делать какие-то предположения и ожидать от наследников определенное поведение.
Но конструктор функция особенная. На неё никакие правила наследования не действуют, ей вообще похуй https://3v4l.org/GF12F , делай что хочешь. А это значит что использовать конструктор в структурировании кода и выстраивании иерархии нельзя категорически. Просто потому что у него нет никакого ожидаемого поведения. В любой момент кто-нибудь может изменить родительский конструктор - и будет прав, потому что не обязан знать что ты там без него нагородил.
Поэтому конструктор используется просто как способ положить готовые значения в переменные и, на крайний случай, убедиться что переданные данные не мусор. Все. Какие-то блядь вычисления, хуйня, малафья. Все это делается ПЕРЕД созданием объекта.
Ты снимаешь штаны перед тем как поссать, а не когда в них пришла первая порция мочи.
>В любой момент кто-нибудь может изменить родительский конструктор
А мне в некоторых моментах не хватает таких перегрузок для самописных функций. Например была функция FindA(), приходится придумывать новое название функции findAByX(int $x). В любом месте кроме этого класса, это выглядит очень наглядным - сразу видно что делает функция и чем отличается от других. Но внутри класса таких методов на целый свиток наберется и скролить оче неудобно бывает.
Такое делается легко и просто findA(Filter $filter): ?A И не надо ничего городить.
>В любом месте кроме этого класса, это выглядит очень наглядным
Нихуя не понял что ты пытался сказать. Как раз когда перегружаемые методы описаны подряд еще можно что-то понять. А когда они размазаны по иерархии начинается пиздец. Ага, тут так. И тут так. И вот тут так. Ну значит и там так. Делаем. А там нихуя не так. Там внезапная перегрузка.
Не знаю, у меня все равно требует передавать аргументы при создании нового объекта, хотя я в констурктор как только не пихал значения по умолчанию
>Не знаю, у меня все равно требует
Так ты код давай показывай https://3v4l.org/ Че-то слабо верится что у меня вот нихуя не требует, а ты такой особенный.
Что сделаешь? Ты же говоришь у тебя код не работает. Че ты блядь делать собрался?
Прошу подсказки. Я работаю ручным тестировщиком и на проекте дохуища апи и в ручную тестить -- это пиздец.
Рук сказал, что хочет, чтобы я внедрил автоматизацию на phpUnit, а он и коллеги (пхпшники) будут помогать.
Но у меня знания пыхи на уровне иф нэйм === "123" вывести "Хуй" ну и максимум какой-нибудь тернарный оператор. В ВУЗе когда-то прогал на всём, но тоже базово (лет 6 назад), про ООП слышал, но не знаю, в общем.
Короче пара вопросов:
1. Чтобы писать на пхпюнит модульные тесты, на каком уровне надо знать пыху?
2. Если в день тратить 3 часа на изучение (5 дней в неделю) пыхи, смогу ли за месяц уже начать писать первые автотесты?
Буду рад любым ответом. Спасибо!
>Чтобы писать на пхпюнит модульные тесты, на каком уровне надо знать пыху?
Чтоб написать всменяемыве тесты нужно писать код лучше, чем обычный код. Потому что это все еще тот самый код, который между прочим уже никто тестировать не будет + умение непосредственно тестировать.
Но ты не переживай. Это не твоя проблема, а твоего руководителя. Ставлю косарь, что этот пидорок через пару месяцев тесты тупо отключит. Потому что они реально начнут мешать, а переписывать их после тебя - проще заново начать.
Меня он не устраивает, так как не показывает все связи или может его можно настроить?
Вот пример кода
https://onlinephp.io/c/b22dd
На диаграмме же не видно, что классы AirLogistic и RoadLogistic создают объекты Truck и Plane.
Версия диаграмм в шторме урезанная, там тупо нет кнопки "показать зависимости". В принципе понятно почему - в пхп нет модульности, любой код можно вхуярить в любое место, удачи парсить это говно.
А со сторонними генераторами проблема в том что они все для старых версий, а чтобы проапгрейдить нужно какое-то невменяемое количество работы. Это не тот случай когда можно просто вечерком написать. Это нужны месяцы. И в тот момент когда ты догнал актуальную версию - хуяк вышла новая.
Вот единственное более-менее актуальное что я нашел https://github.com/smeghead/php-class-diagram Сразу видно масштаб проблемы: это надо поднимать сервачок, это не в один клик делается, это еще надо как-то результат прочитать.
Да и вообще глупая твоя затея с UML. Во первых, ты все делаешь жопой-наперед. Сначала строится диаграмма, а потом пишется код. А во вторых, как только диаграмма начнет усложняться ты резко перестанешь понимать на что ты смотришь, а главное нахуя. Вот посмотри на пикрелейтед. Хули ты тут понял? А если и понял, то нахуя тебе эта информация? Именно поэтому UML сейчас на задворках истории. Писать код по готовой чужой диаграмме никто не любит, а большие глобальные диаграммы в голову человека все равно не лезут и смысла от них - только красивая картинка.
При автоматической генерации получилось пару ошибок, я вручную поправил сгенерированный код.
Синтаксис PlantUml очень простой.
Получается, что можно автоматизировать процентов на 80, но нужно подгонять.
Вот так утилита создает скрипт для *.puml:
vendor/bin/php-class-diagram --class-diagram path/to/files
Скрипт отображается плагином PlantUml.
>Сначала строится диаграмма, а потом пишется код.
Я учу шаблоны и мне с диаграммами проще запоминать и понимать.
Рисовать диаграммы пробовал разными способами и все очень нудно.
Этот пока оптимальный. Спасибо за совет.
Потому что в русский языка используются фигурные кавычки, отдельно левые и правые.
ну так как правильно изучатьто? мне похуйна тесты закроют их или нет, просто чем быстрее внедрю их, даже если они хуевые будут, мне +35% к зп дадут точно.
>как правильно изучать
>мне похуй
Ну ты и кадр. Если похуй, то нахуя че-то там изучать? Открой первое же видео на ютабе "как писать тесты на пхп" и хуярь. Тебе же на результат поебать.
Какое нахуй "правильно"? Хуярь как хуярится и все. Отдуваться-то все равно будет долбоеб, который тебе это доверил. А к тому моменту когда выяснится что там за говно, уже и ты все замазанные в закат съебете с премиями и бонусами.
Ебать ты тупой. Ну просто как полено. Признавайся, тебе кампудахтер мама включает?
Просто признай что ты дебиан и всё
https://github.com/casshh87/Vektor/tree/main
> А к тому моменту когда выяснится что там за говно, уже и ты все замазанные в закат съебете с премиями и бонусами.
Бля это красиво, да так в любой конторе, в целом.
Но всё же. Мне для себя хочется некую базу, чтобы понимать ООП в пхп хотя бы.
Разраб посоветовал пхп 8.3 учить, а книгу сказал, что забыл какую. Другой посоветовал Кузнецова и Симдянова пхп 7.
Сам же я хочу Котерова и Симдянова пхп 8 книжку осиить.
Я в целом понимаю, какие типы есть, как работают функции, условия, циклы (базовая база прям), но не понимаю их нюансов и самостоятельно кодить пока проблемно. На уровне чтения более-менее понятно.
По поводу автотестов да, а что ты хотел. 100к зп всего у меня, делать мне нехуй ещё прям от а до я выстраивать процесс автотестов тут. Тем более юнит-тестов (их должны разрабы ебашить).
Пчел, от того что тебе не нравится ответ ничего не поменяется.
Люди по нескольку лет на пхп пишут и все равно не могут нормальный тест высрать. И это они еще худо-бедно понимают что за хуйню написали, потому что это ИХ код. И то пройдет пару месяцев и они перестанут понимать, и код и тесты.
А писать тесты к ЧУЖОМУ коду, который ты нихуя не понимаешь, на языке на котором ты не пишешь - это заранее провальная идея. А код будет максимально непонятным. Потому что даже тот кто его написал нихуя его не понимает. И это еще если код вообще тестируем. На пхп принято писать парашу, которую в принципе протестировать нельзя. Вон в посте выше, паренек взял и нахуярил статики, ну чисто чтобы было, по настроению. А как её тестировать? Да никак блядь.
Про понимание ооп насмешил пиздец. Кто его блядь понимает-то? Ты думаешь тот кто на этом ебучем языке пишет хоть на миллиметр понимает ооп? Да хуй там. На двух пхп макак три "архитектуры". Это наши мальчики учат кента бека понимать тдд, а мартина что такое на самом деле "сингл респонсибилити".
Короче. Ответ будет тот же самый. Хороших тестов у тебя не получится. Потому что мусор на входе = мусор на выходе. Ты на эти тесты хоть самого Дейкстру посади, и тот застрелится нахуй.
Твой единственный вариант: дать говна, взять бабки и съебаться до разбора полетов. Засудить тебя не смогут, потому что ты все спихнешь на руководителя - его идея, он одобрял, он принимал работу. И хули он скажет? Не принимал? А кто тебя к коду подпустил? Виноват. Не одобрял? Откуда тогда это в проде? Виноват. Не его идея? А как это доказать?
Вот и все.
>А писать тесты к ЧУЖОМУ коду
Мне надо автоматизировать апи. У нас их 4 штуки, по ним есть документация.
Мне по сути надо дергать метод и передавать какие-то значения. Мне прошлый разраю показал пример, я по нему прогнал все методы (заняло это максимум часа три).
Тест одного метода это передать на вход токен и логин, например, и посмотреть заказы по этому логину. Всё. И вот такие методы поргонять надо. Я пока ещё хуево в этом ориентируюсь, моэтому, скорее всего, хуево объяснил, но надеюсь, суть ты понял.
>Про понимание ооп насмешил пиздец
Да многие его так-то понимают. Может быть на базовом уровне, но всё же. Тут я не могу продолжать беседу, т.к. не шарю
>Засудить тебя не смогут
Вот этого вообще не боюсь. Никогда об этом даже не думал. Максимум че смогут сделать, это уволить, но и то я по собственному увольняться не буду. Если будут грозиться увольнением по статье - тоже хуй уволят. Мне предложили попробовать. Я предупредил, что юнит тесты пишут разрабы и в пыхе я не шарю. Мне одобрили такой вариант, что я буду пробовать. В конечном итоге если уволят, то пару окладов дадут, но до этого не дойдёт.
Я уже параллельно смотрю вакахи от +50% к своей зп и меня зовут на собесы активно, так что если че съебу в закат и всё.
Распизделся я что-то.
У меня руководитель в целом слабый очень. Он шарит, да, но по нему видно, что он слабоват.
>Мне надо автоматизировать апи
А какая нахуй разница на каком языке бекэнд если ты тестируешь апи? Ну и тестируй. Открываешь postman и хуяришь, причем тут язык вообще? Причем тут ооп? Для этого вооще никакого языка знать не надо.
Вообще ты в показаниях путаешься, тут ты сам написал: >>229272
>Рук сказал, что хочет, чтобы я внедрил автоматизацию на phpUnit, а он и коллеги (пхпшники) будут помогать.
На это тебе и был ответ. МАКСИМАЛЬНО ТУПАЯ ИДЕЯ. Тво "рук" либо тотальный кретин, либо хитрожопая скотина, которая с этого поимеет какой-то гешефт.
Про увольнение какую-то хуйню написал. Это твоя первая работа? Если захотят уволить - уволят. Пришить несоответствие в IT - как нехуй делать. Регламента нет, проверять "соответствие" будут те кто хочет тебя выпнуть. И меньше всего тебе надо какой-то публично проверяемой хуйни типа суда или выговора. Я не имею ввиду суд из-за того что тебя на зп кинули или чего-то подобного, такое говно офк надо давить. Я имею ввиду именно суд по оспариванию увольнения. Вот такая хуйня будущего работодателя врятли обрадует. А пробивается все это на раз-два, потому в сб бывшие мусора/фэбосы и сидят.
А главное - нахуя это тебе надо? Хмм. Что же делать? Свалить прямо сейчас и в течении недели запрыгнуть на повышенную зп? Или пару месяцев бурундучать, пытаясь не опоздать ни на минуту, чтобы не поймать выговор, выебав все нервы себе и окружающим, с перспективой лишних отказов в будущем? Про оклады тоже все просто. В договре нет? Если не указано - не ебет что сказано, готовься не получить нихуя.
>Про увольнение какую-то хуйню написал.
Нет
>пытаясь не опоздать ни на минуту, чтобы не поймать выговор, выебав все нервы себе и окружающим, с перспективой лишних отказов в будущем? Про оклады тоже все просто. В договре нет? Если не указано - не ебет что сказано, готовься не получить нихуя.
С этим всё ок. ПРихожу когда захочу, главное делать работу и всё.
>>231333
>>231060
>>229272
Прочти уже книгу "Automating API delivery. APIOps with OpenAPI". Там всё твёрда и чотка написано, как тестировать апи, как деплоить апи, и так далее. Ты щас пытаешься выдумать свои какие-то кривые велосипеды с phpunit, вместо того чтобы послушать более умных людей и сделать качественно.
Есть стандарт. Он называется ОПЕН АПИ. Он блять работает для всех языков - для джавы, для питона, для пхп, для тайпскрипта. https://www.openapis.org/ Не надо ничего выдумывать. Есть уже готовые генераторы https://openapi-generator.tech/ Бери и генерируй
>С этим всё ок. ПРихожу когда захочу, главное делать работу и всё.
Ноу щит, гений. Речь шла о том, когда ты откажешься увольняться и начнешь вымогать у работодателя оклады.
А че краб, у тебя кол-во вакансий на пыхе в три раза сократилось, а джунов на рынке как говна. Ещё и на симфони, на котором в снг вообще редко пишут, а если и пишут то крупные проекты где вкатуны нахуй не нужны. Ещё бы в Руби вкатывались
Нахуй сходил уже?
Да идите нахуй я и там и там уже спросил
272x480, 1:13
Нахуй ты лезешь? Вот тебе пикрелейтед, архитектура типичного битрикс сблева, с комментариями одного из авторов.
СХОДИ САМ И НАМ ПОТОМ РАССКАЖЕШЬ. Устройся и расскажешь трудно было или легко. Много платили или мало. Я давно уже из PHP съебал. Мне ничего в этом языке не нравится, я просто блять ненавижу пхп. Единственный его плюс - это много работы. Всё.
Много на пыхе работал? Тяжело перекатывался на другой язык? С одной стороны опыт на другом языке не роляет, с другой, ты уже не обычный вкатун и у тебя есть опыт коммерческой разработки, это уже ставит тебя выше 99% вкатунов
Где-то с 2014-го. Свалил пару лет назад. Потому что никому ничё не надо. Интересных проектов нет. Развития нет. Супер высокой зарплаты тоже нет. На другой язык перекат это тоже самое что вкат с нуля. Никакие регалии не засчитываются. Они обычно говорят ну это понятно что вы на пхп работали. А вот конкретно на языкнейм у вас сколько лет опыта? Год. Ага, так и запишем год. Извините, нам нужны опытные программисты.
Понятно, куда вкатился? Опыт не крутил? А то говорят, что без опыта даже на собес не зовут
Да вордпресс на фрилансе. Ты не слышишь меня. Я говорю, работа говно а ты продолжаешь твердить про трудоустройство. Какая разница зовут или нет. Меня несколько раз приглашали на работу. Но чё толку-то от этого. От того что тебе предложили вакансию дворника, ты чё от этого счастливее и богаче стал? Я открываю требования, там стоит jquery, gulp, modx, ещё чето-то там. Пишу им - у вас легаси. Потом до меня допёрло, что всё пхп везде это сплошное легаси. Там везде некротехнологии двухтысячных годов. Везде каждый сраный слайдер на каком-нибудь жиквери висит. ЗП выше 150к в похапэ редко встречается и туда хуй устроишься. Полезного применения у похапэ вне веба нет никакого. Если на питоне например можно тренировать нейронки, писать сайты, писать автоматизацию. На сишарпе можно сайты писать, десктоп приложения, игры. То тут только говносайты и всё.
А где не легаси? Кабан будет каждый год приложение переписывать, чтобы тебе нескучно, модно и молодежно было? Легаси это хлеб. Хоть пыху с говно Yii возьми, хоть питон с древней джангой, хоть сишорп с винформами.
Ну блять, да, богаче и счастливей, лучше пхп легаси разгребать за 150к, чем гайки за 40к крутить, а то что там нет модных молодежных хайповых технологий, ну извините, неохота конкурировать с тысячей вкатунов на вакансию и крутить опыт, да и легаси везде есть
По пыхе вот лучшие курсы, можно учиться по подписке за 4к в месяц. Если напишешь в техпод, они расскажут как можно пройти всю профессию по подписке, там и ооп и все что хош
https://ru.hexlet.io/programs/php-phpunit-testing
https://ru.hexlet.io/programs/php-oop
Да, самые дефицитный кадры после 1с-ников. У меня знакомый вот такую хуйню составлял пару месяцев назад. На симфони я нашел работу, даже не зная базовых вещей по симфе. Меня конечно пизданули с испыталки, но новую работу я нашел через 2 дня
>На симфони я нашел работу, даже не зная базовых вещей по симфе. Меня конечно пизданули с испыталки, но новую работу я нашел через 2 дня
Удаленка или офис?
На лару или симфони перекачусь, если сходу на эти фреймы не получится, битрикс это если совсем худо будет, да и пока не попробую не узнаю, может понравится, в любом случае, для меня главное в люди выбраться, тяга к самореализации уже по башке лупит, не могу жить спокойно пока не уйду с дно работ, в общем дальше видно будет, это проблема будущего меня, а для нынешнего важно закрыть эту потребность, не знаю как объяснить, это мои какие-то загоны, комплексы, я боюсь представить себя 30 или 40 летнего, метающегося по дно работам, да и в битриксе или даже 1с не вижу ничего страшного, это просто работа, которую нужно выполнить, к тому же пока сам не попробую не узнаю
А почему у тебя в таблице на 6+ лет опыта такое большое соотношение резюме/вакансии? Да и в целом резюме больше, чем на мидлов, я думал наоборот, среди сеньоров с большим стажем нехватка специалистов, неужели это волки постарались?
>Кек, вакансий на симфони с зп 200-300к жопой жуй
Для людей с опытом, а не залетного дебила который даже базовых вещей по симфе не знает
>>233415
Развития нет никакого. Прогресс обходит пхп стороной. Как 10-20 лет назад было всё тоже самое, то и ещё 30 лет будет всё тоже самое. Где не легаси? Отвечаю: в стартапах. Но ни один нормальный стартап не использует пхп. Он не нужен и банкам, клиентура у пхп - это ипэшники, мелкий бизнес, перевозчики/логистические компании, интернет-магазины, депутаты, коммунальные службы. Всё. Везде где деньги есть, в больших корпорациях а-ля гугл, амазон, и т.д. Там это не используется. А используется там где денег мало, то есть говнолендинги, говномагазины купи-продай, всё на монолитах естественно, без стандартов, без ci/cd и проч.
Ну дак я накрутил опыта, в чем проблема-то? На собесах иногда спрашивают не про симфони, а все что около - бд, ооп, солид, решить простенькую задачку, набросать sql несложный - чтобы на эти вопросы отвечать вообще не нужен опыт реальной разработки.
>Ну дак я накрутил опыта, в чем проблема-то?
Ну вот. Сразу бы вот так написал. Не у всех есть такая наглость как у тебя чтобы вот так прямо пиздеть людям в глаза. И ведь это все равно рано или поздно вскроется и тебя с позором выпнут на улицу
Ладно, спасибо тебе за честный отзыв, подумаю над твоими словами, поковыряюсь в парочке других языков, в шарпе, жаве, что больше понравится, туда и начну вкат, если что накручу опыт, поебать, не мы такие, рынок такой, битрикс и 1с все равно никуда не денутся
>за сколько вы осилил вёрстку?
Я чё блять считал чтоли?)))) Ты вопросы тупые задаёшь. К тому же вёрстка постоянно меняется.
>не рисовать хуйню
Не выёбывайся и просто возьми готовые компоненты. Вот например https://react-spectrum.adobe.com https://core.clarity.design/ Зачем мучаться рисовать кривые блять компоненты, если есть готовое от топовых компаний
Причем здесь твои говно компоненты, если чел написал, что вкатывается в дизайн, но хочет верстку попутно освоить?
Да, вкатываюсь в дизайн интерфейсов (нравится), просто хочу развиваться дальше. Вопрос: куда дизайнеру будет профитней расти дальше, как я понимаю, вёрстка будет плюсом, но тред толком не читал, начал сразу с глупых вопросов, как положено. Может здесь есть анон, который тоже начинал с веб-диза, потом начал изучать языки программирования (какие? для чего?).
Верстальщик это самая забитая сутулая собака в тиме. Им платят меньше всех, они сидят и мечтают вкатиться во вротенд.
Манямирок. Дизайнер делает несколько недель макет одной странички и только под десктоп, а тебе потом надо сверстать целый сайт с нее еще для планшетов, мобилок, личный кабинет скучей контролов, которых в дизайне за пару дней. Это не просто так из галеры в галеру повторялось...
>Дизайнер делает несколько недель макет одной странички
>тебе потом надо сверстать целый сайт с нее еще
Что за хуйню я читаю.
Верстальщик верстает то что ему надизайнили. Надизайнили страничку - наверстает страничку.
Какой нахуй "целый сайт"? Верстка идет строго по макету. Если верстальщик хоть на пиксель что-то свое наколохозит, то дизайнер на ультразвук переходит сразу. И какая нахуй разница личный кабинет или хуичный? То как выглядят контролы решает дизайнер - это его работа. Если тебя как верстальщика заставляли это делать, то поздравляю - гоя прогрели на бабки. Заплатили за работу дизайнера зарплатой верстальщика.
>Это не просто так из галеры в галеру повторялось...
Ебать ты лох.
нет ты
Ты писал, что диз
>самая забитая сутулая собака в тиме
Ты хоть одно дизайнера видел чтобы в штате? Кабан не дурак дизайнера нанимать, чтобы тот раз в пол года дизайны мастерил.
А бля.. ты писал проверстальшика...
Нахуй ты про верстальшика написал, если речь шла про то что чел учит дизайн? Верстальшиков сейчас вообще нигде нет, может быть только в больших студиях, которые клепают мелкие сайты на потоке.
>Вопрос: куда дизайнеру будет профитней расти дальше, как я понимаю, вёрстка
Ты с утра уже накатил, стекломойный слепошарый долбоеб?
Мало того что ты лезешь, хотя написано не тебе. Так ты, пост на который пытаешься высрать ответ, прочитать не в состоянии.
Лично тебе написано?
ЗЫ
1) Дизайнеру учить верстку смысла нет. Верстать будет фронтендомакака как ему надо.
2) Надо заниматься одним.
3) Веб дизайнер может изучить верстку, жс, основы пыхи и делать настраиваемые темы для вордпреса, чтобы на стоки их выкладывать. Но врядли можно назвать это перспективой...
Так фронтенд это и есть работа с "ебалом сайта"? Это разве не про верстальщика и дизайнера?
>Фронтенд-разработчик отвечает за пользовательский интерфейс и взаимодействие пользователей с веб-приложением. Его задачи включают:
Создание визуального интерфейса: Разработка и реализация дизайна страниц, который видят пользователи. Это включает работу с HTML, CSS и JavaScript. (GPT)
С дизайнером похуй, он ко всему этому относится, как и медсестра к врачам, но верстальщик разве не является фронтенд-разрабочиком?
Просто видел людей в интернетах, у которых в услугах было сказано, что они делают всё сразу, от разработки дизайна до натягивания этого дизайна на сайт. Хочу, наверное, также, чтобы не сдохнуть на зарплате диза. С дизайном уже разобрался, а вот с программированием практически не знаком, отсюда такие вопросы бейте, но не обссывайте.
Я >>235589
Уже сто лет нет никаких верстальщиков. Они были когда сайты верстали на флоатах и инлайн блоках. Сейчас в флексбоксами и гридами любая собака сверстает.
То есть, верстка сейчас проходит в два клика и верстальщики стали не нужны?
>Сейчас в флексбоксами и гридами любая собака сверстает
Погуглю, спасибо.
Ну ты побольше жпт говна читай, образовывайся.
"Фронтенд" означает исключительно джаваскрипт макаку. В любой маломальски крупной компании есть четкое разделение на "программистов" и "не программистов". Дизайнеры в компании работают над вообще всем дизайном. Никто не будет выделять в отдельную команду своего дизайнера - это дорого. То же самое с тестировщиками. В 99% случаев есть отдел дизайна, есть отдел тестирования и есть несколько комад из программистов: 2 фротендера и 3 бэкэндера или наоборот. Отдела верстки нет. А верстать надо. Вот и нанимается какой-то полупокер, который то-ли в команде, то ли нет, но дизайнеры его в свой круг точно не пустят - плебс.
>Сейчас в флексбоксами и гридами любая собака сверстает.
И именно поэтому верстать будет чел, которому платят 300к в месяц? Открою секрет, только ты никому не рассказывай: нормальному программисту эта верстка нахуй не нужна. Ну не будет программист верстать. Ему че делать больше нехуй? Может еще полы помыть? Зп то та же хули б нет?
>Почему говорят "с помощью интерфейса (сигнатуры публичных методов) можно защитить клиентский код от изменений"
Потому что ты с какого-то хуя отождествляешь два совершенно разных события: "изменение реализации" и "изменение контраката (интерфейса)". Какая разница ПОЧЕМУ тебе нужно изменить интерфейс, важно что при это переписать придется вообще все. Все имплементации, всех клиентов. Такие масштабные изменения это уже даже не рефакторинг - это буквально создание нового модуля, с новыми правилами, на месте старого.
А чтобы держать под контролем изменения в чужих модулях, создается ACL модуль, который закрывает чужие мутные и жидкие интерфейсы, нашим расово верным жестким интефейсом https://miro.com/app/board/uXjVKsKQKyY=/?share_link_id=710900735461
>>242007
Сделай эксперимент. Запости этот вопрос в джава и шарп тред и сравни ответы. Потом расскажешь.
Слышал, что есть возможность засунуть php-код в файл с расширением для изображений.
Если я по URL-обращусь к этому файлу, то отработает php-код в ней?
Или если браузер сделает GET-запрос к серверу для загрузки этой картинки на страницу, то также отработает php-код в ней?
Пчел, поверь, оно тебе не надо.
Если дегенераты записали в плюсы знание алгоритмов на пхп и вышку, то это охуительный звоночек что перед тобой ебанашки и неадекваты. А тут еще и записали в плюсы ЗНАНИЕ РЕКЛАМНЫХ ТЕХНОЛОГИЙ блядь. Ну какой долбоеб такое напишет? Какая им разница что ты там про рекламу знаешь? У них че блядь комптентных рекламщиков нет? Типа пхп макака будет поучать бизнес как рекламу продавать, прод переписывать? Вопросы без ответов.
Короче залупа. Очередной "фуллстек" на кипр. Очевиднейший наеб на даллары.
Да, такая уязвимость есть. Но твой вопрос не понимаю. Вообще она довольно всратая. Гуглится по названию Remote Code Execution.
Она всегда разная
https://youtu.be/XyE6yTDFQ68
>А тут еще и записали в плюсы ЗНАНИЕ РЕКЛАМНЫХ ТЕХНОЛОГИЙ блядь.
Если берешь человека на сеньерскую должность, а не тупо исполнителя, то не вижу причин не указывать. Значит им нужен человек, который будет понимать, чего от него хотят и который скажет что и как можно реализовать. Это же плюс, разве нет?
>У них че блядь комптентных рекламщиков нет?
Видимо нет.
>Если берешь человека на сеньерскую должность, а не тупо исполнителя
Сразу видно вкатуна, скакими-то фантазиями о сеньрскости.
Пчел, нет ничего хуже чем некомпетентное руководство. Ни один манагер не даст себя поучать программисту. Как писать код - пожалуйста, твое дело. А вот за то как вести бизнес ему бабки платят, он за них будет глотки грызть. Собственно этим манагеры и занимаются - грызут друг другу глотки за ресурс.
Или ты думал что сеньор - это умывальников начальник и мочалок командир? Программирование - это сервис, сфера услуг. IT по определению в подчинении. Разве что сам бизнес - это продажа IT услуг, хотя и там тебе все равно будут говорить что делать, а не спрашивать что делать.
>Видимо нет.
О том и речь. Бабки откуда, если самый компетентный в бизнесе компании сотрудник на двачах сидит, а не у них в офисе? Это очевидный развод лохов, таких вакансий с "кипра" куча, и все на фуллстек долбоебов, готовых создать бизнес под ключ. Только с деньгами в этом месяце проблема... и в следующем... а на третий месяц чел из телеги пропадает.
Не зависимо от того 1000 человек в компании работает или 10, мы всегда вместе на общем мите обсуждали поставленные задачи по новым фичам. Менеджер рассказывал, что хочет заказчик, смотрел какие технологии нужно применить и как это работает у конкурентов. Мы же со своей стороны говорили как можно это реализовать и сколько времени на это понадобится. В компании из 10 человек, где я был в курсе работы всей системы, я сам учствовал в разбиении задачи на подзадачи и планированием сроков. В копании побольше этим занимались сеньеры (программситы 4 грейда и выше).
>Или ты думал что сеньор - это умывальников начальник и мочалок командир?
Так и было.
>обсуждали поставленные задачи по новым фичам
О чем я и говорил. Бизнес ставит задачи - ты выполняешь. Если вдруг окажется что ты разбираешься в бизнесе лучше, чем те кто ставит тебе задачи, то ты или будешь послан нахуй или вступишь в жесткую схватку за жизнь в этой компании. Нахуй этот бой кому обосрался? Проще с некомпетеными долбоебами не связываться.
>Менеджер рассказывал, что хочет заказчик, смотрел какие технологии нужно применить и как это работает у конкурентов
Это даже более печальная ситуация, чем описал я. Нормальный CTO манагеров к разработке на километр не подпустит, а то те программистов даже срать под их надзором заставят. Менеджмент как газ - занимает весь доступный объем.
>Так и было.
Ну значит прогревали ваших сеньоров на бабосики, заставляли выполнять работу тимлида за зп сеньора. Зато "4 грейда и выше". Служи дурачок - получишь значок.
Откликнулся на вакансию "младший бэк", мне скинули тест.
Как вам вопросы?
of course, все это спокойно можно нагуглить, но, блять, рили? спрашивать с джуна про то, что делать если высокая нагрузка на микросервисы или чем отличается архитектуры? Это вам, блять, не вопросы про то, чем отличается абстрактный класс от интерфейса!
>Откликнулся на вакансию "младший бэк", мне скинули тест.
>Как вам вопросы?
Да он никакой не младший. Это кликбейт, чтобы собрать побольше откликов. К чему угодно можно дописать в заголовке junior/младший и вакансия автоматически соберёт х10 откликов. По факту, это обычный разработчик с низкой зарплатой и всё.
>спрашивать с джуна
Вы дальше заголовка не читаете что ли? Надо требования смотреть. Кто угодно может что угодно написать. Я ща пойду запощу синьор хтмл-верстальщик. Или напишу вакансию, перечислю 50 технологий, поставлю минимум 6 лет опыта и скажу что это джуниор вакансия. А хуле, я так вижу. А ты попробуй докажи, что это не джуниор.
Это также тупо как искать на маркетплейсе по словам "халявный iphone" или "дешёвый adidas". Джуниорность подразумевается из контекста, между строк, это не буквально. Не нужно вбивать фразу "джуниор" в поиск. Надо читать описание.
Я расцениваю его, как мини-портфолио. А так же, как обучение по написанию хоть чего-нибудь. Это конечно не тот самый опыт, что любят требовать работодатели, но могут ли они расценивать за "опыт", то что у тебя на гите? Они вообще смотрят у джунов его?
Портфолио это не сурсы в гите, а работающий проект, желательно с хорошим онбордингом, чтобы даже херочке было видно куда тыкать. Для портфелио нужно чтобы проект был БОХАТЫЙ.
Но это работает только в говноконторы.
>Есть ли смысл иметь и вести гит с пет-проектами для начала поиска работы?
Писать пет проекты надо постоянно.
А вот показывать их имеет если там актуальный код, который будущий работодатель может имаджинировать у себя в проде.
Если там леденящий душу пиздец, наподобии этого >>231200 то лучше его держать подальше от своего резюме.
>Аноны, привет, такой вопрос. Есть ли смысл иметь и вести гит с пет-проектами для начала поиска работы?
Нет. Это обычная показуха. Типа как когда Путин приезжает и нужно срочно покрасить траву, уложить асфальт. Моё личное мнение - работа, чтобы кому-то что-то показать не нужна ни в каком виде.
>Я расцениваю его, как мини-портфолио
Можно поработать над брендингом, сделать красивый сайт с описанием услуг или вести блог, переводить англоязычные статьи. От этого и то больше пользы будет.
>А так же, как обучение по написанию хоть чего-нибудь
Не аргумент. Можно обучаться и делать что-то осмысленное одновременно.
>не тот самый опыт, что любят требовать работодатели
А ты никак не можешь сначала получить опыт. Если только прыгнешь на машине времени в будущее. Все начинают с нуля.
>Они вообще смотрят у джунов его?
Кто-то смотрит, кто-то не смотрит. Все люди разные. У всех характер разный. У кого-то одна задача, у кого-то другая.
>>243805
>>243809
Спасибо за развернутые ответы.
Учитывая, что опыта нет, то в любом случае будет - "леденящий душу пиздец". И исходя из этого, лучшее решение - это сжечь свой реп.
>Можно обучаться и делать что-то осмысленное одновременно.
Интересная и правильная мысль, но сколько это займет времени, только один Бог знает.
В общем из всего, что прочел, я только укрепил мысль "пройти собесы и чекнуть, что вообще от тебя будут требовать".
>что вообще от тебя будут требовать
Это какое-то ситуативное мышление. Начнём с того, что у программиста должен быть свой БРЕНД. Бренд складывается из публичного образа, взять того же Немчинского https://nemchinskiy.me/ Он выступает на конференциях, пишет статьи, ведёт ютуб. Можно сделать типа персонального блога. Вася-пупкин.com. Наполнить статьями, добавить услуги и давать ссылку работодателям. Здравствуйте, я Вася Пупкин, веб-разработчик. Вот мой сайт, там подробно рассказано чем я занимаюсь. Буду рад сотрудничеству с вашей компанией.
А так, просто ходить, чё-то делать и спрашивать я вот сделал хуйнянейм, вам нравится!? Это на мой взгляд тупо.
А что если под "хуйнянейм", будет вот так? :
- Здесь я реализовал такую хуйню
- Здесь есть такая залупа
- Изучил это, подключил это
Ебать насрано в башке. Какой нахуй "бренд"? Обсмотрелся инфоцига и блохеров и совсем ебанулся? Вся эта возня делается как раз чтобы больше код не писать и на дядю не пахать.
>А так, просто ходить, чё-то делать и спрашивать я вот сделал хуйнянейм, вам нравится!? Это на мой взгляд тупо.
Важно не что сделано, а как сделано. МАНЕРА ПИСЬМА важна. ИДИОМАТИЧНОСТЬ. Я выше приводил пример неактуального кода. Опытный человек с первого взгляда может сказать: бля, ну так не пишут - это хуйня.
Да это обычная показуха, имитация бурной рабочей деятельности. Ты просто имитируешь какой ты типа охуенный работник. Одно дело разрабатывать чтобы понравится работодателю, а другое решать свои насущные проблемы. Мне нужно например, анализировать свои инвестиции. Хоп-хоп, сделал графики, то сё пятое десятое. Или я захотел сделать умный скворечник. Купил teensy, симку, камеру, повесил, фотографируешь птиц.
Разница в том, что от твоих проектов никому ни жарко ни холодно. Ни работодателю, ни тебе, ни другим. Я бы понял, если бы ты связался с какой-нибудь благотворительной организацией, допустим "помощь детям больным пиздецой" и предложил им сделать сайт бесплатно. Тогда мир стал бы хоть чуточку лучше.
Я уж не говорю про то, что то время, которые вы тратите на бесполезные, никому не нужные проекты, можно было потратить на какой-нибудь стартап (какая разница на что тратить время). А что толку от ещё одного форума/todo/магазина/двача, их уже в сети миллион готовых, будет миллион первый.
Начал откликаться на hh.ru - почти на все отклики, которые я отправил, получил ответ. Даже если тебя не хотят брать, все равно приходит письмо "Извините так и так". Приятно.
Допустим, я добавляю в него метод СохранитьВБД(), который в теле делегирует другому объекту, представляющему таблицу, создание записи в БД. Из-за этого метода нарушается SRP? Класс изначально не связан с логикой взаимодействия с БД.
Как же этот каргокульт у пыхеров достал...
Нет, не нарушается, если объект для сохранения в бд прокидываешь через конструктор класса. Кури ACWA Book Аделя Ф.
>я добавляю в класс метод
>читай «Архитектура сложных веб-приложений. С примерами на Laravel». Вторая редакция.
А че не Ницше, Канта? Может Мейера с его талмудом по ооп на 1200 страниц?
>>245281
Это буквально пикрелейтед: квадратики к квадратикам, кружочки к кружочкам. Вы без книги по АРХИТЕКТУРЕ СЛОЖНЫХ ПРИЛОЖЕНИЙ блядь не в состоянии разные функции по разным дырочкам распихать?
Запутался в понятиях Entity и Model в рамках MVC.
У нас в проекте есть Entity/Product. Тут есть метод, который добавляет определенные фильтры для запроса в БД.
В данном методе идет запрос в БД для получения складов, которые доступны пользователю для получения товара, и на основе этих складов дополняется фильтр для основного запроса получения товаров.
Я не совсем понимаю почему этот метод был добавлен в Entity/Product. Да, этот метод относится к товару, но разве метод, который насыщает параметры для запроса не должен находится в моделе?
И второй вопрос. Как я говорил, в данном методе происходит запрос для получения доступных складов. Стоит ли этот запрос перенести в модель DeliveryArea или нет?
В "рамках" MVC нет никаких Entity. А Model в MVC это вся бизнес логика. А про базу тут вообще ничего не написано.
Ну давай как 14 летнему зумеру объясню.
У тебя есть МОДЕЛЬ самолета, в масштабе 1 к 48. Почти как настоящая, может даже летает. Ты ставишь эту модель на стол, включаешь камеру и подрубаешь стрим на твиче. Люди смотрят (нет) и донатят тебе таски: закрылки на взлет, убрать шасси и всякое подобное.
Ты в этой ситуации КОНТРОЛЛЕР, модель самолета - это (внезапно) МОДЕЛЬ, а исходящий видеопоток это ВЬЮ. Ты (КОНТРОЛЛЕР) транслирешь донаты (ЗАПРОСЫ) в действия с самолетом (МОДЕЛЬЮ), и управляешь стримом (ВЬЮ) - ракурс камеры, качество, фильтры, реклама.
Так где тут база вообще?
Ну, представим что наступил вечер, ты остановил стрим и убрал самолет в КОРОБКУ. Как это влияет на процесс стрима? А как влияет на процесс стрима то что ты убрал самолет не в коробку, а в ЧЕМОДАН? Да никак блядь. В самолете нет никакой кнопки для самоубирания в коробку, самолет не возит с собой коробку, в котрой он хранится. Ему совершенно похуй куда его положат. Это сама коробка должна быть такой, чтобы вместить самолет и такой чтобы этот самолет можно было оттуда достать.
>$planeStorage->store(ToyPlane $plane): void
>$planeStorage->get(): ToyPlane
А теперь представим что для одного из стримов ты достал из ЯЩИКА игрушечного пилота для самолета. Ебет ли при этом самолет как и откуда ты достал пилота? Ебет ли донатеров как там у тебя хранятся твои самолеты и пилоты? Разумеется нет, это никак не связано. А снаружи вообще никакого хранилища не видно - самолет всегда стоит на столе.
Так нахуя лепить хранилище хуй пойми куда? Нахуя вся эта путаница с методами нужна если можно просто сделать коробку, в которую ты кладешь свою модель и из которой её потом достаешь?
MVC - это очень простой паттерн на самом деле.
Есть вью - хуйня, которая что-то показывает. Например, винда рисует кнопки. Вью написал не ты и тебе похуй что там, работает и работает.
Есть контроллер - это твой код, где ты что-то делаешь. Пользователь нажал кнопку - вызывается контроллер.
А модель - это тупо декларативное описание того, что показывает вью. Какой-то класс без кода, просто набор полей. Если тебе надо показать кнопку когда пользователь что-то сделал, ты не обращаешься напрямую к контролу, ты выставляешь какое-то свойство в модели и возвращаешь эту модель из контроллера. Дальше модель как-то биндится к кнопке на экране и хуяк кнопка появилась.
Зачем это придумали? Чтобы писать юнит-тесты на гуй. Чтобы проверить, а действительно ли кнопка показывается, тебе не надо запускать все тяжелое приложение и эмулировать клики мышкой. Достаточно просто вызвать контроллер и посмотреть, какие данные он вернул в модели. Все просто.
>>3247191
Это развитие процедурного подхода. В процедурном программировании ты вызываешь функции напрямую и никак не подменишь вызовы в юнит тестах. В анемике ты вызываешь функции через класс, а в тестах подкладываешь моки, где надо.
Тебя спросить забыли кому и где работать.
Проблема в чтении доков: уже 2.5 месяца времени читаю доки по ларавел.
То же самое было с другими технологиями. Но с на ларавель уже заебало. Я нихуя не делаю, 247 читаю.
Как вы читаете доки? И нужно ли их все читать? Или достаточно проходить курсы, где цимес всего что нужно и обращаться к документации только по необходимости?
Доку ты читаешь для решения конкретной задачи. Курсы проходить не надо. Идёшь на собес без задней мысли.
Прочитать полностью ларавель надо. Потому что ты должен знать все возможности фреймворка. Для начального уровня хорошо прочитать раздел Basic. Остальное можешь пробежать, просто сделать общий очерк - почти у всех статей есть вводная часть.
Я ищу на хабр вакансии и на hh.ru
Пиздец, конечно, мало вакансий на джуна по сравнению с мидлом. У Мидла 50-60 вакансий стабильно, в то время как у джуна дай Бог, чтобы хотя бы 5...Это хабр вакансии.
Не плачу, но немного заебало. + Приходится отмахиваться от вакансий битрикс и ворд пресс и я уже думаю: мб пора снизить планку?
Ты удаленку что ли ищешь? На фреймворках вкатунов первое время только в офис берут
Хочу создать иллюзию безопасности на своем пет-проекте и поэтому использую его, да
Содержание:
Есть отдельно frontend на vue на loacalhost:3000
Есть отдельно backend на laravel 10 на loacalhost:8000
Подготовил оба конца по инструкции: https://laravel.com/docs/10.x/sanctum#spa-authentication
1) раскомментировал строчку в Kernel
2) сделал supports_credentials option within your application's config/cors.php configuration file to true
3) в api сделал роут Route::middleware('auth:sanctum')->get('/login', functырыпырырастопыры)
4) на фронтенде включил
axios.defaults.withCredentials = true;
axios.defaults.headers.withXSRFToken = true;
(пруф на скрине с цифрой 1, все токены на месте, токен запроса СОВПАДАЕТ с тем, что отдает санктум при обращении к нему)
5) в запросе allow-credentials и ориджин ок (скрин с цифрой 2)
Залогиниваюсь на фронтенде так:
аксиос(локалхост/санкум/цсрф-токен)
.then(респ => {
аксиос(локалхост/логин)
})
и все равно 401 (Unauthorized)
П А А А Ч И М У ? Какого ему еще рожна надобно? Может сталкивался кто с такой бедою? Вся надежда.
Хочу создать иллюзию безопасности на своем пет-проекте и поэтому использую его, да
Содержание:
Есть отдельно frontend на vue на loacalhost:3000
Есть отдельно backend на laravel 10 на loacalhost:8000
Подготовил оба конца по инструкции: https://laravel.com/docs/10.x/sanctum#spa-authentication
1) раскомментировал строчку в Kernel
2) сделал supports_credentials option within your application's config/cors.php configuration file to true
3) в api сделал роут Route::middleware('auth:sanctum')->get('/login', functырыпырырастопыры)
4) на фронтенде включил
axios.defaults.withCredentials = true;
axios.defaults.headers.withXSRFToken = true;
(пруф на скрине с цифрой 1, все токены на месте, токен запроса СОВПАДАЕТ с тем, что отдает санктум при обращении к нему)
5) в запросе allow-credentials и ориджин ок (скрин с цифрой 2)
Залогиниваюсь на фронтенде так:
аксиос(локалхост/санкум/цсрф-токен)
.then(респ => {
аксиос(локалхост/логин)
})
и все равно 401 (Unauthorized)
П А А А Ч И М У ? Какого ему еще рожна надобно? Может сталкивался кто с такой бедою? Вся надежда.
Да, но куда ему, он общую инструкцию-то повторяет, но вот это самую последнюю тонкость все равно получить не удается, что-то крайне неочевидное, до обидного
Да.
>На фреймворках вкатунов первое время только в офис берут
Убедился об этом на опыте. 98% вакансий - только офис для интерна/джуна.
Сегодня глянул когда впервые начал откликаться - в начале апреля. Пятый месяц идет моего поиска, пусть и ленивого. Только в этом месяце перешел на hh.ru, мб этот переход сыграет роль в получении работы.
Конечно, я так себе выбрал условия работы - только ларка и только удаленка.
848x480, 0:06
Кто понимает, что произошло? Почему дублировались записи в сессиях? И почему проблема вдруг пропала?
>Битрикс
Работать с ним это примерно как продавать жопу на вокзале. По перспективам, прибыльности и удовольствию от работы.
Это я тебе как битриксоид со стажем говорю.
Перекатился и давно, поэтому есть что с чем сравнить.
Вкатываюсь в фулл написание лэндосов.
Нужно ли уметь использовать пулы с учетом того, что я буду брать самые дешман-тарифы по оборудованию или я слишком углубляюсь и не понадобится больше 2х потоков, которые можно вручную указать?
Я не уверен в своем ответе, но под капотом Лары (10 по крайней мере) есть рандомно работающее кеширование рандомных конфигов -- оно то работает, то не работает, то кеширует, то очищает и чего там как это большой вопрос, по крайней мере я пришел к такому выводу при работе с ней...
https://onlinephp.io/c/23008
Даже нейронка ахуела от этой кучи говна.
Тебе не приходило в голову что было бы нехуйно отделить обработку файлов от твоей уебищной html свалки?
Нейросеть
Короче, вчера всерьез думал, допустимо ли генерить название изображений, которые загружают пользователи, функцией random_string(20).'.jpg', думал - а вдруг сгенерит тот, который уже был? Так лень писать проверку на наличие, ведь шанс 1 на 62^20. Типа думал, может в начало добавить "$user_id-time()-random_string(20)" чтобы точно исключить.
>Наши уроки по PHP собраны по адресу http://codedokode.github.io/phpbook .
Стоит трогать или 5 пыха слишком сильно отличается от 8?
Да хуй его знает. Может быть блядь с помощью ФУНКЦИЙ?
Ух бля, прям как код админки битрикса
Стоит, если нет понимания что такое переменные, функции, регулярные выражения и т.д.
Для того, что ты написал, есть специальные функции в php. Например, random_bytes, результат закинуть в bin2hex.
>Стоит трогать или 5 пыха слишком сильно отличается от 8?
На самом деле очень сильно, на там такой базовый материал что поиграться можно.
Я пытался, но что я могу поделать если хтмл не может в обработку пхп, а пхп может? Вот и приходится пихать через эхо морду
>ооп знаю
>пыха дохуя с-подобный язык или это я долбоёб?
Каждый ебаный раз. Не успел познавший ооп дописать до конца поста, а уже обосрался.
А тебе не приходило в голову и обрабатывать хтмл в пхп?
https://paiza.io/projects/oOdnjEEFjizZGUr-NkOHHw?language=php
Нахуй ты вообще на этот хтмл время тратишь? У тебя с кодом проблемы, а ты хуйней занимаешься.
знаю, но чтобы загенерить строку размером с нечетным кол-вом символов, придется все же дописать отдельную функцию
На каждый пук файлы дёргать, ещё и с проверкой существования? )) Я думал, в пхп есть что-то типа редактирования хтмл-документа как в ява-скрипте. Было бы удобно. А вложенные структуры как через пхп? Это же будет по функции на каждый тег...
Не хватало нам пхп кретинов, джаваскрипт дегенераты подползли. По функции на каждый тег у него.
Все. Хтмл дрисня это ваше болото теперь, редактируйте документы, дрочите цсс, выравнивайте кнопочки. А мы с бекэнда будем вам джейсончики слать и о вротенд параше не вспоминать.
Давай, забирай этот хтмл и ползи обратно в жс тред.
ну что php это слон , ну нормально
У меня кстати рил так. Делаем апишку на симфони, с остальным ебуится фронты. Хотя я не против фронта, если честно мне нравится SSR и мне нра сайты которые работают с no-script. Очень шустрые получаются
Тут пацаны как титаны финтех ворочают российский, а ты к нам с такими вопросами.
стек php8/yii2
если шанс залететь на 100к деревянных?
в целом на работе занимаюсь вроде как важными вещами, но тащемта 50к(
Охуеть, а почему нас спрашиваешь? Мы про тебя знать что-то больше тебя самого должны?
на 50к пердеть долго можно потому, что дураков работать за эти деньги сегодня немного
аналогично ононе, только laravel/битрикс и 60к.
дрочим отклики короче, и думаю можно опыта полгодика крутануть, тип это вторая работка уже, была еще совсем маленькая галерка до этого, где сеошное гомно прикручивал.
как думаешь поможет?
>Не хватало нам пхп кретинов
if(...) { шаблон181.пхп }
else { шаблон182.пхп }
Я правильно понял твой подход? Или ты только /body оборачиваешь с умным видом?
Дегенерат, для этого используется маршрутизация. Запрос приходит в конкретный экшен, конкретного контроллера, который отвечает за отображение конкретной страницы, с конкретным шаблоном.
Да и вообще я показал человеку принцип работы с шаблонами. Как убрать оттуда пхп код. Как в них прокидываются переменные и как работать с output buffer'ом. В реальном проекте это все делается в объектном стиле и в шаблон прокидывается куча функционала, с поддержкой всех этих динамических форм и виджетов.
Причем это в "реальном ПЕТ проекте". В рабочем проекте у тебя будет фреймворк и целый отдельный движокк шаблонизации. Со своим языком разметки вместо обычного пхп. И с кучей фишек и особенностей, который еще изучать заебешься.
Но это все лирика. Как я и сказал: нам пхпшникам этот вротэнд нахуй не уебался. Так что, червь-пидор, собирай все эти дивчики, боди-хуеди и уебывай в жс тред. Двигайте там свои кнопочки, выравнивайте текст и дрочите пиксель перфект динамическую верстку под андроид. Здесь твоей тупости не рады, здесь своих идиотов хватает.
>>233592
О мудрец, поведай зелёному вкатунцу. Пишу честно, как есть. Мне на программирование поебать абсолютно, я это воспринимаю чисто как фарм денег. Хочу иметь свою тыщу долларов в месяц работая из дома. И работая не круглые сутки, а 6 часов +- в день. С головой вроде всё нормально. В гугл умею, английский знаю. Стоит вкатываться? Как с фрилансом дела на пыхе.
Вот в треде многие пишут что там зэпэха 60к , 80к, 100к. Вас за эти деньги сильно ебут? вопрос ко всем. И сколько на фрилансе на пыхе можно зарабатывать.
> И работая не круглые сутки, а 6 часов +- в день
Это в перспективе через год-два. Понятно что будучи зеленью придётся больше работать/учиться
>сколько на фрилансе на пыхе можно зарабатывать
Фриланс это нерегулярные шабашки. В 95% случаев ты не будешь связываться с ним потому, что оно не стоит тех денег, что предлагает заказчик.
>И сколько на фрилансе на пыхе можно зарабатывать.
От нуля до бесконечности. Зависит от 1) географии - какой фриланс, зарубежный, отечественный. 2) платёжеспособности клиента, у шейха из арабских эмиратов и школьника из усть-пердюйска разные бюджеты. 3) вовлечённости и дисциплины, если ты работаешь по 5 минут в день с перерывом на обед, то ты и будешь получать за 5 минут. 4) конкуренции на рынке.
>Хочу иметь свою тыщу долларов в месяц работая из дома
>работая не круглые сутки, а 6 часов +- в день
Вполне возможно. Это называется "ловушка среднего дохода". Вроде пожрать есть, одеться есть, а выше стремиться/развиваться уже не хочется. Я так довольно долго получал по $20/час, на всё хватало, но развития не было.
>Стоит вкатываться?
Стоит, почему нет. Это лично мои претензии к языку, но чисто для заработка денег язык сойдёт.
>Вас за эти деньги сильно ебут?
Не знаю как сейчас, я ушёл из пхп давно.
Спасибо за такой развернутый ответ!
Сука как же хорошо, надо бы вкат возобновить.
>погугли как в пхп с шаблонами работают
Как я понимаю, это для крупных блоков кода, которых несколько на страницу. А на масштабе ветвлений и циклов это не применяется - т. е. избавиться от эхо-строчек таким образом не получится; редактировать свалку файлов по отдельности сложнее. По сути такой include ничем не отличается от обычной функции, разве что если код хтмл статический, то предпочтительней писать его в подключаемом файле, а если динамический, то в функции. Производительней всё-равно будет второе.
Кроме того есть проблема переименования: бегать менять имена файлов чуть что...
>>253881
>здесь своих идиотов хватает
Пока одного вижу.
Если я засру код различными проверками значения, то будет ли это оправданно?
"В своей книге «Эффективное использование C++» (Effective C++) Скотт Майерс приводит отличный пример дилеммы, касающейся проектирования с использованием наследования. Рассмотрим класс с именем Bird. Одной из наиболее узнаваемых особенностей птиц является, конечно же, их способность летать. Таким образом, мы создадим класс с именем Bird, содержащий метод fly. Вам сразу же должна стать понятна проблема. Что нам делать с пингвином или страусом? Они тоже являются птицами, однако не умеют летать. Вы могли бы переопределить соответствующее поведение локально, однако метод по-прежнему будет иметь имя fly. Нет смысла располагать методом с именем fly для класса птиц, которые не летают, а только ходят вперевалку, бегают или плавают."
Разве тут есть дилемма? Больше похоже на неправильное использование наследования, потому что в общий класс следует выносить только то, что будет общим для всех подклассов.
>потому что в общий класс следует выносить только то, что будет общим для всех подклассов
А в казино следует ставить на тот номер на котором будет шарик.
А также то, что если я пишу код объекта А так, что он содержит объект В (композиция), то объект А не будет зависеть от объекта В, если я вместо указания типа конкретного класса, укажу тип абстрактного класса или интерфейса и в ситуации, когда мне нужно будет использовать объект А в отрыве от написанной системы (т.е. в другой системе), мне нужно будет всего лишь объявить нужный интерфейс и написать к нему соответствующий класс-реализацию и этот класс-реализацию передать объекту А?
В любом случае, зачем называть этот пример дилеммой?
Я сомневаюсь, что в начале развития ООП-парадигмы, люди не понимали, что переход от общего к частному в иерархии классов это что-то запредельное.
Хотя с кем я разговариваю...
Как всегда обсуждение в соответствующих тематических тредах сводится не к диалогу темы треда, а к тому, чтобы клоуничать и иронизировать. С таким подходом к диалогу тебе лучше идти сразу в /b.
В php есть тайпхинтинг, запрещающий передавать в функции и возвращать из них некорректные типы, поэтому тебе чаще всего не нужно делать явные проверки на тип в коде.
Просто ты тупой еблан.
Дилемма заключается в том что когда мы сталкиваемся с элементом, который больше не вписывается в иерархию, то есть два варианта: 1. все равно вписать его в иерархию, 2. вынести его из иерархии. И оба варианта - говно.
А твои маняфантазии про то что нужно просто знать что там будет в будущем вписываться и не вписываться - это тупая хуйня. Что тебе и показали на ироничном и остроумном примере умные люди.
Когда говорят о зависимостях, то имеют ввиду МОДУЛИ кода. Какая разница что ты зависишь от интерфейса, если этот интерфейс в той же библиотеке что и его реализация?
Вот поставил ты себе Guzzle. Если ты будешь у себя в коде использовать ClientInterface из этой библиотеки, а не Client, что изменится? Твой код все равно без модуля Guzzle работать не будет. Физически.
640x360, 1:24
Бля, давно так не проигрывал
https://laravelplayground.com/#/snippets/9f11453e-29f1-4a43-8584-3513e71b2430
Сразу пикрелейтед вспомнился. Ебало даунов неиронично пользующихся этой говной в программировании имаджинировал.
Это копия, сохраненная 15 ноября в 01:42.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.