• Какой из этих подходов в ООП лучше и как они называются?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    с самого начала у нас есть более-менее абстрактный класс


    Так не должно быть. "абстрактные" классы это способ устранения дублирования, нам больше важны интерфейсы объектов и полиморфизм. Но конкретно в рассматриваемом примере нам важна только инкапсуляция.

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

    Вот и вся разница. Далее вход идет инкапсуляция. То есть наше состояние должно быть изолировано внутри объекта, и доступ к нему напрямую из внешнего мира должен быть закрыт.

    Если мы хотим создать объект с каким-то состоянием по умолчанию - мы берем первый вариант (либо как в примере прописывваем прямо как значение свойства, либо сэтим в конструкторе).

    Если мы хотим создать "пустой" объект и уже потом определить его состояние - мы выбираем второй вариант. Как правило этот способ создает много побочных эффектов если не контролировать его, да и обычно это делают не потому что так правильно а потому что подругому не умеют (типичный пример - сущности доктрины. Многие просто не представляю себе как с ними работать без сеттеров).

    Если же мы хотим создать объект но он не может быть пустым, объект должен требовать начальное значение в момент создания. Тогда мы просто передаем значение в конструктор. Без этого значения (или с неправильным) мы не сможем создать объект. К примеру если у пользователя обязательно должен быть email и пароль имеет смысл "заставлять" разработчиков явно передавать их в конструктор объекта. Это эдакая вариация.

    А теперь попробуем первый и второй подходы вместе + третий кейс с обязательными параметрами:

    class User {
         private $id;
         private $email;
         private $password;
    
         public function __construct($email, $password) 
         {
               // это ваш первый пример только без наследования, оно не нужно
               // в нашей задаче идентификатор пораждается
               // при создании объекта самим объектом, состояние по умолчанию
               $this->id = Uuid::uuid4(); 
    
               // мы требуем входящие данные что бы задать начальное состояние
               $this->email = $email;
               $this->password = $password;
         }
    
         // мутация состояния, второй вариант.
         public function changePassword($password) 
         {
                $this->password = $password;
         }
    }


    То есть вся разница только в том, откуда приходят данные для формирование объектом своего состояния. Изнутри (первый случай) или снаружи (второй случай). Оба подхода вполне себе можно использовать вместе.

    Ну и да - зачем в вашем примере наследование и нейкий "абстрактный" класс - не понятно. Наследование это не принцип, это механизм для достижения полиморфизма подтипов. С ним нужно быть осторожно, особенно если с полиморфизмом не разобраться сначала.
    Ответ написан
    Комментировать
  • Как отсортировать массив по нескольким параметрам?

    alsopub
    @alsopub
    uksort вам поможет - fi2.php.net/manual/ru/function.uksort.php

    $data = array(
      'asd' => 5,
      'sdf' => 7,
      'a' => 7,
    );
    
    
    $cmp = function ($a, $b) use ($data) {
      if ($data[$a] == $data[$b]) {
        return $a < $b ? -1 : 1;
      }
      return $data[$a] > $data[$b] ? -1 : 1;
    };
    
    uksort($data, $cmp);
    
    var_dump($data);
    Ответ написан
    7 комментариев
  • Есть ли IT деревни на северо-западе РФ?

    Предлагаю получить по бесплатному гектару земли на Востоке и построить IT-колхоз. Выращивание корнеплодов и, конечно же, программирование - что может быть лучше?
    Ответ написан
    9 комментариев
  • Какой смысл от синглтона, когда есть статика?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ведь в любом случае мы получаем глобальное состояние


    А глобальное состояние что? Правильно, плохо. У меня тут недалеко есть один небольшой проектик под iOS где ребята решили повесилиться, и сделали сингелтон с сотней публичных свойств. И вся система работает с этим глобальным состоянием плодя побочные эффекты. Инкапсуляция? не, не слышали.

    Какой смысл использовать именно singleton?


    Сингелтон - это паттерн, который запрещает нам иметь в рамках процесса два инстанса одного объекта. Самый простой способ - использование статики. Сингелтоны полезно, когда у вас, например, два потока, и каждый наровит создать объект, а вам жизненно необходимо что бы объект в системе был один, что бы ошибок небыло.

    В PHP, где не не особо популярна идея многопоточного программирования, и процветает "умирающая" модель выполнения, в сингелтонах вообще нет смысла. И используют их потому что... внимание... хотят иметь глобальный доступ к различной фигне, в том числе организация глобального состояния.
    Ответ написан
    6 комментариев
  • В чем моя причина провала тестового задания Яндекса?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ну давайте я покритикую:

    возьмем файлик

    1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

    class Travelsort {
        constructor() {}
        sortTickets(tickets) {}
    }


    2) вы не умеете пользоваться исключениями.
    if (!Array.isArray(cards)) {
        throw new ValueError('Wrong input');
    }


    3) использование let там где должен использоваться const

    4) в принципе использование переменных там где их быть не должно

    5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

    6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

    7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

    8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

    Далее... берем следующий файлик

    1) если вы пишите комментарии к таким маленьким кускам кода - стало быть у вас хромает именование вещей. Все должн быть понятно просто из названий методов/функций/переменных. При работе в команде над серьезными проектами это немаловажно, ибо код чаще читают чем пишут и экономить нужно именно это время.

    2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

    Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

    3) очень много дублирования.

    4) очень плохо с protected variations.

    Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.
    Ответ написан
    17 комментариев
  • Какие есть обучающие ресурсы по фронтенд разработке?

    edward04
    @edward04
    Начинающий ninja frontend
    https://www.youtube.com/channel/UC7enHM_oJRYJOnyJr...
    https://www.youtube.com/channel/UCZeU17nbVfzczAkJV...
    https://www.youtube.com/channel/UCHHw70vvbfyM6xJQo...
    https://www.youtube.com/channel/UCIIt69f5D44s2cdb9...
    tohtml.it/post/74511047203/markup-process

    По нему скучаю искренне и иногда сижу на подоконнику с лате и смотрю на капли дождя, стекающие по стеклу:
    https://www.youtube.com/channel/UCdnFX7mzgup9moXG2...
    Это для общего развития:

    https://stepic.org/course/%D0%90%D0%BD%D0%B0%D0%BB...

    Похожий вопрос:
    Какие задачи нужно уметь выполнять на JS начинающему?

    Ваша библия:
    https://developer.mozilla.org
    Можно докинуть еще:
    webref.ru
    htmlbook.ru
    Просто случайная ссыль
    https://docs.google.com/document/d/1kehaJKKRo7zxYp...
    Еще одна:
    https://github.com/ihorzenich/html5checklist
    Еще какая то штука
    https://github.com/dypsilon/frontend-dev-bookmarks
    Лучшие практики тостеровцев
    Как вы начинаете вёрстку сайта?
    Инструменты
    fredsarmento.me/frontend-tools

    После пары часов выпускания пара из ушей, включить на всю громкость и хоть как то отвлечься от этой жизни
    https://www.youtube.com/channel/UCY0C6A3t3RTUN3BB6...

    На freecodecamp.com неплохо алгоритмы можно потренить

    Ну и конечно
    learn.javascript.ru

    PS
    еще это
    Какие ресурсы с новостями по web-разработки вы знаете?

    PSPS
    Не отвечаю за качество контента под ссылками, может кое что уже outdated.

    https://vk.com/video79753760_171233585

    Удачи, брат
    Ответ написан
    4 комментария
  • Выбор базы данных для админки?

    sim3x
    @sim3x
    settings.json
    settings.yaml
    bash environment variables
    Ответ написан
    Комментировать
  • Какой язык выбрать в качестве основного?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Мне 14 и я встал в тупик!


    Вам 14, это нормально.

    Я собираюсь стать программистом

    Какой язык выбрать в качестве основного?


    Английский. Начните с него.

    web-dev в качестве серверного языка выбирают PHP, Python,

    А как же Ruby? Go? Javascript + Node.js? Erlang?

    Для системного администрирования Python,

    Да как-то даже Perl еще юзают.

    Для создания приложений C#,C++,Python.

    Java!, Kotlin, Scala, DLang, Rust, Go... Да и приложения разные бывают.

    Какой язык используете вы, и что посоветуете мне?


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

    Могу вам только сказать, что если вы осилите эту книжку, то вы уже будете на голову выше среднестатистического джуниора PHP коих на рынке сейчас тьма.
    Ответ написан
    Комментировать
  • Как отправлять push-уведомления с wordpress?

    BupycNet
    @BupycNet
    Основатель PushAll
    Pushall.ru
    Поддержка Chrome (дополнение + web push), Safari, Firefox, Telegram, Android (приложение + веб пуш), email, через неделю iOS.
    Есть плагин для WordPress, который автоматически публикует новые посты на канал и рассылает уведомления подписчикам.
    Ответ написан
    Комментировать
  • TDD/BDD в чем разница и для каких видов модулей стоит использовать?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    TDD

    - пишем тесты - маленький кусочек, то что можно минут за 10 написать. На этом этапе мы формулируем что мы хотим написать.
    - пишем код - пишем код, который делает тесты "зелеными". то есть все работает. Мы делаем это максимально быстро, самым тупым способом, который просто быстрее всего сделать.
    - рефакторинг - после того как все работает, или еще через пару итераций, что бы набралось чуть больше "грязи", чистим код поочередно. Важно при рефакторинге чистить что-то одно. Либо код, либо тесты (да да, их тоже надо рефакторить иногда устраняя дублирование). Поправили код - прогнали тесты, все хорошо? тогда можно тесты подправить. Ну и т.д.

    BDD
    - пишем фичаспеки - это этап детализации более высокоуровневых требований. Фич. Обычно на этом этапе просто записываются мысли как что должно работать. В этом плане описание фичи описывает юзкейс, а сценарии - детализируют поведение фичи. То есть если у кого-то возникает вопрос как что должно работать, люди описывают пример в виде сценария. Типа что есть, что мы делаем и что в итоге должна выдать система.
    - пишем код - так же как и в случае с tdd, можно писать код для разных уровней.
    - рефакторинг.

    TDD - для одного разработчика, BDD - для команды. А BDD-style assertions для chai - это пафос. По сути это "планирование фич" в рамках библиотек и отдельных объектов. Чуть меньший масштаб. Но ничем от TDD вообще не отличается, хотя если сильно постараться можно так же оценивать ценность фич для пользователей нашей библиотеки и т.д.

    Как никак в BDD основная мысль - фичаспеки должен иметь возможность читать продукт оунер или стэкхолдеры, то есть те кому проект собственно нужен, что бы говорить должно работать так или нет. В случае с библиотеками... ну вы пишите что-то для девелоперов, а они в состоянии читать тесты как фичаспеку. И в принципе от предметной области недалеко.
    Ответ написан
    1 комментарий
  • Почему правильнее делать сайт по mvc?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    У вас может быть и модель, и прдставление и контроллер хоть в одном файле, суть то не в этом.

    MVC описывает не все приложение (есть Model2 которое убого но описывает все приложение, но я бы не рекомендовал вам сейчас на него ориентироваться). Оно описывает только "как сделать так, что бы приложение ничего не знало о UI".

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

    Далее, у нас есть представление. Вопреки вашему мнению, представление это не html а http. Поскольку PHP должен сформировать именно HTTP ответ (так или иначе, при помощи echo и header или при помощи абстракций над http). Просто обычно сайтики в качестве тела ответа содержат html. Но намного проще воспринимать "представление" как HTTP ответ. "шаблонизаторы" в этом плане не относятся к представлению, это способ его генерации. Сделаем допущение что весь view в нашем MVC это обычный HTTP ответ. Просто кусок текстовой инфы выплюнутый в буфер вывода. Помимо HTTP есть еще варианты: CLI или консольные скрипты, у них сфой формат представления. А еще есть менеджеры очередей и кучи других вариантов.

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

    Ранее мы уже сказали что "шаблонизаторы" это не часть представления а только способ его получения. Где мы должны использовать шаблонизатор тогда? Как сделать так, что бы наша "модель" или точнее наше приложение ничего не знало об этом "шаблонизаторе" (или сериалайзере, или json_encode, или еще чем-то там)? Положим между представлением и моделью что-то промежуточное - контроллер.

    Опять же контроллер - это не обязательно один объект. Это может быть целая цепочка объектов, которая может передавать запросы друг дружке и что-то с ними делать. Например один "контроллер" глянет мол "ага, он в качестве тела запроса прислал json - десериализуем". А второй контроллер такой "ага, он должен быть авторизован - надо проверить". Ну и т.д. покуда мы не дойдем до последнего контроллера в цепочке, который уже будет дергать "один" метод модельки. Это слой адаптеров между http и нашим приложением. Вот ключевая мысль MVC на бэкэнде (или ели точнее Mediating controller MVC или MVA, паттерн который реализован в большинстве современных бэкэнд фреймворков).

    Зачем нужно отделять UI от приложения? потому что что-то из этого явно меняться будет чаще и не одинаково. А еще можно распаралелить работу. А еще можно заменить реализацию одной из частей без вреда для другой. Словом мы получаем намного больше гибкости, но только если приложение ничего не знает о представлении.. В противном случае мы получаем антипаттерн под названием smart ui, для борьбы с которым 40 лет назад и придумывали MVC.
    Ответ написан
    3 комментария
  • Зачем нужен Gulp?

    @artinnok
    бекенд-программист
    CSS и JS:
    К примеру, у вас имеется большое количество (Х штук) css или js файлов, которое вы подключаете на своих страницах посредством тэгов <link> и <src>.
    При загрузке страницы, браузер клиента будет отправлять X запросов к вашему серверу, а ваш сервер должен будет ответить на X запросов.
    Это:
    1. Тормозит загрузку страницы - будете ждать ответа от сервера
    2. Загружает ваш сервер

    С помощью сборщиков фронтэнда вы можете "склеить" все файлы в один - main.css и main.js, которые будут отдаваться 2 запросами с сервера. Также, вы сможете минифицировать CSS и JS. Под минификацией подразумевается уменьшение размеров файла на диске. Естественно, более легкий файлы будет быстрее прогружаться + минимальное количество запросов к серверу.

    IMG:
    К примеру, у вас имеется Х изображений размером 700 Кбайт. Клиенту надо будет загрузить 700 * X Кбайт. Если вы пропустите свои изображения через Gulp, то вы получите изображения с меньшим размером на диске и такого же качества, т.е. клиенту придется прогрузить примерно (500-600) * X Кбайт.
    Ответ написан
    1 комментарий
  • Как найти проект на гитхабе, к которому можно присоединится для опыта в веб разработке?

    vicodin
    @vicodin
    Имею некоторый опыт
    ходишь по репозиториям, просматриваешь списки issue, если зацепишься за какой-нибудь - пиши, что попробуешь пофиксить, фикси, делай пулл-реквест.
    Ответ написан
    Комментировать
  • Есть ли смысл ри изучении YII 2 заглядывать в книги по первой версии фреймворка?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    в книгах по фреймворкам особо смысла нет изначально. Читаем документацию и читаем больше книг (классика, вроде Фаулера, Кента Бэка и т.д.)
    Ответ написан
    1 комментарий
  • Правильно ли я расставляю приоритеты в развитии?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Для начала, как говорится, определитесь с целями. Вы хотите больше интересных задач. При этом ваша специализация - верстка. Раз уж вы только только решили попробовать "gulp" и sass - предположу что с такими инструментами, как скажем autoprefixer вы так же не знакомы. И тем более webpack.

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

    По процессам вам стоит ознакомиться с существующими методологиями в верстке. BEM, Css modules и т.д. Сейчас все популярные фреймворки (в том числе и angular) идут по сути реюзабельных компонентов, и подобных подходы к верстке зададут вам какую-то основу.

    Передт тем как учить фреймворки стоит определиться с целями. Если знания ангуляра вам нужны на уровне шаблонов - ну тут тогда можно просто почитать да попробовать в свободное время. Если же вас именно качественное понимание всего интересует, но перед фреймворками надо хорошо изучить javascript (и ознакомиться с текущим стандартом ES2015). И уже после этого можно приступать к фреймворкам.
    Ответ написан
    1 комментарий
  • MVC php на пальцах?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ох...

    Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.

    mvc-mvp-mvvm-6-638.jpg?cb=1375170002

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

    View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

    Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

    Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

    Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

    Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.
    Ответ написан
    Комментировать
  • Качество кода ради производительности?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ну дак в чем собственно вопрос, стоит ли делать подобные жертвы ради производительности?


    Нет, достаточно просто настроить opcache нормально:

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

    2) Отключить инвалидацию кэша в opcache (opcache.validate_timestamps=0) и сбрасывать кэш вручную при деплое

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

    4) обновитесь до php7

    p.s. среднее время ответа для простеньких запросов - 30ms, память - 10-15Mb. Если запускать симфони в php-pm, то запросы отдаются за ~10-15ms, потребление памяти на запрос посчитать немогу (так как все запущено как демон). Но этот вариант пока рекомендую для очень простых апишек где нужна скорость реакции системы.
    Ответ написан
    2 комментария
  • Как не распыляясь дотащить до front-end мидл девелопера?

    @djay
    Must have:

    - HTML5/CSS3 - знать как минимум в совершенстве
    - JavaScript, включительно ECMAScript 6-7
    - В порядке вещей - Bootstrap + Jquery
    - Grunt/Gulp, Bower
    - Знание хотя бы одного фреймворка. Сейчас более менее ходовые это Angular.js и Backbone
    - Знание системы контроля версий Git. Умение работать с GitHub/BitBucket
    - Опыт работы от 2-х лет

    Как плюс:

    - Знание Canvas, SVG, умение писать игры
    - Знание шаблонов проектирования
    - Умение покрывать код тестами

    Это и есть обобщенный набор навыков по рынку на текущий момент.
    Ответ написан
    9 комментариев