Т.е., "код возврата" — это HTTP Status, в котором не предусмотрены ошибки бизнес-логики. Я правильно понимаю, что вы, как клиент, предпочитаете в случае ошибки на уровне бизнес-логики (например, "клиент с таким ИНН уже есть") получить ответ от сервера со статусом 200?
лично мне намного удобнее, когда бросят эксепшн при неудачном логине
Только если вам нет нужды объяснять user'у перед экраном, что же, собственно, произошло нехорошего на той стороне интернета, из-за чего самый важный и срочный запрос в его жизни не проходит. Причем в максимально удобной и понятной для него форме, чтобы он самостоятельно вырулил из сложившейся ситуации и по-возможности минимально вынес мозг call-центру. А так — да, для разговоров "server-to-server" достаточно в лог скинуть сообщение и стектрейс.
Люто возопил от одного названия — "багодельня"! Плюсанул уже только за это. А тут и еще сама идея оказалась творческой — ввести соревновательный элемент в достаточно унылый процесс разгрёба багов. ОК, пусть идея не новая, но ругать ссср'овские субботники могут только те, кто ни на каких не был. Там обычно бывает весело ;)
Меняйте работу в таком случае. Не спеша, плавно — но меняйте. Иначе превратитесь в крутого спеца по наложению г@вен шпателем особо тонким слоем. Как говаривал один старик: "побеждает тот волк, которого мы кормим" (с)
Мне кажется, что не так важно, кто придумал топор — добрый человек или преступник. Важнее, кто им пользуется. Пока в мире существует хотя бы один преступник или маньяк, всегда есть ненулевая вероятность попадания топора в его руки.
Ну да, если обрабатывать по 100 паролей в секунду, то при длине цифрового пароля в 8 символов на подбор уйдет не более 278 часов, а при длине пароля в 6 символов — не более 3. А если бы 6-символьный пароль содержал еще и символы в нижнем или верхнем регистре, то на брутфорс такого пароля ушло бы не более 252 дней. Это при учете, что все 252 дня сервер отвечал бы со скоростью 100 паролей в секунду.
Я даже не ожидал, что где-то еще используются чисто цифровые пароли. Повезло, однако :)
По стилю изложения напоминает "Легкий способ бросить курить" Алана Карра. Там целую книгу в ступе толклась одна банальная мысль: "хочешь бросить курить — не кури". Со всех возможных и невозможных сторон. У меня даже мысли про НЛП и зобирование мелькали при ее прочтении. Но я ее часа за два-три прочитал и курить бросил. Сомневаюсь, что хоть кто-то бросит курить, прочитав ту же мысль вот в этом посте. Информация до разных людей доходит по-разному. Вернее, мы привыкли по-своему извлекать нужную нам информацию из внешнего мира. Если она не в удобном нам виде — это раздражает. Но это наши проблемы, а не проблемы излагающего. Он, вообще-то, решает свои проблемы, а не проблемы читателей :)
Глянул. Я одну из первых статей по 4х читал — даже понравилось. А потом с очередной соскочил в самом начале. Глянул наискось — очередной шаг на пути неизвестно какой длины и неизвестно куда ведущем. Поэтому и бросил. Может быть "Ускорение4Х" меня сбивает — ощущение, что за этим заголовком очередное нерабочее бла-бла-бла (что первый же коммент в предыдущей статье и обозначил). Слишком вызывающе и амбициозно — четырехкратное ускорение. Говорит о том, что я офигенно сильно не так что-то делаю, раз можно двигаться в 4 раза быстрее. Если это правда, то это сильно бьет по самолюбию. Поэтому проще сказать, что это очередное бла-бла-бла — мы и так бежим со всех ног, чтобы только оставаться на месте, а этот парень уверяет, что можно бежать в 4 раза быстрее? Очередной балабол!
Может стоит отребрендить название методики на что-то менее уничижительное для "черепах"? Или это такое сито — только для амбициозных "черепах"? В любом случае, продолжайте рассказывать, даже если статьи буду минусить — невозможно понравиться всем, особенно на Хабре. Да вы и не должны всем нравится.
Нормально все написано — обучение на примерах. Основная мысль простая (если у тебя нет своей цели — ты реализуешь цели того, у кого она есть), но пока ее не сформулировали в явном виде, она особо сама в голове не появляется (ОК, основная мысль статьи, что для ускорения4х нужно учесть цели каждого участника команды, но я же смотрю на через призму своих интересов). Даже стало интересно, за что заминусовали предыдущую. Пойду гляну.
Вот сейчас вы меня вообще убили — из-за того, что стартапы выдают на-гора кучи мусора, страдают старушки-вкладчицы в пенсионные фонды! Куда мне перевести денег, чтобы компенсировать те 5%, что выделяют пенсионные фонды венчурным капиталистам на спекулятивные инвестиции, потерянные из-за нерадивых стартапов? Старушки не должны страдать из-за несовершенства этого мира!
Прочитал ровно до того момента, как у меня начала возникать жалость по отношению к бедным венчурным капиталистам, которым приходится копаться в кучах мусора в поисках изумрудного зёрнышка, которое принесёт им доход, что не смогут перебить другие капиталисты. Остановился, подумал — стало жаль других капиталистов, которые не смогут, если те найдут. Дальше читать не смог — жестокая статья.
Чувак, написавший статью — теоретик. В теории, оно возможно и так, а на практике сколько он чего и у кого стянул таким способом? Я писал тест на JS'е для оплаты тестовой кредитной картой покупки в тестовом магазине на тестовой учётке в braintree — я задолбался во фреймы нырять и эмулировать ввод данных на форме. И это при том, что у меня были все возможности отдебажить код на странице. Сделать обратную операцию и считать данные из формы у braintree — задача не намного более простая. А таких процессингов кредиток — не одна штука. И форматы форм у них почему-то не совпадают. В теории можно написать универсальный скрипт для всех процессингов, который будет сливать номера всех кредиток хитрым неотслеживаевым способом на засекреченный адрес в интернете. На практике можно даже написать статью, как это сделать в теории. Но сделать на практике то, что описано в этой теории, пока что не удалось никому. Включая автора статьи.
Замечательное замечание! Именно поэтому я и говорю, что за анемичной моделью будущее — по крайней мере, в web-приложениях, где я обитаю. Там изменения всё время как из рога изобилия.
Более того, мне даже кажется, что за анемичной моделью будущее. Все приложения, по большому счету, создаются для обработки данных. И представление разработчика о предметной области (модель) — это всего лишь одно из множества возможных представлений (моделей). Эту мысль замечательно со всех сторон показывает коллега maxstroy в цикле своих статей.
Мы никоим образом не сможем избежать хранения данных, но мы можем избежать связывания данных с правилами их обработки. Ничего не имею против ООП, но я также ничего не имею и против ФП. Просто, чем сложнее проектируемая предметная область, тем выше шанс, что придется один и тот же набор данных рассматривать с точки зрения разных моделей. И чем раньше отделить данные (то, что хранится в базе, грубо говоря) от обработчиков (то, что существует в программном коде), там меньше вероятность применить имеющуюся модель (объект = данные + поведение) в непредназначенных для этой модели (поведения) условиях.
Т.е., "код возврата" — это HTTP Status, в котором не предусмотрены ошибки бизнес-логики. Я правильно понимаю, что вы, как клиент, предпочитаете в случае ошибки на уровне бизнес-логики (например, "клиент с таким ИНН уже есть") получить ответ от сервера со статусом 200?
Надеюсь, что "код возврата" это не "содержимое поля 'ошибка'" ;)
Не секрет — "проверять все варианты ошибок"
Только если вам нет нужды объяснять user'у перед экраном, что же, собственно, произошло нехорошего на той стороне интернета, из-за чего самый важный и срочный запрос в его жизни не проходит. Причем в максимально удобной и понятной для него форме, чтобы он самостоятельно вырулил из сложившейся ситуации и по-возможности минимально вынес мозг call-центру. А так — да, для разговоров "server-to-server" достаточно в лог скинуть сообщение и стектрейс.
Люто возопил от одного названия — "багодельня"! Плюсанул уже только за это. А тут и еще сама идея оказалась творческой — ввести соревновательный элемент в достаточно унылый процесс разгрёба багов. ОК, пусть идея не новая, но ругать ссср'овские субботники могут только те, кто ни на каких не был. Там обычно бывает весело ;)
Напишите в комментах, как надо.
Меняйте работу в таком случае. Не спеша, плавно — но меняйте. Иначе превратитесь в крутого спеца по наложению г@вен шпателем особо тонким слоем. Как говаривал один старик: "побеждает тот волк, которого мы кормим" (с)
Мне кажется, что не так важно, кто придумал топор — добрый человек или преступник. Важнее, кто им пользуется. Пока в мире существует хотя бы один преступник или маньяк, всегда есть ненулевая вероятность попадания топора в его руки.
Извиняюсь за оффтоп, но споткнулся о текст:
и сразу в памяти всплыло:
Тем не менее, BPM считаю темой интересной и перспективной.
Статья должна была называться "Как устроиться на позицию web-разработчика ничего не понимая в web-разработке".
Ну да, если обрабатывать по 100 паролей в секунду, то при длине цифрового пароля в 8 символов на подбор уйдет не более 278 часов, а при длине пароля в 6 символов — не более 3. А если бы 6-символьный пароль содержал еще и символы в нижнем или верхнем регистре, то на брутфорс такого пароля ушло бы не более 252 дней. Это при учете, что все 252 дня сервер отвечал бы со скоростью 100 паролей в секунду.
Я даже не ожидал, что где-то еще используются чисто цифровые пароли. Повезло, однако :)
А по времени не пробовали оценить, во сколько это выльется?Дочитал до.
По стилю изложения напоминает "Легкий способ бросить курить" Алана Карра. Там целую книгу в ступе толклась одна банальная мысль: "хочешь бросить курить — не кури". Со всех возможных и невозможных сторон. У меня даже мысли про НЛП и зобирование мелькали при ее прочтении. Но я ее часа за два-три прочитал и курить бросил. Сомневаюсь, что хоть кто-то бросит курить, прочитав ту же мысль вот в этом посте. Информация до разных людей доходит по-разному. Вернее, мы привыкли по-своему извлекать нужную нам информацию из внешнего мира. Если она не в удобном нам виде — это раздражает. Но это наши проблемы, а не проблемы излагающего. Он, вообще-то, решает свои проблемы, а не проблемы читателей :)
Глянул. Я одну из первых статей по 4х читал — даже понравилось. А потом с очередной соскочил в самом начале. Глянул наискось — очередной шаг на пути неизвестно какой длины и неизвестно куда ведущем. Поэтому и бросил. Может быть "Ускорение4Х" меня сбивает — ощущение, что за этим заголовком очередное нерабочее бла-бла-бла (что первый же коммент в предыдущей статье и обозначил). Слишком вызывающе и амбициозно — четырехкратное ускорение. Говорит о том, что я офигенно сильно не так что-то делаю, раз можно двигаться в 4 раза быстрее. Если это правда, то это сильно бьет по самолюбию. Поэтому проще сказать, что это очередное бла-бла-бла — мы и так бежим со всех ног, чтобы только оставаться на месте, а этот парень уверяет, что можно бежать в 4 раза быстрее? Очередной балабол!
Может стоит отребрендить название методики на что-то менее уничижительное для "черепах"? Или это такое сито — только для амбициозных "черепах"? В любом случае, продолжайте рассказывать, даже если статьи буду минусить — невозможно понравиться всем, особенно на Хабре. Да вы и не должны всем нравится.
Нормально все написано — обучение на примерах. Основная мысль простая (если у тебя нет своей цели — ты реализуешь цели того, у кого она есть), но пока ее не сформулировали в явном виде, она особо сама в голове не появляется (ОК, основная мысль статьи, что для ускорения4х нужно учесть цели каждого участника команды, но я же смотрю на через призму своих интересов). Даже стало интересно, за что заминусовали предыдущую. Пойду гляну.
Вот сейчас вы меня вообще убили — из-за того, что стартапы выдают на-гора кучи мусора, страдают старушки-вкладчицы в пенсионные фонды! Куда мне перевести денег, чтобы компенсировать те 5%, что выделяют пенсионные фонды венчурным капиталистам на спекулятивные инвестиции, потерянные из-за нерадивых стартапов? Старушки не должны страдать из-за несовершенства этого мира!
Прочитал ровно до того момента, как у меня начала возникать жалость по отношению к бедным венчурным капиталистам, которым приходится копаться в кучах мусора в поисках изумрудного зёрнышка, которое принесёт им доход, что не смогут перебить другие капиталисты. Остановился, подумал — стало жаль других капиталистов, которые не смогут, если те найдут. Дальше читать не смог — жестокая статья.
В таком случае у вас блестящее будущее — вы сможете на раз-два надергать номеров кредиток из интернета и продать их оптом перекупщикам.
Чувак, написавший статью — теоретик. В теории, оно возможно и так, а на практике сколько он чего и у кого стянул таким способом? Я писал тест на JS'е для оплаты тестовой кредитной картой покупки в тестовом магазине на тестовой учётке в braintree — я задолбался во фреймы нырять и эмулировать ввод данных на форме. И это при том, что у меня были все возможности отдебажить код на странице. Сделать обратную операцию и считать данные из формы у braintree — задача не намного более простая. А таких процессингов кредиток — не одна штука. И форматы форм у них почему-то не совпадают. В теории можно написать универсальный скрипт для всех процессингов, который будет сливать номера всех кредиток хитрым неотслеживаевым способом на засекреченный адрес в интернете. На практике можно даже написать статью, как это сделать в теории. Но сделать на практике то, что описано в этой теории, пока что не удалось никому. Включая автора статьи.
Замечательное замечание! Именно поэтому я и говорю, что за анемичной моделью будущее — по крайней мере, в web-приложениях, где я обитаю. Там изменения всё время как из рога изобилия.
Более того, мне даже кажется, что за анемичной моделью будущее. Все приложения, по большому счету, создаются для обработки данных. И представление разработчика о предметной области (модель) — это всего лишь одно из множества возможных представлений (моделей). Эту мысль замечательно со всех сторон показывает коллега maxstroy в цикле своих статей.
Мы никоим образом не сможем избежать хранения данных, но мы можем избежать связывания данных с правилами их обработки. Ничего не имею против ООП, но я также ничего не имею и против ФП. Просто, чем сложнее проектируемая предметная область, тем выше шанс, что придется один и тот же набор данных рассматривать с точки зрения разных моделей. И чем раньше отделить данные (то, что хранится в базе, грубо говоря) от обработчиков (то, что существует в программном коде), там меньше вероятность применить имеющуюся модель (объект = данные + поведение) в непредназначенных для этой модели (поведения) условиях.