Роман

https://serversforhackers.com/

Болшая часть кода redmine сложно назвать чем-то хорошим. Методы на 50+ строк тут считаются нормой. В проекте тонны легаси-кода. Так как история редмайна началась ооочень давно, когда даже rails еще не был мейнстримом, часть решений redmine стали конфликтовать с аналогичными решениями rails, которые появились несколько позже. Все эти проблемы решаются стандартным для руби способом, манкипатчингом. В итоге нет нормальной поддержки i18n, нет sprockets (подключить костылями можно, но даже после того как оно заведется, проблем будет достаточно), фронт из нулевых (и внешне и внутренне), адекватность внутренней логики часто под большим вопросом, особенно что касается старого кода.
Стабильная версия redmine работает на rails 4.2, но на подходе новая версия с rails 5.2.

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

Но при всем при этом, так как это руби, обходные пути можно найти почти всегда, положительные тенденции в кодовой базе имеются, хотя и на низком уровне. С минимальными костылями можно переиспользовать систему фильтров как в задачах. Хотя с некоторой кривостью данной сиспридется смириться или долго и мучительно слать пулл-реквесты (которые в случае redmine оформляются в виде задач на redmine.org с прикладыванием патчей).

О себе. 5 лет работаю с redmine, но, так как задачи не связаны напрямую с redmine и rails, особой боли не испытываем. Жить можно.

никаких, так делают имбицилы

попробуйте блокам которые не нужны при печати добавить visibility: hidden
блоки будут не видны, но место которое они занимают останется.
htmlbook.ru/css/visibility

Зачем проектировать свой, плохой поиск (потому что не так-то просто найти специалистов, способных сделать хороший, они все в Гугле давно работают), когда может быть можно, например купить яндекс-сервер для локальной сети? Или он вам не подойдет?

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

Или разбиение на слова. Многие системы при индексации разбивают текст на слова. Разбивать ли текст по знаку «минус»? будет ли находиться слово, разбитое переносом: «обык-новенный»? Будет ли разбито на части слово RMT-2600? И будет ли поиск по нему работать? Будут ли находиться слова с опечатками? «обыкновеный» и «Обыкновенный»? А поиск цифр (кодов), если в тексте он в виде 3-123-124, а пользователь вводит без дефисов?

Отдельная песня — поиск фамилий. Johansonn, Йохансон, Иогансон, Йохансонн. Обработка юникодных символов вроде ́́́a?

Сможете ли вы индексировать например DOC, PDF и другие форматы, которые используются.

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

Также, есть проблема ранжирования. Искомое слово встречается в 300 документах. Естественно, все 300 никто смотреть не будет, будут смотреть первые несколько десятков, вопрос, как ранжировать эти 300 документов, чтобы вначале шли более релевантные?

Если в запросе несколько слов, надо ли искать каждое слово отдельно? Или обязательно присутствие всех слов на определенном расстоянии?

Вот смотрите, сколько сложнорешаемых проблем выскакивает после 10 минут раздумий.

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

А то, что пишут выше, про LIKE % и Windows Search, вообще ничего, кроме огорчения не вызывает.

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

То, что в вашем вопросе не упомянуты слова «индекс», «ранжирование» и прочее, меня настораживает.

Вы, кстати, можете посмотреть, как устроена посиковая система sphinx, но я сомневаюсь, что сфинкс сам по себе способен решить описанные мной проблемы. Он скорее способен выполнить (средненько) роль индексирующего и ищущего компонентов.

Тоже столкнулся с этим, но нашел ответ:
https://medium.com/devschacht/%D1%80%D0%B5%D0%B0%D...

в твоем случае нужно присваивать новое значение через Vue.set
Vue.set(checkboks, 'state', 1)

надеюсь поможет

Да, есть способ лучше. Дать щщей дизайнеру за такое.
А по делу: я бы взял 4 дива и не переживал по поводу лаконичности.

Zeplin, Avocode, Invision.

3. Развиваться в самом бекенде - php

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

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

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

Конечно же написанное всё имхо)

methods: {
  async fetchData() {
    this.showPreloader = true;
    const promises = this.items.map(item => axios.get('/api/items/${item.id}/'));
    const results = await Promise.all(promises);
    this.showPreloader = false;
  }
}

Мартин Фаулер круто пишет обо всех паттернах. Про DI можно почитать тут. Вообще у него отличный блог. И он же автор книги P of EAA. Правда русский ее перевод крайне не рекомендую читать, можно только запутаться, так что читайте в оригинале.

Если хотите разобраться с паттернами, то самая простая (и при этом дельная!) книга - это Фриман&Фриман. Ее можно читать и на русском.

Применительно к PHP - вот лучшая книга про шаблоны (и не только), которую я видел PHP. Объекты, шаблоны и методики программирования от Мэт Зандстра.

Порядок прочтения рекомендую следующий: Фриман&Фриман, затем Мэт Зандстра, и на десерт Фаулера P of EAA.

UPD:
Важно отличать паттерн Dependency Injection от Dependency Injection Container.
Простейший пример внедрения зависимости:

interface IEngine {}
 
class V8Engine implements IEngine {}
 
class Car {
  public function __constructor(IEngine $engine) {
    $this->engine = $engine;
  }
}
 
$car = new Car(new V8Engine());

Простейший пример игнорирования явного внедрения (для такого кода трудно писать unit-тесты, его труднее понимать и править):

class V8Engine {}

class Car {
  public function __constructor() {
    $this->engine = new V8Engine();
  }
}

$car = new Car();

Отличный (и легковесный) пример DIC - это pimple:

// define some services
$container['session_storage'] = function ($c) {
    return new SessionStorage('SESSION_ID');
};

$container['session'] = function ($c) {
    return new Session($c['session_storage']);
};

Советую прочитать и понять его исходники, чтобы убедиться, что в DIC (во всяком случае для PHP) нет никакой магии. Первая версия была всего ~100 строк. Необходимо также отметить, что класс Session использует шаблон Dependency Injection, явно определяя свою зависимость от SessionStorage. А контейнер делает лишь правильную связку.

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

задача — считать, сколько времени я провожу за работой

• ManicTime - мощный стэндалон тайм-трекер. Очень гибкий в настройках, сидит в трее, есть хоткеи, разные типы таймеров. Платный.
  
• RescueTime - только в автоматическом режиме логирует, в каких приложениях/сайтах проводите время, и выводит подробную статистику. Бесплатного аккаунта хвататет за глаза.
  
• Toggl — отдельный софт в трее, расширение под хром, приложение на андроид. Интеграция с кучей сервисов (трело, асана и т.д.). Хоткеи тоже есть. Бесплатного тарифа вполне достаточно.
  
• TimeDoctor — платный. Есть отдельный софт в трее, хоткеи. Интеграция с кучей сервисов.
  
• Pomello — простой помидоро-трекер, интеграция с трелло. Хоткеи есть, в трее не сидит, простенький бар поверх всех окон
  
• PomoDoneApp — простой помидоро-трекер, интеграция с трелло. Хоткеи есть, в трее показывает таймер с обратным отсчетом времени.
  
• tmetric.com — простой трекер, интеграция с трелло, есть десктопное приложение, помидорок нет. Хоткеи есть, сидит в трее
  
• Вот еще статья на хабре от 2015 г. https://habrahabr.ru/company/xakep/blog/254119/
  

доп инфа тут: Чем удобнее всего учитавать время работы над конкретной задачей?

Я использую связку Trello+Toggl+Pomello

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

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

Так что посоветую 2 варианта изучения.
1) Тупо работаешь над сложные проектами, только действительно сложными, а не сайтиками на cms. И со временем ты начинаешь встречаться с проблемами. Тогда открываешь паттерны и тебе не придется даже как то их особо понимать, потому что это будет естевственно для тебя. Я думаю ты используешь ide вместо редактора кода. Но к примеру я помню тот момент, когда я пользовался саблаймом и знал, что есть ide, но я писал на тот момент простые вещи и когда мне говорили, почему я не юзаю ide, ведь в ней столько всего, я не понимал их потому что мне и саблайма за глаза хватало. Но пришло время, когда надо было то и се и саблайма стало мало. И тут открываю ide, а там уже есть все необходимое и думаешь в такие моменты, как я раньше этим не пользовался. А дело в том, что раньше и не надо было. Может неудачный пример, но вы поняли ) Конечно, этот вариант изучения не совсем реален, по скольку сложный проект еще найти надо, да еще попасть в команду, которая не говнокодит, так как и крупные проекты бывают достаточно плохо написаны. Но можно как вариант к примеру делать свою cms и применять в ней как можно больше паттернов.

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

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

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

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

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

2. Использование готового фрейморка, с которым вы никогда не работали
Готовьтесь потратить массу времени на его изучение. Порой даже на решение тривиальных задач в некоторых фреймворках придется потратить несколько дней, если вы с этим никогда не работали. По собственному опыту могу сказать, что если сравнивать варианты (2) и (4), то готовьтесь потратить в 3 — 4 раза больше времени. Однако у этого варианта есть и плюсы: вы освоите ещё один фреймворк и в следующих проекта сможете выбирать вариант (1), другим разработчикам знакомым с данным фреймворком будет гораздо проще разобраться в коде, последующая разработка и развитие проекта существенно ускорятся.

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

4. Вообще без фреймворка
Такой проект сильно рискует превратиться в спагетти-код. Но абсолютное большинство новичков начинает именно с этого. В этом нет ничего страшного, если это ваш первый проект, вы освоитесь с языком и его возможностями, набьете кучу шишек, и неизбежно рано или поздно перейдете к вариантами (1), (2) или (3).

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

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

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

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

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions