Еще я смотрел какую-то вводную лекцию Яндекса по тестированию, так там промелькнуло, что код не допускается к тестированию если у него цикломатическая сложность больше 5.
Кстати говоря, программы типа yEd Graph Editor поддерживают вычисление необходимых цифр, для расчета цикломатической сложности алгоритмов. Вам же останется только набросать алгоритм и посчитать на калькуляторе по формуле.
Если API-backend будет на PHP, да, то рекомендую вот такую реализацию OAuth2 https://oauth2.thephpleague.com/ , кстати, там есть и валидатор токенов для сервера ресурсов. (Не очень вчитывался в предидущее написаное, так-что заранее извиняюсь.)
Лично мой опыт -- я залез в сложную разработку и, когда проблемы стали неразгребаемыми, я обратился к шаблонам проектирования и, знаете, быстро так сразу всё воспринимается, моментально прям. Может к чтению теории добавить реальную практику и дело пойдет лучше?
Можно разнести функционал на отдельные процессы запускаемые systemd или еще pcntl, или apache thrift, или rabbitmq, на худой конец exec в /dev/null, параллельте тяжелые задачи.
Не подключайте то, что не нужно. Это я про lazy load сервисов. А если надо их постоянно, то надо не отключаться и переподключаться только при обрыве, например какой-нить демон, который реализует какой-нить RPC и к нему контроллеры обращаются за немедленными ответами и запуском других процессов.
Ну это я так, варианты ускорения перечислил некоторые...
Господа :) Попросил бы смотреть на вещи в разрезе Архитектуры приложения. Например, если вы говорите о файндерах, то какое место они занимают в системе и почему именно там, какую роль они выполняют с точки зрения системы в целом. Иначе это оффтоп. Спасибо.
Вот да... И спустя 3 года - ничего не меняется...
Я хочу сказать, что nginx на фронт таки покруче будет (статику выкидывать, да и вообще, не только статику, а направлять запросы может не только на апач, а может и на node или еще что), а php таки лучше как модуль для apache, ибо, как писали в дургих ответах - гибче...
artemt: Вот для фронта только JS, для сервера - лучше с JS не начинать (мое субъективное мнение основанное на опыте)... Поэтому и говорю, что на сервере лучше что-то, на чем можно написать ЛЕГКО ПОНЯТНЫЕ программы ^_^ конечно, на ноде можно что угодно написать, но думаю со мной все согласны, что JS - не очень-та и простой, когда надо разбираться в чужом коде, чего не сказать про PHP (и это я говорю про хорошо написанный код, понятно, что набыдлокодить можно на любом языке)
ZoomLS: Я бы на вашем месте не советовал JS как язык для сервера... Нужно хорошо понимать что делаешь, что бы программировать на ноде. JS имеет крайне хреновую интроспекцию кода, в отличие от PHP и Java, поэтому, все ide надрываются, когда пытаются понять у какого метода откуда ноги растут :) поэтому, код получается не "мэйнтайнабл" и поддерживать его может тока создатель... Не спорю, есть хорошо написанные скрипты, где все понятно, но когда он попадает в мешанину других библиотек и скриптов, то это перестает иметь значение...
Я бы вам советовал начать с PHP, потом, если захотите, перейдете на ноду, ведь работая на web - JS точно не забудешь :)
Говорят, что настоящие программисты пишут программы не на языке, а с применением языка. Отсюда можно сделать важный вывод: знать язык важно, но также не менее важно знать паттерны проектирования, думать объектно-ориентированно, книжечку мистера Фаулера далеко не убирать, да и вообще, стремиться практиковать все самое хорошее (это я про лучшие практики).
Если вы меня еще захотите спросить про путь, который надо проделать, что бы нормально вникнуть в разработку с применением PHP, то я могу посоветовать вам сначала изучить сам язык (естественно), а далее заняться symfony2. Ибо симфония всасывает все самое хорошее, то, о чем я выше говорил и это будет интересно, я вам гарантирую. А дальше у вас будет много чего учить, так как симфония - это набор компонент, а их, поверьте, крайне много...
Вряд ли он умрет... Сам по себе он конечно не айс язык, но как платформа для сервер-сайда - очень даже! Да и экосистема вокруг него сильная: взять хотя бы прекрасные IDE, которые, кстати, могут работать с интерпретатором по сети (например vagrant), чем js ide похвастаться не могут (привет связочка webstorm-nodejs!), язык начинает более строго относится к типизации и аннотациям, да и движок становится всё лучше год от года, а это позволяет строить более крутые серверные системы... В общем-то язык и его окружение берут всё самое лучшее из других языков и продуктов (взгляните хотя бы на симфонию или доктрину, ничего не напоминает? :) Пусть это и субъективное мнение (моё), но работать в экосистеме php проще и удобней и не так долбануто, как в nodejs :)
Я не буду спорить о том, на сколько сильно nodejs подвинет остальные экосистемы на серверах, но это будет ощутимо и даже чувствуется уже сейчас... Но когда все поймут, что простота и удобство - важней - перейдут на Java ^_^
а можно сделать по паттерну компоновщик, вроде, например, с помощью этих функций. uasort принимает статический метод из класса компановщика (вроде), а тот в свою очередь прогоняет массив по всем методам которые были подключены заранее, получается, алгоритм можно будет менять, подставлять "плагины" сортировки ))) %)
Василий лучше не спорь с FanatPHP, а то он расскажет тебе, что суть вопроса автора не в том, что лучше, а что автор именно хотел узнать, и только он правильно ответил на этот вопрос ))) без обид
Молодец вы, молодец FanatPHP. Отлично поработали. Кто бы спорил. Вы меня еще попутно понаоскорблять успели сполна. Хотя моя мысль проста: не хранить разметку в БД. И, отвечать именно так у меня были причины. Хотя бы то, что автор может посмотреть на мое сообщение и подумать, например: "А ведь и точно, что-то в программе не так, если мне приходится таким заниматься, точно, надо шаблоны сторить в fs". А может ему точно надо хранить HTML или XML-подобную разметку в БД и никак иначе и он просто проигнорирует мое сообщение. Но, пока есть подозрение, что мой ответ поможет и может быть полезным, я его оставлю. И, заметьте, только вы ко мне придрались.
