*sarcasm*
О! Вот это новости! Оказывается, для того, чтобы что-то делать нужно знать инструменты, которыми пользуешься! А потом начнут говорить, что неплохо бы почитать документацию. Жду статьи на Хабре, где мне расскажут, что дорогу надо на зеленый переходить
Я Вам по собственно опыту посоветую держаться как можно дальше от соотечественников. Очень велик риск остаться в дураках. Пустить пыль в глаза соотечественнику чуть проще, чем иностранцу. Это видно даже сейчас на Вашем примере, потому что вы УЖЕ отдаете предпочтение ему, вместо такого же иностранца. То есть ваш уровень доверия изначально выше. И все об этом прекрасно знают и очень часто на этом играют. Далеко за примерами ходить не надо. Почитайте, к примеру, истории иммигрантов в США, которые по приезду пытались искать помощи у сограждан. Процент обманутых, кинутых, подставленных людей слишком велик.
В статье, например, написано, что должен быть не просто прототип, а реальная выручка и клиентская база, пусть и небольшая. Лично я с этим полностью согласен. Куда проще вкладывать деньги, когда команда УЖЕ показала какой-то результат. Само собой, есть умельцы привлекать инвестиции даже без бизнес-плана, но это уже совсем другая история.
Когда ставишь вопросы наподобие: «Сколько уйдет на изучение технологии N», неплохо было бы держать во внимании уже имеющуюся базу. Я не думаю, что кто-то без серьезной подготовки в области физики и астрономии можно быстро освоить какую-нибудь новую технологию поиска отдаленных, мелких небесных тел. Тоже справедливо и для программирования. Без БАЗОВЫХ знаний программирования, осваивать новые технологии нет большого смысла. Обладая сильной базой, тебе намного проще изучать «новые» технологии, которые, на самом деле, в большинстве своем реализуют старые, давно известные принципы. Помню, когда обычный паттерн Observer, известный с незапамятных времен в мире фронтенда произвел вау-эффект и все заговорили о 2-way data binding.
Потом: под освоением все понимают совершенно разные вещи. Я программирую на PHP больше 7 лет, но не могу сказать, что я его освоил. Значит ли это, что у меня какие-то проблемы? Отнюдь. Просто всегда есть куда расти и углубляться. Другая сторона медали, что по долгу службы мне иногда приходится писать фронтенд, в том числе и на хипстерских реактах с редуксами и прочих ангулярах.
Объективно, мой уровень во фронтенд-разработки несколько выше, чем у большинства middle-фронтендщиков, с которыми мне приходилось пересекаться. Причина тому — более сильная БАЗА. Абстрактное мышление, умение гуглить, хорошее знание и понимание паттернов, как всем известных, так и более специфических, постоянное изучение трендов и исходников на гитхаб. В то время, как многие фронтенд-разработчики не могут даже разобраться как работает event-loop в JS, они считают что «освоили JS». Хотя вопрос цикла обработки событий — один из ключевых в JavaScript.
Так вот, что бы вкатиться в ангуляр и сделать на нем простенькое SPA для бронирования билетов на концерт и последующей их верификации мне потребовался день. Значит ли это, что я освоил Angular за день? Ну конечно же нет, потому что мне не пришлось использовать и 10% возможностей и инструментов фреймворка.
В общем: научиться варить пельмени != научиться готовить. Если говорить об освоении новой технологии, как о пельменях, то месяца — очень много, если есть база(умеешь включать плиту, кипятить воду, наливать ее в кастрюлю и т.д). Если базы нет — то это время может ОЧЕНЬ сильно возрасти. Непредсказуемо сильно, если говорить об абстрактных знаниях или навыках. Человеку без математической подготовки и определенного склада ума будет почти невозможно без базы начать писать код на Erlang, например. А подготовка базы может легко занять и целый год.
Если говорить, как о более общем навыке«готовка», то это бесконечный цикл, ибо даже самый хороший повар постоянно совершенствует свое мастерство.
Я хотел это услышать от автора статьи, ибо у меня входе прочтения самой статьи сложилось стойкое ощущение, что ему можно оказать существенную помощь, задав такой вот вопрос.
Да, я об этом и говорю. То есть в статье упоминаю о том, что не нужно строить свои инфраструктуры и использовать Doctrine или что-то подобное. И опять таки, Вы должны четко понимать, нужна ли вас Doctrine или дополнительный слой абстракции.
А я вам как раз и говорю, что это не так. Понимать что и зачем ты делаешь, конечно, нужно. Это очевидный факт и касается выбора абсолютно любого инструмента\технологии, начиная от языка программирования. Но рекомендовать не строить свои инфраструктуры(ШТА? С каких пор использование другой ORM, которая не идет в комплекте с фреймворком начало называться построением своей инфраструктуры?) и отказываться от использования Doctrine(пока что никаких аргементов в пользу отказа от использования я у вас не заметил) это, как минимум не очень правильно по отношению к читателям.
Вы наверное упустили тот момент, что в скинутом примере рассматривается вопрос обхода графа зависимостей сущности и там НИКАК не рассмотрен вопрос того, какие сущности должны быть в принципе. Я бы порекомендовал хотя бы ознакомиться сначала с лучшими практиками, прежде, чем раздавать советы. Начать можно отсюда:
https://ocramius.github.io/doctrine-best-practices/#/34
Это, кстати, применимо не только к доктрине.
Невнимательность, отсутствие практики и опыта делают свое дело.
Да. Часто это относится к каждому из нас, не так ли?
Не пытайтесь играть с Repository в frameworks с ActiveRecord
Вы меня, конечно, извините, пожалуйста, но что за фреймворки с Active Record такие? Какая проблема в том, что бы не использовать Eloquent в Laravel, а юзать тот же Doctrine? Настравивается 5 минут. И точно так же работает в обратную стороно — можно использовать Eloquent без Laravel.
Тоесть Repository должен как принимать так и возвращать единый формат, для хранения данных. Как правило это Entity — класс с геттерами и сеттерами без логики
Что вообще за сущность с геттерами и сеттерами без логики? Как раз такой сущность быть не должна.
Это типичный пример, когда люди не сами доходят до паттернов, а начитываются умных книг и суют свои репозитории и тд...
На самом деле это был яркий пример того, когда умных книг не прочитали, а просто краем уха где-то услышали. В любой умной книге будет черным по белому написано, что реализация таких методов, как create — никак не задача репозитория.
Ну с учетом того, что PHP7(Symfony 2\Laravel\Zend2 и т.д) производительнее вашего RoR и Django, а цена среднего PHP-девелопера ниже специалиста того же уровня на RoR, Django, я уж не говорю о Go, то выбор НЕ в пользу PHP в данной ситуации кажется как раз намного более странным.
А, то есть Slack выбрали PHP по вашему мнению именно из-за возможности установить на shared-хостинге? Пользую пыху > 5 лет, ни разу не пользовался shared-хостингом. Я пыхарь, как вы выражаетесь и моим аргументом НИКОГДА небыло «возможность запуска на shared». VPS\VDS — не аргумент в пользу пыха. Не аргумент в пользу чего бы то ни было вообще. А php.ini несложно расценивать, как environment variables которые есть почти в любом веб-проекте на любой технологии.
Написание ТЗ нужно заказчику не меньше, чем разработчикам. Как правило, у заказчиков, которые еще не написали ТЗ у самих полностью отсутствует понимание того, как система вообще должна работать. Практически ни один человек не способен удержать в голове столько деталей, сколько есть, пусть даже в маленьком проекте. ТЗ на 5 страниц текста намного лучше, чем когда его нет вообще. Касательно бремени написания ТЗ — разработчик или заказчик? Ну давайте я к вам обращусь, как к разработчику за составлением детального ТЗ и согласованием деталей со мной в процессе разработки на какую-нибудь, скажем торговую площадку. Ваши аналитики будут пол года сидеть и делать мне ТЗ, согласовывать со мной, разработчиками, консультировать меня. А когда закончим я просто возьму результат и отдам его своим собственным разработчикам — УРА, пацаны, бесплатное ТЗ завезли, ай-да разрабатывать!
Поиск минимально необходимого уровня формализации — отдельная тема. Если в случае с хипстерским стартапом ТЗ на 5 страничек А4 — вполне себе нормально, то для какой-нибудь системы учета для предприятия оборонной промышленности ТЗ должно быть максимально детальным и подробным. Все очень зависит от сферы и конкретного проекта.
Я не автор статьи и даже не девушка, но за плечами больше 3х лет опыта жизни в разных азиатских странах. В подходе к образованию есть очень большая разница. Про корейский подход в частности написано немало статей, они довольно легко гуглятся. А про уровень образования очень трудно судить, ибо девушка ичится в ТОП-1 Вузе страны по IT, само собой, там уровень у ребят серьезный, но это не говорит о том, что он такой или даже близкий к этому везде. Для корейцев образование очень много значит — для них это билет в жизнь, так что предположу, что уровень все-таки высокий. Из-за диких учебных нагрузок нередко случаются суициды среди школьников выпускных классов.
Ну ладно вам. Делал ЮРИСТ! Я вот готов этой девушке стоя поапплодировать только за то, что не побоялась. А она не только не побоялась, но и сделала. При том продукт, которым УЖЕ пользовалось больше людей, чем продуктами многих людей, называющих себя программистами.
Я Вас помню из предидущих тем, мое прошлое сообщение — лишь послание тем, кто будет его читать. У меня нет никакой необходимости вам что-то доказывать) Уймитесь уже наконец. Добра <3
Если же есть необходимость, то вряд ли ваш личный проект будет больше требовать разбиения на микросервисы
Мой личный проект в среднем обрабатывает 10к запросов в секунду, думаю, на этом можно закончить :D
Нужно заранее понимать, нужен ли сервис в данной ситуации или нет.
Нет. В целях обучения мы можем выделять эти сервисы искуственно. Нет ничего дурного в том, что бы в собственных проектах пробовать разные подходы и получать практический опыт их применения.
Мало у кого есть личные проекты (хотя это плюс, а то имеем сапожников без сапог)
Разработчик без личных проектов — тоже самое, что адвокат без судебной практики. Это как
разработчик без аккаунта guthub и знания английского. Право на существование само собой имеет, но это уж точно не то к чему стоит стремиться.
В реальности это все разобъется в пух и прах.
У меня например не разбилось, что я делаю не так?
В реальности придется думать в каждом конкретном случае, как резать монолит.
Очевидно, однако, если ты пользуешься одними и теми же архитектурными принципами, то этот процесс будет, как минимум унифицирован. Вот был у меня DDD проект. Взял, да повыдергивал домены на микросервисы. Часа 2 заняло с учетом написания Dockerfile.
Фреймворки за вас это не сделают
Проектирование это и не задача фреймворков.
Это типа умение дрочить? :)
Это не умение дрочить, это подкрепление теоретической базы практикой, что является стандартным в процессе обучения практически любому навыку.
Первый раз мы решаем квадратное уравнение до реальной необходимости это сделать(у многих такая необходимость не возникает вообще никогда).
Кмк, вещи нужно использовать по мере необходимости и с пониманием.
Да, в таком случае при возникновения этой самой необходимости ты делаешь миллионы ошибок, которые такой же программист УЖЕ преодалел, изучая и практикуясь.
На поверхности был как бы ООП. Но это был ад. Я код вообще перестал понимать. :)
Ну я до первого опыта коммерческой разработки использовал ООП и даже все эти абстрактные фабрики, стратегии и прочие синглтоны. Может всетаки дело не в необходимости а отсутствии у кого-то системного подхода к собственному обучению?
Не нужно пытаться что-то использовать, потому что так все делают
Нужно хотя бы понимать, что они делают и почему они это делают. А еще лучше уметь это делать тоже. Тогда у тебя будет хотя бы шанс оценить, нужно ли оно тебе или нет. А иначе получается поведение 14-летнего подростка в духе: «ФУ, микросервисы мейнстрим, лучше буду дерьмо жрать с кучей инстансов монолитных приложений, зато НИКАК ФСЕ»
Та плевать, как кто делает
Ну это вообще какой-то вброс дерьма на вентилятор. Стандарты? Паттерны? Лучшие практики? Что объединят три предыдущих вопроса? Это именно то «как делают другие» и разработчику на это не должно быть плевать.
Не нужно свой код подстраивать под что-то, не понимая этого чего-то
Обратного никто не утверждал.
А также, наверное, не стоит советовать новичкам идти по пути непонимания и наименьшего сопротивления.
Этого им тоже никто не советовал, ну, во всяком случае, я точно не советовал.
Нужно меньше догм
Назовите хоть одну — уберем.
Но это не значит, что не нужно интересоваться новыми подходами. Нужно. Только применять их с пониманием.
Для того, что бы у тебя появилось понимание, тебе нужно сначала их как минимум использовать :)
Повторю еще раз начало своего сообщения:
В это болото можно и нужно лезть и из собственного интереса, но не на деньги работодателя
В это болото можно и нужно лезть и из собственного интереса, но не на деньги работодателя(если он сам не просил, конечно), само собой, и уж точно после освоения базовых принципов DDD. Тогда:
а) Появляется представление о том, когда микросервисы не нужны, а когда будут вполне себе неплохим решением
б)+ к скилу проектирования(в т.ч монолитных приложений)
в) Практический опыт ДО реальной необходимости
Какое сообщество программистов? Ты четко указал, что мы говорим о СНГ. И что в СНГ 90% похапэшников, не могут в ООП.
А, то есть ты решил взять 2 разных комментария, написанных в 2х разных контекстах, 2м разным людям, вырвать их из контекста и обвинить меня в том, что я мол за своими словами не слежу. Позволю себе такой же «опус».
Это всё справдливо только если только мы говорим не о чистых ФП. А говоря ФП, во всяком случае я подразумеваю ЧИСТОЕ ФП. И самый высокий уровень абстракции, который мы там можем себе позволить — Функции высших порядков, что все еще очень далеко от ООП по уровню абстракции. Если не прав, буду рад увидеть пример. Я даже нагуглить не смог.
О! Вот это новости! Оказывается, для того, чтобы что-то делать нужно знать инструменты, которыми пользуешься! А потом начнут говорить, что неплохо бы почитать документацию. Жду статьи на Хабре, где мне расскажут, что дорогу надо на зеленый переходить
Потом: под освоением все понимают совершенно разные вещи. Я программирую на PHP больше 7 лет, но не могу сказать, что я его освоил. Значит ли это, что у меня какие-то проблемы? Отнюдь. Просто всегда есть куда расти и углубляться. Другая сторона медали, что по долгу службы мне иногда приходится писать фронтенд, в том числе и на хипстерских реактах с редуксами и прочих ангулярах.
Объективно, мой уровень во фронтенд-разработки несколько выше, чем у большинства middle-фронтендщиков, с которыми мне приходилось пересекаться. Причина тому — более сильная БАЗА. Абстрактное мышление, умение гуглить, хорошее знание и понимание паттернов, как всем известных, так и более специфических, постоянное изучение трендов и исходников на гитхаб. В то время, как многие фронтенд-разработчики не могут даже разобраться как работает event-loop в JS, они считают что «освоили JS». Хотя вопрос цикла обработки событий — один из ключевых в JavaScript.
Так вот, что бы вкатиться в ангуляр и сделать на нем простенькое SPA для бронирования билетов на концерт и последующей их верификации мне потребовался день. Значит ли это, что я освоил Angular за день? Ну конечно же нет, потому что мне не пришлось использовать и 10% возможностей и инструментов фреймворка.
В общем: научиться варить пельмени != научиться готовить. Если говорить об освоении новой технологии, как о пельменях, то месяца — очень много, если есть база(умеешь включать плиту, кипятить воду, наливать ее в кастрюлю и т.д). Если базы нет — то это время может ОЧЕНЬ сильно возрасти. Непредсказуемо сильно, если говорить об абстрактных знаниях или навыках. Человеку без математической подготовки и определенного склада ума будет почти невозможно без базы начать писать код на Erlang, например. А подготовка базы может легко занять и целый год.
Если говорить, как о более общем навыке«готовка», то это бесконечный цикл, ибо даже самый хороший повар постоянно совершенствует свое мастерство.
А я вам как раз и говорю, что это не так. Понимать что и зачем ты делаешь, конечно, нужно. Это очевидный факт и касается выбора абсолютно любого инструмента\технологии, начиная от языка программирования. Но рекомендовать не строить свои инфраструктуры(ШТА? С каких пор использование другой ORM, которая не идет в комплекте с фреймворком начало называться построением своей инфраструктуры?) и отказываться от использования Doctrine(пока что никаких аргементов в пользу отказа от использования я у вас не заметил) это, как минимум не очень правильно по отношению к читателям.
Вы наверное упустили тот момент, что в скинутом примере рассматривается вопрос обхода графа зависимостей сущности и там НИКАК не рассмотрен вопрос того, какие сущности должны быть в принципе. Я бы порекомендовал хотя бы ознакомиться сначала с лучшими практиками, прежде, чем раздавать советы. Начать можно отсюда:
https://ocramius.github.io/doctrine-best-practices/#/34
Это, кстати, применимо не только к доктрине.
Да. Часто это относится к каждому из нас, не так ли?
Вы меня, конечно, извините, пожалуйста, но что за фреймворки с Active Record такие? Какая проблема в том, что бы не использовать Eloquent в Laravel, а юзать тот же Doctrine? Настравивается 5 минут. И точно так же работает в обратную стороно — можно использовать Eloquent без Laravel.
Что вообще за сущность с геттерами и сеттерами без логики? Как раз такой сущность быть не должна.
На самом деле это был яркий пример того, когда умных книг не прочитали, а просто краем уха где-то услышали. В любой умной книге будет черным по белому написано, что реализация таких методов, как create — никак не задача репозитория.
Мой личный проект в среднем обрабатывает 10к запросов в секунду, думаю, на этом можно закончить :D
Нет. В целях обучения мы можем выделять эти сервисы искуственно. Нет ничего дурного в том, что бы в собственных проектах пробовать разные подходы и получать практический опыт их применения.
Разработчик без личных проектов — тоже самое, что адвокат без судебной практики. Это как
разработчик без аккаунта guthub и знания английского. Право на существование само собой имеет, но это уж точно не то к чему стоит стремиться.
У меня например не разбилось, что я делаю не так?
Очевидно, однако, если ты пользуешься одними и теми же архитектурными принципами, то этот процесс будет, как минимум унифицирован. Вот был у меня DDD проект. Взял, да повыдергивал домены на микросервисы. Часа 2 заняло с учетом написания Dockerfile.
Проектирование это и не задача фреймворков.
Это не умение дрочить, это подкрепление теоретической базы практикой, что является стандартным в процессе обучения практически любому навыку.
Первый раз мы решаем квадратное уравнение до реальной необходимости это сделать(у многих такая необходимость не возникает вообще никогда).
Да, в таком случае при возникновения этой самой необходимости ты делаешь миллионы ошибок, которые такой же программист УЖЕ преодалел, изучая и практикуясь.
Ну я до первого опыта коммерческой разработки использовал ООП и даже все эти абстрактные фабрики, стратегии и прочие синглтоны. Может всетаки дело не в необходимости а отсутствии у кого-то системного подхода к собственному обучению?
Нужно хотя бы понимать, что они делают и почему они это делают. А еще лучше уметь это делать тоже. Тогда у тебя будет хотя бы шанс оценить, нужно ли оно тебе или нет. А иначе получается поведение 14-летнего подростка в духе: «ФУ, микросервисы мейнстрим, лучше буду дерьмо жрать с кучей инстансов монолитных приложений, зато НИКАК ФСЕ»
Ну это вообще какой-то вброс дерьма на вентилятор. Стандарты? Паттерны? Лучшие практики? Что объединят три предыдущих вопроса? Это именно то «как делают другие» и разработчику на это не должно быть плевать.
Обратного никто не утверждал.
Этого им тоже никто не советовал, ну, во всяком случае, я точно не советовал.
Назовите хоть одну — уберем.
Для того, что бы у тебя появилось понимание, тебе нужно сначала их как минимум использовать :)
Повторю еще раз начало своего сообщения:
а) Появляется представление о том, когда микросервисы не нужны, а когда будут вполне себе неплохим решением
б)+ к скилу проектирования(в т.ч монолитных приложений)
в) Практический опыт ДО реальной необходимости
Спасибо за видео!
А, то есть ты решил взять 2 разных комментария, написанных в 2х разных контекстах, 2м разным людям, вырвать их из контекста и обвинить меня в том, что я мол за своими словами не слежу. Позволю себе такой же «опус».
Ну и иди общайся со своими неадекватами, клоун.