среда, 23 декабря 2015 г.

немного о mwce и о планах

Наконец, взялся за написание гайдов "как напилить свой модуль на коленке" с примерами и скриншотами. Забавно, но пока написал первую четверть, нашел небольшую недоработку, поправил... И тут меня посетила мысль, что опять надо будет делать билд, собирать архив, сувать его на обменник.. долго, нудно, а, главное - лень. Вспомнился старый добрый уже давно запиленный модуль для получения обновлений (еще на версии 1.5.3 и 1.6.0), и скорее всего, надо сделать локальную установку патчей. Но вводить его буду, когда пойму, что процесс пошел и народ, наконец, начал что-то сам писать.

Вообще, забавно.. На данный момент, аналога движка для му нет... вообще нет: и бесплатный и куча ништяков может делать...
Либо я не донес до народа, либо народ зажрался...


суббота, 5 декабря 2015 г.

немного поработал с php 7

собирал по-быстрому пыху с офф сайта вин сборку + апачу отсюда. Настройка стандартная, в общем-то, ничего существенно нового не прибавилось (единственное, если сидели на апаче 2.2, то на 2.4 изменено order allow deny, имейте ввиду) Как я писал ранее, весьма себя оправдывает новый движок: где-то работает так же, а где-то в разы быстрее выходит. Пока побаиваюсь ставить его на продакшн, но ковыряю и подгоняю CMS под стандарты 7ки. Вот тут есть видео про новые возможности (требуется регистрация). Более-менее внятно человек ведает о what's new.
О своих впечатлениях могу сказать так: все замечательно, но есть 1 большое но: нет адекватных инструментов для работы с mssql или я слепой... это несколько удручает, но поживем-посмотрим и найдем еще..

вторник, 1 декабря 2015 г.

php 7

Поставил, поработал. Впечатлило. Очень впечатлило.
Причем мерил с тем, что у меня в продакшене, с тем, что по-быстрому поднял на ноуте
да, у меня винт 7200 оборотов, но на сервере ssd да и проц по-серьезнее. В общем и целом могу сказать, что версия с 7 на ноуте работала не хуже чем с 5 на сервере. по скорости не уступает, а кое-где и быстрее (сотые секунды, но при больших выборках это решает).
Да, забыл, речь про mwce .

вторник, 17 ноября 2015 г.

Starcraft 2: Legacy of the Void

Starcraft 2: Legacy of the Void. Прошел за 2 дня, почти на "казуальном" уровне - сюжет был самым интересным местом.
Общие впечатления:
  • багов не найдено. Карл.. нет багов! (огромная куча самого вонючего дерьма с наилучшими пожеланиями кидаю в сторону valve - берите пример, криворукие маркетологи и программисты, как надо работать. Близы, оказались на высоте)
  • Интересный сюжет. Для себя отметил, что играть за протосов, пожалуй, наиболее комфортно 
  • Похоже, что задел на продолжение есть. 

пятница, 30 октября 2015 г.

Продолжается перепись и модернизация двигла... пока на работе только видны результаты: на паблике все несколько потише... хотя, документацию потихоньку начал писать на форуме.
Надо будет еще сайт обновить... только, вот сил на всех со временем не оч хватает, но мы и не торопимся.

воскресенье, 11 октября 2015 г.

Что такое MVC (Nodel-View-Controller) моими глазами. Тут только теория и много пьяных букв.

Самое первое, о чем хотелось бы сказать - я не претендую на истину в последней инстанции и все ниже написанное может показаться кому-то бредом. Запись будет написана в, мягко говоря, не деловом стиле, так что подумайте еще раз, прежде чем читать дальше. Вы можете смирится написать в комментариях здравую критику, я только за. 

Второе, о чем хотелось бы сказать - я не являюсь теоретиком, а на 80% все познаю в практике, из-за чего могу быть неправ или не совсем прав. Так же из меня ужасный учитель и "объяснятель", так что если Вы все еще хотите читать дальше... вобщм, я предупредил.

Третье, но уже по теме: MVC является паттерном, то есть шаблоном программирования, который перерос в религию "тру-программистов". Шаблоны, если говорить на чистом и любимом русском - варианты решения типичной ситуации. И поэтому всегда, слышите? Всегда прежде чем использовать тот или иной шаблон трижды (если такой же как я, то все 5 раз) подумайте, а подходит ли данный шаблон под вашу ситуацию или нет, если нет, то не надо использовать что-то притянутое за уши. Пожалейте всех тех, кому сопровождать ваш код, ну или себя, если это будете Вы.

Что же, кто выдержал эти три первых абзаца разминки, дерзайте, я начинаю...

MVC он же Model - View - Controller (Модель - вид - Контроллер(управление, по-русски)) шаблон(алгоритм) программирования, в том числе используется PHP (на котором я иногда говногодю). В последнее время, данный принцип можно встретить в 99,99% серьезных проектов(сайтов), начиная от известных фреймворков типа симфонии yii, заканчивая моим тетрисом - mwce.

Принцип работы

Идея MVC, примерно, в следующем: ваш сайт делится на 3 логические части, которые вы описываете в 3 классах для каждой страницы сайта:

  • модель
  • контроллер
  • вид

Модель отвечает за данные. Вид отвечает за внешний вид страницы, то есть это интерфес. И контроллер, понятно из названия, управляет результатом, что предоставляет ему модель, чтобы потом некоторые из них появились у вас на экране через Вид.
Так же важно учесть, что модель - это не просто прослойка между базой данных и контроллером. По сути, модель работает с данными: перебирает, запрашивает у базы, может проверять, посылать, сортировать, в общем, вся работа с даннами проходит именно в ней...
Если не совсем понятно, то  представьте, что контроллер - начальник, который получает задачи от клиента, и в зависимости от его[клиента] хотелок требует и раздает поручения: модели получить и отсортировать определенные данные, а виду их отобразить на экран, вот оно и будет. Да, и не забывайте, что у начальника может быть много подчиненных (В том числе, из соседнего отдела Васи, который одолжит оных за определенный ништяк), то есть 1 контроллер может запрашивать данные с разных моделей, если это действительно нужно.

Для чего это надо и чем полезно

Во-первых, MVC почти всегда реализовывают на ООП (ни разу не видел этого в функциональном виде, хотя, думаю, при желании можно). А что такое объектно-ориентированное программирование? Правильно, это классы с инкапсуляцией, наследованием и полиморфизмом. Если не понятно о чем я говорю, то прежде чем пережевывать написанное тут, очень рекомендую поплотнее познакомится с ООП и с его плюсами и минусами.

Во-вторых, мы получаем некоторую степень абстракции, что позволяет нам не меняя архитектуры и принципов создавать и достаточно быстро создавать, новые страницы с совершенно разной логикой (что на 80% зависит от модели, на 15% от контроллера и на 5% от вида).

Как правило, все контроллеры и модели являются потомками родителя - контроллера и родителя - модели. ( с видом обстоит по-разному, все зависит от того, как реализован класс). Для чего? А все просто: в родителях описывается обязательное поведение для потомков: входная точка для контроллера, например. Подключение к базе данных и подключение ряда нужных данных(чтение файлов, разбор конфигов) для модели.

То есть, если так получилось, что вы меняете, например, базу данных с mysql на ms sql, все, что вам будет нужно - отредактировать модель (ту прослойку где идет работа с бд, возможно, это отдельный класс, что подключается к модели), причем, в большинстве случаев только 1 - родителя и все.

Если же требуется добавить логику или реакцию на какое-то действие пользователя, то вы точно знаете, что начинать нужно с контроллера. В этом заключается вся гибкость: не нужно лазить по всему коду и искать, какие же мне надо изменить строки, при постановке задачи уже будет ясно, что и где менять + так как все части независимы друг от друга, их можно перелопачивать не боясь, что поломается все.
Но всегда нужно помнить, что стрелять по воробью из танка хоть и весело, но глупо: писать "хелловорд" в паттерне MVC, зная, что он точно не будет развиваться - пустая трата времени.

вторник, 6 октября 2015 г.

Почему не стоит начинать играть в CS:GO

В первую очередь, хочу сразу заметить, что это лишь мои умозаключения и наблюдения, основанные на моем собственном опыте, как программиста, так и игрока.

С чего все начиналось или позвольте представиться.

С counter-strinke я познакомился в начале двухтысячных, где-то в районе 2003-2004, может быть, чуть раньше. Точно сказать не могу, так как учился еще в школе. Помню только, что первая "играбельная" версия моя была 1.5, хотя чуть позже я видел и более ранние версии. Более-менее, по-геймерски, я подошел к игре где-то в 2006 году. На тот момент был пик всяких городских соревновашек по "каэс" и каждый "настоящий пацан" был в "тиме" и резался в игровых клубах... в общем, к чему я... А к тому, что мало-мальский опыт и понимание игры у меня было и есть. Поиграв пару тройку лет, побывав в команде, поиграв внутри колледжа на внутренних "соревнованиях", как - то благополучно отошел от нее. Да, кстати, забыл, еще основательно игрался в quake 3 arena, в общем, люблю иногда "пострелять".

...К кс я "вернулся" примерно года полтора назад, сначала вспомнил про 1.6 и периодически "восстанавливал скилл"  на дм-ах  и пабликах. CS:S я попросту пропустил, она для меня как windows vista для понимающих, в сравнении с тем же cs:go (как с win 7) и как win XP, с 1.6.
Так вот, поигравшись чутка в 1.6 я все-таки пересилил себя и решил взглянуть, чем же так разительно отличается эта ваша "каэс го". Ну, с точки зрения концепции, cg:go - весьма не плохое логическое развитие старой-доброй 1.6, но теперь эта игра приносит еще и прибыль и в первую очередь, огромную прибыль valve, как от визуальных моделек оружия, наборов музыки, наклеек, внутриигровых событий (в игре они называются "операции" (на данный момент, последняя закончившаяся - "bloodhound")), в принципе, законно и справедливо.. почти.

Первые звоночки

Ну как олдскульный олдфаг, считающий, что у него большие ...амбиции, более-менее, приноровившись к новой для себя динамике игры я пошел "катать катки" - играть в рейтиноговые игры - "соревновательный режим". Суть режима проста: стандартная 30-раундовая игра (за террористов и за спецназ) до 16 побед одной из сторон или ничьей в случае счета 15:15. Задумка автоматчей - супер, но вот реализация... В общем, самое первое изменение - уменьшение тикрейта до 64 в непрофессиональных играх, в то время, как на любом сервере 1.6 тикрейт по умолчанию не ниже 128.

Что такое тикрейт и что происходит, когда он низкий.

Чтобы четко понять, что это такое, сначала небольшой экскурс "на пальцах" в архитектуру. Архитектура CS клиент-серверная. Что это значит: все компьютеры, на которых включена cs  и играющих на 1 карте (игре) отсылают данные одному серверу. Сервер обрабатывает данные и отсылает клиентам ответ, по сути как начальник указывает клиентам что им делать.
В эти данные примерно входит: местонахождение игрока, движение, выстрелы, оружие, взрывы, ослепления, в общем, все движения в игре.
В ситуации, когда игроки стреляют друг в друга именно сервер решает кто в кого попал и кто увернулся, понятно, что с огромным числом особенностей. Так вот, тикрейт - это период, с которым сервер синхронизирует данные  и чем он выше, тем точнее и актуальней данные. Очень не плохое объяснение (в скриншотах) есть на этом ресурсе.
Чем чреват низкий тикрейт? а все просто. Помимо времени обновления и синхронизации данных на сервере, существует еще и скорость доставки данных до сервера и потеря некоторого числа данных по дороге. Так вот, из-за всех этих особенностей можно увидеть следующую картину: выбегаете вы такой довольный и высаживаете пол обоймы в глову человека (причем, при таких условиях, что промахнуться - невозможно), а он мало того, что не получает вообще урона, так еще и убивает вас. Это утрированно, но чем выше ваш уровень и уровень оппонентов, тем острее становятся эти вещи. На моем уровне счет идет на доли секунды и я уже очень сильно ощущаю это "фитчу", когда в тебя из-за угла прилетает пуля в голову причем, не через стену, а прямой наводкой. Это значит, что человек успел высунуть дуло и выстрелить, но я этого даже не увидел, причем дело не в моей реакции, А действительно, моделька игрока или оружия не высовывалась из-за угла.
Да, забыл упомянуть, на каждый матч в соревновательном режиме пишется демо (в демо все действия с точки зрения сервера, не клиентов(игроков)), которое можно потом посмотреть, как играл ты и твои оппоненты (очень полезно для работы над ошибками).
Так вот, каково же мое возмущения, когда я на втором экране включаю видео, что писал с игры и сравниваю демо и видео, там, как раз, данный случай четко характеризует проблему и таких возгласов цельный интернет. Valve со своим плюрализмом специально опустили тикрейт для "непрофессиональных игроков" до 64, мол, все это может компенсировать пинг и мощность компьютера (в плане отображения кадров в секунду: когда оно ниже 60, лучше не играть в cs). Но это еще не все.

О читерах, бустерах и других несправедливостях.

Не так давно в cs:go ввели патрули. То есть, сыграв не менее 150 игр, со званием выше silver valve дает возможность просматривать демки и оценивать игру других игроков на предмет нечестной игры. Отличая мысль! Но... решение принимается коллегиально, голосованием определенного кол-ва игроков, срок принятия решения может быть более 2х недель.Сколько за это время можно "убить" званий игрокам посчитать не сложно, и кстати, если читер будет особенно хитер, то его могут забанить, а потом и разбанить, в случае, если он сумеет доказать, что это не чит.
 Аккаунт "признанного читера" банится в рейтинговых играх и весь его инвентарь так же банится, унося с собой все заработанные шкурки для оружия. Чем это плохо: в рейтинговый игре существует 2 вида читеров:

  • те, кто просто не умеют играть по-другому
  • те, кто специально за деньги поднимает звание игрокам 

И еще один вид не читеров, но читеров - те, кто заведомо имеет очень высокое звание, но играет против людей, что в несколько раз слабее по званию и опыту, поднимая звание аккаунту или команде, опять же, за деньги или для хорошего видео на ютуб.
Читером назвал я таких людей потому что против тех, которые играют в cs 20 часов всего, встает "читер" - человек с опытом, как правило, выше 400 часов, предугадывая все их действия, убивая с 1 выстрела или ножа (что, пожалуй, еще обиднее). Как вы считаете, какое настроение будет у вас после такой вот игры или у вашего дитя, что в нее играл. Нервное? Возможно, это даже мягко сказано. Но, как минимум, настроение будет попорчено и скорее всего, в следующей игре и не у 1 человека.


Еще одна несправедливость, как следствие предыдущей, или то, что можно назвать просто "фартом", вы играете в команде с игроками, которые не заслуживают то звание, которое у них есть, а против вас играют "заслуженные". Подобная "катка" бывает просто адом - вы читаете игру, вы если не сильнее, то наравне с оппонентами, НО ВАША КОМАНДА... в общем, это из разряда - я все понимаю, все делаю, но сделать ничего не могу и виноват не я - кусай свои локти, друг, если достанешь.  

В результате, настроение ваше может быть, мягко говоря, подпорчено от таких вот игр, это не есть гуд. Но и это еще не все.

Слово - не воробей, вылетит - не поймаешь.

Никогда, повторяю, никогда, даже своему врагу я не пожелаю играть с разноязычными игроками в одной команде. Чем это чревато: непонимание -> раздражение -> оскорбления -> большая вероятность слитой игры и настроения. Особенно опасен тот самый момент, когда команда состоит из пары русскоязычных игроков и выходцев из Польши, Литвы... Если они прознают, что вы - русский, то в большинстве случаев кроме слов "kurwa, fu*k  you" и т.д., вы ничего не увидите и самое страшное, не услышите. А если еще учесть, что средний возраст игроков - 14-18 это очень печально. Честно сказать, будучи человеком с возрастом уже за 25 лет, я узнал некоторые нецензурные выражения, о которых раньше даже не ведал. Самое страшное, что люди оскорбляют даже не вас, а ваших родителей, и похоже, сами того не понимают. Что так же убивает ваше настроение, мораль в игре и моральный уровень.

О заработке в CS:GO 

 У истоков концепции cs:go, похоже стоят евреи - деньги в данном сообществе делаются, буквально из воздуха и света. Покупка продажа игровых предметов за реальные деньги, повышение званий за реальные деньги(буст), сайты - лотереи, где можно выиграть шкурку на оружие за реальные деньги, сайты - мошенники. Я знаю 2 больших портала, который за деньги предоставляет доступ к своим внутренним лигам для игры в  CS:go, отличие от того что есть - меньшее количество читеров, так как существует абонентская плата и античит, помимо vac'a. Работа стримером и ютубером, то есть, производство роликов с собой в главные роли по игре, начиная от гайдов, заканчивая приколами. Воровство аккаунтов, причем, чем больше дорогих шкурок оружия у вас есть, тем больше шанс, что у вас сопрут аккаунт, а если учесть, что аудитория несколько не подкована в IT-безопасности, то этот шанс изрядно повышается. Не однажды я сталкивался в игре с людьми, которые сетовали, что у них украли скины или же аккаунты на сумму от 5000-10000 рублей, на вопрос, зачем вы столько вливали денег я так и не услышал внятного ответа. И последний вид "заработка" - внутриигровой: за игры вам иногда выпадают оружия или ящики, которые можно продать на внутренней торговой площадке или обменять на другие вещи у игроков.

Вместо итогов

В cs:go я поигрывал примерно год- год + пару месяцев, за это время было выиграно в соревновательной игре 200 игр (не считая тех, где я играл с читерами), статистику проигрышей, я не знаю, но думаю где-то не менее 100-150, "наиграно" более 2000 часов в общем. На всех основных "оружиях" у меня настреляно не менее 1000 убийств, на второстепенных в среднем 300, на АК и m4 более 4700 на каждом (причем, за последние месяцев 6), "набивалось" все это на паблик серверах, дм и в соревновательном режиме, соотношение паблика к соверновательному режиму "по набиву" - 1/3, хотя, в последнее время стал 1/2, звание в соревновательной игре  - "биг стар" или distinguished master guardian, это чуть выше "среднячка". Начинал после "калибровки звания" с silver 2 или silver 3 (Да, я прошел почти через все круги ада в этой игре). Это не хвастовство, это статистика, чтобы вы понимали, что я знаю, о чем говорю и не писали, что это "плач рака". Я - командный игрок и для меня всегда на первом месте стояла не моя статистика, а выигрыш команды. + я реально до сих пор получаю огромное удовольствие от слаженной командной игры, где есть и тактика и поддержка, несмотря на тот совершенно ужасный уровень качества самой игры: игра вышла в 2012 году в ней до сих пор есть баги и недоработки. Это говорит о уровне тех, программистов, что пишут игру. Проверить новую "архитектуру" cs:go легко и не принужденно - просто зайдите на deathmatch (dm/дм) сервер, где народу будет хотя бы 15 человек и сравните с тем, что было в 1.6 это красноречивей всех слов.

Итак, на данный момент, зная, что меня ждало в игре, честно, я бы не стал даже думать об этой ней, где бОльшая часть ее механизмов сейчас направлена только на заработок и получения сомнительных регалий, в обмен на нервы, настроение, и в большинстве случаев впустую потраченное время. Если же вы все-таки решили купить и поставить оную, чтобы часок посидеть на классик сервере - то предупреждаю сразу: остерегайтесь болезни моделек! если затянет, то будет худе азартных игр!

Простите за столь сумбурное изложение, просто наболело, нужно выпустить было пар.




суббота, 3 октября 2015 г.

Работа над "билдом" muonline

...идет полным ходом, но... в основном, по выходным.

Что уже сделано:

  • подобран диз (название на одном известном форуме у темы espada-legend, но сам диз сделан для thanatos'a)
  • все элементы диза разбиты по плагинам
  • сделаны плагины авторизации, серверов(qinfo), меню
  • модули: новости, показ ошибок 

Скорее всего, сначала сделаю упрощенную версию и выложу ее. далее посмотрим, как пойдет.

среда, 23 сентября 2015 г.

как оно это все.. ну там... внутри (о фитчах)

Шаблонизатор

При генерации страницы (ф-я out) так же из папок темы css и js "подтягиваются" скрипты с названием папки, то есть, если вызвать out("main","news"), которая "кушает" шаблон main.html из папки news, то при генерации html-кода будут проверены на существование файлы:
theme/название_темы/js/news.js и theme/название_темы/css/news.css.

Если они существуют, то их содержимое будет помещено в |global_js| и |global_css| в index.html темы. Так же учитываются и плагины. То есть, весь код или стили будут в 1 месте, а не подгружаться вместе с каждым шаблоном.

О кешировании

Теперь в контроллере есть возможность кешировать (визуальные) результаты работы любых  методов класса, либо по названию метода, либо задавая свои собственные названия

О плагинах


Плагины теперь тоже имеют права доступа для групп, что дает дополнительную гибкость и использования оных для постоений меню и прочих "фишек" для отдельно взятых групп.

О меню


  • В меню вновь вернулась возможность управлять порядком позиций (через админку, естественно). 
  • Идеологически, все меню рекомендуется реализовывать в плагинах. 1 плагин отвечает за 1(?) меню.

понедельник, 21 сентября 2015 г.

Первое видео MWCE 1.6.2 - альфа-версия.

Накатил ролик, чтобы вы могли посмотреть на то, о чем я столько написал (и не лень же было).


Вкратце пробегусь, что на видео:
С самого начала, я показываю установку: возможные типы подключений (кстати, расширяемо + намек, что это может быть не обязательно только ms sql), адрес до сервера с бд и авторизационными данными.
Далее, вид админки (цифры, что слева на фоне авторизации - генерация. чуть врет, зараза, можно не обращать внимание):
- авторизация
- кратенький "пробег" по основным модулям.

Внимание обращу на то, что время от времени я выбираю "билд" и вот для чего: так как, я уже упоминал в прошлых записях, что "билды" имеют независимые настройки, нужно переключаться между админкой и нужным "билдом", чтобы настроить конфиги, "запилить" плагины или страницы, другого способа как сделать универсальней я, к сожалению, не придумал.
Да, еще упомяну об одной вещи: для каждой базы данных админка будет своя. То есть, для каждой базы пара - сайт(может быть не 1) + админка. Усложнять, пока не вижу смысла

суббота, 19 сентября 2015 г.

как оно это все.. ну там... внутри (о шаблонизаторе)

В данной статье речь пойдет о шаблонизаторе и, наверное, наиболее интересной эта тема покажется дизайнерам и девелоперам.

Начну с того, что было раньше. Для новичков - в MWC есть свой шаблонизатор (угу, он же view). Это не smarty или иной известный продукт, а самописный ... класс, основная идея которого была вычерпнута из интернетов - "резервируем" слова и заменяем их на словарик. Как это работает внутри сейчас смысла рассказывать не вижу, а вот что изменилось со старых версий рассказать стоит. На данный момент, скелет темы выглядит так:
theme - общая папка тем, admin - тема админки, внутри много папок, одна из которых html. Все папки в html  кроме public содержат шаблоны к определенным скриптам (по названию папок), в public лежат шаблоны главной страницы, страницы логина и ряда плагинов, где по 1 шаблону на "брата". Кстати, images, js,scripts,css отведены под "особенные" скрипты или ксс файлы, которые используются только в данной теме. Суммируя увиденное - я упорядочил файлы и скомпоновал их по смысловой и служебной нагрузке, а то вот такое несколько неудобно:

Возможно, перфекционизм со мной сыграл злую шутку, но мне вот так лично мне нравится больше:

Это несколько изменило функции, которые отвечали за "показ на экран", теперь туда в некоторых случаях нужно будет указывать папку, в которой находится тот или иной шаблон.

Так же были пересмотрены функции, которые добивали словари, в общем, из такого вот безобразия получилось другое безобразие :) :



На этом, думаю надо заканчивать повествование... да, кстати, сейчас полным ходом доделываю инсталку для админки (сопсно, ядра), потом пишу немного howto, а потом скорее всего beta версия будет в свободном доступе.





пятница, 18 сентября 2015 г.

очередная alpha muwebclone engine

Вместо введения.

Добил, наконец-то, до альфа версии обновленный движок. Ну, точнее как, добил я его гораздо раньше, админку долго и усиленно выпиливал и допиливал. Многое убрал, многое пересмотрел, с учетом опыта пользования:
Вот так теперь выглядит меню админки. Кто пользовался предыдущей версией увидит, что названия страниц были изменены на более простые и добавился плагин, что показывает билд, но о нем позднее.

Итак, суммарно и доходчиво, что же нового будет в данной версии и чем она отличается от предыдущих.

Самое первое, на что хочется обратить внимание: наконец-то есть полноценная работа с MVC, но изначально, когда сей велосипед [движок] был изобретен, он позиционировался, как наиболее простой и быстрый в разработке и добавлении своих модулей. А чтобы писать применяя MVC, все же, нужно изучать движок и знать некоторые особенности, а это долго и порог вхождения явно выше, чем просто функциональное программирование.
Поэтому я долгое время не хотел уходить от модели "почти MVC". Движок давал песочницу и ряд инструментов-игрушек, чтобы можно было "играть" в ней. Но в силу того, что я использую MWC еще и в enterprise, я "уперся в потолок" возможностей старой версии. И, волей не волей, мне пришлось думать, как увеличить себе высоту потолка, чтобы не упираться, но в то же время совсем убегать от старых наработок не хотелось, так как накидать функционально модуль с надписью "привет мир!" куда быстрее, чем городить шаблон, писать модель и управлять контроллером... в общем, меня посетила мысль.. точнее 2: 1 - а зачем отказываться; 2 - почему бы не совместить. И действительно, в данной версии, 1.6.2 можно писать и с идеологией MVC и обычным функциональным программированием и не париться ни о каких классах.

Идеология.

Движок стал похож на фрейморк(набор инструментов) по структуре(да и не только по структуре).
В корне находится 6 папок и пара-тройка файлов:

Папка app содержит в себе родительские классы контроллера, модели, шаблонизатора и ряда вспомогательных классов. В папке configs можно найти файл с настройками самого ядра, libraries содержит сторонние библиотеки, например, phpexcel. Некоторые логи хранятся в текстовом виде в папке log, а в theme хранятся, очевидно, темы. 
Самая интересная папка - build, в ней хранятся, сами "сайты". Админ-панель тоже является отдельным "сайтом" и вот так выглядит ее структура папок (равно как и для любых сайтов в папке build, дефолтная структура буде именно такой):


Структура папок сильно напоминает ту, что была в предыдущей версии, единственная разница лишь в том, что вместо "pages" теперь "controllers" и "models" (к слову, названия можно менять как душе угодно), в которых, соответственно, находятся контроллеры и модели. Каждый билд рассматривается как отдельная сущность со своими конфигурациями. 

Что дает такой подход:
  • Возможность расширится (плагинами) до переключения между билдами, что может позволить использовать сайт в нескольких ипостасях: например, гостевая книга и полноценный продакшн сайт или сайт для сотрудников компании и сайт для клиентов, или, в случае с muonline, каждый билд - разный сервер... в общем, все ограничивается только потребностями.
  • Возможность работы с разными базами данных и разными серверами, так как конфигурации независимы.
  • Гибридный подход к разработки модулей и плагинов: простое функциональное программирование или MVC подход.


про удобство и настройки рассказывать не буду. кто пользовался - знает.
    

Распространение.

Само ядро будет совершенно бесплатно. + к нему будет приложен пример работы. Ряд "билдов" под определенные направления тоже будет выложен совершенно бесплатно.

В чем моя выгода.

Примерно, с версии 1.4 я хотел сделать платформу для разработки сайтов. Тогда тематика была узкая - Muonline. С течением лет мои потребности, как и взгляды менялись (думаю, это нормально :) ), по развитию самого движка это можно проследить.
Так вот, цель была создать платформу - на данный момент считаю, что я близок. Чем она выгодно отличается от того что уже есть, имею ввиду симфонии, уии и т.п. ? Да, наверно, ничем. MWC был(да и есть) хобби, результаты которого я использую и на работе тоже.
Ну и понятно, что ежели вдруг найдутся те люди, кому надо будет напилить сайтик и обратятся ко мне, у меня есть готовый инструмент. Удобно? я считаю да.

понедельник, 14 сентября 2015 г.

как оно это все.. ну там... внутри (о плагинах)

Вообще, лучше начал измышления с определения:
Плаги́н (англ. plug-in, от plug in «подключать») — независимо компилируемый программный модуль, динамически подключаемый к основной программе и предназначенный для расширения и/или использования её возможностей. Плагины обычно выполняются в виде библиотек общего пользования. (https://ru.wikipedia.org/wiki/Плагин попутно замечу что геолокация ru.wiki аж в далеких сша, по сему стоит относится ко всем материалам несколько с сомнением
 Ну, вроде как все подходит: подгружаются в главное окно независимо от страниц и расширяют функционал (авторизация, поиск и т.п.) и как показывает опыт, это реально бывает очень и очень удобно. Но вот, при реализации возник вопрос: делать ли зависимость плагинов от групп, то есть, для группы "гости" показывать панель авторизации, а для иных групп - нет, выходит очень удобно: не надо делать лишние и пустые проверки внутри самих плагинов - все уже укра.. сделано за нас.

Но плагин авторизации - тривиально, в энтерпрайзе все гораздо интереснее: что мешает на определенные плагины вешать меню для определенных групп пользователей (отделов)? в старой версии это был отдельный тугой класс, который отвечал за строительство меню и плагины занимались лишь отображением, зато при новой реализации требуется лишь создать модельку меню с основными методами, а потом наследовать для каждого плагина и редактировать потомка уже под особенности каждого меню, при том, что меню так же смогут иметь разные шаблоны для отображения, свое кеширование и т.п., но будут более гибкими. Красота...

Поэтому отвечая на свой же вопрос, а надо ли, даю ответ: да, надо. пусть это будет чуть-чуть сложнее, чем было, но слишком много плюсов, чтобы отказываться.

единственное, чем. пожалуй, пока ограничу плагины - у них не будет бегрануда (он просто им не нужен, во-вервых, а, во-вторых, если их оставить, то каждый модуль помимо своей работы будет выпиливать еще и работу плагинов, а оно нам надо?).

понедельник, 7 сентября 2015 г.

как оно это все.. ну там... внутри

Сия запись - рассуждение, анализ уже содеянного, для тех, кто, возможно, пойдет тем же путем. Речь пойдет о новой версии MWCe, та, что с именованием 1.6.2.

Итак, первое, с чем мне пришлось столкнуться при переходе с недо-mvc, на mvc - что делать с плагинами: в старом варианте они выполнялись чуть раньше генерации страниц. По факту плагины - почти те же страницы, просто они выполняются при любом вызове любых страниц, так как они составляют часть интерфейса, а фактически, на них возложена мелкая, но очень нужная логика: отображение определенных менюшек для определенных групп пользователей или банальный логин и т.д.

В текущем же случае, получалось несколько странно: либо вписывать их в головной Controller, чтобы при каждом обращении к очередной странице оно все генерировалось и не надо было бы заботится о том чтобы вписывать их каждый раз, но большое "но" заключалось в том, что это "почти" страницы, да и как быть с ajax запросами к страницам, тоже генерировать плагины, что там и не нужны?..  В общем, даже если я их и вписываю в контроллер, то остается вопрос с использованием MVC в плагинах, так как если уж писать  как положено, так сразу, а не "потом допилю" - нет ничего более постоянного, чем временное.
Делать нечего - напилил PController специально для плагинов, отличие от страниц в том, что в плагине точка входа только одна, потому что, в любом случае, вызывать экшены как-то не нужно (ну, по крайней мере, в моем видении), хотя при желании можно сделать ajax запросы и достичь нужного функционала.
На самом деле, вышло совсем не плохо: получилось так, что на уровне плагина можно при определенных обстоятельствах изменить страничку без перезагрузки, так как плагин запускаются гораздо раньше (банальная подмена get-параметра страницы усе решила), чем генерация страничек и вообще их логика, что очень удобно при сокрытии страниц от определенных пользователей или  при выведении логин-формы. Свои велосипеды я пока выкладывать не буду, но придет время - все можно будет скачать и посмотреть на мой кривой код и лайв-примеры.
Единственное, что меня беспокоит - для каждого плагина по факту инициализируется 2 класса: контроллер и модель, коннект к бд проходит чуть пораньше и всего 1 раз, так как иначе создавать подключение для каждого плагина (коих может быть сколь угодно) + еще страница было бы подобно выстрелу себе в ногу и расстрелу сервера баз данных, по понятным причинам. Тык вот, время генерации и потребляемые ресурсы. сейчас пока пишу админку, так сказать - сердце самого движка (если мозг - контроллеры и модели) смотрю и стараюсь воевать за каждую сотую долю времени генерации...

среда, 2 сентября 2015 г.

воскресенье, 30 августа 2015 г.

Немного о старом и еще чуть-чуть о новом MuWebClone и о его развитии

Я как-то подзабросил блог. Надо бы чуть-чуть его подраззабросить.
***
Сопсно, речь поведу о новом mwce, шо будет нового и как оно примерно будет работать. Пока это мысли-наработки, частично даже  реализованные.
Итак, прежде чем говорить о версии 1.6.2, вспомним, а что было до... Хотя, скорее для себя я вспомню :).
Сначала было слово... ну, это понятно.
Первый страшный mwc был создан на основе тогда знаменитого muweb. Причем, создан - громко сказано, выглядело это "я слепила из того что было", даже хуже.
Потом "проект" был заброшен, но идея жила, а автор усиленно (когда не мешала лень) пытался выпрямить руки.
Потом появился  уже mwc, как оформившийся сайт с какими-то плюшками от 0.1 до 1.4, потом был 1.5 с шаблонзатором и говнокодом, но уровень хелоувордщика преодолен не был.
Потом было решено сделать 1.6, его можно считать попыткой ребетенка сделать первые щаги.
Сделал. Принцип его был "почти MVC": как таковой mvc используется только в недрах сайта, все остальное заточено под простое функциональное программирование с небольшими вкраплениями классов, так сказать, для простого хелоувордщика, да...
Так вот, так как некоторая основа используется в энтерпрайзе (для интрасети  и не совсем в виде системы управления проектами), я понял, что местами я уперся в потолок возможностей того "творения", что было запилено + постоянная халтурка с напилом модулей всем тем, кто в свое время обзавелся 1.6 двиглом:
сайты сами по себе несколько отличались: у одного было отличие в шаблонизаторе, у второго куча баз, у третьего еще что-то там...

Ну, в общем для тех, кто хоть раз занимался паттерном mvc сейчас уже ухмыляется: мол, да, ты описываешь преимущества как раз-таки обычного model-view-controller паттерна.

Так как я особо не парился в свое время с шаблонами программирования, то и использовал их не ахти как активно (даже сейчас считаю, что лучше недобдеть чем перебдеть, в данном случае, ибо если шаблоны использовать там, где они на фиг не нужны, то кроме захламления кода ничего хорошего не получится), то сел штудировать книги, статьи, код. Ну и, в конце концов, насмотревшись творений умных дядь типа yii и симфоний, я пришел к выводу, что, пожалуй,  стоит "убрать" ограничение "онли простой подход", и на свет в муках начала вырисовываться 1.6.2 (1.6.1 все тот же 1.6, только со своеобразным "сервис паком").

Концепция нового 1.6.2 будет примерно в следующем:
- есть основа с классами-родителями: контроллера, модели, ряда вспомогательных классов, сторонних библиотек
- есть билды (привет, bundle), унаследованные от данных родителей, со своими направлениями расширения.
Это автоматически помогает мне в 1 месте держать хоть все проекты кастумеров и допиливать их в нужном направлении, причем, при выявлении более удачного подхода для решения какой-либо задачи я могу путем изменения родителя запилить для всех проектов сразу очередной патчик (или для каждого в отдельности, если это не касается ядра), то есть по факту управление уровнем абстракции. Лично мне нравится такая идея :) Ваш Кэп.
- есть поддержка плагинов.
а куда без них? попробовав раз - торчу и сейчас.
- есть возможность писать и обычные функциональные скрипты как это было во всех предыдущих версиях. Это значит, что до сих пор, кому-то не нужно будет затачиваться на тему, как работает все это внутри и как писать свои контроллеры, модели и шаблоны. То есть, я не отказался от гибридного подхода, а все также его продвигаю. Стрелять по воробьям из такнка - это весело и даже иногда действенно, но требует затрат времени, которое, как обычно, еще вчера закончилось. Это, конечно, навалило ряд вопросов, как это все заставить работать... вроде как разрулил, на тестах посмотрим, был я прав или не очень.  Ваш Кэп.

Потом я подумал, что иметь конечно кастумеров - круто, но все-таки изначально, в саамом начале пути mwc, ставшего аж mwce была цель сделать лвиг для всех, а не только для тех, кто готов платить. Поэтому сам "движок" будет свободным и доступен для скачивания, возможно, сделаю репозиторий на том же гите, пока не решил. А вот билды уже буду писать или дорабатывать под конкретные нужды людей, будь то просто сайт-визитка или же muonline проект, а может даже ла проект, не знаю, время и востребованность очередного велосипеда покажет, нужно ли оно или нет.
Да и чего греха таить, хочешь найти ошибки и усовершенствовать то, что есть наиболее быстрым способом? Выложи в паблик! Ну "тыпонел" да? Ваш Кэп.

За сим пока откланиваюсь, ежели будет еще что интересного - отпишу.

P.S.:Если кому-то интересно, как организовывалась система управления проектами или как я доходил до понимания, что ж такое этот мэ вэ цэ, то пишите, напишу статейки еще.