All streams
Search
Write a publication
Pull to refresh
3
0
Дмитрий Грачев @dimas

Разработчик ПО

Send message
я бы поспорит насчет «типовой точки зрения юзверя»…

по крайней мере «юзверь-юзвери» знакомые, кто соскочил с аськи (и даже джаббера) на скайп мотивировали это отсутствием спама…
Э-э-э,

unicyr_ctype.hpp, line 189

std::map<mask, wchar_t> masks;

а не наоборот ли?

p.s. пардон, если что, очень спать хочется :)

на gentoo обычно никто руками не собирает, если только не желает потрахаться нестандартно…

то же накладывание патчей и изменение параметров конфигурации делается изменением одного ebuild-файла за пять минут…

да и чтобы поставить в другое место тоже немного усилий потребуется…

зато был бы готовый ebuild, из которого можно бы было сделать patch и для последующих версий и автоматом накатывать…
минусовать могут не столько за сам вопрос, сколько за его формулировку…
:) а поддерживать потом сделанное — тоже через коммуникацию? а если П и М давно уволились или по другую сторону шарика отдыхает?

да и оберации сознания штука такая…
:) а если их не трое — а пятеро? а если делаем что-то сложнее чем сайт из трех страничек, что еще и через год поддерживать кому-то надо будет?
О. Вот это тоже типичная ошибка, которая портит отношение в коллективе, а тем более между тестерами и разработчиками — кто больше виноват :)

Ошибки были, есть и будут, особенно в системах «с большим наследством»… Да и если бы их не было — тестеры бы были не нужны :)

Но защита разработчку тоже от тестера не нужна по сути, главное — чтобы противостояния и взаимных обвинений не было. В идеале то, конечно, хочется вообще сотрудничества — чтобы и разработчик мог внятно объяснить что в каких компонентах поменялось (или вообще какие трогали), а тестер мог не только внятно объяснить последовательность 100% воспроизведения ошибки, а то и помочь локализовать или хотя бы миннимизировать последовательность…
от такого подхода недалеко до того, что тестирование будет слабеньким…

с тестировщиков должны спрашивать за серьезные необнаруженные баги в релизе.

а уж они должны сами или совместно с разработчиками придумывать как их обнаруживать и, по возможности, автоматизировать это…
Дим, я бы еще проще сказал: процесс тестирования не должен напоминать перекидывание мячика через сетку…

Но, как ты помнишь по нашему совместному опыту (:), для этого еще и проектная документация должна быть нормальной, чтобы не было так, что тестер и разработчик постановку трактуют каждый по своему, а менеджер хочет третьего :)
Я, вот, похоже знаю откуда берутся пустышки :)

Зашел я на сайте. И хочу узнать ровно две вещи:
— могу ли я импортировать данные из другого источника
— сколько стоит и в чем разница

И вот как-то потыкался по ссылкам и навскидку не нашел. Тыкнулся в карту сайта… Потыкался там в несколько ссылок, понял что это топики на форуме (что, на мой взгляд, вообще в карту включать не надо), и вообще перестал искать…

А мне и регистрироваться лень, но у меня есть работающее решение — MS Money ^)
читайте договор :)

там обычно прописан срок, через который номер теряется… обычно через полгода в «отстойнике» номера продаются снова…
так и так можно переоформить, если заставить это сделать владельца точки (если симка действительно на него оформлена).

в противном случае это будет лишней «дыркой», которой наверняка рано или поздно воспользуются…
FireFox add-on Tab Mix Plus :)
светодиод желтый горит обычно не только когда денег совсем нет, а когда их запас меньше некоторого значения…

причин же невыдачи может быть больше одной:

1. в банкомате есть свои счетчики купюр, которые вводят инкассаторы, когда меняю кассеты с купюрами. даже тут могут быть ошибки, ибо они сами их не считают, а вводят цифры с бумажки на кассете.
2. банкомат, когда начинает набирать суммы для выдачи, проверяет их по куче показателей, в том числе по толщине. если у него появляется подозрение, что произошла ошибка, например слипшаяся купюра, то все набранное сбрасывается в специальную reject-кассету и процесс начинается снова.

т.о. вполне может быть ситуация, когда банкомат считает что в кассетах что-то осталось, а на деле уже нет… или что-то с самим трактом набора, например…

при этом в части операций разобраться, были ли в реале деньги выданы или нет, можно разобраться только после инкассации, когда заберут reject-кассету и ленту из журнального принтера, передадут в соответствующее подразделение и т.д. пока не разберутся — да, деньги будут заблокированы на счете.

по крайней мере все было так, когда я с этим работал десять лет назад и у нас на обслуживании стояли банкоматы NCR(AT&T) четвертого-пятого поколения.

да, по-хорошему это все должно мониториться, но в реале задержки могут быть от суток (на неделе) до трех-четырех, пока доедут да разберутся с машинкой.

а обязательно одним файлом? MozBackup никак не заменит?
12 ...
38

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Software Developer, Fullstack Developer
Senior
Git
SQL
Python
C#
C++
Qt
Linux
PostgreSQL
Golang