Дмитрий Энтелис

надо быть очень трастовым, крупным и договариваться с эквайрингом(банком) напрямую.

т.е. для "небольшой интернет магазин" никак скорее всего

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

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

Можно поинтересоваться, что за тестовое было?

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

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

1. php.net/manual/ru/function.mb-strtolower.php
2. php.net/manual/ru/function.array-rand.php

Вы видимо, считаете, что кто-то за 5-10% комиссии будет вам задачи в зубах притаскивать как собака тапочки?
А 50% - не хотите ли? А то и и вовсе 70%.

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

2. Смысла в этом нет ровным счетом никакого.
Посреднику крайне важно было бы получать хорошые отзывы от клиентов. То есть с разработчиков требовалось бы много. Для посредника важен оборот - то есть заказов много, но и разработчиков много.
А это приводит к тому, что разработчика сменить несложно, чуть вы где слабину дали.

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

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

3. TopTopal, EPAM, Luxoft - крупные посредники. Там по другому. Вам будет поприятнее. Себе они конечно тоже оставляют большущий процент. Но первоначальная сумма, выплачиваемая заказчиками столь велика, - что до вас будет неплохо доходить.

Кто сказал что они ниже уровнем?
Эффект Даннинга — Крюгера
Программеру всегда трудно вникнуть в чужой код - это не зависит от квалификации того, кто кодировал.
Возможно что даже и они более квалифицированы - просто давным-давно забили на перфекционизм, а из вас он еще прет из за юнешеского максимализма.
А может и вы правы.

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

$sum = $a > $b ? ($a > $c ? $a + ($b < $c ? $b : $c) : $b + $c) : ($b > $c ? $b + ($a < $c ? $a : $c) : $c + $a);

А теперь от теории к практике, я сам несколько раз попадал под проверки, а также несколько лет "работал" независимым специалистом по киберпреступлениям, в том числе на проверках лицензионной чистоты. Руководство всегда показывает пальцем на админа и говорит "Мы не знали, вот ответственный специалист!" Заканчивается это тем, что компанию штрафуют, а админу прилетает срок. Наличие бумажки о том, что директор знал об установке пиратского софта трактуется судом как преступный сговор. Позиция админа "я не обязан разбираться в тонкостях лицензирования" - это как позиция бухгалтера "я не обязан разбираться в тонкостях налогообложения". Правильных решений может быть только два - либо заставить компанию перейти на лицензионное ПО, либо уволиться.

SetEnvIfNoCase User-Agent .*google.* search_robot
SetEnvIfNoCase User-Agent .*yahoo.* search_robot
SetEnvIfNoCase User-Agent .*bot.* search_robot
SetEnvIfNoCase User-Agent .*ask.* search_robot

Order Deny,Allow
Deny from All
Allow from env=search_robot

С такими параметрами:

пользователи-проектировщики создают и поддерживают каталог Строительных объектов (1М+ объектов)
пользователи-инспекторы создают и поддерживают реестр Плановых инспекций объектов (10М+ работ)

ни о какой готовой системе и речи быть не может.

Тут у меня два варианта:
1) Либо бы слишком переоценили свои силы, и такого у вас никогда не будет. Для CMS норм.
2) Либо будет, но тогда возникнет вопрос расширяемости / монетизации, и любая CMS сдохнет от хотелок.

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

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

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

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

А со знанием других языков (php, js, go) python осваивается за 10 дней. Он потому и используется так интенсивно в науке, чтобы на программирование, как на прикладной навык, тратить минимум телодвижений и времени, а максимум на нейроинженерию.

Не заморачивайтесь слишком сильно. Просто открывайте ИП, платите 6% с того что упало на расчетку, и на всякий случай откладывайте еще 6% на штрафы. Можете перейти на патент с нового года — вообще отлично. Бухгалтерия где-нибудь в Эльбе, счет в Авангарде.

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

Как по мне, лучше все делать на сервере. Зачем нагружать и садить батарею смартфона/ноутбука, если с этим может справится сервер где-то в нидерландах за 5 баксов в месяц? Да и тем более, у многих "китайфоны", которые после двух месяцев эксплуатации еле дышат.
У меня уже был спор по этому поводу с фронтендщиком, но в итоге каждый остался при своем мнении. Возможно я чего-то не понимаю

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

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

Изучил весь httpd.conf, перекопал кучу гайдов по highload (они старые и с сомнительными советами типа "отключить лишние модули"

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

1) Это у всех VPS так называемый "мощный" процессор медленнее, чем на каком-то жалком хостинге, пусть и с VIP-тарифом?

Нет, возможно это у Вас, персонально, какой-то дрянной VPS-хостер, или того хуже, тариф аки "OpenVZ, мы не перепродаём проданные ресурсы... ну разве что раз 10, но больше не перепродаём"

2) Поможет ли в такой ситуации FastCGI?

FastCGI - это режим работы PHP, напрямую, на производительность в значительной степени он не влияет, более того, сама логика работы FCGI (если сравнивать Apache-FCGI и Apache-mod_php) будет медленнее, по тому как для взаимодействия FastCGI будет использоваться сокет ("обычный" или unix-сокет), что подразумевает сетевое взаимодействие, вместо непосредственной работы интерпретатора PHP "внутри" сервера. Думаю, Вам поможет несколько другое (постараюсь описать ниже).

3) Почему не популярны фишки типа eAccelerator (кеширование AST и т.п.)?

Понятия не имею, почему они не популярны и откуда у Вас такая статистика... Но, возможно, дело в том, что eAccelerator морально и физически устарел, и если верить например, вот такой банальной статье (нет, я не работаю с такой "шедевральной" CMS как "Битрикс", просто это первое упоминание про eAccelerator, которое пришло мне в голову) - с версиями PHP выше 5.3 не работает.

Я знаю, что многие из них заброшены, но это не причина, а следствие.

Не могу прокомментировать это, так как Вы не указали следствие - чего именно. Другими словами, я не совсем понимаю, что Вы хотели этим сказать.

4) Что еще может помочь?

Ну так, сходу, по памяти (варианты могут быть не связаны между собой):
1. Отказ от поддержки .htaccess в Apache или хотя бы сокращение их количества
2. Установка Nginx в качестве фронтального сервера, для отдачи статики
3. Полный отказ от Apache вообще и переход на Nginx+FCGI (только не подумайте, я очень люблю Apache за его гибкость в настройке и широкие возможности, другой вопрос, что мало кому эта гибкость фактически нужна и мало кто способен его грамотно, качественно и полноценно настроить... Nginx в этом плане будет куда попроще). Почему FCGI? По тому, что другой приемлемый способ взаимодействия Nginx'а с PHP мне не известен. Настройка FCGI-пула - обязательна.
4. OpCache - с версии 5.5 встроено "искаропки", к включению и настройке - настоятельно рекомендуется. Я не знаю, как обстоят дела с CMS и используете ли Вы CMS на сайте, но из моей практики, скорость работы PHP-фреймворков возрастает в среднем 8-20 раз.
5. HHVM, как альтернатива
6. Проверка:
а) Того, что дело действительно в PHP. В частности, стоит собрать все логи сервера, например, сколько длились запросы, в БД, их количество и так далее.
б) Проверка скорости работы дисковой подсистемы... Не буду "тыкать пальцем", но одно время я арендовал довольно большое кол-во VPS'ок у одного популярного хостера, и в какой-то момент, я заметил, что средняя скорость работы дисковой подсистемы - 1.4Кбайт/сек., при этом "отказы" (аки "невозможно записать блок") были примерно в 50% случаев... это продлилось не очень долго, но и через несколько месяцев, у этого же хостера, тарифы с "обычным HDD", почему-то обладали более быстрой дисковой подсистемой, нежели тарифы с "быстрыми SSD"... можно сделать выводы...
в) Проверить реальную скорость работы процессора, не редко она отличается от завяленной достаточно сильно.

P.S. Если Вы сформулируете вопрос(ы) более точно - я смогу дать более точные рекомендации, если конечно они Вам нужны :)

P.P.S. Есть вариант решения проблемы вообще "в лоб", самый наверное сложный и пожалуй самый производительный в ряде случаев. Это Varnish + тонкая настройка оного, позволяет выдавать большую часть страниц из кэша (оперативной памяти) за наносекунды, иногда позволяет обслуживать очень много тысяч запросов в минуту, при этом, это не просто кэширование кода или что-то подобное... это кэширование целиком страниц и/или ответов сервера. Среди прочего - позволяет "не трогать бэкенд вообще", т.е. при запросе страницы, может не быть ни обращений к БД, ни выполнения того же PHP (или любого другого) кода, на стороне сервера. Требует довольно тонкой настройки, не очень подходит для сайтов "на CMS", для сайтов на фреймворках - требует изначально корректного подхода к разработке и продумывания того, что и как будет/должно кэшироваться. При некорректном подходе - наиболее вероятный результат - работать будет, но не так быстро как хотелось бы, а часть сайта вообще может перестать нормально функционировать. Есть так же другие решения, но с учётом довольно общих формулировок вопроса - говорить о них довольно сложно.

Ах, да, забыл важную деталь... Почему "хостинги" используют Apache и не откажутся от него (совсем)? В большей степени по тому, что Apache позволяет делегировать часть настроек пользователю через .htaccess. При этом, для статики не редко стоит всё тот же Nginx, который, как Вы понимаете, подобным образом делегировать часть настроек пользователю не позволяет, в виду чего для этих задач не подходит и не "буксует" на этом (в отличии от Apache'а). В т.ч. и по этому, мы на 99% отказались от "хостингов" (по причине наличие Apache'а, и невозможности от него избавиться или самостоятельно настроить, и как следствие "тормозов" которые приходят вместе с подобным подходом).