cogden

lamp - это просто название стека.
а как его ставить (по отдельности или готовые сборки) рояля особого не играет.

потому что становиться легко выстрелить в коленку.
например, при рефакторинге переименовав переименную не во всех методах и тому подобные сайдэфекты.
или установив сторонний модуль/библиотеку/etc, где используется переменная с таким же именем.
усложняется контроль данных и еще куча всего. нет особого смысла повторять что уже было написано:
https://cbabhusal.wordpress.com/2015/09/27/ruby-wh...
softwareengineering.stackexchange.com/questions/14...

нафига, тут вообще js?
это уже давно решается на чистом css. например, https://codepen.io/rm/pen/ldhon

textField.isEditable = false не?

теги переименовываются при помощи клика на теге и нажатия Shift+F6

можно еще так:

echo 'sha384-' . base64_encode(hash_file('sha384', 'path-to-file', true));
// или
echo 'sha384-' . base64_encode(hash('sha384', file_get_contents('path-to-file'), true));

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

стоит вообще рассматривать ssd

стоит. если цена не смущает.

Стоит купить 2 диска по 500гб или 1 на 1тб ?

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

https://developer.mozilla.org/ru/docs/Web/JavaScri...

домен никак не касается того, кто на нем зарабатывает деньги.

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

Во-первых, изменяется система адресации документа. Если вы сохраните документ методом saveXML(), а затем загрузите его снова методом loadXML(), то в новом документе последовательно расположенные текстовые узлы сольются в один узел. Таким образом, одна и та же информация будет иметь различное логическое расположение в документе.

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

Чтобы избежать этих проблем, в стандарте DOM2 в интерфейс Node (класс domNode РНР 5) введен метод normalized. Данный метод "сливает" все последовательно расположенные текстовые узлы в один узел. Эта операция производится как с поддеревом дочерних узлов текущего узла, так и с поддеревом атрибутов узла типа domElement

РНР 5 в подлиннике
stackoverflow.com/a/13787629/1528973 показан пример.

для этого давно придумали phpDocumentor.

где-то вводили, иначе бы ее не было.
git config user.email

php.net/manual/ru/control-structures.if.php

Можно модель MVC собрать без class?

конечно можно.

Почему везде нужны class?

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

пффф...

$functionName = __FUNCTION__;
$this->client->$functionName();

и всех делов.

или $this->client->{__FUNCTION__}();

Ω - alt+z на макоси, про винду не в курсе.
или я

в бадишопах командировки - обычное дело.

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

приложение меняется целиком.
пользовательские файлы не трогаются.

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