Ага, очень сомнительный слот "работа в офисе". Основная задача, которую помогает решить расписание – быть более эффективным, чтобы максимум твоих действий давали результат. Т.е. за каждым слотом должен стоять какой-то результат – выполненная задача, решенная проблема, достигнутая договоренность. А чтобы был результат, нужно написать шото конкретное, а не размытую задачу "работа в офисе".
Ну это уже зависит от человека, на сколько он умеет реалистично планировать свое время. Конечно же это не получится с первого раза – это такой же навык, как и все остальные, его нужно освоить. Опять же, никто не говорит, что работа должна пройти точно по расписанию, всегда может пойти что-то не так. Если времени на задачу не хватило, то это не значит, что нужно бежать в расписание и обязательно все переписывать, чтобы оно совпадало с твоими реальными действиями. Это просто сигнал о том, что нужно не забыть отменить/перенести (физически, не в расписании) следующий ивент и предупредить людей об этом или выделить еще один слот когда-то для завершения текущей задачи.
В конце концов, если у человека много дел, то у него в любом случае есть план в голове – когда и что он будет делать сегодня. А есть люди, у которых очень много дел и им приходится планировать свое время на несколько дней вперед или на неделю. Просто сложно держать все в голове, можно легко что-то забыть. Опять же, когда тебе нужно запланировать какую-то встречу и перед глазами недельный календарь со слотами – ты сразу видишь "дырку", куда может стать эта встреча. Это легко и быстро и не нужно тупить вспоминать когда там будет время на неделе свободное.
Расписание – отличная штука, согласен. Если для задачи запланирован конкретный слот времени, то скорее всего она будет выполнена, в противном случае вероятность "переноса на завтра" очень высока.
А вот слоты "free", "read", "sleep" – ужас. Они могут быть оправданы только, если человек идет к большой цели. Иначе, попахивает каким-то режимным объектом – ни грамма беззаботности и беспечности, а это прямой путь к выгоранию и паническим атакам при виде календаря.
В связке с Ionic можно использовать и то и другое. Cordova давно на рынке, Capacitor представлен относительно недавно. Соответственно, плагинов Cordova больше и сообщество больше. Хотя Capacitor поддерживает многие плагины Cordova.
Есть отличие в сборке:
В случае с Cordova есть конфигурационный файл, в который вы вносите инструкции для мобильных платформ. На основе него генерируются мобильные проекты при каждой сборке.
С Capacitor все немного иначе – вы генерируете мобильные проекты один раз и после каждой сборки делаете синхронизацию проекта на JS и мобильных проектов. Вам придется вносить изменения в нативный код. Как минимум необходимо менять версию приложения перед каждой публикацией. Но также может понадобится добавлять различные разрешения и инструкции в нативный код каждой из платформ. Придется закоммитить мобильные проекты.
В конце концов оба инструмента делают одно и тоже.
Ionic по факту – набор компонентов для мобильных интерфейсов. Для взаимодействия с нативными функциями и портирования под мобильные платформы можно выбрать как Capacitor, так и Cordova. К слову, Capacitor и Ionic делают одни и те же люди.
Каким боком Ионик к тому что iOS не даёт сканить сеть? Та же проблема будет и в нативном приложении, так ведь?
Да, так и есть. Похоже, что я не так донес свою мысль, я немного другое имел ввиду. Плагины, которые находятся в официальной документации Ionic, разрабатываются не командой Ionic. Это личные разработки разных людей. Поэтому не стоит рассчитывать на то, что плагин будет работать так, как написано в документации. Также не стоит рассчитывать на стабильную поддержку плагина. Это ни в коем случае не упрек людям, которые делают эти самые плагины – огромная благодарность им за их работу и за то, что эти плагины существуют вообще. Этот факт просто важно знать и учитывать, чтобы ожидания всегда совпадали с реальностью.
Ионик не серебряная пуля, ограничен таргет платформой и имеет свои собственные косяки. Но в целом можно и большие приложения собирать. Вопрос не в размере а в том насколько глубокая интеграция нужна с нативной платформой.
В целом так и есть – основные проблемы кроются в нативных возможностях. Но есть и проблемы формата "такая-то кнопка на такой-то модели телефона с такой-то версией ОС выглядит криво". Такие вещи тестировать и исправлять не всегда просто. Если приложение для широких масс, то частенько могут такие задачи прилетать.
Как мне кажется, для импортов в рамках приложения, лучше использовать один скоуп: @app-name/system@app-name/auth, @app-name/system и т. д.
Да, отличная идея. Визуально это очень хорошо выделит импорты приложения от библиотек.
Служебные директории core, при таком подходе, очень легко могут превратится в очень большие свалки в каких-то общих модулях (app, shared и т. д.), но зависит конечно от предполагаемого объема приложения.
Согласен, предел масштабирования есть. В какой-то момент захочется добавить дополнительные разделения.
Разделение на основе семантики, а не по функциональному признаку, может значительно упростить восприятие отдельных частей проекта.
Я думаю, что разделение по функциональному признаку требует больше внимания и контроля, появляются дополнительные вопросы:
если сущность относится к нескольким функциям, то класть в какую-то общую папку или в папку первой, второй или третьей функции;
если сущность единственная для какой-то функции, то все равно делать папку или складывать в какую-то общую папку.
Вроде это все и некритично, но такие вопросы ставят в тупик. Хотя действительно удобно, когда связанные вещи рядом. Такой подход более актуален для больших модулей. На мой взгляд оба варианта имеют место быть и тут больше зависит от предпочтений.
Кстати для контроля зависимостей между различными узлами приложения можно использовать NX.
Да, хорошая вещь. В плане структуры вообще отличная. Особенно полезна при тестировании. Тесты в большом приложении могут очень долго бежать, а в случае с NX можно каждый кусочек отдельно прогнать. NX дает классную структуру, но непростую, на первых порах может быть сложно. Особенно с обновлением зависимостей проекта/ов и самого NX.
По факту да. Но далеко не везде она есть, поэтому решил написать. Часто в начале все складывают как придется, не хотят на это время тратить. А когда проект вырос, то уже сложно привести все в порядок. Уже не дерево, а лабиринт. Начинают на ходу переносить файлы, менять структуру зависимостей и т.д. Это все очень неприятно. Плюс в гите отследить изменения в файле если его 3 раза перенесли и 2 раза переименовали тоже тот еще квест.
единственное что не понимаю смысл в алиасах и реэкспорт в index файлах
Я и не говорю о каком-то супер смысле этого. Просто намного приятнее смотреть на алиасы, чем на забор из слэшей и точек. Когда мы импортируем что-то из node_modules, то не пишем же полный относительный путь. Так почему не делать также со своими модулями. Но и есть небольшой плюс у этого все же – мы видим из какого модуля приходит зависимость, по слэшам и точкам это сложно понять.
не очень понятно, зачем делать не рутовые. какой проф
Если сервис является зависимостью только для одного lazy модуля, то зачем его создавать на старте приложения. Идея в том, чтобы соотносить все сущности с модулями, не валить все в кучу. Чем больше проект, тем больше куча.
нет необходимости к каждому компоненту создавать core
Я не предлагал создавать папку "core" для каждого компонента. Посмотрите, она есть только в модулях.
такое себе. сервисы, интерфейсы и т.д. могут вполне лежать и рядом с соответствующим компонентом, если конечно там не вагон файлов на один компонент
Это нормально работает, когда в одиночку трудишься над проектом, свой порядок в голове и все прекрасно. Проблемы начинаются, когда несколько человек трудятся над проектом. Сегодня интерфейс используется только в одном компоненте и лежит с ним в одной папке. А завтра этот интерфейс уже используется в десяти компонентах и двух сервисах. И тут есть 2 варианта:
разработчик забьет на это и оставит его там, где он есть;
перенесет в корень проекта, в котором уже сам черт ногу сломит, потому что там под сотню интерфейсов таких же;
создаст очередную папку "share" или "helpers" или еще что-то.
Если нет общего стандарта, то каждый делает так, как считает правильно. При этом у каждого своя правда. Так и появляется хаос.
И тут дело не в "красоте". Проблема в том, что чтобы понять в хаосе что к чему относится, что от чего зависит и что где используется, нужно открыть каждый файл и выполнить "find usages" – это все очень долго и нужно в голове все держать. А когда приходится разделить какую-то одну штуку на две отдельные штуки, так совсем становится печально.
Напротив! При наличии свободного времени (если студент, а не от кто после работы валится с ног), всё свободное время посвящаешь только обучению, в том числе и самостоятельному.
Эта история не про большинство. Сколько в каждой в группе студентов, которые все свободное время посвящает обучению, один или два? Дополнительное образование в свободное время – само по себе сложное занятие, как для студентов, так и для тех, кто работает. А если быть к тому же учителем и учеником в одном лице, так это еще сложнее в разы.
Если на них ходить после работы, то очень быстро на всё домашки просто забиваешь, по причине усталости (я пытался учить на курсах и китайский и японский, но как только на работе аврал, на курсы и задания просто забиваешь).
Вы хотите сказать, что самообразованием заниматься было бы проще, чем проходить курсы? Получается, выполнить подготовленную учителем домашку после работы – сложно. Но самому придумать себе домашку, выполнить ее и самому же проверить – проще.
Стоп, ну так а почему тогда такой дефицит кадров на рынке, если все вокруг мотивированные и неленивые? Ваша история как раз про того одного выжившего, а не про большинство.
Да, если «тут всё неправда», «а вот мой друг Коля успешно…» или «а у меня получилось» - прекрасно, текст не про вас и не для вас. Вы и ваш друг Коля – выжившие.
Ну действительно, зачем нужно курсы. Пусть все читают книжки и придумывают себе задачи. Работать будет некому.
К сожалению, не знаю ни одного человека, который сам прошел весь путь с 0 до трудоустройства. Не учился у универе и не покупал никакие курсы, а сам читал литературу и смотрел бесплатные лекции. Мотивация теряется на раз два, когда неделю бьешься об стену из-за того, что не просто не работает, а даже не запускается. Теряется даже у опытных ребят, я уже не говорю про новичков – у них появляется чувство безисходности и многие бросают не успев начать.
Я писал не об этом. Не спорю, что ресурсов сейчас бесплатных пруд пруди. Я писал о том, что намного эффективнее двигаться шаг за шагом по подготовленной продуманной программе заданий, от простых к сложным, а не быть одновременно учеником, методистом и учителем.
Не понял к чему это. Я не говорил, что классическое образование бесполезно. Но я и не говорил, что оно поможет в трудоустройстве лучше, чем какие-то курсы – ни то ни другое не является гарантией. На мой взгляд, курсы помогут быстрее найти работу, потому что будет больше практики, будет что показать на собеседовании. А когда уже деньги получаешь, можно погружаться в теорию и повышать свой уровень. Грустно как-то читать фундаментальную теоретическую литературу по вечерам и параллельно думать о том, что утром кушать. На первых порах можно опустить глубокие знания, чтобы поскорее решить ключевую задачу – найти работу.
Я же не спорю, что есть форумы и т.д. Но только поможет вам быстрее парень из вашей группы. Потому что он делает такое же задание, делает его параллельно с вами, он в теме, вы на одной волне. Это будет намного эффективнее и быстрее, чем найти среди 4 миллиардов одного человека, готового потратить пол часа своей жизни на вас.
Однозначно дело в желании. Как говорят: "Желание – тысяча возможностей, а нежелание – тысяча причин". Но реалии таковы, что и после универов, и после курсов "выживают" мягко говоря не все. А у тех, кто сам бежит, дорога сложнее и запутаннее, шансов "выжить" намного меньше.
- Когда сам учишься, то нет режима. Первый день занимаешься все свободное время, второй день – немного меньше, третий день – позвали погулять, четвертый день – домашние дела. Очень быстро обучение сводится на нет. Мало кого хватает даже на неделю, а нужно пол года, год или дольше. Курсы обязывают тебя ходить на лекции и делать домашние задания.
- Теория, лекции, документация – можно найти в сети без проблем. Но как попрактиковаться. Не так уж и просто придумывать для себя задания на первых этапах. Еще очень сложно перейти от выполнения небольших заданий, к созданию полноценного проекта – это кажется нереальным. А на курсах ты постепенно выполняешь подготовленные задания, а в конце делаешь относительно большой проект. В итоге, переходишь из состояния "это нереально" в состояние "я это могу".
- Если нет друга или знакомого, который уже работает в сфере, то будет очень тяжело. Нет четкого понимая что учить и в какой последовательности. Непонятно когда уже пора начать искать работу, достаточно знаешь или нет, правильно делаешь или нет, что хорошо что плохо. Идешь практически вслепую, очень просто свернуть не туда. Нужна очень точная цель и road map, которая к ней ведет.
- Комьюнити. Когда в группе делаешь что-то – намного проще. Хорошо иметь чат людей, которые находятся в контексте твоей задачи. Всегда можно попросить помощи и быстро получить обратную связь. Будешь двигаться значительно быстрее, чем сам по себе. Когда в одинокого часами или даже днями разбираешься с проблемой, то это сильно демотивирует и убивает желание и интерес продолжать. Как я писал выше, курсы дают тебе первые победы и ощущение того, что все возможно и не так уж сложно, нужно просто приложить немного усилий.
Абсолютно точно! Где вообще можно учиться программирования если не на курсах? Я не вижу ни одного другого варианта. В универе учат также только базовым конструкциям языка, но еще и знания зачастую мягко говоря несвежие дают. Думаю, что главная проблема курсов – маркетинг. Всем нравится быстро и много зарабатывать, маркетологи этом пользуются. У людей складывается ложное впечатление, что курсы это гарантируют.
Универ и/или курсы – базовые вещи. Глупо ожидать, что после них сразу найдешь работу. Но ты получишь основной костяк знаний и сможешь их развивать. Знания собираются по кусочкам, каждая активность в сфере полезна: учеба у универе, прохождение курсов, создание пет-проектов, написание простенького скрипта для друга, чтение статей и новостей по теме, активность в профильных чатах и сообществах. Другого пути для выживания не знаю.
Я думаю, что из-за того, что он дает меньше свободы программистам. Он дает тебе из коробки набор "строительных блоков" (модули, компоненты, сервисы и т.д.) и привила, по которым они могу взаимодействовать между собой. Программистам приходится следовать этим правилам. Это некие стандарты, которые позволяют легко стоить и масштабировать большие приложения. При этом не будет проблемы "чем больше приложение – тем сложнее его поддерживать и развивать". Ну и в довесок TS из коробки. Меньше свободы, больше стандартов.
Да, есть много чего интересно в каждой сфере, что в голову само по себе не придет, пока не работаешь напрямую в этой сфере. Несколько месяцев назад ходил на собеседование в компанию, у которой был проект для парковки кораблей в доках. Я даже не мог представить, что такое существует и, тем более, что к этому имеет отношение Angular)
По поводу аэропорта у меня подтверждений нет. А вот над системой для электростанций работает мой товарищ. Есть заказы от автодора, железной дороги, от портов и т.д. Я не утверждаю, что везде в таких проектах используют Angular, но это популярный инструмент в данной нише.
По поводу анимации и скорости реакции. Не думаю, что для всех проектов важна скорость реакции на очень высоком уровне. Это, скорее, исключение, чем правило. Для какой-нибудь системы мониторинга это может быть критично. А для системы, которая чекает билеты – нет. Кто знает, какая система может понадобиться, это очень специфическая ниша. Но то, что спрос на Angular там есть – это точно)
Хочу сказать слово в защиту Angular. React и Vue однозначно популярнее, но я уверен, что Angular занимает не 4%, а сильно больше. В основном, на Angular делают разнообразные админки. Это может быть какая-нибудь CMS/CRM-система, а может быть система для управления аэропортом или электростанцией. Такие сайты не попадают в топ индекса поисковиков, для них это просто неактуально. Кроме прочего, к сожалению, сейчас SEO и Angular – несовместимые понятия (если речь не идет о SSR).
Вы упоминали в статье Wildberries. Буквально пару месяцев назад получал от них приглашение на вакансию по Angular. Может быть у них CMS на Angular или основной сайт рендерится на сервере и использует при этом Angular. В любом случае, они точно для чего-то используют этот фреймворк.
Не думаю, что анализ топ индекса может показать реальную картинку того, какие фреймворки используют компании на российском рынке.
Ага, очень сомнительный слот "работа в офисе". Основная задача, которую помогает решить расписание – быть более эффективным, чтобы максимум твоих действий давали результат. Т.е. за каждым слотом должен стоять какой-то результат – выполненная задача, решенная проблема, достигнутая договоренность. А чтобы был результат, нужно написать шото конкретное, а не размытую задачу "работа в офисе".
Ну это уже зависит от человека, на сколько он умеет реалистично планировать свое время. Конечно же это не получится с первого раза – это такой же навык, как и все остальные, его нужно освоить. Опять же, никто не говорит, что работа должна пройти точно по расписанию, всегда может пойти что-то не так. Если времени на задачу не хватило, то это не значит, что нужно бежать в расписание и обязательно все переписывать, чтобы оно совпадало с твоими реальными действиями. Это просто сигнал о том, что нужно не забыть отменить/перенести (физически, не в расписании) следующий ивент и предупредить людей об этом или выделить еще один слот когда-то для завершения текущей задачи.
В конце концов, если у человека много дел, то у него в любом случае есть план в голове – когда и что он будет делать сегодня. А есть люди, у которых очень много дел и им приходится планировать свое время на несколько дней вперед или на неделю. Просто сложно держать все в голове, можно легко что-то забыть. Опять же, когда тебе нужно запланировать какую-то встречу и перед глазами недельный календарь со слотами – ты сразу видишь "дырку", куда может стать эта встреча. Это легко и быстро и не нужно тупить вспоминать когда там будет время на неделе свободное.
Расписание – отличная штука, согласен. Если для задачи запланирован конкретный слот времени, то скорее всего она будет выполнена, в противном случае вероятность "переноса на завтра" очень высока.
А вот слоты "free", "read", "sleep" – ужас. Они могут быть оправданы только, если человек идет к большой цели. Иначе, попахивает каким-то режимным объектом – ни грамма беззаботности и беспечности, а это прямой путь к выгоранию и паническим атакам при виде календаря.
В связке с Ionic можно использовать и то и другое. Cordova давно на рынке, Capacitor представлен относительно недавно. Соответственно, плагинов Cordova больше и сообщество больше. Хотя Capacitor поддерживает многие плагины Cordova.
Есть отличие в сборке:
В случае с Cordova есть конфигурационный файл, в который вы вносите инструкции для мобильных платформ. На основе него генерируются мобильные проекты при каждой сборке.
С Capacitor все немного иначе – вы генерируете мобильные проекты один раз и после каждой сборки делаете синхронизацию проекта на JS и мобильных проектов. Вам придется вносить изменения в нативный код. Как минимум необходимо менять версию приложения перед каждой публикацией. Но также может понадобится добавлять различные разрешения и инструкции в нативный код каждой из платформ. Придется закоммитить мобильные проекты.
В конце концов оба инструмента делают одно и тоже.
Ionic по факту – набор компонентов для мобильных интерфейсов. Для взаимодействия с нативными функциями и портирования под мобильные платформы можно выбрать как Capacitor, так и Cordova. К слову, Capacitor и Ionic делают одни и те же люди.
Да, так и есть. Похоже, что я не так донес свою мысль, я немного другое имел ввиду. Плагины, которые находятся в официальной документации Ionic, разрабатываются не командой Ionic. Это личные разработки разных людей. Поэтому не стоит рассчитывать на то, что плагин будет работать так, как написано в документации. Также не стоит рассчитывать на стабильную поддержку плагина. Это ни в коем случае не упрек людям, которые делают эти самые плагины – огромная благодарность им за их работу и за то, что эти плагины существуют вообще. Этот факт просто важно знать и учитывать, чтобы ожидания всегда совпадали с реальностью.
В целом так и есть – основные проблемы кроются в нативных возможностях. Но есть и проблемы формата "такая-то кнопка на такой-то модели телефона с такой-то версией ОС выглядит криво". Такие вещи тестировать и исправлять не всегда просто. Если приложение для широких масс, то частенько могут такие задачи прилетать.
Я уже писал выше, это классный инструмент, не спорю. В статье речь о простой структуре. Я бы не сказал, что Nx – это простая штука, нужно уметь с ним.
Да, прочитал комментарии выше по этому поводу. Пересмотрю свой подход. Спасибо за обратную связь, открыли мне глаза в вопросе провайдинга сервисов!
Да, отличная идея. Визуально это очень хорошо выделит импорты приложения от библиотек.
Согласен, предел масштабирования есть. В какой-то момент захочется добавить дополнительные разделения.
Я думаю, что разделение по функциональному признаку требует больше внимания и контроля, появляются дополнительные вопросы:
если сущность относится к нескольким функциям, то класть в какую-то общую папку или в папку первой, второй или третьей функции;
если сущность единственная для какой-то функции, то все равно делать папку или складывать в какую-то общую папку.
Вроде это все и некритично, но такие вопросы ставят в тупик. Хотя действительно удобно, когда связанные вещи рядом. Такой подход более актуален для больших модулей. На мой взгляд оба варианта имеют место быть и тут больше зависит от предпочтений.
Да, хорошая вещь. В плане структуры вообще отличная. Особенно полезна при тестировании. Тесты в большом приложении могут очень долго бежать, а в случае с NX можно каждый кусочек отдельно прогнать. NX дает классную структуру, но непростую, на первых порах может быть сложно. Особенно с обновлением зависимостей проекта/ов и самого NX.
По факту да. Но далеко не везде она есть, поэтому решил написать. Часто в начале все складывают как придется, не хотят на это время тратить. А когда проект вырос, то уже сложно привести все в порядок. Уже не дерево, а лабиринт. Начинают на ходу переносить файлы, менять структуру зависимостей и т.д. Это все очень неприятно. Плюс в гите отследить изменения в файле если его 3 раза перенесли и 2 раза переименовали тоже тот еще квест.
Я и не говорю о каком-то супер смысле этого. Просто намного приятнее смотреть на алиасы, чем на забор из слэшей и точек. Когда мы импортируем что-то из node_modules, то не пишем же полный относительный путь. Так почему не делать также со своими модулями. Но и есть небольшой плюс у этого все же – мы видим из какого модуля приходит зависимость, по слэшам и точкам это сложно понять.
Если сервис является зависимостью только для одного lazy модуля, то зачем его создавать на старте приложения. Идея в том, чтобы соотносить все сущности с модулями, не валить все в кучу. Чем больше проект, тем больше куча.
Я не предлагал создавать папку "core" для каждого компонента. Посмотрите, она есть только в модулях.
Это нормально работает, когда в одиночку трудишься над проектом, свой порядок в голове и все прекрасно. Проблемы начинаются, когда несколько человек трудятся над проектом. Сегодня интерфейс используется только в одном компоненте и лежит с ним в одной папке. А завтра этот интерфейс уже используется в десяти компонентах и двух сервисах. И тут есть 2 варианта:
разработчик забьет на это и оставит его там, где он есть;
перенесет в корень проекта, в котором уже сам черт ногу сломит, потому что там под сотню интерфейсов таких же;
создаст очередную папку "share" или "helpers" или еще что-то.
Если нет общего стандарта, то каждый делает так, как считает правильно. При этом у каждого своя правда. Так и появляется хаос.
И тут дело не в "красоте". Проблема в том, что чтобы понять в хаосе что к чему относится, что от чего зависит и что где используется, нужно открыть каждый файл и выполнить "find usages" – это все очень долго и нужно в голове все держать. А когда приходится разделить какую-то одну штуку на две отдельные штуки, так совсем становится печально.
Эта история не про большинство. Сколько в каждой в группе студентов, которые все свободное время посвящает обучению, один или два? Дополнительное образование в свободное время – само по себе сложное занятие, как для студентов, так и для тех, кто работает. А если быть к тому же учителем и учеником в одном лице, так это еще сложнее в разы.
Вы хотите сказать, что самообразованием заниматься было бы проще, чем проходить курсы? Получается, выполнить подготовленную учителем домашку после работы – сложно. Но самому придумать себе домашку, выполнить ее и самому же проверить – проще.
Стоп, ну так а почему тогда такой дефицит кадров на рынке, если все вокруг мотивированные и неленивые? Ваша история как раз про того одного выжившего, а не про большинство.
Ну действительно, зачем нужно курсы. Пусть все читают книжки и придумывают себе задачи. Работать будет некому.
К сожалению, не знаю ни одного человека, который сам прошел весь путь с 0 до трудоустройства. Не учился у универе и не покупал никакие курсы, а сам читал литературу и смотрел бесплатные лекции. Мотивация теряется на раз два, когда неделю бьешься об стену из-за того, что не просто не работает, а даже не запускается. Теряется даже у опытных ребят, я уже не говорю про новичков – у них появляется чувство безисходности и многие бросают не успев начать.
Я писал не об этом. Не спорю, что ресурсов сейчас бесплатных пруд пруди. Я писал о том, что намного эффективнее двигаться шаг за шагом по подготовленной продуманной программе заданий, от простых к сложным, а не быть одновременно учеником, методистом и учителем.
Не понял к чему это. Я не говорил, что классическое образование бесполезно. Но я и не говорил, что оно поможет в трудоустройстве лучше, чем какие-то курсы – ни то ни другое не является гарантией. На мой взгляд, курсы помогут быстрее найти работу, потому что будет больше практики, будет что показать на собеседовании. А когда уже деньги получаешь, можно погружаться в теорию и повышать свой уровень. Грустно как-то читать фундаментальную теоретическую литературу по вечерам и параллельно думать о том, что утром кушать. На первых порах можно опустить глубокие знания, чтобы поскорее решить ключевую задачу – найти работу.
Я же не спорю, что есть форумы и т.д. Но только поможет вам быстрее парень из вашей группы. Потому что он делает такое же задание, делает его параллельно с вами, он в теме, вы на одной волне. Это будет намного эффективнее и быстрее, чем найти среди 4 миллиардов одного человека, готового потратить пол часа своей жизни на вас.
Однозначно дело в желании. Как говорят: "Желание – тысяча возможностей, а нежелание – тысяча причин". Но реалии таковы, что и после универов, и после курсов "выживают" мягко говоря не все. А у тех, кто сам бежит, дорога сложнее и запутаннее, шансов "выжить" намного меньше.
Оно то конечно можно, но есть несколько проблем:
- Когда сам учишься, то нет режима. Первый день занимаешься все свободное время, второй день – немного меньше, третий день – позвали погулять, четвертый день – домашние дела. Очень быстро обучение сводится на нет. Мало кого хватает даже на неделю, а нужно пол года, год или дольше. Курсы обязывают тебя ходить на лекции и делать домашние задания.
- Теория, лекции, документация – можно найти в сети без проблем. Но как попрактиковаться. Не так уж и просто придумывать для себя задания на первых этапах. Еще очень сложно перейти от выполнения небольших заданий, к созданию полноценного проекта – это кажется нереальным. А на курсах ты постепенно выполняешь подготовленные задания, а в конце делаешь относительно большой проект. В итоге, переходишь из состояния "это нереально" в состояние "я это могу".
- Если нет друга или знакомого, который уже работает в сфере, то будет очень тяжело. Нет четкого понимая что учить и в какой последовательности. Непонятно когда уже пора начать искать работу, достаточно знаешь или нет, правильно делаешь или нет, что хорошо что плохо. Идешь практически вслепую, очень просто свернуть не туда. Нужна очень точная цель и road map, которая к ней ведет.
- Комьюнити. Когда в группе делаешь что-то – намного проще. Хорошо иметь чат людей, которые находятся в контексте твоей задачи. Всегда можно попросить помощи и быстро получить обратную связь. Будешь двигаться значительно быстрее, чем сам по себе. Когда в одинокого часами или даже днями разбираешься с проблемой, то это сильно демотивирует и убивает желание и интерес продолжать. Как я писал выше, курсы дают тебе первые победы и ощущение того, что все возможно и не так уж сложно, нужно просто приложить немного усилий.
Абсолютно точно! Где вообще можно учиться программирования если не на курсах? Я не вижу ни одного другого варианта. В универе учат также только базовым конструкциям языка, но еще и знания зачастую мягко говоря несвежие дают. Думаю, что главная проблема курсов – маркетинг. Всем нравится быстро и много зарабатывать, маркетологи этом пользуются. У людей складывается ложное впечатление, что курсы это гарантируют.
Универ и/или курсы – базовые вещи. Глупо ожидать, что после них сразу найдешь работу. Но ты получишь основной костяк знаний и сможешь их развивать. Знания собираются по кусочкам, каждая активность в сфере полезна: учеба у универе, прохождение курсов, создание пет-проектов, написание простенького скрипта для друга, чтение статей и новостей по теме, активность в профильных чатах и сообществах. Другого пути для выживания не знаю.
Я думаю, что из-за того, что он дает меньше свободы программистам. Он дает тебе из коробки набор "строительных блоков" (модули, компоненты, сервисы и т.д.) и привила, по которым они могу взаимодействовать между собой. Программистам приходится следовать этим правилам. Это некие стандарты, которые позволяют легко стоить и масштабировать большие приложения. При этом не будет проблемы "чем больше приложение – тем сложнее его поддерживать и развивать". Ну и в довесок TS из коробки. Меньше свободы, больше стандартов.
Да, есть много чего интересно в каждой сфере, что в голову само по себе не придет, пока не работаешь напрямую в этой сфере. Несколько месяцев назад ходил на собеседование в компанию, у которой был проект для парковки кораблей в доках. Я даже не мог представить, что такое существует и, тем более, что к этому имеет отношение Angular)
По поводу аэропорта у меня подтверждений нет. А вот над системой для электростанций работает мой товарищ. Есть заказы от автодора, железной дороги, от портов и т.д. Я не утверждаю, что везде в таких проектах используют Angular, но это популярный инструмент в данной нише.
По поводу анимации и скорости реакции. Не думаю, что для всех проектов важна скорость реакции на очень высоком уровне. Это, скорее, исключение, чем правило. Для какой-нибудь системы мониторинга это может быть критично. А для системы, которая чекает билеты – нет. Кто знает, какая система может понадобиться, это очень специфическая ниша. Но то, что спрос на Angular там есть – это точно)
Хочу сказать слово в защиту Angular. React и Vue однозначно популярнее, но я уверен, что Angular занимает не 4%, а сильно больше. В основном, на Angular делают разнообразные админки. Это может быть какая-нибудь CMS/CRM-система, а может быть система для управления аэропортом или электростанцией. Такие сайты не попадают в топ индекса поисковиков, для них это просто неактуально. Кроме прочего, к сожалению, сейчас SEO и Angular – несовместимые понятия (если речь не идет о SSR).
Вы упоминали в статье Wildberries. Буквально пару месяцев назад получал от них приглашение на вакансию по Angular. Может быть у них CMS на Angular или основной сайт рендерится на сервере и использует при этом Angular. В любом случае, они точно для чего-то используют этот фреймворк.
Не думаю, что анализ топ индекса может показать реальную картинку того, какие фреймворки используют компании на российском рынке.