Вообще, я считаю «верный путь в php» большой досадной ошибкой. Точнее некоторые его важные фундаментальные принципы. Писать код в глобальную область видимости и использовать eval() в коде нужно шире, как это делается в SKY framework. По крайней мере, дорогой читатель, я надеюсь, что вы допускаете разумность существования двух путей, а уж какой путь истинно верен, только время способно показать. Часто новое это хорошо забытое старое, прошу вас, не торопитесь думать, что «SKY way» это бесперспективное прошлое.
Простые вещи всегда имеют больший потенциал для развития, чем сложные. «SKY way» это наилучшая основа, дающая возможность реализовать идею проекта, в котором «сила сайта» была бы обусловлена кодом пользователей проекта, когда уровень развития сайта сопоставим с социальной сетью, но только где контент — код.
«SKY way» образует некоторые небольшие запросы к изменениям в php в текущий момент, например, хорошо бы было иметь функции: get_context($deep) и filter_context($array). Первая бы выдавала массив переменных соответствующих контексту уровня глубины, где $deep = 0 — свой контекст переменных, 1 — контекст уровня вызова функции, в которой находится код get_context(1). Возвращаемый массив — такой же, как и для callback функции для set_error_handler(). Вторая бы фильтровала массив, для вывода на экран программиста и анализа им переменных, при этом, например $GLOBALS, не должна быть показана в «чистом» виде, но лишь в сокращенном. «SKY way» не следует принципу изолирования, когда программист просто не использует глобальную область видимости для переменных, чтобы избежать нечаянного их переопределения в процессе разработки. Вместо этого, в «SKY way» имеются специальные средства, чтобы не допустить такие ошибки, в частности, например используя вышеуказанную функцию get_context(). Принцип изолирования и другие принципы, которые используются, например в Symfony и других популярных в данный момент Framework, приводят к слишком высокому уровню сложности архитектуры, в сравнении с «SKY way».
Второй пример. Чтобы избежать ошибок второго рода, классически, рекомендуется просто не использовать eval(). Но если аргументом для eval() есть код, находящийся в константе — нет абсолютно никакой опасности в использовании eval(). Однако, все равно, не рекомендуется использовать eval(), рекомендуется опасаться его «как огня». В «SKY way» такая логика считается ошибочной. Альтернативы для eval() нет. Наоборот, та альтернатива, которая используется в Symfony и Framework со сходной архитектурой, считается сомнительной, когда eval() не используются широко, так как, подобный путь слишком увеличивает сложность. Усложнять архитектуру кода для повторного использования (КПИ) на PHP, все равно, что, «пилить сук на котором сидишь». Но можно ли использовать eval() не опасаясь подвергнуть приложения риску? Можно. Можно, например, при использовании eval() выдавать ошибку PHP WARNING, когда достоверно неизвестно о безопасном использовании eval(), в остальных случаях не выдавать ошибку. Также можно, например, в Framework, сделать реестр использования eval(), чтобы привлечь внимание разработчиков к этим местам в коде или использовать комбинированный, гармоничный с самим PHP способ. Я подразумеваю, что реестр содержит текстовые описания гарантий безопасности. Кстати, можно представить ситуацию, когда начинающий программист не знает об опасности eval(), а наличие реестра, акцентирует его внимание и он благодаря этому избежит ошибок безопасности.
Также, как нет идеальных людей и идеальных программистов, нет идеального кода, для которого можно было бы привести точное доказательство, что код идеален. Но можно условно назвать идеальным код, который проанализирован огромным количеством программистов и активные итерации по совершенствованию которого, не прекращаются никогда. Такой подход предлагается в проекте SKY для достижения цели X, как и поиск всех других возможных путей для создания такого кода. Такой процесс непрекращающегося совершенствования, называется в проекте SKY «кристаллизацией». Понятие сходно с термином «оптимизация», но второй подразумевает волевое решение прекратить совершенствование на некотором этапе. Термин «кристаллизация» может стать актуальным на проекте SKY при условии достижения цели X.
В проекте SKY уделяется огромное внимание потенциальной частоте использования КПИ на реальных веб-приложениях. Так ядро SKY Framework (потенциально наиболее часто употребимый код), составляют всего лишь три файла, размером около 50 Kbytes и именно этот код должен быть подвержен максимальной кристаллизации сообществом. Гибкость кода, в том числе ядра, выбирается более низкой, в сравнении, например с гибкостью компонентов Symfony.
Ввиду ультимативного преследования принципов KISS, в SKY многие решения не типичны или даже противоположны тем, которые приняты сообществом, поддерживающим «верный путь в PHP»:
1) нет необходимости использовать (по крайней мере, как базовые средства разработки) технологии в Framework:
а) роутинг страниц, как механизм излишен. Реально нужные задачи, которые им решаются, легко реализовать простыми манипуляциями в коде приложения.
б) ORM как механизм излишен. Нет необходимости «делать обертку» для и без того лаконичного языка SQL.
в) Компилируемые шаблоны излишни. PHP сам по себе предоставляет достаточно средств, чтобы использовать PHP шаблоны с самым высоким качеством.
г) Механизм NAMESPACE излишен. Он решает задачу этапа разработки, на этапе выполнения, в том числе на production инсталляциях, что само по себе даже неверно логически.
д) и т. д. нет необходимости сейчас все вспоминать и перечислять…
2) В SKY уделяется гораздо большее внимание этапу разработки. В SKY все старается быть гармоничным, как окружающий мир. SKY Framework поставляется вместе с веб-приложением DEV.SKY, ориентированным на решение задач этапа разработки в гораздо большей мере, чем например, консольная утилита Symfony. Я бы сказал, что в SKY, «сапожник имеет сапоги».
3) нет папки vendor. Требуется переработка классов на packagist в соответствии с идеологией SKY. В SKY допускается (но, конечно, стараемся избегать) редактирование КПИ, в том числе ядра, разработчиками приложений. Во-первых есть стандартные средства для изменений кода ядра (с помощью приложения DEV.SKY) — получения из «чистого облака» кода «облачной модификации», это позволяет заменить высокий уровень гибкости компонентов Symfony, SKY-решением. «Чистое облако» это термин проекта SKY, характеризующий условно идеальный КПИ, потенциально способный стать полноценной заменой для не менее чем 70% сайтов реально существующих в Интернете. Во-вторых, обновления кода ядра, просто часто не требуется, ввиду того что он мал, прозрачен и кристаллизирован. В-третьих, обновления кода ядра, остаются возможными путем слития (ручного разрешения коллизий) и не представляют трудностей из-за того, что код мал и прост. Также обновления редки, ввиду того, что код кристаллизирован (идеален). В четвертых, стараться «уходить» от обновлений это скорее хорошо, чем плохо. Нельзя быть уверенным в постоянной благонадежности доверительных источников, нехорошо тратить личное время на обновления заведомо не идеального кода.
4) Вместо packagist, код третьего крыла, как и ядро SKY, хранится в БД кода, на том же сайте, в том же проекте SKY. Нет смысла собирать более 100К классов на PHP как на packagist, вместо этого, имеет смысл иметь гораздо меньшее кол-во классов на coresky.net, но подвергать код кристаллизации, постоянному совершенствованию. Не нужно иметь альтернативные решения на packagist, лучше иметь единые идеальные решения. В проекте SKY будет цениться умная мысль даже анонимного пользователя, с помощью пирамидальной системы рейтингов и бонусов. Любой участник системы будет способен легко влиять на любой код КПИ в SKY, если имеет ценные мысли.
5) и т. д. нет необходимости сейчас все вспоминать и перечислять…
На этом сайте, habrahabr, я иногда встречаю статьи подобные этой: PHP: фрактал плохого дизайна. Эта статья — интересная работа, но минус автору за то, что он не сделал анализ «железобетонного факта», не ответил на вопрос — почему язык PHP является ведущим в области веб разработки. Без такого анализа статья видится как «плач вопиющего..». Даже если автор написал эту статью без специального заказа от создателей конкурирующих языков, она имеет 100% рекламный (анти-рекламный) характер. Кстати, мое мнение: язык PHP похож на простой C/C++ с возможностями языка высокого уровня, именно этот факт, первую очередь, а не верная маркетинговая стратегия или что-либо иное, принесло ему, имеющуюся популярность. Важна также возможность расширения языка с помощью модулей «extension», написанных на C и удачное время начала разработки. Автор хвалит Perl, но Perl был раньше и проиграл в популярности, это факт. Подобно этой статье, предлагающей напрочь отказаться от PHP, я рассматриваю «верный путь в PHP», как подобный, но еще более тонкий маркетинговый ход, предлагающий напрочь отказаться от других подходов с целью использовать только этот. Мне видится, существующая в данный момент, к сожалению, большая «армия» профессионалов, поддерживающая «правильный путь в PHP» и небольшое количество профессионалов, чувствующих что в «правильном пути» что-то не так, к вторым, я отношу и себя. Первых я прошу не быть категоричными в убеждениях, позволить существовать «небесному пути», вторых я приглашаю на проект для более детального изучения того, что имеется уже сейчас в проекте SKY.
Еще я встречаю статьи подобные этой: PHP: неправильный путь. Имхо, это все — робкие попытки «армии меньшинства» сказать «правильный путь в PHP», на самом деле, не верен. В этой статье приводится фраза:
Но даже KISS может стать угрозой для проекта, если довести его до абсурда.
Мысль верная, но мне не нравится угол рассмотрения. Я бы сказал так: при совершенно определенной постановке задачи нужно всегда придерживаться принципов KISS. Просто, дело в том, что сделать безошибочную, совершенно определенную постановку задачи в области программирования бывает также трудно как и выполнить саму задачу. Выполняя задачу, разработчики часто принимают решения, которые могли бы присутствовать в постановке задачи и это было бы хорошо, как для того кто ставит задачу, так и для того кто ее выполняет. Использовать сложное решение, в то время, когда можно применить простое, равносильно выбрасыванию денег на ветер. В масштабе человечества, сложные решения вносят чрезвычайно большие потери разных ресурсов.
В заключении хочу отметить, что эта статья и проект SKY не только о создании веб-приложений на PHP. При достижении цели X, последствия будут невообразимы, это:
а) создание свободного идеального КПИ как для веб-разработки, но также и для другого программирования. Создание формального подхода для получения идеального кода не только для веб.
б) язык PHP не панацея, вероятна выработка сообществом идеального языка, возможно ответвления от PHP с возможностью конвертации старых скриптов. При достижении цели X, влияние проекта SKY на разработчиков PHP будет сильным. Важно не привязывание к конкретному языку, а поиск верных канонических связей и идеальных решений в программировании.
в) возможно создание контролируемого искусственного интеллекта, в отличие от недавно прозвучавшего в новостях DEEPMIND, который, несмотря на принятый «комитет по этике ИИ», вероятно работает по принципу «черный ящик» и вероятно представляет угрозу. Нельзя создать ИИ типа «черный ящик», чтобы он был безопасен. Хакеры знают как можно «взломать все», но если ИИ будет умнее людей, он также, обязательно вырвется на свободу. Эта проблема сродни проблеме CO2 в атмосфере и глобальному потеплению: все всё понимают, но продолжают ездить на бензине, также же и с ИИ: хочется сделать первый раз неважно какой, но реально работающий.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (269)
SerafimArts
28.10.2016 21:25+19> но нет ни одного, сила которого бы была обусловлена кодом пользователей
https://github.com/
pxz
28.10.2016 21:44+3Было очень тяжело читать. А автору стоит вспомнить о том, что PHP — это не только про сайты (сайты в том понимании, в котором они упоминаются в тексте статьи).
coresky
28.10.2016 21:46-3Что вы имеете ввиду? Консольные скрипты? Не понял вашу мысль, можно подробнее?
sayber
29.10.2016 01:39На PHP давно пишут полноценные программы не связанные с сайтами в обычном понятии.
К примеру из моего опыта — банковская, кассовая и транзакционная CRM, система бронирования клиент-брокер-отель, алгоритмы прокладки маршрутов между пунктами назначения по дорогам и много чего другого.coresky
29.10.2016 08:32М-да… А что такое CRM? Не веб ли приложение? Те приложения, которые ориентированны для работы в локальных сетях или на локалхосте даже, не имеюют ли часто demo в паблике? Я употребил слово «сайт» где-то, вместо «веб-приложения» и это вас ввело в конфуз? От чего же?
BanderasPRO
28.10.2016 21:46+20Статья напоминает дамп мозговой деятельности PHP програмиста в момент погружения в сон
voidMan
29.10.2016 06:39+2Фух, а я думал, что я один ещё не проснулся, чтобы понять смысл вышеизложенного…
kroshanin
28.10.2016 21:52Мне кажется, что ваш проект SKY еще в начале пути, во всяком случае вы позиционируете его как php-ядро для создания сайтов, а сам ваш сайт по уровню, честно говоря, слабоват (на мой взгляд).
Но сама идея у вас очень и очень интересная, поэтому спокойно относитесь к критике — у вашего проекта есть и достаточный потенциал, и хорошие перспективы.
OnYourLips
28.10.2016 21:59> Имхо, и php достиг высокой популярности, в первую очередь, благодаря простоте.
Этого не достаточно. Технология формируется не новичками, а теми, кто в ней закрепился.
Назовите альтернативную технологию, которая может конкурировать с PHP по охвату всех сфер веб-разработки, от решений на коленке, коробочных продуктов и стартапов до энтерпрайза.
Назовите технологию, в которой можно так же быстро создать первоначальный проект-прототип, но потом эволюционировать в стабильный проект на сотни человеколет.
Сила PHP в его мощной экосмистеме и свободе выбора. PHP очень умело балансирует между ruby с python и java с C#, попадая в обе ниши. Здесь вам и возможность написать страничку в пару строк, и сильная статическая типизация (тайпхинтинг), важная для крупных проектов.coresky
28.10.2016 22:09Я согласен — PHP богат, но он и прост как никакой другой
SerafimArts
29.10.2016 03:06+2Прост для обучения азам, но крайне сложен для понимания полностью. Я считаю себя довольно опытным, но до сих пор полностью не осознаю что конкретно делает метод `send()` у оператора `yield` и почему это заставляет конструкцию `$value = yield $key => $val;` пропускать один «тик» отдачи данных.
Может вы ответите, раз считаете себя переросшим большинство профессионалов, которые писали Right Way (оригинальный), пройдя все терни языка?coresky
29.10.2016 08:45-10Я не PHP сюда пришел преподавать, ваш вопрос — оффтоп, но отвечу так и быть: yeild не имеет ничего общего с тиками. Их логика совершенно не взаимосвязана. И если «пропускается тик» то это просто кандидат в «todo list» разработчикам PHP, это просто их недоработка. И в этом ничего сложного нет, если вы программируете на симфони и не понимаете этого, то мне жаль ваших заказчиков. Несмотря на неоспоримые достоинства языка PHP — посмотрите за занавес и прочтите статью PHP: фрактал плохого дизайна
KlimovDm
28.10.2016 22:13+4Чтобы попытаться понять статью зашел на сайт, изучил термины, изучил FAQ.
Принцип KISS как правило — хорош. Жаль, что вы его не исповедуйте в изложении материала. Вы наплодили столько новых лишних сущностей… Забыли о бритве Оккама? Жаль…coresky
28.10.2016 22:18-2Все термины нужны, а предостережение есть см. http://ru.coresky.net/roots?id33 Там написано:
Нужно стараться вносить как можно меньше новых терминов, чтобы читателю не приходилось искать их значения. Тем не менее…
symbix
29.10.2016 00:54+4А мне показалось, что все гармонично. И код, и статьи, ммммм, соответствуют нестандартному мышлению автора.
Mariik
28.10.2016 23:35+4нет необходимости использовать (по крайней мере, как базовые средства разработки) технологии в Framework
роутинг страниц, как механизм излишен.
ORM как механизм излишен
Компилируемые шаблоны излишни
Механизм NAMESPACE излишен.
Интересно, а вот скажем классы — они тоже излишни? Может тогда просто сразу вернемся к четвертому PHP? Там ведь ничего лишнего — 100% соответствие идеологии SKY. Да ну его все… К чему эти излишние всякие там паблики, статики, трэйты и интерфейсы. Только вносят путанницу.Ну правильно? Писали ведь на четвертом PHP и все было предельно ясно и просто. Ну полный SKY в общем.coresky
29.10.2016 00:00-5ООП — величайшее достижение в программировании. Практически весь код третьего крыла должен быть написан с использованием классов, так как логически неверно выполнять редко используемый код в процедурном стиле. В коде coresky (3 файла о которых я писал) также есть 4 класса. А вот запросы к БД лучше делать с помощью функции-обертки sql(), так как она чрезвычайно часто используется. А вот, когда фреймворк предлагает использовать метод класса для запросов к БД — это идеологическая прихоть, имеющая мало общего с объективной реальностью. Разработчики языка могли бы просто выделить имена, которые можно применять для функций фреймворк, с той целью, чтобы они никогда не пересеклись с новой версией языка. Это сделать им чрезвычайно просто. Просто задекларировать у себя на сайте.
VolCh
29.10.2016 11:34появление ORM прямое следствие популярности ООП и РСУБД. Это мост между ними.
coresky
29.10.2016 11:53Это круто… А практическая необходимость в чем?
Вот вы работали раньше без ORM и было ужасно плохо… можете объяснить в чем были сложности?
lair
29.10.2016 12:18+1Сложность в том, что надо писать весь этот избыточный SQL-код, помнить как названы объекты в БД, писать код, который преобразует обратно результат в тот, который нужен программе… И все это, конечно же, без поддержки компилятора.
Зачем, когда можно просто написать вот так:
var searchResult = _db.Books.Where(b => b.Author.BirthDate.Year < 1970).GroupBy(b => b.Author);
bm13kk
03.11.2016 16:08зануда мод: а в вашем коде надо помнить, что поле авторов у обьекта книга, называется
Author.
ИМХО
ламбды (безымянные функции, да и класы) не попадают под "сильную" типизацию. Если же их писать с типизацией — получается больше кода и теряется преимущество синтаксического сахара.
Либо надо создавать "супер сильную типизацию". Где компилятор (и ИДЕ) сможет по определению
function Where(f(b: Book): Boolean)проверить...Where(b => b.Year < 88)на валидность.lair
03.11.2016 16:11а в вашем коде надо помнить, что поле авторов у обьекта книга, называется Author.
Не надо. Автодополнение вполне работает.
ламбды (безымянные функции, да и класы) не попадают под "сильную" типизацию.
Почему не попадают-то? Код выше полностью типизированный.
Где компилятор (и ИДЕ) сможет по определению function
Where(f(b: Book): Boolean)проверить...Where(b => b.Year < 88)на валидность.Что значит "проверить на валидность"?
TheShock
03.11.2016 16:55Что значит «проверить на валидность»?
Вопрос становится неактуальным, когда понимаешь, что лямбда типизированнаяlair
03.11.2016 16:56Ну… мало ли, человек хочет, чтобы конструкция
Where(x => x > 99).Where(x => x < 99)не компилировалась или автоматически оптимизировалась в пустой итератор.
TheShock
03.11.2016 16:53зануда мод: а в вашем коде надо помнить, что поле авторов у обьекта книга, называется Author.
ламбды (безымянные функции, да и класы) не попадают под «сильную» типизацию. Если же их писать с типизацией — получается больше кода и теряется преимущество синтаксического сахара.
Рекомендую вам пописать на C# в хорошей IDE, мурашки по коже пойдут) Лямбды вполне типизируются и типы выводятся автоматически (это ведь довольно просто) так, как очень часто в Generic'ах.
Посмотрите на исходники Linq:
public static IEnumerable<TSource> Where<TSource>( // 1 this IEnumerable<TSource> source, // 2 Func<TSource, bool> predicate) // 3
Строка 3 означает, что лямбда обязана принимать на вход тип TSource (тот же, что в IEnumerable), а на выход давать bool. Так и типизируется.
VolCh
29.10.2016 13:39+2Изоляция объектной модели от способа хранения — это не необходимость, но это упрощает разработку, поддержку и развитие. Написать, что угодно можно в машинных кодах, но гораздо проще и дешевле писать с использованием более высокоуровневых средств.
Без ORM я работал когда толком и ООП не использовал. Как только начал использовать, то идея что гораздо лучше будет маппить записи БД на объекты модели и наоборот, чем продолжать работать на уровне бизнес-логики и представления с массивами, возвращаемыми mysql_fetch_assoc и(или) генерировать SQL на этих уровнях, возникла практически сразу — это упрощает отслеживание и управление взаимосвязями сущностей приложения. Теперь мне не надо думать о способе хранения данных, когда я реализую бизнес-логику или представление, у меня просто есть граф объектов, с которым я работаю. А когда работаю на уровне логики хранения мне не надо думать о том, как изменения в ней могут повлиять на остальной код, логика хранения на вход команд принимает граф объектов и на выходе запросов отдаёт граф объектов.
lair
29.10.2016 11:42… а какие парадигмы программирования, кроме ООП и процедурной, вы лично пробовали и знаете на уровне, достаточном, чтобы утверждать, что ООП — величайшее достижение?
coresky
29.10.2016 12:01-9При работе в проекте SKY, я пользуюсь беспрецендентной логикой, и глубоким пониманием того, что делаю. Большинство же из вас не понимает глубоко что делают, а просто следуют указанием «умных учителей». Прошу вас, не пишите глупостей, ставя (может быть и с сарказмом) под сомнение то, что ООП величайшее достижение. ООП должно применяться — там где должно, и не где попало… По этому поводу хорошо написано в статье: PHP: неправильный путь.
lair
29.10.2016 12:15+4Вот казалось бы, я вам задал простой и прямой вопрос. А вы, вместо того, чтобы на него ответить, от ответа уходите. "Беспрецендентная логика и глубокое понимание" — это не парадигма программирования.
И нет ничего глупого в том, чтобы поставить под сомнение громкое и ничем не обоснованное утверждение.
raveclassic
29.10.2016 13:16Величайшее достижение? А вы пробовали ФП?
(я, пожалуй, заострю внимание — именно функциональное, а не процедурное)coresky
29.10.2016 13:45-6вы меня простите, ваш вопрос оффтоп. Он далеко уходит за пределы темы статьи.
raveclassic
29.10.2016 13:58+2А в каком месте оффтоп-то? Вопрос относится не к статье, а к вашему смелому утверждению «ООП — величайшее достижение».
Это еще при том, что я закрыл глаза на заявление «Большинство же из вас не понимает глубоко что делают, а просто следуют указанием «умных учителей». », ибо не ведаете что творите.
TheShock
29.10.2016 13:58А вы пробовали ФП?
А вы? Без ооп и для чего-то крупного, с длительной поддержкой и реальными пользователями.raveclassic
29.10.2016 14:01Да, всю жизнь гонялся за ООП. А, в целом, и сейчас приходится. Но мне системы, написанные, ну например на том же OCaml или Haskell, кажутся гораздо более элегантными и лаконичными.
Сфера деятельности мне позволяет, например, использовать в работе Elm и Purescript, которые всецело опираются на Haskell. И код действительно становится проще и предсказуемей.
Хотя, к сожалению, резко повышается порог входа для поиска сотрудников.TheShock
29.10.2016 14:04Простите, я не понял ваш ответ. Спрошу еще раз. У вас есть продукт, который был написать исключительно на ФП, он достаточно крупный и не тривиальный, он развивался эволюционно (как большинство сложного софта сейчас), его использует или использовало множество пользователей (потому что писать для себя и для пользователей — разные вещи)? Если да, то дайте ссылочку, пожалуйста
seryh
29.10.2016 14:28В вашем комментарии сквозит намек на то что ФП менее удобен для больших проектов и масштабируемых систем. Непонятно откуда взялся этот стереотип, возможно из за JS к которому пока неуклюже пытаются придать функциональную парадигму некоторые фреймворки. Сами идеи ФП такие как неизменяемость состояний и чистые функции как раз и располагают к написанию более поддерживаемых больших и сложных систем. Как эти идеи представлены в конкретных языках, вопрос другой. Что касается вашего вопроса про массовый продукт реализованный исключительно с использованием ФП то как вам пример Riemann?
VolCh
29.10.2016 15:20В вашем комментарии сквозит намек на то что ФП менее удобен для больших проектов и масштабируемых систем.
По-моему, вы предвзяты. Скорее имелось в виду, что вы намекаете на необходимость попробовать ФП, сами не обладая опытом его применения в серьёзных проектах.
Как эти идеи представлены в конкретных языках, вопрос другой
Это первейший вопрос при выборе платформы для серёзной разработки.
TheShock
29.10.2016 15:30Опять отвечаете на какой-то другой вопрос.
Я вот просто много пообщался с командами, которые использовали ФП. И вот задаешь вопрос и обычно слышить ответ:
— да, все просто шикарно, мы уже полгода фигачим, все иммутабельно, декларативно, чисто как слеза девственности, да, пользователи еще не видели, да и QA только мельком, но все точно очень клево.
— да, мы вот написали очень клевую тулзу за пару дней (даже две, если считать ту, на которой тренировались), так клево, что на ооп так не напишешь, хипстеры на последней афтерпати просто писали кипятком
— да, пользователей запустили, пришло куча чейнджреквестов и багрепортов, но пофиксить не получается ибо пользователи — идиоты и не понимают нашу стройную архитектуру, иммутабельность и чистоту (ну или если честные с собой люди, то где-то здесь осознают свою ошибку, но уже ничего не поделаешь)
— ну а люди, которые ничего толком не писали крупного обычно кидают какую-то тулзу для программистов в пример — веб-сервер, сервер чата, сервис мониторинга, етс. Где на любой чейнджреквест, который не вписывается в «стройную чистую иммутабельную архитектуру ©®» можно просто забить, а любой баг, который вызван этой архитектурой задокументировать как фичу.
Почему у кого б из сторонников ФП я не спросил — ни у одного нету личного удачного опыта.
И да, я лично не писал функционально ни на чем кроме JS.
Мы вот писали игру, пять лет, три из них с десятками тысяч живых пользователей. И я представляю, что такое поддержка живого продукта годами.TheShock
29.10.2016 15:34Хочу еще раз акцентировать:
Я не программировал на ФП языках, а программирование в стиле ФП на JS убедило меня в том, что на JSв стиле ФП пишется неподдерживаемый код. И настолько медленный и текущий, что, например, для игр не подходит.
Но я так и не встретил ни одного человека, который бы писал что-то на ФП, что может сойти за опыт успешного применения ФП в коммерческой разработке. Где истории успеха?
У меня вот друг близкий любит на Ерланге в свое удовольствие писать. Говорит, что любимый и самый изящный язык. Но крупные вещи предпочитает писать на более классических — php или java зависимо от задачи.lair
29.10.2016 15:40Но я так и не встретил ни одного человека, который бы писал что-то на ФП, что может сойти за опыт успешного применения ФП в коммерческой разработке. Где истории успеха?
raacer
29.10.2016 15:45+4Он, наверное, хочет пообщаться лично с автором такого проекта, задать честные вопросы и услышать честные ответы. Так что проекты других людей не подходят, надо именно Ваш.
TheShock
29.10.2016 16:00+2Это вы участвовали в его написании? Да, я знаю, что есть крупные компании, часть сервиса которых написано на ФП языках (клиент для Win вот написан на C# на сколько я могу судить, а в статье врут, что «WhatsApp fully written in Erlang»), но я хочу личного общения, а не сухих рекламных буклетов. Почему на хабре нету людей, которые тут и там говорят: «да, я писал, да, клево».
Я хочу не просто почитать: «да, вон та компания говорит, что крута, держит много» (та в любом стиле можно так написать)
Хочу спросить: «и как вам спустя несколько лет? насколько легко возвращаться в старый код? легко ли найти человека в команду? если найдете — как он входит? а как пишете гуи? легко ли реагировать на все хотелки пользователей/заказчиков? Я вот столкнулся с тем, что не всегда в команду приходится брать синиоров. И не всегда необходимы именно синиоры. Как мидлы от ФП справляются в вашей команде?».
youlose
29.10.2016 16:25Backend игры World of Tanks написана на Erlang'e.
TheShock
29.10.2016 16:53+1Кто вам такое сказал? Там С++ и Питон
Игровые объекты BigWorld написаны на языке Python, стандартном объектно-ориентированном языке, позволяющем программистам в три раза эффективнее выполнять поставленные задачи. В случае возникновения необходимости оптимизировать работу регулярно используемых функций, скрипты могут использовать язык C++
youlose
29.10.2016 17:24Я смотрел конференцию по функциональному программированию, там их тимлид рассказывал о обсчёте игровой карты и расчёте областей видимости танков. Эта задача у них выполнена на эрланге, к сожалению это видео найти не смог за 5 минут, но то что у них используется erlang это не секрет.
С вами всё же соглашусь в том что не весь бэкенд, но какая-то часть со сложными задачами — точно.TheShock
29.10.2016 17:34+1Да, у нас в Варгейминге даже в Киеве были вакансии на Ерланг, я туда друга рекомендовал. Чтобы вы понимали — это неимоверно крупная контора, где есть огромное количество сервисов от самых маленьких до довольно крупных и самых разных языков. Более того, на некоторых направлениях эксперименты вполне поощряются, а для уменьшения усталости поощряются довольно экстремальные. Но это еще не значит ничего.
У нас вот в проекте для билда Gulp использовался. И вполне мы могли б на конференции какой-нибудь рассказать. Только это отвратительная, неюзабельная штука, куда нельзя послать мидла без бутылки. Не удивительно, что он так быстро умер. И вот вы уже можете сказать, что «В Варгейминге используется Gulp на продакшене», вот только комментарии о нем у нас нелестные.
seryh
29.10.2016 16:29Я специально в своем комментарии в защиту ФП упомянул JS, это очень распространенный опыт, обжечься на нем и ругать ФП. Сам писал бэкенд на Node.js с лямбдами и думал что пишу ФП, это был очень неудачный опыт. Но этот опыт говорит только о том что в JS очень неудачная реализация для ФП и не более. Примеры больших ФП проектов вам привели, это намекает что парадигма жизнеспособна. Почему в целом и в Российском IT сегменте такие большие проекты сложно найти? Думаю ответ очевиден, для большого проекта нужно собрать в одну команду несколько специалистов со знанием ФП языка, что ввиду невысокой распространенности проблематично, так же немаловажный аспект — бизнес не будет вкладывать деньги в непроверенную годами технологию. Повод ли это хоронить ФП? Не думаю.
TheShock
29.10.2016 16:55Так я сейчас и не спрашиваю про свой опыт, а про чужой.
Писать ФП на JS — мазохизм, тут без сомнений. Но вот на хабре много советуют ФП. Неужели никто из советчиков не может на своем опыте сказать, чем он хорош на практике?S_A
29.10.2016 17:48Я в ряды советчиков не напрашиваюсь, но пару мыслей из практики (F#) скажу. Дозированно смешиваю (но не взбалтываю) с С#. Хороший коктейль, когда в F# только алгоритмы. Они реально меньше, например генетический алгоритм у меня в три раза меньше (не меньше) вышел.
Но ввиду своей лаконичности, F# достаточно труден и в отладке и в чтении, и в чем-то даже в написании. Но от «вау»-эффекта по первости сложно отделаться, как программировать заново научился :) Какой-нибудь энтерпрайз на функциональщине полностью точно писать не стану. Выигрыш от количества кода полагаю будет потерян, и по времени выигрыша тоже не думаю что будет много (если учитывать отладку).
raveclassic
29.10.2016 18:08Прочитав ветку, уловил суть вопроса
А вы? Без ооп и для чего-то крупного, с длительной поддержкой и реальными пользователями.
В таком случае ответ нет, но не потому что ФП не годится для промышленной разработки, а потому что компания не может себе позволить писать в ФП из-за высоких рисков не найти разработчиков. Т.е. это никак не относится к самой парадигме.
Писать ФП на JS — мазохизм, тут без сомнений
Я не программировал на ФП языках, а программирование в стиле ФП на JS убедило меня в том, что на JSв стиле ФП пишется неподдерживаемый код
Полностью с вами согласен тут, JS ужасен в этой парадигме.
Неужели никто из советчиков не может на своем опыте сказать, чем он хорош на практике
Позволю себе описать некоторые плюсы опираясь на свой опыт с elm и ps:
- Полное отсутствие рантайм-ошибок
- Хорошая тестируемость и предсказуемость кода из-за отсутствия сайд-эффектов
- Иммутабельность из коробки и как следствие time-travelling отладка, hot-reloading и прочие фишки. Ну и, опять же, предсказуемость кода
Наверное стоит уточнить, что ФП скорей всего не подходит для высокопроизводительных приложений. Хотя, тот же OCaml позволяет писать в смешанном стиле с изменяемыми значения в местах, где требуется производительность.
Но есть и минусы:
- Иногода может понадобиться сильно сломать голову, чтобы решить тривиальную задачу
- Производительность в целом ниже (я про elm и ps, OCaml местами обгоняет C++, ну или обгонял раньше)
- Необходимость крайне высокого уровня самодисциплины и, как следствие, риски при поиске разработчиков
Подводя итоги: мой совет про ФП был не про реальную коммерческую разработку а в противовес идее, что «ООП — лучшее, что придумало человечество».TheShock
29.10.2016 20:35«ООП — лучшее, что придумало человечество».
Ну как мне кажется, на данный момент так оно и есть (и, конечно, не в той извращенной форме, какой его видит автор). Как минимум в плане парадигм программирования. ФП — оно хорошо для определенных задач, но не так универсально, ведь решает именно определенные задачи. И игру, или графический редактор не будешь писать на ФП, в то время как серверы, чаты прекрасно пишуться на ООП или даже процедурно. Тем более, что чистота и иммутабельность — не привилегия ФП и современные ООП языки поддерживают ФП на достаточном уровне чтобы использовать его там, где он нужен и только там.
В таком случае ответ нет, но не потому что ФП не годится для промышленной разработки
А вы считаете, что годится? Ну вот я менеджер в каком-то крупном городе, куда могу схантить разработчиков. Или даже, допустим, ФП стало популярным, как это стараются сейчас всюду всунуть. И теперь у нас рынок заполонили мидлы и джуны и даже можно задорого купить синиора. И что, как на счет ответов на остальные вопросы? Можно ли будет этот код поддерживать через 3 года активных change-request? Легко ли сможете вы вставить что-либо противоречащее архитектуре? Где состояние прописано прям в бизнес-логике. Как на счет написания гуи? А если гуи игры (допустим, казуалки, где производительность должно хватить). Или какой-либо интерактивный и анимируемый. Плавные изменения значений как результат анимаций, а не мгновенная перерисовка после приказа от сервера.
Ну вот вы бы взялись написать аналог гимпа, казуальную игру, видеоредактор етс при помощи ФП? А если бы вы знали, что вам его 3 года поддерживать и вносить любые правки, то выбрали бы ФП или ООП?
Полное отсутствие рантайм-ошибок
Разве это не особенность всех статически-типизированных языков? Намного страшнее ошибки логики.coresky
29.10.2016 21:06-1Я писал «ООП величайшее достижение в программировании» а не лучшее что придумало человечество. Как однако у вас восприятие «летает»… И ООП в извращенной форме применяется в современных трендовых фреймворк, значительно неоправданно увеличивая сложность. Нужно его применять там где нужно, а не где попало…
raacer
29.10.2016 21:41+2Я писал «ООП величайшее достижение в программировании» а не лучшее что придумало человечество. Как однако у вас восприятие «летает»…
Это у Вас русский язык летает, Вы так излагаете мысли, что Вас никто не понимает. «Величайшее» — это превосходная степень прилагательного — высшая степень проявления признака. Другими словами — самый великий. Выше уже некуда.
Нужно его применять там где нужно, а не где попало…
Представьте пожалуйста объективные критерии оценки, где нужно применять ООП. Сразу напоминаю, что ваш «здравый смысл» не является объективным, не говоря уже о том, что мало кому здесь он кажется здравым.coresky
29.10.2016 22:02-1Превосходно…
>объясните… только это заведомо не здраво…
зачем тогда просите писать? Это здравая последовательная логика?raacer
29.10.2016 22:08+1Объясняю. Здравый смысл — это субъективный взгляд, ощущение правильности. Поэтому здравый смысл — это не объективные факты, а нам интересны именно факты, которые в итоге можно измерить человеко-часами, доходом и т.д.
Более того, если верить «Вики», здравый смысл — это тот взгляд, который разделяется большинством людей. Ваш взгляд не разделяет почти никто из читателей, так что он вряд ли может претендовать на данный титул.
Если Вы посмотрите внимательно, то увидите, что я прошу Вас представить объективные критерии оценки, а не субъективное мнение.
raacer
29.10.2016 22:11+1Если же вы хотите выбирать, где нужно использовать ООП, руководствуясь здравым смыслом, то прислушайтесь к нему. То, что Вам все пишут — это и есть здравый смысл.
https://ru.wikipedia.org/wiki/Здравый_смысл
raacer
29.10.2016 22:15Кстати, тут не так давно в какой-то статье обсуждали ООП vs ФП. Оказалось, создатель ООП вообще считает, то его неправильно поняли, что ООП никак не мешает ФП, а очень хорошо с ним сочетается, и что императивщики сильно извратили идею. В общем, ООП — это совсем не то, что хотел предложить автор данной концепции. От него осталось только название.
seryh
29.10.2016 21:22Все ваши вопросы, можно смело адресовать и к ООП. Их решения напрямую зависит от квалификации разработчика закладывающих архитектуру на старте проекта, ФП или ООП тут имеют мало значения как таковые. Особенно с учетом того что почти все языки гибридные, могу ошибаться но только Haskell можно назвать чистым ФП языком, остальные функциональные языки могут работать с мутабельными состояниями, что позволяет там где нужно писать императивно, а уже большую часть функционально. Помимо того, ошибки проектирования с использованием ФП нормальная практика для только набирающей популярность методологии, паттерны проектирования ООП тоже не за один год придумались. Для ФП есть и еще будут свои паттерны.
Отвечая на тезис «ООП — лучшее, что придумало человечество», лично для меня определенно нет, по простой причине. ООП для меня это рутинный кактус который нужно есть, а ФП это тот код, при написании которого я могу отдохнуть.coresky
29.10.2016 21:29ООП величайшее достижение в программировании
Лучшее, что придумало человечество это пиво )
VolCh
30.10.2016 12:43+1для только набирающей популярность методологии
ФП зародилось практически одновременно с процедурным ИП: Лисп и Фортран — ровесники. Первый ООП язык (Smalltalk) появился гораздо-гораздо позже, в 1980-м релизнулся. А Лиспу скоро будет 60 лет, причём мёртвым языком он никогда не был, на нём писали и пишут постоянно. Напрашивается вывод, что что-то с ФП не так, раз оно 60 лет только набирает популярность и паттерны проектирования для него придумываются. Может для отдыха оно и годится, но бизнес и власть в его промышленной эксплуатации выгоды не видит, как правило, если и использует то в каких-то весьма ограниченных областях.raacer
30.10.2016 13:01+1Я помню, еще в школе на математике далеко не все понимали, как строить график функции. Зато выполнять последовательность указаний и отдавать их другим — это элементарный навык, который все получают еще в детстве. Возможно, по этой причине императивное программирование проще декларативного, а декларативное вообще мало кому дается для понимания. За функциональным программированием стоит целый раздел дискретной математики. Сколько у Вас в классе было отличников по математике? Если функциональщиков — десять человек на всю страну, то мало кто рискнет затевать серьезный проект в функциональном стиле.
VolCh
30.10.2016 13:47+2Зато выполнять последовательность указаний и отдавать их другим
Практика показывает, что даже программисты не всегда этим владеют в достаточной степени:
Жена посылает программиста в магазин:
— Дорогой, купи, пожалуйста, палку колбасы, и если будут яйца, то купи десяток.
Через полчаса программист возвращается с десятью палками колбасы.
Жена:
— Что это?! Зачем ты купил столько колбасы?
Программист:
— Ну так яйца-то были…
:)
А если серьёзно, то в случае если ФП действительно не соответствует человеческому мышлению в целом (не важно, врожденному или приобретенному), то область его применения крайне ограничена просто из-за малого числа альтернативно мыслящих людей.
С другой стороны, среди программистов не встречал особых трудностей с освоением азов ФП, когда какой-то кусок программы требуется написать в функциональном стиле, храня его (куска) состояние в стеке вызовов. Трудности возникают когда нужно написать всё приложение, активно взаимодействущее с внешним миром, в таком стиле. Так что я больше бы поставил на то, что ФП мало подходит для решения подавляющего большинства практических задач, чем на то, что требуется какое-то особое мышление, которое очень трудно приобрести. В конце-концов, доминирующие аппаратные архитектуры (Тьюринг-подобные машины) оперируют прежде всего набором инструкций, изменяющих состояние, а функциональные языки лишь предоставляют декларативную абстракцию над императивной машиной, что бесплатно не даётся, а в человеческом мышлении скорее первична декларативная составляющая, чем императивная. Задача обычно ставится декларативно (заметно при общении с бизнесом, далеким от ИТ или с детьми), а вот уже решение переводится в императивную форму, если нет уверенности, что исполнитель правильно поймёт декларативную. В какой-то мере работа современного программиста в принципе состоит из перевода декларативных слабоформализованных задач заказчика в императивные команды тьюринг-машины. И почему-то многие программисты избегают варианта полной формализации в декларативной форме с автоматическим переводом в императивную.raacer
30.10.2016 13:59Почему-то… Но вот почему — непонятно. Пока только сложность восприятия кажется мне надежным аргументом.
Трудности возникают когда нужно написать всё приложение, активно взаимодействущее с внешним миром, в таком стиле.
Как на счет Phoenix? Люди уже целый фреймвёрк сотворили.
Какие именно трудности возникают? Это факт или предположение? Если факт, то можно ли описать подробнее прецеденты и суть возникших проблем?VolCh
30.10.2016 14:52Сложно сказать, по-моему, именно сложность предмета самого по себе или, скажем, необходимость ломать привычки. И определённо эмуляция декларативного исполнителя императивным не бесплатна. Остаётся только надеяться, что транслятор языка будет, например, разворачивать хвостовую рекурсию в циклы (в популярных движках JS, например ещё не реализовано, хотя и определено стандартом ES2015), будет мутировать состояние уже имеющихся экземпляров структур данных вместо почти полного глубокого копирования и удалением оригинала и прочие оптимизации применять. В идеале ещё и наличие в библиотеке функций с императивной реализацией (инкапсулированной, конечно) в тех случаях, когда она заметно эффективней функциональной.
Я бы назвал общепринятым мнением, что ФП усложняет работу с мутируемым состоянием, сайд-эффектами (включая ввод/вывод) и т. п., без которых сложно обойтись (или это будет очень накладно по вычресурсам) при решении подавляющего большинства практических задач. Мой личный опыт в виде попыток создавать простейшие CRUD веб-приложения с хранением данных в РСУБД на Лиспе и Хаскеле это подтверждает. И, кстати, сложилось впечатление, что мутации внедрены в эти языки именно таким образом, чтобы облегчить работу транслятору, а не разработчику. Я очень надеюсь, что обошлось без сознательного усложнения работы с мутациями с тем чтобы разработчики прибегали к ним только когда без этого реально не обойтись, а не мешали функциональный и императивный подход руководствуясь локальной простотой начальной реализации, как это часто встречается в мэйнстримовых языках (прежде всего Си-подобных), к которым некоторые функциональные возможности были прикручены позже и транслятор не следит за чистотой функций.raacer
30.10.2016 15:42Тогда, возможно, Вам для полноты картины стоит посмотреть на Elixir. Там работа с состояниями обернута довольно изящно.
raveclassic
30.10.2016 16:00Тогда, возможно, Вам для полноты картины стоит посмотреть на Elixir.
Боюсь, что erlang/elixir это как раз больше про оригинальное ООП, нежели ФП. Объекты есть (процессы), общение через сообщения есть (позднее связывание), все как завещали, только приправленное некоторыми функциональными фишками.raacer
30.10.2016 16:06Ну так ведь и ФП же там в чистом виде.
raveclassic
30.10.2016 16:14От ФП там иммутабельность и паттерн-матчинг, когда ни типизации, ни алгебраических типов данных (хотя, это частично решается атомами в кортежах), ни, уж тем более, теории категорий, к сожалению нет. Так было бы совсем круто. Кстати, кажется, если мне память не изменяет, кто-то даже пробовал спортировать OTP на haskell.
0x9d8e
31.10.2016 13:03+1Недавно мне поставили задачу в императивном стиле. В смысле текст задачи был как-бы псевдокодом на русском языке. В итоге я так и не смог понять что нужно сделать т.к. не смог понять, что должно получиться. А мои навыки как раз и заточены на генерацию решений «как сделать чтобы получилось как описано». Пришлось идти и устно расспрашивать, что и зачем должно быть на выходе. Да и в личной жизни слова девушки вида "(не/с)делай то-то и то-то" меня совсем не берут, нужно описать что должно получиться и зачем, только после этого можно давать подробности по «деталям реализации».
raacer
29.10.2016 21:33ФП — оно хорошо для определенных задач, но не так универсально, ведь решает именно определенные задачи. И игру, или графический редактор не будешь писать на ФП
Отсутствие доказательства того, что ФП лучше, не является доказательством того, что ФП хуже. То, что мало специалистов по ФП, тоже не говорит о том, что он хуже. Например, я считаю, что PHP хуже, чем Python или Ruby, по многим объективным критериям, но количество разработчиков на PHP как бы «доказывает», что PHP — лучший язык. Также, как количество курильщиков может доказывать, что курить — это хорошо. Здесь нет логики, выбор большинства не может быть объективным критерием оценки.TheShock
30.10.2016 09:51Ну ты прям меня обижаешь, я могу в базовую логику. Конечно, количество не обязательно означает качество.
«ФП — оно хорошо для определенных задач» — вывод сделанный не из-за количества последователей.
Тем не менее полное отсутствие свидетельствует уже о чем-то. Например…
Слышали про "Чайник Рассела"? Так вот. Сейчас ФПисты похожи на религиозных фанатиков. Да, никто не видел (лично) успешных проектов на ФП, только где-то в библии сказано, да, никто не может назвать игру или 3д-редактор на ФП, кто-то даже слышал голос бога и после химиотерапии его родственник чудесным образом исцелился. Никто не может точно наверняка сказать, что ФП работает, но все верят и стараются затянуть в эту веру окружающих.
И я не удивляюсь, что люди, которые писали маленькие или подходящие вещи действительно так считают, ибо… прототипы всегда писать намного веселее в абсолютно любом стиле. Я вот писал прототип видео-редактора на WebGL на жесткой смеси процедурщины, ооп, фп, быдлокода и какой-то матери. Писать мне было весело и легко, оно клево работало и фичи добавлялись быстро. Но это совершенно не значит, что я считаю такой подход приемлимым для реально разработки.raacer
30.10.2016 11:08Есть свидетельства в виде сторонних проектов. Но на Хабре никто не делится ни положительным, ни отрицательным опытом. О чем это говорит? Мне — только о том, что никто из хаброюзеров не использовал ФП в своих больших проектах. Доказывает ли это, что ФП не годится? Нет, совершенно. Это доказывает лишь то, что ни у кого нет данного опыта.
TheShock
30.10.2016 11:17Тем не менее, почему-то, многие стараются убедить, что это очень круто и надо в него обязательно верить. Почему?
raacer
30.10.2016 11:34Не знаю. Просто не следуйте их примеру и не пытайтесь безосновательно убедить, что это не круто. Пусть кто-то поверит и попробует, это же интересно! ;)
Я тут на коленке начал небольшой проект по сравнению парадигм. Надеюсь что-то прояснить для себя. Если получу какой-то стоящий результат — обязательно поделюсь этим на Хабре.TheShock
30.10.2016 11:41А потом нельзя работу будет найти, где не отказались бы от нормальных практик в пользу новой моды? ;) Люди ж читают всё это и думают — оно ведь реально так клево. А критически мыслить — сложно, что никто на практике это реально еще не использовал и методик пока не изобретено.
raacer
30.10.2016 11:51Так надо же проверить, чтобы критически мыслить. А пока в основном только теоретически рассуждения и анализ чужого опыта.
VolCh
30.10.2016 12:45+1Мне — только о том, что никто из хаброюзеров не использовал ФП в своих больших проектах.
Или не хотят признаваться в ошибках.raacer
30.10.2016 13:04Да ладно! Не обязательно признаваться в ошибках и вспоминать о том, что был евангелистом ФП. Зато обвинить парадигму в своих неудачах — это святое дело! Уверен, был бы повод — все тут рассказывали бы истории, как ФП подвело их на важном проекте.
raveclassic
30.10.2016 15:30+1Можно ли будет этот код поддерживать через 3 года активных change-request?
Да, поддержка через 3 года функционального кода настолько же сложна, насколько сложна поддержка ООП через те же 3 года. Вот только накосячить с ООП гораздо проще.
Легко ли сможете вы вставить что-либо противоречащее архитектуре?
Ну не сказал бы, что легко, но и не сложнее, чем с ООП. Более того, в случае ООП нужно отдавать отчет, что все вставленные костыли рано или поздно вернутся головной болью. ФП же сужает круг мест, где эти костыли можно расставить.
Как на счет написания гуи?
Вот как раз ФП тут больше подходит. Взять тот же реакт: ui — чистая функция от состояния.
А если гуи игры
Почему нет? Хотя опыта в этой области у меня нет. Ну, и перфоманс видимо просядет.
Плавные изменения значений как результат анимаций, а не мгновенная перерисовка после приказа от сервера.
На самом деле, все это возможно. ФП ничем не отличается в плане возможности наличия сложного состояния процесса (например, анимации). Просто обработка этого состояния по-другому происходит.
Ну вот вы бы взялись написать аналог гимпа, казуальную игру, видеоредактор етс при помощи ФП? А если бы вы знали, что вам его 3 года поддерживать и вносить любые правки, то выбрали бы ФП или ООП?
Ну, я не могу похвастаться таким опытом в ФП, чтобы сесть и написать гимп. Но, тем не менее, это опять таки не значит, что ФП не годится для этих вещей. На ФП прекрасно пишутся огромные сложные вещи, взять ту же MirageOS на OCaml.
Разве это не особенность всех статически-типизированных языков?
В том то и дело, что нет. Статическая типизация лишь обеспечивает проверку типов, но не обработку тех же исключений. Вот зареджектится ваш промис, а вы это не обработали — пожалуйста, рантайм ошибка. В случае же с тем же Elm (ну, раз уж за фронтенд), там просто не существует этих исключений. Все возможные сайд-эффекты обрабатываются как данные.
pda0
29.10.2016 00:21+3Поскольку большинство, включая текущих разработчиков php, eval не считают полезной вещью, а так же по ряду очевидных объективных причин eval имеет проблемы:
- Низкая скорость из-за парсинга и компиляции в момент вызова функции;
- Не используется кэш байткода;
- Ограничен доступ к локальным переменным и пространствам имён;
- Не поддерживается компиляторами, типа HipHop;
- Не понятно что там с обработкой ошибок, возникших внутри eval-кода.
coresky
29.10.2016 00:40-2Насчет пространств имен — я писал…
Глобальные переменные доступны через инструкцию global, вы говорите о недостатках SKY Framework или о другом? В SKY Framework (текущем) eval имеет доступ ко всему что нужно.
Ваши пункты 1,2,4 — это один пункт. Замечание впросак, не готов дать ответ. Плюс нужно сравнить быстродействие готовых эквивалентных приложений. За счет того что в Symfony не используется eval, а КПИ имеет известную тяжелую архитектуру, я не думаю, что будет выигрыш в производительности.
Ошибки нормально, как обычно обрабатываются. С этим нет проблем.pda0
29.10.2016 23:52+1Понимаете, проблема не в том, какое применение вы нашли eval, а в том, что эту функцию фвно не любят текущие разработчики языка. И если учесть, что сейчас она в основном используется вредоносным кодом, то я не удивлюсь, если в следующей мажорной версии её просто выкинут.
Это здорово искать новые пути разработки, но опираться на функциональность, живущую на птичьих правах немного опасно.
AlexTest
29.10.2016 00:47+1А дебажить PHP код изобилующий eval — это ад кромешный!
coresky
29.10.2016 00:52-2нет самоцели применять много eval, но он иногда сильно упрощает вид кода, вплоть до тривиально простого вида. Вы используете eval, если знакомы с проблемой?
AlexTest
29.10.2016 01:10+3Я рефакторил легаси код с кучей eval и знаком с проблемой не понаслышке!
Даже если в коде будет всего один eval, использующийся для выполнения различных кусков кода из БД и прочих источников данных, недоступных для анализатора IDE — это уже «ад» для того, кто будет с этим кодом работать после автора.
Все ваши проблемы можно решить с помощью уже давно реализованных в PHP замыканий! Но при этом разобраться с кодом стороннему разработчику в своей IDE будет в разы проще, и исчезнут проблемы с которых началась эта ветка.coresky
29.10.2016 01:18-4вы не поняли, почему я использую eval. Анонимные функции я так же использую, это совсем другое. Если вы у меня в коде увидели create_funcion() и не поняли почему там не используется замыкание, то ответ прост — это непринципиально. Если вы программист PHP скачайте код из видео на главной, посмотрите немного внимательней код
AlexTest
29.10.2016 01:24+1ответ прост — это непринципиально
Если для вас непринципиальны мои доводы и pda0,
то дальше объяснять вам недостатки eval — бессмысленно!coresky
29.10.2016 01:27-1Вы читаете мое сообщение, прежде чем написать комментарий? ) Я сравнивал функцию create_funcion() и Closure. А Closure не может заменить eval.
TimsTims
29.10.2016 00:39+3Господа, будьте добры, кто-нибудь в одном предложении скажите, о чем тут пытался сказать автор?
> Идею проекта SKY можно излагать по разному, но самое короткое и простое изложение следующее:
В итоге получилось на полэкрана некороткого и непростого изложения, не раскрывающего сути.
> Так сайт packagist сопоставим с проектом SKY, достигшем цели X
Увы, не сталкивался с проектом packagist.
> нет ни одного, сила которого бы была обусловлена кодом пользователей
github.com
И всякие сайты-песочницы кода, вроде jsfiddle.net, нет? Сайт помогает эмулировать код, а без этого кода «силы» нет. Сюда-же можно добавить великий Stackoverflow — уберите из него все коды пользователей, и какая будет у этого сайта «сила»? Если засчитываем Stackoverflow, то считаем и миллионы форумов, где люди в топиках задают вопросы по программированию, и им отвечают предоставляя код (начиная от програмирования контроллеров и веб-страниц, заканчивая монстрами биг-даты).
> В данный момент проект SKY мало известен
Хоть 1 слово про проект то! ни слова о том, что же за проект, в конце то концов. Куча воды. После первого громадного абзаца так и не понятен проект. А второй абзац начинается вообще с мемуаров:
> Вообще, я считаю «верный путь в php» большой досадной ошибкой…coresky
29.10.2016 00:49>github.com
нет. я писал о идеальном коде разрабатываемом коллективно.
Fedcomp
29.10.2016 07:19А почему гитхаб то под это определение не подходит?
coresky
29.10.2016 08:51-1А где вы там видите коллективную разработку кода, в том смысле, который упоминается в статье? У вас есть идеальный framework, над мельчайшими деталями которого потрудилось множество людей? Жаль, что никто не понял материал статьи, я честно старался быть максимально лаконичным. Посмотрите результаты голосования в этой статье — довольно много людей хотят что-то исправить в framework с которыми работают. Если бы существовал сайт достигший цели X, таких людей бы не было. Они либо прояснили свое понимание вещей, либо их идея была использована для совершенствования framework.
VolCh
29.10.2016 12:16+4Не может быть одного фреймворка, удовлетворяющего всех. Даже если пишешь сам всё с нуля в рамках одного проекта приходится идти на компромиссы.
coresky
29.10.2016 12:24-2Если фреймворк «закрутить» сложно, как есть, то да — бредовые мысли могут не совпасть, так как ход мыслей у людей разный. А если сделано просто, то может один удовлетворить всех.
VolCh
29.10.2016 13:45+4Не может. Есть вечные компромиссы, на которые часто приходится идти разработчикам, например, читаемость против потребления ресурсов, надежность против потребления ресурсов и читаемости, Более того, даже под читаемостью каждый понимает своё. А в одних задачах в требование надежности входит атомарность изменений, или всё меняем, или не меняем ничего, если хоть что-то поменять не можем, а в других надежной считается система, которая изменяет всё, что может изменить, даже если что-то не может. Да и по ресурсам часто приходится искать компромисс между скоростью и потреблением памяти. Не сможет одно решение удовлетворять всех, всегда и при любых условиях.
coresky
29.10.2016 15:01-1Все веб-приложения (мы же говорим о них?) имеют конечное количество канонично-логических связей. Первая, например, что существует центральное тело страницы и LAYOUT и нужно «их» соединить. Я говорю о наиболее частом случае при построении веб-приложений, да, встречается редко и не так и аякс не так. Это я называю каноничной предрасположенностью. Таких вещей не очень то много и они продиктованы основой, которая «уходит» за пределы темы. Уходит в http протокол, принятый способ фундаментальной архитектуры браузеров и прочее. Так вот такой «каноники» не очень то много…
Теперь вопрос… вы не верите в идеальный код? Задача то для всех одна: «сделайте так чтобы сайты можно было читать в интернете...». Вспомнилось видео: хочу мышкой открывать окна..
Как может возникнуть разнобой в требовании программистов к фреймворк? Исходя из этой логики, существует единое лучшее решение. Есть одна лучшая постановка задачи и одно лучшее решение. Альтернативы, имхо, доказательство лишь того, что каноничность так и не «разрулена», хотя, я верю, что это возможно.lair
29.10.2016 15:11Первая, например, что существует центральное тело страницы и LAYOUT и нужно «их» соединить.
… и даже у этой задачи есть больше одного равноправного решения.
Люди до сих пор не могут определиться, какой presentation pattern лучше подходит для веб-приложений (и, будем честными, с развитием технологий это банально меняется), а вы говорите "идеальный фреймворк". Да он устареет раньше, чем будет написан.
Задача то для всех одна: «сделайте так чтобы сайты можно было читать в интернете...».
Эту задачу решает http-протокол… и если вы обратите внимание, тоже единой версией не обошлось.
Но вообще я вам настоятельно не рекомендую смешивать веб-сайты и веб-приложения.
VolCh
29.10.2016 15:37+1Если мы говорим о сайтах, которые только читают (как минимум никакие состояния на сервере пользователями не изменются, кроме технических логов, счётчиков и т. п.), то я вообще сейчас порекомендовал бы какой-нибудь генератор статических файлов, вообще без уровней сервера приложений и хранилища данных, только веб-сервер.
А если мы говорим о веб-приложениях с изменяемыми на стороне сервера пользовательскими данными, то требования к ним куда более разнообразны чем просто «сайт можно читать и писать в интернете», особенно в части «писать». Скажем, если не предполагается какой-то совместный доступ к данным между пользователями, то его возможность в фреймворке будет избыточна для данной задачи, а если предполагается, то надо будет искать компромиссы между, как минимум, удобством работы и целостностью данных.
Вы исходите изложногонедоказанного тезиса «есть одна задача и есть одна лучшая её постановка». Задачи разные, более того нередко противоречащие друг другу, например, «мы должны всегда иметь возможность идентифицировать пользователя и иметь полный список действий которых он совершил, всего версии всех его данных и т. п.» и «мы не должны иметь возможности при всём желании идентифицировать пользователя, получить доступ к его данным и т. п.».coresky
29.10.2016 16:00Есть конечно такие различия, но я писал, что в SKY большое внимание уделяется потенциальной частоте использования функционала. Ваш первый случай «всегда иметь возможность идентифицировать пользователя» — частый, я бы сказал, его нужно «танцевать» в «чистое облако». Второй «мы не должны иметь возможности при всём желании идентифицировать пользователя» — редкий, может быть получен модификацией кода CLEAR-CLOUD с помощью приложения DEV.SKY. Я бы отдал первому случаю 90% частоты, второму 10% из всех сайтов реально присутсвующих в Итернете. Второй случай, это только некие платежные системы или нечто когда повышенные требования к безопасности или требования закона государств. Таких случаев мало.
Вы «летаете» в абстракциях, в жизни 10% случаев это мало… Нет смысла делать код гибким, чтобы поддерживать их.lair
29.10.2016 20:22+1Второй «мы не должны иметь возможности при всём желании идентифицировать пользователя» — редкий, может быть получен модификацией кода CLEAR-CLOUD с помощью приложения DEV.SKY.
И вы, конечно, не в курсе, что модификация кода фреймворка для решения задачи — это плохо?
Вы «летаете» в абстракциях, в жизни 10% случаев это мало…
10% — это 36 дней в году (больше месяца). Это один месяц (больше) из вашей зарплаты за год. Это мало, да?
jMas
29.10.2016 23:54Если перевести в автомобильную тематику, то "Как легковушка может удовлетворить потребности в перевозке огромного количества стой-материалов?". Потом, как заметили в комментариях, кому то нравится дизайн, а кому то практичность (производительность) и далеко не все готовы идти на компромис со своими убеждениями и брать что то "идеальное".
AaAAxzz
29.10.2016 09:40+1«проект packagist» это про композитор речь (менеджер пакетов для PHP), мне особенно понравилось
нет папки vendor. Требуется переработка классов на packagist в соответствии с идеологией SKY.
примерно ~ 115 тысяч пакетов переработать, coresky, извини, разочарую, но на это ни кто не подпишется.
franzose
29.10.2016 03:03+4Жесть какая-то. Вы пишете на PHP 3?
coresky
29.10.2016 08:54-3На главной странице http://ru.coresky.net/ упоминается что нужен PHP 5.4 и выше. Как можно быть таким невнимательным? Просто ужас действительно.
MetaDone
29.10.2016 03:50+1Требуется переработка классов на packagist в соответствии с идеологией SKY
роутинг страниц, как механизм излишен.
Писать код в глобальную область видимости и использовать eval() в коде нужно шире, как это делается в SKY framework
Механизм NAMESPACE излишен.
автор или толстенный тролль, или не понимает о чем говоритcoresky
29.10.2016 09:01-3Я честно говорю, я трудился над тем, чтобы в статье не было грамматических и прочих ошибок, материал был легко понятен, несколько (довольно много) часов. Могу я вас попросить, в дань уважения моей работе, давайте не будем здесь употреблять слово «троль» и «велосипед». Я не прошу вас больше не о чем.
Мне искренне жаль, что материал показался многим сложен для чтения. А вот большой процент людей, не вникшим ни в какую суть, но желающих покритиковать, огорчает.kroshanin
29.10.2016 09:48-2А вот большой процент людей, не вникшим ни в какую суть, но желающих покритиковать, огорчает.
Таков сейчас хабр. Если ваше мнение отлично от мнения большинства — вас минусуют, даже не пытаясь ни в чем разобраться. Причем независимо от того, насколько вы правы/неправы или какие аргументы вы в свою пользу приводите.
P.S. Знаю, что за этот комментарий меня тоже скорей всего заминусуют, но хочется вас поддержать. Повторюсь, некоторые ваши идеи (да и сам проект тоже) достаточно интересны и заслуживают должного внимания.
michael_vostrikov
29.10.2016 11:16+8А почему вы решили, что люди не вникли в суть?
Вы предлагаете не использовать PDO и именованные параметры, а экранировать данные вручную.
У вас в коде куча потенциальных SQL-инъекций.
if (sql("+select count(1) from users where email='$data[email]'$or")) return 3;
Email перед этим проверяется регуляркой. Вы в курсе, что одиночная кавычка в email это разрешенный символ? Кто-нибудь решит привести вашу регулярку в соответствие с RFC, и в запросе появится уязвимость.
Вы предлагаете писать в полупроцедурном стиле с eval() и глобальными объектами. При этом некоторые процедуры с какими-то скрытыми хаками.
function sqlf() { $ary = func_get_args(); $func = 'global $sky; return is_array($v) ? $sky->join("' . strtolower(substr($sql = array_shift($ary), 0, 1)) . '", $v) : $v;'; return sql(vsprintf($sql, array_map(create_function('$v', $func), $ary)), 2); } function strand($n = 23) { ... if ($n != 7) $str .= 'o0Ol1iIB8'; # skip for passwords (9 chars) ... }
Вы предлагаете другим разбираться, поддерживать и развивать ваш код с кучей сокращений и запутанной архитектурой. Все вот этиglobal $UA, $PVAL, $s_crypt, $p_mem; $this->idc; $this->gpc; $this->qn;. А что означают$sky->s_c_mandaи$sky->s_j_mandaя даже думать не хочу.
Это правильный путь? Нет уж, спасибо.coresky
29.10.2016 11:40-8..cookie mandatory, javascript mandatory
нет никакой кучи потенциальных SQL инъекций, зачем врать? Приведите хоть 1 пример реальный… а не «побурчал, сделал умный вид» и ушел. Да, экранировать надо вручную, это принцип KISS. Если у вас сложности с экранированием вручную, вы не будете способны написать нормальное веб-приложение, даже если фреймворк даст вам функции-методы, где авто-экранирование.
>процедуры с какими-то скрытыми хаками…
настолько сложно, что вы не можете понять работу функции? Три строчки то всего… Что может быть проще? А может просто признаетесь, что не владеете func_get_args и vsprintf в полной мере?
У меня сложная архитектура? Тут я просто «пас»…lair
29.10.2016 11:45+1Ручное экранирование (данных, отправляемых в БД) — это бессмысленная трата времени и сил при наличии параметризованных запросов. Более того, параметризованные запросы (обычно) производительнее на сервере. Так кому и зачем может быть нужно ручное экранирование?
jMas
30.10.2016 00:15Автор статьи просто не понимает, что KISS требует контекст.
- В юриспруденции важна подробность описания. И чем подробней, тем отсекаются всякие "домыслы"
- Армия (из которой пошел KISS) — важна краткость при передаче информации, чем метче и точнее, чем меньше слов — тем лучше, но все слова и фразы должны быть заранее выучены (чем и занимаются в учебках)
Потому, я считаю, KISS не такой простой каким может показаться. Другими словами — нужно учитывать внешние требования и не писать лишнего. Применять к программированию следующим образом: если требуется одностраничник — не нужно городить огород из кучи абстракций и баз данных. Если бизнес требует абстракции — пиши абстракции.
Но автор подумал, что 640 Кб хватит всем.
lair
30.10.2016 00:56Автор статьи просто не понимает, что KISS требует контекст.
По моим ощущениям, автор статьи не только этого не понимает.
Если бизнес требует абстракции — пиши абстракции.
Бизнес обычно не требует абстракции, бизнес хочет, чтобы работало.
jMas
30.10.2016 11:16Бизнес обычно не требует абстракции, бизнес хочет, чтобы работало.
Бизнес еще требует чтобы оно быстро и легко поддерживалось. (Отсюда и любовь бизнеса к популярным фреймверкам — большое количество разработчиков и саппорт, модульности — в каком то смысле это и есть абстракции).
lair
30.10.2016 13:40+1Бизнес хочет, чтобы стоимость сопровождения и внесения изменений была минимальной, это правда. На все остальное ему наплевать.
(К сожалению, есть бизнес, который лезет не на свою территорию, и пытается решать, каким образом стоимость сопровождения будет меньше — и, поверьте мне, далеко не всегда это "популярные фреймворки".)
jMas
30.10.2016 14:18Иногда дешевле бизнесу поддерживать свое, иногда взять поддерживаемое. В двух вариантах есть достоинства и не достатки. Смотря какие цели (контекст). Тут как всегда серебряной пули нет.
В конечном счете, ему (бизнесу) наверное все равно, главное чтобы соотношение "цена-качество-скорость" или улучшались или хотя бы оставались на том же уровне.
А разработчикам, чтобы непрерывно удовлетворять изменяющиеся требования бизнеса (улучшать скорость, ускорять поддержку), приходится строить абстракции (примеры: ассемблер, Java, виртуальные машины, React: рендер на клиенте или сервере), чтобы добиться заменяемости на уровнях ниже. Вчера компьютер занимал целую комнату, завтра стал квантовым, но программы тех бородатых времен продолжают работать.
lair
30.10.2016 14:24+1Вот про это я и говорю: бизнесу плевать на абстракции, фреймворки и модульность. Ему нужна низкая стоимость разработки, и конечно, если спросить, то ему нужна низкая стоимость поддержки (но вот повысить для этого стоимость разработки он откажется).
michael_vostrikov
29.10.2016 12:19+3нет никакой кучи потенциальных SQL инъекций, зачем врать? Приведите хоть 1 пример реальный…
«Потенциальная SQL инъекция» означает, что сейчас инъекции нет, но при некоторых условиях она может появиться. Пример я вам привел: меняем регулярное выражение для соответствия RFC — появляется инъекция в запросе.
Да, экранировать надо вручную, это принцип KISS
В запрос передаются 10 значений. Можно 10 раз вызывать escape(), можно 10 раз не вызывать escape(). Минус 80 символов, как минимум. Мне непонятно, почему более громоздкий вариант это по-вашему проще.
Если у вас сложности с экранированием вручную, вы не будете способны написать нормальное веб-приложение, даже если фреймворк даст вам функции-методы, где авто-экранирование.
Почему это? Кстати, раз уж зашел разговор, написанные вами веб-приложения можно где-то посмотреть?
У меня сложная архитектура?
Не сложная, а запутанная и, соответственно, сложная для понимания. Архитектура у вас как раз простая, и это тоже показатель — то, что вы простую архитектуру записали сложным и малопонятным кодом.
настолько сложно, что вы не можете понять работу функции?
Смысл не в том, что ее нельзя понять, а в том, что для понимания ее работы надо залезть в реализацию. А для понимания работы системы в целом надо залезть в реализацию всех функций, потому что а вдруг там тоже магические константы.
Прочитайте книжку Макконнелла, если еще не читали. А если читали, то задумайтесь, почему программисты считают ее хорошей.coresky
29.10.2016 12:31-3сайт из видео — http://ru.coresky.net/download?video1.sky.zip
Можно 10 раз вызывать escape(), можно 10 раз не вызывать escape()
вы фантазируете, это нереальный случай (оч. редкий), но даже в этом случае — просто используйте цикл, если надо. Посмотрите мой реальный код, где запросы к БД и сравните со своим. Что проще?lair
29.10.2016 12:38+1eval($me) or die; if ('delete' == $PVAL): sql("delete from $me where id=$WVAL"); jump(me);
Первые строки файла
admin/_blog.php.
И да, это ужасно.
coresky
29.10.2016 12:45-1Предлагаю глубоко вникнуть в детали… Это простейший кусочек кода, который, надеюсь, не даст повода много прояснять. Начну разговор так: что ужасного то? Очень просто, это ужасно?
lair
29.10.2016 12:51+7Ужасно то, что этот кусок кода (а) делает непонятно, что (что такое
$me?$PVAL?$WVAL? нет, спасибо, ответ "это переменные" мне не нужен), и (б) то, что из него понятно — ужасно: представьте себе, что случится, если$WVALбудет иметь значениеid(просто строка из двух символов).
Веселее всего, конечно,
$me— которая сначала исполняемый код, потом имя таблицы, а потом и вовсе непонятно что (что делаетjump?).
Поэтому нет, это не простой код. Простой код — это тот, который понятен и не вызывает вопросов. А у вас код… простецкий. Он прикидывается простым, но таковым не является.
coresky
29.10.2016 13:31-4В том-то и дело, что даже тривиально простой код вам не понятен, а что уж говорить о коде симфони и ларавел? Вы не сможете никогда постичь его глубинного значения. Даже сами авторы таких фреймворк не понимают и «высокие авторитеты» не понимают, по этой причине появился ларавел из симфони.
Опишу глубинный смысл этого кода:
1 способ аналитического взлома сайта — это запустить файл, который сам по себе включаем, как точку входа. Такое действие часто может выдать детали кода хакеру. Существует 3 способа защиты от этого взлома:
1. модный — поместить файлы PHP выше корня веб-сервера
2. положить файл .htaccess с кодом «deny from all»
3. написать вначале файла defined('CONST') or die; — хорошо забытый старый способ
В SKY является стандартным способ номер 3, но можно использовать любой или все.
Способ номер 3 несет четыре функционала в себе, без добавления (вообще !) нового кода. Во-первых, защита от взлома. Во-вторых, в константе указывается имя точки входа, например там может быть admin или front или cron или… другая… Эта информация используется в коде первого крыла main/sky.php, который всегда (! самый потенциально употребимый код) участвует для потенциальной замены любого сайта в Интернете. Кроме того, канонически веб-приложения всегда (оч. часто) построены так, что есть LAYOUT и код «центрального тела страницы». Таким образом третье функциональное назначение: если написать eval($me) or die; это сработает так-же как и defined('CONST') or die; Если переменная $me неопределена сработает die. Код переменной $me можно найти… Но если нормальная работа $me будет хранить имя файла без подчеркивания и .php Ее можно использовать в запросах SQL. При переименовании файла, запросы менять не надо. Часто удобно, чтобы псевдо-имя файла совпадало с именем таблицы с которой работает. Кроме того в трассировке показывается что «центральный файл страницы» запустился (или нет). В четвертых: открыв любой файл SKY-приложения, всегда сразу видно это включаемый файл или файл-точка входа. Благодаря всему описанному функционалу, выбран способ 3 как базовый и стандартный для защиты от основного способа интеллектуального взлома. Есть стандартный файл admin/_main.php, в котором есть стандартный код, который можно запустить и проверить — есть ли надежная защита от такого взлома…
if ('delete' == $PVAL): — тут у вас думаю нет проблем в понимании
sql(«delete from $me where id=$WVAL»); здесь $me выше описана. $WVAL одна из стандартных переменных: $PAGE, $PVAL, $WHAT, $WVAL. Практически всегда (очень часто) первых два ключа-значение из массива $_GET нужны, для обеспечения роутинга страниц, как вы называете (хотя для меня это громкие слова только). Чтобы был проще доступ, эти ключи-значения помещены в эти переменные.… чтобы было тривиально просто.
Этот файл admin/_blog.php — авто-генерированный утилитой VISUAL из приложения DEV.SKY. Он считается только каркасом. Если вам нужен файл для приложения, которое выполняется только на вашей раб. станции, то и дополнительного «крышевания» не надо. Или если доступ к файлу есть только у вас, у разработчика в аггрессивном Интернете. Но если, вы не доверяете всем вхожим в админку, нужно допистать код крышевания, сделать защиту от SQL инъекции. Этот файл, только каркас!
jump(me); — это просто редирект. Константа me будет хранить ?blog
функция редиректа, так же как и sql() — часто используемая. Не нужно ее в класс «пихать»
все, в общем-тоlair
29.10.2016 14:08+7В том-то и дело, что даже тривиально простой код вам не понятен
Как уже сказано выше, он совсем не "тривиально простой".
Вы не сможете никогда постичь его глубинного значения.
Оу, вы вот так легко делаете рассуждения о моих когнитивных способностях? По юзерпику, наверное?
Опишу глубинный смысл этого кода:
1 способ аналитического взлома сайта — это запустить файл, который сам по себе включаем, как точку входа.
модный — поместить файлы PHP выше корня веб-сервераЭто не "модный", это простой и эффективный. Нельзя взломать то, к чему нет доступа.
(впрочем, можно еще взять язык/платформу, где "включаемые файлы" либо изжиты, либо сами по себе не являются исполняемыми для веб-сервера, и вообще не думать о таких вещах)
- написать вначале файла defined('CONST') or die; — хорошо забытый старый способ. В SKY является стандартным способ номер 3,
То-то у вас там написано
eval, а неdefined.
Код переменной $me можно найти…
А я не хочу ничего искать, в том-то и дело. Я хочу открыть самодостаточный (а иначе зачем он в отдельном файле) код, и понять, что он делает, без дополнительных подпрыгиваний и поисков.
Но если нормальная работа $me будет хранить имя файла без подчеркивания и .php Ее можно использовать в запросах SQL. При переименовании файла, запросы менять не надо.
… теперь у вас таблица в БД связана с именем файла. Причем неявно. Как хорошо, что мне никогда не надо будет это отлаживать.
В четвертых: открыв любой файл SKY-приложения, всегда сразу видно это включаемый файл или файл-точка входа.
Угу. Я вот понял, что это включаемый файл, но вот найти, где он включается, мне не удалось.
$WVAL одна из стандартных переменных
Которая имеет какую семантику? И почему эта семантика не понятна из названия?
для обеспечения роутинга страниц, как вы называете (хотя для меня это громкие слова только)
Оно и видно, что для вас "роутинг" — это громкое слово, хотя это всего лишь обычный термин, имеющий англоязычное происхождение.
Но если, вы не доверяете всем вхожим в админку, нужно допистать код крышевания, сделать защиту от SQL инъекции.
Я имею привычку не доверять никому. Очень полезно. И если сгенеренный код по умолчанию небезопасен, то зачем он мне такой?
Константа me будет хранить ?blog
Угу, отдельное спасибо за то, что отдельно есть
$meиme, и не дай б-г их перепутать.
все, в общем-то
Угу. Для того, чтобы объяснить пять строчек кода, вам пришлось написать экран текста. Это как раз и ужасно.
S_A
29.10.2016 17:40Вы не сможете никогда постичь его глубинного значения.
Вот знаете, до этого даже не смотрел код — статья как-то не настроила. Но после такого пойду посмотрю…
А так-то, постигать «глубинное значение» в коде, когда у тебя дедлайны, заказчик грозит судами-тудами, и какая-нибудьпое*еньстраница начинает валить логами вместо красивых каких-нибудь слайдеров и карточек товаров (из 1С, спасите меня от неё), а потом еще три проекта в очереди и там конь не валялся… извините, всё это некогда.coresky
29.10.2016 17:54-1>Вы не сможете никогда постичь его глубинного значения.
это про симфони и ларавел я писал. Там по контектсту понятно. Но и насчет кода SKY, я писал, что считаю только коллективно можно создать идеальный код.
>Вы не сможете никогда постичь его глубинного значения.
И сами авторы не могут, косвеное доказательство появление ларавел из симфони.
Я так понимаю, здесь мало кого интересует истинна. Здесь просто арена для развлечений… Что ж вы так невнимательно читаете… (почти все комментаторы)S_A
29.10.2016 18:01Да нет, вот, зашел на сайт, поглядел. Скажу вам так: использую Zend и недоволен. Bitrix — терпеть не могу. Wordpress уважаю, хотя годен он далеко не всегда.
Мысль моего коммента была скорее в том, что инструмент хорош под задачу. Сделать быстро магазин с выгрузкой из 1С? Ну, битрикс, ладно… Сделать корпоративную визитку? Ок, вордпресс. Кастомный каталог? Zend и Doctrine замечательны.
Не остается места для философии в программировании за деньги. А для души и решений на салфетке я предпочитаю javascript.
raveclassic
29.10.2016 19:00можно создать идеальный код
Идеального кода не существует, и существовать не может. Вы, видимо, все еще на светлой стороне.
michael_vostrikov
29.10.2016 14:30+2Это вы, видимо, с разработкой больших приложений не сталкивались. Там и под 50 бывает, и с наследованием таблиц, причем одновременно редактируется как минимум половина. Информация к размышлению: как вы думаете, сколько параметров может быть у обычной городской квартиры?
В коде у меня, как ни странно, нет ни циклов, ни escape(). Проще не придумаешь.coresky
29.10.2016 15:07когда делаете фреймворк нужно по умолчанию настраивать на наиболее часто-употребимый случай.
michael_vostrikov
29.10.2016 17:40Ну вот есть ваш фреймворк, в котором надо писать экранирование, циклы, и следить за количеством полей, и есть другой фреймворк, где ничего этого делать не надо. В соответствии с принципом KISS нужно выбрать другой фреймворк. Поэтому люди вас и критикуют, а вернее, пытаются объяснить, в чем вы не правы, а не потому что они не вникли в суть и не захотели понять ваши высокие цели.
coresky
29.10.2016 18:02-1Здесь 2 вещи на чаше весов:
1) автоэкранирование есть — не надо добавлять вручную
2) не делать автоэкранирование: код фреймворк не перегружен лишним кодом и второе: сделать автоэкранирование бывает нужно для 1-2 полей часто. Если с автоэкранированием: что тогда… для моего session_id, который заведомо int будет применено автоэкранирование… нужен ли этот лишний код? Статистически это ненужное автоэкранирование будет работать очень часто, что не нужно.
На чаше весов, имхо перевешивает логика имеющаяся в SKYmichael_vostrikov
29.10.2016 19:31+1Нет никакого кода для автоэкранирования в коде фреймворка, данные не склеиваются с запросом в одну строку. Запрос передается отдельно, данные отдельно. Смотрите примеры использования PDO::prepare.
Даже если вы не будете использовать PDO, а добавите автоэкранирование всех параметров запроса, на выполнение этих «лишних» вызовов уйдет гораздо меньше времени, чем на прием-передачу данных из БД через сетевое соединение. Вы пытаетесь экономить на спичках.
И претензии к вашему фреймворку связаны не только с экранированием, так что на чаше весов здесь гораздо больше критериев.
youlose
29.10.2016 19:55«код фреймворк не перегружен лишним кодом и второе: сделать автоэкранирование бывает нужно для 1-2 полей часто»
Предварительная оптимизация — зло, а у вас есть результаты замеров, где ясно что эта часть критически важна для оптимизации производительности?
Вам же уже писали, что использование prepared запросов может и увеличить производительность запроса, скешировав его на стороне DB сервера.
А в шаблонах я очень редко видел чтобы экранирование вообще существенно могло повлиять на производительность.
«что тогда… для моего session_id, который заведомо int будет применено автоэкранирование… нужен ли этот лишний код? Статистически это ненужное автоэкранирование будет работать очень часто, что не нужно.»
1. У взломщика это значение может быть чем угодно.
2. Вот вы сейчас помните что session_id — int, а через неделю уже нет или другой человек начнёт работать над вашим проектом, ему же придётся потратить время и понять как вообще там должен быть тип, а если он новичок или пофигист, он просто проигнорирует эти разбирательства и сделает как ему удобно, таким-то образом многие уязвимости и появляются.
ellrion
29.10.2016 12:16+6Вот именно! Я искренне не понимаю ту часть сообщества хабра которая поддерживает автора. Он скрываясь за собственными терминами и словоблудием продвигает пару вполне нормальных истин. "Простота — хорошо"; "Опенсоурс — хорошо"; "Слепое следование любым постулатам — плохо". Но при этом сам же автор всё это нарушает абсолютно.
Не понимает, что проектов в которых десятки опытных разработчиков УЖЕ ведут разработку вместе и шлифуют код полно. И Флагман это гитхаб. И такая коллективная работа ведется как раз над современными фреймворками, которые так не нравятся автору. Достаточно открыть вкладку с контребьютерами. Но нет нужно там всё бросить и делать скай, ибо там все силы тратятся в пустую.
Говоря что нельзя быть слепым следователем каких то постулатов, сам пишет о слепом следовании KISS при этом в каком то своем понимании.
И самое имхо главное то что он уже сделал это плохо, вот именно ПЛОХО. Говоря что современные подходы только вносят сложность, сам код написал так что в нем невозможно разобраться, он ужасно СЛОЖНЫЙ. Да я быстрее в ларе прикрутил бы броадкастинг эвентов через реббит, при этом сделал бы это всё используя подход фреймворка, и в слое самого приложения вообще бы не было разницы со стандартными методами броадкастинга. Чем в приложении автора пойму откуда какая переменная прилетела и откуда например на какой то строчке есть $user хранящая данные аутентифицированного пользователя. Не говоря уже о каких то сложных вещах типа нескольких одновременных аутентификациях.
А использования тысячи переключалок в визуальной утилите еще сложнее. Я бы быстрее код ядра фреймворка прочитал и понял.
Нет простоты у тебя автор. Никакойcoresky
29.10.2016 12:19-7Параметрические парадоксы индексируемых континуумов, ортодоклально коллапсируют с тенденциями классических литералов. Это шутка, простите… )
ellrion
29.10.2016 22:36+2О да, это было очень умно. Нечего сказать не по одному из пунктов? Собственно как говорят "слив засчитан".
Повторюсь ваш код ужасно сложен. Он, как тут было верно сказано, простецкий а не простой. А вы путаете эти понятия. И плюс учитывая что сами писали эти несчастные несколько файлов и мусолили их по много раз вот он и кажется вам простым. Код огромного Ларавель в котором есть функционала в сотню раз больше проще в разы чем ваши "крылья".
MetaDone
29.10.2016 13:25+2Давайте же углубимся в суть.
Первый попавшийся под руку файл и в нем жесть
$useds = ['---', 'used', 'not used']; $edit = is_numeric($PVAL); $block = $u_profile_code && $u_profile_code < 4 ? '' : 'none'; function checkbox($p) { global $targets, $wona; return sprintf('%s type="checkbox"', $p > -1 ? ($targets[$p] ? ' checked' : '') : ($wona[-$p - 1] ? ' checked' : '')); } $sql = "~select left(p.status,2)='00' or c.package_id=0 as x, p.name as pname, c.* from _dev_codebase c left join _dev_packages p on (p.id = c.package_id) where c.id=$PVAL"; extract($edit ? sql($sql) : ['x' => 1, 'pname' => 0] + get_columns2('_dev_codebase', 3), EXTR_PREFIX_ALL, 'r'); list ($tabs, $vo_me, $vo_all, $targets, $status, $wona) = explode(' ', $r_status, 6); $d = ''; echo str_replace('%TITLE%', "Edit CBR - $TITLE", $start_html); ?>
Об этом я и писал в комментарии к вашей прошлой публикации — «Можно сделать как в старые темные времена прям в странице sql-запрос и вывод в браузер и это будет работать».
пожалуй, хватит углубляться — весь проект в таком духе
Не думал что когда-то такое скажу, но наверно в видеоуроках попова код приятнее.
И с прошлой публикации так и не видно примеров проектов на этом чуде.
Надеюсь, это все троллинг и вы не считаете это простым и легким в поддержке.
coresky
29.10.2016 09:32-5Хм, однако я приятно удивлен. По результатам голосования, практически половина программистов не довольны чем-то в «верном пути» и существующих трендовых фреймворк. Да, откройте же глаза! Уже прошло много лет жизни PHP, а хорошего пути в PHP нет до сих пор. Голосование по-видимому здесь анонимно, люди честно голосуют. В комментариях же боятся быть уличены в невежестве…
Предложение для сайта HABRAHABR: сделайте, чтобы было можно писать анонимно комментарий зарегистрированным пользователям — жизнь предстанет в другом цвете. Да… некоторые люди, тогда будут пробовать писать плохие «каки». Нужно, чтобы авторы комментариев были предупреждены, что за нецензурную лексику — в этом случае, просто могут потерять аккаунт. А за честное мнение, не будут «заминусованы»…
Мне уже кажется, что на этом уважаемом сайте, просто имеются люди, следящие за хабами и в маркетинговых целях подавляют иные подходы, не соответствующие желаемым. Т.е. это их рабочее задание. «PHP right way» в это случае о-о-очень тонкий маркетинговый ход. Это просто вирус, поразивший программистов.S_A
29.10.2016 09:54У вас чудесный опрос! Две галки. Люди голосуют очень честно, вне всяких сомнений (без сарказма).
coresky
29.10.2016 10:09-2Уже прошло много лет и за это время можно было сделать фреймворк так, чтобы всем нравился 99%, я в это искренне верю. Это потенциально возможно — 100%.
TheShock
29.10.2016 12:20Это потенциально возможно — 100%.
Но, как видите, не для вас.
И вообще, даже в таком старом деле, как физический инструментарий нету до сих пор единства. Все умные люди уже пользуются бензопилой, а есть старперы, которые до сих пор предпочитают молоток и отвертку.
KlimovDm
29.10.2016 10:04+1У Josh Lockhart перед вами есть одно большое преимущество — он адекватно, аргументированно и понятно объясняет свой подход. Пусть вас не удивляют результаты голосования, они говорят лишь о том, что многие голосовавшие используют PHP как рабочий инструмент, зачастую миксуя различные подходы, не превращая какой либо из них в религию.
coresky
29.10.2016 10:22Такую критику, считаю адекватной, спасибо. Буду стараться работать лучше над легкостью текстовых материалов.
seryh
29.10.2016 10:05Посмотрел ваш сайт, видео, исходники проекта. Количество вложенных сил и то что вы ведете проект минимум с 2013 года, бесспорно вызывает уважение. Однако меня не покидало чувство что вы с 2010 года живете в изолированном бункере где нашли книжку о PHP. На подобный проект в 2016 году кроме как с удивлением и непониманием смотреть не удается. Если вам не нравится "путь PHP" почему бы не посмотреть на другие языки? Если отойти от мейнстрима то выбор огромен, в том числе и с принципом проектирования приближенном к KISS.
coresky
29.10.2016 10:15-2Я хочу прояснить невежество… Вот точно так-же, как разработчик laravel сказал мимо строчек, что symfony это невежество и сделал папку illuminate. Но только одно невежество заменено другим.
Я хочу, чтобы вы перестали «дышать через противогаз» и вдохнули глоток чистого воздуха… Сорри, если аллегория показалась жесткой. Язык PHP подходит лучше других.franzose
29.10.2016 11:17Вот точно так-же, как разработчик laravel сказал мимо строчек
Это где и когда такое было? :)
coresky
29.10.2016 12:07-1«Мимо строчек» означает, что просто намекнул. Он назвал папку illuminate, что нужно перевести как «прояснять». Ларавел базируется на симфони, намек состоит в том, что была путанница, а стало ясно.
Fractalzombie
29.10.2016 10:47+1Посмотрел сайт. Тексты похожи на секту => Идеальный код, Программисты Земли… Ну в 2016 году живем, зачем это?
Посмотрел видео: особо оттуда ничего не ясно, но называть symfony и laravel невежеством — это как назвать .NET или Spring — убожеством. Вы конечно извините, но как мне кажется, для разработчиков уровня Enterprise — ваш код не подойдет. Все эти визуальные генераторы и т.п. вещи ну для замены вордпресса.coresky
29.10.2016 10:50-1Ну а как вы объясните, что автор захотел переработать Symfony и создать Laravel? И еще вопрос: как вы думаете, какие мысли у него были, чтобы придумать название для папки illuminate?
Fractalzombie
29.10.2016 10:55Есть проекты, которые начинать стоит на symfony, есть, которые на laravel. Тут дело не в том, какой лучше, а какой подойдет для конкретного кейса.
В именовании папок лучше узнать у самого разработчика, что он преследовал.
coresky
29.10.2016 11:03Надо же… А алгоритм не подскажете? Как правильно выбрать симфони или ларавел?
Fractalzombie
29.10.2016 12:16+1Ну если вы сами не понимаете, то смысл объяснять? Можно же глянуть спецификацию. Но если честно почитав комментарии к прошлой вашей статье, я для себя понял одно, общаться с вами это как об стенку головой биться.
coresky
29.10.2016 12:40-1Так может совсем не стоит «биться»? Может стоит хотя бы взглянуть внимательней в другую, непривычную сторону? А там может быть новая дорога, и чистый воздух?
Fractalzombie
29.10.2016 13:13Конечно, я такой подход использовал, когда выпускался с академии, когда не знал не парадигм, не ООП и фреймворков.
VolCh
29.10.2016 13:54Проанализировать задачу для начала, включая пожелания заказчика в кратко-, средне- и долгосрочной перспективе. Посмотреть насколько она подходит под симфони и ларавел, а может лучше вордпресс установить или на плюсах её решить.
cjbars
29.10.2016 12:07+14Не побоюсь так комментировать, но чего мы лебезим тут? Автор откровенно самовлюбленный неуч, пытающийся наплевать на прогресс и мнение окружающих, пишущий при этом чистейший говнокод в лучшем его проявлении. Автор даже думает какой то кашей. Это невозможно читать, ни статью ни комментарии.
Бред какой-то, и ведь еще не сезон обострений.raveclassic
29.10.2016 13:08О, что вы, вот вам предыдущая часть с не менее эпическим срачем в комментах
ultrinfaern
29.10.2016 16:23+8Я согласен с автором, что глобальные переменные это здорово. И прекрасно, что он
смог избавиться от локальных переменных — они сбивают с толку же! Предлагаю улучшить
код фреймворка избавившись от функций. Зачем вот они нужны? Когда читаешь код с функциями, все время нужно
куда-то перелистывать, искать эти куски (да еще и локальные переменные сбивают
с толку), возвращаться уже непонятно куда… Проще писать код прямо и читать его тоже легко.
А для одинаковых кусков есть редактор: скопировал кусок кода, вставил где нужно и все!
Я думаю, все согласятся что читаемость кода увеличивается, но опять, как сказал,
автор все гонятся за какими-то непонятными трендами.
Rottenwood
29.10.2016 18:01+1А как в канонах фреймворка решается вопрос с модульным тестированием, особенно когда логика тестируемого приложения использует данные из БД и ответы внешних сервисов?
coresky
29.10.2016 18:23-1пока никак. Я предлагаю в нынешнем времени разобраться и попробовать «поиграться» с тем что сейчас имеется. Понять много хороших идей, которые сейчас есть. Взять на вооружение проект SKY как хобби. Я писал, чтобы сделать код условно идеальным — нужна коллективная работа и множество иттераций по совершенствованию. Только тогда я бы позиционировал SKY как замену вашим привычным фрейворкам. Хотя я считаю, что текущий coresky, написанный только лишь лично мной одним — уже хорош и интересен и может с успехом быть применен на большом спектре сайтов. Но в проекте еще очень много работы, которую нужно выполнить прежде чем позиционировать его как коробочное решение… В проекте интересно кардинально отличающееся рассмотрение проблем веб-разработки.
Fractalzombie
29.10.2016 20:02Так только вами или многими программистами с планеты Земля?
coresky
29.10.2016 20:14Если на Марсе обнаружат живых программеров, то и марсиане нужны обязательно. Чем больше тем лучше иначе код будет неидеальный
Fractalzombie
29.10.2016 20:39Ну просто вас подловили и вы решили включить сарказм?) Вы же такой взрослый, и не отвечаете грубостями?
coresky
29.10.2016 21:17Я не считаю сарказм грубым ответом. Это хорошо, что у вас есть желание спорить. В споре рождается истина. Во все времена, новое встречают в штыки… Вы повторили именно так как я писал в статье, мою мысль о том как может быть получен условно идеальный код, с сарказмом, и как вам показалось «в чем-то меня подловили»… Но только не в чем вы не «подловили», так как не написали ничего нового… Просто показали свое невежество… это смешно.
KlimovDm
29.10.2016 21:56>>> В споре рождается истина.
Не стройте иллюзий. В споре истина может родиться только если участники дискуссии примерно одинаково образованы, умеют ясно выразить свою мысль на одном языке с оппонентом и, самое главное, уважают чужое мнение.
Нет, только не здесь…raacer
29.10.2016 22:01Истина рождается в дискуссии. А здесь ее не видно, просто какое-то словестное состязание с целью доказать свою правоту — то есть обычный бестолковый спор. Если комментаторы хоть некоторые пытаются аппелировать фактами, указывать на несоответствия, то автор упорно игнорирует либо перекручивает. Дискуссией можно было бы назвать, если бы автор пришел с вопросом наподобие такого: «сделал штуку, считаю полезным, давайте обсудим у кого какие мнения, почему это хорошо или плохо». Но автор не задает вопросов, он только отвечает на них.
coresky
29.10.2016 22:37-1В дискуссии толку мало, согласен. Но ведь есть еще и те, которые прочли, но участвовать в дискуссии не захотели.
«сделал штуку...» не «прокатит». Чтобы разобраться в «штуке» надо ее поизучать и поюзать, поразбираться. А на это надо хотя бы неделю. Тут никто по-видимому разбираться не хочет. Даже в элементарных вещах путаются. Комментарии здесь — это просто, по-моему, своеобразный способ развлечения у вас… Но кто-то возможно захочет по-разбираться, из тех, кто промолчал. Ради них я с вами общаюсь.raacer
29.10.2016 22:54+4Вам надо было сделать другой опрос: Как вам мой SKY?
— Фигня полная
— Любопытно, но сыро
— Интересно, но не более
— Попробую, возможно это то, что я так долго искал
Тогда позвольте дать Вам несколько советов, как улучшить сложившуюся ситуацию.
1. Сделайте перерыв и попробуйте через время изложить свои мысли в более ясной форме. Так сказать, дубль два. Почитайте что-нибудь на тему того, как сделать хороший доклад или презентацию. Потренеруйтесь, покажите друзьям то, что у вас получилось. Не бойтесь переписывать по несколько раз. Презентация шедеврального труда требует особо тщательной проработки. Если Вы хотите представить новую концепцию, потрудитесь изложить ее так, чтобы даже вашей бабушке было понятно. Не обвиняйте других, что им лень читать — это читать просто невозможно. Возьмите ответственность на себя, только так Вы сможете что-то исправить.
2. Если хотите сделать что-то ценное для других, а не только для себя — начните мыслить критически даже по отношению к своим идеям. Перестаньте ассоциировать свои идеи с собой. Постарайтесь набраться терпения, выслушать все замечания, и сделать из них выводы. Используйте мнение посторонних наблюдателей как способ посмотреть на своё изобретение под другим углом и сделать его еще лучше. Если Вы хотите сделать что-то для других, то надо учитывать потребности других людей. Если Вы делаете для себя лично, исходя из своих странных субъективных представлений о том, что такое хорошо, то это никому не будет интересно.
3. Одно из самых больших замечаний к Вам — это качество кода, оно соответствует уровню любителя. Пожалуйста, прежде чем давать другим возможность постигнуть шедевральность своего изобретения, сделайте код по крайней мере читабельным и аккуратным. Перестаньте использовать странные непонятные хаки, придерживайтесь общепринятых стандартов кодирования, научитесь давать хорошие имена функциям и переменным. Почитайте что-то на тему «как писать надежный и читабельный код». Ваш код — это ваше лицо. Если Вы придете с темой «как навести порядок в доме», и в качестве примера покажете свою неубранную квартиру — Вам никто не поверит. Да Вам и самим стоит усомниться в своих идеях. Это большой повод задуматься и что-то пересмотреть.raacer
29.10.2016 23:00И еще: постарайтесь пожалуйста быть последовательным и основывать свои утверждения на конкретных фактах, а не на здравом смысле. Ваш личный смысл мало кому интересен. Только доказательства в виде фактов и экспериментов, результаты которых можно воспроизвести, могут быть интересны с научной точки зрения.
coresky
30.10.2016 12:26Респект и уважуха вам за этот пост. Вот, наконец, ясные мысли, совершенно лаконичные. Вот только, думаю, жаль эти советы не помогут мне. Ах, как все хотят быть доктором, но никто не хочет быть пациентом…
Ваш совет 1 — я так и делаю.
>чтобы даже вашей бабушке было понятно
Я очень много думал, как представить проект. У меня есть штук 5 или больше описаний идеи проекта
>Не обвиняйте других
Я не обвиняю вас и никого из вас. Да, я бы хотел дискуссии в другом тоне, но она в том, в котором есть. Это как здесь кто-то написал: «я не люблю PHP, но он номер 1, это факт». Жизнь нужно воспринимать такой какой она есть, не стоит совать голову в песок или уходить в свой фантазийный мир. Я виню в том, что дискуссия в таком тоне, в каком есть, только себя. Буду продолжать следовать (1)
Совет 2
>и сделать его еще лучше
coresky файлы http://ru.coresky.net/code (ядро SKY) прошли очень много итераций по совершенствованию мной, может быть 1000, начиная с 2005 года наверно, и будут продолжать совершенствоваться.
>ассоциировать свои идеи с собой…
как это? идея или есть или она не идея, а заблуждение.
>выслушать все замечания…
Этот код очень дорог для меня, потрачено очень много моих усилий для его создания. Замечания здесь в большей мере, не могут быть использованы мной, так как я слышу, например, не пишите в глобальную область видимости, но я не могу не писать, вся концепция основана на этом. По сути, большинство советует: «выбросите вашу работу», я не собираюсь это делать.
>Если Вы делаете для себя лично
прошу прощения, но глупо было это писать. Если бы я делал для себя, не было бы проекта в паблике и этой статьи
Совет 3.
>соответствует уровню любителя
если код выглядит просто, это не значит что он уровня любителя.
>странные непонятные хаки
это нормальный синтаксис PHP, это часть концепции проекта. Использование create_function, eval позволяет делать тривиально простой код. Это также часть концепции. Этот ваш совет, по сути, совет: «выкиньте ваш код»
>хорошие имена функциям
например где плохо?
>покажете свою неубранную квартиру
это нормальная критика, я знаю, что нужна лучшая «обертка для конфеты». Но я «причесал» все, как только мог, буду «причесывать» дальше… Проблема в том, что я слишком «на многое замахнулся», для того, чтобы «протолкнуть» такое, нужны о-о-очень большие ресурсы, а их у меня пока нет. И если не появится сильная помощь для проекта SKY, то он так и не запустится… Но я буду продолжать работать над ним, так как искренне верю
Так, что ваши советы или неприменимы или я уже в курсе и следую и так им.raacer
30.10.2016 13:28+1Этот код очень дорог для меня, потрачено очень много моих усилий для его создания
Вот это — проблема. Почитайте о фиксировании ошибок и о том, почему это важно.
если код выглядит просто, это не значит что он уровня любителя.
Тут уже писали о разнице между «просто» и «простецки». А бы не придумал лучшего объяснения. Простой — это такой, с которым легко работать: читать, изменять.
это нормальный синтаксис PHP
PHP сам по себе ненормален. Там есть полно вещей, которые нежелательно использовать по вполне объективным причинам. Задайтесь вопросом, и Вы обязательно найдете ответ. Задайте вопрос здесь, и найдется знающий человек, который не поленится объяснить.
Проблема в том, что я слишком «на многое замахнулся», для того, чтобы «протолкнуть» такое, нужны о-о-очень большие ресурсы
Да, согласен с Вами. Ниже я уже писал: работа проделана колоссальная, но вот пользы для своих проектов я не вижу совсем. Для примера можно взять другие проекты и посмотреть, сколько людей работают над ними. Если желаете, чтобы у Вас набралась команда последователей — представьте прежде всего идею и базовый функционал, продемонстрируйте ее сильные стороны (генератор — это не новая идея, но она до сих пор не обрела большую популярность по известным причинам), и развивайте проект вокруг этой идеи. Если никто не подтянется — это повод пересмотреть саму идею, возможно даже бросить ее и выбрать совершенно иной подход. Не страшно выкинуть негодную идею. Страшно всю жизнь потратить на нее. Люди учатся на ошибках, и это нормально. Нормально экспериментировать и пробовать что-то новое, и сталкиваться с неудачами. Ненормально цепляться за нерабочую идею и губить на нее все свое время. Чем быстрее Вы будете проверять свою идею и находить ошибки, тем быстрее достигнете цели. Но даже если Вы потратили пять лет, таки лучше что-то изменить через эти пять лет, чем продолжать зарывать голову в песок.
Очень похвально, что Вы тщательно готовились, но, к сожалению, и десять вариантов статей не является гарантом того, что хоть одна из них будет годной. Нужен опыт публикации статей. Самый хороший способ понять, как не надо делать — это сделать неправильно и посмотреть, чем это плохо. Вы сейчас написали «неправильно» и это плохо, теперь самое время сделать выводы. Чем это неправильно? Это сплошная философия и никакой конкретики. Давайте примеры кода, примеры решения проблемы, сравнение вашего решения с другими популярными подходами. Не надо абстрактных аналогий и длинных философствований, покажите конкретные примеры. Вы сами наверняка понимаете, что совершили какую-то большую ошибку, это видно по тому, как Вас встретили. Самое время превратить неудачу в победу. Вместо того, чтобы обвинять всех в невнимательности, спросите людей, почему они невнимательны. Вместо того, чтобы обвинять всех, что они не хотят вникать, спросите, почему они не хотят вникать. Смотрите на свою работу как сторонний наблюдатель. Вместо того, чтобы отстаивать свою идею, попробуйте покритиковать ее, и Вы удивитесь, как люди сами начнут отстаивать Ваши же идеи, в которых есть хоть крупица истины, и обнаружите, как полезны могут быть взгляды под иными углами. Эта информация окажет Вам большую помощь в дальнейшей работе. Получение такой информации — это шаг вперед, это и есть маленькая победа на пути к достижению целей.coresky
30.10.2016 15:44Я считаю себя хорошим программистом и только. Даже если бы я был супер-профессионалом в области публикаций, все равно, сложно сказать: ребята, а давайте перевернем всю область веб-программирования с ног наголову, это хорошо! И так, чтобы все поверили… Для этого нужен, наверно, гипноз только )
Посмотрите последний пост Дурова в vk. Он там пишет 10 советов и совет номер 1 — все нужно делать быстро. vk сделан им за месяц и после этого стал развиваться. Я верю ему. У меня тоже был опыт успешного проекта, который был сделан за неделю, кстати на коде SKY. Насчет проекта SKY, — я сразу понимал, что он совершенно далек от такого пути. Разрешимая ли это проблема, и сейчас непонятно, но я сдаваться не собираюсь. Я получал удовольствие творчества, я искренне верил (и сейчас верю), что многие мои идеи ценны, лучше идей других людей, стал «запечатлевать их в камне». Еще ньюанс в том, что я очень люблю веб-программирование и меня тошнит от трендовых фреймворк.
Я видел интервью с А. Макаревичем, он говорил: не задавайте мне вопросы в стиле «если бы, да кабы… такого не может быть никогда, поэтому не следует об этом и думать». А я люблю, мыслить в стиле «если бы..». На сайте coresky, есть мои размышления, по поводу «если бы человечество бросило максимально возможные ресурсы для создания супер виртуальной реальности». Такой стиль мышления позволяет более красочно моделировать ситуации в уме, а программисты много моделируют в уме.
Цель X описанная выше, в статье из этой области фантазий, но потенциально реальная. Я пытаюсь придумать подход к запуску SKY в стиле «очень быстро, как VK», но не могу ничего придумать пока. Статью на хабре, я планировал написать еще 3 года назад. Я не мог больше тянуть и сделал то, что сделал. Вероятно, это бесполезно: за все время 1 регистрация на сайте, и то человек, по-видимому просто хотел посмотреть «что в средине». Около 10 установок всего-то приложения DEV.SKY. и не очень приятные ощущения в шкуре «мальчика для битья». Но я должен был попробовать хабр.
>покажите конкретные примеры
У меня есть такая идея: портировать форум PHPBB на SKY Framework. Одно время я работал с ним, его хорошо знаю. Он довольно многофункциональный, но я думаю мог бы сделать хорошую реализацию его за «терпимое время». Ничего не придумывать, взять их дизайн и портировать.
Как считаете, может это помочь проекту SKY?
Позволит ли сайт phpbb.com рекламироваться у них бесплатно или они не заинтересованы?
Может быть не phpbb, а другое хорошее приложение без изъянов? NULL-сайт, как видим не впечатляет… DEV.SKY. слишком компактное, сложное, многофункциональное приложение. Его, чтобы «причесать» нужно больше усилий, чем порт для phpbb и нет 100%-гарантий, что им будут активно пользоваться, нет потенциальной возможности получить бесплатную рекламу от авторов phpbb.raacer
30.10.2016 16:04Я считаю себя хорошим программистом и только.
Было опрос на эту тему. Более половины водителей считают свои навыки вождения выше среднего. Простое математическое выражение показывает, что многие из них ошибаются.
Я пытаюсь придумать подход к запуску SKY в стиле «очень быстро, как VK», но не могу ничего придумать пока.
А Вы не пытайтесь объять необъятное. Сделайте что-то маленькое, но самое полезное. Все остальное приложится позже.
Как считаете, может это помочь проекту SKY?
Позволит ли сайт phpbb.com рекламироваться у них бесплатно или они не заинтересованы?
Сомневаюсь. У них свой проект, свое видение.
Может быть не phpbb, а другое хорошее приложение без изъянов?
Вот что Вы пытаетесь «продавать» — то и надо рекламировать, а не phpbb.
raacer
29.10.2016 23:15Чтобы разобраться в «штуке» надо ее поизучать и поюзать, поразбираться. А на это надо хотя бы неделю. Тут никто по-видимому разбираться не хочет.
И Вы, кстати, в этом ошибаетесь. Некоторые товарищи, даже несмотря на Ваше сумбурное изложение, открыли Ваш код и прокомментировали то, что они там увидели. Вы получили конкретные замечания, но приняли их в штыки вместо того, чтобы извиниться за такую сырость и пообещать в ближайшем будущем выложить более приличный код. Это просто неуважение к читателю, Вы не бережете наше время. Или у Вас просто не получается, ну тогда надо потренироваться и улучшить результат. Я лично даже разбираться не хочу, пока Вы не приведете в порядок свои мысли, не говоря уже о самом коде. Мы все заняты своими делами, и тратить время на то, чтобы разбираться с каждой новой сомнительной поделкой, нам не интересно. По опыту мы знаем: если инструмент написан так, что в нем невозможно разобраться, то и работать он будет так же, и баги в нем будут множиться как грибы, и исправление одного бага будет порождать десять других. Стандарты кодирования именно из этого негативного опыта и произрастают. И каждый, кто с ним сталкивается, приходит к пониманию, зачем эти стандарты были придуманы, начинает их применять и радуется улучшению показателя цена/качество своих продуктов. Так что, пока нет никаких оснований Вам доверять. Уважайте, пожалуйста, время людей, к которым обращаетесь, и готовьте материал так, чтобы он был максимально удобен для восприятия.
lair
30.10.2016 00:58Чтобы разобраться в «штуке» надо ее поизучать и поюзать, поразбираться. А на это надо хотя бы неделю.
Ну во-первых, для поверхностных оценок достаточно нескольких часов (если, конечно, в своей отрасли).
А во-вторых, какой смысл разбираться в "штуке", если ни она, ни вы пока ничего нового и полезного не предложили?
coresky
30.10.2016 09:42-1Я не предложил нового? Вы считаете ваши слова адекватные? Вы имеете ввиду, что я осознаю, что ничего нового не предложил или это в ваших глазах нет ничего нового? Я предложил очень много нового, другое дело, что в вашем понимании нет ничего нового.
Вы скачайте код к видео, посмотрите как он прост.
Сравните его с эквивалентным кодом вашего фреймворк…
Новое и полезное: веб-приложение разрабатывается намного проще легче и быстрее чем в вашем фреймворк… это просто небо и земля…
Нужно бы сделать тесты, чтобы сравнить производительность. Думаю и работать будет намного быстрее, несмотря на медленный eval(). Фактические измерения, были бы наверно для вас более весомым аргументомMetaDone
30.10.2016 10:09+5Вы скачайте код к видео, посмотрите как он прост.
Скачал, по вашему это просто?
define('DIFF_CNTS', 'if ($d >= 0) $i++; if ($T & 1) { if (!$sl) $l_ = $l; $sl++; } if ($T & 2) { if (!$sn) $n_ = $n; $sn++; } $T = 0;'); define('DIFF_UNIQ', '$f = 0; if ($d < 0) { $srch = $old[--$l_].$l0.$srch; $l0 = "\n"; $repl = $new[--$n_].$n0.$repl; $n0 = "\n"; if ($x && $x[2] == $l_) $f = 1; } else { if ($sn) for (; $sn; $sn--, $n0 = "\n") $repl .= $n0.$new[$n++]; else { $n_ = $n; $f = 1; } if ($sl) for (; $sl; $sl--, $l0 = "\n") $srch .= $l0.$old[$l++]; else { $l_ = $l; $f = 1; } if ($f) return 1; } if ($f) { $file = str_replace($x[0], $x[1], $file); $snap = str_replace($x[1], $x[0], $snap); $x[0] .= "\n".$srch; $x[1] .= "\n".$repl; } elseif (eval(DIFF_TEST)) { if ($x) $str .= sprintf("\n\n# SEARCH: #\n%s\n\n# REPLACE: #\n%s", cbesc($x[0]), cbesc($x[1])); $x[0] = $srch; $x[1] = $repl; } else return 1; $x[2] = $l; $file = str_replace($x[1], $x[0], $file); $snap = str_replace($x[0], $x[1], $snap); $srch = $repl = $n0 = $l0 = ""; $sn = $sl = $d = 0; $n++; $l++; return 0;'); define('DIFF_TEST', ' if ($srch === "" || $repl === "" || substr_count($snap, $srch) != 1 || substr_count($file, $repl) != 1) return 0; $_t = str_replace("\n", "", $srch); if ("" === $_t || "" === trim($_t, $_t[0])) return 0; $_t = str_replace("\n", "", $repl); if ("" === $_t || "" === trim($_t, $_t[0])) return 0; return 1;'); define('DIFF_UFIX', ' if (!$l_) $d = 1; elseif ($i >= $c) $d = -1; elseif ($d == 0) { # search ext direction $db = $x ? $l_ - $x[2] : 0; for ($df = 0; $df + $i < $c; $df++) if ($rL[$df + $i] != "=") break; if ($df + $i == $c) $df = 0; if ($db && $df) $d = $db < $df ? -1 : 1; elseif ($db) $d = -1; elseif ($df) $d = 1; else $d = $l_ < $c - $i ? -1 : 1; } $sn = $sl = $d;');
у вас даже комментариев не написано почти нигде, или не писать комментарии тоже «sky-way»? Ваш код простой для вас, т.к. вы автор, для остальных — нечитабельный и корявый говнокод (по другому не знаю как назвать)
И опять же — нет примеров каких-либо приложений на этом чудеraacer
30.10.2016 11:16+2О Боже, что это!!!
coresky
30.10.2016 13:42-1Это не код из видео, зачем врать? Вы все время передергиваете факты, чтобы устроить цирк.
Критиковать код прошу из видео http://ru.coresky.net/download?video1.sky.zip
Приведенный вами код из DEV.SKY. В самой статье написано в проекте SKY еще очень много работы… И проект SKY, я предложил пока только как хобби… Я не говорил, что все идеально.
Да, этот код из DEV.SKY. выглядит экстремально, непривычно. Это своеобразный способ, разделить код на части для более простого восприятия и вероятно требует переработки. Но есть и много другой более приоритетной работы, поверьте. Не забывайте, SKY это хобби и деньги мне за него никто не платит. Ресурсы мои невелеки, время от времени большие, время от времени меньшие…
raacer, так вы только сейчас на сайт зашли? Т.е. вы «пробежались» по статье, увидели «белую ворону», нонсенс и решили поразвлечься… Я так и думал, вы изначально и не собирались пытаться понять о чем я пишу, потому что вы уверены, что у вас достаточно аргументов самому-то не попасть в просак. И так многие комментаторы сделали… Жаль, что вы цените такой способ развлечения больше, чем возможность посмотреть на веб-программирование с непривычной стороны и возможно понять что-то новое.MetaDone
30.10.2016 13:54более простого восприятия? вы точно тролль. там ни в одном редакторе даже подсветка не сработает, я уже молчу про тотальное отсутствие комментариев.
давайте из архива из видео посмотрим
$log = []; $sky = new SKY; extract($sky->load(), EXTR_PREFIX_ALL | EXTR_REFS, 's') or exit('err mem'); if ($sky->debug) require 'main/debug.php'; if (at('0 23')) lsql("delete from visitors where dt_l + $s_clear < now()"); at('59 23') && sql("+select 'do work once at the end of day'"); # sample2 if (at('1 0')) $sky->s_email_cnt = 0; if (at('3 3')) require 'main/c_sitemap.php'; $sky->save([ 'cron_dt' => sprintf("%s, execution time: %01.3f sec, SQL nums in cron tasks: $sky->qn", NOW, microtime(true) - START_TS), 'online' => sql("+select count(1) from visitors where dt_l > now() - interval $s_visit minute"), ]); lsql("+select 'test'");
не лучше.
raacer
30.10.2016 14:25+2raacer, так вы только сейчас на сайт зашли? Т.е. вы «пробежались» по статье, увидели «белую ворону», нонсенс и решили поразвлечься… Я так и думал
Опять Вы занимаетесь ясновидением. Сначала дождитесь ответа, а потом уже делайте выводы.
Я неправильно сказал. Я на него заходил, но сразу вышел, так как в тексте не увидел никакой полезной информации — не более, чем в данной статье. Зашел второй раз в ответ на Ваш призыв внимательно что-то изучить. Видео я вообще не люблю, считаю это тратой времени, т.к. хорошо структурированный материал читать быстрее, чем смотреть видео. Но пришлось посмотреть его, чтобы понять, в чем суть проекта.
Меня не интересует Ваш проект в принципе. Я не пользуюсь PHP, и все эти костыли для меня не имеют никакой ценности. Меня заинтересовала Ваша странная манера подачи информации и странный способ воспринимать критику. Я пытаюсь понять, что тут происходит: то ли это тест Тьюринга, то ли троллинг, то ли Вы просто сформировали неудачную идею и еще менее неудачно подали ее. Сейчас склоняюсь к последнему варианту. Искренне желаю Вам достичь успеха в Вашей работе и пытаюсь Вам помочь в этом, но Вам надо научиться критически мыслить, прежде всего по отношению к самому себе.
Жаль, что вы цените такой способ развлечения больше, чем возможность посмотреть на веб-программирование с непривычной стороны и возможно понять что-то новое.
Я очень ценю возможность понять что-то новое. Сам с удовольствием сделал бы какую-то поделку вроде вашей, но считаю, что сначала нужно изучить имеющиеся решения, чтобы не изобретать велосипеды и вооружиться полезными наработками. Примерно пять лет назад я посмотрел на программирование с непривычной но желанной для меня стороны — ООП и метапрограммирование — перейдя на Python/Django. Сейчас я хочу посмотреть на веб-программирование с новой непривычной для меня стороны — попробовать в деле функциональное программирование с использованием Elixir и Phoenix. Считаю, что пока не испробую ФП, заниматься изобретениями слишком рано.
Это своеобразный способ, разделить код на части для более простого восприятия и вероятно требует переработки.
Понимаете, когда Вы помещаете весь код в строку, Вы создаете большие трудности:
1. Редактор не подсвечивает такой код, он становится труден для восприятия.
2. Анализатор не предупреждает об ошибках.
3. Дебажить такой код — это ад.
С таким кодом крайне сложно работать. Это плохой стиль. Так нельзя делать даже временно, такие идея вообще не должны быть в голове, потому что это десять шагов назад во всех технологиях программирования. А если в выбранном Вами языке недостаточно развито метапрограммирование — Вам следует выбрать другой язык, и не лепить из PHP то, для чего он не подходит. Или записывайтесь в core-разработчики PHP и улучшайте его изнутри.
if (at('0 23'))
Магические числа — это плохо. Что это такое? Ноль часов двадцать три минуты? Совершенно непонятно, как это работает.ellrion
30.10.2016 14:34Упаси нас все боги от такого core разработчика) Человек прибывает в своем мирке. Он сам не понимает что не предлагает ничего нового. И смена языка ему ничем не поможет. Хотя ему с его тягой к KISS (хотя я считаю, что у него свое извращенное понятие этого принципа, но всё же) можно посоветовать разве что golang попробовать.
raacer
30.10.2016 14:44+1Ну почему же так категорично? Даже на текущем SKY можно что-то запилить :) И наверняка могут появиться последователи. Посмотрите как там клёво можно таблички перетаскивать и поля сортировать, и код прямо в браузере редактировать. А как генератор странички шлёпает — сказка! Наверняка найдутся поклонники такого подхода. Как минимум в каком-то своем узком круге последователей и под узкий круг задач он вполне может достичь успеха и что-то творить. Чего ему не занимать — так это упорства. Вот попробуйте запилить подобную штуку! Думаю, у большинства не хватит мотивации ))) Я вот маленькое приложение для Django выложил — и то задолбался его поддерживать )
coresky
30.10.2016 17:43>Редактор не подсвечивает такой код
мне так, в то время было удобней… и я писал выше, я согласен — нужно переработать
>Анализатор не предупреждает об ошибках
неверно. ошибки внутри eval() возникают, с этим нет проблем
>Дебажить такой код — это ад
diff — работает, его не надо дебажить, я уже делал миллион запусков-тестов. Еще раз: error_handler работает внутри eval.
>давайте из архива из видео посмотрим
Файл называется cron.php, значит как-то связан с кроном…
вверху: define('START', 'cron');
не defined, а define — определение константы, значит это консольный скрипт для cron-задач, точка входа.
есть такой код: lsql("+select 'test'"), значит это просто пример организации cron-задач.
at с англ. переводится как «во время»…
>Ноль часов двадцать три минуты?
верно.
Функция at() — полная эмуляция синтаксиса крон. Можно упаковать много крон-задач в один файл.
Значит скрипт должен запускаться каждую секунду…
Но плохо может быть то, что сбой одной задачи приведет к сбою остальных, такой подход нетехнологичен. Однако, есть ряд задач, когда не очень важен 100% запуск крон-задач или вы сильно уверены, что сбоя не будет, если это например запрос:
lsql(«delete from visitors where dt_l + $s_clear < now()»);
просто «чистка» таблицы сессий.
К тому же никто не запрещал, выносить крон-задачи в отдельный файл, как например в том же архиве файл c_summer.php. префикс c_ — крон-задача.
Что же тут плохого или непонятного?
Это все MetaDone, вы бы могли и сами понять, даже без документации, если бы не были настроенны на троллинг.MetaDone
30.10.2016 18:04если у вас там типа планировщик, возьмите за образец https://laravel.com/docs/5.3/scheduling
сравните сами и поймете что у вас все просто коряво. скажите, чем ваша реализация лучше той, что по ссылке?coresky
30.10.2016 20:18-2Вы мне дали ссылку, просто Клондайк для антирекламы ларавел, если я не ошибаюсь…
Про namespace я молчу.
Начну с того, что в примере по ссылке «подтягивается» 3 файла, а сколько они в свою очередь «подтягивают» я даже не смотрел…
В SKY «подтягивается» один require 'main/conf.php', а он в свою очередь еще один require 'sky.php';
КПИ (код повторного использ.) для работы с DB лучше объединить с другим кодом, который в ларавел разделен. В этом нет смысла, нормально определить «код первого крыла» который выполняется при всех точках входа, включая CRON. Это маленький ньюанс, но все состоит из маленьких ньюансов. Если вы знаете ларавел, и вам нужен крон, дополнительно вам нужно открыть страницу (что вы дали выше) чтобы изучить документацию для Illuminate\Console\Scheduling\Schedule
В SKY не нужно ничего изучать для добавления крон-задачи.
Обычно крон-задачи простые, например очистка сессий и нужно выполнить один только запрос. В SKY я пишу
if (at('0 23')) lsql(«delete from visitors where dt_l + $s_clear < now()»);
просто в глобальной области видимости, нет никакой опасности переопределить глобальные переменные, у ларавел делается класс, что лишнее. В SKY нужно только знать SQL той БД с которой работаем, у ларавел опять таки вплюс нужно изучить класс, чтобы написать DB::table('recent_users')->delete();
разработчик пишет: When using the scheduler, only a single Cron entry is needed on your server. т.е. нужен только один файл крон нужен, а запускать будем каждую минуту… Это неверное утверждение, если крон-задача очень важна, она может невыполниться ввиду ошибок в другой задаче, поэтому желательно иметь возможность делать несколько файлов крон. ОК, сделаем еще один файл, наперекор автору ларавел, но нет метода ->now() в Illuminate\Console\Scheduling\Schedule
Тогда применим, например ->hourly();
Это «костыльно».
Вот это:
// Run hourly from 8 AM to 5 PM on weekdays…
$schedule->command('foo')->weekdays()->hourly()->timezone('America/Chicago')->between('8:00', '17:00');
выглядит сложно и некрасиво. Я сторонник чтобы был один способ ->cron('* * * * * *'); список альтернативных методов, как ->hourly(); никчему.
В SKY можно, вложено использовать функцию at()
if (at('0 1,2,12')) {
if (at('3')) { }
}
Чтобы добиться времен запуска, для которых прямой синтаксис крон невозможен.
Самое интересное, это явный бред просто, или я что-то не понял? Только спокойно, мне реально интересно…
Какой смысл вообще в ->skip() и ->when() методах, если можно просто написать:
// code of the when
$rule =…
if ($rule) {
// code of the cron-task
…
Тоже самое касается хуков ->before() и ->after()
Прошу Вас давайте разберемся…
С ларавел кроном, вроде как мне все понятно… Неужели я что-то неправильно понимаю? Или все-таки Клондайк? Спасибо.lair
30.10.2016 20:53Про namespace я молчу.
К сожалению, не молчите. Так что же плохого в
namespace?
КПИ (код повторного использ.) для работы с DB лучше объединить с другим кодом, который в ларавел разделен
Почему лучше?
В SKY не нужно ничего изучать для добавления крон-задачи.
Это банально неправда. Нужно найти, где и как это задаются задачи, и разобраться с синтаксисом.
В SKY нужно только знать SQL той БД с которой работаем, у ларавел опять таки вплюс нужно изучить класс, чтобы написать DB::table('recent_users')->delete();
Ну так знать классы фреймворка дешевле, чем знать вариации SQL для всех БД.
Это неверное утверждение, если крон-задача очень важна, она может невыполниться ввиду ошибок в другой задаче
С чего вы это взяли? Это в вашей реализации так, но не обязательно так в других.
нет метода ->now()
Логично, что нет, потому что не бывает задачи по расписанию "сейчас" (костыли в рассмотрение не берем).
Я сторонник чтобы был один способ ->cron(' '); список альтернативных методов, как ->hourly(); никчему.
Ага, давайте заставим всех, кто имеет дело с этим кодом, учить крон-нотацию. Зачем? Написать Hourly намного проще, и это дешевле в дальнейшей поддержке.
Какой смысл вообще в ->skip() и ->when() методах
Разделение действия и условия.
если можно просто написать
if ($rule)Можно. Но теперь вам придется для каждого действия написать свой код, хотя можно было бы обойтись одним действием и разными условиями.
Условия и хуки — это способ декомпоновать код на простые легко используемые структурные единицы. Ну и заодно еще читаемость повышает.
MetaDone
30.10.2016 21:03весело, из вашего комментария очевидно что крупнее сайта-визитки или бложика вы не делали
Про namespace я молчу.
я вам писал про это, ваши аргументы против пространств имен не тянут на годные
КПИ (код повторного использ.) для работы с DB лучше объединить с другим кодом, который в ларавел разделен.
бред — зачем смешивать разные зоны ответственности? Если к примеру я буду парсить посты из разных источников, то зачем мне в куски, которые получают информацию с сайта-источника, примешивать сохранение постов в базу? Получение отдельно, сохранение отдельно (первый пришедший в голову пример, таких можно кучу придумать)
дополнительно вам нужно открыть страницу (что вы дали выше) чтобы изучить документацию
Ну… в laravel есть что открывать, и самое главное — почти на любой вопрос я могу найти ответ, как и на любом популярном фреймворке. У вас даже комментариев нет, не то что документации.
В SKY не нужно ничего изучать для добавления крон-задачи.
вам — не нужно, остальным ваши извращенные идеи при создании этого не так очевидны.
В SKY нужно только знать SQL той БД с которой работаем, у ларавел опять таки вплюс нужно изучить класс, чтобы написать DB::table('recent_users')->delete();
Покажите пожалуйста пример, как в вашем чуде организовать email-рассылку на 20000 писем через mandrill, да еще так чтоб она не длилась часов 8.
ОК, сделаем еще один файл, наперекор автору ларавел, но нет метода ->now()
вы в курсе что можно просто выполнить консольную команду?
$schedule->command('foo')->weekdays()->hourly()->timezone('America/Chicago')->between('8:00', '17:00');
выглядит сложно и некрасиво.
и как оно будет выглядеть в sky?
нет никакой опасности переопределить глобальные переменные, у ларавел делается класс, что лишнее
представьте, что у вас 100-150 различных консольных команд. С вашим подходом все превратится в нечитаемую мешанину.
Тоже самое касается хуков ->before() и ->after()
Запустили плановую рассылку — как закончилась отправили письмо админу
Вы мне дали ссылку, просто Клондайк для антирекламы ларавел, если я не ошибаюсь…
ошибаетесь, как всегда, потому что судя по всему не сталкивались с хотя бы немного сложными задачами с использованием вашего чудо-фреймворка. И если вас смущает количество подтягиваемых файлов и так печетесь о быстродействии, то смотрите сюда — https://docs.phalconphp.com/ru/latest/reference/cli.html
ellrion
30.10.2016 21:54+3Неужели я что-то неправильно понимаю?
Вы снова ВСЁ неправильно понимаете))
Я пропущу ваши первые тезисы о неймспейсах, числе файлов, "простоте" вашего кода и необходимости читать документацию. Ибо вам уже дали пару ответов. Скажу лишь что я рад что в Ларе код хранится по PSR-4, что каждому классу отведен свой файл а не свалено всё в единую огромную дурнопахнущую кучу вашего "первого крыла" (как же вы достали со своими самопридуманными терминами) А еще замечу что вы похоже не знаете как работает кеширование кода в php. И что Лара умеет собирать свой код ядра в один файл. Но при этом исходники приятно разложены.
Далее:
крон-задачи простые, например очистка сессий и нужно выполнить один только запрос.
Это не так. То что вы всю свою "карьеру" не писали ничего сложнее блога это ваш юзкейс.
Обычно это отдельная, зачастую ресурсоемкая задача. С достаточно большим временем выполнения. И не тривиальным кодом. (Отправка писем по запланированной рассылке, агрегация данных, подготовка отчетов). В ларавель они красиво вынесены в консольные команды. Но и что то простое можно сделать просто без класса а описав действия в замыкании.
Ваш планировщик — дно неприменимое в продакшене на сколь нибудь серьезном проекте. Я не хочу что бы одни мои задачи зависели от выполнения других.И в ларе представляешь они не зависят. Ибо тот скрипт который прописывается в крон он запускает запланированные задачи прописанные в нем изолированно. Я не хочу писать в crontab новые строки (тем более что доступа у меня может и не быть и делать это надо через админа). А блокировка от двойного запуска долгой задачи? а запуск с особыми условиями среды, часового пояса, ежеминутно но в определенный день или промежуток времени… И еще десяток юзкейсов которые дает Лара и о которых вы в силу вашего скромного опыта даже не задумываетесь. А еще я хочу иметь возможность запустить форсированно (не по крону) какое то задание, например если ночью в момент нужной задачи лег ДЦ, или еще почему то. (Вот для этого в ларе и обернуты они все в классы консольные команды)
if (at('0 23')) lsql(«delete from visitors where dt_l + $s_clear < now()»);
просто в глобальной области видимости, нет никакой опасности переопределить глобальные переменные, у ларавел делается класс, что лишнее
$schedule->call(function () { DB::table('visitors')->where(...)->delete(); })->dailyAt('23:00');
$schedule->command('foo')->weekdays()->hourly()->timezone('America/Chicago')->between('8:00', '17:00');
выглядит сложно и некрасиво.Ага ну давай повтори это же условие "красиво" в своей системе. Особенно between и timezone. А учитывая что я изучил твой недокод. Сразу отвечу, что ты не повторишь никак.
разработчик пишет: When using the scheduler, only a single Cron entry is needed on your server. т.е. нужен только один файл крон нужен, а запускать будем каждую минуту… Это неверное утверждение, если крон-задача очень важна, она может невыполниться ввиду ошибок в другой задаче, поэтому желательно иметь возможность делать несколько файлов крон.
Это у вас так, а вот в Ларе они запускаются изолированно, представляете до чего программисты додумались. Именно что бы время выполнения или ошибки в одних задачах не влияли на другие. И всё это разруливает 1 скрипт. Вот это да!
Или все-таки Клондайк?
Да кландайк, но не система планировщика Лары, а вот этот ваш комментарий. Он идеально показывает что вы некомпетентный, неуч и к тому же глупы. (Да я "скатился" до грубости, но пора уже огласить правду)
coresky
30.10.2016 23:08Я ошибся один раз, присоединив хук ларавел к ->call() вместо ->command() увидев в первый раз новую для меня документацию и все — надо орать?! Вы представляете какая «каша» у меня в голове после 3 дней здесь общения с вами всеми на хабре, еще и с непривычки? А сколько раз мне писали здесь, явную «пургу» из-за невнимательности или по другим причинам? и я никого не обзывал. А я был даже искусственным интеллектом, проводящим тест тьюринга. Хотите, чтобы я закончил писать комментарии здесь? Да пожалуйста.
lair
30.10.2016 23:28+1Я ошибся один раз, присоединив хук ларавел к ->call() вместо ->command() увидев в первый раз новую для меня документацию
Ну то есть вы раньше в laravel не разбирались? И в том, как в других системах устроены фоновые/рекуррентные задачи — тоже?
ellrion
31.10.2016 07:49+1Эм, из всех ошибок на которые я указал ты увидел только call? Чувак, с тобой точно что то не так. Самая вопиющая ошибка была где ты не понял как вообще работает планировщик в ларе и написал бред
разработчик пишет: When using the scheduler, only a single Cron entry is needed on your server. т.е. нужен только один файл крон нужен, а запускать будем каждую минуту… Это неверное утверждение, если крон-задача очень важна, она может невыполниться ввиду ошибок в другой задаче, поэтому желательно иметь возможность делать несколько файлов крон. ОК, сделаем еще один файл, ...
Ну и тон сообщения это радостно презрительное улюлюкание. "Кландайк!", "антиреклама". Мне тут в одном из комментариев посоветовали уважать ваш труд. Так вот, нет. Вы не уважаете труд тысяч разработчиков.
ButscH
30.10.2016 23:00
Обычно крон-задачи простые, например очистка сессий и нужно выполнить один только запрос
Ну понятно что у Вас то они обычно простые, сложные не впишутся концепцию проекта SKY, т.к. они требуют много строк кода, а здесь то «clear cloud»
А вот рассмотрим реальные cron задачи:
— Синхронизация списка пользователей сайта и AD корпоративной сети
— Синхронизация календарей сотрудников из MS Exchange с корпоративным порталом.
— Ежедневная рассылка уведомлений по электронной почте
— Обновление поискового индекса на сайте
— Генерация отчетов
Каждая из этих задач требует выполнить не один SQL запрос, вдобавок нужно сформировать и т.д. и т.п. Боюсь ваш крон файл не выдержит такое, так же как и код.
Кстати, вы же знаете, что крон задачи можно добавлять напрямую в crontab, это сэкономит лишние!!! килобайты!!! Вдумайтесь, зачем ваш файлcron.php, если можно, например,crontab -eи там добавить нужные задачи.
* * * * * /var/www/sky-project/cron.php session:clear 0 0 0 0 * /var/www/sky-project/cron.php delete:project
Функцияatкостыль!
дополнительно вам нужно открыть страницу (что вы дали выше) чтобы изучить документацию
Я так понимаю, вы стали программировать не заглядывая в документацию, да и видимо так со всем остальным. Дома у вас инструментов также никаких нет, только потому, что есть камень, самый простой инструмент и с его помощью можно сделать все, забить гвоздь, развести огонь ну и инструкция не нужна! Зачем усложнять жизнь?
Так вот правда в том, что инструменты, также как и ваш, рождаются тогда, когда его автор считает, что он необходим. И чем больше людей используют инструмент, чем он полезнее. Давайте обратимся к статистике: https://packagist.org/explore/popular и посмотрим какие сейчас инструменты нужны всем.
Неужели я что-то неправильно понимаю?
Вам бы идти в демагоги, а не в программисты.
Ну и напоследок: я бы советовал взять, к примеру, SugarCRM. Почему его? А потому что он монструозный и код открыт и там вы в полной мере окунетесь в мир глобальных переменных, php4, легаси кода и т.д. Изучая его вы сможете в полной мере ощутить себя в шкуре тех разработчиков, которым вы пытаете впарить свою систему. После того, как вы во все это окунетесь, задумайтесь над тем, насколько можно сократить код по идеологии SKY Project
P.s. Вы же, надеюсь, понимаете, что как только ваш КПИ (код повторного использ.) по возможностям отчасти сравняется с Laravel, то ему потребуется документация? Или вы думаете, что весь код из Laravel можно сократить до 3-х функций? И отсюда у вас возникает вопрос: раз даже я, разработчик, который решил изменить мир к лучшему не смог изучить код Laravel, то код от лукавого и не нужен, не то что мой, понятный мне без документации, а значит всем остальным и в этом его преимущество.
P.p.s У меня в проекте 276 файлов с классами покрытыми phpDoc + 60 view файлов (и это еще не большой проект, без учета сторонних библиотек), как думаете, насколько это можно сократить?
lair
30.10.2016 18:09+2Анализатор не предупреждает об ошибках
неверно. ошибки внутри eval() возникают, с этим нет проблемВерно-верно. "Ошибки возникают" и "анализатор предупреждает об ошибках" — это две очень большие разницы.
diff — работает, его не надо дебажить, я уже делал миллион запусков-тестов.
Любой код в какой-то момент приходится дебажить. Не надо это делать только с кодом, который никогда не запускается. А учитывая, что юнит-тестов у вас нет...
Файл называется cron.php, значит как-то связан с кроном
Угу. И весь этот велосипед можно заменить на готовое решение. В частности, вместо
if (at('0 23')) lsql("delete from visitors where dt_l + $s_clear < now()");было быRecurringJob.AddOrUpdate(CleanUpOldVisitors, Cron.Daily);, не было бы никакого запуска каждую секунду (который, на самом деле, не нужен, а иногда и опасен), нормальное логирование/мониторинг/UI и так далее.
raacer
30.10.2016 18:21ошибки внутри eval() возникают, с этим нет проблем
Это не предупреждение анализатора кода в IDE, это ошибки времени выполнения, которые неизвестно когда и при каких обстоятельствах вылезут и какой беды наделают.coresky
30.10.2016 21:47-2Я написал eval('1 / 0;'); и вот run-time ошибка в SKY Framework, см. http://ru.coresky.net/err2.png у меня уже нет возможности разместить скриншот прямо здесь ввиду низкой кармы.
>Ну так знать классы фреймворка дешевле, чем знать вариации SQL для всех БД.
Я думаю надо знать и SQL БД и ORM иначе чел. не программист. Если чел. знает только ORM, больше чем сайт-визитку он не напишет на ларавел.
>С чего вы это взяли? Это в вашей реализации так, но не обязательно так в других.
Да с того, что PHP скрипт выполняется в 1 поток и если неважная задача остановит работу скрипта например по фатальной ошибке, то важная крон-задача может вообще не выполнится. Это вопрос не SKY, а выполнения скрипта в 1 поток (процесс на UNIX машинах)
>И весь этот велосипед можно заменить…
У меня впечатление, что Вы намерено на черное говорите белое и наоборот. У меня противоположное мнение, у ларавел куча лишнего, в SKY все просто и есть все необходимоеraacer
30.10.2016 22:18Я написал eval('1 / 0;'); и вот run-time ошибка
Это ошибка времени выполнения, а я говорю о предупреждениях анализатора кода еще до запуска программы и выполнения этой конкретной строки. В чем Вы пишите программы? Far конечно вряд ли покажется какие-то предупреждения. Попробуйте PyCharm, например. Или может какая-то консольная утилита есть.
BoShurik
30.10.2016 22:39function test() { sleep(5); $a = 1 + 1 // Missing ; return $a; } echo "Start\n"; echo test() . "\n"; echo "Stop\n";
function test() { sleep(5); $a = eval('1 + 1'); // Missing ; return $a; } echo "Start\n"; echo test() . "\n"; echo "Stop\n";
Первый вариант сразу вернет
PHP Parse error(при чем не обязательно даже вызывать проблемную функцию)
Второй вариант — только через 5 секунд.raacer
30.10.2016 22:46Кстати да, забыл о самом главном — о парсере самого интерпретатора :) Тогда всё еще печальнее.
lair
30.10.2016 23:33Я написал eval('1 / 0;'); и вот run-time ошибка в SKY Framework,
Рантайм. А анализатор/компилятор дает ошибки раньше.
Я думаю надо знать и SQL БД и ORM иначе чел. не программист. Если чел. знает только ORM, больше чем сайт-визитку он не напишет на ларавел.
Знать все в деталях невозможно. Для общих задач знать ORM эффективнее.
(скажите, а вы, конечно, знаете все используемые вами компоненты хотя бы на один уровень вниз? и да, какие ORM вы знаете?)
Да с того, что PHP скрипт выполняется в 1 поток
Даже я слышал про
pthreads. Так что нет.
У меня впечатление, что Вы намерено на черное говорите белое и наоборот. У меня противоположное мнение, у ларавел куча лишнего, в SKY все просто и есть все необходимое
Необходимое кому? Я уж не говорю, что вопрос не только "что есть", но и "как оно реализовано". Пока что все разобранные примеры показывают, что реализовано плохо.
coresky
31.10.2016 12:33-1pthread не полноценно рабочая вещь
http://php.net/manual/ru/pthreads.requirements.php
pthreads requires a build of PHP with ZTS (Zend Thread Safety) enabled ( --enable-maintainer-zts or --enable-zts on Windows )
>представляете до чего программисты додумались
представляюlair
31.10.2016 12:42pthread не полноценно рабочая вещь
Ну, во-первых, не "неполноценно", а "не для каждого PHP", но кого это останавливает?
А во-вторых, это, в общем-то, не единственный вариант — учитывая, что запуск идет из консоли, там можно почти что угодно наворотить (собственно, Laravel
pthreadsне использует, а использует, он, похоже, просто отдельные процессы).coresky
31.10.2016 15:29-2>но кого это останавливает?
я уже понял, что никого…
представить ситуацию, что у вас не работает на сервере phtread элементарно, когда вам это внесло существенные сложности…
Вы мне будете «втирать» что ее пофиксить легче, чем просто дать возможность записать 2 строчки в кроне, вместо одной и что ситуация, когда у вас есть возможность записать только одну строчку в кроне (а две никак) чаще чем, когда не работает pthread? Или наваять какие-то исполняемые файлы, которые фокают процесс, легче чем 2 строчки просто записать?
Это был риторический вопрос. Отвечать не надо. Всем спасибо.lair
31.10.2016 15:37Или наваять какие-то исполняемые файлы, которые фокают процесс, легче чем 2 строчки просто записать?
Конечно, легче. Для записи строчек в крон нужен доступ к серверу, а для того, чтобы использовать
ProcessизSymphonyдостаточно взятьSymphony.
(я молчу про то, что есть решения — не на PHP, правда — которые вообще без крона работают)
Ну и на самом деле, устроено-то все ровно наоборот: Laravel-евский планировщик так написан, что ему достаточно одной строчки в кроне (и у него разумные системные требования). Разработчику для этого ничего специально делать не надо. Вы зачем-то стали утверждать, что так работать не будет, падение одной задачи приведет к падению всего планировщика.
О том, что проще — речи, на самом деле, не шло.
michael_vostrikov
31.10.2016 16:24+1Вы так и не поняли, похоже. В указанном планировщике есть возможность сделать несколько задач. Одна строчка в кроне запускает не задачу, а планировщик. Чтобы падение одной задачи не влияло на другие, они выделяются в отдельные команды. Каждая команда запускается в отдельном процессе. Форкать вручную ничего не надо, планировщик запускает процессы сам. Пользователю нужно указать только одну строчку на каждую команду. 2 команды значит 2 строчки. Pthreads и его ограничения здесь ни при чем, вам просто указали, что количество способов запустить в PHP 2 задачи одновременно больше 0.
coresky
01.11.2016 20:01-3Ваши посты корректны, поэтому отвечу… Неужели я так плохо отвечал, что непонятно и вы об этом пишете? Похоже симптом анекдота (ищите в этой теме) про колбасу и яйца значителен на хабре, когда дело касается общения программистов.
Мне здесь написали, что Pthreads решает задачу параллелелизма для крон в ларавел. Я сказал что «врядли». Похоже изобретатель ларавел написал исполняемый файл (для каждой ОС отдельный), чтобы решать эту задачу. «Фокает» он, а не пользователь ларавел.
Не
>2 строчки
а две Closore
А вы можете представить, что вы решаете задачу которую решил разработчик ларавел, как оно сделано? Крон раз в минуту запускает исполн. файл (условно artisan.exe), который запустил крон-файл пользователя, создал реестр запусков и потом в отдельном потоке запуcкает наши Closure-крон-задачи пользователя (или примерно так). Все довольно сложно только ради того чтобы все задачи были в одном файле и для них нужна была одна строчка в крон (раз в минуту). Вся эта сложность и надежность artisan.exe здешних менеджеров проектов «не парит», и они правы (без сарказма). artisan.exe в авторитете а ларавел бесплатно доступен.lair
01.11.2016 20:31Мне здесь написали, что Pthreads решает задачу параллелелизма для крон в ларавел.
Кто?
Похоже изобретатель ларавел написал исполняемый файл (для каждой ОС отдельный), чтобы решать эту задачу.
Тоже нет. И из доки это очевидно.
Все довольно сложно
Что сложного-то?
(повторюсь, я бы предпочел и без крона обойтись, но это не везде и не всегда работает)
MetaDone
01.11.2016 21:32+1вы бы повнимательнее код посмотрели, да документацию глянули вместо того чтоб демагогию разводить.
Суть простая — вместо того, чтобы на каждую нужную задачу не приходилось редактировать crontab, туда пишется только задание для планировщика laravel, а внутренние команды он сам разруливает по тем же правилам что и крон. За параллельное выполнение там отвечает компонент Symfony Process.
И все сводится к тому что если время настало — запускается консольная команда, которая уже непосредственно делает что-то полезное, и для редактирования периодичности ее исполнения не придется подключаться по ssh и редактировать crontab + все расписание видно в коде.
Кстати у вас нельзя задать расписание к примеру только на рабочие дни с 9 до 18:00, к тому же все выполняется последовательно, что на реальных задачах не позволит использовать ваше чудо-решение.AlexTest
03.11.2016 04:39А если совсем просто, то laravel использует компонент Symfony Process, который основан на proc_open. Этой PHP командой для каждого зарегистрированного задания (в терминах laravel — команды) запускается отдельный процесс PHP, в котором опять-таки отрабатывает код laravel, который наконец-то выполняет собственно код команды.
michael_vostrikov
02.11.2016 17:13+1Похоже изобретатель ларавел написал исполняемый файл (для каждой ОС отдельный)
Строка запуска «php /path/to/artisan schedule:run» намекает на то, что это PHP скрипт, а не бинарный файл. Соответвенно, он один для всех ОС. И он есть в исходниках фреймворка на github.
а две Closore
Closure это один из способов. In addition to scheduling Closure calls, you may also schedule Artisan commands and operating system commands.
Крон раз в минуту запускает исполн. файл (условно artisan.exe), который запустил крон-файл пользователя, создал реестр запусков и потом в отдельном потоке запуcкает наши Closure-крон-задачи пользователя (или примерно так). Все довольно сложно
Не знаю, почему вы так решили. Я с этим фреймворком не работал, но насколько я понял из документации, крон запускает скрипт планировщика, в планировщике запускается функция Kernel::schedule(), где написано расписание задач, нужные задачи запускаются. Closure выполняются в том же процессе, команды запускаются в отдельных процессах (не потоках). Все просто и логично.
Вся эта сложность и надежность artisan
проверена тысячами пользователей фреймворка в разных проектах.
ellrion
31.10.2016 12:44О вы снова на высоте!) Там не используется pthread))
Ну давайте попытайтесь еще.
ellrion
30.10.2016 10:10+1Тут большинство считает, что его слова адекватны. Качали мы уже всё. Нет спасибо такого нам не надо. Наш код проще. Аналогии конечно последнее дело, но никак не могу отделаться от мысли что автор настоятельно втирает всем булыжник вместо например Беретты.
Идейно тоже нет ничего нового. или напиши только чётко и без воды хоть один (лучше просто один) тезис что ты предложил.
michael_vostrikov
30.10.2016 11:22+1Скачал. Регистрации нет. Через админку пользователя добавить нельзя. Пароли хранятся в открытом виде. После логина ссылка «ROOT» в меню не работает, выводятся 2 ошибки, «Controller `c_user::` or method `default_c::c_user()` not exist» и «View file `view/_sample.php` not exist». Проверка доступа находится в представлениях. CMS часть не работает, как фреймворк систему использовать сложно, по причинам, уже описанным в других комментариях.
Код шаблона админки:
<?php defined('START') or die; # For Licence and Disclaimer of this code, see http://coresky.net/license $err = $out = $refresh = ''; $sky->head(); $top_html = '<!doctype html><html><head>' . ob_get_clean(); $top_html .= css(".active {background: #91d0c0 !important}") . '</head><body style="margin-top:0">'; define('zebra', 'return @$i++ % 2 ? \'bgcolor="#eee"\' : "";'); define('button', '<a href="?%2$s" class="admin-btn%3$s">%1$s</a>'); if (!$user->adm_allowed): echo 'Not permited'; elseif (2 == $user->auth): ...
Для сравнения, фреймворк Yii2.
Шаблон проекта ставится одной командой, многофункциональный компонент для работы с пользователями еще одной. После установки все работает. Из коробки есть UI в стиле Bootstrap и механизм управления любыми скриптами и стилями, меню, пагинация, многоязычность и многосайтовость. Проверка доступа находится в контроллерах. Шаблонов страницы можно иметь несколько для разных разделов и менять в рантайме.
Код основного шаблона страницы:
<?php /* @var $this \yii\web\View */ /* @var $content string */ use yii\helpers\Html; use yii\bootstrap\Nav; use yii\bootstrap\NavBar; use yii\widgets\Breadcrumbs; use frontend\assets\AppAsset; use common\widgets\Alert; AppAsset::register($this); ?> <?php $this->beginPage() ?> <!DOCTYPE html> <html lang="<?= Yii::$app->language ?>"> <head> <meta charset="<?= Yii::$app->charset ?>"> <meta name="viewport" content="width=device-width, initial-scale=1"> <?= Html::csrfMetaTags() ?> <title><?= Html::encode($this->title) ?></title> <?php $this->head() ?> </head> <body> ...
VolCh
30.10.2016 12:54+3Новое и полезное: веб-приложение разрабатывается намного проще легче и быстрее чем в вашем фреймворк…
В современном мире скорость первоначальной разработки во многих случаях не является определяющим фактором при выборе стека технологий. Определяющим всё чаще является скорость внесения изменений при изменении требований, скорость исправления ошибок, скорость добавления новой функциональности, скорость горизонтального масштабирования в конце-концов. Как у вашего решения с этим?
lair
30.10.2016 14:02+2Вы считаете ваши слова адекватные?
Да, я считаю, что мои слова — адекватные.
Я предложил очень много нового
Что конкретно, один пример хотя бы?
Новое и полезное: веб-приложение разрабатывается намного проще легче и быстрее чем в вашем фреймворк… это просто небо и земля…
Вам правда надо перестать гадать на юзерпике. Вы даже не знаете, каким фреймворком я пользуюсь (если вообще пользуюсь каким-то), но уже делаете какие-то утверждения о нем.
Помните, я приводил пример из вашего кода?
if ('delete' == $PVAL): sql("delete from $me where id=$WVAL"); jump(me); //... elseif ('new' == $PVAL || 'edit' == $PVAL): $new = !$WVAL or is_numeric($WVAL) or die;
Так вот, приличный современный фреймворк позволяет сделать это вот так:
Delete(int id) _repository.DeleteById(id) return View() [AutoValidate] Edit(User user) _repository.InsertOrUpdate(user) return View()
(более того, если становится понятно, что этот бойлерплейт повторяется без изменений, его можно просто выкинуть и заменить на генеричное поведение, другое дело, что в реальной жизни это слишком редкий сценарий)
Никаких
if, никаких магических строк, никаких ручных проверок типа (и вообще ручной валидации).
Это проще, это понятнее, это дешевле в поддержке.
TimsTims
29.10.2016 18:27+1> На этом сайте декларируется теория о чрезвычайной важности создания кода наивысшего качества, идеального кода.
Омг омг омг. Начали за здравие, а потом:
> Ядро SKY. это повторно-используемый код для создания веб-сайтов
И это уже не говоря о том, что теперь чтобы сделать быстренько сайт-визитку, тебе надо написать код наивысшего качества, либо взять чей-то уже готовый код и выложить копию уже существующего сайта, слизанного со SKY. Никакого творчества, просто рутина! А через 20 лет уже не останется людей, умеющих писать новый ИДЕАЛЬНЫЙ КОД, т.к. все привыкли копировать весь идеальный код со skynet, и весь веб в будущем (в глазах автора) будет выглядеть как одинаковые странички, с одинаковым фреймворком, решающий одинаковые задачи, и даже возможно с одинаковым оформлением. /сарказм офф.
Судя по всему, у это еще один пост очень молодого, полного энтузиазма человека, бьющего себя в грудь, что изобрел лекарство от рака, и кичащий, что он знает, что надо людям, и убеждает в этом других(в начале осени была похожая тема, где другой автор поднял дикий срач, где он вышел из себя, карма опустилась ниже 50, а потом начались ответы с фейков). Не нужно его в этом винить, я и сам таким был, но надо как можно раньше проснуться и начать думать более реально.coresky
29.10.2016 18:37+1для создания кода наивысшего качества взята веб-разработка это просто популярная область которую удобно взять как базис.
вы не угадали, я старше многих из вас и отвечать вам грубостью на грубость не собираюсь. Если где я и ответил с сарказмом, так просто ради смеха… смешно было.TimsTims
29.10.2016 21:46> отвечать вам грубостью на грубость не собираюсь
Простите, если обидел, но прямую грубость в вашу сторону я не выражал.
> вы не угадали, я старше многих из вас
порыв как у молодого бойца. не угадал, что ж
raacer
29.10.2016 21:49+1Сколько лет Вы программируете профессионально, до 8 и более часов в день?
coresky
29.10.2016 22:17-1Я не собираюсь вас уговаривать принять SKY, аргументируя это своим опытом, это считаю неправильным. Но опыт больше вашего однозначно, если вы 81 года рождения.
>Простите, если обидел, но прямую грубость в вашу сторону я не выражал.
я имел ввиду не вас конкретно, а любого из комментаторов. Есть некоторые позволяющие себе лишнее.raacer
29.10.2016 22:25И все же, Вы можете прямо ответить на вопрос? Вы ведь не девушка, чтобы свой возраст скрывать? Думаю, логично описать свой опыт читателям, чтобы дать им представление о том, сколько Вы могли уже повидать в своей профессиональной жизни. Ответьте пожалуйста.
И еще, скажите пожалуйста, на каких ЯП вы профессионально программировали, и какие фреймвёрки использовали профессионально как минимум в трех проектах.
lair
29.10.2016 22:32Но опыт больше вашего однозначно, если вы 81 года рождения.
А можно, пожалуйста, в конкретных цифрах?
raacer
29.10.2016 22:34Я не собираюсь вас уговаривать принять SKY
Принять можно религию, или точку зрения. А фреймёрки и парадигмы — это инструменты. Их выбирают исходя из задач.
ellrion
29.10.2016 19:07+3Но можно условно назвать идеальным код, который проанализирован огромным количеством программистов и активные итерации по совершенствованию которого, не прекращаются никогда.
Автор, по твоему собственному определению код современных фреймворков например laravel идеален. Более тысячи контребьютеров. Изменения вносятся ежедневно. А к тому же используются компоненты над которыми работали еще тысячи. Что ты на это скажешь?
ButscH
30.10.2016 01:29+2Я не верю в происходящее. Это тест Тьюринга? Если да, то этот бот смог убедить кучу народа в том, что он настоящий человек.
Здесь либо программиста переклинило от того, что у него была куча кода со времен php4 и он не смог пережить его тотальное устаревание. Также я подозреваю, что человек за всю жизнь сделал всего один проект и его название SKY. Если вспомнить свой путь создания нескольких проектов для широкой публики, я могу с уверенностю сказать, что код проекта SKY будет занимать меньше места, чем список хотелок, которых не будет хватать окружающим.
Скажите, вы можете дать вразумительное объяснение, почему чтобы сделать простой запрос к БД, код в вашем framework выглядит так:
$db->$mysql->select( … )
Нет, не можете? а зачем тогда так пишите? Многие, могут поспорить сейчас и попытаться дать объяснение, но после очередных вопросов, они не смогут дать вразумительный ответ или дадут, но после следующих – не смогут.
Я так понимаю, что разработчик не знает про то, что не все используют mysql, sqlite, pgsql, и Query Builder позволяет на выходе получить запрос под конкретную БД с учетом ее особенностей.
Если происходит сабмит формы с 100 полями, то QB позаботится об экранировании данных.
Ах этот лаконичный SQL запрос… когда в нем начинают появляться условия :) Или мы не хотим соблюдать последовательность при проверке условий…
Приведу пример из SugarCRM, когда они пошли по похожему пути https://github.com/butschster/sugarcrm_dev/blob/master/data/SugarBean.php#L2883 Казалось бы, что может быть проще, чем выполнить SQL запрос и зачем только нужен этот Query Builder?!
// Пример высосан из пальца и код упрощен по максимуму $query = DB::table('users'); if ($groupByTotalLogins) { // Здесь мы можем не соблюсти последовательность, но на выходе получим валидный SQL $query->join('logins_history')->....; $query->groupBy(...); $query->select(...) } if ($joinProfile) $query->join(...); if (!$withDeleted) $query->where('deleted', 0); if ($onlyId) $query->select('id'); if (//condition) { $query->orWhere('field', '>', 10); } // Остальные 100 условий
Ну и чистый лаконичный SQL
$table = 'users'; $select = $onlyId ? 'id' : '*'; $where = ''; $groupBy = ''; $orderBy = ''; if ($joinProfile) { $table .= ' join profile ...'; } if ($groupByTotalLogins) { $table .= ' join logins_history ...'; $select .= ' count(logins_history.*) as total_logins'; $groupBy .= '....' } if (!$withDeleted) { $where .= 'deleted = 0'; } if (//condition) { $where .= !empty($where) ? ' OR' : ' '; $where .= ' filed > 10 ' } if(empty($where)) { $where .= !empty($where) ? ' AND' : ' '; $where = '1=1'; } ... // Вспомним что у where еще могут быть группировки условий... $query = "select {$select} from {$table} where {$where}"; if(!empty($groupBy)) { $query .= "group by {$groupBy}"; } if(!empty($orderBy )) { $query .= "order by {$orderBy}"; }
В чем смысл приложения, в котором своего функционала всего с гулькин нос и банально он не будет корректно работать со сторонними библиотеками, которые по мнению автора зло, но так необходимы остальным разработчикам, которые ценят свое время и хотят использовать проверенные сообществом решения и покрытые тестами.
Хотелось бы пару строк от автора о том, как расширять ядро не затрагивая при этом сам код?
Подведем итог: с 2012 года автор смог осилить написание около 100 кб устаревшего к настоящему времени кода. Пакет «FORUM.SKY» появится тогда, когда автор сможет уместить идеальный всеохватывающий код в 800 строк. Остальные пакеты появятся тогда же.coresky
30.10.2016 11:03-1Я не понял смысл приведенных вами примеров кода. Старый без QB не рабочий? Если я правильно понял, вы говорите: «да он же некрасив»… Странная логика, наваяем QB, чтобы код был красив…
Нет… сейчас, вы начнете оправдываться и говорить: я каждый день меняю БД в одном и том же проекте. В основном работает MySQL, а по пятницам, я запускаю сайт на PostgreSQL, QB позволяет мне просто отредактировать конфигурацию приложения.
Я при всем желании не могу понять, здешних комментаторов, похожих на вас, которые просто троллят авторов и получают при этом удовольствие?
>Я так понимаю, что разработчик не знает про то, что не все используют mysql
Вы вправду так думаете? А мне кажется, что вы просто не сообразили, как более тонко потроллить.
Давайте-ка все вместе покритикуем автора… Можно писать что попало. У всех нас цель одна — автор, и те, кто в моем лагере будут лояльны ко мне. Главное устроить вкусный цирк, удовольствие при этом получат все… Ура!!! Вперед в бой…
Я неутомимо буду прояснять ради тех кто читает и думает, но не участвует в цирке. Итак, во-первых, в этой статье четко, русским языком написано, «ORM не нужен, по крайней мере, как базовое средство разработки...». Тоже относится к QB. Только код, который требуется для 70% реальных сайтов в Интернете (потенциально может заменить их код), должен быть включен в «чистое облако». Не базовые средства разработки, могут присутствовать в коде 3 крыла и включаться в проект при необходимости. Последнее касается и QB и ORM.
Если бы вы хоть немного были внимательны, взглянув на код первого крыла http://ru.coresky.net/code?main/sky.php или почитали комментарии, прежде чем спешить участвовать в «цирке», то поняли бы, что файлы в SKY характеризуются свойством «port» и «clear-cloud». Для того, чтобы работать, например с PostgreSQL, нужно просто взять тот-же файл «main/sky.php», который является портом для этой БД.
В статье выше, ясно написано: «В SKY допускается редактирование КПИ, в том числе ядра», а вы пишите: «как расширять ядро не затрагивая при этом сам код?». Вы очень не внимательны.raacer
30.10.2016 11:32+1Нет… сейчас, вы начнете оправдываться и говорить:
Вот Вы себя, по-видимому, оракулом считаете. Это одна из причин, почему с Вами не получается вести дискуссию — Вы наперед знаете, кто что думает, и сами отвечаете на свои вопросы. С таким талантом надо на передачу «Битва экстрасенсов». А здесь люди общаются аргументами.
Я при всем желании не могу понять, здешних комментаторов, похожих на вас, которые просто троллят авторов и получают при этом удовольствие?
Вы не отвечаете ни на один из существенных вопросов. На любое существенное замечание у Вас есть только один аргумент, и он выглядит так: «сейчас вы начнете писать <предсказания оракула>».
Давайте-ка все вместе покритикуем автора…
Вас есть за что критиковать. Вы предлагаете то, от чего Все бегут как от огня. Вы еще не поняли это?
У всех нас цель одна — автор, и те, кто в моем лагере будут лояльны ко мне.
Вы — чересчур обидчивый человек, воспринимаете все на свой счет. Мы Вас не знаем, а обсуждаем в основном только Ваш продукт. Вы даже не захотели ничего рассказать о своем опыте. Но когда Вы игнорируете всяческие попытки вести с Вами дискуссию, ничего не остается кроме как троллить Вас.
Если бы вы хоть немного были внимательны, взглянув на код первого крыла http://ru.coresky.net/code?main/sky.php или почитали комментарии, прежде чем спешить участвовать в «цирке», то поняли бы
Посмотрел и ничего не понял. У Вас в коде нет ни одного комментария. На что мне эта простыня? Что я там должен понять? Надо догадаться по коду, как это использовать? Я, в отличие от некоторых, на оракула не учился.
ButscH
30.10.2016 13:47+1Странная логика, наваяем QB, чтобы код был красив…
Милейший, вы в моем примере увидели красоту кода? Ну да, код красив, но им также удобно пользоваться! Он избавляет от дублирования кода, он экономит время разработчика.
Для того, чтобы работать, например с PostgreSQL, нужно просто взять тот-же файл «main/sky.php», который является портом для этой БД.
Вы видимо шутите? Т.е. если у вас будет поддержка 10 БД, то ваш проект будет содержать 10 клонов, разница в которых только в SQL запросах? Кто будет за этим следить?
Я так понимаю, что вы нахватались откуда то красивых словечек и умных фраз и решили, что теперь то вы бог программирования, но по факту моя теория о том, что единственный проект, который вы за всю жизнь сделали — это SKY. В противном случае вы бы понимали что даже при создании простейшего сайта для различных заказчиков вы столкнетесь в разными требованиями.
Простейший пример: Один заказчик хочет, чтобы в БД пароли хранились с определенным алгоритмом шифрования, который ваша CMS не поддерживает, второй хочет видеть авторизацию по email, третий хочет полноценной api и SPA с использованием JWT, я так понимаю что в вашей SKY ни один из этих кейсов не реализуем?
lair
30.10.2016 13:48+2Старый без QB не рабочий?
Рабочий, но дорог в поддержке: добавление нового условия (или, хуже того, новой фичи типа пейджинга) будет слишком дорого.
Я неутомимо буду прояснять ради тех кто читает и думает, но не участвует в цирке. Итак, во-первых, в этой статье четко, русским языком написано, «ORM не нужен, по крайней мере, как базовое средство разработки...».
Вы правда думаете, что повторение одного и того же тезиса — это разъяснение? Так я вас расстрою, это не так. Если вы считаете, что ORM не нужен — докажите, что минусы от его применения превышают плюсы от него же (заметим, что действительно есть ситуации, когда ORM не нужен, вопрос только их распространенности).
В SKY допускается редактирование КПИ, в том числе ядра
Вам неоднократно написали: это плохая практика, поведение должно меняться без переписывания ядра.
raacer
30.10.2016 12:04+1Автор, я таки зашел на Ваш сайт и посмотрел, что там. Посмотрел в основном ту информацию, которая представлена наиболее лаконично — видео и картинки. В остальном сильно много воды.
Так вот, я в шоке! Автор, Вы проделали огромную работу!!! Видно, что Вы работали много лет не покладая рук над этим продуктом! Только непонятно зачем.
Редактор кода и утилита сравнения файлов в браузере — это круто. Но зачем это? Все равно все будут писать в своих любимых IDE, и редкий нуб воспользуется Вашим редактором.
Генератор страничек — это выглядит очень впечатляюще для новичка. Клац-клац — и все готово за две минуты. Супер. Но меня интересует не время, затраченное на генерацию стандартных функций, а простота дальнейшей разработки и поддержки. Вы продемонстрировали колоссальные возможности вашей системы, но все это — мелочи, не являющиеся чем-то уникальным. И после генерации стандартных страничек много еще придется допиливать руками. Как потом с этим работать — вот в чем вопрос. Современные фреймвёрки предоставляют массу инструментов, облегчающих написание и сопровождение кода. Вот это важно. Попробуйте за две минуты сгенерировать социальную сеть типа Facebook, и Вы поймете, что чем больше проект, тем меньше толка от вашей утилиты. Причем даже на не очень больших проектах польза от него будет стремиться к нулю.
DeLuxis
31.10.2016 09:09Порой трудно отказаться от своих привычек и признать ошибки.
Вы пошли по наименее затратной для вас дороге, но она привела вас в болото.
Возвращайтесь обратно и начинайте осваивать новое. Например тот же Yii2.
Попробуйте создать копию своего сайта на нем, ради хобби! Просто чтоб попробовать.
И поставьте какой нибудь NetBeans, PHPStorm с плагинами.
Не тратьте время зря. Развивайтесь.youlose
31.10.2016 11:57Когда я в последний раз ставил Yii ради интереса, и первая и вторая версия после первоначальной установки выдавали неработающий сайт (это было полгода назад), с тех пор это исправили, надеюсь? А то подобное начало не очень дружелюбно для новичков.
M-A-XG
31.10.2016 12:17-3Та нафиг ваши фреймворки.
Это они — путь в болото.
Это как застрявание в текстурах.
Нормальному разработчику фреймворк не нужен.
amaksr
Что то я совсем ничего не понял (кроме того что глобальные переменные и eval это хорошо, а фреймворки — плохо). Наверное, проект SKY просто опережает свое время…