Да, утверждаю что PHP это грааль.

[Polar]

А по факту заходишь в АОТ раздел таблицы, а там всего лишь один единственный класс с названием Таблица. И какое название ему в конструктор передашь - такой класс он тебе и создаст.
А еще вторым параметром ему передаешь коннект из какого сервера и какой базы тебе эта таблица нужна (т.е. совсем на другой сервер и на другую базу). И уже импорт/экспорт не нужен, а всегда актуальные данные. Можно одни таблицы держать на одном сервере БД, а другие на другом. А еще можно будет сделать, что одни таблицы в MySQL, другие в MSSQL, третьи на Oracle, а код пишешь как-будто все в одном.
В результате меньше кода, меньше ошибок, скорость больше, нагрузка меньше, больше эффекта за то же время.

[macklakov]

Цитата:

Сообщение от Polar

из какого сервера и какой базы тебе эта таблица нужна (т.е. совсем на другой сервер и на другую базу). И уже импорт/экспорт не нужен, а всегда актуальные данные..

Программистов что, совсем не учат теории надежности? Microsoft тоже эту подлянку себе регулярно устраивает.
Тут вот какое дело. С ростом количества вазаимозависимых компонентов, вероятность сбоя системы растет экспоненциально. Именно поэтому на многих производтсвах такое истеричное онтошение к качеству. Всякие Six Sigma вводят и прочее. Это происходит из-за того что иногда систему не получается упростить и приходится наращивать надежность каждого из компонент.
Но намеренно вводить в систему дополнительные зависимости, это значит гробить ее надежность прямо на старте. У вас одна из баз сбойнет и все остальное встанет. Или соединение с одной из баз сбойнет.

[gl00mie]

Цитата:

Сообщение от Polar

один единственный класс с названием Таблица. И какое название ему в конструктор передашь - такой класс он тебе и создаст. А еще вторым параметром ему передаешь коннект из какого сервера и какой базы тебе эта таблица нужна (т.е. совсем на другой сервер и на другую базу). И уже импорт/экспорт не нужен, а всегда актуальные данные. Можно одни таблицы держать на одном сервере БД, а другие на другом. А еще можно будет сделать, что одни таблицы в MySQL, другие в MSSQL, третьи на Oracle, а код пишешь как-будто все в одном.

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

[Polar]

Цитата:

Сообщение от macklakov

Программистов что, совсем не учат теории надежности? Microsoft тоже эту подлянку себе регулярно устраивает.
Тут вот какое дело. С ростом количества вазаимозависимых компонентов, вероятность сбоя системы растет экспоненциально. Именно поэтому на многих производтсвах такое истеричное онтошение к качеству. Всякие Six Sigma вводят и прочее. Это происходит из-за того что иногда систему не получается упростить и приходится наращивать надежность каждого из компонент.
Но намеренно вводить в систему дополнительные зависимости, это значит гробить ее надежность прямо на старте. У вас одна из баз сбойнет и все остальное встанет. Или соединение с одной из баз сбойнет.

Майкрософт тебе совсем мозг деформировала.
Есть два подхода в создании систем.
1. Если в процессе что-то пошло не так, то программа падает и запускается снова.
2. Если что-то пошло не так, то боремся до последнего за живучесть системы и только потом падаем.

Ты думаешь все системы написаны в стиле майкрософта? Всегда чуть что и синий экран?
Прикинь так бы атомные станции строили? Дверью в подсобке не так хлопнул, и БАДАБУМ! Потом ждем период распада и строим новую станцию. )))

[Polar]

Цитата:

Сообщение от gl00mie

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

Это называется некрофилия. На дворе 2017 год, а ты выкопал статью от 2000 года. Причем там обосран и TCP и SQL. Ты ими не пользуешься? Фельдегерями пакеты шлешь, а данные в тетрадочке собираешь?

[macklakov]

Цитата:

Сообщение от Polar

1. Если в процессе что-то пошло не так, то программа падает и запускается снова.
....
Прикинь так бы атомные станции строили?

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

[Polar]

Цитата:

Сообщение от macklakov

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

Ну правильно. А мне ужасы расписываешь.
" У вас одна из баз сбойнет и все остальное встанет. Или соединение с одной из баз сбойнет."

Это с фига ли у меня все остальное встанет? Я же не использую майкрософт, и компоненты сам пишу с нуля.

[ax_mct]

Цитата:

Сообщение от Polar

Майкрософт тебе совсем мозг деформировала.
Есть два подхода в создании систем.
1. Если в процессе что-то пошло не так, то программа падает и запускается снова.
...

Скорее всего имеется в виду модель работы PHP и того же Apache когда каждый запрос (GET/POST из браузера) изолирован и его падение не затрагивает сервер и другие запросы. Это особенность устойчивости PHP и соотносится с stateless природой web-протоколов.

А если речь о desktop приложениях и OS то мы лезем в дебри и вообще непонятно о чем говорим.

Цитата:

Сообщение от Polar

3-х звенную архитектуру знаешь? Что такое сервер приложений знаешь? Вот приложение это код на этом сервере.

Короче в терминах аксапты. Открываете АОТ в разделе таблицы, там структура таблиц описана. Закрываете. Перенастраиваете коннект на другую базу с совершенно другими таблицами. Открываете АОТ заходите в раздел таблицы, а там совершенно другие таблицы с другими полями и все уже описано за вас и ничего менять не надо.

Цитата:

Сообщение от Polar

А по факту заходишь в АОТ раздел таблицы, а там всего лишь один единственный класс с названием Таблица. И какое название ему в конструктор передашь - такой класс он тебе и создаст.
А еще вторым параметром ему передаешь коннект из какого сервера и какой базы тебе эта таблица нужна (т.е. совсем на другой сервер и на другую базу). И уже импорт/экспорт не нужен, а всегда актуальные данные. Можно одни таблицы держать на одном сервере БД, а другие на другом. А еще можно будет сделать, что одни таблицы в MySQL, другие в MSSQL, третьи на Oracle, а код пишешь как-будто все в одном.
В результате меньше кода, меньше ошибок, скорость больше, нагрузка меньше, больше эффекта за то же время.

Такие как бы динамичные Data Entity? Академически интересно, но практически:
- какие проблемы это решает?
- реальны ли эти проблемы?
- можно ли решить эти проблемы по другому?
- как данное усложнение помогает тебе реализовать твой бизнес-план?

Граальность PHP в стартаповости но с использованием популярных велосипедов.
Из Грааля надо пить, а не писать в него

[Polar]

Цитата:

Сообщение от ax_mct

Скорее всего имеется в виду модель работы PHP и того же Apache когда каждый запрос (GET/POST из браузера) изолирован и его падение не затрагивает сервер и другие запросы. Это особенность устойчивости PHP и соотносится с stateless природой web-протоколов.

А если речь о desktop приложениях и OS то мы лезем в дебри и вообще непонятно о чем говорим.

Вот именно! Похоже Маклаков вообще не в теме построения вебприложений.

Цитата:

Сообщение от ax_mct

Такие как бы динамичные Data Entity? Академически интересно, но практически:
- какие проблемы это решает?
- реальны ли эти проблемы?
- можно ли решить эти проблемы по другому?
- как данное усложнение помогает тебе реализовать твой бизнес-план?

Представляешь не надо мне теперь описывать структуру каждой таблицы в коде и изменения можно теперь делать только в базе данных а не поддерживать в актуальном состоянии все эти Data Entity. Какое же это усложнение? Я с себя кучу тупой работы скинул.

[ax_mct]

Цитата:

Сообщение от Polar

Вот именно! Похоже Маклаков вообще не в теме построения вебприложений.

Представляешь не надо мне теперь описывать структуру каждой таблицы в коде и изменения можно теперь делать только в базе данных а не поддерживать в актуальном состоянии все эти Data Entity. Какое же это усложнение? Я с себя кучу тупой работы скинул.

Не совсем понял как именно работает твое ORM (Object Relational Mapper),
но их много разных для PHP, неужели нет ни одного подходящего?

Я тупо не верю в разумность писать свой собственный ORM, если только не в учебных целях. Исхожу из того что если подобного в PHP не существует то этого и не нужно. Грааль он священен - из него надо пить то что в нем есть.

http://rohithegde.github.io/php-orm-comparison/
Doctrine (DataMapper pattern)
Propel (ActiveRecord pattern)
Redbean (DataMapper pattern)
Idiorm (ActiveRecord pattern but oriented towards Query Language)
Paris (ActiveRecord pattern & dependent on Idiorm)
Spot ORM (DataMapper pattern built on top of Doctrine DBAL)
Outlet (DataMapper pattern)
Xyster (DataMapper pattern)
Leap (Kohana FW)
Eloquent (Laravel FW)
MicroMVC
Gacela
NotORM

[ax_mct]

Цитата:

Сообщение от Polar

Представляешь не надо мне теперь описывать структуру каждой таблицы в коде и изменения можно теперь делать только в базе данных а не поддерживать в актуальном состоянии все эти Data Entity. Какое же это усложнение? Я с себя кучу тупой работы скинул.

То есть речь об автогенерации конкретного класса представляющего конкретную таблицу? Так достаточно других лентяев и соответственно созданных инструментов.
К примеру
Doctrine comes with a bunch of tools to help generate model classes from your existing database. http://symfony.com/doc/current/doctr...gineering.html

//-----
На предыдущие вопросы такие ответы?

- какие проблемы это решает?
Ответ: ускорение создания классов описывающих таблицы. Так?

- реальны ли эти проблемы?
Ответ: для некоторых программистов - да, для всех клиентов твоего бизнес-продукта - нет. Так?

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

- как данное усложнение помогает тебе реализовать твой бизнес-план?
Ответ: никак. Неоправданная трата времени на техническую реализацию ненужного.
Так?

А вообще правильное дело делаешь. Активная глупость бьет ленивый ум. Глупый умнеет, умный деградирует.

По архитектуре вот это забавно если с английским хорошо.
https://www.hakkalabs.co/articles/ro...ure-lost-years

Удачи!

[Polar]

Вот ты думаешь, что блажь на меня напала и я пишу самостоятельно от собственной глупости. Даже мыслишки у тебя не проскакивает, что я уже мог изучить уже написанное и придти к выводу что ничего из этого не подходит мне.
И как ты логически объясняешь появление новых инструментов в программировании? Ведь по твоим словам все уже написано и ничего нового по твоей логике уже не должно появляться, только глупцы будут чем-то заниматься и у них ничего не получится. А умные люди будут обходиться ислючительно тем, что уже написано.

[ax_mct]

Цитата:

Сообщение от Polar

Вот ты думаешь, что блажь на меня напала и я пишу самостоятельно от собственной глупости. Даже мыслишки у тебя не проскакивает, что я уже мог изучить уже написанное и придти к выводу что ничего из этого не подходит мне.
И как ты логически объясняешь появление новых инструментов в программировании? Ведь по твоим словам все уже написано и ничего нового по твоей логике уже не должно появляться, только глупцы будут чем-то заниматься и у них ничего не получится. А умные люди будут обходиться ислючительно тем, что уже написано.

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

Будучи сам исключительно тщеславным, я также не вижу в этом пути стать известным или прославиться. Новые инструменты в программировании не создаются задиристыми членами аксфорума

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

Цитата:

Сообщение от ax_mct

Тот же упомянутый Yii был создан Qiang Xue примерно за год, но в результате осмысления и переработки другого его фреймворка - PRADO, который он выпустил за 4 года до этого. То есть по сути время создания того же Yii - это многие годы.

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

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

Граальность PHP в том что ты садишься на что-то уже популярное.

[Polar]

ax_mct, Смотрел мультик где гриф учит страуса летать?
Найди и посмотри еще раз. Может себя там узнаешь.

P.S. Крылья Ноги и Хвосты называется.

[ax_mct]

Цитата:

Сообщение от Polar

ax_mct, Смотрел мультик где гриф учит страуса летать?
Найди и посмотри еще раз. Может себя там узнаешь.

P.S. Крылья Ноги и Хвосты называется.

И гриф, и страус - оба подходят.

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

Цитата:

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

[Polar]

ax_mct,
моя бизнес модель создать что-то, чтобы результат моего труда принадлежал мне, а потом продавать, то что я создал. Может это момент самоутверждения или вызов самому себе.
Но вот твоей бизнес-модели я вообще понять не могу.
Деньги платят только в двух случаях:
1. Что-то не могут сделать сами.
2. Не хотят делать сами.

Причем в первом случае платят больше, чем во втором.
Вот ты хочешь брать уже готовое и что дальше? Продавать это? Ты думаешь за что тебе будут платить?
Неужели никто другой не может также взять уже готовое решение?
Сразу себя ставишь в положение лишнего звена.
В аксапте вы зарабатываете только лишь потому, что Майкрософт не хочет работать с клиентами напрямую, а только через вас.
Но уже пора прикинуть будущее. Ваш "бобик" если еще не сдох, то уже чувствует себя не очень.
А опенсорс решения вы как будете продавать? Тут любой индус, китаец или Вася из деревни сертифицированный партнер.
Вот ты, ax_mct, ответь за что тебе деньги платить будут? За то что ты зае*атый парень и много умных слов знаешь?
Мне вот ты совсем не нужен, ты ленивый и балаболистый. А я и без тебя смогу деньги заработать, зачем мне с тобой делиться?

[gl00mie]

Цитата:

Сообщение от Polar

На дворе 2017 год, а ты выкопал статью от 2000 года.

Выходит, старые статьи плохи, и за 16 лет сложные абстракции перестали быть дырявыми?

Цитата:

Сообщение от Polar

Причем там обосран и TCP и SQL. Ты ими не пользуешься?

Тот же TCP там приведен в качестве примера сложной дырявой абстракции. Если отойти от статьи, то из моего скромного опыта поддержки и развития распределенных систем, любая связка со "сторонними" базами данных - это потенциальная проблема с производительностью/доступностью/надежностью/масштабируемостью. Можно долго и упорно настраивать индексы в "своей" базе, переписывать запросы и алгоритмы для снижения длительности блокировок, но потом какой-нить "умник" в сторонней базе забудет выставить уровень изоляции в READ_COMMITTED_SNAPSHOT, и твой код повиснет намертво при банальном чтении данных внутри транзации, а вместе с этим в твоей системе вырастет развесистое дерево блокировок и всё встанет колом.

PS. Хотя, конечно, в "песочнице" можно вообще, как 1С в свое время, использовать файловую БД и не париться - и так сойдет...

[Polar]

gl00mie, Ты бы себя послушал, как ты звучишь. Уже старперство какое-то.

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

[Raven Melancholic]

Polar, Вы серьезно считаете, что любой, кто не может понять причину и смысл написания Вашей "нетленки" ни в чем не разбирается?

[ax_mct]

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

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