(якшо я правильно зрозумів ваше зауваження)
здається шо цей рейтинг не про створені в Україні (чи українцями) продуктові компанії, а про продуктові компанії в цілому, які присутні в Україні. інакше в рейтингу не було б Ubisoft/NetCracker/Playrix/Samsung R&D і тд

ca.masterkey.ua/...​cumenty/#documents-anchor

Спробуйте тут

1. Звісно є, якщо це не копіпаста з інших джерел, яка порушує авторське право цих джерел.
2. Тобто ви хочете авторське право на текст, який відскануєте деінде і видасте наче він ваш? Чим тоді ви відрізнятиметесь від розробника який скопіює ваш труд?
Ви ніяк не сховаєте html з текстом від кінцевого користувача.
З іншими пунктами вам на консультацію до юриста-знавця права на інтелектуальну власність/авторського права.

бажано уникати назву дії над ресурвом в path.

можете ввести поняття ресурсу як Search, тобто не дієслово а іменник (так як вище порекомендували). далі його не обовʼязково створювати десь взагалі, просто опрацьовуєте цей ресурс згідно якимось правилам (у вашому випадку це пошук orders) і видаєте на-гора результат у вигляді колекції із ресурсів order. наче все згідно REST тут

чесно кажучи не знаю хто придумав, що POST тільки для створення і тільки тоді це буде по канонам REST.
REST колись був дисертацією чувака, в тій дисертації ні слова про POST не знайшов ics.uci.edu/...​pubs/dissertation/top.htm

в rfc про POST також не сказано шо той обовʼязково має щось створювати на сервері (на відміну від PUT), просто цей метод вважається не ідемпотентним, бо на нього поклали такі функції які не можуть гарантувати ідемпотентність.
datatracker.ietf.org/...​tml/rfc9110#section-9.3.3

тому POST /orders/search цілком норм підхід

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

Маршрутизатор цим займається
uk.m.wikipedia.org/wiki/Маршрутизатор

і/або комутатор uk.wikipedia.org/wiki/Мережевий_комутатор

не заради срачу, але я б порадив не використовувати google translate для перекладу або хоча б давати розробникам(тим які працюють в dou) прочитати переклад перед публікацією.

хз шо гірше: дієвидло чи запит на вилучення(pull request, запит на злиття/стягнення/стягування) чи пропозиції (props в реакті, атрибути/характеристики мабуть)

Чмут там так часто виступав, хіба вони не друзі?

Більше ніж друзі ) Чмут один із засновників мілітарного

uk.wikipedia.org/wiki/Мілітарний

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

1. для яких кведів? під айтішні кведи підпадає з десяток таких точно, частина з яких може бути доволі суперечливою(айті чи не айті)
1.1. чому саме для цих кведів, а не для інших?
2. ваше рішення впливає на ЗЕД фопів
3. як ви уявляєте сплату податків? це ж типу треба в системі вносити правки. якшо фоп 3 група і цей квед, тоді такий-то податок, якшо інший квед то інший податок
3.1. як рахувати якшо основний квед зі збільшеним податком, а супутній зі звичайним? чому?
4. всі системи/автоматичні розрахунки також треба змінювати.

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

також таке рішення навряд чи змогли б продати в гарній обгортці. взагалі дія сіті створювали скоріше для компаній і майбутніх інвестицій, а не для фопів, бо згідно зі слів тих же укр компаній, податків прийдеться платити менше ніж при поточній співпраці ТОВ-ФОП. міграція фопів в гіг-контрактори це вже побічний ефект, так сказати, але не менш важливий.

мені здається що у рейтингах влади. підняти податки для гіг-спеців — отримати <=~250к незадоволених, підняти податки для фоп 3 групи — отримати мабуть на порядок більше незадоволених.

взагалі питання не тільки в податках, а в тому що будь-які зміни до правил дія сіті викликатимуть менше хейту влади просто через малу чисельність невдоволених.

мінус в тому, шо айтішників виносять в окрему групу з окремими правилами. і якшо сьогодні, наприклад, податкове навантаження 5%+1.5%, то завтра може бути 15%+1.5%, бо грошей в держави нема(особливо зараз під час війни). нагадаю, шо сума в контракті прописується gross. тобто вам ніхто ті 10% не докине до gross раптом шо. ви готові до такого повороту? я — ні. тому шо коли переважна більшість компаній прийматиме на роботу тільки по гіг-контракту, то вам не буде куди діватися. можете пофантазувати над іншими потенційними змінами. аргумент про «25 років» також через цю причину не приймається. сьогодні 25 років, а завтра просунуть в турбо режимі поправку з відміною цієї норми разом з іншими поправками(як недавно було про відстрочку через інвалідність родичів).

ви можете сказати шо з фоп те ж саме може статися, тут я погоджуюсь і не погоджуюсь одночасно. тому шо фоп 3 група на загальному оподаткуванні це не тільки айтішники, а ще багато інших. тому підняти податки для ~250к (якшо всіх айтішників підімнуть в дію) VS підняти податки для хз скількох фоп 3 групи — різні речі.

додам ще трохи щодо відпустки. працював деякий час по КЗпП, мав 28 днів відпустки. з точки зору компенсації це повна лажа була, як на мене. бо:
1. при вирахуванні із зарплати, дні відпустки рахувались як робочі. приклад: при зарплаті 100к на місяць робочий день працівника коштує 5к грн, якщо в місяці 20 робочих днів. 2 тижні -> 10 робочих днів -> −50к від зарплати.
2. нарахування відпускних йшло окремим рядком. такі дні рахувалися як календарні, тобто за ціною середньоденної зарплати за останній рік. таким чином при зп 100к/міс маємо 1200к річної. 1200к/354 = 3.4к грн. 354 дні бо державні свята не враховуються.

5к — 3.4к = 1.6к грн — це сума, яку працівник не дорахується за кожен день відпустки при вищенаведених умовах.

варто ще сказати, що приклад трохи спрощений. якшо я правильно памʼятаю, то в суму річної зарплати входить тільки зарплата, а не всі виплати( типу премії, лікарняні, відпускні тощо), тому місяці, в яких працівник хворів або відпочивав, принесуть трішки менше ніж 100к. але тут я можливо помиляюсь.

з лікарняними все ще гірше. я мав необережність захворіти і мені лікарняні нарахувались як 0.5 від календарного або робочого дня (не памʼятаю вже), бо страховий стаж роботи по КЗпП менше ніж якась там потрібна кількість років. якшо загальний страховий стаж більше ніж 7 чи 8 років, то тоді працівник матиме 100% від календарного або робочого дня. при цьому, перші 5 днів лікарняного оплачуються роботодавцем, а наступні фондом соц. страхування, які чекати треба, скажемо так, довго. і обовʼязково лікарняний лист від лікаря, який може його видавати(а можуть не всі), на імʼя компанії без помилок. інакше перероблювати (були випадки).

Чи очікуєте ви знову напливу IT-фахівців цієї зими, якщо в інших регіонах будуть проблеми зі світлом?

а мав місце наплив минулої зими? в Ужгороді, здається, був графік 2/>=8, де >=8 це кількість годин без світла. Враховуючи, шо в Ужгороді немає центрального опалення, і багато хто користується котлами від розетки, то маю сумніви шо Закарпаття є гарним місцем для зимівки.

p.s. Розумію, шо Ужгород не є все Закарпаття, але це обласний центр все таки. Тому підозрюю, що в інших населених пунктах ще гірше з електрикою.

Якщо ви маєте на увазі пенсію за віком, то ваше мірило не працює.
Якшо коротко й узагальнювати, то на даний момент будь хто(незалежно від статі) віком 60+ і страховим стажем 30+ має право на пенсію. А далі йдуть виключення й уточнення.

Про 40+ стажу і будь коли валідно лише з 2028 року.

Стаття 26
zakon.rada.gov.ua/laws/show/1058-15#Text

youtube.com/...​Z98dC-V-N3m0Go4deliWHPFwT

Ось плейлист де розробник ігор пише власний рушій з нуля. Також можете на цьому каналі пошукати інші відео по створенню ігор, їх там чимало.

Тут www.youtube.com/...​da7AkHxhzp8?feature=share

Так ось же він
dou.ua/...​rums/topic/42843/#2601703

не знаю, чи ця фіча корисна і матиме популярність загалом, бо мав справу з деякими проектами на реакті, і там код після фігми треба було б мабуть довше переробляти, ніж написати з нуля самому, бо ті проекти мали кастомізовані компоненти, в тому числі інпути. також колись мав справу з автозгенерованими стилями в фігмі. вцілому норм підхід, але знову ж таки, на той час фігма не вміла нормально в display/position і таке інше, бо потім я звав фронтендера, щоби той підфіксив стилі після фігми.
хз як там chatgpt в цьому напрямку поживає, але вважаю шо знання верстки все ще потрібне, як мінімум через кількість браузерів/девайсів/розмірів екрану.

p.s. думка субʼєктивна, я не фронтенд дев і ніколи не мав задач з фронтенду важчих ніж змінити колір кнопки