Вот что прикольно: цифры в новости рассчитаны на хомячков, которым только выше скорость чтения и подавай, а что с ней делать они не знают. Почему-то производителям (тому же Samsung) проще показать, что скорость SSD в 2-3-4 раза превышает скорость HDD, чем долго и нудно объяснять, что основной выигрыш SSD у HDD из-за скорости доступа (seek), которая у SSD выше как минимум на порядок
А можно еще шире взять: это все одна профессия — IT-шник. Просто кому-то что-то ближе, в чем-то больше опыта — тем и занимается.
Если серьезно, тестировщик, QA, кодер, архитектор, менеджер — это всего-лишь проектные роли. Другое дело, что не все взаимозаменяемые. Да, QA может работать какое-то время простым тестировщиком, но во-первых его ручная работа будет очень демотивировать, во-вторых, это просто неэффективное использование рессурса. Да и разница между тестировщиком и QA очень большая, QA — это не просто тестировщик с большим опытом, тут нужен опыт управления, опыт разработки.
Да, бывают случаи в реальном мире, когда просто делят на «software developer» и «специалист по качеству», но это чаще в мелких проектах на три калеки, там каждый на все руки мастер и уровень ответственности невысокий. Представьте проект, в котором постоянно присутствует несколько десятков разработчиков, и столько же тестировщиков. Если каждый разработчик (будучи даже сеньером, но выполняющий на проекте строго определенную роль кодера) полезет в архитектуру приложения — вся эта шобла (извините, команда), никогда никуда не приедет. С QA то же самое. Кстати, QA в данном случае будет скорее все равно один, причем не факт, что будет закреплен за этим проектом. И для эффективности его работы иерархия в компании будет выстроена таким образом, чтобы он был не в подчинении никого из команды, включая менеджера, QA — это трезвый взгляд со стороны, а не изнутри песочницы.
Пожалуй, немного больше объясню: разница между «тестировщиком» и «QA» примерно такая же, как между «кодером» и «архитектором». Вы же не станете жаловаться, что кодер Вася не проявляет инициативу и не лезет менять архитектуру приложения, напротив, скажете «слава богу, не нужно ему туда соваться». Вот так с тестировщиками, не их задача думать о качестве в проекте, их задача — только контролировать его (качество) используя заранее известные критерии.
Я чуть-чуть побуду занудой и напомню, что решение о том, чтобы посадить в пару разработчика и тестировщика — это таки задача QA. И да, тестировщик и QA — это совсем не одно и то же. Если тестировщик всю жизнь занимается ручными тестами — прекрасно, это его работа, значит не нашлось никого, кто позаботился бы о QA в его проектах и не выделил области для автоматизации.
А вот от документации уходить никак нельзя, опять же, если есть QA. А если QA отсутствует, то разработчики с тестировщиками как-угодно могут договориться между собой, хоть левой ногой код писать и в телефонном режиме его «тестировать»…
Ok, не совсем точно выразился (по поводу «более...»). Я о том, что любые тесты выполняются согласно неким заданным критериям: что должно быть, чего быть не должно. Так вот эти критерии в разных проектах могут очень сильно отличаться. В одном проекте проблема №1 сразу сделает билд «красным» (тогда как проблема №2 вообще не будет протестирована), во втором проекте — с точностью до наоборот.
Описываемая область находится на границе знаний между разработчиками и тестировщиками. Если б было ясно сказано, что зеленая/красная лампочка — она только для разработчиков, тогда согласен, команда разработчиков уверена какой продукт отдает. Но поскольку тут упоминался еще и менеджер, который обычно гораздо менее технически подкован чем разработчики и тестировщики, но при этом гораздо лучше знает, чего от продукта ждет заказчик, зеленая/красная лампочка ориентированная и на него тоже, должна нести несколько другой смысл.
По поводу «зеленый билд — хорошо, красный — плохо» — не хватает уточнения: в рамках написанных тестов/в рамках поставленной задачи.
Вот пример специально из ручного тестирования, несколько преувеличенный, но, надеюсь, моя мысль будет понятна. Возьмем две проблемы в приложении, которые мы регрессим:
1. приложение падает при старте (скажем, на определенном железе/системе)
2. в одном из основных диалогов приложения расстояния между тремя основными кнопками визуально неодинаковые, разница — 2-3 пикселя
Теперь зададим вопросы по обеим проблемам: проблема серьезная? Отсутствие этой проблемы в билде сделает его «более зеленым»? Присутствие — сделает «более красным»?
Чаще ответ будет: №1 — серьезная, №2 — косметика, можно пропустить. Однако зависит от условий: может система/железо, на которых возникает проблема №1, вовсе не является target системой для приложения, значит эта проблема не должна влиять на принятие решения go/not go. А вторая проблема — иниджевая, заказчик, для которого пишем приложение, уже неоднократно тыкал нас носом в аналогичные проблемы в других местах приложения и использует как аргумент, что мы не в состоянии нормально работать. По-прежнему считаем, что с такой проблемой можно отдавать билд заказчику?
возможно, неочевидно и запутанно, но как-то ж пользуются…
лично меня больше удивляет обратное: пользуются FB те же люди, которые пользуются и iOS-девайсами, кои для меня (девайсы) — темный лес с совершенно неочевидным функционалом. КАК после простого и понятного FB они способны пользоваться нелогичными эппловскими прибамбасами???
возможно, это еще один пример, когда FB пытается думать за вас. у меня несколько сот друзей, потому при нажатии на «Friends» открывается таки список друзей. вполне возможно, что если друзей мало — их «надо искать»
1. клик на Timeline (это там где имя пользователя написано)
2. клик на Photos
экран с: «Photos of You», «Photos», «Albums», переходим в нужную категорию
3. (не кликаем на фото для открытия) наводим на фото мышку — видим справа вверху на фото две кнопки: звездочка — «Highlight», и карандаш — «Edit or Remove».
4. жмем на карандаш — получаем выпадающее меню на фото: Edit Location, Change Date, Download,…
по поводу хранения не дольше, чем существует FB — это со всеми сервисами, не находите?
«вернуть обратно» — это скачать на локальную машину? специально пошел проверить только что: кнопка c карандашиком на фотке открывает меню, в котором присутствует (и работает) «Download».
остальные «мелочи» не вписываются в юз-кейс «получить доступ к фото через определенное время», скорее это уже отсутствующие плюшки
ни в коем случае не хочу обидеть пользователей ни FB, ни VK ни других соц-сетей, но достаточно давно наблюдаю следующую картину среди огромного количества знакомых. существует три варианта:
— не разобрался в FB, зарегистрировался в VK
— FB даже не слышал, не разобрался в VK, зарегистрировался в одноклассниках
— зарегистрировался в FB и на всякий случай в VK (ради пары друзей, который не осилили FB), одноклассники — явно не мой уровень
вспомнил свой первый комп: 1994-й, amd 386dx40, мамка с впаянным процессором = 90$, память — 1mb (4 планки по 256kb) = 40$. все в сумме с 14" монитором и винтом на 200mb — 780$, купленный за свои, честно заработанные. только школу закончил тогда… модем первый на 2400 за 30$, потому что 9600 — это было очень круто и очень дорого. на этом всем в режиме однозадачности под dos жила моя первая bbs, по совместительству — фидошная нода.
памяти через год докупил, когда подешевела: шиканул, купил сразу 4 планки по 1mb в сумме за 105$ получилось. сильно позже — модем idc 33600, лучшее, что можно было купить за <200$. помню, в те времена еще споры были: os/2 vs win95, я к подосиновикам себя относил
в OpenIndiana pool v.5000, отказались от «наборов» опций, сделали опции, включаемые отдельно.
в принципе, единственное, чего не хватает сейчас в zfs, разрабатываемом комьюнити, это шифрования. но его действительно нигде кроме оракла нет
интересно, но… а что мешает использовать стабильный солярис (openindiana) со стабильной zfs?
кстати, а что про требования к памяти zol пишут, в частности по рекомендациям для dedup?
из моего опыта (домашнего): 60Gb сстема с dedup, 2*2TB zpool под торренты и raidz из 3*1TB под данные: Prefetch начинает эффективно использоваться где-то после 20-22Gb ARC, при меньших объемах — только Demand.
прошу прощения, что не стал копировать описание принципов работы из указанной статьи.
опишу своими словами:
— команда add выполняет добавление пути в базу, происходит это без проверки на существование реального пути. проверкой занимается «обвязка» в shell, которая выполняет добавление только тех путей, по которым был выполнен реальный переход при помощи команды cd
— команда go только просматривает список «знакомых» каталогов на предмет попадающего в условия поиска, согласно подсказок. проверка на существование каталога, который она возвращает также осуществляется в «обвязке»
— разбор по частям в текущей реализации не выполняется
пример использования:
1. когда-либо ранее выполнили переходы в существующие каталоги:
$ cd ~/work/jira/scripts
$ cd ~/wotk/jira/lib
$ cd /export/src/myproject
при успещных переходах данные пути сохранились в ~/.2paths
2. выполняем переход с подсказкой:
$ 2 jisc
осуществляется переход в ~/work/jira/scripts
$ 2 proj
осуществляется переход в /export/src/myproject
Если серьезно, тестировщик, QA, кодер, архитектор, менеджер — это всего-лишь проектные роли. Другое дело, что не все взаимозаменяемые. Да, QA может работать какое-то время простым тестировщиком, но во-первых его ручная работа будет очень демотивировать, во-вторых, это просто неэффективное использование рессурса. Да и разница между тестировщиком и QA очень большая, QA — это не просто тестировщик с большим опытом, тут нужен опыт управления, опыт разработки.
Да, бывают случаи в реальном мире, когда просто делят на «software developer» и «специалист по качеству», но это чаще в мелких проектах на три калеки, там каждый на все руки мастер и уровень ответственности невысокий. Представьте проект, в котором постоянно присутствует несколько десятков разработчиков, и столько же тестировщиков. Если каждый разработчик (будучи даже сеньером, но выполняющий на проекте строго определенную роль кодера) полезет в архитектуру приложения — вся эта шобла (извините, команда), никогда никуда не приедет. С QA то же самое. Кстати, QA в данном случае будет скорее все равно один, причем не факт, что будет закреплен за этим проектом. И для эффективности его работы иерархия в компании будет выстроена таким образом, чтобы он был не в подчинении никого из команды, включая менеджера, QA — это трезвый взгляд со стороны, а не изнутри песочницы.
А вот от документации уходить никак нельзя, опять же, если есть QA. А если QA отсутствует, то разработчики с тестировщиками как-угодно могут договориться между собой, хоть левой ногой код писать и в телефонном режиме его «тестировать»…
Описываемая область находится на границе знаний между разработчиками и тестировщиками. Если б было ясно сказано, что зеленая/красная лампочка — она только для разработчиков, тогда согласен, команда разработчиков уверена какой продукт отдает. Но поскольку тут упоминался еще и менеджер, который обычно гораздо менее технически подкован чем разработчики и тестировщики, но при этом гораздо лучше знает, чего от продукта ждет заказчик, зеленая/красная лампочка ориентированная и на него тоже, должна нести несколько другой смысл.
Вот пример специально из ручного тестирования, несколько преувеличенный, но, надеюсь, моя мысль будет понятна. Возьмем две проблемы в приложении, которые мы регрессим:
1. приложение падает при старте (скажем, на определенном железе/системе)
2. в одном из основных диалогов приложения расстояния между тремя основными кнопками визуально неодинаковые, разница — 2-3 пикселя
Теперь зададим вопросы по обеим проблемам: проблема серьезная? Отсутствие этой проблемы в билде сделает его «более зеленым»? Присутствие — сделает «более красным»?
Чаще ответ будет: №1 — серьезная, №2 — косметика, можно пропустить. Однако зависит от условий: может система/железо, на которых возникает проблема №1, вовсе не является target системой для приложения, значит эта проблема не должна влиять на принятие решения go/not go. А вторая проблема — иниджевая, заказчик, для которого пишем приложение, уже неоднократно тыкал нас носом в аналогичные проблемы в других местах приложения и использует как аргумент, что мы не в состоянии нормально работать. По-прежнему считаем, что с такой проблемой можно отдавать билд заказчику?
P.S.: оффлайном еще во времена fidonet наигрался
лично меня больше удивляет обратное: пользуются FB те же люди, которые пользуются и iOS-девайсами, кои для меня (девайсы) — темный лес с совершенно неочевидным функционалом. КАК после простого и понятного FB они способны пользоваться нелогичными эппловскими прибамбасами???
2. клик на Photos
экран с: «Photos of You», «Photos», «Albums», переходим в нужную категорию
3. (не кликаем на фото для открытия) наводим на фото мышку — видим справа вверху на фото две кнопки: звездочка — «Highlight», и карандаш — «Edit or Remove».
4. жмем на карандаш — получаем выпадающее меню на фото: Edit Location, Change Date, Download,…
«вернуть обратно» — это скачать на локальную машину? специально пошел проверить только что: кнопка c карандашиком на фотке открывает меню, в котором присутствует (и работает) «Download».
остальные «мелочи» не вписываются в юз-кейс «получить доступ к фото через определенное время», скорее это уже отсутствующие плюшки
— не разобрался в FB, зарегистрировался в VK
— FB даже не слышал, не разобрался в VK, зарегистрировался в одноклассниках
— зарегистрировался в FB и на всякий случай в VK (ради пары друзей, который не осилили FB), одноклассники — явно не мой уровень
памяти через год докупил, когда подешевела: шиканул, купил сразу 4 планки по 1mb в сумме за 105$ получилось. сильно позже — модем idc 33600, лучшее, что можно было купить за <200$. помню, в те времена еще споры были: os/2 vs win95, я к подосиновикам себя относил
в принципе, единственное, чего не хватает сейчас в zfs, разрабатываемом комьюнити, это шифрования. но его действительно нигде кроме оракла нет
кстати, а что про требования к памяти zol пишут, в частности по рекомендациям для dedup?
из моего опыта (домашнего): 60Gb сстема с dedup, 2*2TB zpool под торренты и raidz из 3*1TB под данные: Prefetch начинает эффективно использоваться где-то после 20-22Gb ARC, при меньших объемах — только Demand.
опишу своими словами:
— команда add выполняет добавление пути в базу, происходит это без проверки на существование реального пути. проверкой занимается «обвязка» в shell, которая выполняет добавление только тех путей, по которым был выполнен реальный переход при помощи команды cd
— команда go только просматривает список «знакомых» каталогов на предмет попадающего в условия поиска, согласно подсказок. проверка на существование каталога, который она возвращает также осуществляется в «обвязке»
— разбор по частям в текущей реализации не выполняется
пример использования:
1. когда-либо ранее выполнили переходы в существующие каталоги:
$ cd ~/work/jira/scripts
$ cd ~/wotk/jira/lib
$ cd /export/src/myproject
при успещных переходах данные пути сохранились в ~/.2paths
2. выполняем переход с подсказкой:
$ 2 jisc
осуществляется переход в ~/work/jira/scripts
$ 2 proj
осуществляется переход в /export/src/myproject
P.S.: добавил «обвязки» в репозиторий