Подсказывать может только субъективное предубеждение… Сложно математически доказать, что выборка из 3 млн. сайтов (StatCounter) менее репрезентативна, чем выборка из 1 млн. сайтов (LiveInternet).
К тому же, на большинство новых сайтов вообще ставят Google Analytics или Яндекс.Метрика, а данных по этим сайтам нет ни в одной публичной статистике.
Нет, StatCounter в отличии от многих агрегаторов, ведёт отдельную статистику по мобильным браузерам, что правильно, на мой взгляд.
Альтернативные браузеры — это, например, Konqueror, Epiphany, Galeon, Camino, etc. Несомненный плюс состоит в том, что большинство этих браузеров основано на Gecko и/или WebKit, так что особых проблем с рендерингом у них обычно нет. Хотя есть и исключения, типа Links или Dillo.
Это не соответсвует действительности по данным Яндекса? :-)
А если серьёзно, то нам не дано судить, что соответствует действительности, а что нет. Мы можем обсуждать только данные по определённым выборкам, определить же какая из выборок наиболее соответствует генеральной совокупности нереально в данном случае. Поэтому обращайте больше внимания на тенденции, а не на конкретные цифры.
Ничего. Обычная коррекция к росту, тем более что с начала сентября американские рынки выросли примерно на 20%, теперь настало время сбросить перекупленность.
> А есть расширения для приема всяких вебманей и прочих сбербанков?
Для самой свежей версии пока нет, но в принципе ничего сложного при необходимости… Тем более, что для предыдущих версий было расширение для приёма платежей через РобоКассу.
Что самое интересное, всё как раз с точностью до наоборот:
RoR превосходно подходит для создания сложных веб-приложений, а для создания простеньких сайтов подойдут скорее php-шные CMS'ки.
Необязательно, есть же такие слова, как «жюри», «каракули», «глясе», «пенсне» и др., которые прижились и без суффиксов.
Хотя всё равно, слова то не русские, а заимствованные.
И «юзабилити» и «эргономика» — оба заимствованные слова и в этом плане ничем кроме базового языка не отличаются.
Просто «грекофилы» теперь уже противостоят не «латинству», а «англицизму», не первый век уж буйствуют :-)
Доверить проектирование GUI тестеру — всё равно что доверить обезьяне управлять танком и не важно какой процент от кода приходится на долю UI, на его долю в любом случае приходится 100% взаимодействия с пользователем.
Научитесь уже проигрывать в споре достойно. Ваша точка зрения уже давно признана в корне ошибочной. Обратитесь уже наконец к мировому опыту IxDA, если ума хватит.
> у программиста, который зажат в рамках одного модуля
Это уж слишком проектнозависимо, мне не встречались проекты, в которых программисты работали только над одним модулем, как будто зашоренные.
Это просто плохой пример организации работы программистов.
> Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи
Ну не то чтобы «прекрасно знают», но как минимум догадываются при каких обстоятельствах посыпятся ошибки. Попробуй попроси у программиста, не занятого в проекте, прочитав спецификацию, назвать 20 мест, где могут возникнуть проблемы. Особого труда это для него составить не должно, при этом в 12-15 из 20 названных мест, ты потом реально найдёшь баги. А всё потому, что каких-то уникальных багов на практике встречается крайне мало и даже не в каждом проекте.
> бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях
Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
> плох тот тестировщик, который не умеет программировать ;)
Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
> почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат?
Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Очень похоже, что Вы описываете должность, совмещающую обязанности инженера по качеству, больше известны как QA, и бизнес-аналитика (Business Analyst). Только это аж 2 другие профессии. Тестировщики (Software Test Engineer) не должны заниматься тем, что вы выше указали, это не входит в их должностные обязанности.
Кстати, мне довелось работать в компании, где были представители всех 3 вышеназванных профессий, вот там бюрократия то была… хотя сейчас не об этом. Они кстати все отличались и по уровню знаний и по уровню зарплат.
Поэтому мне в голову не приходило, что вы под тестировщиками имеете в виду людей, которые по вашему описанию аж на 3 ставки (SwT, QA, BA) работают. Я всё-таки считаю такое именование абсолютно некорректным.
работа программиста заключается в том, чтобы написать код который будет решать поставленную задачу (обычно четко понятную) и выполняться в рамках каких-то ограничений (тоже обычно оговоренных).
Далековато от истины, «чётко» известно что надо сделать, только сложность в том, что надо придумать как это сделать.
Т.е. для тестировщика единственной чётко поставленной задача будет «найти все несоответствия спецификации и здравому смыслу». А у программистов подобных «чётко» поставленных задач по несколько штук в день.
Задача тестировщика, мало того, что проверить, что код работает именно так как планировалось
ну это совсем тривиальная часть. согласны?
но и еще придумать случаи в которых программа может работать не правильно, и не только придумать а и заставить программу повести себя не правильно.
А вот тут у программистов преимущество, они прекрасно знают все эти случаи и уж тем более знают, что надо ввести чтобы получить ошибку, просто никогда не будут гонять по этим сценариям свою программу, т.к. это неосновной сценарий и т.к. для этого есть тестировщики.
Ничего нетривиального для программистов в этой части работы тестировщиков тоже нет.
В добаков не плохо еще и убедиться, что программа верно обрабатывает ошибки и исключительные ситуации.
Ну по найденному сценарию проверить реакцию программы — это совсем тривиально.
я никогда в жизни не видел идеальных спецификаций.
Идеальная, не идеальная, а формальную проверку на соответствие спецификации тестировщики обязаны делать для каждого минорного релиза.
Для примера, вот вам пара вакансий.
А ничего, что QA Engineer и Software Test Engineer (тестировщик) — это разные профессии?
Как обычно, вся дискуссия перестала иметь смысл, раз вы соединили эти 2 профессии в нечто единое и непонятное.
Вам понятие user experience testing ничего не говорит?
Говорит, это когда писали, писали программу, уже почти дописали и вдруг как вспомнили «А ей же люди будут пользоваться», «рюшечек» на самые уродливые места понавесили и поставили штамп «User Friendly».
Никто на этапе тестирования не даст менять концепцию UI, т.к. это будет стоить в 2 раза больше, чем то что уже есть.
А вот Вам понятие Interaction Design явно не знакомо. Советую ознакомиться.
часто GUI появляется намного позже, чем функциональность.
А кто спорит, именно из-за такого подхода большинство программ имеют уродский GUI. Всем известна гонка функциональных возможностей, которыми пользуются от силы 0.1% пользователей, зато остальных 99.9% эти излишние функции только в тоску вгоняют.
Только при таком херовом подходе к разработке, никакое тестирование уже не поможет.
К тому же, на большинство новых сайтов вообще ставят Google Analytics или Яндекс.Метрика, а данных по этим сайтам нет ни в одной публичной статистике.
Альтернативные браузеры — это, например, Konqueror, Epiphany, Galeon, Camino, etc. Несомненный плюс состоит в том, что большинство этих браузеров основано на Gecko и/или WebKit, так что особых проблем с рендерингом у них обычно нет. Хотя есть и исключения, типа Links или Dillo.
А если серьёзно, то нам не дано судить, что соответствует действительности, а что нет. Мы можем обсуждать только данные по определённым выборкам, определить же какая из выборок наиболее соответствует генеральной совокупности нереально в данном случае. Поэтому обращайте больше внимания на тенденции, а не на конкретные цифры.
Для самой свежей версии пока нет, но в принципе ничего сложного при необходимости… Тем более, что для предыдущих версий было расширение для приёма платежей через РобоКассу.
RoR превосходно подходит для создания сложных веб-приложений, а для создания простеньких сайтов подойдут скорее php-шные CMS'ки.
Хотя всё равно, слова то не русские, а заимствованные.
И «юзабилити» и «эргономика» — оба заимствованные слова и в этом плане ничем кроме базового языка не отличаются.
Просто «грекофилы» теперь уже противостоят не «латинству», а «англицизму», не первый век уж буйствуют :-)
Вам кажется это мало? В городских розетках максимальный ток обычно ограничивают до 6 А, а на большем уже предохранители должны срабатывать.
Для ярых ненавистников магии существует Python и Django.
Научитесь уже проигрывать в споре достойно. Ваша точка зрения уже давно признана в корне ошибочной. Обратитесь уже наконец к мировому опыту IxDA, если ума хватит.
Это уж слишком проектнозависимо, мне не встречались проекты, в которых программисты работали только над одним модулем, как будто зашоренные.
Это просто плохой пример организации работы программистов.
> Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи
Ну не то чтобы «прекрасно знают», но как минимум догадываются при каких обстоятельствах посыпятся ошибки. Попробуй попроси у программиста, не занятого в проекте, прочитав спецификацию, назвать 20 мест, где могут возникнуть проблемы. Особого труда это для него составить не должно, при этом в 12-15 из 20 названных мест, ты потом реально найдёшь баги. А всё потому, что каких-то уникальных багов на практике встречается крайне мало и даже не в каждом проекте.
> бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях
Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
> плох тот тестировщик, который не умеет программировать ;)
Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
> почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат?
Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Кстати, мне довелось работать в компании, где были представители всех 3 вышеназванных профессий, вот там бюрократия то была… хотя сейчас не об этом. Они кстати все отличались и по уровню знаний и по уровню зарплат.
Поэтому мне в голову не приходило, что вы под тестировщиками имеете в виду людей, которые по вашему описанию аж на 3 ставки (SwT, QA, BA) работают. Я всё-таки считаю такое именование абсолютно некорректным.
Далековато от истины, «чётко» известно что надо сделать, только сложность в том, что надо придумать как это сделать.
Т.е. для тестировщика единственной чётко поставленной задача будет «найти все несоответствия спецификации и здравому смыслу». А у программистов подобных «чётко» поставленных задач по несколько штук в день.
ну это совсем тривиальная часть. согласны?
А вот тут у программистов преимущество, они прекрасно знают все эти случаи и уж тем более знают, что надо ввести чтобы получить ошибку, просто никогда не будут гонять по этим сценариям свою программу, т.к. это неосновной сценарий и т.к. для этого есть тестировщики.
Ничего нетривиального для программистов в этой части работы тестировщиков тоже нет.
Ну по найденному сценарию проверить реакцию программы — это совсем тривиально.
Идеальная, не идеальная, а формальную проверку на соответствие спецификации тестировщики обязаны делать для каждого минорного релиза.
А ничего, что QA Engineer и Software Test Engineer (тестировщик) — это разные профессии?
Как обычно, вся дискуссия перестала иметь смысл, раз вы соединили эти 2 профессии в нечто единое и непонятное.
Говорит, это когда писали, писали программу, уже почти дописали и вдруг как вспомнили «А ей же люди будут пользоваться», «рюшечек» на самые уродливые места понавесили и поставили штамп «User Friendly».
Никто на этапе тестирования не даст менять концепцию UI, т.к. это будет стоить в 2 раза больше, чем то что уже есть.
А вот Вам понятие Interaction Design явно не знакомо. Советую ознакомиться.
А кто спорит, именно из-за такого подхода большинство программ имеют уродский GUI. Всем известна гонка функциональных возможностей, которыми пользуются от силы 0.1% пользователей, зато остальных 99.9% эти излишние функции только в тоску вгоняют.
Только при таком херовом подходе к разработке, никакое тестирование уже не поможет.