All streams
Search
Write a publication
Pull to refresh
8
0

QA Engineer

Send message
Задав в поиске на хабре «QSettings» и нашлось больше 5 тем не включая вашу. В чем новизна? Что есть у Вас чего нет в официальной документации?
В прочем как всегда формулировка «это воспрепятствует расследованию преступления» это все равно что «но это может не помешать при дополнительных финансовых затратах»
Я человек итеративный и у меня с первого раза не особо получается написать удачно. Сначала вроде как хорошо, а потом всегда видишь косяки и понимаешь что вопрос можно по разному понять, а поправить уже никак. Вернее сам вопрос можно, а вот варианты ответа на более точные формулировки нет (
Сегодня на практике понял насколько мне сильно бесит интерфейс хабра по части редактирования опросов.
Нет возможности:
* Добавить новый вариант ответа;
* Изменить существующий вариант ответа;
* Удалить существующий вариант ответа;
* Переключить с чекбоксов на радиобатоны;
* Добавить новые теги;

По крайней мере их я не нашел.

Еще вопрос, что делать в случае если я решил убрать опрос в черновики и мне он больше уже не нужен? Где заветная кнопочка «удалить опрос»?
Значит «тем что надо» является «знание». Отсюда опять же требования: «Что я хочу узнать?» мы же не можем изучать все на свете, мы должны выставить достижимую цель, благодаря которой мы поймем «теперь мы изучили и разобрались».
Мысль номер один:
В том-то и причина, что тесты заставляют взглянуть на причину поломки! Вспомните по какой причине мы, разработчики, отдаем тестировать продукт тестерам? Отдаем мы их потому что мы можем не заметить, а все потому что нам многое кажется очевидным и мы часто восклицаем «Тут багов не будет». Нам нужен взгляд со стороны на наше творение.
Так и с тестированием. Мы можем лелеять и сколь угодно долго утверждать «наши тесты выявляют все возможные баги» и даже не догадываться о каких-либо нюансах.
Если мы переместим тесты на поломанный жесткий, мы можем увидеть поломанный тест совсем не по тем причинам по которым мы ожидали планируя тест. Это еще один способ взглянуть на свой продукт совсем под другим углом зрения при тестировании.

Мысль номер два:
Не надо дожидаться отработки всего набора тестов. Надо поставить каждому тесту рейтинг или приоритет, а затем выставить их выполнение согласно рейтингу или приоритету. Возьмем случай тестирования класса строка и другого класса содержащего операции со строкой. Вопрос: Зачем ждать когда выполнятся тесты по строковым операциям, если класс строка имеет багу и тест это УЖЕ показал?
А вы действительно настолько «везучий» что у Вас все 100 кейсов из 100 возможных завалятся по причине жесткого? На практике если отработали 80% кейсов уже скажет о многом разработчику.
Более того плохо-работающее железо может выявить те случаи о которых разработчик даже не догадывался, но на которые его продукт должен адекватно реагировать!

К тому же тестирование это не ед. сфера применения жесткого. Его можно применить для временного хранения данных, к примеру меж сотрудниками организации. Развивайте фантазию, в любой организации, тем более в ИТ-сфере, дыр, которые требуют чтобы их закрыли очень много и на все нужно финансирование.

Надо всегда плясать от вопроса: «А что конкретно я хочу получить?», если у Вас требование: «100 процентная сохранность данных» тут даже думать не надо. Более-того даже если у вас отличный жесткий, то даже в этом случае на это не следует надеяться и следует подумать о бэкапе.
И что с того? Это бизнес-данные, потеря которых аукается по бизнесу? Нет же! Подумаешь ежедневный тест-набор не прошел, пройдет завтра. Это все же лучше чем сегодня покупать очередной за 2.5. Зачем тратить там где можно не тратить?
Зачем так не оптимально? Есть еще возможность юзать дальше, где нет требования по сохранности данных. К примеру для тест-машин, которые создают тест-файлы, чтото с ними делают и выдают результат тестирования. То что может быть профакапится тест-файл это не критично для бизнеса.
У Суворова есть офигенные слова: «Не знаешь что делать делай шаг вперед». Они очень часто меня спасают меня от перфекционизма. Именно они заставляют меня начать любым более-менее правильным способом известный в момент когда уже слишком долго сижу над проектированием и думанием чего-нить
Пользоваться чем-либо надо только тогда, когда четко понял, что это что тебе надо. А это понимание диктуется ТЗ, Проектом, Требованиями, Бюджетом и многими многими другими факторами. Если у Вас требование написать быстро, пусть даже в ущерб скорости выполнения не думаю, что вы сядете за реализацию чего-либо.
Чаще задавайте себе вопрос перед действием: «Почему это надо делать?».
>>На тот момент я не тянул
Что вы вкладываете в эти слова? Не знание?

>>Зато он header-only
Буст солидной частью тоже в хидер-онли
Суть вашего поста сводится к «Читайте МакКонела» ) У него отлично написано про то что вы хотели выразить в своем посте словами «Есть два типа программирования с помощью языка и на языке».
А можете порыться и описать что-нить для локализации. О чем это я вы можете понять почитав немного о boost.locale или GNU Gettext.
Какие ваши критерии по выбору библиотеки логирования?
Я отказался от TCLAP в пользу boost.program_options и не жалею! )
Сами эти POCO не во всем придерживаются того что придумали. Соглассно их кодинг-стайлу: строчка из poco-1.4.3p1\Net\src\NameValueCollection.cpp:
const std::string& NameValueCollection::get(const std::string& name, const std::string& defaultValue) const
{

должна быть совершенно другой:
const std::string& NameValueCollection::get(
    const std::string& name,
    const std::string& defaultValue) const
{


Странно. Вроде дядьки умные, а почему-то не юзают то что сами и разрабатывают!
Боже упаси юзать log4cpp, куда лучше boost.log или glog
>>уже давно досовский стаб можно было выкинуть, оставив только MZ
Все эти «некрасивости» никак не мешают обычной и штатной работоспособности приложений, а если учесть что обычный стаб даже 200 байт не весит и вспомнив размеры современных жестких, то как-то глупо париться по этому поводу.

>>А ещё лучше. чтобы он предлагал скачать нужную версию .NET :)
+1, заводи задачу в Мелкософт-баг-трекере!
>>почему в Microsoft не сделали подобную заглушку для .NET приложений.
Почитайте внимательней мат.часть на предмет развития и появления .NET. Эта технология развилась благодаря COM-технологии. А все эти Ко-Сервера, Ко-Клиенты ничто иное как исполнимые файлы прописанные в реестре.

>>И как пользователю догадаться, что нужно установить .NET framework?
Это должен разработчик заботится. При написании инсталяционного скрипта для продукта он должен обнаружить нужное и выдать сообщение чего не хватает.

Information

Rating
Does not participate
Location
Железнодорожный (Московск.), Москва и Московская обл., Россия
Date of birth
Registered
Activity