evgemiil: в том то и суть, сначала надо делать MVP в которой реализовано то, что ценно для вашей целевой аудитории и раскрывает суть. В этом плане например разумнее сначала реализовать авторизацию через соц сети а уже потом обычную.
evgemiil: типа того, а еще я советую вам провести какой-никакой бизнес анализ, ставнить конкурентов, проработать стратегию монетизации, возможно запилить прототипы/мокапы что бы сначала решить нужен ли вам очередной клон вконтакта.
Adrastus: ONBUILD обычно используют в ситуациях, когда ваш образ будет использоваться только как базовый, и когда результат команды зависит от каких-то переменных окружения к примеру. Ну то есть мы предоставляем возможность "собрать под себя" базовый образ. Это очень удобно, но это не совсем для этих нужд.
В принципе если хотите - можете ставить зависимости и при сборке контейнера, это тоже вполне себе живой вариант. Проблема только в том что вы не сможете при сборке использовать кэш. Так же помимо npm есть другие менеджеры пакетов, например если вы собираете PHP контейнер - там по дефолту нет composer, а стало быть его надо еще и ставить отдельно.
Короче лично для меня все упирается в кэш и возможность качать пакеты из приватных репозиториев.
1. если это так, то там скорее всего микросервисы и все такое а значит есть хотя бы парочка дорогих синьеров которые будут следить за всем.
2. У нас есть синьер который будет следить.
А что у нас на рынке фриланса? Нет синьеров. Народ не учится, за ними не следят. В целом это общая проблема индустрии. Даже в небольших компаниях может просто не найтись человека который бы в должной мере менторил людей. Я это наблюдаю в половине компаний Минска когда люди просто не развиваются и не знают как.
И ладно бы такие разработчики загубили просто чей-нибудь "стартап" и кто-то просто деньги потерял. Если бы вы знали насколько стремные вещи используются в крупных индустриях, типа медицины, или аэро-перевозки... вам бы стало страшно.
Павел Гоголинский: в целом я потому и говорил о монге - вы бы решили эту проблему намного быстрее. Главное учитывать что при работе с монгой не должно быть связей и все ваши бизнес-объекты в рамках бизнес-транзакции должны ложиться в один документ, и тогда все будет просто замечательно.
Арина Григорьева: архитектурные пакеты - это хорошо, но от того что архитектору нужно все это знать что посчитать и т.д. объем знаний не уменьшается, уменьшаются трудозатраты. Скажем инсоляцию посчитать и т.д. - нужно уже знать зачем это надо и т.д.
По поводу "пиши код в блокноте" - ну собственно а где его еще писать на собеседовании? Мне вообще нравится больше листики да вайтборды. Мне не нужен на собеседовании от человека работающий код, мне ход мысли его надо узнать.
Что до бюджета компаний... Ситуация не сильно поменяется, наоборот ЗП выравляются. Сейчас у нас ситуация такая что есть 90% дешевых и средних разработчиков, которые так себе разработчики, и 10% сильных и дорогих. Если же уровень разработчика хоть немного выровняется, выровняются и ЗП. Правила рынка труда. Если больше шансов заменить сотрудника, его ценность на рынке падает. А стало быть никаких проблем.
Ну и опять же, я знаю слишком много примеров когда джуниоров продавали по стоимости синьеров и т.д. Вы бы согласились работать с человеком у которого год опыта коммерческой разработки над своим продуктом?
Арина Григорьева: суть в том, что координально нового в программировании небыло уже лет 30. А стало быть все эти "новые штуки" это всего-лишь видоизменение очень старых идей. Если человек будет понимать примерный ход мысли как мы пришли к такому или к такому решению - то проблем добавить еще десяток новых однотипных фреймворков я не вижу. Да и небыло бы их столько если бы народ знал что они просто переизобретают колесо.
Короче я сторонник идеи что разработчик должен знать как оно что устроено хотя бы на один слой абстракции ниже того с чем ему приходится работать.
Ну и да, сравнивать таксиста и программиста несколько некорректно. Это все же инженерная специальность. Или хотите сказать что архитекторы проэектирующие здание не должны знать нюансов работы с материалами, из которых в конце концов будут дома строить? Или там аэродинамику не надо учитывать и т.д.
Арина Григорьева: не, это нужно, и никогда не знаешь когда столкнешься с такими задачами. Просто нужно еще объяснять про то откуда баги берутся, экономическая эффективность разработки и т.д. А то народ из ВУЗов выходит и думают что им за код платить будут.
Арина Григорьева: нет, паттерны как раз и были, а вот принципы из которых эти паттрерны выводятся - этого как раз и нет. Паттерны это не важно, важны принципы.
А раскрыть суть идеи о том что объекты изолируют состояние и побочные эффекты, что такое состояние и побочные эффекты... и если это все понимать, то все становится намного логичнее. Что полиморфизм - это теория типов и никакого отношения непосредственно к ООП не имеет. И инкапсуляция это не "фича" ооп, в Си например тоже была инкапсуляция, и все было ок. В javascript например многих смущает отсутствие модификаторов доступа, и потому говорят что там недо-ооп и нет инкапсуляции, а то что сокрытие состояния там достигается за счет модулей - не, не слышали. Ну я думаю вы поняли мой основной посыл. ООП - это сокрытие побочных эффектов, декомпозиция системы и управление зависимостями. Идеальный компромис между функциональными и структурным программированием.
И да, принципов там побольше, но по сути они не привязаны конкретно к ООП. Тут больше здравого смысла.
Арина Григорьева: не знаю... у меня как бы тоже вроде бы все было неплохо, у меня был довольно хороший курс по сетям, история железа именно, типа там эволюция архитектуры микропроцессоров - прекрасно давали этот материал. И базы данных были, и C#, и компиляторы/интерпритаторы свои писали.
Системное программирование, алгоритмизация, к этому притензий у меня лично нет. Но...
При изучении скажем ООП даже не пытались объяснять что такое полиморфизм... Про SOLID рассказывали на 4-ом курсе внезапно на курсе лекций по сетям... и так, мельком, просто между делом. Тестирование - это уже была магистратура и я к тому времени уже 4 года как практиковал TDD.
Иван Кондратьев вот только такие штуки лучше сделать один раз директивой. И хватит уже $scope использовать, 2016-ый год, angular 1.5, компоненты и все такое...
