Еще. Код нужно писать не как попало, а аккуратно и по правилам. Почему? Потому, что на неакуратно написанный код не хочется даже смотреть.

Если тебе лень выравнивать код руками, закачай его на http://beta.phpformatter.com/ и нажми «format». Робот исправит выравнивание и отступы в мгновение ока (да, прогресс не стоит на месте). Если ты используешь мощную IDE вроде PhpStorm, там тоже есть функция форматирования кода.

Горячие клавиши для форматирования кода в разных IDE: https://gist.github.com/codedokode/8759492

Вообще, в PHP долгое время не было единого стандарта оформления кода, все писали как попало и было много бардака, но сейчас дело лучше — есть стандарты PSR-1 и 2. Вот как надо оформлять код:

- переменные и функции пишутся с маленькой буквы, подчеркивание не используется, используется camelCase, пример: $x, $numberOfPeople, printResults()
- Название функции начинается с глагола, в стиле «сделайЧтоТо»
- не знаешь английский? Не беда, в 21 веке есть решение этой проблемы. Не пиши транслитом, открой лучше Гугл Транслейт или slovari.yandex.ru и найди название для переменной там
- в именах классов используется CamelCase, первая буква большая, «_» может использоваться
- мы предпочитаем подстановку переменных вместо конкатенации строк: "I am $age years old" — хорошо, 'I am ' . $age . ' years old' — плохо из-за обилия точек и кавычек
- мы используем для отступов 4 пробела (можно настроить редактор, чтобы при нажатии Tab он вставлял 4 пробела)

Вот ссылка на стандарты, где все это описано подробнее и даны примеры оформления:

PSR-1: https://github.com/php-fig/fig-standards/blob/master/accepted/ru/PSR-1-basic-coding-standard.md
PSR-2: https://github.com/php-fig/fig-standards/blob/master/accepted/ru/PSR-2-coding-style-guide.md

------------------

Итак, ты зашел в тред и решил помочь какому-то анону, дав ему совет или подсказку. Спасибо! Но прочти сначала эти напоминания, чтобы твоя помощь действительно была полезной.

Будь доброжелателен

Не годится: «Ты мануал хоть раз в жизни открывал, обезьяна?»
Не годится: «В гугле забанили?»
Не годится: «Твой код плохой»
Хорошо: «Вот, как можно улучшить этот код: ...»
Хорошо: «Ты неправильно используешь функцию abc(). Вот ее описание: ссылка, и как видишь ей надо передать строку, а не массив»

Не придирайся к знанию английского языка.

Объясняй

Не очень хорошо: «сделай как в этом коде»
Хорошо: «если ты вставляешь текст от пользователя в SQL запрос, то получается SQl-инъекция, которая позволяет взломать твой сервер (ссылки). Чтобы этого избежать, надо вставлять данные с помощью плейсхолдеров (ссылки)»
Хорошо: «Помни, что код пишется для людей. Если писать такие большие функции, то в них становится трудно разобраться...»

Не проповедуй

Мы учим использованию самых распространненных подходов, стандартов, библиотеки фреймворков. Если ты не любишь ООП, пробелы в коде, jQuery, сам PHP, то рассказать об этом стоит в каком-нибудь другом треде.

Не придирайся к знанию английского языка, анон пишет как умеет.

Ах да. Если тебе кажется, что что-то в учебнике или задачах можно сделать лучше — пиши, обратная связь всегда очень полезна.

>>568986

>По поводу использования одного хеша с многими ключами (page:visits:unique) против хранения отдельных ключей (visit:{IP}:{id})

Да, про масштабируемость не подумал.
Ну и у меня уже подсознательная тяга к инкапсуляции (положить все в один хеш, а не держать миллионы несвязанных ключей) и реляционности.
И был вопрос о выборке необходимых ключей, я тогда знал только команду KEYS, которая перебирает все ключи, поэтому непродуктивна.
Кажется, там еще есть команда SCAN, но я пока не понимаю, как она работает.
http://redis.io/commands/keys

>Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using SCAN or sets

http://redis.io/commands/scan

>SCAN is a cursor based iterator. This means that at every call of the command, the server returns an updated cursor that the user needs to use as the cursor argument in the next call.

Что за "cursor"? О каком итераторе они говорят? Это какой-то алгоритм? яннп
Ну хорошо, я согласен что нужно хранить отдельные ключи вместо хеша, только не понимаю как по ним искать нужные.

>в чем проблема накопления одинаковых id в очереди?

Лишняя память. Зачем мне по сто-тысяче раз хранить в списке повторяющиеся значения, если можно хранить только уникальные?
Хотя здесь наверное это не критично, и лучше хранить лишнюю информацию, чем добавлять лишние операции в алгоритм (проверка сета с уникальными посещениями перед записью в очередь).
Хорошо, сет тоже выбрасываем.

>с транзакциями не получится простое масштабирование на несколько серверов.

Я пока не в курсе, как реализованы транзакции в редисе, поэтому не понимаю почему транзакции препятствуют масштабированию.

>редис не гарантирует что все команды в транзакции будут выполнены. Это совсем не то же что транзакции в MySQL например.

Этого тоже не знал, я думал транзакция = acid.

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

Думал об этом, но отказался по соображениям: если "суммировать и группировать" на стороне редиса, то я пока просто не знаю как это сделать; если на стороне php, то нам понадобится выгрести из редиса все пары ip:id, не много ли памяти это займет? Если каждый ключ допустим в среднем 30 байт, то десять миллионов посещений в сутки даст почти 300 мб.
А, ну да, можно же выгребать это по частям, все время забываю.

>- в каком порядке коммитим mysql/redis?

Сначала mysql конечно. Он же пишет на диск. Redis пишет в оперативную память, это пара милисекунд. Да, у нас остается точка отказа между этими двумя коммитами, но во-первых это промежуток наверное меньше милисекунды, во-вторых я просто не знаю, что тут можно сделать.

Ну хорошо, значит упрощаем алгоритм.
При просмотре страницы:
Если ключ ip:id существует, то конец. Иначе создаем такой ключ, и добавляем его в очередь.

Скрипт по расписанию:
1. Берет длину очереди (LLEN), фиксирует это значение в переменную. Так что нас не беспокоит, что в конец очереди будут продолжать добавляться записи, мы будем работать только с этими N записей из головы очереди.
2. Запрашиваем порциями данные из редиса (без удаления их из очереди), пока не достигнем этой суммы N.
2.1. Парсим каждую строку вида "ip:id", чтобы получить ip и id, сохраняем в некий массив вида ['id страницы'=>кол-во посещений,].
2.2. Получаем минимальное и максимальное значение этого массива. Затем в цикле ходим от min до max, осуществляя поиск ключей для каждого такого значения.
В этом поможет функция array_keys со вторым параметром. В конце этого шага получаем массив вида ['кол-во посещений'=>array('все id страниц с таким кол-вом посещений')].
2.3. Ходим в цикле и для каждого ключа массива, упомянутого выше, подставляем массив айдишников в запрос:
UPDATE tbl_name SET visit_counter = visit_counter + delta WHERE id IN (implode($arr, ',')).
2.4. Коммитим mysql, затем удаляем обработанное кол-во записей из начала очереди.

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

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

>- настройки сохранения данных на диск, AOF и RDB, придется сначала разобраться как каждая работает. Ими ты выбираешь между надежностью, производительностью и объемом дискового трафика.

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

Ну ладно, пошел читать матчасть.

>>568993

>главное что нужно, это понимание принципов нормализации (именно понимание, а не заучивание определений)

А понимание откуда берется? Нужно нащупать определенную точку в толстой кишке, и оно включится? Или благодаря практическому опыту?
У тебя как всегда неадекватно сложные задачи. Мне так почему-то кажется, что проектировали itunes и google play люди с немного большим опытом, чем у меня, и потратили чуть больше чем полчаса.

Я не знаю, как это решить.
Например, как хранить ссылку на исполнителя трека? Исполнителем может быть либо группа, либо сольный артист (который может одновременно принадлежать к одной группе, а может даже и не одной). Если я сделаю две таблицы, для групп и для артистов, то я не смогу у трека выставить внешний ключ одновременно на две таблицы. Или создать два ключа? Тогда половина значений будет null, тоже некрасиво.
Можно создать таблицу исполнителей, где будут и группы, и артисты. Внешние ключи хранить в таблице групп и артистов на эту таблицу. Как например советуют здесь http://stackoverflow.com/questions/2002985/mysql-conditional-foreign-key-constraints
Скажем так

artist
- id
- name
...
- performer_id
foreign key (performer_id) references performer (id)

ensemble
- id
...
- performer_id
foreign key (performer_id) references performer (id)

performer
- id
- type (enum: artist, ensemble)

Но тогда я не представляю, как получить информацию по исполнителю.
Дай хоть слова, по которым гуглить.

>>568993
Сделал пока только часть задания (оно слишком большое).

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

performer
- id
- type (enum: artist, ensemble)

artist
- id
- name
- surname
- birth_year
- ensemble_id (fk, null если сольная карьера)
- performer_id (fk)

ensemble
- id
- name
- foundation_year
- performer_id (fk)

track
- id
- title
- short_description
- full_description
- release_date
- category_id (fk)
- type (enum: single, remake, remix, cover)

track_performer
- track_id
- performer_id (fk)

track_author
- track_id (pk, fk)
- author_id (pk, fk)

genre
- id
- name

track_genre
- track_id (pk, fk)
- genre_id (pk, fk)

album
- id
- short_description
- full_description
- release_date
- type (enum: album, tribute, remix, remake, collection)
- author_id (может быть null)

album_track
- album_id (pk, fk)
- track_id (pk, fk)

label
- id
- name

category
- id
- title
- label_id (fk)

price
- country_id (pk, fk)
- category_id (pk, fk)
- available (enum: y, n)
- base_price
- royalties

Не сделал пока подписки, продажи, отчеты, и что там еще требуется.

>>569214

> https://github.com/never3ver/catsandmice/blob/master/animals.php

В этом файле код плохой (с копипастой, все одной простыней без разбиения на функции, с логическими ошибками). К примеру:

> https://github.com/never3ver/catsandmice/blob/master/animals.php#L16

> $world->addAnimal(new Mouse(rand(0, $world->getWidth()), rand(0, $world->getHeight())));

Нет гарантий что клетка свободна

> https://github.com/never3ver/catsandmice/blob/master/animals.php#L10

> $tempX = rand(0, $world->getWidth());

Это потенциально бесконечный цикл, если вся строчка будет занята. Надо делать for с ограничением попыток вместо while.

Ну и код читается тяжело. Вот как можно было написать:

функция добавитьЖивотное(карта, животное) {
попытаться 10 раз {
сгенерировать координаты животного;
если (карта говорит что клеткаCвободна()) {
на карту поместитьЖивотное();
выйти;
}
}

выдать ошибку;
}

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

> https://github.com/never3ver/catsandmice/blob/master/animals.php#L30

тут вообще кошмар какой-то, версии с двоеточием предназначены для использования в HTML-шаблонах, а не в коде.

> https://github.com/never3ver/catsandmice/blob/master/classes/World.php

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

> https://github.com/never3ver/catsandmice/blob/master/classes/World.php#L43

Тут нет проверки что $key не пуст и животное вообще есть на карте, неаккуратненько

> https://github.com/never3ver/catsandmice/blob/master/classes/World.php#L49

> $x > $this->getWidth()

Тут не >= должен быть?

> https://github.com/never3ver/catsandmice/blob/master/classes/World.php#L59

> if ($critter instanceof Cat) {

> return "Cat";

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

> https://github.com/never3ver/catsandmice/blob/master/classes/World.php#L67

И тут тогда тоже надо будет поменять. Обычно если функция возвращает объект, его отсутствие обозначают как null, null для этого и придуман, чтобы показать отсутсвие объекта.

> https://github.com/never3ver/catsandmice/blob/master/classes/Animal.php#L43

> public function setWorld($world) {

Нужен тайп-хинт. Так как тут можно передавать и объект и null, не забудь приписать его как значение по умолчанию (ClassName $world = null), а то null проходить не будет. Мануал: http://php.net/manual/ru/language.oop5.typehinting.php

> https://github.com/never3ver/catsandmice/blob/master/classes/Animal.php#L6

> protected $awareness;

Вообще, это свойство мне кажется лишним. У нас ведь есть функция которая возвращает это число, зачем множить сущности? Свойство бы пригодилось если бы процесс вычисления был долгим, но там ведь одна строчка return, нет смысла усложнять код.

> https://github.com/never3ver/catsandmice/blob/master/classes/Mouse.php#L16

> public function makeMove(World $world)

зачем передавать world если он есть в животном?

> https://github.com/never3ver/catsandmice/blob/master/classes/Mouse.php#L80

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

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

> https://github.com/never3ver/catsandmice/blob/master/classes/Mouse.php#L88

> $rate = $distanceToCat + $pathsQuantity;

Ты складываешь 2 фактора, но одинаков ли вес этих факторов? Вот 2 ситуации:

- до ближайшей кошки 1 ход, из клетки 4 выхода, сумма = 5
- до ближайшей кошки 3 хода, из клетки 1 выход (допустим там пара мышей стоит), сумма = 4

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

Насчет расчета расстояния, ты считаешь декартово расстояние. Оно актуально в тех случаях когда мир изотропен (одинаков во всех направлениях), но у нас кошка при ходе по диагонали ходит не на 1, а на 1.41 (корень из 2) условных единицы. В таком мире логичнее считать не декартово расстояние, а сколько ходов надо кошке чтобы добраться до цели (с учетом что она ходит в 8 сторон). Это кстати можно вынести в отдельную функцию тоже.

> https://github.com/never3ver/catsandmice/blob/master/classes/Cat.php#L15

> public function getSymbol() {

> if ($this->sleepCounter == 8) { // если кошка съела мышку или сделала 8 ходов

> $this->sleepCounter = 0;

Вот это мина замедленного действия. У тебя функция называется getSymbol, то есть судя по названию она только возвращает текущее обозначение. А на деле она меняет состояние кошки (это называется побочный эффект). Что же будет если вызвать ее 2 раза?

$s1 = $cat->getSymbol(); // @
$s2 = $cat->getSymbol(); // C

Такого быть не должно. Методы которые называются «получить имя», «получить значок» не должны ничего менять в состоянии объекта и возвращать разные результаты при нескольких вызовах подряд.

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

> https://github.com/never3ver/catsandmice/blob/master/classes/Cat.php#L62

> $length = min($length);

> return $length;

Лучше писать return min($length);, а также не использовать одну переменную для хранения разных типов данных (массив и число).

В коде кошки несколько раз повторяется число 8, вынеси это в приватное поле либо константу с понятным именем.

И еще, у кошки и мышки функция makeMove похожа. Есть ли возможность вынести общий код в функцию базового класса?

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

>>569485

> Ну и у меня уже подсознательная тяга к ... реляционности.

Редис это NoSQL и тут надо мыслить именно ключами-значениями.

> И был вопрос о выборке необходимых ключей, я тогда знал только команду KEYS, которая перебирает все ключи, поэтому непродуктивна.

> Кажется, там еще есть команда SCAN, но я пока не понимаю, как она работает.

SCAN позволяет получать список ключей порциями. Она возвращает тебе допустим 10 ключей и специальное число-идентифиактор, который ты указываешь при следущем вызове чтобы получить следующие 10. Преимщуества очевидны: редис блокируется ненадолго в отличие от KEYS, на стороне PHP не нужна память чтобы хранить все ключи. Вообще KEYS это команда не для продакшена, это больше для отладки у себя на компьютере. Да и SCAN тоже больше для целей вроде экспорта данных, создания бекапов, отладки, и тд. Не стоит алгоритмы на ней основывать. NoSQL так неэффективно использовать.

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

> Что за "cursor"? О каком итераторе они говорят?

Это из баз данных, некоторые базы данных позволяют читать результаты запроса по мере выполнения (стримить), и там «курсор» это абстрактная структура которая позволяет получить следующий кусок ответа. В редисе он нужен чтобы следующий вызов SCAN вернул не те же самые данные, а следующий блок.

Там в мануале по SCAN первый раз выполняют команду scan 0, она возвращает 10 записей и курсор - число «17». Его передают во второй вызов scan 17, и получают следующие записи и новое значение курсора. И т д.

При использовании этой команды надо проверить в документации, а что если в процессе обхода ключей ключи добавляются или удаляются? Какие гаратии дает эта команда? Там отдельно есть абзац на эту тему.

> Ну хорошо, я согласен что нужно хранить отдельные ключи вместо хеша, только не понимаю как по ним искать нужные.

Можно оставить хеш, я не против. Но масштабируется лучше с отдельными ключами. Искать их не надо. Лучше сделать алгоритм который не требует обхода хеша (и не придется думать, что будет если хеш меняется в процессе обхода). Как раз очередь тем и хороша что данные там добавляются с одного конца, а снимаются с другого, и конфликтов не возникает, даже если мы делаем несколько операций (чтение + удаление блока отдельно).

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

>>в чем проблема накопления одинаковых id в очереди?

> Лишняя память. Зачем мне по сто-тысяче раз хранить в списке повторяющиеся значения, если можно хранить только уникальные?

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

Плюс, если у тебя просмотры идут на разные объявления, так что на одно приходится по 2-3 просмотра, то много мы не сэконоим, а вот алгоритм сильно усложняется: нам теперь надо атомарно очищать этот хеш p:v:a.

>Хорошо, сет тоже выбрасываем.

Рад что мы пришли к пониманию

> Я пока не в курсе, как реализованы транзакции в редисе, поэтому не понимаю почему транзакции препятствуют масштабированию.

Как минимум тем, что масштабирование подразумевает распределение нагрузки на N серверов (так как 1 не справляется), а транзакция выполняется на одном сервере. Механизмы распределенных транзакций между несколькими серверами сложны и в редисе их нет. Также они обычно бьют по производительности. Если используется отдельный сервер-координатор, то мы получаем еще и единую точку отказа. Если интересно, можешь на досуге подумать про то как сделать распределенную транзакцию c ACID, которая была бы устойчива к отключению серверов и нарушению каналов связи, но только не сломай голову, это реально сложная тема, сложнее чем все что ты тут изучал. Для начала можешь гуглить по словам «Distributed transaction», «two-phase commit», «CAP теорема».

Вот тут вроде простая статья: https://ru.wikipedia.org/wiki/XA_%D0%A2%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%B8

Если тебе нужен простой пример где нужна распределенная транзакция: представь банк, у которого данные пользователей разнесены на N серверов. Со счета на сервере A надо перевести сумму на счет, хранящийся на сервере B. Описанный выше протокол может использоваться для выполнения этого перевода с поддержкой ACID, но конечно производительность тут будет значительно ниже из-за многочисленных коммуникаций между серверами, приложением и координатором. Это не для хайлоада, а для случаев когда на первом месте надежность.

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

В редисе «транзакция» это не SQL транзакция с ACID, это просто команды накапливаются в буфере и выполняются атомарно (так как редис однопоточный) по команде EXEC. можешь почитать описание в документации редиса ( http://redis.io/topics/transactions ) и сделать сравнение с SQL ACID транзакциями.

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

> Сначала mysql конечно. Он же пишет на диск. Redis пишет в оперативную память, это пара милисекунд. Да, у нас остается точка отказа между этими двумя коммитами, но во-первых это промежуток наверное меньше милисекунды, во-вторых я просто не знаю, что тут можно сделать.

Я тоже. Есть конечно решение, которое описано выше, распределенные транзакции, но я думаю реализовать XA (который не поддерживается ни редисом ни MySQL как я понял) ради учета просморов объявления это излишне.

> 2.1. Парсим каждую строку вида "ip:id", чтобы получить ip и id, сохраняем в некий массив вида ['id страницы'=>кол-во посещений,].

А зачем нам в очереди хранить ip? Мы же кладем туда только уникальные просмотры (неуникальные отсеиваются хешем pvu).

> В этом поможет функция array_keys со вторым параметром. В конце этого шага получаем массив вида ['кол-во посещений'=>array('все id страниц с таким кол-вом посещений')].

Возможно тебе поможет функция array_count_values. array_keys это как-то сложно, лучше тогда просто циклом массив обойти и сгруппировать.

> Как видишь, здесь значительно больше телодвижений в самом php-скрипте,

Пусть. Это часть которую масштабирвать проще всего, просто ставим еще пару серверов.

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

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

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

>>569676

Константы надо хранить не отдельным объектом, а поместить в «класс» Гамбургер. То есть можно так:

Hamburger.SIZE_BIG = 'big';
или
Hamburger.SIZE_BIG = 1;

Значение константы это число или строка, не стоит в ней хранить данные, это будет уже не константа, а что-то странное.

Вместо того чтобы создавать методы при создании объекта, лучше создать их один раз, с помощью прототипов. Разберись с прототипами и реализацией классов на их основе. Твой подход имеет недостатки:

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

> var price = size.price + stuffing.price;

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

У тебя в коде нет никаких проверок на ошибки, передачу неправильных значений.

> кроме проверки на ошибки. Это нужно делать через try..catch? Там получается каждый метод в него нужно будет оборачивать?

Почитай урок про исключения и зачем они нужны (чтобы сообщать об ошибках). try/catch используется для ловли исключений тем, кто использует твой класс. А от тебя требуется только выкидывать их через throw.

То есть если ты раньше писал console.log("Неверно что-то передано"), теперь замени это на throw new HamburgerError(...) или new Error(...).

>>569750

Зачем писать 100500-й движок ИМ если есть готовые?

>>569771

Для начала начни с наших задач на HTML/CSS в ОП-посте. Показывай их на проверку. После того, как успешно выучишь все основы, там в конце есть макет, на нем можно будет потренироваться в адаптивности.

Вообще адаптивность это умение хорошо отображаться на разных устройствах. Она достигается за счет правильной «резиновой» верстки и переключения раскладки страницы на маленьких экранах через @media.

Я думаю для начала надо полностью освоить основы CSS и позиционирование, прежде чем браться за адаптивность. В заданиях есть ссылка на хорший блог softwaremaniacs, где хорошо это объясняется.

>>569831

Почему бы потихоньку не попробовать?

>>569896

Это справочник, а не учебник. А учиться лучше по нашим задачкам из ОП поста.

>>570096

> Предлагаешь что ли отдельно считать расстояние по X и по Y?

Ну число ходов нужное кошке чтобы добраться до мышки зависит от расстояния по X и Y. Вопрос, как? Попробуй рассмореть примеры которые я дал и найти зависимость. Не видишь?

> Не правда, кошка всегда будет проходить целое количество клеток. Высчитывание расстояния на это никак не влияет, только оценивает ход.

Если кошка на 3 клетки выше и на 3 правее, то твой код даст декартово расстояние = sqrt(18) = 4.24. Если кошка на той же строчке, в 4 клетках справа, расстояние до нее = 4. Кажется что первый вариант лучше, кошка дальше.

В нашем изотропном мире, где все направления равноценны, это так. Но в игре мир неизотропен. Кошка по диагонали двигается быстрее. В первом случае кошка доберется до мышки не за 4.24, а за 3 хода (по диагонали). Он хуже.

> Я совершенно не понимаю эту задачу.

Давай еще чуть помучаем расстояния. Разбери примеры которые я дал и сколько там ходов надо кошке.

>>570280

Разберись с наследованием, чтобы не изобретать велосипеды.

> На самом деле мелькала мысль сделать по принципу eav, но мне кажется это большим усложнением в данном случае.

EAV это замена наследованию когда классов сущностей огромное число (сотни), чтобы упростить систему. Но у нас всего 2 наследуемые сущности и EAV не подходит.

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

> ensemble

Тут id и performer_id по моему дублируют друг друга.

> track

> - category_id (fk)

По моему там на уровне альбомов же проставляется категория?

Связь между альбомами и треками M:N, почему? Один трек на разных альбомах разных лейблов может иметь разную стоимость и условия распространения.

>>570286
>>570310
>>570290
>>570326

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

Алсо я в общем согласен с постом, что ОП неплохой человек.

>>570319

Зависит от того, как ты настроишь. Там есть такие возможности:

- для разработки локально ты можешь встроить компилятор LESS/SASS на яваскрипте в веб-страницу. Тогда код компилируется в браузере, удобно тем что все изменения в файле применяются сразу, но страдает скорость загрузки и браузер притрмаживает.
- для выкладки кода на сервер ты компилируешь код в CSS с помощью компилятора, вызвая его напрямую из командной строки или через инструмент вроде gulp/grunt. Соответственно пользователь загружает итоговый CSS файл. Кстати, grunt/gulp умеют еще много чего: склеивать, сжимать файлы, делать CSS спрайты и тд. Правильные разработчики делают один скрипт деплоя который все это делает и автоматически загружает изменения на сервер.

Проверить что у тебя исплоьзуется можно глянув на исходный код страницы в браузере (Ctrl + U), или в dev tools (Ctrl + Shift + I) на вкладке network.

>>570374

Должен, если так написан договор. Более того, ты только разрешение продавать их треки у лейблов выпрашивать замучаешься, и там будет куча условий: минимальный объем продаж который ты обеспечишь (неустойка за провал плана), география распространения, обязательные отчеты, итд. Ты не можешь просто взять и продать 10 песенок, там счет идет на миллионы минимум. Раньше лейблы еще требовали использовать DRM, но благодаря Джобсу удалось это отстоять.

Также, лейблы не готовы продавать все песни. Например Битлз долгое время были недоступны в электронных сервисах, также бывает что новинки дают не всем, а только избранным. Есть по моему 3 крупных лейбла, с каждым надо договариваться отдельно. Также, есть еще мелкие лейблы, с которыми надо заключать отдельные договоры.

Истории по теме:

https://m.roem.ru/11-06-2015/197756/apple-music-no-rocks/
https://m.roem.ru/22-06-2015/198520/swift-wins/

>>570451

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

>>570470

Это плохой способ, там задачи часто неинтересные и малополезные. Полезные кстати есть в нашем треде.

>>570465

Учебник на народе из оп поста.

>>570475

Лучше наши задания на html/css из оп поста.

>>570521

В первую очередь для обозначения каких-то опций, где есть несколько вариантов выбора. Константы там используются для замены «магических» (т.е. непонятных) чисел и строк. Допустим ты делаешь игру, и в ней есть танки трех типов: легкий, средний, тяжелый. Ты хочешь обозначать как-то их типы:

$tank->type = 1; // плохо: что это значит? какие есть еще варианты? непонятно
$tank->type = 'light'; // что это значит? какие есть еще варианты? непонятно

Также, если ты опечатаешься то PHP не укажет тебе на это.

А вот как надо:

class Tank
{
// содержательный комментарий
const TYPE_LIGHT = 'light';
const TYPE_MEDIUM = ...
...

$tank->type = Tank::TYPE_LIGHT; // прекрасно: читабельно, PHP или IDE укажет на ошибку при опечатке, IDE покажет автодополнение, можно искать поиском по коду

Также, константы можно использовать например для хранения постоянных величин, например максимальная скорость танка:

const MAX_SPEED = 80;

> Вот, есть у меня класс с методом, в котором используются константные данные, но только в одном методе. Надо ли их объявлять, как константу класса? Или же достаточно описать просто, как переменную в конкретном методе?

зависит от ситуации и хочешь ли ты чтобы она была видна снаружи.

>>570655

Нужно больше подробностей. Что используешь, PDO или MySQLi, включен ли режим PDO::ERRMODE_EXCEPTION, в случае mysqli пишешь ли if после query, и тд. Что в логе ошибок ? Включен ли display_errors?

>>570707

Чтобы не быть пустословом, напиши важные пункты которые я не даю и наоборот, бесполезные знания которые я заставляю учить. Не больше 10 слов на 1 пункт. Пока будем считать тебя пустословом.

И да, хорошо анон написал, давайте меньше обсуждать личность ОПа, а больше программирование.

>>570790

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

>>570794

> смертной казни за оскорбление святынь ислама

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

>>570793

Через пакетный менеджер ubuntu (apt-get install?)

> Есть ли анонасы, у которых такая смесь работает именно на этой версии бубунты?

А как нгинкс взаимодействует с постгрес? По моему никак и соответсвтенно проблем совместимости быть не может.

>>570814

Наследование может быть? Ну или 2 отношения вида «пользователь купил альбом» и «пользователь купил трек» с 2 внешними ключами.

> Создать доп.таблицу "товар" и ссылаться на нее из таблиц альбомов и треков?

Это одна из форм наследования

> Мне не очень нравится такой подход с точки зрения размера полученной таблицы.

Тут нужна оценка. Мы создаем глобальный сервис и лишний гигабайт ничего не решает.

>>570842

Никогда не использовал. Не нравится много статических методов.

>>570845

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

>>570847

В документацию можно и тут послать.

>>571003

> Из 9 аккуратных строк кода мы получаем 14 (в нашем случае, а ведь в других может быть и в разы больше).

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

> Если объявлять константы отдельно на цену и на калории,

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

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

А чему она равна абсолютно не важно так как мы никогда не используем ее значение. Hamburger.SIZE_SMALL может быть равно 1 или 'small' - это ни на что не влияет.

Вот глянь еще тут пример с танками: >>570869

> то получается и передавать в аргументы при создании нового гамбургера нужно не 2 значения а 4

Нет. Мы передаем размер и начинку, а класс должен сам знать сколько они стоят.

>>571005

В первом примере:

SIZE_BIG: ...

SIZE_BIG это не константа, а лишь строка 'SIZE_BIG', ты не можешь в программе написать например console.log(SIZE_BIG), это выдаст ошибку о несуществующей переменной.

Во втором примере: не надо стоимость делать константами. КОнстанты нужны только для обозначения параметров гамбургера вроде размера или начинки.

Ну сам подумай: а как без констант указать какого размера ты хочешь гамбургер? с какой начинкой? Строки не годятся так как это не понятно, легко опечататься, непонятно какие еще есть варианты.

>>570868
А я кстати знал про эти паттерны, но не понимал в каких ситуациях их можно применить на практике.

Тогда применим Class Table Inheritance для групп и артистов.
Performer
- id
- еще какие-то общие свойства
Artist
- id (pk + внешний на performer(id))
- first_name
- surname
- birth_year и т.д.
Ensemble
- id (pk + внешний на performer(id))
- name
- foundation_year и т.д.

Я так понимаю, что выбирать из этих таблиц двумя джойнами с юнионом
SELECT p.id, a.name, a.surname FROM performer p JOIN artist a ON p.id = a.id
UNION (SELECT p.id, e.name FROM performer p JOIN ensemble e ON p.id = e.id)

Еще одна особенность такого подхода в том, что мы должны внимательно следить за бизнес-логикой в приложении, чтобы не заинсертить что-то неправильное, например в Artist и Ensemble записи с одним id.

>Почитай про паттерны наследования. Ты явно пытаешься их переизобрести

Я о них не знал/не понимал их.

>>571191

> Artist

- id (pk + внешний на performer(id))
Лучше назвать поле performer_id чтобы было понятнее.

А ты сравнивал варианты? Сравни-ка Single Table Inheritance против Class TI.

> Я так понимаю, что выбирать из этих таблиц двумя джойнами с юнионом

Юнион работает только когда список полей одинаковый. У тебя таблицы с разными полями и это осложнит жизнь, так что выбирай просто 2 джойнами.

> Еще одна особенность такого подхода в том, что мы должны внимательно следить за бизнес-логикой в приложении, чтобы не заинсертить что-то неправильное, например в Artist и Ensemble записи с одним id.

Это да. Или рассмотреть еще другие варианты наследования.

>>571205

Нет, погоди, зачем незарегистрированному пользователю кука? Куками обычно идентифицируют зарегистрированных.

>>571207

strval(...), почитай примеры по smplexml в мануале PHP, там отдельная страница есть.

>>571208

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

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

Потому тебе надо разбраться в CSS как следует. Гармоничный HTML и CSS код вряд ли вызовет у тебя неприятные ощущения, скорее наоборот, удовлетворение от хорошо сделанного дела.

> пусть цены формируются так: лейбл выделяет несколько категорий, каждый альбом относит к категории и задает цену на трек и на альбом отдельно

Категория задается для альбома? Значит, трек обязан входить минимум в один альбом, даже если это сингл?

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

Лицензионные отчисления зависят от страны, как это было в случае с ценообразованием? И они вообще в чем измеряются, в процентах?

>>571340

>анон, который Юи делает, а ты дебаггер в своей IDE настроил и освоил?

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

>>571337

>А ты сравнивал варианты? Сравни-ка Single Table Inheritance против Class TI.

Сравнивал. STI мне не нравится из-за большого кол-ва нулевых значений. Хотя да, она нас обезопасит от вставки одинаковых id, с чем мы можем столкнуться в Class TI.
И джойны будут не нужны. Ок, заменяем на STI.
Concrete TI не рассматриваю, потому что эта схема имеет все недостатки Class TI, плюс отсутствует "общая" таблица, ради которой эти пляски и затевались.

Короче, у меня пока получилось так
Performer
- id
- first_name
- surname
- group_id (внешний ключ на эту же таблицу, null если музыкант не состоит в группе)
- birth_year и пр.атрибуты музыканта
- group_name
- foundation_year и пр.атрибуты группы
- type (enum: artist, group)

Country
- id
- name

Label
- id
- name
- country_id (fk)

Category
- id
- name
- label_id (fk)
- album_base_price
- track_base_price

Category_country
- category_id (pk, fk)
- country_id (pk, fk)
- local_album_price
- local_track_price
- available (enum: y, n)

Tariff
- id
- label_id (fk)
- type (enum: trial, premium)
- tracks_total (макс.кол-во треков доступно для прослушивания)
- tracks_total_free
- one_track_per_day (допустимое кол-во прослушиваний треков в день)
- one_track_per_day_free
- one_album_per_day (допустимое кол-во прослушиваний альбомов в день)
- one_album_per_day_free
- one_performer_per_day (треков исполнителя в день доступно для прослушивания)
- one_performer_per_day_free
- purchase_fee (отчисления за покупки)
- trial_fee (отчисления за бесплатные прослушивания)

Subscription
- id
- name (trial, premium)
- duration

Audition
- id
- user_id
- track_id

User
- id
- email (null для незарегистрированных)
- password (null для незарегистрированных)
- country_id
- прочие свойства пользователя

Content
- id
- title
- length
- track_album (fk на эту же таблицу)
- album_type (enum: simple, remix, tribute и т.д.)
- release_year
- content_type (enum: album, track)

Genre
- id
- name

Content_genre
- content_id
- genre_id

Content_author
- content_id
- performer_id

Content_performer
- content_id
- performer_id

Purchase
- id
- content_id
- дата покупки и т.д.

User_subscription
- user_id
- subscription_id
- expired

Там еще какие-то рекомендации, непонятно как их делать, и нужно ли их хранить отдельно в базе, или выводить из анализа продаж в приложении.

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

Не знаю, допустим сделаем таблицу
Promo
- album_id
- expired

Теперь нужно еще написать запросы на выборку из этой свалки.

>>571539

> Короче, настройки "save 1 1" вполне хватит. (сбрасывать на диск каждую секунду)

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

А чтобы ты знал что искать в этом мануале, объясню. В редисе есть 2 способа сохранения: RDB и AOF.

RDB - это сохранение снапшота (снимка) всей базы в файл. Как сделать снимок многогигабайтного массива данных и сохранить, не останавливая работу редиса? Для этого использется форк. В линукс-системах форк - это операция, которая создает полную копию процесса, то есть выделяется память и все содержимое памяти редиса копируется в нее, и появляется второй процесс-клон первого, который не спеша сбрасывает на диск гигабайты данных. Так как это отдельный процесс, то он никак не мешает редису. Редис блокируется только на время выполнения форка.

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

Разумеется сделать копию огромного объема данных мгновенно нельзя. Но ОС оптимизирует форк, вместо реального копирования она использует copy-on-write ( http://freesource.info/wiki/Texnologii/CopyOnWrite& ), то есть одни и те же страницы памяти отображаются в оба процесса и реально копируются только когда один из них пытается что-то в них поменять. Если редис особо ничего не меняет в памяти, то копирования не происходит, оба процесса работают с одной областью памяти.

После того как произошел форк, процесс-копия записывает данные в файл. Последовательная запись данных на диск - это наиболее эффективный режим его работы и скорость записи может достигать 100-200 Мб/с. Но даже так, на сброс 3 гб данных нужно около 15 секунд.

Очевидно что твоя идея с save 1 1 во-первых, не сможет сбрасывать данные каждую секунду, во-вторых, будет генерировать огромный дисковый трафик, полностью загружая диск постоянной перезаписью текущего снапшота. Соответственно для всех остальных процессов диск начнет отвечать с большой задержкой.

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

Потому снапшоты нельзя делать часто.

И потому в редисе есть второй способ сохранения данных - AOF. AOF значит append only file, то есть файл, данные в котором дописываются только в конец. Почему только в конец? Чтобы ни при какой ситуации не повредить ранее записанные данные и потому что тут опять получается последовательная запись, самый эффективный режим работы магнитных дисков.

Редис пишет в AOF файл все полученные от клиентов команды, например SET key value. При успешном сбросе RDB снапшота на диск лог очищается (так как эти данные есть в снапшоте).

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

Если мы будем писать данные в AOF после каждой операции, да еще и дожидаться физического сброса на диск, то наша система будет очень надежной, и будет гарантировать сохранение данных в любой ситуации. Как MySQL. Но при этом она станет медленной так как редис однопоточный, на сильно загруженной системе диск занят еще и другими делами и большую часть времени мы будем ждать его реакции. И никаких десятков и сотен тысяч записей в секунду нам не видать.

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

Лог обычно генерирует небольшую нагрузку на диск так как записываются в него только приходящие команды, если одна команда имеет размер 100 байт и идет 10 000 команд в секунду, это 1 Мб/с дискового трафика.

Однако лог имеет свои недостатки. Если не использовать RDB то лог будет расти неограниченно. Такой лог может занять все свободное место на диске, и восстановление данных будет очень долгим.

Потому у администратора есть большой выбор вариантов сохранения данных:

- отключить RDB/AOF
- использовать только редкий RDB
- использовать RDB + AOF с разными степенями надежности

Также, даю тебе почитать вот такую статью, сделанную разработчиками вконтакте (они тоже пилили свои хранилища наподобие редиса, у них же хайлоад), вдруг что полезного найдешь: https://github.com/vk-com/kphp-kdb/blob/master/docs/ru/DBMS_Storage_Comparison.wiki

>>571587

>Редис пишет в AOF файл все полученные от клиентов команды, например SET key value. При успешном сбросе RDB снапшота на диск лог очищается

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

Все это чудесно в теории, но где искать настройки? save единственная, которая упоминается в мануале, потому ее и притащил. Но я уже понял, что она отвечает за RDB, то есть за снапшоты, их не нужно делать часто.
save 900 1 // делаем снимок каждые 15 мин
В документации вижу только ссылку на файл с примерами тысяч настроек https://raw.githubusercontent.com/antirez/redis/2.8/redis.conf
Мне это все читать ради 2-3 строчек, которые мне реально понадобятся?
А нет, пронесло, вроде не так и много, ладно.

>By default Redis does not run as a daemon.

А у меня почему-то запускается автоматически (ставил апт-гетом).
Там они говорят только запускать его руками командой ./redis-server /path/to/redis.conf

>daemonize no

У меня прописано yes.
loglevel notice
logfile /var/log/redis/redis-server.log
dir /var/lib/redis // папка, куда складываются rdb и aof файлы

Нашел наконец-то
appendonly yes // +
appendfilename "appendonly.aof"
appendsync everysec // +
no-appendfsync-on-rewrite yes // +
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Должно хватить. Был отключен режим appendonly и синхронизацию ставим в everysec. И еще опция no-appendfsync-onrewrite выставить в yes, чтобы лог продолжал вестись даже в момент сброса rdb. Остальное по умолчанию.
А, самое главное забыли
maxmemory 512mb

Я не знаю как быть, у меня на нетбуке всего 2 гигабайта, из них убунту съедает 800mb при запуске, хром еще 300-400.
Как-то можно войти в систему минуя графический интерфейс, как на настоящий сервер, чтобы оно мне не засирало память?

>>572349

Ты можешь пока порешать что-то еще, ОП придет, проверит твои задачи и даст тебе нормальные советы.

По этой >>571991 задаче один из вариантов решения такой:

Заводим переменные для результата, накапливаемого числа, знака операции.

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

Ты можешь попробовать это расписать так: допустим у нас строка 25 + 34 - 17 = . Вот как она обрабатывается

Текущий Символ | результат | накопитель | операция
---------------
2 0 2 ?
5 0 25 ?
+ 25 0 +
3 25 3 +
4 25 34 +
- 59 0 -
1 59 1 -
7 59 17 -
= 42 0 =

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

>>572383

> Роялти может зависеть от страны пользователя

Ну тогда избавляемся от таблицы tariff, переносим следующие атрибуты в таблицу category_country
- tracks_total (макс.кол-во треков доступно для прослушивания при наличии подписки)
- tracks_total_free (... во время пробного периода)
- track_perday (макс.кол-во прослушиваний одного трека в день)
- track_perday_free (... во время пробного периода)
- purchase_royalty (отчисления за покупки)
- audition_royalty (отчисления за бесплатные прослушивания)

Второй запрос

>Поиск доступных пользователю альбомов, треков по тем же критериям

Под "доступными" подразумеваются надо полагать те альбомы и треки, на которые не истек лимит прослушиваний. Те, которые запрещены в данной стране, отсеиваются условием WHERE category_country.available = 'y'.
Прослушивания сохраняются в таблицу audition. Условие для проверки исчерпания лимита прослушиваний будет выглядеть как-то так:
SELECT x FROM content c1
JOIN content c2 ON c1.track_album = c2.id
JOIN category c3 ON c2.category_id = c3.id
JOIN category_country c4 ON c3.id = c4.category_id
JOIN audition a ON c1.id = a.track_id
WHERE (SELECT COUNT(*) FROM audition WHERE user_id = 'uid' AND audition.date = CURDATE()) <
(
IF("проверяем тип подписки" = 'premium',
SELECT c5.track_perday FROM category_country c5 WHERE c3.id = c5.category_id AND c5.country_id=(SELECT country_id FROM user WHERE user_id = 'uid') ),
SELECT c5.track_perday_free FROM category_country c5 WHERE c3.id = c5.category_id AND c5.country_id=(SELECT country_id FROM user WHERE user_id = 'uid') ),
)
AND (то же самое для проверки tracks_total).
Хотя еще не учел длительность подписки.
Короче, это какой-то пздц. Вроде бы ничего сложного, если разбить на мелкие части, но удержать в голове целую картину, все эти связи, таблицы и т.д., немного проблематично.
Я лучше пока вернусь к заданиям попроще.

>>572657

Разумеется, все замечания которые я написал, они не просто так, а имеют какую-то причину.

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

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

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

То есть код должен выглядеть примерно так:

function Hamburger(size, stuffing) {
this.validateSize(size);
this.validateStuffing(stuffing);
...

Функции здесь нужны чтобы не раздувать размер конструктора и потому, что их названия служат комментарием. Ты как-то не так меня понял.

По коду

> this.toppingsArr = {

> toppingSause: 0,

У тебя жестко заложен список добавок, лучше бы использовать в качестве ключей сами константы:

this.toppings[Hamb.TOPING_ZZZZ] = true;

Так добавление нового вида добавки не потребует правки кода в этом месте.

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

Почему ты выбрал словарь для хранения добавок, а не обычный массив?

> if (topping == Hamburger.TOPPING_SAUCE) {

> this.toppingsArr.toppingSause++;

> }

> if (topping == Hamburger.TOPPING_MAYO) {

> this.toppingsArr.toppingMayo++;

> }

Тут нужен более обобщенный код, не перечисляющий каждый вид добавки

Далее, функция Hamburger.prototype.addTopping написана неправильно. Вот как она сделана у тебя:

- добавить добавку
- проверить правильность переданных аргументов

А вот как надо:

- проверить правильность переданных аргументов
- добавить добавку

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

Мой вариант лучше защищен от ошибок. Это называется exception safety, безопасность относительно исключений. В моем варианте если объект выбросил исключение, им все равно можно пользоваться так как я гарантирую что он остается в корректном состоянии.

В первом варианте нет exception safety. Если объект выбросил исключение, то им дальше пользоваться нельзя так как не гарантий что он в корректном состоянии.

Я вижу, ты в коде попытался добиться exception safety, вручную сбрасывая число добавок до 1 при ошибке. Но это лишнее усложнение, достаточно просто поставить проверку в начало функции и это будет не нужно.

> Hamburger.prototype.calculateCalories = function () {

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

>>572622

Все эти усложнения лишь запутывают пользователя и не нужны. Если у тебя у статьи может быть ровно 1 категория, используй категории, если несколько то исплоьзуй теги.

> Например, на автомобильном сайте по типу статьи и по производителю

Что значит «тип статьи» ? В любом случае все эти навигации как правило делаются для поисковых роботов, а люди ими редко пользуются так как они запутанные или там сотни тегов и ничего не понять.

Насчет того как делать URL есть простое правило: 1 страница = 1 URL. не может быть 2 одинаковых страниц с разными URL, не может быть 2 разных страницы с одним URL. Твоя схема навигации должна это учитывать.

Ну и традиционно URL рассматривают как путь по разделам, вроде

/news/politics/some-new.html - раздел новости, подраздел политика, страница новости

Вот мой урок с обзором схем URL на примерах: https://gist.github.com/codedokode/772a4ccc03e41d6b7cba

> Не будет ли путаницы, ведь кто-то может захотеть с несколькими тегами сразу работать

Живой человек вряд ли

> Вроде избавляет от лишних полей в БД, но вместо поиска по varchar будет полнотекстовый индекс и поиск по большим текстовым полям.

Ты мешаешь все в кучу. Какая база данных, мы вроде систему URL проектируем? Проектируй схему URL не оглядываясь на БД, она тут вообще никаким боком не относится.

Схема URL на яндекс-маркете очень адекватная.

> https://market.yandex.ru/product/123456/spec?hid=567839&track=tabs

Сразу все понятно: это продукт с id = 123456, страница характеристик. Дополнительные параметры видимо используются для статистики.

> видишь менюшку сверху? И менюшку справа? Обрати внимание, категории пересекаются, они разных типов. Вот тебе двойная навигация.

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

Если то-то непонятно, задавай конкретные вопросы.

Анон, который делает счетчик посещений на редис. Есть предложение сделать счетчик отдельной независимой от Юи и (может быть) клиента редиса библиоеткой. Чтобы его можно было подключить к любому проекту через композер. Подробно расписывать пока некогда, потому пишу кратко.

Зачем?

- чтобы использовать правильный подход. Например в мире Node.JS очень много маленьких библиотек, делающих только одну вещь
- чтобы его можно было подключить к любому сайту на любом фреймворке и любом redis клиенте
- больше шансов что код кому-то пригодится и не умрет в безвестности
- можно продемонстрировать что ты умеешь выделять отдельные компоненты в библиотеку
- можно попробовать пропиарить библиотеку в виде поста в блог или на хабр, попробовать добавить ее в packagist (не знаю впрочем, стоит ли)

Затраты по времени примерно такие:

- создать новый репозиторий = 10 мин
- сделать composer.json = 10 мин
- сделать readme с понятным описанием = 1 час
- рефакторинг кода с вынесением зависимостей = 2 часа
- сделать пример подключения (в качестве документации) = 1час
- подключить к основному проекту сайта объявлений через композер = 10 мин

Конечно хорошая библиотека еще должна быть покрыта тестами, но это требует времени (разобраться с тестами = 6 ч, написать и отладить = 8 ч) и я не знаю, есть ли оно у тебя.

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

>>572483

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

>>573315

для начала прорешай наши задачки на HTML/CSS из ОП-поста чтобы закрепить знания CSS. Когда решишь все задачи, там в последней задаче будет PSD-макет который надо сверстать.

> Вот как ставится задача верстале на настоящей работе?

Бывает дают макет, бывают на словах объясняют («тут надо бы меню покрупнее сделать и чуть вправо сдвинуть»).

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

Нет, неправильный порядок. Сначала ты смотришь на макет и пишешь семантичный (осмысленный) HTML-код, который содержит все основные блоки, текст, праивльно размеченный тегами. А только потом пишешь CSS чтобы этот код выглядел как требуется. И по мере написания подставляешь нарезанные картинки.

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

>>573321

Ты чего злой такой?

> Ебать, не сделаешь же в меню пункт "все"?

А где я написал что его надо сделать?

> Плюс, категорий каждого типа может быть десяток, это что, сто вариантов в .htaccess прописывать?

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

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

> Просто если к твоему варианту добавить теги, то /tags/android и /all/android по сути будет вести на один и тот же набор материалов, нормально ли это?

нет, у одной страницы должен быть один URL, а не два.

> Может вообще ВСЕ категории сделать на тегах?

Ты под архитектуру вордпресса подгоняешь систему? Так бы и написал. Я исходил из того что мы можем сделать любую схему URL и соответтвенно никаких ограничений нет.

>>573322

Не очень понимаю. ЧТо нам мешает сделать свойства «тип материала» (статья, обзор) и «категория» (андроид, ноутбуки ) и тд? Теги используются когда нужно отнести материал к нескольким категориям. Или ты на вордпресс ориентируешсяь? Тогда надо было так и писать, а не сбивать людей с толку.

>>573323

Нарезать задача верстальщика. Так же как и выбрать оптимальный формат картинок например.