qwead

Подавляющее большинство - придурки и фантазеры. Сидят и пузо чешут "вот я щаз сделаю свой фейсбук... $50 у меня есть, надо фрилансера найти", идут дают объявление, а дальше дело редко заходит.

У нас вчера был случай. Неделю переписываемся с клиентом - девушкой. Вчера прислала мужа на переговоры. Муж посидел минут 10, вообще ничего не понял и спешно убежал. Через полчаса девушка пишет "Извините, в ваших услугах не нуждаемся". Спрашиваю "Почему?", отвечает "Потому что вы ничего внятного не объяснили".

Хотя с ней план действий согласовали от и до, показали красивое портфолио и (по рекомендации) предложили пакет услуг без предоплаты на условиях "если не сработает - вы не платите".

То есть ну полный идиотизм. Это часто происходит. И, к сожалению, это нормально.

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

Я делаю тоже самое, и тоже 2 года.
Но вот мне все также интересно, по вечерам читаю книги, на выходных смотрю видео.

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

1) Род Стивенс - "Алгоритмы. Теория и практическое применение".
2) Джон Маккормик - "Девять алгоритмов, которые изменили будущее".

Выучите SOLID (Боб "Принципы, паттерны и методики гибкой разработки"), GOF (банда 4х, хватит https://metanit.com/sharp/patterns/), GRASP (Крэг Ларман - "Введение в объектно-ориентированный анализ, проектирование и интеративную разработку") наизусть, прочитайте книги авторов.

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

Надо уточнять model/db first, но судя по всему model. Такие вещи обычно руками не пишут, а используют Add-Migration -Name AddFieldAvatarToUsersTable.
Ну а по сути вопроса:

AddColumn("dbo.users", "avatar", c => c.string(nullable: false, defaultValueSql: "default.jpg"));

и

DropColumn("dbo.users", "avatar");

Во-первых в setState в корень предыдущее состояние передавать не нужно, так под капотом к нему так и так подмешается предыдущее состояние, в не зависимости от того, что вы туда передадите. Примерно так:
state = { ...prevState, ...newState };

Во-вторых не правильно передавать в setState this.state, так как setState выполняется асинхронно и ваше текущее состояние может успеть измениться. Если надо обновить состояние на основе предыдущего, в setState по-хорошему надо передавать функцию, в которую первым аргументом при вызове придет ваше состояние:

this.setState(prevState => ({
  some_data: {
    ...prevState.some_data,
    ...input,
  },
});

1 комментарий - в конце тега body создается div с Вашим классом и текстом.
2 комментарий - этот же div удаляется спустя 1 секунду.

Nginx, к примеру, умеет rate limit:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    location /login/ {
        limit_req zone=mylimit;


        proxy_pass http://my_upstream;
    }
}

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

Extract Text Plugin, там в доке все есть

На всякий случай пример...

{
          test: /\.scss$/,
          use: ExtractTextPlugin.extract({
            fallback: 'style-loader',
            use: [
              { loader: 'css-loader', options: { sourceMap: true } },
              { loader: 'postcss-loader', options: { sourceMap: true } },
              { loader: 'resolve-url-loader', options: { sourceMap: true } },
              { loader: 'sass-loader', options: { sourceMap: true } }
            ]
          })
        }

и ниже в плагинах

new ExtractTextPlugin('styles/[name].css'),

Тут подробно объяснено

EF стоит использовать тогда, когда в приложении есть много однотипных несложных запросов, особенно если это fix price проект.
Бывают конечно заказчики жлобы, которые все побыстрее хотят, по сути при работе с ними, кроме как EF вариантов то особо и нет, они не дадут вам время скажем писать скажем на Dapper. Но потом они обычно приходят, когда приложением реально начало много людей пользоваться и просят им повысить Performance, и тогда уже узкие места переписываются на SQL(часто в виде хранимок).

Если вы не будете писать каждый раз логи, а накапливать их, то есть вероятность, что перед тем как сохранить пачку логов у вас ляжет приложение и тогда вы уже никаких логов не почитаете.
А вообще писать через EF логи - это как топить печку бумагой, вместо дров/угля.
Если хотите структурированные логи очень рекомендую присмотреться к MongoDB.

Предлагаю вам вынести front-end в отдельный проект и повесить его на другой порт.
А в проекте с API настроить CORS и будет вам счастье.

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

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

var foo = {
  bar: 'bar value',
};

console.log(foo.bar);
// => bar value

console['log'](foo['bar']);
// => bar value

Разберем ваш пример. Такая запись:

var action = 'addClass';

$('.some-selector')[action]('some-class');

равносильна такой:
$('.some-selector').addClass('some-class');

То же самое для объекта:

var key = 'name';

var obj = {
  name: 'Tom',
  age: 24,
};

console.log(obj[key]);
// => Tom

console.log(obj.name);
// => Tom

console.log(obj[key] === obj.name);
// => true

key = 'age';

console.log(obj[key]);
// => 24

Так же есть случаи, когда к ключу можно обратиться только таким способом:

var obj = {
  'three words key': 'value',
};

console.log(obj['three words key']);

// => value