Якщо зрозуміла деструктуризація об’єктів, то відбувається приблизно таке (використовую 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
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/...
Смілива заява про відсутність досліджень ))). Як раз я цим питанням цікавився і виявляється є. Ось, почитайте анотацію link.springer.com/...
Якщо маєте час, послухайте інтервью www.functionalgeekery.com/...
Та ні, класно, просто Ви вжили «замість» от я і подумав як це динамічна мова може замістити штуку яка лише те і робить що типи додає :-). Я б тож залюбки щось юзав функціональне, типу Elm, бо я полюбляю типи, але ж як це клієнтові продати? Після мене ж клієнту буде важко знайти девелоперів на Elm...
Його виборець мріє щоб ІТ розкуркулили. Нащо йому зважати що ми проти?