Тоді проблема в розумінні слова «саме». Чи це дійсно єдина компанія, в якій кандидат хотів би зараз працювати. Чи це тільки одна з, наприклад, 5 чи 10 (з 100+ існуючих в IT в найближчому доступу і міліона будь-якого напряму), але таки в топі побажань.

Я завжди розумів «саме» в другому сенсі. Якщо рекрутер має у питанні перший сенс, то це вже його проблема. Але я чесно відповім, чому вони для мене в топі.

До того що this аргумент а не параметр.

Саме за вашим же визначенням this — параметр.

вказано що вона очікує якісь значення? Ні.

До чого це взагалі?

Якась біліберда. Нічого не зрозуміло.

Маю чесно те ж саме сказати про ваш коментар.

Програмісти пишуть програми а не проектують будівлі чи якісь пристрої.

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

Ось в цьому якраз є сенс. Ви могли не іти на linkedin взагалі. Ви могли вибрати іншу пропозицію з тих, що прийшли на linkedin. Іншу з тих, де рекрутер благав прийти на інтервʼю; навіть якщо зараз на ринку мало пропозицій, були періоди, коли за кожним, хто міг відрізнити Java від JavaScript, ганялись з пачкою грошей. Ви прийшли на інтервʼю, значить, чимось вам компанія здається привабливою, хоча б на перший погляд. Так ось чому саме? Я вважаю, цілком нормальне запитання.

Дуже сміле твердження. Обґругтувати зможете?

Параметри задаються в визначенні функції. Аргументи це коли дані передаються функції.

Це дійсно відповідає практичному використанню цих термінів в ECMA-262 (раз уж ми ліземо в формальності, гайди використовувати стандарт, а ви, судячи з ваших слів, неявно схиляєте контекст тільки до JavaScript, і стаття про нього). Але формального визначення цих двох термінів — argument і parameter — в тексті стандарту просто нема, хоча секція словника там є. Пункт 9.2.12, який описує матчінг одного другому, неодноразово використовує слова «formal parameters» або просто «formals»; якби термінологія у описаному вами варіанті була однозначною, ніхто таких слів не використовував би.

Ну а ще більш дивно те, що, навіть у такому варіанті, ваше твердження

Не параметр а аргумент.

виглядає дивним. Бо всередині функції діють, за вашим же визначенням, саме «параметри», і один з них, завжди присутній, зветься this. Якого саме аргумента значення було йому присвоєне при виклику функції, залежить, як стаття і каже, від масси факторів. Ви точно впевнені, що не помилились? Перевірьте своє твердження, тричі.

Ну я нелогічного бачу тут тільки те, що є явна різниця в поведінці (args) => {body} і function(args) {body}. З досвіду інших мов — тут краще було б або описувати явний список запозичень з контексту, або дозволити транслятору самому визначати цей список. Порівняно з цим, навіть non-strict використання document/window/etc. виглядає менш дивним.

Для стрілкової функції рушій глядить значення this так само, як і глядить значення звичайної змінної в звичайній ситуації.

Тут таки краще сказати, що має місце захоплення контексту в місці створення стрілкової функції, і this береться з цього контексту.

І виникає вже питання історичного характеру — чим саме форма (args) => {body} відрізняється від function(args) {body}. Зі сторонньої точки зору тут різниця суто штучна.

Не параметр а аргумент.

Це паралельна термінологія, теж дозволена. Раніше була навіть основною.

Якщо коротко, то this посилається на контекст виконання. В принципі все.

Коли ви не кажете, як саме він посилається, то це ні про що.

В Європі тим паче в 2:30 спати треба:))

(але взагалі краще б бекап робився на ходу)

Тому для універсального підбору я робив так: спочатку IPA-транскрипцію переписував КИРИЛИЦЕЮ.

Цікаво, як ви кирилицею розрізняли навіть в англійській [a], [ɐ], [ɑ], і [ʌ].

Конвертування в кирилицю мабудь просто зрізає їх унікальні фонеми ...

Турецьку кирилиця здатна описати без великих проблем. Але яка саме у вас була конверсія — ХЗ.

Мені тут одне незрозуміло — а сенс?

Деякі місця, в яких я працював, без зміни назви змінювали характер внутрішнього устрою, у всіх деталях, двічі чи тричі. Могли змінитись володільці, CEO і так далі. Що толку, що всі дані точні, а історія безперервна, наприклад, з 1995 року, якщо нова політика призвела до того, що 90% персоналу звільнилось за два роки і замінено іншими людьми? Або що спільного, наприклад, у Укрпошти в 2026 і Пошти СРСР в 1980, крім номерів деяких відділень?

А ще одне місце було — «пусту» фірму викупили, грубо кажучи, за ящик коньяку і навісили на неї роботу нового типу. І теж було гарно.

А цей приклад з KodiX. Ну хай через якісь причини той же засновник вирішив створити ще одно ТОВ і щось робити через нього. Знову ж, я знаю місце, де цих ТОВ було під десяток і вони якось «перетікали» одне в інше, але працювати там було добре. І що з того?

Треба дивитись на конкретних людей, хто має реальний вплив і що він робить і як. Ось це — значно більш стійка характеристика. Ви пишете — Тарас Гриців. Про нього щось конкретне є?

Здається, ви (з моделлю) погано врахували аллофони і межі між реальними фонемами. Наприклад, в General American [ʌ] і [ɑ] обидві можуть зсуватись до [ɐ], а [æ] повзти вгору до [eə] чи навіть [ɪə]; в британській — навпаки, донизу до [a]. Інші мови теж можуть таким страждати. В німецькій [ɔ] нормально повзе до [o], а в словʼянських, по більшости, це заборонено (хоча є в болгарських і українських говірках). Ось такі речі дуже тяжко перевчити, і якщо модель сформована на одному мапінгу алофонів до фонем, на інші вона не підходить. Навіть в англійській між RP і GA, вже сказав, буде дуже приблизний збіг. Людина вміє перемикатись між такими моделями, після багаторічного навчання різним мовам. А у вас, напевно, все простіше.

В вашій розповіді максимально дивне, мені здається, те, що тренування на українській і російській дало легше розуміння англійської і німецької, ніж турецької. Якраз турецька має чіткі голосні і сінгармонію, схожу на східнословʼянську (наприклад /ɣɔ/ :: /gʲø/), я очікував би протилежного ефекту.

Ну і як саме у вас виглядали ті транскрипції? Наприклад, як позначалась палаталізація? Чи позначали дорсальний і альвеолярний характер приголосних як /t/, /d/?

Питання, питання...

GitHub навмисно створений так, щоб міліони простих кодерів, які щось роблять, але не хочуть думати про тонкощі задля акуратної і чистої історії, в якій можна було б щось знайти і через 20 років без надмірних зусиль, змогли б працювати в режимі, коли Git спрощений до централізованого засобу ведення коду, тільки з оффлайн-сховищем. І він не один такий: BitBucket, Gitlab йдуть тим же шляхом. Бо інакше «ширнармаси» такого не осилять. Те, що роблять в LKML чи в Gerrit — скрупульозна праця над якістю кожного окремого коміта — для пересічного користувача GitHub це нісенітниця, яка не коштує і цента уваги, йому треба «деліверити».

Але в них всіх додані фішки інтеграції з CI, публікації релізів і пр. — все, що потрібно, щоб «деліверити» «з рельсів в бій». Тому до них і тягнуться.

Мет говорить частково про те ж. По пунктах:

(1) — ну не знаю. Ну да, GitHub запускає тести на будь-який push. Я не знаю, чого Мет пише про «You don’t want the feedback loop after the commit you want it before.», може, у якомусь складнішому випадку?

(2) — дискусія є в обох, але в GH висновок від одної людини і дуже простий.
Дивимось на Gerrit: за замовчуванням оцінки від −2 до +2, можна розширити.

(3) — я взагалі не зрозумів. Здається, через API можна пригорнути автомати.

(4) — stacked PRs це те, що головна фішка в Gerrit, і зроблені вони там суперово. Я не бачив аналогів.

(5) — ну зовнішні тулзи завжди існують, питання в якості інтеграції.

(6) — не впевнений, вони всі громіздкі.

(7) — я не бачив крім Fossil тулзи де б це було, але Fossil це не Git.

(8) — ну може бути. Я погано собі уявляю таку роботу, але треба пробувати.

(9) — не зрозумів, що саме підписуватиметься.

Висновок на зараз: GitHub якийсь... лайнуватий, мʼяко кажучи, але не зовсім зрозуміло, куди іти так, щоб було на схожу кількість користувачів, ніж зараз.

Взагалі згоден. З поправкою на те, що ці критерії можуть принципово відрізнятись між різними доменами і цілями: читабельність (читовність?) для математика, для програміста ядра і для програміста веба дуже різні; і іноді таки оптимізація стає важливішою за розуміння першим зустрічним зі сторони, навіть якщо він добре знає мову і має досвід.

Але з акронімом RMCE проблема — він не складає слова, що запамʼятовується:) Найдурніша збірка рецептів «SOLID» (дурна не окремими рецептами, а саме які вибрали і як зібрали) виїхала, я вважаю, більш ніж наполовину через красиве імʼя. Є більш конструктивні приклади: ACID, SMART. Навіть JSON звучить як знайоме імʼя:) А що таке RMCE?

Прошу надати креслення правильної прокладки.

Що вони дійсно є, казатимемо з виходом 3.16. Зараз рано.

а зараз?

Здається, вже нормально. Дякую.

вже є

Дякую. Напис на кнопці краще б удосконалити — вказати саме про стиль показу (наприклад як в Gitlab: plain text editing // rich text editing), але виглядає працюючим.

Але прошу передивитись логіку розділення на рядки після цитати (blockquote). Здається мені, що воно додає зайвий рядок після цитати. Якщо в rich mode після цитати (blockquote) нема великого пробілу, відповідь іде одразу після цитати, то в plain mode відповідь іде після blockquote в тому ж рядку сирця. Можете подивитись в поточному коменті: у мене перше «Дякую» іде взагалі без жодного пробілу або LF після завершення цитати, і тоді в фінальному нема пропуску, а якщо я додаю хоча б один LF, виникає великий пропуск. Тут треба особливу обробку.