Сергей Семенко

Boot - это просто автоконфигуратор и запускалка, позволяющий не писать конфигурацию контекста вручную и не разворачивать приложение на сервере приложений.

Используй try/catch, про колбеки можешь забыть. Раньше только так можно было отловить какие-то исключения во время выполнения, теперь в них нужды нет.

Код чище, понятнее.

async getAll(req, res) {
    try {
       const { rows, rowCount } = await db.query(query)
       return res.status(200).send({ rows, rowCount })
    } catch (error) {
       return res.status(400).send(error)
    }
  }

как писать поддерживаемый код?

Если уж очень коротко, то соблюдать SOLID/GRASP. Мне понравился твит одного из авторов React Router:
https://twitter.com/mjackson/status/1171524189850701825

Most common mistake software developers make: putting stuff in the wrong place. Coupling responsibilities and concepts that should be kept separate.
For me, this is 95% of software development. Just figuring out *where* things belong.

Что гуглить, что учить?

Фундаментальные знания, вроде вышеупомянутых SOLID/GRASP, паттерны (не только классические паттерны, но и вообще, общеизвестные решения определённых задач), базовые структуры данных. Фреймворки/библиотеки всегда будут приходить/уходить, что-то будет забываться. А фундаментальные знания всегда актуальны.

Может литературу какую почитать посоветуете?

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

Можно ли себя называть миддлом, если твой код говно?

Не пытайтесь себя оценить. В каждой компании свои понятия миддла. А если кто-то 35 лет на лиспе кодил, а потом прыгнет на Angular - кто он, джун или сеньор?
И, да, все мы в какой-то степени пишем говнокод. Если кто-то Вам доказывает, что он пишет супер чистый код - не слушайте.

И ответ на главный вопрос.

Как перестать говнокодить и принимать неверные архитектурные решения?

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

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

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

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

Добро пожаловать в асинхронность.
request() выполняется асинхронно. Вот вы его вызвали, он внутри себя запомнил, по какой ссылке нужно (будет) обратиться и куда вернуть результат. И внешний вызов request() всё, отыграл.

Веб-запрос ещё не пошёл выполняться, а уже работает следующая итерация вашего цикла for().

Все запросы пойдут выполняться почти параллельно. Поэтому и длительность десяти запросов примерно равна длительности одного.

Хинт не по теме вопроса, а

По довольно распространённому соглашению, все параметры после двойной черты считаются позиционными (чаще всего это имена файлов). git придерживается этого соглашения.

Например кто-то случайно создал файл с именем -n, а вы хотите вывести все файлы в папке командой cat

$ ls -l
total 8
-rw-rw-r-- 1 lynn lynn 6 Apr 19 12:34 file1
-rw-rw-r-- 1 lynn lynn 6 Apr 19 12:33 -n

если просто выполнить cat *, то получится странное:

 $ cat *
     1	file1

потому что bash раскрыл звёздочку и получилась команда can file1 -n, т.е. вывести файл file1 с нумерацией строк.
А вот так всё выведется правильно:

$ cat -- *
file1
a
b
c

Потому что раскроется в cat -- file1 -n, но по соглашению, после -- не может быть ключей команды, только имена файлов.

Конкретно в git есть ещё более строгое соглашение, по которому параметры после -- могут быть только путями.
Например если у вас есть файл test и ветка test, то будет так:

$ git branch 
* master
  test

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   test

no changes added to commit (use "git add" and/or "git commit -a")

$ git reset test
fatal: ambiguous argument 'test': both revision and filename
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

$ git reset -- test
Unstaged changes after reset:
M	test

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

Является ли желтая квадратная форма в конце анимации видоизмененной кнопкой или же это совершенно другой элемент разметки?

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


С такими анимациями можно долго играться, самое главное - проверить в конечном итоге кроссбраузерность. А то в хроме и FF работает, а в каком-нибудь IE всякое может случиться.

P.S.: Но в целом - я голосую за реализацию таких вещей целиком на JS. Практика показывает, что в проектах с такими анимациями очень быстро собирается большое количество одновременно анимирующихся значений у большого количества элементов, которые нужно синхронизировать между собой. На CSS голова лопнет все это делать. И да, чем больше всего меняется в CSS-анимациях в единицу времени, тем выше шанс найти какой-нибудь редкий баг и долго ломать себе голову в поисках проблемы. Лучше уж взять какую-нибудь библиотеку вроде anime.js или любимый многими GSAP и использовать их.

https://status.github.com/messages

* Requires Microsoft Windows 10 Professional or Enterprise 64-bit - https://www.docker.com/docker-windows

полазь по сайту
поспрашивай в телеграмме