Вот вам пример — в среде нанимателей кочует задачка на тему: «почему канализационные люки круглые?». Правильный ответ кандидата на должность разработчика: «Круглые, потому, что, т. к. диаметр круга одинаков, то люк круглой формы никогда не провалится в колодец...». Правильный ответ аналитика: «Потому что стволы деревьев на спил круглые».
Вот это прям кошмар-кошмар! Люки круглые, потому что колодцы обычно круглые — удобнее же одинаковые формы такими же накрывать. А колодца круглые — потому что арочная форма бетонного кольца лучше всего противостоит боковому давлению грунта — так сказать, материалоемкость изделия минимальна.
Кстати, можно придумать и схему без сколь нибудь длительного резерва. В этой схеме сложнооткатываемым шагом является транзакция платежной системы. А вот операция с билетом, как мне кажется, — легко откатывается назад.
Поэтому транзакцию платежной системы тащим в самый низ по схеме (перед визуализацией ставим). Перед ней просим билет у ресурсной системы, если платеж не прошел — то после нее «возвращаем» билет в ресурсную систему.
К недостаткам стоит отнести, что пользователю об ошибке мы говорим в самом конце. Он потратил время на выбор места, а только в самом конце узнает, что не вышло.
К достоинствам — тут очень короткое время резерва, не зависящее от пользователя. А поэтому невозможна атака класса ДОС.
(это когда «особо умный» пользователь открыл вкладок и поставил все ваши билеты в резерв. продать больше вы ничего не можете)
А я не очень понял, к какому конкретно утверждению в 1 задании относится вопрос «почему?». Почему жульническая?
Ну потому что не соответствует законодательству.
1) Билеты являются бланками строгой отчетности. Их выпуск занимает существенное время и не может пройти в короткий промежуток заказа.
2) Выпуск билета — операция с негарантированным результатом. Поэтому в случае неудачи — вообще не понятно, за что вы с клиента взяли деньги? Да и в случае удачи тоже отчасти этот вопрос остается.
3) Платежные системы обычно печатают и кассовые чеки (электронные). А в чеке должно быть указано, «что купил». А по схеме этой информации вообще не существует на момент оплаты.
И да, правильно выше заметили о необходимости резерва (на глаз с 5го по 14й пункт должен покрываться с резервом и отдельно подумать о таймауте снятия с резерва) — правда резерв можно ставить только на то, что уже существует. А раз билета еще нет — то и резерв на него не поставить.
Можно и без резерва, но тогда с 5 по 14 пункт — должны быть атомарной операцией (условно, будто бы одной транзакцией, которая либо прошла целиком, либо нет).
Просто сегодня производительность компьютеров позволила использовать новые техники разработки. С точки зрения жручести ресурсов они ужасны, но бизнесу и пользователям — фичи намного важнее стабильности. Именно так пользователи голосуют рублем. Пользователи могут и роптать на стабильность, но она все же не на первом месте. Выиграет продукт, где фич больше и добавляются они быстрее. А для стабильности — я бы описал ее как ограничение «число багов терпимо» — все, что лучше этой планки — уже достаточно и дальнейшее улучшение не приносит пользы на рынке.
Эти новые техники в основном сводятся к:
1) переиспользованию армии разработчиков сайтов. Их намного больше, чем остальных программистов. Вполне логично для человечества использовать их ресурсы.
2) более декларативный (высокоуровневый) подход. Условно «собираем программу из готовых кубиков функционала». Он делает вход в профессию легче. А еще позволяет сосредотачиваться на логике приложения, не отвлекаясь на детали реализации.
3) реальная кроссплатформенность. Веб технологии позволяют одному и тому же коду работать как на смартфоне, так и на десктопе — и на разных платформах этих устройств, и работать примерно одинаково. Я бы сказал, что им удалось достичь кроссплатформенности намного лучше остальных технологий.
4) смещению тестирования продукта с разработчиков на пользователей. Тут есть объективные причины:
а) глаз у разработчика замыливается и ему плохо удается поиск ошибок. Поэтому существуют парное программирование. Поэтому тестеры и разработчики — разные люди.
б) пользователей намного больше, чем разработчиков продукта. Они сделают это на порядки быстрее.
Вот пункты 1,2,3 — все жертвуют ресурсами в угоду скорости добавления фич. Пункт 4 жертвует числом багов в угоду скорости добавления фич.
Ок, давайте назовем это по-другому. HTML и CSS, которые раньше ждали от дизайнеров, сейчас переходят к фронтенд-разработчику. Область дизайнеров сужается до концепции интерфейса.
Именно об этом тренде я и писал.
То, что вы написали на реакт — является просто ООП подходом. Весь ООП — он про переиспользование кода и упрощение разработки в больших проектах. Вы и получили от него эти преимущества.
Не думаю, что отдельно подход HTML-in-JS добавил каких-то преимуществ. Мне кажется, что там из js делается html, что был бы просто какой-нибудь template engine с html — примерно одно и то же на выходе получилось бы.
А вот работу дизайнеров это способно усложнить. Ранее они могли одним взглядом пройти по HTML — увидеть полную структуру страницы и по ней писать CSS. Теперь придется проводить полный тест приложения, ведь реакт может внезапно по какому-то условию показать новый блок html. Но если js-разработчик и дизайнер — это одно лицо, то вообще проблемы не будет. Думаю, рынок идет в этом направлении.
То, что вы написали на реакт — является просто ООП подходом. Весь ООП — он про переиспользование кода и упрощение разработки в больших проектах. Вы и получили от него эти преимущества.
Не думаю, что отдельно подход HTML-in-JS добавил каких-то преимуществ. Мне кажется, что там из js делается html, что был бы просто какой-нибудь template engine с html — примерно одно и то же на выходе получилось бы.
А вот работу дизайнеров это способно усложнить. Ранее они могли одним взглядом пройти по HTML — увидеть полную структуру страницы и по ней писать CSS. Теперь придется проводить полный тест приложения, ведь реакт может внезапно по какому-то условию показать новый блок html. Но если js-разработчик и дизайнер — это одно лицо, то вообще проблемы не будет. Думаю, рынок идет в этом направлении.
Вот это прям кошмар-кошмар! Люки круглые, потому что колодцы обычно круглые — удобнее же одинаковые формы такими же накрывать. А колодца круглые — потому что арочная форма бетонного кольца лучше всего противостоит боковому давлению грунта — так сказать, материалоемкость изделия минимальна.
Поэтому транзакцию платежной системы тащим в самый низ по схеме (перед визуализацией ставим). Перед ней просим билет у ресурсной системы, если платеж не прошел — то после нее «возвращаем» билет в ресурсную систему.
К недостаткам стоит отнести, что пользователю об ошибке мы говорим в самом конце. Он потратил время на выбор места, а только в самом конце узнает, что не вышло.
К достоинствам — тут очень короткое время резерва, не зависящее от пользователя. А поэтому невозможна атака класса ДОС.
(это когда «особо умный» пользователь открыл вкладок и поставил все ваши билеты в резерв. продать больше вы ничего не можете)
Ну потому что не соответствует законодательству.
1) Билеты являются бланками строгой отчетности. Их выпуск занимает существенное время и не может пройти в короткий промежуток заказа.
2) Выпуск билета — операция с негарантированным результатом. Поэтому в случае неудачи — вообще не понятно, за что вы с клиента взяли деньги? Да и в случае удачи тоже отчасти этот вопрос остается.
3) Платежные системы обычно печатают и кассовые чеки (электронные). А в чеке должно быть указано, «что купил». А по схеме этой информации вообще не существует на момент оплаты.
И да, правильно выше заметили о необходимости резерва (на глаз с 5го по 14й пункт должен покрываться с резервом и отдельно подумать о таймауте снятия с резерва) — правда резерв можно ставить только на то, что уже существует. А раз билета еще нет — то и резерв на него не поставить.
Можно и без резерва, но тогда с 5 по 14 пункт — должны быть атомарной операцией (условно, будто бы одной транзакцией, которая либо прошла целиком, либо нет).
Эти новые техники в основном сводятся к:
1) переиспользованию армии разработчиков сайтов. Их намного больше, чем остальных программистов. Вполне логично для человечества использовать их ресурсы.
2) более декларативный (высокоуровневый) подход. Условно «собираем программу из готовых кубиков функционала». Он делает вход в профессию легче. А еще позволяет сосредотачиваться на логике приложения, не отвлекаясь на детали реализации.
3) реальная кроссплатформенность. Веб технологии позволяют одному и тому же коду работать как на смартфоне, так и на десктопе — и на разных платформах этих устройств, и работать примерно одинаково. Я бы сказал, что им удалось достичь кроссплатформенности намного лучше остальных технологий.
4) смещению тестирования продукта с разработчиков на пользователей. Тут есть объективные причины:
а) глаз у разработчика замыливается и ему плохо удается поиск ошибок. Поэтому существуют парное программирование. Поэтому тестеры и разработчики — разные люди.
б) пользователей намного больше, чем разработчиков продукта. Они сделают это на порядки быстрее.
Вот пункты 1,2,3 — все жертвуют ресурсами в угоду скорости добавления фич. Пункт 4 жертвует числом багов в угоду скорости добавления фич.
Именно об этом тренде я и писал.
Не думаю, что отдельно подход HTML-in-JS добавил каких-то преимуществ. Мне кажется, что там из js делается html, что был бы просто какой-нибудь template engine с html — примерно одно и то же на выходе получилось бы.
А вот работу дизайнеров это способно усложнить. Ранее они могли одним взглядом пройти по HTML — увидеть полную структуру страницы и по ней писать CSS. Теперь придется проводить полный тест приложения, ведь реакт может внезапно по какому-то условию показать новый блок html. Но если js-разработчик и дизайнер — это одно лицо, то вообще проблемы не будет. Думаю, рынок идет в этом направлении.
Не думаю, что отдельно подход HTML-in-JS добавил каких-то преимуществ. Мне кажется, что там из js делается html, что был бы просто какой-нибудь template engine с html — примерно одно и то же на выходе получилось бы.
А вот работу дизайнеров это способно усложнить. Ранее они могли одним взглядом пройти по HTML — увидеть полную структуру страницы и по ней писать CSS. Теперь придется проводить полный тест приложения, ведь реакт может внезапно по какому-то условию показать новый блок html. Но если js-разработчик и дизайнер — это одно лицо, то вообще проблемы не будет. Думаю, рынок идет в этом направлении.