Його виборець мріє щоб ІТ розкуркулили. Нащо йому зважати що ми проти?

Якщо зрозуміла деструктуризація об’єктів, то відбувається приблизно таке (використовую argumentss замість arguments тому що останнє є зарезервованим):

var options = {
  title: "Menu"
};

function showMenu({ title: menu, size = 10 }) {
  alert(size); // 10
  alert(arguments[1]); // undefined
}

// showMenu(options);
let { title: menu, size = 10 } = options;
let argumentss = [options];
alert(size); // 10
alert(argumentss[1]); // undefined
alert(argumentss[0].title===options.title); // true

Робив подібного розміру проект для автоматизації деяких своїх задач. Все здається спочатку просто а потім не встигаєш...

Оскільки часу майже не лишилося, краще не звязуватися з роутером, з ним теж доведеться розбиратися. Я б узяв github.com/...​facebook/create-react-app. Затягнув би react-bootstrap.github.io і на цьому швиденько би написав щось таке (накидав за хвилин 15): codesandbox.io/s/139y259z4j.

Сподіваюся це допоможе. Якщо зявляться запитання можете запитати мене напряму: [email protected]

Я не зовсім зрозумів чи програмування варінт для Вас. Якщо так, то зверніть увагу на dou.ua/...​/?from=premiumevents_3725. Ми там навчатимемо мало популярній технології APL. Мало популярна технологія = більше шансів, що Вашу кандидатуру розглянуть. Сам так починав в IT. Щоправда в 28 :-)

Дякую на доброму слові, Сергію! ;-)

Where is the

green button at the top of this page

?

Немає ніде :-). Фронтендера не замінити ИИ. Просто потреба в механічних інтерфейсах, як мені здається, може зменшитися. Примітивний приклад, щоб проілюструвати: я даю команду звонити дяді Васі замість натискання контакти, пошук, скрол, клік на виклик. Поки писав це, то подумав, що я напевно натякаю на conversational інтерфейси.

Друзі, я чогось не розумію? Це про той AI який те саме що й обчислювальна статистика? Ось тут описаний експеремент з голубами, яких навчили розпізнавати рак на знімках з точністю до 99%. www.scientificamerican.com/...​geons-to-diagnose-cancer. Я так розумію наш теперішній AI це приблизно голуб, якого навчили тикати дзьобом у правильну картинку з певною точністю за червячка.

У звязку з цим виникають питання:
1) Ми що, покажемо голубам купу коду із GitHub-у а тоді повиганяємо програмерів і замість них посадимо голубів розуміти Product Owner-а та бізнес і підтримувати корпоративний код з тисячами рядків коду?
2) Нас задовільнить на запит балансу на рахунку отримувати відповідь типу «100 грн +/- 10грн впевненість 98%»?
3) Нас задовільнить що із 100 походів в магазин 2 невдалі бо система не достатньо впевнена у вашому балансі?
4) Нас задовільнить неможливість перевірити чому AI прийшов до того чи іншого висновку, бо крім Decision Tree алгоритму усі інші — black-box і відлагодити їх нам просто не вистачить мізків?
5) Чи йдеться що ймовірнисний AI генеруватиме код, який з певною ймовірністю тупо не зкомпілюється чи не зможе повернути результат?

Мені чомусь здається, що хвилюватися більше потрібно UI розробникам. Статистичний AI дуже добре автоматизує взаємодію машини і невизначеного навколишнього світу. А якщо так, то менше потрібно буде людського втручання в роботу машин -> менше буде потреби в купі кнопочок і формочок. DBA зрештою перетворяться на Data Engineer чи щось подібне. Професії еволюціонують. Хірург 100 років тому вельми відрізняється від хірурга сучасного...

Якщо трошки англійську знаєш, то глянь курс pluralsight www.pluralsight.com/...​cting-applications-dotnet. Там якраз йдеться про всі архітектурні рівні. Загалом народ для кожного рівня свої сутності використовує а тоді маплять з одного на інший. Так рівні менше один про оден знають, а отже менше залежать. Але в маленькому проекті це може бути overengineering. Я часто в маленьких проектах створював одну структуру і використовував її скрізь, і в DAL і UI. Швидкість розробки висока, код простенький і не треба в купі місць поле додавати при змінах і пробоем з підтримкою не виникало.

По сути получим более закрученную программу, что как ч понимаю и есть ООП.

Хехе, теоретично ООП це ідея поєднання даних і процедур роботи з ними в одному програмному модулі. Шаблони додають більше правил і рекомендацій як саме розбити систему на обєкти. Але з усіми цими наслідуваннями, інверсіями контролю, мутабельністю ООП код і справді майже завжди стає заплутаним. Зробити його не заплутаним дуже важко, я багато років намагався стати класним ООП програмістом і не вийшло :-). А от з функіональним кодом (functional programming) таких проблем, принаймні у мене, не виникає...

Шаблони, як і решта кращих практик проектування покликані покращити design for change вашої програми. Тобто після застусування шаблону програма повинна стати концептуально більш зрозуміла і такою, що в неї легко внести зміни.

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

Нажаль, дуже часто, прочитавши про який небудь шаблон виникає спокуса його будь-що застосувати в своєму проекті. Але шаблон — це не абсолютне добро. Якщо у вас код простий як дерево і усім зрозумілий, а ви його зробили заплутанішим застосувавши шаблон, то ви зробили програму складнішою у супроводі, крім шаблонів є ще правила YAGNI, KISS, Rule of Three.

48 часов в режиме нон-стоп участники трудились

Як це можливо 48 годин не спати і розвязувати складні технічні задачі? І на фотках усі виглядають бадьоро...

1) Замість читати довідники, почитайте ліпше SoftSkill, John Sonmez. www.amazon.com/...​pers-manual/dp/1617292397. Чоловік робив ті ж самі помилки що і ви. І взагалі, у Джона є відповіді на усі ваші запитання на його YouTube каналі.
2) www.freecodecamp.org

www.freecodecamp.org

PHP -> PhD in computer science -> APL -> .NET -> JavaScript підійде? :-)
www.nechai.net

Clojure дуже цікава мова, яку варто вчити. Цей досвід точно буде корисний для відточування вмінь у дизайні програм. Але якщо там 100% ClojureScript, то я б замислився: www.nechai.net/…​ld-software-for-business.

Мої міркування на цю тему: www.nechai.net/…​15/07/31/getting-into-it

Так, суперово! Дякую згадали тут про це. Мене найбільше в другій версії заінтригував strictNullChecks. Думав прощавайте runtime exceptions. Але ж ні. Далі я зясував ось таку річ github.com/...t/TypeScript/issues/11238. А тоді ось таку stackoverflow.com/...s-does-not-narrow-down-un. Excitement минувся...

Та ні, класно, просто Ви вжили «замість» от я і подумав як це динамічна мова може замістити штуку яка лише те і робить що типи додає :-). Я б тож залюбки щось юзав функціональне, типу Elm, бо я полюбляю типи, але ж як це клієнтові продати? Після мене ж клієнту буде важко знайти девелоперів на Elm...