GTRxShock

Петрова, Орлова: Новый самоучитель английского языка.

Вся актуальная литература есть только на Amazon. Вот, например, книги по JavaScript тематике, отсортированные по дате выхода (с учетом планируемых).

Также, на заметку, издательство O’Reilly предлагает в открытом доступе ряд материалов для изучения, а издательство Packt раз в сутки выкладывает для бесплатного доступа рандомные книги - можно мониторить на предмет актуальности исходя из личных потребностей.

Крайне редко вы встретите актуальный русскоязычный аналог, да еще с толковым переводом. Поэтому, я бы делал ставку на английский - это ваша дополнительная степень свободы относительно доступа к самой новой и качественной информации на рынке.

1. Выделить одну главную функцию сервиса
2. Сделать её, сверстать и выкатить, это будет MVP
3. Не заморачиваться с вёрсткой
4. Не заморачиваться с методами авторизации
5. Не думать про нагрузку, не заниматься оптимизацией кода и БД
6. Если поймали себя на мысли что вы думаете какой паттерн тут применить вы в Ж, просто пишите код, который работает!!
7. Не совмещать написание сервиса, который вы РЕАЛЬНО хотите запустить с изучением чего-то нового (языка, БД). Утоните в учёбе и никогда не запустите.

Это всё на своём опыте написания проекта говорю вам а не голословно ))

Во-первых, читайте про замыкания и bind.
Во-вторых, вам eval тут не нужен триста лет.
В-третьих, data-callback="after_upload($(this))", который у вас потом отправится в eval - это вообще феерический говнокод.

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

Например так:

<form name="upload" data-ajax="true" data-callback="after_upload_1">
<!-- ............ элементы формы -->
</form>

<script>
    function callbackForge(type) {
        var callback;
        switch (type) {
            case "after_upload_1": callback = function(a,b,c) {...}; break;
            case "after_upload_2": callback = function(a,b,c) {...}; break;
            ...
            case "after_upload_n": callback = function(a,b,c) {...}; break;
        }
        return callback;
    }

    $('form[data-ajax]').on('submit', function(event){
        event.preventDefault();
        var th = $(this);
        var form_name = th.attr('name');

        var data = th.serialize();
        var callback = callbackForge(th.data('callback'));

        $.post('/ajax/'+form_name,{data: data})
        .success(function(d){
            // парсится ответ и в зависимости от ответа 
            // показывает либо ошибки, либо информацию о сохрнении
            ParseResponse(d, 'form[name='+form_name+']');
            callback(th, data, event); // и тут уже какие параметры хотите, такие и передавайте
        });
    });
</script>

Для управления сложностью.
https://habrahabr.ru/post/169487/

Все что сделано при помощи ООП можно написать и в процедурном стиле, например, но чем сложнее проект тем сложнее будет во всей этой каше разобраться. Весь смысл ООП - разбить большущую сложную систему на кучу отдельных ПРОСТЫХ объектов, методов, сущностей.
А еще с ООП неразлучна абстракция. Чтобы можно было одну часть программы выбросить и подменить на другую.

Сегодня у нас выводится на веб-страничку, по которой кликают мышкой, а завтра не мышкой - а тач пальцами. А послезавтра вообще в VR шлем, и управление голосом. И если система правильно спроектирована - ее не придется переделывать ПОЛНОСТЬЮ, а только ту часть, которая ответственна за ввод/вывод.

В PHP отсутствует Double Dispatching и перегрузка методов

Double Dispatch в PHP:

class Foo {
    // ...
    public function makeSomeStuff(Bar $bar)
    {
         $bar->doStuff($this->someData); // double dispatch!
    }
}

Перегрузка методов:

class Foo {
    public function foo() {}
}

class Bar extends Foo {
    public function foo() {} // перегружен!
}

и в ответ на отличающуюся от базового класса/интерфейса сигнатуру он вывалится с ошибкой

то что вы хотели сделать называется ad-hoc полиморфизм, и он есть из коробки в любом языке программирования с динамической типизацией. Достаточно просто не указывать явно сигнатуру, все довольно просто) Ну и да, минус этого то что это не явно и в рантайме. Для языков со статической типизацией явная "перегрузка" нужна только для того что бы компилятор мог построить таблицы диспетчеризации вызовов.

Но решить проблему как-то нужно

Перегрузка методов в наследниках с изменением сигнатуры это как раз таки нарушение принципа подстановки барбары лисков (LSP для сокращения).

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

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

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

Однако каждый из хендлеров может не работать с конкретной реализацией сервиса.

Значит полиморфизм в нашем случае пошел погулять. Есть куча решений данной проблемы, в частности Chain of responsibility.

> Visitor. Предполагает наличие в каждом из хендлеров методов типа handleService1(Service1 $service) и handleService2(Service2 $service), при этом один из методов остается пустым

зачем так усложнять то? У вас должен быть снаружи только один публичный метод а внутри уже реализация сама разберется. Ну то есть если хотите - можете внутри сделать два приватных метода но это так же странно.

> Массив маппинга, который говорит, какой хендлер может обрабатывать какой из сервисов.

Опять же излишнее усложнение.

Короче ваша проблема в том что у вас есть некие сервисы, с неким интерфейсом, которые по факту делают совсем разные вещи. То есть они априори не могут принадлежать к одному и тому же типу. Ну и нарушение LSP на лицо, вы не можете в коде заменить одну реализацию сервиса другой.

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

Почему бы не использовать css grids?

Хороший кандидат на должность Junior React Developer, по моему мнению, должен соответствовать следующему перечню требований:
1. Хорошее знание JavaScript. В React разработке используется ES6 и большинство экспериментальных фич еще не вошедших в стандарт.
2. Хорошее знание HTML и CSS. Кроссбраузерная верстка. Так же, хорошо иметь представление о том, что такое css-in-js.
3. Web APIs. Умение работать с объектной моделью документа(DOM) и все эти XMLHttpRequest, localstorage, cookie, history и прочее.
4. Хорошее знание API React. Вы должны хорошо знать React, знать его возможности, понимать основные концепции и уметь ответить на большинство типовых вопросов. Для этого достаточно хорошо изучить документацию, разобрать пару типовых проектов на github и попрактиковаться. Много полезной информации, приёмов и идей можно подчерпнуть из тематических статей и докладов. Так же, на просторах интернета можно найти подборки типовых вопросов, часто задаваемых на собеседованиях. В англоязычном сегменте их больше.
5. Redux. Уверенное знание API. API библиотеки до боли пост. Знать, что такое промежуточное ПО и зачем оно. Понимать базовые концепции архитектуры Flux. Все это есть в документации и многочисленных курсах.
6. Умение работать с менеджером пакетов npm на базовом уровне.
7. Node.js. Хотя бы уметь написать простейший express/koa сервер, который будет отдавать ваше приложение и статику.
8. Webpack. Базовые знания.
9. Умение работать с git. Хотя бы знать и уметь примерять команды: init, clone, add, commit, push, pull, merge, checkout.
10. Иммутабельность. Четкое понимание зачем это надо. Знание приемов иммутабельного изменения структур данных. Это есть в официальном туториале React.
11. Статическая типизация TypeScrpt/Flow. Для начала хватит самых основ и способности понимать чужой код.
12. Функциональное программирование. Хватит знаний полученных в процессе изучения JavaScript, а так же не помешает знать, что такое каррирование, чистые функции и рекурсия.
13. Базовые концепции ООП. Хватит знаний полученных в рамках изучения JavaScript.
14. Асинхронный код. Понимать как его правильно организовывать. Promise, async/await.
15. Сетевые протоколы передачи данных. Вполне хватит базовых знаний о http/https, о том, что такое заголовки и какие они бывают. Хорошо знать о том, что такое websocket.
16. За плечами должен быть хотя бы один учебный проект на React. Хватит типового тестового задания.
Примеры таких заданий: 1, 2, 3(сайт может быть не доступен на территории РФ, советую отрыть через VPN и посмотреть), 4, 5. Если подобного проекта у вас нет, то будьте готовы, что потенциальный работодатель предложит вам выполнить тестовое задание и только по его результату вас, может быть, пригласят на техническое интервью. Если напишите хорошо, вас скорей всего пригласят.
17. Желателен опыт создания типовых UI элементов. Например, чтобы не вызывало трудностей написать простой кастомный чекбокс. Куча примеров реализаций типовых элементов есть на codepen.

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

Похожий вопрос.

Arbitr,

А если в статье много картинок, при этом они идут по ходу текста, а не одна за другой, как тогда быть? Хранить тег Img прямо в тексте статьи?

почему нет?
причем, не обязательно прямо-таки именно чистый тег <IMG>.
а вполне можно хранить специальным тегом типа ![GitHub Logo](/images/logo.png) причем со ссылкой просто на идентификатор картинки, а конкретные пути к файлу будут подставляться при формировании страницы для посетителя.
это был пример из Markdown

Все зависит от задач

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

Если же предполагается редактирование и какой-то там Визивиг, то удобнее будет хранить специальным образом.

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

Arbitr,

Когда искал вопрос, на форумах писали, что избыточное хранение тегов это не оч хорошо.

Речь о том, что теги могут влиять на форматирование.
Но если набор тегов ограниченный и они проходят контроль и очистку перед помещением в БД, то - можно.

P.S.:
Строго говоря, хранить имеет смысл не чистые теги HTML, а намеки на них. Например, текст:

Это некий текст. А вот тут картинка #img#id0234#

По сути это тоже тег. Но вы его преобразуете в <IMG> по определенным правилам. Сегодня у вас картинка лежит в http://example.com/images/id0234.jpeg, а завтра вы решили поместить картинки на отдельный сервер в облако и адрес будет https://images.example.com/id0234.jpeg

Например, использовать RxJava, тогда репозиторий возвращает Observable и ему не важно, кто на него подписан.
Другой вариант - использовать коллбеки. Презентер, обращаясь в репозиторий, релизует интерфейс коллбека для получения данный. В этом случае репозиторий опять же не знает, кто к нему обращается.

Поделюсь с вами вот такой ссылкой:
https://www.youtube.com/playlist?list=PLswdBLT9llb...