Судячи зі змісту статті, доведеться сплачувати податок в Польщі, а не в Україні. Проте, як це юридично виглядає, я слабо собі уявляю, адже зазвичай ФОП сплачує податок з усього доходу, а не прибутку.

Відповідь на ваше питання є в міждержавній угоді про уникнення подвійного оподаткування. В якій державі створюється код, в тій і сплачується податок. zakon.rada.gov.ua/laws/show/616_168#Text

Для цілей цієї Конвенції термін «постійне представництво»
означає постійне місце діяльності, через яке повністю або частково
здійснюється комерційна діяльність підприємства.

Прибуток підприємства Договірної Держави оподатковується
тільки у цій Державі, якщо тільки підприємство не здійснює
комерційної діяльності в другій Договірній Державі через
розташоване в ній постійне представництво. Якщо підприємство
здійснює комерційну діяльність як вказано вище, прибуток
підприємства оподатковується в другій Державі, але тільки в тому
розмірі, який може бути віднесений до цього постійного
представництва.

Работаю удаленно на прямую на запад на продукт на PHP, ВО нет

А я одно время не брал людей с профильным ВО.

🤔

Все залежить від того, які задачі та обов‘язки обговорювався на старті. Посада з ними зазвичай корелює, але так буває не завжди. Мені відомі кілька компаній, в яких всі мають однакову посаду — Software Engineer. Проте, хтось по рівню джун, а хтось — тех. лід. Якщо список ваших обов‘язків змінився, — це вже привід переглянути умови співробітництва. Зрештою, вас ніхто не змушує безумовно приймати нові обставини. Якщо не хочеться конфронтацій, можна сказати, що чогось із нових обов‘язків просто не вмієш.

Завжди радий бачити на доу технічну статтю високої якості. А тут подвійне «бінго»: на рівні з якістю ще й хороша подача. Merci

Дискусію з приводу багів варто починати з розуміння самої суті цього поняття.

An imperfection or deficiency in a work product where it does not meet its requirements or specifications.

Як наслідок, у випадку відсутності вимог до продукту (або його частини), він (ця частина) не може містити дефектів.

Як буде можливість, то ще детатьно проб‘ю кабель по маркуванню. З боку конектора виглядає ніби просто мідний дріт, і він там точно не луджений. Свіч стоїть на техповерсі, всі комунікації всередині будинку, тому певно з атмосферними явищами і температурою проблеми немає. Саме зі свічем не знаю як перевірити, проте за ідеальних обставин скачування чогось із ближніх країн (Польша, Німеччина) буде 950 Мбіт/с. Трохи далі географічно або в популярний час буде опускатись до 850-900. Враховуючи оверхед всього стеку протоколів, 950 виходить вже й не дуже далеко від 1000.

Можу підтвердити, що маю вдома чесний гігабіт на звичайному кабелі 5е, який тягнеться по стояку десь метрів 25-30 від провайдерського свіча.

Маю виключно позитивний досвід з Ubiquity. Це техніка, яка просто працює, і не любить вам мізки. Раджу дивитись на лінійку UniFi. Сам зараз користуюсь Dream Machine у вигляді циліндра (не плутати з версією Pro, яка монтується у стійку). По конфігурації Костянтин вірно написав. Кількість точок доступу регулюйте в залежності від потреб.

Вже давно підсів на чай. Бонусом іде ритуал заварювання, який має певний медитаційний вплив і дозволяє розслабитись.

Дружу з людиною, яка з дитинства кожен день вживала воду з лимоном, бо цей напій в сім‘ї теж вважався дуже корисним. Зараз через це має передчасні проблеми з зубами. Напій, безперечно, смачний, проте в якості щоденного розглядати не раджу.

Мені шкода, що ваш підкол не вийшов.

Підозрюю, що мова йде про цей вислів

ну если ты и правда считаешь это хорошим вопросом на собеседовании — у меня для тебя плохие новости

Тож, ви не могли би уточнити, в чому саме полягають ці погані новини, які ви обоє маєте на увазі?

Ви правильно зрозуміли питання. Хочу звернути увагу, що твердження

в оригинальной версии std::[c]ref есть также вариант [c]ref(T&)

невірне. Варіанту з сигнатурою

cref(T&)

ref(const T&)

Прошу, найпростіший приклад нижче. Аналогічних випадків можна придумати безліч.

template<class T> void std_cref(const T&) {}
template<class T> void std_cref(const T&&) = delete;

template<class T> void bad_cref(const T&) {}
template<class T> void bad_cref(T&&) = delete;

int main() {
	int i = 0;
	std_cref(i);
	bad_cref(i);  // error: call to deleted function 'bad_cref'
	return 0;
}

Тенденція на генералізацію завжди існувала, але термінологія мені все ще не зрозуміла. За такою логікою на етапі testing skills можна було би просити інженера пройти всі попередні віртуальні етапи, а саме: витягнути вимоги із замовника, спроектувати продукт, запрограмувати його та створити тестову документацію.

Був би радий, якби хтось пояснив, чому процес requirements elicitation називають system design. Вважаю, що було би коректно проводити такі інтерв’ю з підготовленим документом з вимогами.

Не можу з вами до кінця погодитись. Протягом всього часу, що цікавлюсь цими питаннями, я не зміг знайти згадки про процес, в якому архітектура могла би бути первинною. Отже, відомі мені альтернативи такі: (1) розробка вимог -> виділення архітектурно значущих вимог -> розробка архітектури; (2) розробка системи -> виділення аспектів архітектури (поки що в статусі гіпотез) -> перевірка отриманих гіпотез (у разі потреби повертаємось до попереднього кроку) -> побудова архітектури.

А як під час співбесіди взагалі можна розробити архітектуру системи на словах? Моє перше питання в такому випадку — «дайте почитати вимоги». Відповідь завжди одна з двох: або «це тестовий приклад; в нас немає вимог» (а далі пауза), або «ну ви самі придумайте».

Рекрутери жаліються, що Senior Automation QA крутять носом від 5к. Щось мені підказує, що в розробників справи не гірше йдуть. Життєва мудрість каже, що важливо знати, які 20% зусиль дають 80% успіху, і сконцентруватись на них.