Пожалуйста добавьте ещё функцию проверки наличия топлива на колонке. Уже несколько раз напарывался на ситуацию, когда подъезжаю к колонке, оплачиваю из машины, а потом подхожу к пистолету и вижу там табличку — "топлива нет", а я уже оплатил его. Приходится идти в кассу, где мне делают возврат. Ещё несколько раз было такое, что я заезжаю на колонку из расчёта, что там сейчас заправлюсь, а потом оказывается, что там нет 95го и я еду до следующей.
PS: лично из моего опыта тип топлива первичнее колонки. Ещё подъезжая к заправке я знаю каким топливом буду заправляться, но ещё не знаю в какую колонку встану. Было бы удобнее, если бы приложение изначально показывало бы мне в каких колонках сейчас есть нужное топливо.
Если я правильно помню Европейский суд по правам человека уже не действует на территории РФ так как поправки в конституцию, которые устанавливают верховенство локальных законов перед международными уже вступили в силу.
Ну тут есть одна деталь, которая имеет сомнительный эмоциональный оттенок на мой взгляд. Если бы его первая жена так же запарилась с его здоровьем как и вторая, и соответственно узнала бы этот диагноз и прошла бы путь до конца, то именно она осталась бы с его наследством.
Да, это совершенно не то, о чём стоит думать с этической точки зрения, но эта деталь действительно поменялась бы от раннего диагноза.
Как говорит наш дизайнер — хороший дизайн не должен ощущаться или должен ощущаться никак… Пользователь не должен его замечать и фокусировать на дизайне внимание. Дизайн должен не перетягивать внимание на себя, а фокусировать внимание пользователя на том ради чего он вообще зашёл на ресурс.
Поэтому да, пользователь скорее обратит внимание на плохой дизайн, чем не хороший)
Чтоб переписать изначально рабочий сайт с нуля требуются достаточно веские основания. А в вашем случае программисты просто рукожопы.
К тому же друпальное комьюнити это какая-то отдельная секта. Переписать сайт на технологию, которую не понимают достаточно глубоко, при этом не имея достаточных оснований для этого потому что… Ну это же Друпал!=) Я бы с ним вообще не связывался. А тут весь набор некомпетентности.
Тут как говорится «с дуру можно и МПХ сломать».
Я категорически не согласен с таким предвзятым подходом, что человек пишущий код заново и экономящий на спичках называется опытным и авторитетным, а человек строящий приложение на готовых решениях — начинающим и неуверенным.
Может быть мы с вами в принципиально разных сферах работаем, я работаю в сфере веба и мобильных приложений, где ваш подход смерти подобен. Самые жуткие проекты, которые мне доставались шли одним и тем же сценарием. Был разработчик построивший приложение на велосипедах потому что они быстрые. Фреймворки не нужны, сторонние библиотеки нужно сначала прочитать и тд. И всё вроде бы неплохо работает пока не появляется она — ФИЧА!
Это закон программирования — каждое изменение кода — потенциальный крах системы. Программист, который в вашем понимании должен оцениваться как опытный и авторитетный разработчик, начинает рушить свой идеальный, быстрый, но построенный на велосипедах код пытаясь встроить в него новую фичу. Откуда взялась фича? Ну у заказчика поменялась бизнес-логика, что-то изменилось в бизнес-процессе да мало ли! Это не вопрос программирования.
И вот код программиста уже выглядит не так хорошо, а тут появляется ещё фича, потому что новые изменения являются новыми и устаканиваются по ходу дела. Появляются новые баги — и всё это потенциальные крахи системы. И тут велосипеды дают о себе знать. И вот ваш изначально быстрый код крашится и валится, но при этом ещё и представляет из себя нераспутываемую лапшу. Заказчик терпит повышения бюджета месяцы, годы. Но потом наступает момент, когда проект просто умирает. Не из-за заказчика, а из-за программиста велосипедофила. И вот заказчик меняет команду разработчиков и потом нам приходится это разгребать.
Проект, где не появляется новых фичь это какая-то экзотика, я даже не припомню такого… Такое может быть только на проекте, который либо очень узконишевой, либо которым мало кто пользуется.
Ну вот извините, но практически весь ваш комментарий — попытка разобраться, откуда исходят требования. Но речь-то не про источник требований, а как развиваться кодовой базе в условиях постоянно появляющихся хотелок и требований. Источники могут быть разными, часто разработчики с ними не согласны, иногда не согласны с ними и пользователи, но заказчик неумолим. Сути это не меняет — есть требование, которое нужно удовлетворить, за него деньги платят. Если каждый разработчик будет критиковать механизмы монетизации приложения, то это прямое нарушение разделения обязанностей на проекте. У меня были заказчики, которые очевидно стартовали проекты, которые по моему мнению не окупятся, мы говорили заказчику, но он был неумолим и проекты не окупались. Но точно так же были и проекты, где мы предупреждали заказчика об аналогичных проблемах и его фичи стреляли и приносили деньги. Каждый смотрит со своего ракурса и не всегда то, что видит разработчик соответствует тому, что видит заказчик. Пусть каждый решает свои задачи.
Постоянно появляющиеся требования разработчиками должны восприниматься как данность, как закон природы, к которому они должны быть готовы.
ТС же причитает, что разработчики не экономят ресурсы железа. Это плата за гибкость к изменениям. Тут применим эволюционный процесс и выше указали в комментариях на это — были разные подходы и разработчики, но самым жизнеспособным оказался подход — главное писать гибкий код, дружелюбный к новым требованиям, чем код, скурпулёзно считающий такты процессора. К сожалению это очень часто взаимоисключающие направления.
Ну появление новых требований диктуется не разработчиком, а заказчиком и пользователями. Зачем делать редизайн? Ну может потому что у конкурентов дизайн адаптивнее(новые устройства появляются регулярно и ваш старый сайт на новом экране может выглядеть не так хорошо), красивее и современнее.
Плюс заказчик просит фичи потому что… Ну это уже от проекта зависит. Требования пользователей год назад, когда ваше приложение только появлялось и было в новинку и требования сейчас, когда они его распробовали будут серьёзно разниться. Да, господи, просто посмотрите как изменился контакт. Если сейчас выкатить его в старой форме приблизительно лет десяти назад со стеной, отсутствием аудиозаписей, только одной аватаркой и тд и тп, то этим сайтом просто никто не будет пользоваться.
Ваш продукт должен быть дружелюбен к изменениям потому что они наступят ГАРАНТИРОВАННО. Расчитывать при разработке на приложение, которое будет оптимизировано один раз и не будет модифицироваться, значит изначально писать либо крайне узконишевой продукт, либо мёртворождённый.
Почему потребовалось переписывать калькулятор? Не ко мне вопрос, калькулятор некоммерческий проект, денег не приносит и монетизации не имеет. Тут скорее всего потому что просто кому-то захотелось, но сделать так, чтоб бюджет сильно не тратить и потому сделали всё халтурно. У меня нет полного ответа в частности про калькулятор.
Ну тут проблема понятна — пока отрабатывает предыдущая анимация кнопка знака не срабатывает и получается каша. По идее просто халтурно сделанное приложение и проблема отношения к тестированию софта, не ожидал от Эппл такого.
Но к теме разговора это никакого отношения не имеет. Проблема-то не в том, что телефон НЕ УСПЕВАЕТ отработать калькуляцию и даже не в том, что установочник калькулятора весит много, хотя мог бы весить всего ничего и даже не в том, сколько ресурсов кушает данное приложение(а именно эти проблемы заявлены в статье), а в том, что разработчики халтурно подошли к реализации и тестированию своего софта
Ну про глючность это как раз аргумент в пользу того, что лучше переиспользовать готовые решения, чем писать каждый раз оптимизированный низкоуровневый велосипед.
Если дизайн надо заново осваивать, то это большой вопрос к дизайнеру проекта и к теме разговора отношения не имеет.
Новый ненужный функционал? Так говорите как будто его программисты придумывают:)
На счёт тормозов. Пользователь не хочет приложение, которое работает максимально быстро. Это никому не нужно. Пользователь хочет приложение выполняющее свою функцию в приемлемое количество времени. Разница между 0.05 с и 0.5 с для рядового пользователя настолько несущественна, что её никто не заметит. А это разница в производительности на порядок! А вот то, что ради этих 0.45с вы угробили почти весь бюджет заказчика, при этом писали исключительно свой код не используя фреймворки потому что они тянут лишние зависимости и занимают место. И как следствие, на разрежение лапши в коде тратится неприлично много времени, что приводит к появлению багов.
Итог приложение открывается на 0.45 с быстрее, но вот при нажатии на нужную пользователю кнопочку крашится. Зато быстро:)
Каждому решению своё место. Там где производительность является ключевым фактором, там приложения оптимизируются на минимальное время отклика и открытия, но в большей части софта это не нужно.
Когда тормоза в приложении начинают мешать им пользоваться, тогда приложение оптимизируется, но во-первых все современные решения позволяют оптимизировать приложение до того самого приемлемого уровня, а во-вторых определяющим фактором и узким местом становится уже не железо, а пользователь, который начиная с определенной задержки перестаёт чувствовать разницу и траты бюджета на дальнейшую оптимизацию становятся неоправданными.
Я в таких случаях привожу аргумент «Твоё приложение может быть бесконечно оптимизированным, но какой в этом толк, если оно не работает?». А почему оно может не работать? Ну например потому что заказчик постоянно хочет фичи и меняет требования, а конкуренты поджимают. Ни один продукт не живёт в состоянии стазиса, он всегда развивается и именно развитие продукта является тем самым испытанием, которое диктует приоритет на том, чтоб брать стабильные, готовые решения даже если они медленнее, чем каждый раз писать своё и быстрое решение. Пользователь конечно заметит, что приложение грузится чуть медленнее, но когда вы начнёте путаться в тоннах самописного кода и будете допускать баги(а при таком подходе вы неизбежно к этому прийдёте), то это намного более критичная ситуация.
Windows 95 работало быстрее? Хм… Ну давайте время отклика калькулятора посчитаем, но сколько приложений вы на нём запустите? А пользователи ждут, толпа жаждет хлеба и зрелищ! И когда вы начнёте удовлетворять потребности этой толпы вдруг окажется, что придётся писать менее оптимизированный, но более гибкий код.
Пост как по мне, так борьба с ветряными мельницами «Этот мир живёт неправильными приоритетами!», но десятилетия разработки ПО привели именно к этой расстановке приоритетов не просто так
Извиняюсь, за поздний ответ.
Приведённые в статье тесты не являются unit-тестами с изначальном смысле этого слова. Это скорее Интеграционные тесты API.
Если вы тестируете методы и классы, а не запросы, то сбор документации по использованию API становится немножко нетривиальной задачей. В данном случае наверное да, этот метод не подойдёт.
Да, в документацию пойдёт ровно то, что тестируется. Если на что-то не написано теста, то система на это не рассчитана.
Ну не то, чтобы не устраивало, но два года назад, когда этот проект стартанул выбор пал на Swagger. Плагин всё это время жил как внутренняя корпоративная тулза, поэтому большой потребности добавлять поддержку Blueprint не появлялось.
Насколько я могу нагуглить в принципе реализовать поддержку Blueprint формата вполне можно.
Пожалуйста добавьте ещё функцию проверки наличия топлива на колонке. Уже несколько раз напарывался на ситуацию, когда подъезжаю к колонке, оплачиваю из машины, а потом подхожу к пистолету и вижу там табличку — "топлива нет", а я уже оплатил его. Приходится идти в кассу, где мне делают возврат. Ещё несколько раз было такое, что я заезжаю на колонку из расчёта, что там сейчас заправлюсь, а потом оказывается, что там нет 95го и я еду до следующей.
PS: лично из моего опыта тип топлива первичнее колонки. Ещё подъезжая к заправке я знаю каким топливом буду заправляться, но ещё не знаю в какую колонку встану. Было бы удобнее, если бы приложение изначально показывало бы мне в каких колонках сейчас есть нужное топливо.
Да, это совершенно не то, о чём стоит думать с этической точки зрения, но эта деталь действительно поменялась бы от раннего диагноза.
Поэтому да, пользователь скорее обратит внимание на плохой дизайн, чем не хороший)
А кто сказал, что всё дети следующие после первого являются его детьми?
К тому же друпальное комьюнити это какая-то отдельная секта. Переписать сайт на технологию, которую не понимают достаточно глубоко, при этом не имея достаточных оснований для этого потому что… Ну это же Друпал!=) Я бы с ним вообще не связывался. А тут весь набор некомпетентности.
Тут как говорится «с дуру можно и МПХ сломать».
Может быть мы с вами в принципиально разных сферах работаем, я работаю в сфере веба и мобильных приложений, где ваш подход смерти подобен. Самые жуткие проекты, которые мне доставались шли одним и тем же сценарием. Был разработчик построивший приложение на велосипедах потому что они быстрые. Фреймворки не нужны, сторонние библиотеки нужно сначала прочитать и тд. И всё вроде бы неплохо работает пока не появляется она — ФИЧА!
Это закон программирования — каждое изменение кода — потенциальный крах системы. Программист, который в вашем понимании должен оцениваться как опытный и авторитетный разработчик, начинает рушить свой идеальный, быстрый, но построенный на велосипедах код пытаясь встроить в него новую фичу. Откуда взялась фича? Ну у заказчика поменялась бизнес-логика, что-то изменилось в бизнес-процессе да мало ли! Это не вопрос программирования.
И вот код программиста уже выглядит не так хорошо, а тут появляется ещё фича, потому что новые изменения являются новыми и устаканиваются по ходу дела. Появляются новые баги — и всё это потенциальные крахи системы. И тут велосипеды дают о себе знать. И вот ваш изначально быстрый код крашится и валится, но при этом ещё и представляет из себя нераспутываемую лапшу. Заказчик терпит повышения бюджета месяцы, годы. Но потом наступает момент, когда проект просто умирает. Не из-за заказчика, а из-за программиста велосипедофила. И вот заказчик меняет команду разработчиков и потом нам приходится это разгребать.
Проект, где не появляется новых фичь это какая-то экзотика, я даже не припомню такого… Такое может быть только на проекте, который либо очень узконишевой, либо которым мало кто пользуется.
Постоянно появляющиеся требования разработчиками должны восприниматься как данность, как закон природы, к которому они должны быть готовы.
ТС же причитает, что разработчики не экономят ресурсы железа. Это плата за гибкость к изменениям. Тут применим эволюционный процесс и выше указали в комментариях на это — были разные подходы и разработчики, но самым жизнеспособным оказался подход — главное писать гибкий код, дружелюбный к новым требованиям, чем код, скурпулёзно считающий такты процессора. К сожалению это очень часто взаимоисключающие направления.
Плюс заказчик просит фичи потому что… Ну это уже от проекта зависит. Требования пользователей год назад, когда ваше приложение только появлялось и было в новинку и требования сейчас, когда они его распробовали будут серьёзно разниться. Да, господи, просто посмотрите как изменился контакт. Если сейчас выкатить его в старой форме приблизительно лет десяти назад со стеной, отсутствием аудиозаписей, только одной аватаркой и тд и тп, то этим сайтом просто никто не будет пользоваться.
Ваш продукт должен быть дружелюбен к изменениям потому что они наступят ГАРАНТИРОВАННО. Расчитывать при разработке на приложение, которое будет оптимизировано один раз и не будет модифицироваться, значит изначально писать либо крайне узконишевой продукт, либо мёртворождённый.
Почему потребовалось переписывать калькулятор? Не ко мне вопрос, калькулятор некоммерческий проект, денег не приносит и монетизации не имеет. Тут скорее всего потому что просто кому-то захотелось, но сделать так, чтоб бюджет сильно не тратить и потому сделали всё халтурно. У меня нет полного ответа в частности про калькулятор.
Но к теме разговора это никакого отношения не имеет. Проблема-то не в том, что телефон НЕ УСПЕВАЕТ отработать калькуляцию и даже не в том, что установочник калькулятора весит много, хотя мог бы весить всего ничего и даже не в том, сколько ресурсов кушает данное приложение(а именно эти проблемы заявлены в статье), а в том, что разработчики халтурно подошли к реализации и тестированию своего софта
Ну про глючность это как раз аргумент в пользу того, что лучше переиспользовать готовые решения, чем писать каждый раз оптимизированный низкоуровневый велосипед.
Если дизайн надо заново осваивать, то это большой вопрос к дизайнеру проекта и к теме разговора отношения не имеет.
Новый ненужный функционал? Так говорите как будто его программисты придумывают:)
На счёт тормозов. Пользователь не хочет приложение, которое работает максимально быстро. Это никому не нужно. Пользователь хочет приложение выполняющее свою функцию в приемлемое количество времени. Разница между 0.05 с и 0.5 с для рядового пользователя настолько несущественна, что её никто не заметит. А это разница в производительности на порядок! А вот то, что ради этих 0.45с вы угробили почти весь бюджет заказчика, при этом писали исключительно свой код не используя фреймворки потому что они тянут лишние зависимости и занимают место. И как следствие, на разрежение лапши в коде тратится неприлично много времени, что приводит к появлению багов.
Итог приложение открывается на 0.45 с быстрее, но вот при нажатии на нужную пользователю кнопочку крашится. Зато быстро:)
Каждому решению своё место. Там где производительность является ключевым фактором, там приложения оптимизируются на минимальное время отклика и открытия, но в большей части софта это не нужно.
Когда тормоза в приложении начинают мешать им пользоваться, тогда приложение оптимизируется, но во-первых все современные решения позволяют оптимизировать приложение до того самого приемлемого уровня, а во-вторых определяющим фактором и узким местом становится уже не железо, а пользователь, который начиная с определенной задержки перестаёт чувствовать разницу и траты бюджета на дальнейшую оптимизацию становятся неоправданными.
Windows 95 работало быстрее? Хм… Ну давайте время отклика калькулятора посчитаем, но сколько приложений вы на нём запустите? А пользователи ждут, толпа жаждет хлеба и зрелищ! И когда вы начнёте удовлетворять потребности этой толпы вдруг окажется, что придётся писать менее оптимизированный, но более гибкий код.
Пост как по мне, так борьба с ветряными мельницами «Этот мир живёт неправильными приоритетами!», но десятилетия разработки ПО привели именно к этой расстановке приоритетов не просто так
Приведённые в статье тесты не являются unit-тестами с изначальном смысле этого слова. Это скорее Интеграционные тесты API.
Если вы тестируете методы и классы, а не запросы, то сбор документации по использованию API становится немножко нетривиальной задачей. В данном случае наверное да, этот метод не подойдёт.
Да, в документацию пойдёт ровно то, что тестируется. Если на что-то не написано теста, то система на это не рассчитана.
Насколько я могу нагуглить в принципе реализовать поддержку Blueprint формата вполне можно.