Обычно отправляется токен, сумма для списания. Дальше при необходимости уже 3D secure дергается со стороны банка эквайера. Номер карты передавать уже не нужно.
1. Рекомендация SEO, у нас были дубликаты со слешем и без
2. Писали — наступили на грабли. Некоторые сразу увидели, некоторые спустя какое-то время
3. У нас весь роутинг в nginx, приложение получает только GET запрос.
Проблема тут не совсем в том, где роутинг изначально делался. Когда вы работаете один или в команде есть человек, который стоял у истоков и всё хорошо знает — замечательно. Но часто бывает, что проект живет больше 5 лет и люди менялись каждые полгода-год. В итоге приходит человек вроде меня и видит не то, что даже вавилонскую башню, а просто сборную солянку. И всё потому, что изначально был задан дурной тон в разработке, велосипедостроение, никакой оглядки на best practices и стандартизацию. Всё начинается с мелочей, а заканчивается «разбитыми окнами». Разобраться и навести порядок — не знаю реально ли. Уже не первый раз в такое попадаю. Раньше сваливал побыстрей.
Рассмешили :)
Сейчас работаю в проекте под большой нагрузкой, где делали изначально роутинг на веб-сервере. Вышел такой некислый кусок nginx строк на 800. Прошло несколько лет, наняли SEO-оптимизатора. Интересно, вы представляете, сколько грабель было собрано на продакшене, пока отрубали банальный trailing slash в ссылках?
Да, сертификация PCI DSS — титанический труд, как не помнить такое :)
Вот тут в конце упомянули про библиотеку под Android. Как-то то ли на Тостере, то ли у знакомого всплывал вопрос на тему её использования. Ничего толкового нагуглить не удалось. В лучшем случае были отсылки на экзотические способы установки node.js на рутованые девайсы. Так как же на самом деле обстоят дела?
На мой взгляд это не такая серьезная проблема, хотя реализация не помешала бы. Достаточно использовать WSS и тут, правда, без nginx никак, а также настроить фильтрацию origin domain.
Да, это гораздо лаконичнее того, что я когда-то писал xml-ем под phing :) Правда под ним был еще dbdeploy, позволявший управлять миграциями в БД.
Надо попробовать.
История из 2010-х. Ехал друг на машине, вокруг кружился неадекват на другой. Встали на светофоре. Друг вышел рассказать, что так ездить нельзя. Тот вышел и молча нокаутировал моего друга поставленными ударами кулаков. Друга привела в чувства подняла коллега, ехавшая с ним, но тот уже скрылся. Поехал в травмпункт — сотрясение мозга.
Я считаю легко еще отделался.
Спасибо выглядит неплохо, но не совсем то, что мне нужно. Иногда микрофреймворк нужен не для микроприложений, а для слабой связности компонентов и низкого оверхеда, чтобы интегрировать в имеющийся код.
Мне надо что-то вроде 50% функционала стандартного Symfony 2. То есть с yaml-роутингом и конфигурационными файлами, symfony-translate, twig и DI хоть в каком-нибудь виде. Мне показалось проще допилить Silex до этой комплектации, чем урезать Symfony. По крайней мере в случае с Silex накоплена обширная база знаний.
P.S. я вспомнил еще один нюанс с компонентами 2.8 — негарантированная поддержка php 5.3, что опять же существенно для меня в настоящий момент, увы.
Писать — что?
Конечно в лидерах по такому опросу будут RAD-фреймворки из-за количественного преобладания задач по созданию типовых веб-сайтов.
А если я занимаюсь поддержанием и развитием legacy кода под большой нагрузкой, в котором много backend логики реализовано?
Я лично выбрал Silex.
try-catch я воспринимаю как некий подвид goto, связанный с ошибками, которые нужно словить далеко от текущей области видимости.
Описанный подход можно конечно использовать, но он мне кажется больше сопряжен с возможностью накосячить.
Я тоже периодически спрашиваю себя: а не пора ли прикрутить js-фреймворк с шаблонизатором и роутингом? Проблема тут только в том, что не всегда понятен roadmap со стороны бизнеса и палить из пушки по воробьям не хотелось бы.
С другой стороны, есть свой проект, как раз SPA, но делал через пень-колоду на голом jquery и requirejs. Надо бы перевести его на js-фреймворк. Наверное ваш опыт поможет сократить время :)
Я вижу смысл в случае, когда есть сразу два разработчика: для бекенда и фронтенда.
Тогда мне, как бекенд-разработчику меньше работы, чтобы отдавать структурированные данные и не забивать себе голову клиентской частью.
Либо в случае, когда приложение начинает всё больше походить на SPA и тогда серверный рендеринг становится действительно 5-м колесом.
2. Писали — наступили на грабли. Некоторые сразу увидели, некоторые спустя какое-то время
3. У нас весь роутинг в nginx, приложение получает только GET запрос.
Проблема тут не совсем в том, где роутинг изначально делался. Когда вы работаете один или в команде есть человек, который стоял у истоков и всё хорошо знает — замечательно. Но часто бывает, что проект живет больше 5 лет и люди менялись каждые полгода-год. В итоге приходит человек вроде меня и видит не то, что даже вавилонскую башню, а просто сборную солянку. И всё потому, что изначально был задан дурной тон в разработке, велосипедостроение, никакой оглядки на best practices и стандартизацию. Всё начинается с мелочей, а заканчивается «разбитыми окнами». Разобраться и навести порядок — не знаю реально ли. Уже не первый раз в такое попадаю. Раньше сваливал побыстрей.
Сейчас работаю в проекте под большой нагрузкой, где делали изначально роутинг на веб-сервере. Вышел такой некислый кусок nginx строк на 800. Прошло несколько лет, наняли SEO-оптимизатора. Интересно, вы представляете, сколько грабель было собрано на продакшене, пока отрубали банальный trailing slash в ссылках?
Вот тут в конце упомянули про библиотеку под Android. Как-то то ли на Тостере, то ли у знакомого всплывал вопрос на тему её использования. Ничего толкового нагуглить не удалось. В лучшем случае были отсылки на экзотические способы установки node.js на рутованые девайсы. Так как же на самом деле обстоят дела?
Делал чатик с помощью Ratchet, замечательно работает под этим браузером.
Надо попробовать.
empty($array[$key]) ~ !isset($array[$key]) || $array[$key] == false
Я считаю легко еще отделался.
Мне надо что-то вроде 50% функционала стандартного Symfony 2. То есть с yaml-роутингом и конфигурационными файлами, symfony-translate, twig и DI хоть в каком-нибудь виде. Мне показалось проще допилить Silex до этой комплектации, чем урезать Symfony. По крайней мере в случае с Silex накоплена обширная база знаний.
P.S. я вспомнил еще один нюанс с компонентами 2.8 — негарантированная поддержка php 5.3, что опять же существенно для меня в настоящий момент, увы.
Конечно в лидерах по такому опросу будут RAD-фреймворки из-за количественного преобладания задач по созданию типовых веб-сайтов.
А если я занимаюсь поддержанием и развитием legacy кода под большой нагрузкой, в котором много backend логики реализовано?
Я лично выбрал Silex.
Описанный подход можно конечно использовать, но он мне кажется больше сопряжен с возможностью накосячить.
Достаточно было использовать адаптивную верстку.
С другой стороны, есть свой проект, как раз SPA, но делал через пень-колоду на голом jquery и requirejs. Надо бы перевести его на js-фреймворк. Наверное ваш опыт поможет сократить время :)
Тогда мне, как бекенд-разработчику меньше работы, чтобы отдавать структурированные данные и не забивать себе голову клиентской частью.
Либо в случае, когда приложение начинает всё больше походить на SPA и тогда серверный рендеринг становится действительно 5-м колесом.