Павел Волынцев

P.S. Если не понятно я могу постараться объясниться еще лучше, спрашивайте.

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

Что дано и что вы в итоге хотите?

Отладьте ваши алгоритмы в режиме пошаговой отладки, воспользовавшись какой-нибудь IDE (среда разработки):

• Netbeans IDE: https://netbeans.org/ - https://netbeans.org/kb/docs/php/debugging_ru.html
• Eclipse + PHP: www.eclipse.org/pdt - www.eclipse.org/pdt/articles/debugger/os-php-eclip...
• Jetbrains PHPStorm: www.jetbrains.com/phpstorm - www.jetbrains.com/phpstorm/webhelp/debugging-php-a...
• NuSphere PhpED: www.nusphere.com/products/phped.htm - www.nusphere.com/products/php_debugger.htm

Так же рекомендую вам составить план проверки функций (что на входе - что на выходе) и применить юнит-тестирование с помощью PHPUnit

P.S. Все ссылки на актуальность не проверял. Поищите свежие версии инструкций на сайтах производителей.

Вот на такую недавно натыкался gamesbannernet.com

1. Отправляйте данных аяксом и сохраняйте все запросы в стеке. Если запрос не прошёл сейчас - повторить через минуту. гугло-почтовик так пытается отправить или прочитать что-нибудь когда сеть ненадолго отключилась.

2. Сохраняйте копию отправляемых данных в LocalStorage браузера. Если не удалось отправить сейчас - отправьте в следующий раз, когда пользователь браузером на тот же сайт зайдет. Забыл как такая технология называется. Google Mail Offline и Google Docs Offline так работает

Могу дать прототип 20 страниц в Pencil - нужен прототип HTML на Semantic UI базовом.
4 страницы уже готовы, так что есть с чего начинать.

Устроит такое задание?

Назову несколько типовых структур данных, при использовании которых требуется что-нибудь передать через конструктор объекта:
1. Стек
2. Очередь
3. Дерево или другой связный список
Почитайте тут habrahabr.ru/post/190176

С одной стороны, всё зависит от WSDL. Наверное там прописано, что параметры этого веб-метода именно в нижнем регистре.

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

Как бы страшно это не звучало, но я порекомендую реализовать SOAP Client и SOAP Server на Java, .Net или C++. При этом PHP с ними будет общаться через TCP или unix socket данными в формате JSON, а они уже будут работать с удалёнными серверами или клиентами по протоколу SOAP. Это называется "прокси" или "мост". В плане производительности даже выиграете, потому что
1. Эти языки умеют описание веб-сервиса в формате WSDL компилировать, а PHP его каждый раз интерпретирует
2. В этих языках есть полноценный маршаллинг Object<->XML, а в PHP жалкая имитация либо костыли типа nuSOAP под PHP4

Если у вас есть возможность, откажитесь от SOAP в пользу XML-REST или JSON-REST

Очень неоднозначный вопрос, на который невозможно дать простой ответ.

Если вам так важен этот продукт, постарайтесь удержать внимание к проекту хотя бы одного разработчика. Я прикинул в голове такой вариант: когда понадобится привлечь нового программиста к проекту, оплатить старому программисту время, которое уйдёт на передачу тайных знаний по проекту этому новому программисту - и скажу, что о технических деталях недавно выполненного проекта уже даже через 3 месяца я помню только в общих чертах. Найдите способ удержать внимание старого программиста к проекту, но не полное время - пусть в основное время занимается тем, что ему интересно. Или вот так: поделитесь с ним бизнесом и возможно он сам захочет, чтобы ошибок, уменьшающих доход, было меньше, а значит будет заниматься проектом и не забудет его.

Никогда не нанимайте одного разработчика. Пусть работают в группе. Это теоретически приведёт к тому, что код будет написан так, чтобы его понимал ещё кто-нибудь. Не факт, что код будет ровный и красивый, но если двое-трое его понимают, значит и четвёртый разберётся.

Как подавить желание "всё переделать" ? Никогда не принимайте работу в состоянии "почти готово". У вас есть техническое задание? Если нет, закажите технических писателей - пусть составят ТЗ до начала работы программистов. А по окончании работ проверяйте все пункты ТЗ на реалиацию. Проверяйте на тестовом сервере, на боевом сервере. Несколько раз проверьте, чтобы убедиться, что что-нибудь не сломается само по себе через месяц. Закажите специально тестировщиков, которые смогут проверить проект на соответствие ТЗ. Тогда сработает первое правило программистов - "работает - не трожь". Новый три раза подумает, прежде чем что-то сломать.

А может быть через год действительно надо будет всё переделать. Пусть новенький обоснует. Проведёт code review и найдёт неисправимые уязвимости в безопасности, докажет низкую производительность. Пусть устроит usability test, обоснует редизайн и изменение в функциональности сайта. Пусть устроит A/B тестирование и поможет повысить конверсию и продажи.

Вот как то так. Бред, конечно, зато от сердца.

CMS расшифровывается как "Система управления контентом". Смотрите, какие обычно модули сайта подразумеваются под управлением контентом:
1. прежде всего текстовый контент - то есть записи блогов, новости, статьи, wiki, описания товаров, объявления
2. работа с пользователями - регистрация, управление правами
3. медиа-материалы к контенту - встроенные картинки или поддержка видео-провайдеров (youtube, vimeo)
4. структуризация контента - категории и теги (или таксономия, если быть точным)
5. комментарии к контенту
6. поиск по контенту и комментариям
7. формы обратной связи и другие способы связи авторов проекта и пользователей
8. встроенная система баннеров
9. статистика
N. и ещё несколько других. Не рекламы ради, а для наглядности: список модулей одной из популярных CMS take.ms/5k7Xd

Так вот, если ты делаешь проект и тебе надо выбрать платформу, то посмотри на эту картинку - все ли нужные тебе для проекта модули перечислены на картинке?
Если твой ответ "да", то твой выбор - это CMS. Нужно сконфигурировать её и покрасить в нужный цвет.
Если ответ "нет", то нужно определить:
* сколько модулей придётся дописать (запрограммировать, адаптировать);
есть ли возможность расширять CMS нужными тебе модулями, например, с помощью системы плагинов;
* достаточно ли документации на эту CMS, чтобы не заблудиться в коде.

Для некоторых проектов окажется, что лучше не использовать CMS, а написать с нуля нужный функционал, а потом уже дописать к нему пару модулей, которые присущи именно CMS. Например твой проект касается деятельности Forex и тебе нужно добавить комментарии к текущему курсу валюты :)

А фреймворки, самописные или популярные, используются потому, что позволяют упростить и организовать программный код, чтобы кодилось компактнее, быстрее и было понятнее для чтения.

1. В контролере выбрать из базы все категории, упорядочить в памяти их иерархию, передать в представление. А в представлении вывести категории + их статьи, пользуясь отношениями, описанными в моделях
Документация про организацию отношений между моделями в Yii
(!) Но это подойдёт только для небольшого объёма данных, потому что иначе потребуется память для сортировки категорий + отдельные SQL запросы на поиск статей по каждой категории.

2. Для большого объёма данных от реализации иерархии через parent-child надо отказаться в пользу nested sets. Реализация nested set для Yii (не проверял её правильность, но 51 форк говорит сам за себя ;) )

Предположим, что у вам разделение про профилю.
Есть бакенд-разработчик, который возится с моделью данных (СУБД), кэшем, авторизацией, безопасностью.
Есть фронтенд-разработчик, который занимается пользовательским интерфейсом.

Точно так же как фронтенд-разработчик не будет (не должен) в шаблонах писать прямые запросы в базу данных, чтобы показать в диалогах дополнительно "что-то этакое", так же и бакенд-разработчик не будет (не должен) отшлифовывать кроссбраузерность вывода своего var_dump().

Идеальный вариант - это работы, выполняемые в такой последовательности:

1. готов дизайн-макет страницы
2. дизайн-макет свёрстан верстальщиком
3. полнота данных оценена бакенд'щиком, при необходимости расширена модель данных и дописаны методы для работы с ними (CRUD), настроены права (RBAC)
4. данные для страницы "вывалены" в виде var_dump() в подходящее место макета
5. фронтенд'щик убрал var_dump() и расставил все данные по своим местам в макете

далее итеративный процесс доводки страницы до идеала

Если к моменту вывода var_dump() макета нет - извиняйте, вот вам

<div style="background: green; border: 1px solid red;"><pre><?php var_dump($model) ?></pre></div>

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

P.S. Чуть помогают, но и мешают тоже, генераторы кода, как например в фреймфорке Yii. Можно по быстрому зафигачить таблицу, или диалог, или форму для конкретной выборки данных или модели Active Record, причём все они уже будут работать (сохранение, поиск, постраничный вывод). Уже не так страшно, как var_dump().

Нужно 3 ветки в репозитории - ядро + сайт1 + сайт2

в репозиториях сайт1 и сайт2 делаете git submodule ядро

теперь сайт1 и сайт2 содержат ядро как часть кода

но это сработает только в том случае, когда сайт1 и сайт2 используют ядро, но не модифицируют его. Допустимо наследование, замена классов, настройка через файл конфигурации

Например, ядро содержит файл HttpRequest.php с классом HttpRequest
А в приложении сайт1 требуется дополнительные функции в этом классе
Тогда возможны два варианта решения в зависимости от того, что реализовано в ядре:

1. Настройка автозагрузки файлов
Создаём копию файла Site1HttpRequest.php c определением класса HttpRequest в коде сайт1
Настраиваем autoloader для сайт1 так, чтобы при обращении к определению класса HttpRequest использовался файл Site1HttpRequest.php

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

Ссылки и куски кода:
1. git submodules
2. Использование таблицы классов в фреймворке Yii

Yii::$classMap=array(
        'HttpRequest'=>'/path/to/HttpRequest.php', // <-- можно указать другой путь к классу
);
Yii::createWebApplication($config)->run();

3. Application - класс-локатор в фреймворке Yii

# @file protected/config/main.php
array(
    'components' => array(
         'request' => array(
            'class' => 'HttpRequest', // <-- можно указать другой класс
        ),
    ),
);

Пользовался вот такими методами для защиты небольших фрагментов текста:
1. Генерация текстов в виде изображений - обычно раньше так имейлы скрывали, но можно что угодно генерировать. Можно накладывать водяные знаки, использовать многоцветную подложку, а лучше всего вставлять произвольные символы в произвольных местах тем же цветом, что и основной текст - при распознавании в результатах будет мусор.
2. Вставка в текст мусорных тегов c динамическими случайными стилями
<style>.GHJbk.KLJHK { display: none; }</style>

<span class="ADsdas POxlka3">note</span>
<span class="GHJbk KLJHK">x862</span>
<span class="j38jdJ Uu300D">book</p>

При этом текст выглядит как notebook, а если через буфер обмена скопировать, то notex862book.

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

Оба способа приводят к просадке по производительности

Я, наверное, оригинален.
Использую приложение todoist - это кросплатформенный, навороченный и очень удобный todo-list.

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

скриншот : take.ms/t3cOB

Посмотри следующие разделы в документации:

* кэширование страниц - про то, что в кэш можно поместить всё содержимое страницы
* кэширование фрагментов - про то, что можно поместить в кэш кусочек HTML
* кэширование динамического содержимого - про то, что внутрь кэшируемого фрагмента можно включить код, который меняется (например, в кэш всей страницы - блок банеров, при каждом обновлении страницы показывать другой банер)

Обращайся, если нужны подробности (https://toster.ru/user/copist)