Тимур

Асинхронность - это про конкурентность исполнения. Многопоточность - про несколько потоков.

Асинхронность - это ты проснулся, поставил чайник, пошёл в душ. Услышал писк - вернулся, заварил чай и продолжил чистить зубы.

Многопоточность - это ты проснулся, пошёл в душ, а твоя девушка поставила чайник.

Да, можно. Примерно так.

...
location /images/ {
    try_files $uri @mysite;
}
...
location @mysite {
...
   proxy_pass http://localhost:8080;
...
}

Если не будет картинки в /images, то сработает проксирование на localhost:8080

правильнее так:

1

2 -

Доброго времени суток.
Отвечая на вопрос.
По количеству заказов, на данный момент, по апворку у заказчиков популярны PHP/Wordpress/Laravel, WP вне конкуренции.
В сторону JS есть много заказов по React/Angular/Node.JS, меньше по Vue.
Если же говорить про то, что необходимо, то начиная с самых низов от WP сейчас никуда не деться, просто навыками HTML/CSS на апворке да и вообще уже никого не удивить.
На JS/React/Node.js заказы выше уровнем, без опыта и хорошего портфолио их брать сложнее чем на том же WP.
Ну и общее.
Про идеальный английский - неправда. Знать его конечно необходимо, но уровня intermediate вполне.
По поводу маленьких ставок и быть первым - тоже, не совсем:
• Во-первых это не всем известная помойка. Да, заказчики бывают разные, но основаная масса желает платить специалисту, не равняйте менталитет заказчика из США с нашим, у него не укладывается, что специалист ставит 5-8$ за час. В среднем, все начинают в диапазоне 12-15$, хотите можете и с 5$ начинать, но лучше сразу привыкать ценить свой труд. И вас ценить будут в ответ. Пример из опыта заказ на установку WP, и темы без кастомизации и прочего ушел за 35$/час, на вопрос почему, заказчик сказал, потому что я вижу что вы сделаете за час, а человек будет за 7$ ставить мне его неделю, может заказчик и не прав, но такой ход мысли у многих. Повторюсь есть и иные случаи, но потом часто можно в Job feed увидеть - "даю апворку последний шанс, чтобы сделать мою работу, предыдущий фрилансер не справился".

• Во вторых, там необходимо ответить в течении определенного времени, обычно окно составляет около 10 минут. Ваш cover letter выстраивается у заказчика релевантно вашим скилам, портфолио, последним выполненым работам, но никак не зависит от того вы ответите первая или десятая.

Ни в коем случае, не при каких обстоятельствах не работайте за отзыв и за очень маленькую ставку, мошенников и сволочей большое количество. Случаев работы за 5$ два месяца - масса. Начиналось все с небольшой правки, и обещаний оставить хороший отзыв, а потом в процессе узнаешь что такое JSS, что такое скрытые отзывы. И так люди работали.
Старайтесь избегать заказчиков из Пакистана, Индии. Русскоязычных старайтесь тоже избегать, вообщем ищите заказы в странах от Германии и западнее.

В любом случае, как раз где-то через 6-8 месяцев обучения, вы уже сами будете отвечать на этот вопрос другим. Удачи вам, Марина!

По первой части не забивай себе голову разными ненужными на данном этапе подробностями в планировании (которому ты всё равно никогда не будешь следовать ) и ступай на htmlacademy.ru
купи там платный курс (он там 300 р/мес что ли стоит), а потом честно и тщательно пройди его.

Вот пройдешь его и вопросы по первой части будут сняты.

Использую vscode+webpack+pug+scss+бэм. Из физических инструментов, основной моник: lg ultrawide 29um69g, рядом прикручен моник от ноутбука повешенный вертикально, подключенный через универсальный скаллер.

0) Запускаю Spotify :-)

1) Произвожу установку всех необходимых модулей для сборки. В моем случае у меня набор конфигураций для webpack (отдельные файлы для pug, scss, static и.т.д., выбираю что нужно).

2) Запускаю avocode, загружаю в него макет. Определяю в нем переменные (в то же время записываю их, чтобы сразу кинуть в scss файл) для цветов, размеров шрифтов и.т.д. чтобы при получении кусочков кода из него, он сразу расставлял переменные.

3) Запускаю VS Code, открываю нужную папку.

4) Пишу размету на Pug. Пишу с БЭМ, если встречаю повторяющийся блок, то открываю файл _mixins.pug, в который пишу миксины для повторяющихся блоков, например товаров, пунктов меню, каких-то блоков и.т.д. Pug умеет делать циклы, это ускоряет сильно.

5) Когда HTML готов, начинаю делать каркас. Если дизайн сделан по сетке, определяю контейнеры, колонки, строки в свои классы (не пишу в html тучи классов аля col-md-6, а пишу в SCSS инклуды в нужные мне блоки, типа @include make-col(2) и.т.д.).

6) Экспортирую картинки из Avocode. Очень делается просто, указываю папку и просто кликаю экспорт и ввожу название файла и расширения. Преимущественно для иконок использую svg, если нет svg, то ищу эту иконку в интернете (дизайнеры редко рисуют иконки сами, но зато любят вставлять их не в векторе). Если иконка простая, могу сам ее в inkscape обвести, ну и если нет, то экспортирую png в 2х размере (благо авокод это позволяет, если конечно дизайнер не вставил в исходном маленьком размере). Когда есть контакт с дизайнером, трясу его, ибо растр это плохо для иконок.

7) Пишу стили блоков из страницы. На этом этапе можно на втором монике параллельно смотреть футураму или
Арчера :-) Но чаще на широком монике слева браузер, справа VS Code, а на втором монике Avocode (может меняться местами с браузером). Мысленно нарезаю страницу на блоки. Для каждого блока (БЭМ) создаю отдельный scss файл (кто-то даже для элемента создает, но мне лень), из него сразу выписываю все селекторы. Иногда могу сначала выписать все селекторы со страницы (но так лучше не делать, т.к. во время работы может потребоваться изменить что-то в разметке), но чаще для одного блока выполняю этот пункт и за ним сразу выполняю пункт 8, потом для нового блока опять 7 и 8 и.т.д.

8) Пишу css код вместе с Avocode, у него беру нужные мне параметры (а он уже подставил в них переменные), и вставляю в мой код. И параллельно сверяю со скрином макета используя вот это расширение https://chrome.google.com/webstore/detail/perfectp...

9) Пишу адаптив. Я не могу привыкнуть к методологии mobile-first, поэтому пишу всегда сначала полную версию сайта. Я понимаю, что это чревато всякими проблемами и это типа не модно, но мне норм.

10) Медиа-запросы пишу прямо в блоках, для каждого блока/элемента/модификатора может быть отдельный медиа-запрос. Но для начала определяю breakpoint'ы для разных экранов (чтобы их не было сотни разных), если использую Bootstrap, то беру его breakpoint'ы.

11) Добавляю анимашки. Даже если заказчик не просил отдельно (и если не указал отдельно, что нельзя), он все равно будет доволен, а с animate.css+onscreen.js это вообще работа 10 минут. Сложные анимации обговариваю отдельно, чтобы не сделать ненужную работу.

11) Все снова сверяю, пишу скрипты где надо. Для слайдеров в 99% случаев подходит slick (с доработками конечно, но там хорошее API), для других случаев могу написать свой.

12) Сдаю заказчику и жду ответа сидя на тостере/пикабу.

Это чисто мой опыт, опыт фрилансера, не знаю, как делают другие и не могу на 100% утверждать что это 100% правильный способ. Я так и не смог заставить свой конфиг webpack правильно вставлять спрайты svg.
Надеюсь чем-то поможет мой ответ.

Можно ли подсмотреть

Нет.

Стоит ли сдавать?

в этом случае

Легко ли найти дампы на них?

Не стоит. Лучше нормально подготовиться.
Дампы всегда успеете.

Сильно ли сложно их сдать?

Если курсы подготовки на английском освоите - не сложно, там половина ответов в самих вопросах.

У Вас цель какая? Просто бумажка или планируете стать MCSE и т.д.

Как проходит сам экзамен?

https://www.microsoft.com/ru-ru/learning/certifica...

https://habr.com/post/262707/

Начните с просмотра вот этих двух проектов с примерами на всевозможных языках
todomvc.com
и поинтереснее https://github.com/gothinkster/realworld
А в целом, обычно, в каждом фреймворке есть codestyle guide, бутстрап-библиотеки для старта и вообще всевозможные генераторы.

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

Да, вы верно слышали. Это защита от спама и гулпых фрилансеров, которые шлют однотипные шаблонные предложения на вроде "найми меня".

Если вообще без активности аккаунт, ничего страшного не будет. Единственное, поставьте статус "не нуждаюсь в работе" в настройках. Это чтобы вам не слали инвайты. Ибо есть статус профиля "время отклика на инвайты", где желательно его держать в "отвечает в течении суток". И если всётаки прилетит инвайт, но он вам не интересен, постарайтесь как можно быстрее (в течении суток) отказаться от него, выбрав одну из причин в списке. Отказ от ивайтов никак не влияет на рейтинг, только время отклика.

З.Ы. Во время когда ищу новый заказ, мне 60 бесплатных "коннектов" (по 2 на заявку) очень много, так как очень скурпулёзно выбираю к кому отправить предложение о работе. То задача размытая или не интересная, то цены не те, то условия подозрительные, то клиент какой-то не благонадёжный, то уже наняли. Но некоторые, особенно новички(при регистрации дают 90 коннектов на первый месяц), все эти поинты умудряются прогулять за пару часов в первый день. Рассылая всем подряд предложения. Вот и выходит, что с такими система борется. Повышая качество. Так как не крути, но нас фрилансверов там со всего мира миллионы, а вот работодателей с деньгами всего лишь тысячи.

Делаете ветку master, ветку dev и отдельные ветки под отдельные фичи.
Делаете 2 сайта - один сам проект (основной) - на него выкатываете master, второй сайт тестовый - на него выкатываете ветку dev. Остальные ветки разрабатываете, сливаете с dev выкатываете на тест, если там всё нормально то dev сливаете с мастером. За ноут просто когда садитесь если мастер новый есть делаете git pull и стягиваете новую версию

Switch

public enum DamageType { Melee, Range, Magic }
public class Monster
{
    public double Health { get; private set; }
    public double MeleeDamage { get; private set; }
    public double RangeDamage { get; private set; }
    public double MagicDamage { get; private set; }
    public DamageType FavoriteDamageType { get; private set; }

    public Monster(double health, double meleeDamage, double rangeDamage, double magicDamage, DamageType favoriteDamageType)
    {
        Health = health;
        MeleeDamage = meleeDamage;
        RangeDamage = rangeDamage;
        MagicDamage = magicDamage;
        FavoriteDamageType = favoriteDamageType;
    }

    public void AttackTo(Monster monster, DamageType damageType)
    {
        switch (damageType) // используется switch
        {
            case MonsterType.Melee: monster.Health -= MeleeDamage; break;
            case MonsterType.Range: monster.Health -= RangeDamage; break;
            case MonsterType.Magic: monster.Health -= MagicDamage; break;
        }
    }

    public void AttackTo(Monster monster)
    {
        AttackTo(monster, FavoriteDamageType);
    }
}

То же самое, но со стратегией

public class Monster
{
    public double Health { get; set; }
    public double MeleeDamage { get; private set; }
    public double RangeDamage { get; private set; }
    public double MagicDamage { get; private set; }
    public IDamageStrategy FavoriteDamageStrategy { get; private set; }

    public Monster(double health, double meleeDamage, double rangeDamage, double magicDamage, IDamageStrategy favoriteDamageStrategy)
    {
        Health = health;
        MeleeDamage = meleeDamage;
        RangeDamage = rangeDamage;
        MagicDamage = magicDamage;
        FavoriteDamageStrategy = favoriteDamageStrategy;
    }

    public void AttackTo(Monster monster, IDamageStrategy damageStrategy)
    {
        damageStrategy.Attack(this, monster); // не используется switch
    }

    public void AttackTo(Monster monster)
    {
        AttackTo(monster, FavoriteDamageStrategy);
    }
}


public interface IDamageStrategy
{
    void Attack(Monster attacker, Monster defender);
}
public class MeleeDamageStrategy : IDamageStrategy 
{
    public void Attack(Monster attacker, Monster defender)
    {
        defender.Health -= attacker.MeleeDamage;
    }
}
public class RangeDamageStrategy : IDamageStrategy 
{
    public void Attack(Monster attacker, Monster defender)
    {
        defender.Health -= attacker.RangeDamage;
    }
}
public class MagicDamageStrategy : IDamageStrategy 
{
    public void Attack(Monster attacker, Monster defender)
    {
        defender.Health -= attacker.MagicDamage;
    }
}

Отличие класса Monster только в коде первого метода AttackTo. Ну и свойства FavoriteDamageType или FavoriteDamageStrategy.

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

Поработаю пока с вот этим https://github.com/lukasz-madon/awesome-remote-job... нашел где-то тут на Тостере.

Исследовал ситуацию дальше, понял , что без портфолио не стоит рыпаться.
Нашел список типовых проектов, по которому можно делать портфолио: https://goo.gl/UPx4Sn
Еще хочу добавить , что сейчас никто не будет слушать: "я что-то немного знаю и что-то делал, а вы меня доучите, дайте попробовать, я буду стараться", сейчас правильно общаться вот так: https://goo.gl/8RNNJY , то есть в ответ на "ищем программиста на такой-то проект на том-то" надо отвечать "о круто у меня уже есть такой проект в портфолио, вот ссылка, надо только текст и фотки ваши вставить" :)

Что касается javascript, то оптимальным выбором, чтобы позиционировать себя как javascript или frontend программист, выглядит сконцентрироваться на react.js . У ангуляра больше своих специфических особенностей, vue слишком новый, к jquery в нагрузку будет идти какой-нибудь wordpress или будет только верстка, node.js для серьезного бекенда довольно ненадежный (например сервер на ерланге может лет десять без перезагрузок проработать, имеет крутую асинхронность и параллельность, есть серьезная система перезапуска падающих частей через супервайзеров), хотя в качестве сервера-заглушки для реакта подойдет вполне :) .

Главное преимущество и проклятие скриптовых языков - их динамическая природа. С одной стороны это даёт быстрый цикл разработки, а с другой утяжеляет поддержку крупных проектов. В строготипизорванной Java большая часть ошибок, особенно глупых, уходит на этапе компиляции. С другой стороны, чтобы запустить простой проект на Java придётся выполнить много лишних телодвижений. Ну и всем известная смешная картинка


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