Вы наверняка думаете, что писать на php — это просто. И «hello, world» выглядит примерно так так: <?php
echo 'Hello, world!';
Конечно, чего еще ожидать от языка с низким порогом входа. Ну да, именно так и было раньше. Много лет назад. Но теперь, в 2017 году никто так уже не делает. Давайте рассмотрим, почему, и попробуем построить наше более реалистичное hello-world приложение по шагам, а их, скажу сразу, получилось не мало.
> Полный исходный код «hello,world» можно посмотреть здесь.
Для начала надо осознать тот факт, что без фреймворка сейчас приложения никто не делает. Если вы пишете вручную "
echo 'hello, world'", то обрекаете проект на говнокод на веки вечные (кто потом этот велосипед за вас переписывать будет?). Поэтому возьмем какой-нибудь современный, распространенный в мире фреймворк, например Symfony.Но прежде, чем его устанавливать, надо бы создать базу данных. Зачем базу данных? Ну не хардкодить же строку «hello, world» прямо в тексте программы!
База данных
В 2017 году принято использовать postgresql. Если вы вдруг еще не умеете его устанавливать, я помогу:
sudo apt-get install postgresqlУбунта при установке создаст юзера postgres, из под которого можно запустить команду psql с полными правами на базу.
sudo -u postgres psqlТеперь создадим юзера базы с паролем (придумайте какой-нибудь посложнее).
CREATE ROLE helloworlduser WITH PASSWORD '12345' LOGIN;И саму базу:
CREATE DATABASE helloworld OWNER helloworlduser;Также надо убедиться, что в pg_hba.conf у вас разрешены коннекты к базе с localhost (127.0.0.1). Там должно быть что-то вроде этого:
host all all 127.0.0.1/32 md5Проверим соединение:
psql -h localhost -U helloworlduser helloworldпосле ввода пароля должно пустить в базу. Сразу создадим таблицу:
CREATE TABLE greetings (
id int,
greeting text,
primary key(id)
);
INSERT INTO greetings
(id, greeting)
VALUES
(1, 'Hello, world!');
Ну, супер, с базой всё. Теперь перейдем к фреймворку
php-фреймворк
Надеюсь, что в 2017 году у всех стоит composer на компьютере. Поэтому сразу перейдем к установке фреймворка
composer create-project symfony/framework-standard-edition helloworldphpПри установке он сразу спросит параметры соединения с базой:
host: 127.0.0.1
database_name: helloworld
database_user: helloworlduser
database_password: 12345остальное по умолчанию/по усмотрению.
Надо только в конфиге config.yml поменть драйвер на
driver: pdo_pgsql. (У вас ведь установлено php-расширение pdo_pgsql ?)Проверим, что всё более менее работает, запустив
cd helloworldphp
bin/console server:start
Симфони запустит свой собственный сервер, который слушает порт 8000 и на нем можно дебажить код. Таким образом в браузере по адресу
http://localhost:8000/ должно быть что-то вроде «Это симфони, блаблабла».Уфф! Казалось бы всё, контроллер уже есть, подправить вьюху, создать модель и понеслась, хелло ворлд уже близко!
Но… нет. Извините, но не в 2017-ом. В этом году все делают SPA (single page application).
Php-программист в 2017 году не может обойтись без js и верстки, теперь мы все full stack, а значит и helloworld должен быть соответствующий.
Ну ладно, ладно, еще бывают чистые php-бекенд-разработчики, но давайте возьмем более общий случай
JavaScript и его многочисленные друзья
Поэтому находим в симфони вьюху (а дефолтная вьюха лежит в app/Resources/view/default/index.html.twig) и стираем там всё, заменяя на:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<div id="root"></div>
<script src="js/bundle.js"></script>
</body>
</html>Т.е. всё будет лежат в bundle.js: сжатые javascript файлы прямо вместе со стилями и всем, чем нужно.
Как нам создать этот бандл? Нужно написать приложение и настроить webpack для сборки.
Webpack (или его аналоги) нам все равно бы понадобились, мы же не будем писать код на чистом javascript в 2017-году, когда typescript явно в тренде. А typescript надо как-то преобразовать в обычную js-ку. Это удобно делать, используя webpack.
Разумеется, на чистом typescript тоже никто не пишет. Нужен какой-то фреймворк. Одна из самых модных связок сейчас — это react + redux. А для верстки, так и быть, будем использовать старый добрый олдскульный bootstrap (через sass, конечно же).
Нам понадобится куча js-библиотек. У вас ведь стоит nodejs и npm? Убедитесь, что у вас свежий npm и установите пакеты:
npm init в зависимостях (в файле package.json) пропишем примерно такое:
"dependencies": {
"@types/react": "^15.0.11",
"@types/react-dom": "^0.14.23",
"babel-core": "^6.23.1",
"babel-loader": "^6.3.2",
"babel-preset-es2015": "^6.22.0",
"babel-preset-react": "^6.23.0",
"bootstrap-sass": "^3.3.7",
"css-loader": "^0.26.1",
"node-sass": "^4.5.0",
"react": "^15.4.2",
"react-dom": "^15.4.2",
"react-redux": "^5.0.2",
"redux": "^3.6.0",
"resolve-url-loader": "^2.0.0",
"sass-loader": "^6.0.1",
"style-loader": "^0.13.1",
"ts-loader": "^2.0.0",
"typescript": "^2.1.6",
"url-loader": "^0.5.7",
"webpack": "^2.2.1",
"@types/node": "^7.0.5"
}И выполним
npm installи еще нужно установить:
npm install webpack -gчтобы была доступна команда webpack.
Увы, это еще далеко не всё. Так как у нас typescript, еще надо создать файл tsconfig.json, примерно такой:
{
"compilerOptions": {
"module": "es6",
"moduleResolution": "node",
"sourceMap": false,
"target": "esnext",
"outDir": "web/ts",
"lib": [
"dom",
"scripthost",
"es5",
"es6",
"es7"
],
"jsx": "react"
},
"include": [
"frontend/**/*.ts",
"frontend/**/*.tsx"
]
}С конфигами пока что ок, теперь займемся нашим приложением на typescript.
Сначала создадим компонент для отображения нашего текста:
// файл frontend/components/Greetings.tsx
import * as React from 'react';
export interface GreetingsProps {
text: string;
isReady: boolean;
onMount();
}
class Greetings extends React.Component<GreetingsProps, undefined> {
componentDidMount() {
this.props.onMount();
}
render() {
return (
<h1>{this.props.text}</h1>
);
}
}
export default Greetings;Наше SPA будет подгружать текст надписи через Rest API. React — это просто view-компоненты, а нам еще нужна логика приложения и управление состоянием.
Так что будем использовать redux, а также пакет для связи redux и react (react-redux). Поэтому надо будет еще создать компонент, который будет создавать наш компонент Greetings с нужными properties, и сможет сообщить хранилищу (store) состояния, что появилось новое действие (получены данные для отображения).
Disclaimer: я только начал изучать redux, поэтому наверняка тут есть за что «бить по рукам».
Выглядит этот компонент, допустим, примерно так:
// файл frontend/components/App.tsx
import * as React from 'react';
import {connect} from 'react-redux'
import Greetings from './Greetings';
const mapStateToProps = (state) => {
return state;
}
const mapDispatchToProps = (dispatch) => {
return {
onMount: () => {
fetch("/greetings/1").then((response) => {
return response.json();
}).then((json) => {
dispatch({type: 'FETCH_GREETING', text: json.greeting})
});
}
}
}
export default connect(mapStateToProps, mapDispatchToProps)(Greetings);Ну и точка входа приложения, создание redux-стора, диспатчера и т.д. Тут всё сделано немного по рабоче-крестьянски, но для хелловорлда сойдет, пожалуй:
// подгружает стили bootstrap
import 'bootstrap-sass/assets/stylesheets/_bootstrap.scss';
import * as React from 'react';
import * as ReactDOM from "react-dom";
import {Provider} from 'react-redux';
import App from './components/App';
import {createStore} from 'redux';
const app = (state = {isReady: false, text: ''}, action) => {
switch (action.type) {
case 'FETCH_GREETING':
return Object.assign({}, state, {isReady: true, text: action.text});
}
return state;
}
const store = createStore(app);
ReactDOM.render(
<Provider store={store}>
<App/>
</Provider>,
document.getElementById("root")
);Примерно здесь происходит следующее:
- Первоначальное состояние системы —
{isReady: false, text: ''}. - Создан reducer под названием app, который умеет обрабатывать действие FETCH_GREETING и возвращать новое состояние системы.
- Создан store для обработки состояний.
- Всё отрендеривается в элемент, который мы прописали во вьюхе
<div id="root"></div>
Ах да, совсем забыл. Конфиг вебпака:
const webpack = require('webpack');
const path = require('path');
const ENVIRONMENT = process.env.NODE_ENV || 'development';
let config = {
context: path.resolve(__dirname, "frontend"),
entry: './index.tsx',
output: {
filename: 'bundle.js',
path: path.resolve(__dirname, "web/js")
},
resolve: {
extensions: [ ".js", ".jsx", '.ts', '.tsx']
},
module: {
rules: [
{
test: /\.tsx?$/,
use: [{
loader: 'babel-loader',
query: {
presets: ['es2015', 'react']
}
}, {
loader: 'ts-loader'
}]
},
{
test: /\.woff($|\?)|\.woff2($|\?)|\.ttf($|\?)|\.eot($|\?)|\.svg($|\?)/,
loader: 'url-loader'
},
{
test: /\.scss$/,
use: [
{
loader: "style-loader"
},
{
loader: "css-loader"
},
{
loader: "resolve-url-loader"
},
{
loader: "sass-loader"
}
]
}
]
},
plugins: [
new webpack.DefinePlugin({
'process.env.NODE_ENV': JSON.stringify(ENVIRONMENT)
})
],
node: {
process: false
}
};
if (ENVIRONMENT == 'production') {
config.plugins.push(
new webpack.optimize.UglifyJsPlugin({
compress: {
drop_console: false,
warnings: false
}
})
);
}
module.exports = config;
Теперь мы можем запустить webpack или NODE_ENV=production webpack (чтобы получить минифицированную версию bundle.js)
Pomodoro
Не знаю как вы, а я уже задолбался писать этот hello, world. В 2017 году надо работать эффективно, а это подразумевает, что надо делать перерывы в работе (метод Pomodoro и т.д.). Так что, пожалуй, прервусь не надолго.
[прошло какое-то время]
Давайте продолжим. Мы уже умеем подгружать код с /greetings/1 на стороне javascript, но php-часть еще совершенно не готова.
Doctrine
Уже потрачено много времени, а в php-коде не создано ни одной сущности. Давайте исправим положение:
<?php
// src/AppBundle/Entity/Greeting.php
namespace AppBundle\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* @ORM\Entity
* @ORM\Table(name="greetings")
*/
class Greeting
{
/**
* @ORM\Column(type="integer")
* @ORM\Id
*/
private $id;
/**
* @ORM\Column(type="string", length=100)
*/
private $greeting;
public function getId()
{
return $this->id;
}
public function getGreeting()
{
return $this->greeting;
}
}
Супер. Осталось совсем чуть-чуть.
REST
Надо сделать-таки простенький REST API, который может хотя бы отдать json по запросу GET /greetings/1
Для этого в контроллере (файл src/AppBundle/Controller/DefaultController.php) добавим метод с роутом:
/**
* @Route("/greetings/{id}")
*/
public function greetings($id)
{
$greeting = $this->getDoctrine()->getRepository("AppBundle:Greeting")->find($id);
return new JsonResponse(['greeting' => $greeting->getGreeting()]);
}Всё, можно запускать. На экране отображается «Hello, world!». Внешне он, конечно, выглядит почти также как результат <?php echo «hello, world» ?> (если не считать бутстраповского шрифта), но теперь это современное приложение по всем канонам. Ну, скажем так, почти по всем канонам (не хватает тестов, проверок ошибок и много чего еще), но я уже задолбался это делать :)
Выводы
В последнее время сильно участились споры «зачем нужен php, если есть java». Уж не знаю, кто прав, а кто нет, холивары — дело такое. Но в каждом споре один из аргументов в пользу php — это простота для новичков. Как мне кажется, этот аргумент уже давно не валиден, что я и хотел показать этой статьёй. Новичку все равно придется кучу всего узнать и 100500 конфигов настроить: фреймворки (очень похожие на фреймворки java), базы данных, linux, javascript со всем своим зоопарком, верстка, http-протокол, различный тулинг и многое-многое другое. Даже если это не SPA.
Upd. Статья уходит в глубокий минус, но я не собираюсь менять мнение. Оно примерно такое:
1) SPA всё больше проникает в наш мир, и надо это уметь, хотя бы в общих чертах.
2) Без фреймворков не построишь хорошее современное приложение.
Комментарии (554)
DamirFelix
20.02.2017 11:02+9А если я не знаю PHP, хочу его изучить, мне сразу начинать с фрейморвка? Мне кажется более логично изучить голый PHP.
varanio
20.02.2017 11:07Согласен. Но при этом не надо обманываться насчет того, что голого php хватит для реального приложения. Поэтому почти сразу же надо начинать юзать фреймворк
DamirFelix
20.02.2017 11:15+4сейчас да пожалуй, но как же раньше писались веб-приложения, когда фреймворков не было
stepmex
20.02.2017 11:24+19Сперва приходилось писать свой фреймворк. А потом на нём писать веб-приложение.
VolCh
20.02.2017 11:32+1тысячами разработчиками писались одни и те же вещи, часто с одними и теми же ошибками. Попробуйте написать такое же (желательно так же с объектом Greeting, получаемым из базы, а не массивом или stdClass) приложение на голом PHP и количество кода вас неприятно удивит. Или в коде будут грубые ошибки.
linux_art
20.02.2017 23:41Строчек 5-6 займет? :)
wrewolf
21.02.2017 10:52+1Ага, но только реализация класса Greeting (без учета взаимеодействия с БД)
linux_art
21.02.2017 19:30+1Это только при условии, что стоит цель усложнять код. В ином случае готовый json получается 1 запросом из базы и делать из него внутренний обьект php вообще надобности нету ;)
wrewolf
21.02.2017 19:46+1При условии не усложнять объект и база лишнии, пишем константу в коде, но это выше выяснили.
ellrion
20.02.2017 11:24+6Это смотря какое приложение. Да и фреймворки разные есть. Тут больше важно что нужно знать современные концепции и стандарты современного веб приложения. Вот composer — да; PSR'ы; Неймспейсы; Автолоадинг; Система контроля версий; Единая точка входа; Паблик директория; Роутинг; Шаблонизация; Query builder. Остальное имхо опционально.
И если уж говорить о самой статье, то замените symfony на laravel и react на vue. И статья выйдет короче)
psFitz
20.02.2017 11:35+8Что за бред?
Часто видел когда люди сразу начинали учить cms или фреймворк и потом даже не понимали где cms, а где сам php.
Fesor
20.02.2017 18:52+1голого php хватит для реального приложения
Его то хватит, вопрос в стоимости решения и покрываемых кейсах.
alexlcdee
21.02.2017 15:13Пожалуй, стоит подбирать инструмент подходящий под задачу, а не бездумно хватать фреймворк, если задача запросто решается без него.
Брать фреймворк для вывода hello world — извращение.VolCh
21.02.2017 15:42Как минимум, нужно ещё подумать как задача будет изменяться в обозримом будущем.
alexlcdee
21.02.2017 16:08Вероятность того, что задача «Hello World» менять не будет несколько выше, чем вероятность её изменения, на мой взгляд. Если задача «Hello World» должна будет вырасти дальше за пределы, собственно вывода на экран надписи «Hello World», то проще код вывода «Hello World» выкинуть и решить задачу с нуля отдельным проектом за отдельную сумму.
Почему-то при разработке сайта визитки никто не желает вкладывать туда потенциал соц.сети или интернет магазина, а пилят именно визитку. И если клиент хочет из этой визитки интернет-магазин получить, то ему, собственно, выкатывается отдельный ценник.VolCh
21.02.2017 16:15Почему-то при разработке сайта визитки никто не желает вкладывать туда потенциал соц.сети или интернет магазина, а пилят именно визитку. И если клиент хочет из этой визитки интернет-магазин получить, то ему, собственно, выкатывается отдельный ценник.
Да ладно не желают. Желают, но узнав сколько оно стоит (или в случае внутреннего заказчика — сроки), то свои аппетиты умеряют. Но возможность развития закладывать нужно практически всегда, особенно если заказчик уже рассказал о своих будущих хотелках.
alexlcdee
21.02.2017 16:42Да ладно не желают. Желают, но узнав сколько оно стоит (или в случае внутреннего заказчика — сроки), то свои аппетиты умеряют.
Это было о разработчиках, не о заказчиках. Так-то то, что заказчики хотят по цене сайта-визитки получить систему для запуска шаттлов с возможностью выбора конфигурации этого самого шаттла — само собой разумеющееся.
vlreshet
20.02.2017 11:25+2ИМХО, следует сначала учить чистый PHP, потом попробовать написать свой фреймворк (все должны через это пройти, чтобы исчезло желание писать велосипеды), и только потом пробовать уже существующие фреймворки.
Fesor
20.02.2017 18:49+1потом попробовать написать свой фреймворк
Тут можно напороться на проблему "а что писать то". Ну то есть мы хотим на практике поучиться — это похвально. Но как новичку определить что он делает что-то дельное? Мы же таким образом можем вредные привычки сформировать у человека.
VolCh
21.02.2017 08:58Может выложить свое творчество на Хабр — тут очень доброжелательно ему объяснят, что он делает не так.
wrewolf
21.02.2017 10:54+4Практика показывает влосипедные статьи покрыты минусами от и до.
После этого у человека отпадет желание, что либо писать и в лучшем случае только на хабр. Адекватная критика потеряется в волне хейт-хайпа.Fesor
21.02.2017 11:00+1В целом есть еще чатики всякие, тостеры и подобное. Ну то есть получать фидбэк сейчас есть где. Другой вопрос что… то о чем я писал немного о другом.
Допустим вы решили написать свой фреймворк но понятия не имеете что в нем должно быть… У вас еще нет конкретных задач которые решает фреймворк, и делать мы его будем в отрыве от реальности. И пихать туда будем кучу всего просто посмотрев на других, не разобравшись почему там так и зачем. И скорее всего ближайшее код ревью будет не через неделю а через месяц минимум. А на таких масштабах "конструктивно" уже сложно.
Так что вместо написания своих фреймворков нужно прикладные задачи решать. Если воображение не хватает придумать себе задачу — можно опять же во всяких этих чатиках поспрашивать, или просто погуглить и попробовать повторить проект который нравится. Еще неплохо если будут генерить "изменения требований", причем желательно что бы это делал не тот же человек который реализует проект.
Ну и под "прикладными задачами" я подразумеваю не бложики, а что-то интереснее. Например — клоны инстаграммов, твиттеров. Какие-то утилитки. Хороший пример в чатиках проскакивал — человек отрабатывал навыки на примере тулы для генерации чейджлогов из git log.
wrewolf
21.02.2017 12:15Я это понимаю. Но мой коментарий был к VolCh.
П.С.
Я сам писал фреймворк, да и сейчас сталкиваюсь с несколькими самописными.
Но они все написаны с целью решать определенные задачи.
Koshelenok
21.02.2017 08:28думаю что написание своего фреймворка можно заменить изучением основных паттернов, включая mvc и внедрении зависимостей.
VolCh
21.02.2017 08:58+4Паттерны почти бесполезно изучать, если на практике не сталкивался с проблемами, которые они решают.
michael_vostrikov
21.02.2017 20:25Я бы сказал, сначала основы языка, потом фреймворк, потом попробовать повторить работу фреймворка. Так будет знание того что нужно, и понимание как оно работает.
Fesor
21.02.2017 22:31+1еще нюанс — следует попробовать поработать хотя бы с двумя фреймворками. Чтобы посмотреть разные подходы.
Fesor
20.02.2017 18:47Мне кажется более логично изучить голый PHP.
А еще было бы неплохо поучиться тесты писать до момента когда надо фреймворк брать. Ну и не стоит на голом пыхе заниматься коммерческой разработкой (если у вас нет достаточно опыта).
А так да, знание фреймворка не убережет вас от незнания языка. Логику мы все ж на php пишем.
questpc
21.02.2017 11:25Советую изучить Python вместо PHP. Не смотря на то что PHP в последних версиях взял очень много из Питона, по легкочитаемости кода и красоте синтаксиса уступает последнему. Python по сути это тот же PHP, но лучше. Особенно если 3.x и с использованием Jinja2.
A-Stahl
20.02.2017 11:05+4>надо осознать тот факт, что без фреймворка сейчас приложения никто не делает.
Вот поэтому о PHP и JavaScript многие такого плохого мнения — на каждый чих свой фреймворк. Все они разные. Все велосипедные и…
>кто потом этот велосипед за вас переписывать будет?VolCh
20.02.2017 13:07Обычно плохого мнения о них как раз из-за того, что очень многие не используют фреймворки и библиотеки, а каждый раз пишут велосипеды.
f3ath
20.02.2017 11:24+31Автор умничал-умничал и в итоге написал всю бизнес-логику прямо в контроллер. Молодец.
VolCh
20.02.2017 11:35+3Доставание объекта из репозитория не бизнес-логика. Здесь бизнес-логики по сути нет вообще, только бизнес-данные.
marenkov
22.02.2017 00:06-1В 2017 прямое обращение к репозиторию и сущности из контроллера — это oldschool.
Надо было создать сервис greetings, который орудует приветствиями, а в контроллере извлечь его из контейнера и запросить у него нужное приветствие.
/** * @Route("/greetings/{id}") */ public function greetingAction($id) { $greetingsManager = $this->get('greetings'); $greeting = $greetingsManager=>get($id); return new JsonResponse(['greeting' => $greeting]); }Delphinum
22.02.2017 00:18В 2017 методы контроллера не должны иметь доступа к контейнеру, все зависимости контроллера должны инжектится в него через конструктор.
class GreetingController{ private $greetingService; public function __construct(GreetingService $greetingService){ $this->greetingService = $greetingService; } ... }Fesor
22.02.2017 00:23+1для контроллеров удобнее через дабл диспатч… ух жду symfony 3.3… смогу убрать свои кастыли для этого. В целом нет ничего зазорного не делать контроллеры сервисами.
Delphinum
22.02.2017 00:46для контроллеров удобнее через дабл диспатч
Не знаю как это.
В целом нет ничего зазорного не делать контроллеры сервисами
Откуда же им взять состояние, чтобы не быть сервисами?Fesor
23.02.2017 01:52+1Не знаю как это.
Это когда зависимости для метода прокидываются как аргументы этого метода:
// вместо такого public function doSomething() { $this->someData = $this->dependency->someCalculations($this->someData); } // так public function doSomethingCooler(MyDependency $dependency) { $this->someData = $dependency->someCalculations($this->someData); }
Хорошо подходит для экшенов контроллеров и если вы хотите какую-то логику опрокинуть в сущность чтобы не плодить геттеров и не ломать инкапсуляцию.
Откуда же им взять состояние, чтобы не быть сервисами?
Поясню свою мысль. Контроллер это такая штука, которая уж больно тесно интегрирована с фреймворком (она зависит от абстракции запросов как минимум, шаблонизаторов и подобного). Делать их "независимыми от фреймворка" банально не выгодно. В них не должно быть никакой логики что бы нас это парило.
А при помощи дабл диспатча мы можем полностью устранить необходимость в экшенах контроллера юзать сервис локаторы и тем самым получить практически тот же профит что и от controller-as-service но без гемороя.
Fortop
23.02.2017 10:41А кто мешает сейчас писать в режиме 1 action = 1 controller?
Получается именно то самое поведение, которое вам хочется.
PSR-7 middleware фреймворки реализуют именно то, что вы хотите.
Например Zend ExpressiveFesor
23.02.2017 14:04А кто мешает сейчас писать в режиме 1 action = 1 controller?
Получается именно то самое поведение, которое вам хочется.далеко не то же. Зачем мне ажно целый класс который выглядит так:
class RegisterUserAction { private $handler; private $loginManager; public function __construct(RegisterUserHandler $handler, LoginManager $loginManager, Flusher $flusher) { $this->handler = $handler; $this->loginManager = $loginManager; $this->flusher = $flusher; } /** * @Route("/users", methods={"POST"}) */ public function __invoke(Request $request) { $user = $this->handler->__invoke($this->mapRequestData($request)); $this->flusher->flushChanges(); return $this->loginManager->login($user); } }
если я могу сделать так:
public function registerUserAction(Request $request, RegisterUserHandler $handler, LoginManager $loginManager) { $user = $handler($this->mapRequestData($request); $this->flushChanges(); return $loginManager->login($user); }
Ну то есть кода меньше, делает одно и то же. Это же контроллеры, там нет логики, даже логики уровня приложения. Оно просто связывает HTTP и приложение. Вот если бы можно было полностью от HTTP отвязаться на уровне фронтконтроллера, у меня остались бы только хэнделеры и контроллеры бы юзались как адаптеры например для совместимости со старыми версиями API. Но увы я пока не придумал эффективного способа.
PSR-7 middleware фреймворки реализуют именно то, что вы хотите.
Не то же самое. Повторюсь — я пробовал, на 100% не выходит. Проблема обычно с http реквестом или с flush-ем доктрины. Все равно нужна какая-то одна штука на запрос которая будет связывать все вместе. Проблему частично решает graphql но это если он нам подходит.
marenkov
23.02.2017 14:43Вот если бы можно было полностью от HTTP отвязаться на уровне фронтконтроллера, у меня остались бы только хэнделеры и контроллеры бы юзались как адаптеры например для совместимости со старыми версиями API. Но увы я пока не придумал эффективного способа.
Может это вдохновит вас на идею https://habrahabr.ru/post/280512/Fesor
23.02.2017 15:05Это хорошо подходит когда вы не любите фронтэндщиков.
CommandBus это хорошо, это прикольно, это весело. Но это не значит что HTTP запрос который дергает шину команд ничего не должен возвращать. А если вам надо что-то вернуть — надо знать что возвращать.
p.s. Практикую CQRS на проектах, так что вдохновиться увы не могу и думал над этим не один месяц. Отказаться от контроллеров является непрактичной затеей. Делать экшены контроллеров как классы практично только если у вас логика в контроллерах.
Delphinum
23.02.2017 14:52Зачем мне ажно целый класс который выглядит так
А почему бы не реализовать делегирующий контроллеру middleware?Fesor
23.02.2017 15:06и будет по мидлвэру на действие. То есть адаптеры такие небольшие. То есть… контроллеры.
Delphinum
23.02.2017 15:17Нет, это будет обертка над контроллером, которая подготавливает для него окружение, на пример инжектит зависимости, передает полученные от контроллера данные дальше по цепочке, обрабатывает их как то и т.д. Один и тот же Middleware ведь может обработать несколько действий и даже контроллеров.
Fortop
23.02.2017 16:50Чем он формально будет отличаться от контроллера?
Вы контроллер можете инстанцировать через фабрики. Зачем там middleware?Delphinum
23.02.2017 17:08Дело не в инстанциировании, а в подготовке запроса и ответа. Тут все зависит от задачи. К примеру у вас есть требование: «при запросе с расширением .json, должен возвращаться ответ в формате JSON, а без расширения, в формате HTML» — можно конечно реализовать два контроллера, которые будут одинаково обрабатывать Request, одинаково запрашивать у слоя домена, но по разному формировать Reponse, а можно просто добавить в Pipeline Middleware, который на основании Request будет оборачивать полученные от одного контроллера данные в разные форматы (JSON или HTML).
Fortop
23.02.2017 17:59+2В моем понимании разные форматы это рендеринг в разные View
Соответственно постпроцессинг запросов в middleware у вас потом ответ куда отдаёт?Delphinum
23.02.2017 20:12В моем понимании разные форматы это рендеринг в разные View
Разные View то понятно, но вам же нужно реализовать два контроллера или два экшена просто для того, чтобы выбрать подходящий View.
Про JSON/HTML это был общий пример использования Middleware Pipeline, по тому же принципу, к примеру, можно организовать ACL расположив слой проверки перед контроллером в виде Middleware.Fortop
24.02.2017 13:33Зачем?
Если у меня приложение поддерживает несколько форматов рендеринга, то я это свяжу на этапе роутинга например.
Или в самом контроллере анализируя пришедший из роутинга параметр формата буду подключать необходимые View.
Эдакий Context switch.
Суть в том, что никому другому знать о том поддерживает ли контроллер разные форматы не нужно.
Вот ACL это неплохой пример post-routing события.
Информации для принятия решения к этому времени уже достаточноDelphinum
24.02.2017 14:24Или в самом контроллере анализируя пришедший из роутинга параметр формата буду подключать необходимые View.
Эдакий Context switch.
В том то и суть, что Middleware Pipeline позволяет вынести из контроллера часть логики, инкапсулировав ее в других классах. Разделение ответственности и все такое. Я не настаиваю, просто обсуждаю один из вариантов решения.
VolCh
23.02.2017 18:31Как правило, для HTML нужно возвращать больше данных.
Delphinum
23.02.2017 22:16В том то и прелесть, для HTML можно добавить дополнительный Middleware.
Fesor
23.02.2017 22:30То есть мы можем воспринимать контроллеры как еще один адаптер, еще один мидлварь. И у нас будет адаптер (мидлварь) которая на основе правил маршрутизации будет выбирать нужный. Пока не вижу ни разницы в подходах ни профита. Я лишь выбираю способ с которым удобнее. В PHP удобнее класс-контроллер с несколькими экшенами и дабл диспатчем. В JS удобнее функции-адаптеры которые выступают как мидлвари.
Delphinum
23.02.2017 23:50И у нас будет адаптер (мидлварь) которая на основе правил маршрутизации будет выбирать нужный
Выбирать нужный что?
Разница между обычным контроллером и пачкой Middleware в том, что последние позволяют сгруппировать в себе различную логику, такую как обработка входных данных, кукисов, заголовков, вызовов, выходных данных и т.д. Можно все это объединить в экшене контроллера, а можно разделить на Middleware, что (возможно) позволит повторно использовать эту логику.Fesor
24.02.2017 11:41Разница между обычным контроллером и пачкой Middleware
Я опять же не понимаю о чем спор. Мидлвари или просто слой адаптеров — это хорошо, но это совершенно отдельный вопрос. Он не решает необходимости иметь некий мидвар на конце цепочки который бы соответствовал одному http запросу. А наличие перед этим мидлварем цепочки, каждый элемент которой делает что-то одно — это просто логично.
Delphinum
24.02.2017 14:29Таки я не спорю, я обсуждаю различные, связанные решения, а обсуждения начал исходя из вашего комментария:
и будет по мидлвэру на действие. То есть адаптеры такие небольшие. То есть… контроллеры
Резюмировать мой ответ можно так: не обязательно дробить Middleware по штуке на действие.Fesor
24.02.2017 22:08+1не обязательно дробить Middleware по штуке на действие.
Не обязательно. По факту мы можем реализовать:
- мидварь для всех операций записи, которые не возвращают результата отличного от "все хорошо" (ошибки — это другое, это можно разрулить отдельной мидлварей).
- мидлварь для всех операций чтения, которые возвращают какой-то результат.
- по мидлварю на любую комбинацию запись + чтение на запрос.
То есть в общем и целом мы стоим перед выбором — либо у нас роуты будут разбросаны по всей системе (потому что тут можно без контроллера, а тут без контроллера будет сложно) либо у нас всегда будет тонкий слой адаптеров между HTTP и приложением, по экшену на юзкейс.
Delphinum
27.02.2017 15:21потому что тут можно без контроллера, а тут без контроллера будет сложно
Fesor, не понял причину разброса роутов по системе. Чем плох вариант вроде:
[ 'route' => '/article/update/:id', 'middleware' => [ SessionMiddleware::class, AclMiddleware::class, ControllerDelegatorMiddleware::class, ], 'controller' => ArticleController::class, 'action' => 'updateAction', ]
Возможно проблема в том, что вы конфигурируете роуты только на уровне контроллеров?Fesor
27.02.2017 18:29Возможно проблема в том, что вы конфигурируете роуты только на уровне контроллеров?
Да, мне так удобно. В целом опять же, если согласиться с вашим вариантом, то у меня роль "связующего звена" займут конфиги роутинга. Что менее удобно чем контроллеры.
vintage
26.02.2017 12:20Ну да, можно разделить на мидлвари и всегда парсить куки/боди, проверять права, даже если они фактически не понадобятся. Вместо того, чтобы делать это лениво, в случае запроса к соответствующей сущности.
Delphinum
27.02.2017 15:29проверять права, даже если они фактически не понадобятся
Как у вас может быть, что права не понадобятся? ) Некий юзер обращается к некому экшену, вы же должны узнать, имеет он право на это или нет.
В крайнем случае, что вам мешает исключить конкретные Middleware из очереди для конкретного контроллера?vintage
27.02.2017 16:16Пользователь запрашивает текст статьи. Если статья опубликована — выдаём её без вопросов. Если в черновиках, то проверяем, что пользователь — автор или админ. Жонглирование мидлварями тут ничем не поможет. Удобно это делать на уровне модели, в момент обращения к которой, идёт автоматическая проверка по тем правилам, что соответствуют конкретной сущности.
VolCh
27.02.2017 16:36Не очень удобно. Удобнее это делать между вью и моделью, то есть в контроллере. Правил доступа может быть множество, копить их всех в модели — она разрастется без всякого изменения бизнес-ценности.
vintage
27.02.2017 20:58+1Удобнее вообще не разделять серверную логику на M и V и C, ибо этот паттерн предназначен для интерактива с пользователем, а схема "запрос-ответ" не интерактивна, а строго последовательна.
Более продуктивный подход — организовывать все сущности в виде "ресурсов", к которым можно обратиться через любой протокол (http, udp, ws, ssh) через соответствующие адаптеры.
Зачем вам множество правил доступа?
Ограничения прав имеет чуть ли не наибольшую бизнес ценность.
Знаете, когда реализуешь изоморфную модель, то начинаешь смотреть на вещи по другому. Например, на сервере если нет прав, нужно давать отлуп.
А в клиентском приложении нужно деактивировать кнопки, если нет прав. То есть нужно иметь возможность заранее узнавать есть ли права делать определённые действия с определённой сущностью, до попытки выполнить эти действия. И знание это должно не в коде зашиваться, а приходить вместе с сущностью. Права доступа — такой же атрибут сущности, как и прочие её атрибуты.VolCh
28.02.2017 06:50+1На многих серверах система "запрос-ответ" уже не используется в чистом виде. Как минимум есть всякие пуш-технологии. Да и сам запрос можно рассматривать как событие UI, причём не важно пользователь его инициировал, кликнув ссылку или другой сервер.
А мне ресурсный подход мало нравится, больше сервисный, он универсальней — сервис может обеспечить CRUD-доступ к ресурсу, а может делать гораздо более сложные вещи. И, главное, бизнес обычно оперирует процессами, а не сущностями.
Не мне, бизнесу. Постоянно новые требования. Но эти требования обычно к основной бизнес-логике не относятся. И бизнес-ценности особой не имеет, в плане что не приносит прибыли, защищают от потерь, нужны как неизбежное зло, но прибыли не приносят. Мировая практика показывает, что неразрывное связывание объектов прав доступа (это не только сущности) и описания самих прав (особенно императивное) крайне редко приносит пользу. Различные ACL, хранимые и обрабатываемые отдельно более эффективны как в плане удобства их манипулированием, так и в плане улучшения основной логики — мухи отдельно, котлеты отдельно.
Что является атрибутом, а что нет, определяется не разработчиком приложения, а экспертами предметной области. И даже если эксперты настаивают на том, что право доступа неотъемлемый атрибут сущности или экземпляра процесса, то разработчик может их разбить и связать 1:1, чтобы облегчить свои задачи, например не хранить в базе данных код определения прав с последующим его интерпретацией.
vintage
28.02.2017 09:05На многих серверах система "запрос-ответ" уже не используется в чистом виде.
В рамках REST это в любом случае остаётся — запрос ответ. Даже в схеме "запрос от одного сервера, ответ другому". Нет сохраняющегося состояния вьюшки — нет MVC. Комбинацию клиент+сервер уже можно рассматривать как MVC, точнее на клиенте MVC, но модель синхронизируется с мастер-моделью на сервере.
И, главное, бизнес обычно оперирует процессами, а не сущностями.
Чем бизнес оперирует — то и есть сущность.
И бизнес-ценности особой не имеет, в плане что не приносит прибыли, защищают от потерь, нужны как неизбежное зло, но прибыли не приносят.
Всё же хотелось бы более конкретный пример. Если есть требование, например, что автор может редактировать статью, то проще, производительнее и надёжней просто проверить авторство (причём это можно делать даже на клиенте, без обращения к серверу), чем городить обращение к ACL и обеспечивать каждого автора правами на созданные ими статьи, а когда логика прав меняется — перетрясать ACL.
Даже когда надо выдавать произвольные права произвольным людям/группам — удобнее оказывается просто хранить в модели списки субъектов соответствующим ролям. Но опять же, это применимо лишь для графовой субд, а для реляционной проще вкрутить ACL табличку, да.
VolCh
28.02.2017 09:33В рамках REST это в любом случае остаётся — запрос ответ. Даже в схеме "запрос от одного сервера, ответ другому". Нет сохраняющегося состояния вьюшки — нет MVC. Комбинацию клиент+сервер уже можно рассматривать как MVC, точнее на клиенте MVC, но модель синхронизируется с мастер-моделью на сервере.
Я рассматриваю клиент-сервер как MVC, в котором V и C размазаны между клиентом и сервером. Что между клиентом и сервером есть односторонний синхронный канал "запрос-ответ" — деталь реализации, обусловленная протоколом обмена. Что на клиенте может быть дублирование модели и свое MVC — деталь реализации.
Чем бизнес оперирует — то и есть сущность.
Очень отличается от классического определения сущности в моделировании предметных областей. Как минимум, бизнес оперирует сущностями и процессами, в которые сущности вовлечены. Например, сущности "клиент" и "договор" вовлечены в процесс "заключение договора".
Всё же хотелось бы более конкретный пример. Если есть требование, например, что автор может редактировать статью, то проще, производительнее и надёжней просто проверить авторство (причём это можно делать даже на клиенте, без обращения к серверу), чем городить обращение к ACL и обеспечивать каждого автора правами на созданные ими статьи, а когда логика прав меняется — перетрясать ACL.
ACL просто как пример. Проверять авторство — да, но в слое проверке прав доступа писать
$userCanEdit = ($article->author === $user) || $user->hasGroup('admin', 'moderator') || $user->hasPermission('edit_any_article') || ($user->birthDate == new \DateTime('1975-05-03'));
а не в методе Article::isEditableBy(User $user) то же самое — слишко сильная связанность с User получается.
И способ хранения и сущности, и прав особого значения не имеет для бизнеса, как правило.
vintage
28.02.2017 18:15Как минимум, бизнес оперирует сущностями и процессами, в которые сущности вовлечены. Например, сущности "клиент" и "договор" вовлечены в процесс "заключение договора".
От того, что некоторые сущности назвали процессами, они сущностями быть не перестали. Процесс "заключение договора" сам по себе вовлечён в процесс "продажа товара", который агрегирован в сущность "продажи".
не в методе Article::isEditableBy(User $user) то же самое — слишком сильная связанность с User получается.
И что в этом плохого?
И способ хранения и сущности, и прав особого значения не имеет для бизнеса, как правило.
VolCh
28.02.2017 18:48От того, что некоторые сущности назвали процессами, они сущностями быть не перестали. Процесс "заключение договора" сам по себе вовлечён в процесс "продажа товара", который агрегирован в сущность "продажи".
Сущность — вещь, процесс — действие.
И что в этом плохого?
На любой чих службы безопасности и т. п. нужно менять бизнес-логику. На любое изменение сущности пользователя нужно менять бизнес-логику.
Формат хранения определяет мышление
Я вообще стараюсь не думать о хранении пока не определюсь с объектной моделью. Выбор из SQL, noSQL или вообще в какого-то веб-хранилища последний этап.
vintage
28.02.2017 19:21Сущность — вещь, процесс — действие.
А что толку от этого переименовывания? Суть остаётся та же. Действие, как и любая вещь, обладает состоянием, связями с другими вещами. Как и любые вещи, действия складываются в различные коллекции. Даже процессорные потоки — это не более чем особые структуры. Что уж говорить про собственно процессы.
На любой чих службы безопасности и т. п. нужно менять бизнес-логику. На любое изменение сущности пользователя нужно менять бизнес-логику.
И? Если вы перенесёте эту функцию из файла А в файл Б, связанный с первым как 1-к-1, что-то сильно изменится?
Выбор из SQL, noSQL или вообще в какого-то веб-хранилища последний этап.
А с какими типами СУБД вы работали? Ну, помимо реляционных и словарных.
VolCh
28.02.2017 19:55Действие не обладает состоянием. Оно либо есть, либо его нет. Можно условно считать, что состоянием действия является супепозицией состояний всех вовлеченных сущностей, но это только условность.
С большой вероятностью у нас будет не два файла, связанных 1-1, а множество, связанных с Б (пользователем) многие-к-одному. И при размещении логики проверки прав преимущественно в сущностях (все их там разместить скорее всего не получится, если молотком не вбивать), при изменении сущности пользователя нужно будет менять все сущности модели.
dBase к каким относится? ) А так из экзотики xBase и Db4o немного крутил.
vintage
28.02.2017 20:36Действие не обладает состоянием. Оно либо есть, либо его нет.
Процесс обладает состоянием. Например, текущая стадия.
при изменении сущности пользователя нужно будет менять все сущности модели.
Зачем? Реализуйте тот же интерфейс.
dBase к каким относится? ) А так из экзотики xBase и Db4o немного крутил.
Первая — реляционная. Остальные — хз. Попробуйте поиграться с какой-нибудь графовой. Даже если не будете использовать в дальнейшем, это заставляет взглянуть по другому на привычные вещи.
VolCh
01.03.2017 08:06Сложно представить процесс, в котором есть бизнес-необходимость хранить текущую стадию отдельно от сущностей в него вовлеченных.
Речь об изменении интерфейса сущности пользователя.
Я приверженец подхода по которому система хранения должна минимально влиять на объектную модель. Посмотрю, может быть некоторые мои модели удобнее будет хранить в ней, чем в реляционных или документных.
vintage
01.03.2017 09:19Сложно представить процесс, в котором есть бизнес-необходимость хранить текущую стадию отдельно от сущностей в него вовлеченных.
Процесс "списание товара". Подчинённый подготавливает список товаров, руководитель подтверждает или нет, бухгалтер оформляет списание официально, только если списание подтверждено.
Речь об изменении интерфейса сущности пользователя.
Значит всю логику работы с пользователями нужно будет перетрясти. И будет проще, если эта логика лежит рядом с соответствующими сущностями, а не где-то в сторонке.
VolCh
01.03.2017 10:13- (подчинённый создал список в системе и начал заполнять) у сущности "список товаров на списание" статус "новый"
- (подчиненный отправил на рассмотрение руководителю) у сущности "список товаров на списание" статус "на рассмотрении"
- (руководитель рассмотрел) у сущности "список товаров на списание" статус "утвержден" или "отклонен"
- (бухгатер оформил) у сущности "список товаров на списание" статус "утвержден" и с ней связана бухгалтерская проводка
Этап процесса однозначно определяется состоянием сущности "список товаров на списание" и наличием связанной с ней проводки. Причём связь может быть односторонней — только проводка ссылается на список. А собственного состояния у процесса и нет. Каждый этап должен иметь результат в виде создания, изменения или удаления каких-то сущностей.
vintage
01.03.2017 10:21Причём связь может быть односторонней — только проводка ссылается на список.
Ссылка — это тоже состояние. Вам не кажется странным, что у вас тут две сущности, связанные 1-к-1 и которые всегда существуют в паре? Что вы выиграли от такого условного разделения "процесса списания", на "проводку" и "список товаров" (который на самом деле не список, а полноценный документ с подписантами, количеством, ценами и прочей требухой — почему бы не назвать этот документ "проводкой"?)?
VolCh
01.03.2017 10:45Не всегда. Проводка формируется только если список утвержден руководителем (представим, что бухгалтерия права голоса не имеет). Более того, руководитель может утвердить список лишь частично (для простоты в комментарии) и проводка не будет соответствовать списку.
В целом, исходя из своих знаний и опыта в областях оперативного и бухгалтерского учёта, как в теории так и на практике, а также контекста топика и треда решил, что первичный документ на списание должен быть отделён от проводки по многим причинам, одна из которых стоимость лицензий на бухгалтерскую программу для подчиненного и руководителя.
vintage
01.03.2017 14:20Представим что мы реализуем полный жизненный цикл. Какой смысл разделять эти сущности? Предлагаете дублировать сущность и "закрывать" предыдущую после каждого пройденного шага процесса? А если надо будет вернуться на шаг назад не потеряв при этом привязанные к сущности обсуждения в почте?
VolCh
01.03.2017 15:14Простой — это разные выделенные контексты. Оперативный документооборот и бухгалтерский учёт. Нет смысла создавать бухгалтерские проводки "в планах" на каждый чих, особенно если 90% из них руководством не утверждается. Ну а если в требованиях априори есть, что в процессе утверждения список товаров может измениться и необходимо хранить первоначальную заявку, то мы очень сильно усложним систему, не разделив эти слаюосвязанные и в реальной жизни сущности.
vintage
01.03.2017 19:4999% утверждаются. 1% уточняется и потом всё же утверждается. Первоначальная никого не интересует, но после утверждения изменяться состав списка не должен.
Fesor
28.02.2017 10:26В рамках REST это в любом случае остаётся — запрос ответ.
Вот только есть мнение что подход в чистом виде устарел немного, требования сейчас чуть-чуть другие.
В целом подход запрос-ответ хорошо ложится на MVA.
vintage
28.02.2017 18:19Я проспал statefull революцию?
Fesor
28.02.2017 19:49+1graphql + subscribe пиарят, все чаще вэбсокеты для мобилок юзаются с доставкой ивентов на сервер вместо стэйта… Не уверен что это "революция" но тенденция есть.
Ну и в целом есть нюансы, можно сделать stateless сервер (легко скейлить) с подпиской на изменения данных используя websockets.
vintage
28.02.2017 20:41Вебсокеты батарейку кушают, поэтому лучше всё же централизованные пуши.
Полноценный subscribe я мало где видел. Но подписки — это очень уж ограниченное состояние. Я бы сказал statefew.
Fesor
28.02.2017 23:52+1Вебсокеты батарейку кушают, поэтому лучше всё же централизованные пуши.
Батарейку они кушать могут только за счет проверки соединения (ping/pong). В библиотеках типа socket-io вы можете сами выставлять "частоту" проверок. Ну а в бэкграунде на всяких там iOS у вас всеравно нет выбора — надо юзать пуши.
Ну и в целом у пушей тоже есть ограничения, вроде отсутствия гарантированной доставки (иногда важно знать что было доставлено на клиент а что нет). Так же у эпл есть небольшие ограничения по частоте отправления пушей. Ну и иногда нужно организовывать весьма интенсивное взаимодействие между клиентом и сервером.
Но подписки — это очень уж ограниченное состояние. Я бы сказал statefew.
Ну так это же хорошо :)
Delphinum
27.02.2017 17:09Эмм… А вашей модели «Статьи» нужно знать, что есть такие юзеры, как админы?
vintage
27.02.2017 21:01+1Да, и "Админы" — это тоже модель.
Delphinum
27.02.2017 21:04+1Ну хз, я стараюсь модели максимально ограничить в знаниях. ACL по админам и авторам точно не реализовываю через уведомление Статьи о том, что в ее окружении существуют некие пользователи, которые и не авторы, но тоже важны. Зачем об этом знать Статье? (вопрос риторический)
vintage
27.02.2017 21:37+1Доменная модель естественным образом представляется в виде графа, где все узлы друг с другом перелинкованы. Пользователь логически "знает" о всех своих статьях точно также как и статья "знает" о своём авторе. Да, это не вписывается в реляционную модель, где связь многие-ко-многим эмулируется через поиск по индексу. Если же вы попробуете использовать графовую субд, то перестанете удивляться тому, что многие сущности знают друг о друге. Статья знает об авторе, пользователь о своих группах, группа о ролях, роли… о статьях :-)
Конечно, все эти связи есть смысл хранить, если не требуется их быстрый поиск, но многие можно вычислять динамически разворачиванием графа.
Delphinum
27.02.2017 21:59Статья то не «знает» о таких пользователях, как «Админ». Более того, Статье вообще незачем «знать» о ACL-Ролях. Под «знать» я понимаю не наличие ссылки, а скорее возможность одного объекта использовать другой в своей деятельности.
vintage
27.02.2017 22:07Почему это незачем, если ей, чтобы рассказать о правах, надо знать о ролях?
Delphinum
27.02.2017 22:15А зачем Статье рассказывать о правах? Статья это не ACL, у нее другие обязанности.
vintage
27.02.2017 22:19Затем, чтобы её правильно визуализировать.
У статьи вполне конкретные уникальные правила проверки прав. Зачем их уносить далеко от реализации собственно этой модели?Delphinum
27.02.2017 22:28Возможно я плохо понимаю вашу задачу, но при чем тут визуализация Статьи? ) Если пользователь пытается открыть статью, действуют правила ACL, если же нужно не показывать ссылку на статью в GUI, то достаточно воспользоваться Спецификацией при выборке.
VolCh
28.02.2017 06:54Это не у статьи проверки, это у пользователей. :) Посмотрите на реальность — у документов нет систем проверки прав, есть комплекс мер, которые мешают не авторизованному пользователю получить доступ к совсекретному документу, но сам документ лишь чистая информация.
Fesor
27.02.2017 23:30Более того, Статье вообще незачем «знать» о ACL-Ролях.
Сильно зависит от задачи. Частенько именно "статья" сможет сказать кто ее может редактировать. Например только ее автор. Эта информация доступна только ей.
Но не надо пытаться "обобщить" все на счете.
Delphinum
27.02.2017 23:48Например только ее автор
Меня смущает не то правило, что про автора, а то, что про Админа. Статье не нужно знать о наличии Ролей в приложении.
VolCh
28.02.2017 07:01Не так уж частенько, на самом деле. Скорее это исключение, что статья знает кто её может редактировать, а не правило. Статья может сообщить системе проверки прав доступа, кто её автор, если системе это нужно, но держать в сущности статьи список всех пользователей и(или) пускай групп, которые могут её редактировать — перебор.
vintage
28.02.2017 09:13VolCh
28.02.2017 09:41+1Судя по первому взгляду там не запись знает, кто её может редактировать, а система проверки прав доступа решает по метаданным, сохраненной в одной записи с основными данными. И я сильно удивлюсь, если в этой СУБД нет суперпользователя, который может отредактировать запись, даже если его нет в метаданных записи. В любом случае не похоже, что там хранится полноценный объект, а не, максимум, его данные и метаданные.
vintage
28.02.2017 18:47Пользователь там — это просто запись типа OUser в БД. Если входишь под таким пользователем и обращаешься к restricted записям, то срабатывает повешенный на них хук, проверяющий права. Хук наследуется от суперкласса ORestricted и к неунаследованным от него записям не применяется. Так что фактически это объект со своим состояним и поведением.
Ну, и да, всегда можно войти администратором кластера и воротить что угодно, но это к бизнес-модели уже не относится :-)
VolCh
28.02.2017 19:33Так что фактически это объект со своим состояним и поведением.
Не согласен. Поведение (проверка прав) не принадлежит записи, из записи только иногда (например если юзер не суперюзер) берутся данные для выбора той или иной стратегии поведения для системы проверки прав доступа. Не называем же мы объектом сишную структуру, которую читает какая-то функция. Смысл объекта — поведение вместе с данными, а не снаружи.
vintage
28.02.2017 20:46Покажите мне хоть один компилируемый ООП язык, где методы принадлежат объектам :-D Везде методы — это отдельно лежащие функции, которым в качестве контекста передаётся ссылка на структуру. Обычно в самом объекте максимум, что хранится — это ссылка на таблицу виртуальных методов.
В случае ORestricted — у записи есть ссылка на её класс, у класса — на супер класс, на суперклассе навешан хук. Та же таблица виртуальных методов, только в профиль.
Fesor
01.03.2017 00:01+1Покажите мне хоть один компилируемый ООП язык, где методы принадлежат объектам
покажите мне хоть один пример чистой функции, при компиляции которой не изменяются значения регистра переходов процессора.
Это я пытаюсь донести что вы предлагаете снять один из уровней абстракций. В ООП важным является поведение объекта. Да, само по себе поведение это просто функции которые лежат отдельно и есть некая таблица вызовов. При вызове в рантайме подставляется контекст.
Вот только ООП оно не про объекты. "Все есть объект". Это не значит что у всего должен быть класс, это буквально означает что "любая штука есть объект". Скаляры — объекты, просто в некоторых языках у них нет поведения. Даже в языках вроде Erlang мы можем под объектом со своим стэйтом и поведением понимать тред. И треды между собой будут обмениваться сообщениями. И можно подменять треды в рантайме (late binding).
То есть совершенно не важно что вы называете объектом. Важно то, что статически, на уровне исходников, у вас стэйт и обработка этого стэйта будут максимально рядом. Инкапсуляция и data-abstraction. А как оно там в рантайме — нам не особо интересно с практической точки зрения. Семантический разрыв и все такое.
VolCh
01.03.2017 08:15Таблица виртуальных методов — техническая деталь реализации, логически же метод принадлежит объекту.
Вы делаете что-то вроде Record::findById(1)->read(): record, когда получаете отлуп от системы управления правами или делаете Record::findById(1): record? Если второе, то проверкой права на чтение данных записи занимается не запись. Если первое, то как ограничить право, чтобы клиент не узнал о существовании записи в одних случаях, и узнал но не мог прочитать — в других.
vintage
01.03.2017 09:36Логически и в OrientDB хук принадлежит записи :-)
Если нет права на чтение, то запись просто не будет найдена в поисковых запросах. Если у вас есть её идентификатор, то будет отлуп при попытке чтения её данных.
VolCh
01.03.2017 10:53Каждая запись знает, что есть суперюзер и его надо пускать всегда?
Кем не будет найдена, если проверка прав осуществляется в записи? Сначала найдётся для движка, а потом сама удалится при попытке движка отдать её? Или, всё таки, движок её найдёт, увидит, что пользователь не в ACL записи и не суперадмин и исключит из результатов? А если надо различать ситуации "не найдена" и "нет прав доступа" при общем запросе типа "вывести список всех сотрудников, а также их оклады если пользователь является начальником сотрудника"?
vintage
01.03.2017 14:29Хук скорее всего знает, да.
Скорее всего движок попытается прочитать, сработает хук, который проверит права и даст отлуп, а движок пропустит эту запись. Но я не особо знаком со внутренностями. Да это и не важно — для пользователя "объект сам знает кто как может с ним работать".
Очевидно, оклады должны лежать в отдельных записях с отдельными правами. В OrientDB минимальная гранулярность прав — объект. Я на уровне приложения реализовывал уже гранулярность до конкретных свойств.
VolCh
01.03.2017 15:18для пользователя "объект сам знает кто как может с ним работать".
Если движок пропускает записи, с которым пользователь не может работать, а не даёт отлуп на всю выборку, то не объект, а движок знает.
В OrientDB минимальная гранулярность прав — объект.
Тогда для очень многих схем управления доступом он не подойдёт. Очень часто права ограничиваются к полям объектов и нередко в зависимости от состояния этой, а то и других сущностей.
vintage
01.03.2017 19:51Движок спрашивает у объекта.
Сложную логику вам и ACL не заменит. Только код.
oxidmod
24.02.2017 10:38Вы извините конечно, но чем вас не устраивает один класс-экшен с внедрением через конструктор? У вас лимит на количество классов? оО
VolCh
24.02.2017 11:21А чем вас не устраивает класс из нескольких экшенов? У вас лимит на количество методов в классе? :)
oxidmod
24.02.2017 11:33Ну человек же борется с километровыми конструкторами путем внедрения необходимых каждому методу зависимостей прямо в екшен.
Мне такой поход кажется весьма странным, так как в аргументах смешиваются зависимости и непосредсвтенно аргументы. Проще зависимости в конструктор.Fesor
24.02.2017 11:48+1Ну человек же борется с километровыми конструкторами путем внедрения необходимых каждому методу зависимостей прямо в екшен.
не совсем. Я борюсь с lack of cohesion. У меня есть по классу на экшен приложения, по классу на юзкейс. А контроллеры лишь являются адаптером между HTTP и этим "юзкейсом". Мне проще сделать один класс с 5-ю экшенами связанными по смыслу, а поскольку всем 5-ти экшенам нужны разные зависимости инъектить их через конструктор как-то не очень выгодно.
так как в аргументах смешиваются зависимости и непосредсвтенно аргументы.
А что, аргументы уже не являются зависимостями? Да, это зависимость по данным, но смысл примерно тот же. Грубо говоря у вас будет "запрос" + 1-2 зависимости для обработки этого запроса. Почти всегда. Крайне редко вам понадобится что-то сложнее.
oxidmod
24.02.2017 12:46Но дабл диспатч привязывает вас к контейнеру который умеет в дабл диспатч. Зачем это нужно?
Fesor
24.02.2017 22:10Но дабл диспатч привязывает вас к контейнеру который умеет в дабл диспатч.
Нет, дабл диспатч привязывает меня к мидлвари которая достаточно умная что бы сделать
$container->get(Foo::class)и заполнить аргументы метода. А делать свои имена сервисов умеют все.
Если что — контейнер симфони этого не умеет из коробки. У меня есть ~80 строк кода которые добавляют эту функциональность + кэширование.
Fortop
24.02.2017 13:39Тем что при слабой связности вы будете иметь раздутый конструктор для всех зависимостей. При том что в самих action все одновременно они не требуются.
Вот для случаев описанных ниже
один класс с 5-ю экшенами связанными по смыслу,
Можно.
Я только не совсем понимаю почему они связаны между собой, а зависимости при этом у всех разные…
Из чего и возникает потребность получать зависимости непосредственно при вызове actionDelphinum
24.02.2017 14:35Я только не совсем понимаю почему они связаны между собой, а зависимости при этом у всех разные…
Поддерживаю. Видимо связываются они не общими механизмами или границами доступа, а правилами роутинга или чем то подобным.
Fesor
24.02.2017 22:16Я только не совсем понимаю почему они связаны между собой, а зависимости при этом у всех разные…
Потому что слегка разные операции + у меня есть отдельные классы которые реализуют одно конкретное действие.
есть у меня например ресурс
/accounts/{id}. Он содержит в себе операции над этими ресурсами:
- PUT
/accounts/{id}— создание аккаунта - GET
/accounts/{id}— детали аккаунта - POST
/accounts/{id}/withdrawn— вывод средств
С точки зрения группирования операций мне удобнее держать их в одном классе как 3 экшена. Просто с точки зрения структурирования кода.
Причем для всех трех операций у меня свои зависимости. Для создания аккаунта я хочу сервис который умеет их делать, записывать в базу и т.д. Для второго мне нужен сервис, который достанет нужную информацию об аккаунте. Это не может быть тот же сервис что и для создания аккаунта ибо они могут даже с разными базами данных работать. И для вывода средства у меня есть третий сервис, поскольку он работает больше с пеймент гейтвеем и с точки зрения бизнеса это совершенно отдельный процесс. Но с точки зрения пользователя — оно все рядом.
Fortop
27.02.2017 14:44
Вот вариант когда отдельные классы на каждый тип действия
И естественно фабрики для них примерно так выглядят
App\Action\User\Register::class => function (ContainerInterface $container) { return new \App\Action\User\Register( $container->get(RouterInterface::class), $container->get(TemplateInterface::class), // прочие зависимости ); }, App\Action\User\Login::class => function (ContainerInterface $container) { return new \App\Action\User\Login( $container->get(RouterInterface::class), $container->get(TemplateInterface::class), // прочие зависимости ); },Fesor
27.02.2017 18:32+1- Invoices - Handler - PurchaseProductHandler - TransferMoneyHandler - PayTheInvoiceHandler - Model - Infrastructure - Http - Orders - Handler - AskForRefundHandler - ...
У меня примерно так. Но все равно нужны контроллеры, а "хэндлеры" это просто application-level сервисы, реализация отдельных юзкейсов. Директории верхнего уровня описывают ограниченные контексты (Bounded Context).
- PUT
Fesor
24.02.2017 11:44У вас лимит на количество классов? оО
У меня лимит на количество кода не приносящего пользы. Чем меньше — тем лучше. У меня лимит на количество кода в экшене контроллера.
Fesor
23.02.2017 18:34Увы в реальности так красиво выходит только на очень простых задачах. В остальных случаев хоть какой-то адаптер нужен для каждого конкретного UI. То что мы потом сверху можем через контент негошиейшен разруливать делать json или html — это мелочи.
Fesor
23.02.2017 18:33+1А флаш где делать? Мне его надо сделать между "сделал дело" и "сделал выборку для респонса".
Более того, я и так это делаю в мидлварях. Просто у меня всеравно есть необходимость юзать контроллер как точку, которая уже разделяет операции чтения и записи.
Delphinum
23.02.2017 22:24Да где угодно. Если есть слой сервисов, то думаю в нем, если нет, можно в контроллере или даже можно реализовать специальный Middleware для этих целей. Вариантов куча.
Fesor
23.02.2017 22:29Если есть слой сервисов, то думаю в нем,
а я думаю в том месте, которое регламентирует границы бизнес транзакции. То есть если у нас есть сервис уровня приложения, который описывает какой-то юзкейс, или бизнес транзакцию, то флаш должен быть сразу после вызова этого сервиса.
Через такие штуки как AOP мы можем это разрулить (декорация или ивенты неудобно).
можно реализовать специальный Middleware для этих целей. Вариантов куча.
В этом случае для каждой бизнес транзакции нам нужна мидлваря а при таком раскладе у вас разница между контроллером и мидлварем невилируется. Я вообще не понимаю о чем спор. Покажите мне код который не требует наличия контроллеров, а я скажу что это либо "тоже самое" либо "вот вам причины почему это неудобно".
Delphinum
23.02.2017 23:55а я думаю в том месте, которое регламентирует границы бизнес транзакции
Вполне себе вариант.
Покажите мне код который не требует наличия контроллеров
Выбирайте любой — http://stackphp.com/middlewares/
Понятно, что это можно добавить в контроллер и на выходе мы получим, как бы контроллер, но эти решения проще компоновать.Fesor
24.02.2017 11:50+1повторю еще раз — мидвари это просто цепочка адаптеров. контроллер = адаптер на границе приложения и UI layer. Вы можете делать все так что бы "контроллер" был лишь одним из элементов цепочки мидварей.
p.s. я использую мидлвари, у меня туда вынесены кеширования, аутентификация, jwt авторизация, есть еще кое какие мои мидлвари которые занимаются раграничением прав, но у меня все еще есть контроллеры и за пол года размышлений я не смог от них отказаться. Из вариантов которые пока не пробовал и которые могут подойти — использование graphql или подобных подходов, где вот этот вопрос "что делать после изменения данных" регламентируется на уровне запроса клиентом. В этом случае всем этим может заниматься одна единственная мидлваря.
Fortop
23.02.2017 15:01Ну то есть кода меньше, делает одно и то же.
Это в том случае если зависимости типичны для группы action.
Ну так и сделать наследование никто не мешает — некий CommonAction
А если нет?
Не совсем понял, кто и когда в вашем примере делает инъекцию зависимостей в методы action?
Router?
Проблема обычно с http реквестом или с flush-ем доктрины. Все равно нужна какая-то одна штука на запрос которая будет связывать все вместе.
Все это что? Запрос и работу с моделями доктрины?
marenkov
23.02.2017 12:08Это когда зависимости для метода прокидываются как аргументы этого метода:
Сейчас работаю в проекте на Zend. Там все так сделано. Пекло пекельное.
Когда у метода одна зависимость, как в вашем примере, еще ничего, а представьте пример с 5-ю зависимостями плюс собственными аргументами метода. Каждый вызов такого метода — простыня из аргументов. Да и объявление выглядит уродливо.Fesor
23.02.2017 14:05а представьте пример с 5-ю зависимостями
у меня есть правило — у любой штуки не должно быть более 3-х зависимостей. Если у вас их больше — вам нужно подумать больше над декомпозицией.
Fortop
23.02.2017 14:51Зависимости в конструктор.
Если всего много и объекты сложный, то создаётся фабрика.
Или builder для инжекции зависимостей.
А параметры идут уже непосредственно при вызове
Delphinum
23.02.2017 14:44Хорошо подходит для экшенов контроллеров
Я предпочитаю контроллеры вида:
public function *Action(Request, Response, [$next]){ ... }
Потому такое мне не очень подходит )
Поясню свою мысль
Честно говоря не понял вашу мысль ) По моему мнению контроллеры зависят не от фреймворков, а от семантики запросов/ответов.
Fesor
22.02.2017 00:23+1в 2017-ом году сервисы менеджеры сущностей являются моветоном. Хотя и в нулевых так было...
/** * @Route("/greetings/{id}", requirements={"id": "\d+"}, methods={"GET"}) */ public function greatingAction(int $id, Greater $greater) { return $this->json([ 'greating' => $greater->greet(), ]); }marenkov
22.02.2017 00:44+1int $id в параметрах лишний, он автоматически будет преобразован в Greater $greater
А так да, это самый правильный вариант. Хоть для новичков и многовато магии.Fesor
23.02.2017 01:53нууу я не сторонник идей что бы сущность попадала в контроллер (хотя так часто делаю ибо ленивый), ну а в моем примере
Greaterэто сервис. И да, у меня симфони так умеет)
marenkov
22.02.2017 14:18В данном случае лучше всего автоматический конвертер передающий конструктору готовую сущность, ок. А что предлагаете использовать для манипулирования сущностями вместо сервиса менеджера сущностей?
Контроллер-сервис, как выше, не предлагать — плодить десятки, а то и сотни сервисов, которые таковыми не являются, да еще и инициализируют другие сервисы, которые могут им и не понадобиться ничем не лучше толстых контроллеров.
knekrasov
20.02.2017 11:24+10Полагаю, что требования к Hello world звучат примерно так «нужно уметь выводить надпись Hello world». Точка.
Даже помня, что «выводить» можно теоретически не только в консоль, реализация слишком усложнена.
Откуда у вас взялись REST, Postgres и куча фреймворков? Где тогда load balancing, горячий кэш данных и (конечно же!) MongoDB? Усложнять так усложнять!
alix_ginger
20.02.2017 12:34+1Полагаю, что требования к Hello world звучат примерно так «нужно уметь выводить надпись Hello world». Точка.
Надо быть готовым, что в последствии нужно будет выводить надпись «Good evening world» или «Good morning world» в зависимости от времени суток, на выбранном языке, а потом дать возможность пользователю самому выбрать свое приветствие, и так далее.Delphinum
20.02.2017 12:42+4Не забывайте о дизайне! Кому нужно некрасивое приложение?! Без Sass и Compass это не современное PHP Hello world!
knekrasov
20.02.2017 16:01+1И, видимо, уметь получать последний вариант текста из какой-нибудь Кафки или ZMQ. Ну и уметь масштабироваться, а то мало ли, вдруг мощностей не хватит.
Только вот обычно цель hello world познакомиться с базовыми возможностями языка/платформы, а не предугадать все грабли, на которые придется наступить в «реальной» жизни (кстати, реальность тоже у всех разная). Такое нагромождение сложности у здравомыслящего новичка вызовет только рвотный рефлекс.
lehha
20.02.2017 11:27+6Сейчас тяжело найти нормального программиста, который умеет писать на ГОЛОМ PHP! Нет, движок у проекта есть, но модули почти на 80% состоят из обычного функционального программирования. Попросишь написать небольшую фичу, так он привязывает еще тонну файлов фреймворка.
Это относится как к Frontend, и в большей степени к Backend — где одни демоны, кроны и консоли.
Если программист может решить задачу на голом php, то он сможет и разобраться в фреймворке. А вот наоборот — не суждено.
rsvasilyev
20.02.2017 11:51+19Может потому что нормальные программисты не хотят сидеть и допиливать проект из «80% обычного функционального программирования», которое на самом деле процедурное?)
lehha
20.02.2017 12:46+3А чего допиливать? Например, проекту более 5 лет, он не падает после yum update, нет каких-либо зависимостей, нет отсутствия обратной зависимости. 100% кода в бэкенде такое, выглядит красиво, работает стабильно, дебажится стандартными инструментами, нет скрытой логики.
Frontend действительно стоить держать в современном виде, но главное не зарываться. Сайт Тинькофф-банка грузится сотней запросов к серверам (бесит). Сайт старого банка — двумя запросами. Скорость не в пользу Тинькова…
Fesor
21.02.2017 09:46+1выглядит красиво
весьма субъективная метрика.
работает стабильно
А насколько хорошо расширяется? Есть ли статистика регрессий в коде?
нет скрытой логики.
Неужели нет ни одной глобальной переменной?
lehha
21.02.2017 10:33Расширять бизнес-логику приложения, которое не меняется годами — не нужно. Если необходимо запилить в приложении с названием «калькулятор» вызов такси Убер (или Умер), то это неправильно поставленная задача.
Нет, глобальных переменных нет. Хотя в блоке управления двигателем одного производителя нашли с тысячу таких переменных…
VolCh
21.02.2017 10:51Расширять бизнес-логику приложения, которое не меняется годами — не нужно.
Даже не знаю сочувствовать или завидовать. Что программист-то делать должен с этим приложением? Многолетние баги фиксить? Микрооптимизациями заниматься? На новые версии PHP переводить?
lehha
21.02.2017 11:12Не трогать это приложение :) Заняться другими вещами, например, новым приложением «Умер» )))
Но бизнес не может быть завязан на одно приложение, поэтому всегда найдется работа: запилить новое, помочь клиентам решить старые проблемы, создать новые проблемы))VolCh
21.02.2017 12:10В последнее время у заказчиков идеа-фикс единое приложение для всего. Или, хотя бы, единообразность всех приложений.
VolCh
20.02.2017 12:37+3На голый пхп, да ещё процедурный, для приложений с запретом использования сторонних библиотек на пхп вернусь только за очень большие деньги.
ellrion
20.02.2017 11:29+15Автор, В 2017 держать под гитом
.ideaмоветон)varanio
20.02.2017 11:35да, забыл добавить в .gitignore )
ellrion
20.02.2017 11:46+3Есть мнение что помещать в
.gitignoreтоже моветон) Нужно в.git/info/exclude. Но это конечно спорноDelphinum
20.02.2017 12:54+7Есть мнение, что лучше для этого использовать пользовательский файл исключений:
~/.gitconfig
[core] excludesfile = ~/.gitexclude
~/.gitexclude
.idea/
happyproff
20.02.2017 13:27+2Поддерживаю! .idea это часть окружения конкретного разработчика, а не проекта.
iborzenkov
20.02.2017 14:34+2Вообще-то проекта. Из локального там только workspace.xml и tasks.xml.
И если его правильно (https://www.gitignore.io/api/phpstorm) игнорить, то можно таскать настройки стилей кода и прочие вкусности в проекте, а не настраивать все время.
Общие настройки хранятся в ~/.PhpStorm/config по дефолту.Delphinum
20.02.2017 14:39+2Открою вам секрет — в хороших проектах «настройки стилей кода» применяются на уровне git push hook'ов, и являются уровнем инфраструктуры разработки, а не частью проекта.
Зачем мне, как разработчику не использующему PhpStorm, таскать к себе ваши настройки стилей кода, применимые только в контексте PhpStorm? )VolCh
20.02.2017 14:54+1являются уровнем инфраструктуры разработки, а не частью проекта.
Принятая/согласованная/утвержденная инфраструктура разработки неотъемлемая часть проекта. Пускай лучше вы лишний раз скачаете не нужные вам файлы, чем 90% команды будут "переводить" стайл-гайд на "язык" настроек продуктов джетбрэйнс, а то и вычислять стайл-гайд по реджектам от хуков.
Delphinum
20.02.2017 14:59Принятая/согласованная/утвержденная инфраструктура разработки
90% команды будут «переводить» стайл-гайд на «язык» настроек продуктов джетбрэйнс, а то и вычислять стайл-гайд по реджектам от хуков
Если уж в проекте приняли, согласовали и утвердили инфраструктуру, то должны были заодно и подготовить для всех участников окружение для быстрой развертки и работы в контексте этой инфраструктуры. Можно пойти конечно пойти путем: «запуште все в репу, это быстро и просто» — а можно маленько поднапрячься и сделать по хорошему.VolCh
20.02.2017 15:05./idea в репе — часть этого окружения.
Delphinum
20.02.2017 15:07Так себе аргумент. С тем же успехом можно хранить в репе образ ОСи, на которой должен работать проект )
iborzenkov
20.02.2017 15:18+4Ну так в папочке (docker || ansible || provision ||… ) оно обычно и лежит.
Delphinum
20.02.2017 15:22Конфиги PhpStorm тоже обычно лежат в .idea, но это ведь не означает, что их надо пушать в репу )
iborzenkov
20.02.2017 15:12+2Вот именно — напрячься и сделать по хорошему, запушив после этого в репу то что нужно.
В частности и настройки IDE если 90% пользуются ей. Там можно не только стиль кода, там например могут быть уже преднастроенные параметры запуска тестов локально, vagrant или docker, деплой на тестовые сервера. Разумеется это никак не заменяет скажем билд сервера с запуском тестов, анализаторов и форматеров кода, взаимодействие с которыми кстати тоже можно в эти конфиги сохранить.
ellrion
20.02.2017 14:42Это если в команде договор использовать продукт от jetbrains. Смысла так сильно ограничивать команду я лично не вижу. А если же у вас не проект а библиотека, то
.ideaуж точно быть не должно не в репозитории не в .gitignore
vintage
26.02.2017 11:37Есть мнение, что развёртывание проекта должно производиться одной командой и не должно никак затрагивать другие проекты. Поэтому всякие node_modules и .DS_Store помещают в .gitignore, чтобы ни у кого не было с ними проблем. Всего строчка в .gitignore, а одной головной болью меньше. Будьте прагматичными, а не фанатичными.
Fesor
26.02.2017 14:08.DS_Storeлучше в глобальный гитигнор.vintage
26.02.2017 22:18К сожалению, не всегда с вашим кодом работают достаточно компетентные разработчики с хорошо настроенной системой и не ленящиеся читать маны. Так что чем меньше будет инструкция по развёртыванию окружения, тем больше вероятность, что она будет исполнена как следует.
Fesor
26.02.2017 23:06Так что чем меньше будет инструкция по развёртыванию окружения
Ну так я и не буду просить разработчика на arch добавлять
.DS_Storeв глобальный гитигнор. Это его дело. Так что мануал как раз уменьшится, а добавить вообще все что может закоммитить недостаточно компетентный разработчик, это у вас сил не хватит.
А вот когда на ревью придет реквест с закоммиченным
.DS_Storeразработчику придет вот эта ссылка.vintage
27.02.2017 09:53+1Вы будете писать по мануалу для каждой оси? А на собственно код-то время останется? :-)
Уже есть бойлерплейты для гитигнора со всякой ерундой, которую обычно не надо версионировать.
VolCh
27.02.2017 10:39А для IDEA и ко есть плагинчик, который генерирует гитигнор для всякой ерунды в пару кликов, только выбрать используемую ерунду, начиная с самой IDE :)
Delphinum
27.02.2017 15:36Зачем «по мануалу для каждой оси»? Fesor предлагает бить по рукам, если разраб попробует запушать левую зависимость в репу. В результате и мусора не будет, и разрабы научатся думать головой.
vintage
27.02.2017 16:17Чтобы не тратить каждый раз по 10 минут на объяснение почему и как нужно делать, а потом напоминать, когда у них меняется система.
Delphinum
27.02.2017 17:19Ну если работа ведется с очень уж далекими разрабами и лень подготавливать окружение, то, наверно, можно сделать «лишь бы работало»
vintage
27.02.2017 21:05Лучше делать так, чтобы работа с вашим кодом вызывала как можно меньше трудностей у других людей.
Delphinum
27.02.2017 21:16+1Засовывать в .gitignore не относящиеся к проекту файлы это не «работа с моим кодом», это скорее решение вида: «народу много, а я ленивый, сделаю максимально быстро и чтоб работало»
vintage
27.02.2017 21:39Больше прагматизма, меньше идеологии — рекомендую.
И нет ничего плохого в том, чтобы быть ленивым. Если бы не лень, мы бы до сих пор на ассемблере писали.
Delphinum
27.02.2017 22:10Я уже много раз наступал на грабли своей лени, потому выработал для себя простое правило: «Если действию есть правильная альтернатива, то лучше не полениться сегодня, чем страдать завтра» — ведь Закон Мерфи никто не отменял.
vintage
27.02.2017 22:20Вы будете страдать от лишней строчки в gitignore?
Delphinum
27.02.2017 22:35Конечно. У проектного .gitignore вполне определенные цели, как и у git в целом, зачем возлагать на механизм задачи, которые он не должен решать. Можно ведь воспользоваться подходящим инструментом изначально, тем более если речь идет о большом проекте с множеством меняющихся разработчиков.
vintage
27.02.2017 23:09Это был риторический вопрос. И так понятно, то ни у кого никаких страданий по этому поводу не будет. Тоже мне камень преткновения.
Delphinum
27.02.2017 23:14ни у кого никаких страданий по этому поводу не будет
Ну вот он я, и я страдаю, когда вижу в .gitignore что то вроде .idea ) Иногда мы практикуем такое (чаще всего в унаследованных проектах), но я понимаю, что это не хорошо, от чего и страдаю. Когда мне надоедает страдать, я выпиливаю не хорошие решения.vintage
28.02.2017 09:16Могу лишь позавидовать тому, как удалась ваша жизнь, раз страдаете от такой ерунды :-)
Fesor
28.02.2017 10:32Я немного не понимаю вашу позицию… Попробую просумировать
- Мы не можем знать под какой осью и в каком редакторе работает разработчик (это к вопросу об инструкциях про глобальный гитигнор)
- Мы должны добавить все в свой gitignore, при том что мы все еще не знаем под какой осью и в каком редакторе работает разработчик.
То есть… я пока не понимаю что именно вы предлагаете в контексте этого вопроса.
Мой же вариант — не делать ни того ни того. У всех моих разработчиков настроен глобальный гитигнор. Если мне приходят PR в github и там закоммичено что-то что не должно коммититься — он получит ссылку на доку про глобальный гитигнор и настроит его себе либо удалит файлы из коммитов.
Эффортов — ноль (ну или почти ноль), гитигнор чистый и там только то что относится к проекту, не надо писать километровые доки (они уже написаны).
VolCh
28.02.2017 07:08Цели в проекте .gitignore и git в целом определяет руководство проекта, а не разработчики git. Есть хороша известная возможность у инструмента "из коробки", хорошо подходящая к задачам проекта. Почему бы её не использовать, а не искать другие инструменты или другие возможности у имеющихся? Вот вы страдаете от .idea в игноре, а я страдаю от неё в проекте. Какой ещё способ можете предложить, чтобы новый разработчик случайно не закоммитил каталог .idea? Крайне желательное требование — способ должен быть неотрывно связан с репозиторием.
Delphinum
28.02.2017 13:25Цели в проекте .gitignore и git в целом определяет руководство проекта, а не разработчики git
И это не хорошо. Вы можете гвозди и мотыгой забивать, но есть куда более удачный инструмент для этой задачи. Так же и у git с gitignore, они создавали для решения определенного круга задач. Да, с их помощью можно решить и некоторые смежные задачи, но нужно ли поддаваться желанию «сделать проще»?
Почему бы её не использовать, а не искать другие инструменты или другие возможности у имеющихся? Вот вы страдаете от .idea в игноре, а я страдаю от неё в проекте. Какой ещё способ можете предложить, чтобы новый разработчик случайно не закоммитил каталог .idea?
В git не случайно заложено несколько уровней исключения. «Уровень пользователя» как раз позволяет разработчикам исключить из всех своих проектов не относящиеся к ним данные. Вот представьте, что вы фрилансер и каждую неделю у вас по 1-2 новых проектов. Плюс к этому, вы пишите собственные пакеты «на будущее», и храните их, к примеру, на github. Вам нужно для каждого проекта заботиться о заполнении его локального gitignore файла, когда можно один раз заполнить такой же файл, но на уровне пользователя. Согласитесь, это намного проще и удобнее, потому что правильно.
Аналогично дело обстоит с группой разработчиков. Fesor верно заметил, что при изучении коммита разраба всегда можно указать ему на его же ошибки, в том числе относящиеся к окружению. Это просто для вас, и понятно для разраба.
Крайне желательное требование — способ должен быть неотрывно связан с репозиторием
Вы превращаете репозиторий в проект, но это две разные вещи. Git и репозиторий, созданные с его помощью не являются проектом, они лишь его часть, и не нужно в них пихать все, что с проектом связано. У нас же есть облачные хранилища, есть онлайн редакторы документов, пользуйтесь ими, связывайте все ссылками из вашей проектной вики.
Fesor
27.02.2017 18:33Уже есть бойлерплейты для гитигнора со всякой ерундой, которую обычно не надо версионировать.
А вы предлагаете сразу для всех осей и IDE запихнуть в gitignore?
я указал ссылку где есть ссылки на бойлерплейты и описание что зачем и куда) Как по мне ссылки на этот док достаточно.
vintage
27.02.2017 21:14Всё, что актуально для проекта.
По вашей ссылке много чего предлагают в игнор засунуть, не всё это в конкретном проекте должно игнорироваться. Например, в каком-нибудь проекте *.sql могут быть необходимы. Человек скопипастит этот бойлерплейт и огребёт проблем на ровном месте. Всё же мейнтейнеру виднее какие файлы в проекте нужны, а какие — нет.
Fesor
27.02.2017 23:32Всё же мейнтейнеру виднее какие файлы в проекте нужны, а какие — нет.
Потому я и сказал что кину ссылку во время код ревью человеку который не то закоммитил.
VolCh
28.02.2017 07:09Главное, чтобы разрушать репозиторий не пришлось, если в него утекли чувствительные к разглашению данные.
Atreides07
20.02.2017 11:46+1Простите за оффтоп, но как же раздражают многочисленные "в 2017 году". Т.е. в 2016 можно было говнокодить по страшному и резко, меньше чем за 2 месяца все прозрели и стали писать абсолютно по другому?
berezuev
20.02.2017 11:49+25
Falseclock
20.02.2017 11:59-3Не согласен с автором. Любой нормальный программист должен пройти этап эволюции от говнокода до написания собственных фреймворков. А не использовать готовые, которые сводят на нет суть программирования.
lair
20.02.2017 12:01+9Я надеюсь, вы не используете готовые высокоуровневые языки, которые сводят на нет суть программирования? Только машинный код?
Falseclock
20.02.2017 12:10+2Если брать в пример использование PHP как основного языка для веб приложений, то за последние годы мы пришли к тому, что это программисты это те, кто умеет настраивать CMS и сайт готов, позиционируя себя опытным разработчиком.
Типичный пример. Мне надо было сделать интеграцию самописной CRM системой с 1С по REST\OData через HTTP-сервис, который появился недавно в платформе 1С. И что вы думаете? Я обзвонил сотни программистов, поговорил в живую с десятком и не нашел того, кто это может сделать. Они только и делали круглые глаза, даже не представляя себе, что это возможно.
Две недели упорного труда и сам реализовал то что мне нужно не имея никакого опыта программирования в 1С.
Быть инсталлятором фреймов и готовых библиотек — одно, решать задачи не прибегая к готовым решениям — другое. Это и есть путь нормального эволюционного процесса хорошего программиста.
Sky4eg
20.02.2017 12:16+3Ну вы прям утрируете. Где вы находили эти сотни программистов которые не умеют работать с REST и не способных потратить пару вечеров на ознамление с новой ачивкой для себя?
Source
20.02.2017 13:36+4А я верю Falseclock, приходилось несколько лет назад искать 1С-программиста… у них от словосочетания "HTTP-запрос" нервный тик начинается… и про то, что данные можно передавать не только через расшаренные XML-файлы, они даже слышать не хотят. Возможно есть исключения, но вживую не приходилось встречать.
lair
20.02.2017 13:48-1Если брать в пример использование PHP как основного языка для веб приложений, то за последние годы мы пришли к тому, что это программисты это те
[...]
приходилось несколько лет назад искать 1С-программистаХм.
Source
20.02.2017 16:23-2Вы невнимательно прочитали комментарий Falseclock… Цитирую:
Типичный пример. Мне надо было сделать интеграцию самописной CRM системой с 1С по REST\OData через HTTP-сервис, который появился недавно в платформе 1С.
…
Две недели упорного труда и сам реализовал то что мне нужно не имея никакого опыта программирования в 1С.Я понял его мысль так, что бездумное использование CMS/CMF может довести уровень среднестатистического PHP-шника до уровня среднестатистического 1C-ника. Типа делай как в туториале и ни шагу в сторону.
raidhon
20.02.2017 14:12+2В данный момент работаю над сервисом где всё, а это куча сайтов, мобильный сервис на node.js, мобильные приложения и даже телеграм бот отправляет или получает какие нибудь данные от сервера 1С.
Да и вообще все сходиться на 1С там все хранится и все оттуда запрашивается.
Не могу сказать что я в восторге, так как раз я занят тем что пишу( скорее уже поддерживаю так как уже написал ) сервис на node.js и телеграм бота с мобильными приложениями.
Но вся эта система работает ( ещё и на Windows server ) уже без малого полтора года и 1С программист понимает с полуслова что мне нужен ответ в формате json определенной структуры.
Так что программист программисту рознь.Source
20.02.2017 16:27Тут спору нет, все люди разные и распределение квалификации очень широкое. Просто есть мнение, что Вам повезло, найти квалифицированного 1С-программиста не такая уж простая задача.
raidhon
20.02.2017 18:32Ну тут я никого не искал, мне просто предложили проект.
1С программист уже присутствовал в приложении к проекту.
В остальном вы правы думаю компании просто повезло.
А вообще в моей рабочей зоне микросервисов и мобильных приложений, встретить 1С программиста это как с негром познакомиться на слете ку-клукс-клана ))
Сам удивлен таким обстоятельством.
el_gato
20.02.2017 15:15Cмех смехом, а я периодически ловлю себя на мысли что не помню как аякс запрос на js написать без jQuery.
Source
20.02.2017 16:29Ну так, хотя бы помните, что это можно сделать… значит доку нагуглите за пару минут )
justboris
20.02.2017 16:36+1
fetch('/api/endpont') .then(response => response.json()) .then(json => console.log(json))lair
20.02.2017 16:47+4This is an experimental technology
И эти люди говорят нам про фреймворки.
justboris
20.02.2017 16:56Читаем дальше
Because this technology's specification has not stabilized, check the compatibility table for usage in various browsers.
Поддерживается везде, кроме IE (в Edge уже есть). Достаточно, для того чтобы хотя бы попробовать
lair
20.02.2017 17:00+2Понятно, намек на XHR прошел мимо.
varanio
20.02.2017 17:05в любом случае надо использовать fetch. Если нужна поддержка старых IE, то добавлять полифил, да и всё
RubaXa
20.02.2017 17:20Ага, а потом нам требуется прогресс download/upload и
fetchотправляется мусорку.
vintage
26.02.2017 21:52Не надо, как и уже устаревшие "обещания". Сейчас в тренде реактивное программирование.
Fesor
26.02.2017 23:07мне казалось async/await, frp это весело и прикольно и в большинстве случаев не нужно.
Да и как вы там говорили, не всегда компетентные разработчики достаются которые знают что такое frp и как его готовить.
vintage
27.02.2017 10:04Я ничего не говорил про FRP. OORP готовить настолько просто, что с этим справится даже джуниор. А вот async/await, frp — лишние сложности на ровном месте.
Fesor
27.02.2017 18:35-1async/await сложности? Их умеет любой джуниор дотнетчик
vintage
27.02.2017 21:40По сравнению с их отсутствием — да, сложности.
VolCh
28.02.2017 07:10колбэк хелл проще?
vintage
28.02.2017 09:18Нет, проще — синхронный код.
VolCh
28.02.2017 09:45+1Писать проще, да, особенно однопоточный без всякой конкурентности за ресурсы. Но вот нефункциональным требованиям такой код часто не соответствует. А то и функциональным.
async/await как раз способ сочетать простоту написания синхронного кода с реальной асинхронностью.
vintage
28.02.2017 19:10
Реально синхронный, но неблокирующий код с автоматическим распараллеливанием.
async-await всё же не обеспечивает распараллеливание — нужно позаботиться об этом самостоятельно.
Fesor
28.02.2017 19:51+1const responses = await multipleRequests .map(request => this.preformRequest(request));vintage
28.02.2017 20:53Вы забыли завернуть это в
Promise.all. О чём и речь.
Другой момент — вам нужно собрать все промисы в одну точку, иначе распараллеливания сделать не получится.
Fesor
01.03.2017 00:09-1Вы забыли завернуть это в Promise.all. О чём и речь.
признаю, есть такой момент.
Другой момент — вам нужно собрать все промисы в одну точку, иначе распараллеливания сделать не получится.
А в вашем случае разве не происходит примерно такого же? Ну то есть вам же как-то надо приостановить выполнение кода, как это у вас происходит?
vintage
01.03.2017 09:51В том-то и дело, что нет. То же самое можно было бы переписать так:
@ $mol_mem() header() { return $mol_locale.text( this.toString() + '.header()' ) // там где-то в глубине дёргается файл с локализованными текстами на нужном языке. } @ $mol_mem() sources() { const treeContent = $mol_file.relative( 'quine.view.tree' ).content() const tsContent = $mol_file.relative( 'quine.view.ts' ).content() return `${ treeContent }\n\n${ tsContent }` } @ $mol_mem() content() { const header = this.header() const sources = this.sources() return `# ${ header }\n\n${ sources }` }
И все 3 файла будут загружены параллельно.
Приостановка делается просто — кидается исключение. $mol_mem() заворачивает метод в атом, который это исключение ловит, а наружу светит Proxy, который кидает это исключение лишь при попытке доступа к содержимому результата. Таким образом исполнение продолжается, но в момент, когда мы начинаем работать с результатом, исполнение метода прерывается, если результат ещё не получен.
D01
20.02.2017 19:47+1Большинство программистов 1С, ничего, кроме 1С не знают… Многие даже сетевой адаптер настроить не могут (IP-адрес ввести и т.п.), а Вы REST :-)
Fesor
20.02.2017 19:58Где вы находили эти сотни программистов которые не умеют работать с REST
Вот у меня специфика работы — апишки. И я на собеседованиях обычно не особо спрашиваю про rest просто по одной простой причине — 9/10 обычно начинают про http рассказывать. И для меня разработчик уже неплохо шарит в теме если говорит что оба POST и PUT могут быть использованы как для создания ресурсов так и для их обновления. Да что там, уже хорошо если аббревиатуру REST смогут расшифровать и рассказать как они это все дело понимают (не важно правильно или нет).
То что люди не знают про OData например это меня ничуть не удивляет.
lair
20.02.2017 12:16+2Если брать в пример использование PHP как основного языка для веб приложений, то за последние годы мы пришли к тому, что это программисты это те, кто умеет настраивать CMS и сайт готов, позиционируя себя опытным разработчиком.
Программист — это тот, кто решает задачу заказчика с необходимым качеством (и прочими критериями выполнения). CMS, фреймворк — это не имеет значения.
А уж кто как себя позиционирует — так это личное дело каждого.
решать задачи не прибегая к готовым решениям — другое. Это и есть путь нормального эволюционного процесса хорошего программиста.
Так зачем же вы используете "готовое решение" PHP и "готовое решение" OData? Это совсем не путь нормального эволюционного процесса. Пишите свой язык, делайте свой протокол.
Falseclock
20.02.2017 12:20-1это вы утрируете… и путаете понятия. фреймы — это надстройки. Я не предлагаю изобретать новые стандарты и протоколы. Я о том, что взять чужой код и использовать его, иногда даже не понимая как он работает — одно, разобраться и написать свое — другое.
VolCh
20.02.2017 12:43Фреймы — заботливые обертки для моего кода, берущие на себя десятки рутинных задач, которые раньше у меня ходили из проекта в проект. С фреймом я занимаюсь решением бизнес-задач, а не роутингом, валидацией форс и объектов, работой с БД и прочим, что для решения бизнес-задач если не необходимо, то крайне желательно, но решением не является.
Falseclock
20.02.2017 12:58+2да никто не против фреймов… вопрос развития программиста от хеллоу ворлд, до написания своих фреймов. Зайдите на Тостер. Там сотни программистом спрашивают дурацкие вопрос, почему, например, постгрес не коннектит к базе на Node.js. Он не в курсе как вообще сделать отладку и найти проблему. Ни логи на сервере почитать, ни включить дебаг режим.
Tantacula
21.02.2017 08:28А вы когда новичком были, у вас не возникало вопросов, ответы на которые сейчас показались бы очевидными?
Fafhrd
21.02.2017 11:55+1У меня за 20 лет вопросы на «форумах» возникали раз 5. Но решение находил быстрее, чем там отвечали, и в итоге понимал, что смалодушничал и не хватило терпения в решении вопроса.
Сейчас же на некоторых ресурсах новые персонажи умудряются плодить темы по 5 раз за день, несмотря на фреймворки и их документацию ибо видео-уроков нет ^_^
evil_kabab
21.02.2017 23:13А я с детства никогда не просил о помощи. Попросил — расписался, что ты ребенок, а не мужик. Есть гугл и там есть все ответы. Только сегодня молодежь даже попытки не делает, сразу просят помощи, не гуглят
AFakeman
01.03.2017 00:34+1Ага, и на первой странице гугла нередко выпадают вопросы на SO, где как раз можно почитать полезный и развернутый ответ, который бы не был написан, если бы кто-то не «расписался в том, что он ребенок».
Fesor
21.02.2017 23:56+1Приведу интересное наблюдение, суть которого заключается в том что отладчики плохо влияют на код.
Когда мы пишем код и что-то работает не так, у нас есть два варианта:
- просмотреть код глазами и попытаться его выполнить в голове
- выполнить код, подключить дебаггер, расставить бряки, глянуть как меняется стэйт и что вообще происходит.
Второй подход машинальный, он зачастую не подразумевает глубокого анализа происходящего. Мы концентрируемся на одной строчке кода и состоянии в рантайме, не особо понимая как так вышло что оно такое как есть. Это не требует больших умственных усилий и устранив проблему мы просто идем дальше.
С другой стороны первый подход будет позволять разработчику думать над тем что он написал, а если так делать часто, то можно быстро приучить себя писать относительно читабельный код, проникнуться важностью изоляции состояния и минимизации сайд эффектов. Не говоря о том что мы будем вынуждены делать более качественную декомпозицию чтобы не сойти с ума.
То есть, с одной стороны дебагер штука полезная, и без нее никуда, с другой стороны в любой непонятной ситуации сразу ставить бряку приводит нас к менее читабельному/поддерживаемому коду.
Это же наблюдение можно спроецировать и на фокусировку внимания на фреймворках а не на принципах лежащих в их основе, и на то что сегодня разработчики чаще сразу лезут на тостеры вместо того чтобы попытаться разобраться в проблеме самостоятельно.
Delphinum
22.02.2017 00:23Это же наблюдение можно спроецировать и на любую современную IDE, если очень захотеть.
Fesor
23.02.2017 22:34Можно, и более того — так оно и есть. Есть даже шутка — автокомплит это замечательная вещь которая позволяет создавать вещи вроде
AbstractSomethingFactoryFactory. То есть возможность пользоваться оной плохо сказывается на необходимости думать над именованием и интерфейсами.
Но это не является причиной НЕ использовать IDE или автокомплит. Просто надо думать что делаешь.
codemax
23.02.2017 10:11Есть так называемые «костыль-ориентированные» программисты, которые, к примеру, при исправлении бага, долго думать не будут — найдут ближайшее место и исправят прямо там. Иногда, в простых случаях, им везет, но чаще это то, что называют костылём. И да, дебагер поможет им сделать это быстрее, затратив еще меньше мозговых ресурсов. Но вряд ли отсутствие отладчика завставит его задумываться над кодом вокруг.
С другой стороны — если программист ответственно подходит к вопросу, он даже при наличии отладчика будет думать о влиянии его изменений на код вокруг, на то, какие проблемы могут возникнуть в будущем при поддержке такого решения. Все эти вопросы остаются важными для него вне зависимости от того, есть дебагер или нет. Дебагер, опять же, используется как инструмент ускорения начальной локализации проблемы.
Случаев, когда при использовании дебагера один и тот же разработчик думает над последствиями своего решения меньше, а в ином случае — больше, я пока не встречал. Впрочем, это тоже только мои наблюдения :)
MikailBag
23.02.2017 21:55Как без дебаггера вы найдете ошибку в написании алгоритма?
Fesor
23.02.2017 22:32пару минут попытаться разобраться глазами, а потом запустить с дебагером. Мысль не в том что бы отказаться от дебагеров — это глупо. Мысль в том чтобы сначала думать а уже потом использовать стероиды.
Delphinum
20.02.2017 13:44решать задачи не прибегая к готовым решениям — другое
Вы не задумывались, что есть еще третий вариант: «знать кишки готовых решений» — ?Falseclock
20.02.2017 13:46а у вас не было такого, что до вас никто такое не реализовывал и готовых рабочих примеров нет?
Delphinum
20.02.2017 13:49+2Это совсем другое. Народ пишет о применение фреймворков для решения давно решенных другими программистами задач. Лично я предпочитаю отходить от фреймворков в пользу пакетов.
oxidmod
20.02.2017 13:57ну, как говрят в мире ПХП, композер — лучший фреймворк. Можно и так, если вы достаточно четко представляете то, что нужно сделать. Но на этапе «давайте запилим прототип побыстрей» фреймворк это весьма неплохой каркас (сборка проверенных временем пакетов и необходимый бойлерплейт для их совместной работы)
varanio
20.02.2017 13:59Фреймворк особенно полезен для работы в команде. Например, проект на Yii, наняли новичка, который умеет Yii — и он всё знает, где модели, где контроллеры, как работать с базой и т.д.
Delphinum
20.02.2017 13:59+1У нас уже давно есть несколько скелетонов на все случаи жизни, в том числе для «давайте запилим прототип побыстрей».
composer create-project github.com/tiny-skeleton /var/www/prototype
и дизайнеры/верстальщики уже накидывают скелет для демонстрации клиенту.
evil_kabab
21.02.2017 23:05Немного некорректный пример. Фреймворки для PHP написаны на PHP. Высокоуровневые языки написаны по большей части на низкоуровневых.
Я в 88 году столкнулся с бк 0010, производительности на бейсике не хватало, ну так я быстро изучил ее ассемблер. На редкость простой и понятный…lair
21.02.2017 23:12Немного некорректный пример. Фреймворки для PHP написаны на PHP. Высокоуровневые языки написаны по большей части на низкоуровневых.
И что? Почему фреймворки сводят на нет всю суть программирования, а высокоуровневые языки — нет?
evil_kabab
21.02.2017 23:20+1Примерно так. Высокоуровневые языки избавляют нас от необходимости писать на асм. Симфони и Ларавел вас от PHP не избавят.
Я помню ужасный MFC и win32api и книжку Петзольда. Не хочу спорить, но предпочитаю без фреймворков работать.VolCh
21.02.2017 23:24+1Высокоуровневые языки избавляют нас от необходимости прямой манипуляции низкоуровневыми абстракциями типа адресов и ячеек памяти, фреймворки избавляют нас от необходимости манипулировать высокоуровневыми абстракциями типа текстов HTTP или SQL запросов, сводя их к абстракциями ещё более высокого уровня.
Rastishka
20.02.2017 13:16+1Статья:
«Hello, (real) world!» на php в 2017 году
Раздел:JavaScript и его многочисленные друзья
varanio
20.02.2017 13:22Вы верно ухватили суть статьи. Именно в этом и состоит смысл. Что голый php без всего — это конь в вакууме.
Rastishka
20.02.2017 14:30+1Нет, если бы статья называлась «SPA «Hello, (real) world!» в 2017 году» или «Web «Hello, (real) world!» в 2017 году»
вопросов бы не было.
А так получается в проекте нужны JS бандлеры, JS транспилеры и JS линтеры, а плохой при этом PHP.
krocos
20.02.2017 13:31+1А еще в 2017 docker есть…
mgremlin
20.02.2017 17:33+1Докер бы сильно упростил деплой, что плохо коррелирует с основной идеей статьи 8-)
batyrmastyr
20.02.2017 23:06Но ведь можно сделать свой образ (точнее четыре + docker-compose) в котором скомпилируем всё из исходников. Можно даже собственное ядро линукса собрать для полного счастья.
mgremlin
20.02.2017 23:25Лично для меня докер — это упрощение, хоть как его собирай.
Вот что с ним будет на боевом сервере — это уже большой вопрос 8-)
но поднять новый для себя сервис сначала на локальной дев-машине, а потом на серваке с докером значительно проще. Даже если до того много лет пользовался bare server — к хорошему быстро привыкаешь. Если бы докер сделал легкий доступ из контейнера к локалхосту — уверен, многие бы пользовались.
Докерный сетап в проде лично я вынужден был разобрать из-за ряда неразрешимых проблем. Но часть контейнеров оставил бы с удовольствием 8-) тот же сфинкс — задолбался его настраивать на железе. А в контейнере он заводился в 5 сек…Fesor
20.02.2017 23:28Если бы докер сделал легкий доступ из контейнера к локалхосту
А зачем и чем он сложен? Если надо по быстрому например поднять базу данных на локалхосте (например тесты погонять)
docker run --rm -d -p 5432:5432 --name tests-db postgres
И вуаля. У нас поднята база на локалхосте.
psql -h localhost -u postgre
Другого вида доступов и не нужно особо. В этом же смысл изоляции.
VolCh
21.02.2017 07:37Обычному разработчику изоляция как таковая от докера не нужна, а вот доступы нужны.
mgremlin
21.02.2017 10:00+2смысл в наоборот: чтобы процесс, запущенный в докере, имел доступ наружу. например, ваш постгре поднят на железе, и был доступен внутри стороннего контейнера. Приведен пример — сфинкс, при условии, что его «базовая база» не стартует другим контейнером в compose, а выше, на localhost.
Смысла в изоляции нет вообще никакого, тем более, что она в достаточной степени мнимая. А вот повторяемость, возможность легко сохранить конфиг, легко воспроизвести деплой, сбросить на вендора конфигурацию для «быстро попробовать» — это вот очень ценно.
полетит — можно нанять админа и настроить уже все по-человечески. А вот корячиться самому…
еще пример: хотите вы попробовать какой-нибудь модуль nginx. image_filter, например. В родном докерном образе он включен по дефолту и запускается это все с полтычка. А поставить в систему, на localhost? В новой бунте, например, старая версия, где ничего не работает. Хочешь поменять на самую новую версию — начинаются пляски с бубном, в лоб не ставится. Все можно сделать, конечно, но если с каждой софтиной плясать — охренеешь. А если еще твой хлеб не в этом… То ли дело докер: 10 строк в compose, чистая система, 5 минут работы — все шикарно! На первый взгляд.
Но, повторюсь, все бонусы докера рушатся его безобразной работой с сетью и накоплением ошибок в проде. Там без высококвалифицированного админа его использовать невозможно (/мне не удалось 8-). А вот для разработки — сказочно.
BoneFletcher
20.02.2017 13:41+1Для контроллеров отдающих json рекомендую использовать аннотацию ToJsonResponse:
/** * @Route("/greetings/{id}") * @ToJsonResponse() */ public function greetings($id) { $greeting = $this->getDoctrine()->getRepository("AppBundle:Greeting")->find($id); return ['greeting' => $greeting->getGreeting()]; }
Отличие в том, что в случае ошибки вернется корректный json, а не html-код:
STATUS 500 Internal server error
{ message : 'Exception message' }faost
20.02.2017 14:18Лучше сразу использовать http://symfony.com/doc/current/bundles/FOSRestBundle/index.html
velafrys
20.02.2017 14:03+2В статье вижу один сарказм, при этом годный и злободневный.
Но по комментариям вижу обратное.ellrion
20.02.2017 14:38+1Мы видимо с вами разные статьи прочли. Автор неоднозначно говорит, что данные инструменты не только имеют место быть, но и в связи с требованиями рынка (и возможно моде) должны быть знакомы и применяться разработчиками.
velafrys
20.02.2017 14:42Выглядит все так, будто использовать нужно только те инструменты, что указал автор.
AlexLeonov
20.02.2017 14:06Дочитал до
Php-программист в 2017 году не может обойтись без js и верстки
понял, что статья — полная чушь.
Спасибо, что поставили эту фразу пораньше в тексте, сэкономили мое время.varanio
20.02.2017 14:11+1Не за что.
Только вы откройте, пожалуйста, hh и посмотрите. Не менее 3 вакансий из 4 требуют знание js или указывают, что это «будет плюсом».wladyspb
20.02.2017 18:59Не имею ничего против знания js, css, html — в работе нужно понимать, как работают граничащие технологии. Однако на вакансии «требуется PHP программист для работы с вёрсткой, дизайном, базой данных и сервером» — советую бежать как от огня.
AlexLeonov
21.02.2017 16:06Для меня сочетание в резюме «PHP+HTML+JS+CSS» это скорее минус, показывающий, что человек сам не знает, чего хочет в профессии.
И да, на PHP я пишу 13 лет. И все эти годы прекрасно обходился без JS и вёрстки. Что я делаю не так?VolCh
21.02.2017 16:11+1Почти 20 лет пишу на PHP и редко когда было что JS и вёрстка меня вообще не касалась. Даже когда в команде есть отдельные фронтендеры, то "почему-то" меня ставят лидом команды и я принимаю их задачи.
varanio
21.02.2017 16:33+2> это скорее минус
Почему минус? Это реалии рынка, что js надо знать, отсюда и резюме со знанием js. Всё логично.
> И да, на PHP я пишу 13 лет. И все эти годы прекрасно обходился без JS и вёрстки. Что я делаю не так?
Вы не подходите под большинство вакансий, куда могли бы попасть с вашим опытом php. Кроме того, это довольно странно, на мой взгляд, не интересоваться смежными областями. Хирург узко специализирован, но он должен уметь проводить реанимацию, например.AlexLeonov
22.02.2017 14:14+1Почему «не интересоваться смежными областями»? Я интересуюсь.
Например интересуюсь, как написать на PHP многопоточный неблокирующий код, как собрать ZTE под RHEL, интересуюсь вопросом, как на один инстанс postgres класть 10 000 insert-ов в секунду, не положив этот инстанс, интересуюсь, как автоматизировать деплой php-приложения на несколько десятков тестовых стендов и запустить (опять же в несколько потоков) толстую пачку тестов…
Это не смежные области?
Ну неинтересен мне JS и фронт, не люблю я их — что же делать-то?Fesor
23.02.2017 01:59+1Это не смежные области?
нет, это все бэкэнд и чуть-чуть ops. Очень тесно переплетенные темы.
Ну неинтересен мне JS и фронт, не люблю я их — что же делать-то?
Не могу сказать что фронтэнд это интересно. В подавляющем большинстве случаев это просто верстка и компоновка элементов UI. Да, случается когда надо нетривиальную логику на клиент тянуть но на сервере этого добра больше обычно (покрайнемере сейчас).
С другой стороны как по мне любой уважающий себя бэкэндер должен хорошо представлять как пользуются бэкэндом клиенты и взглянуть на свои проблемы с этой стороны. К примеру… пишем мы микросервисы, пафосные такие, тыкаем в людей пальцами если у них хотя бы два микросервиса шарят между собой одну базу данных или имеют огрехи в изоляции… и при этом всем этим раем бэкэндщика пользуется монолитное мобильное приложение… которому еще и по 10 запросов надо сделать что бы данные из всех микросервисов достать… грустно наверное...
garex
20.02.2017 14:07-1Anton Merge branch 'master' of github.com:anton-okolelov/helloworldphp
Далее не читал, но осуждаю.
Вот более правильные версии хеловорлда ))
https://github.com/DQNEO/php-HelloWorldEnterpriseEdition
https://gist.github.com/lolzballs/2152bc0f31ee0286b722
ju5tify
20.02.2017 14:26-2composer create-project symfony/framework-standard-edition
А так все хорошо начиналось
Сажаскрылvaranio
20.02.2017 14:30Вам не нравится composer, symfony или standard-edition? :)
ju5tify
21.02.2017 15:02Ну конечно же, Symfony.
Зазывать в увлекательный мир PHP c помощью Symfony — это как привезти иностранца в Москву и начать экскурсию с Бутово. Или начать знакомство с США с Детройта вместо Манхэттэна.
Что ждет новичка, который решит встретить новый день с Symfony?
Его ждут аннотации (нативная конструкция в PHP, как всем известно). Его ждут бездонные контейнеры, тормзная Доктрина, мерзкий YAML, сопли из сервисов, которые инжектируются в другие сервисы третьми сервисами. Его ждут еще более тормозные бандлы от Knp, FriendsOfSymfony и прохих мастеров своего дела.
И самое главное — его ждет наглухо упоротое комьюнити из хомячков Фабьена, каждый из которых точно знает Как? Надо? Делать? согласно святым скрижалям Великого Мастера.
Его ждет боль. Его ждет агония.varanio
21.02.2017 15:20+1Ну не знаю. Мне нравится Symfony. Он лучший по расширяемости, по SOLID и т.д. Очень часто можно компоненты из Symfony встретить в самых разных пакетах composer. На них даже другие фреймворки целиком построены. Потому что он абсолютно гибкий. И правильно написан по всем канонам ООП.
ju5tify
22.02.2017 17:44-1по всем канонам
Речь идет о слепленной из говна и палок поддержке несуществующих в PHP аннотаций?
Или о маниакальном фетише DI, благодаря которому чужой код превращается в нечитаемое месиво настолько, что приходится обвешиваться анализаторами XML и YAML барахла в многочисленных васяно-бандлах.
Ах да, у церкви св. Фабьена же свои каноны.VolCh
22.02.2017 18:39Речь идет о слепленной из говна и палок поддержке несуществующих в PHP аннотаций?
Ваше дело использовать их или нет. У нас частичный запрет — нельзя использовать в модели, можно в контроллерах и сервисах приложения.
Или о маниакальном фетише DI, благодаря которому чужой код превращается в нечитаемое месиво настолько, что приходится обвешиваться анализаторами XML и YAML барахла в многочисленных васяно-бандлах.
Ваше дело ставить васяно-бандлы или нет.
maxzuber
20.02.2017 14:33+1При наличии composer, поставьте fxp/composer-asset-plugin, чтобы исключить ось nodejs — npm — bower.
xaja
20.02.2017 14:41+2Starting a basic website in 2014:
1. Install Node
2. Install Bower
3. Pick CSS framework
4. Pick responsive approach
…
47. Write some HTML
— I Am Devloper (@iamdevloper) October 2, 2014
Mithgol
20.02.2017 14:50+1Если Node.js и npm установлены, то тогда PHP вообще не очень нужен, ведь можно поверх ставить web-сервер (например, Express.js) и шаблонизатор (например, Handlebars.js) и далее на них сайт подымать. (Я пишу это отчасти иронически — но не более, чем наполовину.)
Delphinum
20.02.2017 14:54+1Боюсь спросить, что вы предложите узнав, что в качестве ОСи сервера будет выбрана одна из BSD?
batyrmastyr
20.02.2017 23:13>brew info node.js
node: stable 7.5.0 (bottled), HEAD
Platform built on V8 to build network applications
Возможно я вас не так понял, но проблемы не вижу.Delphinum
20.02.2017 23:20Вы меня не так поняли. То был сарказм. Если коротко, то:
Если Node.js и npm установлены, то тогда PHP вообще не очень нужен
Можно передернуть как:
Если под сервер используется BSD, то тогда PHP вообще не очень нужен, лучше использовать TreeFrog Framework
spaceinvaider
20.02.2017 15:30+1аналогичный «Hello word» в java мире, Enterprise Edition
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
наверное автор хтел создать нечно подобное для php стекаDelphinum
20.02.2017 15:33Для php стека нечто подобное уже давно создано, автор лишь хотел показать это.
pvasili
20.02.2017 17:30Вместо того, чтобы вынести мусор автор переклеил обои, сменил мебели, переехал в другую страну (со сменой документа) и потом заказал через интернет клининговой компании вынести мусор в квартире на другом континенте. А мог бы просто вынести пакет :)
roboter
20.02.2017 17:34-1Интересно в каком году в PHP view будет лежать в одной папке с controller.
разделение по фитчам а не типам файлов.Delphinum
20.02.2017 18:17Бывает, что на первом этапе (подготовка прототипа для заказчика) проект выглядит так:
backend/ config/ vendor/ templates/
Фронтендщики побыстрому накидывают шаблоны, а уже после одобрения клиентом в проект вкручиваются контроллеры, мидлевары, модель и прочее.
Бывает даже так, что после демонстрации прототипа заказчику ТЗ меняется настолько, что от контроллеров вообще отказываются.
VolCh
20.02.2017 18:18Как хотите так и складываете. Не нравится стандартное размещение файлов в Symfony — переопределяется лёгким движением руки.
kalsarikannito
20.02.2017 20:42Зачем на это тратить время ?
TonyLorencio
20.02.2017 22:25Если вы пишете вручную "echo 'hello, world'", то обрекаете проект на говнокод на веки вечные (кто потом этот велосипед за вас переписывать будет?).
ZoomLS
21.02.2017 03:35В итоге, получилось столько js, что спрашивается, а зачем тут нужен php?
Можно на самой node.js быстренько накатать простой сервер для «hello word» или сделать «npm install express», и создать всё ещё быстрее. Без шуток.
Gosha_say
21.02.2017 07:05Ну вообще писать hello world на PHP не выгодно ввиду отношения ресурсоёмкости к его полезности, так что на PHP — hello word лучше не писать вообще
lexofein
21.02.2017 09:29Каждый раз когда вижу такие посты, вспоминаю историю про кучу проектов, которые клепали как умели, вместо того чтобы пытаться изучить все и вся. Один из самых ярких примеров дота. Была статья на хабре, в которой речь зашла о том что первая дота была примером лютейшего говнокода и ее очень критиковали разработчики вк3 карт за это. Где теперь разработчики со своим идеально вылизанным кодом, а где теперь дота говорить надеюсь не нужно.
Delphinum
21.02.2017 12:36Первые версии доты клепались на Warcraft'овском конструкторе карт, а если вы не знаете, то в этом конструкторе используется «программирование мышкой». В итоге конструктор компилирует ветвление if/else примерно так:
function if_foo takes string returns boolean проверка endfunction function then_foo takes function returns nothing тогда endfunction function else_foo takes function returns nothing иначе endfunction
Говорить о говнокоде тут нельзя, ибо говняется код уже самим конструктором. Более того, мапермейкеры никогда не писали качественный код по многим причинам, в том числе потому, что в этом просто нет никакой необходимости.
Когда Dota начала набирать обороты, за ее код взялись другие программисты, именно для вылизывания кода, ибо без того, игра лагала до невозможности (поинтересуйтесь историей создания карты).
Вывод: это одна из модель разработки, требующая минимальных усилий на первом этапе для создания рабочего прототипа, но приводящая в результате к необходимости практически полного переписывания прототипа до уровня рабочего проекта.
Enapiuz
21.02.2017 10:14+1То есть вы берете симфони (далеко не самый простой и дружелюбный фреймворк), в довесок к нему берете реакт (тоже не самый очевидный и дружелюбный фреймворк), обмазываетесь тайпскриптом, делаете на этом всем hello world и удивляетесь, что у вас куча оверхеда?
Конечно, если вам нужно что-то маленькое, то можно либо взять маленький фреймворк, либо быстро состряпать из готовых компонентов свой, взять тот же fastroute и вот приложенька с API готова.
А если приложение ваше будет большим, то и симфони не будет таким монстром на его фоне, а скорее всего упростит жизнь.
Тут как всегда просится уже набившая оскомину фраза "для каждой задачи свой инструмент".VolCh
21.02.2017 10:44Причём для реакта берётся далеко не самая стандартная обвязка, да и для симфони многое пишется руками из того, что автоматизировано либо в symfony, либо в bin/console, а про create-react-app не слышали.
А на самом деле при должном опыте подобный (не такой же) скелет разворачивается за полчаса максимум.
varanio
21.02.2017 11:14Отвечу сразу обоим )
Видимо мне надо было назвать статью как-то по-другому. Типа «заготовка для SPA c php». Но теперь уж поздно.
> То есть вы берете симфони (далеко не самый простой и дружелюбный фреймворк)
Что там недружелюбного, в симфони-то? С ним как раз всё норм, и времени не заняло совсем. С конфигами к webpack было в 100 раз больше проблем.
> в довесок к нему берете реакт (тоже не самый очевидный и дружелюбный фреймворк)
Насколько я вижу, сейчас есть два топовых направления: React+что-то или Angular. Ну, я выбрал React+redux
>обмазываетесь тайпскриптом
Вот тут вы не правы на 100500%. Typescript в мире javascript — это как бриллиант в куче г. Строгая типизация, interface и т.д. Особенно для реакта помогает. Когда задаешь interface для props, то тебе IDE не дает ошибиться
при использовании этого react-компонента. Без интерфейсов вообще сложно строить ООП.
При этом никакого особого оверхеда по сути нет, так как все равно обмазываться webpack-ом приходится и его конфигами.
>Причём для реакта берётся далеко не самая стандартная обвязка
Обвязка — это redux, вы имеете в виду? Тут да, возможно надо было бы что-то попроще взять. Без чистых функций и т.д. Но redux интересен лично мне, кроме того, я знаю пару крупных контор, котрые его используют в продакшене и радуются. Поэтому решил взять его.
> да и для симфони многое пишется руками из того, что автоматизировано
Создание сущности по таблице? Ну да, но там сущность на несколько строк, разницы особо нет
> про create-react-app не слышали.
не слышал, посмотрюVolCh
21.02.2017 12:19+1Вот тут вы не правы на 100500%. Typescript в мире javascript — это как бриллиант в куче г. Строгая типизация, interface и т.д. Особенно для реакта помогает. Когда задаешь interface для props, то тебе IDE не дает ошибиться
при использовании этого react-компонента. Без интерфейсов вообще сложно строить ООП.
При этом никакого особого оверхеда по сути нет, так как все равно обмазываться webpack-ом приходится и его конфигами.Вы описываете плюсы статической типизации, но для JS она не ограничивается Typescript, притом что Typescript требует именно полноценного компилятора, а другие типа Flow требуют, максимум, простого плагина к babel, а то и просто типі в комментариях указіваются.
Обвязка — это redux, вы имеете в виду? Тут да, возможно надо было бы что-то попроще взять. Без чистых функций и т.д. Но redux интересен лично мне, кроме того, я знаю пару крупных контор, котрые его используют в продакшене и радуются. Поэтому решил взять его.
Не только, но и его тоже. Но поскольку мы говорим прежде всего о пхп-разработчике, то редакс для него библиотека с соверешнно чуждой парадигмой. Хранить стейт в умных компонентах или использовать ООП-"сторы" типа MobX куда ближе к PHP и Symfony.
Создание сущности по таблице? Ну да, но там сущность на несколько строк, разницы особо нет
Создание таблицы по сущности
не слышал, посмотрю
обязательно посмотрите
vintage
26.02.2017 22:41Typescript требует именно полноценного компилятора, а другие типа Flow требуют, максимум, простого плагина к babel
Вы так говорите будто полноценное хуже неполноценного.
Fesor
26.02.2017 23:09Вы так говорите будто полноценное хуже неполноценного.
вы извращаете слова, никто не говорил про "неполноценные" компиляторы.
В целом если вы завязали проект на TypeScript вы от него никуда не денетесь. Это своего рода вендор-лок, пусть я и не думаю что это очень плохо в данном случае. С Flow все намного более демократично.
vintage
27.02.2017 11:11C Flow всё демократично только если прятать типы в комментариях. Но раз мы говорим про "плагин к babel", то это явно не тот случай.
VolCh
27.02.2017 07:10+1С точки зрения управления проектом, компилятор — новый тип сущности, вводимый в процесс сборки, а плагин к бабел — ещё один экземпляр существующего типа. И вообще можно обойтись без него, описывая типы в комментариях на манер jsdoc
vintage
27.02.2017 11:12-1Сам babel — лишняя сущность при использовании ts.
jsdoc крайне скупо описывает семантику и её крайне плохо понимают ide.
VolCh
27.02.2017 11:56Почему лишняя? Тайпскрипт умеет импортировать в Джс например цсс-файлы? тайскрипт умеет компилировать в ES5+/ES2015-, то есть для браузеров, которые, скажем, 80% фич ES2015 умеют, а 20 нет? Когда в последний раз крутил, то выбор таргетов был строго ограничен и пришлось выбрать ES2015 и оставшиеся 20% компилить бабелем. Альтернатива — таргет ES5 совсем не радовала.
Я про флоу типы в комментариях, а не в коде на манер тс.
vintage
27.02.2017 12:01-1Тайпскрипт умеет импортировать в Джс например цсс-файлы?
И зачем заниматься такими извращениями?
тайскрипт умеет компилировать в ES5+/ES2015-, то есть для браузеров, которые, скажем, 80% фич ES2015 умеют, а 20 нет?
Конечно. Если вы про генераторы, то нет, такой говнокод он не генерирует.
VolCh
27.02.2017 12:07Про модульность не слышали? Про изоляцию CSS компонента от окружения?
Specify ECMAScript target version: "ES3" (default), "ES5", "ES6"/"ES2015", "ES2016", "ES2017" or "ESNext".
Переходных вариантов нет, ориентирован на стандарты, а не реальную жизнь. Или отсекай больше пользователей, чем рассчитывал, или грузи большинству кучу ненужного ему кода.
vintage
27.02.2017 12:33Про модульность не слышали? Про изоляцию CSS компонента от окружения?
Для этого не нужно вкомпиливать стили в скрипты. Впрочем, я сторонник более наглядного БЭМ. Фанатичная изоляция особой пользы не приносит.
Или отсекай больше пользователей, чем рассчитывал, или грузи большинству кучу ненужного ему кода.
Или не используй модные фичи сомнительной ценности.
VolCh
27.02.2017 13:09Не нужно, но это удобно. Сразу видно какие стили применяются к компоненту, а сами файлы стилей не загромождаются бесконечными конструкциями во избежание конфликтов.
"модные фичи сомнительной ценности" как-то слабо применимо к фичам, включенным в стандарт языка и уже поддерживаемым последними стабильными версиями сколь-нибудь популярных браузеров. Просто не все обновляются.
vintage
27.02.2017 13:14Не нужно, но это удобно
Совершенно не удобно. Сорсмапы — штуки до сих пор не надёжные. А для уникальности генерируются имена с хешами. БЭМ же нужен не только для решения конфликтов, но и для понимания что к чему относится.
"модные фичи сомнительной ценности" как-то слабо применимо к фичам, включенным в стандарт языка
То, что они включены в стандарт языка — лишь дань моде. Префиксы в css, Object.observe, application cache — тоже были стандартами и где они теперь?
vladalivan
21.02.2017 11:04Помню, в далеком 2002 году я начал изучать PHP с фреймворка Smarty, и долго делал все через задницу, пока не понял, что чистый PHP как фрейворк гораздо лучше чем Smarty.
Source
21.02.2017 11:49+1iirc, Smarty — это шаблонизатор, а не фреймворк.
vladalivan
21.02.2017 11:55Ну, да, сорри. Я к тому, что не всегда нужно стрелять из пушки по воробьям.
dimaborisovsky
21.02.2017 11:16А флуда то за сутки накопилось не мало. Значит статья людям действительно понравилась!
Mexis
21.02.2017 11:38Люблю такие статьи. Как раз такие статьи напоминают мне, что пора браться за ум и научиться использовать фрейворки. Я фронтендист, но частенько «хардкодю».
Спасибо!
CodeDriller
21.02.2017 12:39+1Стрелять из пушки по воробьям так же глупо, как изобретать велосипед заново. (с)
Я хочу сказать, что сначала ставится и анализируется задача, а только потом под эту задачу выбираются наиболее подходящие для нее инструменты. Это важнейший инженерный принцип! А у Вас так получается, что Вы сначала подобрали себе набор наиболее модных и навороченных инструментов, а потом спрашиваете, что будем с этим делать. Хорошие системы не делаются таким образом.
maxnemo
21.02.2017 13:22Если вы пишете вручную «echo 'hello, world'», то обрекаете проект на говнокод на веки вечные (кто потом этот велосипед за вас переписывать будет?).
Столько заморочек, чтобы написать пару слов hello world…
dreamworker
21.02.2017 13:35+2Вся эта статья характеризуется одним предложением: «синдром преждевременной оптимизации»
OlegZorin
21.02.2017 14:23+2Фремворки, абстракции, паттерны это все хорошо и это все правильно — надо знать и уметь применять.
Но разница между знать и уметь применять — огромна. Для решения конкретной задачи надо использовать подходящие для этого инструменты (чужие или свои — не суть).
Если задача стоит только написать HW, то я сделаю наитивно echo 'HW';. На кой сюда совать ООП, MVC и еще кучу всякой-всячины? В частности, зачем тут БД и симфони (да и вообще любой другой фрейиворк)?
Я конечно понимаю, что болт забитый молотком держится лучше чем гвоздь завернутый гаечным ключом…
Мое личное мнение — код должен быть максимально простом, но при этом он должен удовлетворять требованиям системы в целом. Тогда этот код проще сопровождать и сложнее сломать.
Другое дело, если бы вы написали, что у меня вот такая-то система, заложены такие-то требования к фронту и беку, и надо сделать то-то. Возможно, тогда ваш код имел бы место быть.
С автором соглашусь в одном — нужно владеть как можно большим числом инструментов. Но также надо уметь правильно ими пользоваться.MikailBag
21.02.2017 19:56+2Тут не нужен даже php)
echo "Hello, World!" > /web/server/static/path/index.html
И все)
OlegZorin
22.02.2017 06:49Вообще да, соглашусь.
Однако, статья называется «Hello (real) world» на php. Значит у нас возникает первое ограничение системы — язык php. ))
А вообще, я бы считал эту статью неким «пятничным стебом» и пародией на статью про JS и JS-сообщество (https://habrahabr.ru/post/312022/).MikailBag
22.02.2017 21:34Причем настолько же безосновательным стебом.
Любой живой язык постепенно обрастает кучей библиотек и фреймворков.
На плюсах тоже хелловорд с ассемблерными вставками написать можно)
RidRock
21.02.2017 14:24+2Предположим, автор захотел написать Hello world! на листке бумаги.
1. Описываем долгий процесс получения бумаги (опилки-целлюлоза во все поля).
2. Описываем долгий процесс создания авторучки (упуская при этом возможность использования гусиного пера).
3, Описываем долгий процесс получения чернил (сок ягод?).
4. Описываем долгий процесс изучения и написания буковок.
5. PROFIT!
Зы: Без обид)
14types
21.02.2017 16:55+2Преподаватель по ООП говорил: делайте то, что просят, ни больше ни меньше.
Для вывода «Hello,world!» даже HTML разметки не надо.
ld100
21.02.2017 17:43+1Думаю, критики в комментариях было бы гораздо меньше, если бы в примере был не hello world, а что-то чуточку более приближенное к реальности, вроде «блога за 15 минут».
Fesor
21.02.2017 17:54«блога за 15 минут».
- идем на medium.com
- регаем аккаунт.
Ну или для изысканных
- Идем на github pages
- делаем дела.
ideological
21.02.2017 22:36Всё очень просто.
Если это веб-студия и они пишут 100500 сайтов — то им очень нужен php фреймворк. Жизненно необходим.
Потому что они с ума сойдут разбираться в костылях разных. Нанимаешь чуваков знающих выбранный фреймворк и вот куча визиток и интернет-магазинов.
Если же приходится писать сервис или нестандартный проект какой, то с фреймворком просто будет тесно и он там нафиг не нужен.VolCh
21.02.2017 22:49Да ладно? Для визиток и интернет-магазинов как раз фреймворк не нужен, нужна CMS, а то и вообще генератор статики.
А вот для сервисов и нестандартных проектов фреймворки очень помогают работать именно над нестандартной частью, не тратя время на всякие роутинги и маппинги базы данных (из поста именно они использованы).
Fesor
21.02.2017 22:58+1Если же приходится писать сервис или нестандартный проект какой
то сразу находится миллион стандартных задач:
- логи
- кеширование
- надо как-то с базой работать, нужны либки под тот подход который мы хотим юзать
- надо как-то с http работать
- надо как-то очереди делать
- надо как-то управлять зависимостями
- Аутентификация, авторизация
- надо как-то с <впишите-модную-технологию> работать...
Ну то есть вся инфраструктура проекта. Можно брать full-stack фреймворки или микрофреймворки и дополнять компонентами по вкусу… Порой приходится дописывать что-то свое когда "жмет". Бизнес логика же обычно не должна зависеть от подобных вещей. Кучи принципов и правил не просто так понапридумывали.
vtvz_ru
22.02.2017 00:04+1Несмотря на то, что это не «Hello, World на PHP», но вполне реалистично описывает современную ситуацию. Помню времена, когда был только jQuery и голый CSS… Сейчас порог вхождения для всего web стека намного выше, чем раньше. Хотя создание сложных вещей стало намного проще, но разобраться во всем этом разнообразии разобраться не могу до сих пор
Rathil
23.02.2017 02:56Ну не скажите. Мы сейчас пилим достаточно большой продукт, а точнее переписываем его, сейчас около 1М строк. Переписываем на микросервисы и не используем особо фреймворк. Было решено взять фалкон, но только для малого числа функционала (DI, валидаторы). Так что пишут сейчас без фреймворков. Пишут.
Fesor
23.02.2017 03:21Было решено взять фалкон
Так что пишут сейчас без фреймворков.Простите, но я вижу тут несоответствие. То что у вас выходит некий микрофреймворк — это не значит что его нет. Более того, вы на основе готовых компонентов выстроили свой фреймворк. Вот и все. Ну то есть все как у всех. Просто у вас более узкоспециализированный и вы знаете что делаете.
Rathil
23.02.2017 12:58Ну как Вам ответить, все зависит от того, что Вы подразумеваете под понятием «использовать фреймворк». Если бы мы взяли просто готовую либу, не из фреймворка и использовали ее, Вы бы все равно сказали, что мы используем стороннюю готовую либу, а это почти тоже самое! Просто нам подошёл именно тот интерфейс и тот функционал, вот мы и взяли фалкон и используем его как либу, а не фреймворк. Полностью заврапили те части, что мы используем, своими интерефейсами и полетели…
Skit25
23.02.2017 03:24+1Про postgresql, ваши слова бы да хостерам в уши. Если бы хостеры поставили постгрес, на ряду с мускулем, было бы супер! А так — мускуль. Хотя на локалке, чтобы не отставать использую постгрес, благо фреймворк в 21 веке позволяет менять драйвер, одним словом в конфиге.
aureliano_b
23.02.2017 12:16+1Читал статью с полной уверенностью, что это все саркастический стёб. Собирался было уже написать восторженный комментарий и отдельную статью в продолжение, но не тут-то было. Выглядит так, что автор действительно это все взаправду и на полном серьезе пишет.
Трудно представить, какая помойка в голове у людей, истово верящих во все эти модные словечки. Если вы действительно настолько индокринированы и реально подходите к проектированию и работе так, как описано в статье, мой вам совет: оставьте это ремесло, программирование не для вас.Попробуйте себя лучше на поприще большого современного искусства, акционизма какого-нибудь или популярной философии. Там нужно уметь писать длинные запутанные бессодержательные тексты и максимально избегать простых и понятных формулировок.
Сильно абстрагированные фреймворки вопреки бытующему в среде «корпоративных менеджеров» мнению, не упрощают, а напротив — радикально усложняют разработку и поддержку (см статью, собственно). Это новая религия (слаба роботам, не особо популярная в среде профессиональных разработчиков, как это может показаться после чтения Хабры) возникла из иллюзорных желаний непременной монетизации любого созданного за 15 минут кода, с легкой руки Google и иже.
Популярная нынче бизнес-модель хипстер-стартаперов: берем опенсорс-библиотеки, заворачиваем это все в наши классы и методы, называем это NewBuzzword framework, придумываем этому применение, которое конструирует «уникальное предложение», делаем набор примеров в рамках концепции «уникального предложения» и пишем документацию. Все это выкладываем в свободный доступ и потом везде пишем длинные статьи сдобренные красивой инфографикой в духе «теперь вы можете за 1 минуту написать то, на что другие тратили годы» в журналах для молодняка, а в других журналах (для бизнесменов): «реальная оптимизация бизнес-процессов с новым фреймворком NewBuzzword».
Это настолько хорошо работает, что миллионы неофитов по всему миру с легкостью индокринируются в эти новые секты. Результатом этого воистину религиозного поклонения является миллионы денег налогоплательщиков выбрашенных на ветер и километры говно-кода который никто никогда не сможет поддерживать без необходимости переписывать все заново с нуля каждый раз, когда система в какой-то своей части устаревает или требует расширения спектра применения.
Тем же, кто действительно любит писать код и стремится постичь «Дао» этого ремесла могу посоветовать фундаментальную монографию Дональда Кнута фывфывфыThe Art of Computer Programming.
И да, (не читайте советских газет), не тратьте время на изучение модных фреймверков. Изучайте архитектуру! И избегайте чрезмерных абстракций, они усложняют систему и уводят от понимания сути.varanio
23.02.2017 12:34+2Вы когда-нибудь вообще работали в команде?
Вы когда-нибудь делали SPA-приложение без фреймворка?
Как php, так и js-код без фреймворка в большой команде имеет тенденцию к нарастанию запутанности. Я это видел много раз. И вот именно это говнищще приходится потом переделывать с нуля. В отдельных случаях, при наличии сильного техлида, образовывается некоторая поддерживаемая структура, но это по сути фреймворк! Только велосипедный!!! Но это редкость, обычно всё скатывается в говнокод.
И наоборот: я много раз наблюдал, как человек впервые видел проект например на Yii и сразу начинал писать код, потому что знал Yii.
Например, React, конечно, модное слово, и хайп дурацкий вокруг него, но он не просто так придуман. Если вы потрудитесь изучить его, то вы поймете, для чего он нужен. Я попробовал и оценил преимущества. Вы не пробовали и предлагаете непонятно что в замен.
И отдельным пунктом совершенно непонятно как Кнут со своими сортировками и деревьями и т.д. может помочь с проектированием поддерживаемого приложения в команде.
VolCh
23.02.2017 13:50+1Если вы действительно настолько индокринированы и реально подходите к проектированию и работе так, как описано в статье, мой вам совет: оставьте это ремесло, программирование не для вас.
Процентов 80 новых проектов я начинаю с подобных шагов: поднять базу постгрес, развернуть симфони с доктриной для бэка и вебпак с реактом для фронта. Полчаса максимум. И начинаю проектировать и программировать бизнес-логику и интерфейсы, не отвлекаясь на алгоритмы Кнута для валидации формочек, роутинга и маппинга объектной модели на базу данных.
gerashenko
23.02.2017 18:17+1Статья отражает и мое впечатление об изменениях в сфере веб-разработки за последние 10 лет. Вряд ли описанные шаги являются пособием для новичков, но они хорошо показывают то, как изменились требования к соискателям. Времена, когда знания PHP было достаточно, ушли. Для развертывания приложений сейчас требуется выполнить столько всевозможных настроек и установок, что начинаешь ощущать себя админом, возможно, Docker и решает частично этот вопрос, но он же порождает новые конфиги. Сами приложения теперь включает в себя множество подязыков и языки на языках. Да можно сделать сборку и пользоваться ей, но она устаревает уже через полгода. С легкостью прыгнуть с проекта на проект не получается, нужно смотреть список задействованных технологий. И проблема здесь не в средствах разработки, не в том фреймворке, который вы выберете, а в требованиях к конечным продуктам. Планка выросла. Мне это напоминает игровую индустрию, раньше игру мог написать один человек, сейчас такая игра никому уже не будет интересна, есть исключения, но это будет не та игра, которые сейчас выпускаются корпорациями.
Lorien_Elf
24.02.2017 14:37Кого-то удивляет, что в ближайшие два десятилетия 99% программистов будут заменены ИИ? :)
stargazr
24.02.2017 18:04Получилась статья о том, что современные инструменты веб-разработки не заточены для написания хелловорлдов.
Замечательно! Продолжайте в том же духе. Ждем разоблачений про использование современных Java IDE для ведения заметок, или про видеоконференции по электронной почте.
JDBaha
26.02.2017 14:57-1Изучение пхп следует начать с:
- Изучения синтаксиса
- Изучения одного из популярных фреймворков
- Поднятия собственного движка
В современных фреймворках куча всего лишнего, всевозможные хелперы, обработчики, орм. Кому они нужны, если отдача простой статической страницы на таком фреймворках занимает 70мс? (тестил на локалке, Yii2).
Doctrine бесполезен в 95% случаях. Куча предобработки в запросах и ради чего? Потому что, возможно, в будущем я перенесу проект на другую SQL бд. Этого не случится в 95%ах случаев. А если и перейдете то далеко не факт что это будет sql поддерживающая бд.
Я поднял свой mvc движок, для своего маленького проекта. И страница отдается за 30мс без запросов к бд. При этом там есть нормальный роутинг, актив рекорд, автолоад классов и удобная подрубка сторонних библиотек.
Фреймворки в большинстве случаев слишком универсальны. За что вы платитесь производительностьюFesor
26.02.2017 16:24+2Изучение пхп следует начать с:
а как по мне когда люди начинают идти по такому пути, где-то упускаются следующие понятия:
- декомпозиция — проектирование системы сверху вниз. Обычно разработчики почему-то строят систему снизу вверх (то есть на скорую руку выбирают нижние кирпичики, например схему базы данных и уже потом лемят оттуда).
- data abstraction — это когда мы делаем сначала методы. описываем поведение, а уже потом думаем о данных (если упрощать)
- инкапсуляция — это та штука которая позволяет улучшить реюз абстракций (не кода позволю себе заметить), позволит DRY-ить код, и в целом улучшит понимание что происходит.
- полиморфизм — это та штука которая уменьшает количество if-в в коде и в целом позволяет юзать "похожие вещи" как одни и те же.
В целом фреймворки или написание своего "движка" тут не помогут от слова совсем.
Куча предобработки в запросах и ради чего? Потому что, возможно, в будущем я перенесу проект на другую SQL бд. Этого не случится в 95%ах случаев.
Давайте немного поговорим о "смене БД". Это дурацкий пример, полностью согласен. Если у нас на проекте была выбрана MySQL то мы от нее вряд-ли сможем далеко убежать. Более того, делать совсем без SQL не выйдет в большинстве задач. Рано или поздно появляется native sql для того что бы максимально эффективно использовать выбранную СУБД.
НО! Вместо смены СУБД на всем проекте мы всегда можем добавить вторую! Просто потому что можем упереться в лимиты СУБД или просто потому что в другой СУБД что-то есть из коробки. Тут уже ORM или любые абстракции от хранилища (DAO вам должно понравится судя по всему) сильно экономят время.
В целом достаточно просто что бы SQL не был размазан по всему проекту и лежал изолированно где-то. А как вы это делаете — это уже детали. Например любители доктрины часто размазывают DQL по всему проекту или EntityManager юзают не только там где надо но вообще везде. Это тоже плохо и противоречит идеи Doctrine.
Я поднял свой mvc движок, для своего маленького проекта. И страница отдается за 30мс без запросов к бд.
Symfony3 + Doctrine 2.5 + выборка из базы = 20ms. Что я делаю не так? Скорость ответов важна, но это лишь значит что мы берем что-то медленное и стандартное а потом оптимизируем узкие места. То есть мы экономим 5x на времени разработки (чтобы вы понимали, во фреймворках покрыты многие кейсы о которых вы даже думать не будете, но если будете вам придется все это реализовать самостоятельно), и потом оптимизируем только то что медленно работает. Например в случае доктрины можно гидрацию данных оптимизировать или на SQL.
А вот уже когда у разработчика достаточно опыта, и он знает хотя бы парочку фреймворков и что там для чего, вот тогда можно лепить свои фреймворки оптимизированные исключительно под проекты которые он делает.
Проблема с фреймворками и разработчиками в основном заключается в том, что большинство даже не пытается разбираться "а зачем там что и как работает".
JDBaha
26.02.2017 17:2230мс — это тоже у меня на локалке. Я думал будет понятно, простите.
Если говорить о проектировании систем то лучше уж почитать Фаулера.
И мне кажется добавление еще одной бд входит в эти 5%. В Doctrine я и в правду не захотел разбираться, как и в симфони. Из коробки симфони у меня на локалке отдает страницу за 200мс, кажется это был второй симфони. После я естественно начал гуглить оптимизацию производительности. Понял что там предстоит нешуточная работа и бросил все это дело.Fesor
26.02.2017 18:32+130мс — это тоже у меня на локалке.
ну и у меня на локалке. Просто я повыпиливал все что не нужно юзать. Ну и запускается это все в продакшен окружении с настроенными кэшами.
Если говорить о проектировании систем то лучше уж почитать Фаулера.
Фаулера почитать стоит конечно, а еще Роберта Мартина, Кента Бэка, Алестера Коберна и других хороших людей. Но их почему-то не читают. Ну и опять же на каком этапе читать то из тех что вы озвучили?
И мне кажется добавление еще одной бд входит в эти 5%.
Повторюсь — "абстракция от базы данных" это не для смены оной, а что бы игнорировать наличие оной когда вы бизнес логику описываете. Это не значит что вы не можете делать все через plain sql, просто все операции с базой должны быть изолированы в отдельных штуках. ORM аля Doctrine просто предоставляет вам один из способов делать это быстро и удобно. Ну то есть в большинстве случаев вы не будете проектировать схему базы данных, вы будете работать только с объектной моделью. То что этот инструмент несет в себе высокий уровень скрытой сложности — это да. И авторы к третьей версии собираются выпилить весь "сомнительный" функционал который позволял делать стремные вещи.
JDBaha
26.02.2017 19:28Повторюсь — «абстракция от базы данных» это не для смены оной, а что бы игнорировать наличие оной когда вы бизнес логику описываете
Это выглядит как ненужный слой, по своей сути дающий profit лишь в редких ситуациях. Ну ладно… у каждого свое видение одного и того жеFesor
26.02.2017 23:14Ну ладно… у каждого свое видение одного и того же
Я пока плохо представляю ваш вижен. Давайте на каком-нибудь маломальски простом примере:
Есть например у нас необходимость давать пользователю скидку, если он накупил товаров за календарный месяц на >$100. Можете описать как бы вы делали, куда ложили бы sql, как выглядел бы код?
p.s. Специально выбирал примеры для которых ORM плохо подходит. Мне интересно именно как вы сделали бы подобное в вашем случае. Куда бы положили эту проверку, делили бы как-то и т.д. Где был бы SQL.
JDBaha
27.02.2017 08:29Тоже самое, только без абстрагирования от бд
class User extends \app\system\model\ActiveRecord { public function haveDiscount() { return 100 < Util::getTransactionHistorySumByPeriod($this->id, strtotime('-1month')); } ... } ... class Util { public static function getTransactionHistorySumByPeriod($iId, $iStart, $iEnd = null) { $sEnd = $iEnd === null ? date('d-m-Y H:i:s') : date('d-m-Y H:i:s', $iEnd); $sStart = date('d-m-Y H:i:s', $iStart); return \app\system\Registry::get('db')->add('SELECT SUM(value) AS total') ->add('FROM transactions') ->add('WHERE "id" = :id AND "created_at" > :start AND "created_at < :end') ->execute([':id' => $iId, ':start' => $sStart, ':end' => $sEnd])->fetch('total'); } }VolCh
27.02.2017 10:45У вас всё таки есть слой, изолирующий бизнес-логику от хранилища, назвали вы его правда Util, но суть не меняется — даже если заменить SQL базу на NoSQL, а то и вообще на облачное хранилище с ptotobuf интерфейсом, то ничего в классе User не поменяется, только в слое Util нужно будет что-то менять.
Другое дело, что если нужно будет вывести список всех клиентов с пометкой есть ли у них право на скидку, то или получим ситуацию 1+N запросов, или нужно будет писать ещё один метод в слое изоляции.
Fesor
27.02.2017 18:39+1Вот если вы переименуете
UtilвTransactionHistoryDaoкакой-нибудь, или простоTransactionHistoryбудет то же что и у меня в проектах с доктриной а не "еще одной реализацией AR". Ну и логику тогда можно было бы ложить в сущности.
Я не зря написал что описанная мной задача решается с ORM плохо, просто потому что задача выходит за пределы OLTP (Online-Transaction Processing).
VolCh
27.02.2017 07:19Как по мне, то это самый нужный слой в сколь-нибудь серьёзном приложении. А так-то, да, можно SQL-запросы в PHP-шаблоны складывать.
VolCh
27.02.2017 07:11Doctrine бесполезен в 95% случаях.
актив рекордТо есть вам не понравилась Doctrine и вы изобрели свою ORM?
Delphinum
27.02.2017 15:42+1В современных фреймворках куча всего лишнего
В 3 версии ZendFramework вообще ничего нет, компонуем только то, что нужно в проекте.
автолоад классов и удобная подрубка сторонних библиотек
Эмм… А зачем все это, когда есть composer со встроенным генератором autoload?
Lordz
28.02.2017 09:12-1А зачем нужны 5 классов «встроенного autoload» если в конце он все равно вызывается spl_autoload_register?
Ну это еще ладно… можно объяснить унификацией подключения сторонних библиотек.
Но в чем круть от писанины автора: «return new JsonResponse(...)», вместо return json_encode(...) ?!
А если этот никчемный класс (JsonResponse) порождается 100 раз в секунду?
ЗЫ. Давайте не забывать, что PHP — язык рожденный умирать! А OOP — это всегда медленно…
PHP + OOP = «hello, Highload»
Предлагаю переименовать публикацию :-)VolCh
28.02.2017 09:53return json_encode(...)
А статус ответа, а заголовки? Да банальный 'application/json', его как возвращать? Ну и унификация: JsonResponse — частный случай Response, какой-нибудь миддлваре всё равно какой из Response вернули, допишет свой заголовок, а какая-то только к JsonResponse что-то допишет или наоборот удалит что-то.
OOP — средство уменьшения сложности. Не бесплатное, да.
Fesor
28.02.2017 11:06А зачем нужны 5 классов «встроенного autoload» если в конце он все равно вызывается spl_autoload_register?
Давайте рассуждать. У нас есть
spl_autoload_registerкоторый позволяет нам сделать цепочки автозагрузчиков. Почему нам важны цепочки? Потому что разные модули нашего проекта, не важно наши они или third-party, могут иметь свои правила автозагрузки (например у вас есть старый модуль из эпохи php5.0 бэз нэймспейсов и новый красивый из эпохи 7.0). Это упрощает использование модулей. Мы просто подключаем автозагрузчик модуля и "едем дальше" вместо того что бы каждый раз вкручивать его в проект.
Далее, почему писать свой автозагрузчик плохая идея в большинстве случаев. Что мы можем написать сами за 1 минуту? Скорее всего это будет тупая функция которая тупо по имени класса будет импортировать какой-то файл.
Что мы можем сделать с composer за одну минуту. Описать PSR-4 автозагрузку или прописать инклуды, и вызвать команду
composer dump --optimize --no-dev --classmap-authoritative. Что дает нам эта команда:
- опция
--optimizeи--classmap-authoritativeпозволит нам составить классмэп (какой класс в каком файле искать), что бы не нужно было вычислять это каждый раз и трогать лишний раз файловую систему. Максимально эффективный способ. - опция
--no-devвыкинет все зависимости которые нам требуются для разработки (phpunit например или тэсты) из мэпы классов. - если у нас миллион зависимостей и узким местом становится инициализация классмэпа, есть другая стратегия, которая позволяет использовать apcu и кэш в рантайме. Для маленьких проектов это не самый эффективный вариант, а вот для большших может быть спасением.
И все это вы получаете… просто так из коробки. Подходит как для маленьких так и для больших проектов. Эфортов разработчика — минимум. Так почему бы не юзать?
Но в чем круть от писанины автора: «return new JsonResponse(...)», вместо return json_encode(...) ?!
скорее вместо:
header('Content-Type: application/json'); echo json_encode($data, JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_AMP | JSON_HEX_QUOT); fastcgi_finish_request();
Раз уж вы о производительности заботитесь. Что будет быстрее, записать в поток 2 раза по 100 байт или 1 раз 200? И сколько это по времени если сравнивать с инстанцированием объектов?
ну и опять же, JsonResponse хэндлит еще и варианты для jsonp (вдруг кто-то тут еще под ie6 пишет), что руками делать уже ой как не удобно.
А если этот никчемный класс (JsonResponse) порождается 100 раз в секунду?
разница между простым вызовом json_encode будет ажно целый порядок, 10^-4 ms vs 10^-5 ms. Экономия на спичках.
ЗЫ. Давайте не забывать, что PHP — язык рожденный умирать! А OOP — это всегда медленно…
рожденный ползать летать не может? С тех пор как PHP родился его нутро пару раз переписывали уже. В данный момент он вполне себе может не умирать. Да, пока плохо с инфраструктурой, но если у нас например запросы на чтение (а их обычно большинство), выборки какие-нибудь, можно взять react или php-pm и радоваться жизни.
Некоторые для этих целей берут nodejs например (то есть запись происходит в php, там формируется набор событий. строится проекция на какую-нибудь монгу или эластику, а node через graphql отдает данные).
А OOP — это всегда медленно…
Не совсем так. Медленно — динамическая диспетчеризация, когда вам надо в рантайме соответствия искать кто кого вызывает. Эти вещи решаются различными инлайн кэшами на уровне интерпретатора (JIT, который обещают впилить в php8, вполне способен на подобные оптимизации). А все остальное — не отличается по производительности.
А хайлоад… это надо быть в top 100 по нагрузкам ресурсов что бы "ООП" стало узким местом. Намнооого чаще узким местом становится кривая архитектура.
Lordz
01.03.2017 00:07рожденный ползать летать не может?
В том то и дело, что PHP отлично летает… по крайней мере до тех пор пока ему булыжник на шею не цепляют.
Концепция «рожден чтобы умирать» это от того что PHP — скриптовый язык, который изначально задумывался для веба, и чтобы следовать простому процессу: получить запрос, обработать его, отобразить вывод и умереть.VolCh
01.03.2017 08:21+1задумывался
Это вы правильно прошедшее время написали, сейчас PHP — язык общего назначения, на котором в том числе пишут и демонов и не только для веба. На уровне языка ничего принципиально отличного от других подобных языков нет. Про экосистему (фреймворки, библиотеки) можно поговорить, но вот язык сам уже не мешает.
- опция
RonBarhash
28.02.2017 15:18Статья в стиле «Страшилка для Джунов» :) После статьи осталось впечатление, что в авторе еще до сих пор живет истеричный джуниор :). А после слов: «Не будем хардкоддить… а лучше запихнем все в постгрес», хочется окатить Вас холодной водой!!! Это не уровень ведущего разработчика, и мне искренне жаль вашего работодателя.
Вы из простой задачи сделали монстра. Привычка полить из пушки по воробьям очень пагубна. Если уж так хотелось использовать базы то, могли бы взять что-то полегче SQLite например или что-то современное, для REST есть куча микро-феймворков… про SPA даже говорить не хочется. У каждого подхода есть свое применение. И лепить популярные технологии во все проекты могут позволить себе только джуниоры, ведь им нужно многому учиться и практиковаться. Ах да, по поводу техники POMODORO, в ней основная идея разбивать рабочий процесс на равные доли (рекомендуется по 25 минут с 5-минутными перерывами и т.д.) Вами он как то странно описан :D Было бы очень интересно услышать от автора, почему он лично считает, в чем преимущества использования фреймворков в разработке :)varanio
28.02.2017 15:29Конечно, статья немного провокационная, содержит некоторый прикол. Конечно, это не хелловорлд, а скорее заготовка для серьёзного приложения.
Но! В остальном никакой истерики тут нет. Следующий новый проект я начну именно так, как описано здесь. Ну, может redux заменю на что-то попроще.RonBarhash
28.02.2017 17:19Я лично, ничего против не имею в том, чтобы использовать Постгрес+Симфони в проектах… Но к статье самой есть :) Я от нее ожидал Вашей интерпритации это задачи с использованием современных технологий, которые используются в 2017 году при разработке на PHP. А в статье много времени рассуждения о базе данных и фронтенде и «ничего» о современном PHP. Хотелось увидеть карикатуру на «Мона Лизу» от совренного художника, а оказалось «Суровые будни — 2017» :D
VolCh
28.02.2017 15:53С другой стороны подобный стэк может быть корпстандартом, на котором по умолчанию начинаются новые проекты без особіх требований. Наш, например, не сильно отличается, из глобального только таблицы ручками не создаём и create-react-app используем для фронта.
DeLuxis
Вы смешали frontend (где действительно избыточно много абстракций) и backend.
Достаточно было создать модель и вывести «Hello world!» из базы во вьюхе через контроллер.
varanio
Согласен, получилось скорее hello, world SPA. Но сейчас SPA со страшной силой шагает по планете. Зайдите в любую современную админку банка и т.д. — там будет реакт. Мне кажется, надо уметь хотя бы хелловорлд всего этого дела.
jobanaro
SPA должен умереть…
Fesor
отчего же? Это же волшебно когда UI на клиенте это не статическая страничка а луп отрисовывающий стэйт! А если еще и выстроен как композиция реюзабельных компонентов, ух… А бэкэнд stateless и в целом не зависит от UI особо, крути верти как хочешь. Дикий простор для творчества. Для определенного процента проектов можно вообще без бэкэнда обходиться благодаря всяким там firebase-ам и похожим сервисам. Идеально для CRUD-like приложений, да и с кодогенерацией для UI и реюзом оного как-то получше дела обстоят.
Конечно же это не для всех проектов/команд подходит… И надо фронтэнды уметь, с чем сейчас тугова-то у людей. То есть свои жирные минусы несомненно есть...
questpc
Мне не нравится JSX из-за смешивания логики (кода) и шаблона. В Knockout.js, который я использую, логика отдельно, шаблон data-bind отдельно. Это позволяет использовать общий шаблон с разными JS классами, что очень удобно. Никаких транспилеров и кучи node.js приложений не нужно, все работает на ES5 без какой-либо прекомпиляции. Сам Knockout.js очень небольшой и содержит все что нужно.
SPA плохи двумя вещами — слабой индексацией в поисковиках и глюками старых браузеров. Я больше использую AJAX компоненты чем чистое SPA. Хотя для админки SPA действительно хорош — там не нужна индексация и вряд ли кто зайдет старым браузером.
varanio
Я раньше также думал. Пока не попробовал.
В JSX есть логика, но это только view логика.
Когда вы в handlebars пишете
ведь это тоже смешение тегов с логикой отображения. Просто в jsx наоборот, смешивается логика с тегами. Что дает определенные преимущества: не надо сочинять свой шаблоноязык, а использовать чистый js.
Разумеется, бизнес-логику нельзя пихать в react-компонент, ни в коем случае. Для бизнес-логики надо юзать redux (или еще какой-нибудь flux), обмениваясь с компонентами событиями и т.д.
VolCh
Нельзя смешивать в одном компоненте бизнес-логику и логику отображения. Разделять вполне можно.
vintage
Так не пишите, оставьте шаблоны простыми.
Fesor
Twig/Nunjucks/Jinja2
Angular
React JSX
Knockout.js
Я это к чему — логика отображения в шаблонах — от этого вы не уйдете. Разница лишь в способах которыми вы это дело разруливаете. JSX это лишь сахар чтобы удобнее было.
Я уже не могу писать просто на es5 без всяких бабелев… к хорошему быстро привыкаешь.
На счет браузеров — согласен, хотя с каждым годом ситуация меняется в лучшую сторону. Ну а по поводу индексации — приведу пример. angular-universal. Server-side рендринг в пол пинка (ну как. относительно конечно).
questpc
Тем не менее в случае knockout / angular мы имеем самый минимум логики в шаблонах (конечно можно запихнуть в data-bind JS-код на несколько строк, только это даже человеку не любящему красоту кода будет очевидно выглядеть плохо), а react как-бы поощряет запихивать побольше кода в шаблон. Понятно что хороший программист будет сдерживать себя.
И еще момент с наследованием этого дела. В ES5 и тем более в ES6 можно прототип метода у потомка заменить и пожалуйста — тот же шаблон knockout.js с другим кодом. В то же время в популярном Vue.js с наследованием оказались огромные проблемы вообще не рекомендуют использовать. Хотя на мой взгляд UI без наследования это нон-сенс.
es5 хорош тем что быстрее проект разворачивать (node.js и прочее не нужны) а также сторонний код можно на лету править.
На react может конечно и надо переходить так как спрос на него огромен, хотя идеологически коробит меня от него, привыкнуть ко всему можно. Куча уже существующего кода на Knockout.js работает и вроде как непонятно зачем. Разве что из-за денег.
Fesor
присмотритесь. Количество логики ровно одинаковое. Разница лишь в синтаксисе. Причем в этом плане у jsx есть преимущество перед knockout — не надо изучать новый синтаксис — все работает на обычном js. Как и в underscore templates например и куче других шаблонизаторов.
yoman, кучи скафолдингов, шаблоны проектов и т.д. решают эту проблему. А за счет es2015+ скорость разработки и удешевление поддержки быстро окупает эти вещи.
В целом я фанат ангуляра так что… я не перейду)
Ronnie_Gardocki
React версию можно отрефакторить до такого:
Fesor
да, так поприятнее. Тогда разница вообще ничтожна.
vintage
$mol:
На таком простом примере преимуществ не видно, но обычно каждая строка — это более сложная штука, так что разделение логики и композиции компонент (аналог шаблонов к компонентной архитектуре) не просто возможно, но и позволяет обуздать сложность, появляющуюся, когда логика идёт вперемешку с кусками html.
vintage
Не this.Empty(), а this.No_pet(), конечно же. И с наследованием тут всё хорошо (прям отлично). И нет, это не "самопиар", а объяснение, как та же проблематика может быть решена лучше.
varanio
Ваш пример не особо лучше. Вы все равно изувечили html, напихав туда свой язык. Как и в других шаблонизаторах
vintage
хтмл — не священная корова. в данном случае используется другой не менее декларативный язык для композиции компонент. и никакой логики в нём быть не может синтаксически.
Fesor
А на каком будет видно и в чем заключается преимущество? Мы уже как-то дискутировали на эту тему — ваш вариант возможно и имеет свои плюсы, но не годится для большинства людей.
vintage
На любом более-менее реальном. Ну, банальная задача: в зависимости от флага заворачивать содержимое в дополнительную обёртку. И тут начинаются пляски с партиалами, хелперами, а то и вообще копипастой.
При разделении композиции и логики вы просто пишете, например:
А потом добавляете отдельно любой сложности логику:
Fesor
То есть вывести список — не реальная задача?
Как по мне это больше похоже на костыли нежели "реальную задачу". Мне дико не нравится сама идея что дети управляют родителем. Мне больше по душе в другую сторону, когда контейнер решает что у него внутри. Либо приведите менее абстрактное описание зачем это может понадобиться.
vintage
Вывести список строк в одиночном теге — не реальная. Более типично — вывести список из деревьев, причём каждый элемент списк должен иметь классы/аттрибуты. В том числе и динамические.
Так тут родитель (блок $my_app) и управляет всеми своими элементами (Card, Info, Salary).
VolCh
Очень реальная. Пример — вывести табличку с заголовком строки в виде ФИО клиента и одним из столбцов через запятую номера заказов.
vintage
Только номера заказов должны быть ссылками на страницы этих заказов. Если заказов слишком много, то список должен заворачиваться в спойлер. Клик по имени должен открывать профиль клиента со всеми его заказами.
VolCh
Сложно по бумаге кликать.
vintage
Версия для печати — очень частный случай.
VolCh
Большинство отчётов не нуждаются в интерактивности, даже если формально не печатаются.
vintage
У нас ровно противоположная статистика.
VolCh
У нас отчёты — это отчёты. Если отчёт подробный, то там всё и так есть. Если агрегированный, значит детали никого не интересуют. Были попытки получить интерактивность у отчётов, но и показали другой инструмент и сказал, что это то, что нужно.
Fesor
Значит ваша выборка "реальных случаев" не может быть репрезентативной. Да и вывести ссылку — не сильно сложная проблема и я все еще не вижу "преимуществ" вашего подхода. "Мутация" контейнера детьми я расцениваю больше как какой-то костыль, хотя не отвергаю вероятности что вам это для чего-то нужно.
В целом же как по мне ваш варинт излишне сложен если сравнивать его с любым другим.
vintage
А какая может? Будет чудесно, если вы приведёте ссылку на репрезентативную статистику.
Я говорил про не только ссылку.
Тут нет никакой мутации контейнера. Тут вывод либо одного компонента, либо другого. И это вполне штатная ситуация для нормального инструмента.
Реализуйте мой пример по проще :-)
Fesor
Если я правильно понимаю о чем ваш пример.
vintage
Нет, типичная реализация того же на Ангуляре будет выглядеть так:
Fesor
Эм...
ngElse. Это атрибут элемента, он ничего не знает о соседях.Ну то есть мэйнстрим подход, UI как композиция UI компонентов.
vintage
Fesor
не то что бы повторить, у вас должен быть красивый и удобный метод во вью модел который проверяет это условие, и там где надо просто надо добавить отрицание. Логика провери же будет инкапсулирована.
Почему я считаю что такой подход "удобнее" — потому что, как вы заметили тут в комментариях, далеко не все разработчики компетенты. И их нужно ограничивать. А это значит надо делать компоненты максимально тупыми и выносить из них логику. Такие компоненты и тестить удобнее, и в целом приятно работать.
vintage
Суть от этого не меняется — нужно повторить вызов метода. А если надо будет привязаться к другому методу, то оба вызова надо будет поправить.
От того, что вы разобьёте один компонент на два сильносвязанных, вы никому жизнь не облегчите, а только усложните. Выносить в отдельный компонент имеет смысл лишь переиспользуемую логику.
Fesor
Как жаль что при построении логических выражений нет возможности делать отрицания....
так ее и нет, вся логика в презентерах.
компоненты не могут быть "сильносвязанными". Они либо имею связи/зависимости либо нет.
vintage
В одно месте вам нужно написать "asCard()", в другом "!asCard()". А если нужно первый блок показать при выполнении условий А и Б, второй — Б и В, а третий — А и С? Да, вы можете создать отдельные методы вида "isFirstBlockShowing", но:
Ангуляр не фосирует вынос логики, а наоборот поощряет её написание прямо в шаблоне. И даже если вы лично выносите всю логику, то большинство разработчиков заморачиваться не будут. А фреймворк должен поощрять хорошие практики и препятствовать плохим.
Могут. Выделяя как попало компоненты вы получаете такие вложенные компоненты, которым нужна половина свойств владельца. Ну или они реализуют эту половину свойств самостоятельно копипастой.
VolCh
Очень спорное утверждение, противоречащее многим общепринятым принципам проектирования типа того же принципа единственной ответственности.
vintage
Компонент, созданный лишь для того, чтобы его можно было помещать в разные места, — не несёт какой-то уникальной ответственности.
Fesor
на абстрактных "компонентах" — возможно, как никак что бы определить зону ответственности компонента надо знать что за компонент и за что он отвечает. Потому приведите пример подобной ситуации когда то что мы выноситм не сможет являться полноценным самодостаточным компонентом.
На моей памяти подобного небыло. Были компоненты занимающиеся отображением, весьма тупые, и компоненты-контейнеры, которые максимум разруливали какие компоненты показывать, но не занимались отображением непосредственно.
в целом — да, но можно во вью модели логику подублировать всегда. У разработчиков всегда будет возможность сломать инкапсуляцию и продублировать логику. С этим надо бороться другими способами.
Есть такая проблема. Нужна нормальная декомпозиция, а многие разработчики почему-то этого не умеют.
vintage
Ок, пусть это будет карточка товара: Фотка, название, описание, цена, список тегов. На всех страницах товары показываются такими карточками, но на некоторых страницах карточка должна быть ссылкой, а на некоторых — нет.
VolCh
Решение в лоб
vintage
Замечательно, тольво вы забыли прокинуть alt в картинку, title в ссылку, завернули теги в ссылку (они ведь тоже должны быть ссылками), в стоимость не прокинули валюту (которую надо оформлять другим цветом), плюс у вас появился совершенно лишний див. А уж про прокидывание правильных классов для навешивания стилей я вообще молчу. Ну и, конечно, создали пяток совершенно лишних компонент, которые нигде не будут использоваться кроме как тут.
VolCh
Всё строго по ТЗ :) Единственное замечание которое принимаю сходу — title в ссылку, но только как фичереквест. О всём остальном вы не можете судить по этому фрагменту, не зная схемы объекта product. А div не лишний, а несёт семантическую нагрузку — отделяет карточку продукта от остального документа, делает её самостоятельным элементов, на который, в числе прочего, можно ссылаться в файлах стилей. И компоненты лишними не считаю, даже если они не будут переиспользоваться — они улучшают поддерживаемость кода. Вот захотели вы валюту указывать — я джуну скажу "там есть элемент ProductPrice — добавь наименование валюты", а без компонентов придется "там есть семиэтажный Product, поройся в нём, найди часть, где цена выводится и добавь наименование валюты"
vintage
ТЗ изменилось. Сколько вам времени потребуется на рефакторинг всего проекта под новые требования, описанные в предыдущем сообщении?
Вы на имя тега будете ссылаться в файлах стилей?
Для отображения валют в разных местах имеет смыл создать компонент CurrencyValue. Отображать ProductPrice вне ProductCard было бы странно.
VolCh
title для ссылки откуда брать? product.name или product.link.title? Если первое, то до десяти минут, включая деплой на стейдж- сервер. Если второе — ждём бэкенедеров и плюс 10 минут.
Пока в проекте только одно место, где нужно отображать. Появится второе — будем смотреть что в них общего.
vintage
Боюсь вы не замечаете масштаб трагедии. Тэги должны являться ссылками, поэтому вы не можете взять и снаружи завернуть всю карточку в ссылку. Ссылка должна быть внутри карточки и при этом опциональной.
VolCh
Согласно ТЗ и реализовано. Никаких "внутри" в ТЗ нет. Ели опять ТЗ меняется, то уточните, что значит "внутри". И почему не могу завернуть ссылку в ссылку?
vintage
http://kizu.ru/fun/nested-links/
VolCh
http://jsfiddle.net/L7AxY/
vintage
VolCh
Работает?
vintage
Нет, работать оно будет либо в режиме XHTML, либо если вы создаёте DOM скриптом. О каком-либо изоморфном рендеринге HTML в таком случае придётся забыть.
VolCh
В ТЗ что-то было про изоморфный рендеринг? По умолчанию у нас обеспечивается только функциональность в актуальной стабильной версии Chrome, что фиксируется в коммерческом предложении на внедрение и SLA, ну в Firefox потестим чтобы вёрстка не плыла глобально, а практически весь body генерируется скриптами, клиенту отдаётся минимальная статическая страница.
vintage
Прятаться за вами же написанным кривым тз — верх непрофессионализма. Не удивляйтесь потом, что ваши клиенты уйдут к конкурентам, которые продумывают последствия принятых технических решений и обсуждают их с заказчиком заранее, а не когда заказчик понимает, что вы сделали какашку, а он даже не может потребовать исправления. Тактически вы выиграли тысячу рублей, стратегически потеряли сотни тысяч.
Вы когда к стоматологу приходите — тоже выкатываете ему подробное тз или всё же рассчитываете на его профессионализм и понимание что и для чего он делает и к каким последствиям это приведёт?
VolCh
Не за нами написанным, за вами.
vintage
У вас видимо очень продвинутые заказчики, раз сами пишут вам ТЗ :-)
VolCh
Мне не важно кто пишет, наши заказчики или наши аналитики, главное, что я не пишу.
Fesor
Справедливости ради, вот эти "в тз небыло" немного напрягают. А как же protected variations?
VolCh
Небольшие (с точки зрения заказчика) могут полностью перевернуть подход к разработке. Навскидку, для изоморфного рендеринга React-"шаблонов" я вообще никаких оценок дать не могу — знаю, что некоторые люди это как-то делают, вероятно с помощью http-сервера на NodeJS. Всё. Есть ли у React различия между рендерингом в DOM и в http-ответ я не знаю, в этом направлении в компании вообще ничего не делалось никогда. И вообще, может из-за требования изморфного рендеринга нужно будет полностью пересмотреть бэкенд часть. Ну или оставить PostgreSQL, но выпилить из проекта PHP и меня вместе с ним.
Обеспечивать во фронтенд коде совместимость с каким-то сервером, которого разработчик в глаза не видел — это не мелочь, которую можно опустить в ТЗ по принципу "это же очевидно, вы же профессионалы"
vintage
Представьте, что у заказчика уже есть изоморфное приложение, вам нужно лишь добавить раздел с товарами. Если вы не будете учитывать спецификации, то обретёте проблемы с тем, как браузеры и роботы понимают генерируемый вашим кодом HTML.
VolCh
Для такой задачи я увеличу сроки на месяц, даже если оценю её чисто для фронта на час. И то с большими рисками не уложиться.
vintage
А я увеличу на неделю и уведу у вас заказчика :-Р
Fortop
Вы нам лучше объясните какой плюс заказчику от изоморфного рендеринга :)
vintage
Ну, там разные тезисы: генерация html-писем, индексирование поисковиками и прочими роботами, поддержка отключённых скриптов и браузеров не поддерживающих скрипты, экспорт в хтмл, быстрый показ страницы, экономия батарейки клиентского девайса.
Fesor
Ну например "хотите чтобы ваш круто интернет-магазин вообще поисковиками индексировался" или "хотите чтобы конверсия не падала от того что апа загружается у пользователей 5 секунд".
Продать изоморфность весьма просто. И в целом это не требует каких-то больших эфортов если делать нормально.
@vintage я вот только ваш кейс с "а тепер весь блок продукта стал ссылкой" немного не понял. Мне всегда казалось что делать блоки ссылками — не хорошо, и как правило была бы ссылка где-то внутри блока а какой-то декоратор над контейнером уже бы превращал весь блок в ссылку. Это как бы и кейс изоморфности покрывает, и делать легко и просто, и нет конфликтов со спецификациями.
VolCh
У каждого компонента ровно одна собственная уникальная ответственность. Будет она переиспользоваться где-то, может будет дублироваться — дело десятое. Главное — декомпозиция ответственностей и обязанностей.
vintage
Замечательно. А если мне нужен ListItemsOrNoItems, но с другими ListItems и NoItems?
VolCh
Что-то вроде
ListItemsOrNoItems = (items, AbstractListItems, AbstractNoItems) => items.length !== 0 ? <AbstarctListItems items={items}/> : <AbstarctNoItems/>;и вызов
codehtmlP.S. что-то разметка глючит
vintage
Очень наглядно, спасибо.
VolCh
Естественно в компоненте могут быть определены значения по умолчанию для дочерних элементов — если не указано, то берем стандартный.
vintage
Чудесно, особенно когда таких опциональных компонентов больше 2.
VolCh
Это же XML по сути.
vintage
Это лапша. И в жизни это так не работает, так как вы не прокидываете параметры в в создаваемые тут компоненты.
VolCh
Присмотритесь — прокидываю. И в чем лапша?
vintage
Вы прокидываете один единственный параметр — items.
VolCh
От количества параметров что-то зависит? Тем более их можно группировать в объекты типа options
vintage
Конечно, апи усложняется, апи меняется, вы решили очень частную задачу, и это решение не переиспользуемо.
Наговнокодить-то на реакте легко и просто, я с этим не спорю. Но вот сделать гибкое, легко поддерживаемое, понятное решение — это нужно попариться.
VolCh
Чем оно не переиспользуемо? Вывод списка элементов или элемента, замещающего пустой список — типовая задача и данный сниппет её решает. Передачу дополнительных параметров (что обычно для таких задач не требуется, стили или инлайнятся/импортятся в конкретных элементах, или через контекст передается тема) для дочерних элементов можно реализовать разными способами, например через…
vintage
Договаривайте уж. Через контекст? Глобальную переменную? Урл?
VolCh
Это не многоточие русского языка, а рест оператор джаваскрипта/джейэсикс :)
vintage
что ж вы сразу-то этого не сделли? Давайте посмотрим какой код у вас получится.
vintage
Для сравнения, у меня получился такой.
Рендерит списки любых компонент, а если список пустой — рендерит опять же произвольный компонент переданный владельцем. При этом не трубется никаких прокидываний параметров через...
varanio
На реакте написаны facebook, сбербанк, тинькоф, слак. Я думаю, что, исходя из этого, можно утверждать, что любые проблемы решаются, так или иначе. Такой ли список рендерить, сякой и т.д.
vintage
Разница в стоимости этого решения и стоимости его поддержки. Тинькоф — вообще чудесный пример — орава разработчиков сделала тормозной сайт, где некоторые страницы рендерятся по 4 секунды :-)
VolCh
Не видел необходимости. KISS
vintage
Теперь она появилась, не заставляйте иеня упрашивать вас написать полноценное переиспользуемое решение, которое можно применять в реальных ситуациях, а не только в комментариях на Хабре :-)
VolCh
Не заставляйте меня делать продакшен решение в комментариях на хабре по неясным для меня критериями переиспользуемости.
vintage
Ну, я же не поленился, и сделал продакшен решение по максимальным критериям переиспользуемости. Потратил на это (включая написание демонстрационного примера) не более 5 минут. Неужели на реакте это потребует сильно больше времени? Как же так?
VolCh
Сформулировать требования к переиспользуемости много времени займёт. Навскидку, рассматривать ли возможность замены тегов ul, li и т. п.
vintage
Разумеется :-)
VolCh
Как правило, приложение, в отличии от сайтов и порталов, не нуждается в индексации.