Pull to refresh
28
0
Артур Пантелеев @arturpanteleev

TeamLead | Backend Developer

Send message
Очень странный пост. Что автор хотел сказать? Что можно не имея даже фундаментальных знаний на уровне первокурсника работать прогером и иметь хорошую репутацию в узких кругах?
Допустим это возможно, если под программировнием понимать верстку формочек на модном js фрейме, или настройку тем для Wordpress.
Да только вот все сильные программисты ИНЖЕНЕРЫ волей не волей знают большинство из того что тут перечисленно. И дело тут не в задротстве теории, просто чем больше опыт и чем больше твоя заинтересованность проектом, тем чаще тебе приходится вылазить из своей зоны ответственности и сталкиваться с проблемами, которые весьма косвенно относятся к твоей основной специальности.
В общем, если верх ваших амбиций — это тупо делать задачи из бэклога, списывая время потраченное на кофебрейки и настольный тенис, то ок. А если хотите серьезного развития(как профессионального, так и технического) то рано иили поздно вам придется унать чем отличаетя виртуализация от контейниризации и чем TCP/IP отличается от OSI.
Мне вот эта картинка помогла пониманием времен в свое время:
Английский с червячком
image

Я вижу несколько основных задач, которые можно решить элегантно с помощью микросервисов:
  • Административная
    Раздельные циклы разработки, тестирование и конечно же деплоя
  • Технологическая независимость
    Можно выбирать инструмент под задачу. Тут заюзаем Go с хранением в памяти тут оставим java с полноценной субд. Гораздо легче внедрить новый инструмент.
  • Оптимизационная
    Можно гораздо гибче масштабировать приложение, точечено балансируя число интсансов сервисов, которые не вывозят нагрузку.
  • Дисциплинарно-архитектурная
    Когда для обращения к сервису нам нужно делать сетевой запрос, волей неволей начинаешь больше задумываться о разделении ответственной в приложении и локальности данных, чем когда можешь практически бесплатно залезть в БД или дернуть метод соседнего пакета

Но проблемы эти решаются, лишь в том случае, если есть желание и понимание того что и как нужно решать. Т.к с дополнительными возможностями микросервисы несут в себе нехилый оверхед. Т.е хорошее монолитное приложение из которого нужные части были вынесены как микросервисы — это круто. А вот если мы имеем дело с типичным гавнокодом, то в нем гораздо проще копаться(и меньше шансов положить всю систему) в случае монолита, чем в случае с архитектурой в стиле «микросервисы ради микросевисов»
как в Go принято — максимально плоско и explicit

Это верно подмечено, иначе просто не получится. Да и вообще понравились мысли в заключении. Я вот перехожу с java like языков на golang ну идеологически ахереваю переход дается очень тяжело.
При написании кода складывается ощущение что вернулся лет на 5 назад — ни нормального ddd, grasp, rich domain models, hexagonal architecture — ничего из этого не требуется, и более того, порицается со словами «это не go way»
Вообще я вижу go как язык с довольно узкой нишей(в которой он чертовски хорош). И очень грустно от того, что все почему то увидели в нем серебряную пулю, способную заменить enterprise языки. Из за попыток таких замен и получаются такие недоразумения как фреймворк, которому посвящена статья.
Интересно, а есть успешные кейсы следования идеям DDD при написании приложух на go?
Я чаще всего пока слышу такую точку зрения, что один микросервис на go == Bounded context и получается что код в рамках сервиса уже сам по себе сгруппирован по предметной области.
Ну и прикрываясь этим в project structure самого проекта творится лютая дичь с папками вроде controllers, dbQuery, services и т.д Чего только стоят официальные рекомендации на этот счет.
Т.е внутри микросервиса файлы группируются по технологическим признакам, т.к считается что вся кодовая база одного сервиса обслуживает небольшую узкую часть предметной области
Nginx использует другую модель обработки запросов. Один его воркер может вытянуть тысячи, и даже десятки тысяч соединений, и воркеров можно запустить много.

А можете кинуть линк где объясняется, за счёт чего это достигается? и почему не возникает вот такого же ограничения как у апача:
Как много воркеров (worker) мы можем запустить? Получить оценку сверху достаточно просто, нужно взять размер свободной оперативной памяти, поделить его на максимальный размер воркера, и мы получим некое N, повышать которое крайне нежелательно.
идеалистами, выстраивающими по крупицам безукоризненную архитектуру, ставящими ORM перед базами, которые никогда менять не придется...

Хех)) Вот предпологать что у нас есть что-то, что никогда не изменится(тем более в инфраструктурном слое), это недальновидно, и может аукнуться катострофически через годы. Внедрить абстракцию для работы с бд сейчас, гораздо проще и дешевле, чем переписывать тонны кода на десятилетнем проекте с захардкоженными запросами в БД
Думаю многим(например мне, но я уже не могу исправить минус) сначала показалось что вы просто решили набросить на PHP, т.к вас возмутила фраза «РНР. Это неплохой язык». Потом понял что вы не об этом из коммента ниже.
Ну и в принципе комменты в духе «Закрыл статью.» не очень приятны/полезны, так как наличие какой-то одной неточности или ошибки в статье в самом начале, это не повод ставить на ней крест, и публично об этом высказываться, показываю автору что он, как будто, потратил время зря.
Какую взять архитектуру? Ребята на Хабре пишут, что микросервисы – это клёво. Олег Бунин говорит: «берите микросервисы».

Да вроде никто не говорит, что начинать надо с микросервисов. Наоборот, сейчас во большинстве книг/статей о микросервисах пишут о том, что начинать нужно с монолита(естественно не забывая о low coupling и разделении bounded contexts) и выделять что-то из него по мере необходимости и главное наличии понимания того, какие проблемы мы решаем вынесением определенной функциональности из монолита, и какие издержки будем иметь.
В целом, мне кажется что ваши предложения, будучи формально правильными, являются несколько оторванными от реальности, поскольку не учитывают контекст задачи и требования бизнес-процессов.

Да тут, я соглассен что издержки будут. Но архитектурные ограничения — это стратегические инвестиции в будушее, их смысл уменьшить стоимость поддержки кода через год, три, пять. Допустим, сейчас мы создадим некоторый дискомфорт для малой части пользователей, но это окупится в дальнейшем тем, что у нас не будет фантомных трудноловимых багов, которые будут у 100% юзеров.
Но про бизнесс процессы это вы верно заметили, в большинстве проектов менеджменту насрать что будет через год и тем более 5 лишь бы сегодня закрыть побольше бизнес задач с как можно меньшими проблемами, а инициативы разрабов по поводу инвестиций в будущее не приветствуются. Так что, может я и не прав.
первых 20 лет существования РНР

PHP 20 летней давности — это явно не пример для подражания
чтобы сайт с миллиардной аудиторией падал при срабатывании type juggling

Прямо таки с милиардной?)) Очень хорошие показатели, учитывая, что по статистике ООН 50% населения планеты не имеют доступа к интернету.
А если серьезно, то необязательно раскладывать новый функционал на 100% аудитории, можно разложить ветку с изменениями для 1% или еще меньшей доли, и пофиксить баги, если вдруг они появятся + покрывать тестами. Также можно поэтапно вводить strict type, например только для новых/изменненых файлов, но не пытаться делать вид что ничего не произошло и продолжать работу при, например, строке, приведенной к инту.
Ага, это жопа ((
Поэтому всегда пред обращению к элементу массива приходится делать isset/array_key_exists
Все последние релизы наоборот идёт движение от этого(хоть и не так быстро, как хотелось бы), поэтому меня и удивила подобная идея.
Сначала мы даже хотели пропатчить PHP. Нам хотелось, чтобы если функция принимает какой-то скалярный тип (скажем, int), а на вход пришёл другой скалярный тип (например, float), то не кидался бы TypeError (который по сути своей исключение), а происходила бы конвертация типа, а также логирование этого события в error.log

Очень странное желание, обычно при разработке руководствуются правилом, что если происходит какая-то ошибка, то программа должна «упасть» как можно раньше. А здесь вы, по сути, хотели, чтобы функция уже получившая какие-то некорректные данные, во-первых продолжила работу с ними, а во-вторых, делала какие-то неявные преобразования, над уже ошибочными данными, еще больше усугубляя ситуацию
Класс должен быть ответственен лишь за что-то одно. Если класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой.


Опять статья про SOLID в которой НЕВЕРНО даётся определение основного принципа. Кому интересно, можете обратиться к первоисточнику — книги Роберта Мартина «Clean Code» и «Clean Architecture» и почитать как звучит определение на самом деле, а главное какой смысл заложен в этот принцип.
Не вижу я тут предпосылок для конкуренции.
Если они будут разрабатывать продукт в соответствии с идеями оригинального codeigniter(насколько я помню максимальнго успеха вторая версия добилась), то боюсь, что ударятся в то, что прогресс за упущенный период времени сделал некотоыре шаги вперёд.
А если это будет очередная компоновка компонентов симфони с каким то сахаром, под именем популярного в прошлом бренда то… смысл менять кому-то шило на мыло?
CodeIgniter 4.0.0 alpha1

Интересно насколько реально актуальна и востребована его разработка в 2018 году? Или ей занимаются энтузиасты, исходя из каких то ностальгических соображений?
Судя по числу плюсов, которое набрала данная статья, то «рерайт» этой информации можно каждый месяц(буквально, статья по ссылке от 10 августа) публиковать, а большинство будет радо
Мое мнение, что если человек биомусор допускает вождение в пьяном состоянии, то никакие ограничители не помогут(да он и ставить их не будет). Для них вождение в пяном виде эт прост такой прикол, как правило о последствиях(а тем более о последствиях для жизней и судеб других людей они не думают). Боюсь, что дело тут в личностных качествах, а не технических и административных ограничениях.
P.S Статья неплохая, было интересно прочитать.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity