Сразу стало понятно, что ответить всем не получится. Честно попытался сделать, но быстро сообразил, что проще написать еще один материал. Чем сейчас и занимаюсь. И так.
Ответы
Ответ на первый вопрос.
Нет, я не пытаюсь никого учить. Как минимум мне за это не платят. А делать столь тяжелую и, зачастую, неблагодарную работу бесплатно я не намерен. Так что здесь я просто высказывают своем мнение, с которым каждым может либо соглашаться, либо нет.
Ответ на второй вопрос.
Наши проекты. Не уверен, что здесь можно размещать подобные ссылки. Потому, если интересно, напишите мне в личку, скину их там.
И третий вопрос — самый интересный.
Наши инструменты. Ответ на этот вопрос, как мне кажется даст ответы и на все остальные. Потому здесь поподробнее.
Как правильно сказал Dinver, под те требования, что я пытался выдвинуть в отношение инструментов, для WEB разработки, подходят 90% микрофреймворков. Да именно так! Я не против вообще всех фреймворков. И не против инструментов, облегчающий разработку и снижающих ее время. Собственно об этом я писал в первой статье, но почему-то большинству бросился в глаза только заголовок. И более того — мы сами используем такой инструмент.
Откуда ноги растут
Не буду сейчас углубляться в сравнение существующих микрофрейворков. Это тема для отдельного большого материала. Хочу лишь сказать — писать свой нас заставило не то, что в существующих чего-то не хватает, а то, что на момент, когда в них возникла необходимость, а было это уже больше 10 лет назад, стоящих мы найти не могли. Сейчас положение вещей изменилось, но это уже, как мертвому припарка. Теперь то, что есть у нас, мы считаем ни чуть не хуже, а во многом даже лучше, аналогов. Конечно это дело вкуса, но то что для нас наш инструмент более удобен – наше мнение на которое мы тоже имеем право. А вот почему он нас устраивает, постараюсь продемонстрировать.
Суть
Во-первых, в основе всего лежит написанный нами gem для Ruby. И написан он на чистом Си.
Да именно так. Когда количество законченных проектов было уже достаточно существенным и пришло понимание, что 50% кода просто кочует из проекта в проект, мы решили не просто систематизировать свои наработки, а сделать их лучше и быстрее. А, что работает быстрее, чем код на Си? И, что может быть более дружелюбно к программисту, чем язык Ruby, созданный Matz-ом именно с целью облегчить наш труд?
Как следствие, сейчас с одной стороны производительность работы выросла в разы. А с другой, время отклика любой страницы написанных нами проектов укладывается в 300-500 mc при любых нагрузках. При этом, конечно, нужно упомянуть, что мы используем и своей application server, так же написанный на Си.
Для примера привожу скрин страницы одного из наших проектов. Это crn для типографий, позволяющая управлять, как процессом приема заказов, так и всем производственным циклом. На скрине страница списка заказов. Весь список не видно, но поверьте он достаточно внушительный. При этом по каждой записи выдается не только название и дата, но и краткая статистика. А именно: сумма оплат, перечень продукции, стоимость материалов по каждой, данные покупателей. Одним словом для формирования этой страницы приходится выполнять больше полусотни запросов. При этом время отклика 395 mc, а размер gem-a меньше метра
Подробности
Если Вас все выше изложенное не заинтересовало, то дальше можно не читать. Дальше будет просто небольшое описание. Совсем, совсем краткое. Если же кого-то оно заинтересуют, готов предоставить полную документацию. Здесь это вряд ли уместно.
И так. В gem-e, о котором я упомянул, собраны классы и функции, что мы используем чаще всего.
Главный класс носит название Vdcgi. При его инициализации происходит:
- парсинг HTML заголовков. Все параметры, переданные безразлично каким методом, а так же coocki, становятся доступны через массив «param» экземпляра класса. Если были преданы файлы, то ссылки них можно получить из массива «hash_img». Сами файлы до окончания работы скрипта хранятся в /tmp и затем удаляются. При парсинге параметров учитывается уровень доступа пользователя и переменная level, устанавливаемая в конфигурационном файле. Если уровень доступа меньше, чем level, то применяются жесткие правила, при которых из всех переданных запросов «выбиваются» потенциально опасные символы ' < и так далее. Если level больше, то в дальнейшем такие символы просто экранируются стандартной функцией библиотеки mysqlclient
- подключение к базе данных. Если подключение прошло успешно, то все запросы к базе можно выполнять через экземпляр класса.
- Происходит авторизация пользователя. Если «зашел» авторизированный, то получается его уровень доступа и все данные пользователя.
- Получается имя основного шаблона используемого для формирования страниц
- Устанавливается глобальная переменная определяющая язык интерфейса страниц
- Получается сео информация для запрошенной страниц title, leywords и так далее
Второй по значимости класс — VdMainapp. Вот некоторые функции это класса
- menu – формирует массив для вывода меню на странице
- writelink – создает ссылку
- get_class – возвращает массив классов которые должны быть инициализированы
- fotos – возвращает ссылку на фото и т.д
Перечислять все функции и классов смысла здесь нет. Упомяну только основной функционал
VdUser – работа с данными пользователя
VdKassa – все связанное с платежами и финансами.
VdVideo – для погрузка видео по ссылкам
VdNet – сетевые функции
VdAdmin – функции администрирования
VdImg – капча и фото
VDArcticle – все что нужно для добавления на сайт текстовых материалов
VDMessages – все для чатов, тикетов и т.д
Все выше перечисленное – очень, очень скромное даже не описание того, что есть. Однако, думаю, даже из него Вы поняли – только лишь gem-ом тут дело не ограничивается.
Действительно кроме самого gem-a есть еще:
- база данных (а точнее несколько – одна основная и по одной на каждый язык)
- набор шаблон для шаблонизатора erubis
- набор js скриптов
- набор заготовок для расширения уже существующих классов
- определенное количество Ruby скрипов работающих с AJAX функциями упомянутых выше js.
А еще есть cкрипт instal.rb который все это разворачивает по вашему запросу.
При запуске последнего Вам нужно будет указать директорию проекта и параметры подключения к базе данных. После чего в указанной директории вы получаете все необходимые файлы, а на вашей локальной машине сконфигурированный сервер nginx и фактически работоспособный сайт с минимальным набором страниц и админ панелью. В последнюю можно попасть с логином/паролем admin admin. Внутри Вы сможете добавить остальные страницы, определить их вложенность указать для каждой сео информацию. Ну а дальше – полная свободна творчества.
Несколько ложек дегтя.
Еще раз хочу подчеркнуть. Вопреки мнению некоторых, комментировавших первую статью, я не пытаюсь никого учить. Я даже не пытаюсь не то что навязывать, а даже предлагать работать с нашим инструментом. Хотя он есть в открытом доступе на нашем сайте, но всегда рассматривался только для «внутреннего потребления». Схема была проста – если какой-то функционал присутствовал более чем в 3 проектах, мы переписываем его на Си и добавляем в gem. При этом ни кто не старается навести особую «красоту». Как следствие, если рассматривать его как нечто, что я мог бы предлагать всем, то нужно признать, что проект достаточно сырой. В нем много чего не хватает. Например нет поддержки PostgreSQL (которую, кстати уже пишем) и еще ряда полезных «плюшек». Потому, если у кого-то есть желание познакомиться поближе, – милость просим, но только, как говорится, «под вашу ответственность».
Комментарии (14)
tuxi
02.12.2019 12:52+2Непонятна мотивация минусования, автор же честно рассказал о том, к чему пришла его компания, которая судя по всему работает не первый год и даже не два.
Если их собственный фреймворк помогает им вести разработку быстрее и дешевле и при соблюдении требований к проектам, то «почему бы и нет»?
За мои 15 лет в разработке бекендов, были кучи примеров таких «инхаус» перед глазами, причем иногда все начиналось с популярных фреймворков, которые потом допиливались/перепиливались до нужной функциональности и уже становились теми же самыми «инхаус». Но в конечном итоге, после жизненного цикла в 5 лет, становилось очевидно, что дешевле было сразу создать свое, нежели чем адаптировать что-то стороннее.
Сей рецепт не универсален, и есть тысячи случаев, когда именно не надо пилить свое, но это же не означает, что инхаус это всегда плохо?
vlom88
02.12.2019 14:25+2Проблема подобных инхаус фреймворков в том что какой-либо функционал пишется один раз, в тот момент когда он потребовался, и потом практически никогда не модернизируется, не улучшается, зачастую очень сильно отставая в развитии от технологий. Нет поддержки комьюнити, которое помогает выявить баги.
tuxi
02.12.2019 16:03+1Насчет не модернизируется вот не соглашусь. Если отдел разработки «пилит какое-нибудь и-коммерц ядро системы» для своей компании, то как раз ситуация может быть прямо противоположной. У нас как раз такая ситуация, выкатываем по 3..4 апдейта прода в неделю, из них как минимум 1 достаточно существенный. Приблизительно половина апдейтов случаются после обнаружения/устранения багов и по результатам профайлинга, а вторая половина — новые фичи или очередное А\Б тестирование.
У любого подхода есть минусы и плюсы. Если плюсы в частном случае перевешивают, то почему бы и не пойти таким путем? В нашем случае, мы получаем приличную производительность (по нашей предметной области). Никакой коробочный софт или фреймворк даже близко не сможет такое дать. И естественно продать на сторону этот свой «инхаус фреймворк» как коробочное решение (или фреймворк) мы не сможем. Но у нас и задачи такой не стоит.AleksShved Автор
02.12.2019 16:05+2Про апдейты — у нас практически аналогичная ситуация И про производительность — полностью согласен Причем для нас это главный приоритет.
SDFGHJLK
04.12.2019 08:15У кода не может быть проблем априори. Он написан и работает ровно так, как его написали. И у вас судя по всему нет проблем на вашем рабочем месте. И «движок» ваш крут. Проблемы возникают, когда программист либо уходит из вашего проекта или приходит к вам. В первом случае с большой долей вероятности знания о вашем «движке» можно оставить у дверей на выходе. С такой же вероятностью у вас при смене работы станет важным знать и уметь в «Симфони»(в кавычках). А нового коллегу придется учить вашему «подходу» и всем оптимальным ходам.
«То что один программист может сделать за месяц, два могут сделать за два.» — фреймворки помогают делать именно за месяц или полтора. Стремятся к этому.AleksShved Автор
04.12.2019 08:38Да в какой-то степени Вы правы. Если к нам приходит новый человек он какое-то время учится. Но знайте, что самое интересное? Когда-то у нас была попытка написать проект на рельсах. Взяли человека который утверждал, что рельсы он знает очень хорошо. Проект был достаточно сложный, как в общем и все наших проекты. Это был маркетплейс по покупке с доставкой сыпучих строительных материалов. Там было более 2к в водил которые размещали свои предложения и, когда заходил покупатель, для него нужно было автоматически сформировать наилучшее предложение на основании имеющихся прайсов (порядка 60к) расстояния доставки и еще некоторых факторов.
Так вот пока писалась общая «обвязка» проблем не было. Но как только дело дошло до основного функционала тут все и застряло. Чтобы понять как это сделать нашему новому сотруднику приходилось лезть в маны, в которых далеко не всегда получалось найти нужную информацию. То есть пять же учиться. Причем учить чужой продукт, согласитесь сложнее чем свой. А для части функционала решения вообще найти не удалось и пришлось писать костыли. В результате — время разработки выросло непомерно и продукт получился, честно говоря не очень.
Так вот мораль сей басни такова — если Вы пишите какие-то стандартные проекты, в которых нет особо сложного, уникального функционала Вы вполне можете обойтись коробочными решениями. Тем более для большинства их заказчиков те mc, о которых я писал, честно скажем, значения не имеют. Но если вы делаете, что-то более сложное и уникальное то тут «швейцарский нож» с кучей инструментов не подойдет. Нужен «десантный нож» который может и не «умеет» кофе подавать, но в своей специализации на высоте. И иногда его приходится «ковать» самим. Потому мы и не берет дешевые проекты )SDFGHJLK
05.12.2019 22:16Под узкоспециальные задачи или ресурсоемкие процессы легко написать микросервис, отдельного «демона» или «воркер» хоть на вашем хоть на С. При этом обвязка будет написана любым из 1000 без дополнительного обучения.
AleksShved Автор
02.12.2019 14:57+1Вот тут позволю себе не согласиться. Весь функционал постоянно дорабатывается и улучшается. У нас часть наших программистов работает над проектами заказчиков, а часть над инструментом для них и это процесс постоянный.
Virviil
02.12.2019 19:45-2«Приходите к нам, у нас вы за месяц научитесь пилить на НЕфреймворке, и наберетесь ценного костыльного опыта, который вам нигде не пригодится, потому что на этом НЕфреймворке больше никто не пишет»
Какой программист в здравом уме пойдёт к вам закапывать себе карьеру?
AleksShved Автор
03.12.2019 08:18Кто сказал что мы кого то приглашаем? А по поводу ни кто не пишет — почитайте посты выше. Да и за месяц Вы программистом точно не станете. Это байки «интернет экспертов»
SbWereWolf
«фреймворки не нужны поэтому мы используем in-house аналог»
JustDont
«У нас был собственный вебсервер, CGI, взаимодействие с базой данных, авторизация, и формирование клиентских страниц, а еще это было написано на си. Не то, чтоб это был необходимый запас для всех нужных нам фич, но включив NIH-синдром, остановиться уже трудно. Единственное, что у меня вызывало опасения — это сторонние фреймворки. Я знал, что рано или поздно мы перейдем и на эту дрянь...»
tuxi
"… и соскочить с нее будет очень трудно"