d_v_c

Есть хорошая статья: habrahabr.ru/post/204958
Если кратко: на чистом REST не получится сделать сложную бизнес логику.

Depends от того что Вам вкладываете в понятие "работу от которой я бы был доволен".
Если речь идет про сложную математику - то её в вебе действительно очень мало.
Навскидку распознавание голоса, изображений, pathfinding какой то, анализ bigdata.

Если просто хочется писать что то более осмысленное чем "элемент подсветить, вывести из базы товары" - вариантов немного больше:

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

Это очень обманчивое заблуждение.
Сложная логика появляется там где есть сложные бизнес требования.
Если под интернет магазином подразумевается 3 продажи в день - то тут вообще программировать не нужно, любого готового движка хватит.
А вот если это какая нибудь условная www.lamoda.ru - со своим достаточно нелинейным маркетингом, своей системой складского учета, своей системой автоматизации и оптимизации логистики итд - там в штате ~300 разработчиков сидит, а задача "вывести из базы товары" трансформируется в 100 страничное тз кому, когда и какие товары надо выводить.
Ну и от нагрузки многое зависит. Сделать систему которая бронирует 1 квартиру в секунду и 1000 квартир в секунду - принципиально разная сложность и объем кода.

Мы пользовали https://github.com/PHPOffice/PHPExcel

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

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

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)

Ой ёёёё.

1) Зачем Вы создаете класс для работы с базой данных который четко завязан на 1 таблицу?
Создайте общий класс для работы с базой, от него наследуйте класс модели для конкретного функционала.
Советую почитать про MVC.
Вообще сама идея передачи названия таблицы какая то странная. У Вас много таблиц в которых лежат юзеры?

2) Никогда не используйте оператор подавления ошибок "@"
Код

@mysql_query("set_character_set_client='utf8'");
    @mysql_query("set_character_set_results='utf8'");
    @mysql_query("set collation_connection='utf8_unicode_ci'");

абсолютно бессмысленный, он не выполняется - тут внезапно mysql, а соединения в mysql то и нет, соединение в mysqli

3) Никогда не передавайте данные в базу без обработки. Все данные должны быть как минимум обернуты в mysqli_real_escape_string. Ну или PDO используйте

Шифровать не получится. Plain text.

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

upd смежный вопрос:
Какой из способов безопасного хранения критически важных переменных оптимален?

imho:
1. Портфолио собрать обязательно. Выложить на любой сайт - можно на https://www.behance.net/ , можно на тот же https://moikrug.ru/
2. Теряюсь от вопроса. Если он работает в сфере где доступ к фотобанку нужен - почему у него его до сих пор нет?
3. Надо посмотреть по основным где есть в текущий момент поток заказов актуальной тематике и идти туда.
Сразу покупать "PRO" нужно.
Любые сайты визитки, они же портфолио нужны исключительно как ссылки которые можно послать клиенту.
Для получения денег нужно иметь минимум:

• счет в банке
• яндекс деньги
• Webmoney
• qiwi кошелек
  

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

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

Напомню, что при включении предупреждений выводятся сообщения о необъявленных переменных и индексах массивов.

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

Мало того что ошибки нужно исправлять, по хорошему код нужно писать с обработкой exception и логикой "что делать если что то вдруг сломалось".
Единственное место где вывод любых ошибок должен быть отключен для пользователя (но они все равно должн ы логироваться, обрабатываться и исправляться) - это production.

PS

Больше приходится писать код, меньше сил остаётся на разработку.

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

saas.
иначе - никак.

В общем случае пишется маленькая десктопная софтинка которая ставится на компьютер клиента, висит в фоне, тем или иным способом (вебсокеты, http long polling) получает от Сервера информацию о том что нужно печатать, ну и собственно печатает.

По моему опыту в давние времена(возможно с тех пор что то стало лучше) производители фискальников по запросу высылали .dll и даже примеры кода. Зачастую эти dll различались даже между разными моделями одного производителя. Соответственно вопрос поддержки разных фискальников - решается хардкодом в этой софтинке определенного списка поддерживающихся dll и разных реализаций печати в них, включая как фискальные заморочки, так и разную ширину печати, ограничения по максимальной длине, etc

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