aplic

Делайте скрипт что бы страница загружалась быстро и по основной массе страниц для ботов не потребуется ничего отдельного, они прочитают страницу сформированную JS. Проблема JS сайтов в том, что краулер внутри сайта не бегает, ссылки сформированные JS кодом не видит. Краулер бегает только по html коду. Другими словами под ботов вам нужно адаптировать только очень небольшую часть страниц.

Проблема заключается в том, что достоверной информации нет. Документация гугла откровенно не соответствует действительности, вплоть до полностью обратных утверждений, то есть ребята из гугла сами не знают как оно у них работает. А эксперименты длятся несколько месяцев и не гарантируют объективности, можно получить противоречивый результат т.к. нет полной информации о процессе. Я могу понять людей которые из своего опыта вывели правило об ограничении количества хидеров и стронгов, примерно понимаю почему они так делают. Что бы точнее настроиться на ключевые слова. Хидеры они немного больший вес имеют и можно несоответствующими хидерами легко страницу уронить в выдаче.

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

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

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

Вот я смотрю на это
''+ test2 + ''+i+''+ locris2 + ''
Этим можно детей пугать.

Есть document.styleSheets, есть window.getComputedStyle().

Убрать ); после тела функции (ну и <b> конечно).

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

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

Если трудности с локализацией самого контекста скрипта, это бывает при eval к примеру, ставьте в код
debugger;
и при открытом отладчике вы попадете в контекст исполнения.

А что неудобно? Я пользуюсь гитом и всегда вижу все изменения перед заливкой. И очень все удобно и даже почти ничего и знать и понимать в гите совсем не обязательно. Может вам просто нужно научиться ими пользоваться? Попробуйте какой-нибудь визуальный клиент выбрать попроще.

Уточню, что MS-PL не обязывает вас вашу часть публиковать под этой же лицензией, то есть она не "заразная" (в отличие от GPL). Но модифицированную часть кода который исходно с MS-PL лицензией нельзя публиковать под другой лицензией. То есть вы можете свой код под одной лицензией, а модифицированный под исходной.

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

По мне так хранение имен и фамилий можно делать в виде словарей. Словоформ нет.

При использовании Redis и cluster придется возиться с передачей данных и с организацией и управлением пулом воркеров. Это все можно написать, примеры у меня есть, но хочется какой-то готовой библиотеки предоставляющей простой интерфейс.

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

Может быть стоит сделать более автоматический деплой библиотек в ваш репозиторий? Скажем по принципу npm.

В языках многопоточность, объекты синхронизации, используются либо типовой библиотеки либо возможности самого языка. Многое из этого опосредовано транслируется в API ОС, но напрямую мы API не используем. Потому что это очень важный момент и для надежности и для производительности и прорабатывается еще на этапе создания самого языка. И потому что это синтаксически проще.

JavaScript изначально однопоточен. Но сейчас браузеры позволяют запускать фоновые потоки, фактически это отдельный процесс со своим объектом окна. И взаимодействовать между основным и фоновыми процессами с помощью сообщений. Таким образом можно запускать тяжелые алгоритмы в фоне. Но для целей скриптования странички это конечно же нельзя использовать.