Элементарная задачка - XML, добавление
Элементарная задачка.
Для тех кто ЗНАЕТ решение - просьба не постить код и не давать полного описания.
Ссылки на требуемое изучить для получения решения - весьма приветствуются.
Аналогично в обсуждении - приветствуется указание на проблемы в приводимом коде,
но не желательно заменять пишущего в осознании и исправлении проблем - ему не впрок.
Задача.
Требуется - добавлять какие-то фрагменты в ХМЛ файл.
Для простоты - пусть они будут одинаковые по структуре ХМЛ.
Вроде как все работает, но... медленно. И чем дальше - тем медленнее.
Вместо 10 минут на добавление одного фрагмента надо сделать... хммм... 100 милисекунд... хотя, пожалуй, много.. 20-ти хватит...
Да, пока не забыл - работа с файлом - остается. т.е. если рубильник смайнают - все должно работать без потерь... но журналировать процесс
не надо.
Никаких ограничений не ставится
- хочешь стандартные либы - будь ласка,
- хочешь штаны через голову - милости просим...
только одно ограничение - 20 милисек на добавление...
Надо таки сказать гораздо больше, что бы хоть кто то понял, что действительно требуется.
-----
Да вроде все необходимое сказано.
Требуется именно то что написано - добавить в ХМЛ документ еще один кусок ХМЛа. Сделать это надо максимально быстро.
Добавилось - пишем локально, объем добавления - небольшой.
Пока что вроде стало понятно, что поднять документ в память, добавить и записать обратно - будет медленно.
Почему - пока не понятно. 
(Не мне если что)
Был высказан вариант с высокой фрагментированностью дисков... Но, увы, искомое решение никак не зависит от фрагментированности.
Жду других вариантов...
есть большие сомнения, что это кого то это заинтересует
-----
Ну это как всегда - кто-то будет рыть чтобы найти ответ и чему-то в процессе научится, а кто-то будет
говорить что стандарными либами это не сделать и, следовательно, решения нет... 
Сделать это надо максимально быстро
В начальных условия было определено конкретное время но не определено какое именно время нужно измерять 
объем добавления - небольшой
Небольшой это сколько? Одна строка....
Обрабатывать еще как то нужно добавление?
А вставлять в какое место? А исходный файл можно менять? Типа метку для вставки сделать.
А исходный файл и вставки одинаковые или как получится? И т.п. и т.д. - а гришь что всё сказано.
чему-то в процессе научится
Учится можно тому, что хотя-бы интересно, ну или нужно. А тут еще и с таймером сидеть 
добавить в ХМЛ документ еще один кусок ХМЛа. Сделать это надо максимально быстро
В подобном виде, для какого-то конкретного файла и вставки можно еще как то обсуждать. А так ... ну ждите
Да, если кому надо чутка по-интереснее задачка, то сделаем так.
Документ - тот же.
А добавлять будем - из 30-ти разных потоков.
Естественно, надо решить проблему с синхронизацией записи из потоков...
И если кто думает писать какие хреновы сложности - шел бы он лесом - код требуется совсеm простой...
А тут еще и с таймером сидеть
-----
Вот и Я говорю - кто-то будет сидеть с таймером, а кто-то будет сидеть без таймера...
для какого-то конкретного файла
-----
Эээ... нет... не для конкретного.
Для конкретного ты напишешь решение номер один и оно пойдет в мусорник.
Пиши для любого какой тебе позже представят... 
для какого-то конкретного файла
-----
Эээ... нет... не для конкретного.
Для конкретного ты напишешь решение номер один и оно пойдет в мусорник.
Пиши для любого какой тебе позже представят...
Вы уже на Гитхабе со своим уникальным универсальным решением или даже продаёте свою либу как продукт? Или это никому не надо? )))
Как решать не знаю.
В приведённых вами условиях слишком много неоговорено, поэтому всегда можно не уложиться в отведённое время. Наиболее быстрая задача, как мне кажется, это иметь заранее заготовленный план такого большого XML файла - т.е. где у него с какого адреса или строки что расположено. Или даже разбить этот файл на куски. И при этом нужно заранее знать, куда вставлять - произвольно не означает в случайное место же, а в какой-то определённый участок, примерно положение которого вы знаете? Т.е. по-любому нужно делать инфраструктуру по обработке таких больших файлов - своего рода "базу данных по большим XML". В этом смысле, наверное, проще действительно хранить подобные данные в БД, и не в XML, а XML генерировать по запросу, или периодически и потом кешировать.
Я думаю, что если вы приведёте своё оригинальное решение, как вы успешно справились с этой задачей, на вас куча критики свалится, т.к. решение будет, скорее всего, либо неуниверсальным, либо требовать создание предварительной инфрастуктуры по обработке таких файлов для таких задач.
Никаких ограничений не ставится
- хочешь стандартные либы - будь ласка,
- хочешь штаны через голову - милости просим...
только одно ограничение - 20 милисек на добавление...
Элементарно:
1) десериализуешь XML в нужный объект
2) добавляешь необходимые данные
3) сериализуешь объект в XML
4) если из-за огромных размеров XML описанная выше процедура не укладывается в требуемые 20 милисек (или если перезаписывать этот XML надо слишком часто, т.е. время на запись становится критичной), то выгоняешь ссаными тряпками мудака, который вместо БД решил использовать XML.
если из-за огромных размеров XML описанная выше процедура не укладывается в требуемые 20 милисек (или если перезаписывать этот XML надо слишком часто, т.е. время на запись становится критичной), то выгоняешь ссаными тряпками мудака, который вместо БД решил использовать XML.
охуенный вывод.
это есть если тебе XML приходит от условного Finanzamt’а и его надо передать в фирму рога и копыта, то вы всю коммуникацию должны перевести на БД?!
Вообще, задача "в ооочень большой объём структурированных данных добавляем в произвольное место другие данные" - это больше для БД. Уж точно не единого текстового XML где-то в файловом хранилище.
Как я понимаю, единственное оправдание подобной задачи - вот откуда-то пришло и будет всегда так приходить (типа как тут сказали - из какого-нибудь амта), и повлиять мы на это не можем. Шеф сказал 20 мс и точка, из амта пришёл многогиговый XML и точка, нужно вставлять в произвольное место куски и точка, решение должно быть универсальным и точка. Ах, да - на решение 15 минут.
это есть если тебе XML приходит от условного Finanzamt’а и его надо передать в фирму рога и копыта, то вы всю коммуникацию должны перевести на БД?!
Нет. Если тебе приходит XML от условного Finanzamt'а и его надо передать в фирму рога и копыта, то это разовая операция и время ее исполнения не играет большой роли.
А если тебе надо добиться скорости работы, то ты ищешь оптимальные средства для поставленной задачи.
На одном проекте у нас было куча пакетных данных и взаимосвязей между данными. Ну т.е. пакет данных типа А может быть связан с пакетом данных типа Б, но не может быть связан с пакетом данных типа С. Начальство решило, что оптимально использовать TFS, т.к. там все это есть из коробки плюс к этом данные срази в пакетах, плюс есть история изменений и много других плюшек. Когда я пришел в проект все уже было почти
готово к запуску, но тем не менее я сказал начальству, что TFS для этих целей не подходит и стоит ожидать большую жопу. На тестах и презентации все летало. Выпустили в продакшен... и через месяц посыпались жалобы, что жескать система писец какая медленная. Сукой оказалась TFS :D Пришлось начальству краснеть, получать люлей и следующие месяца 3 мы переводили систему с TFS на MSSQL. Так что для каждой задачи надо подбирать подходящее решение.
Как решать не знаю.
-----
Это Я вполне хорошо понимаю - задачка дана именно под то что ты не знаешь.
слишком много неоговорено
-----
Уточняй. Что будет реально влиять на выполнение задачи - доопределим.
либо неуниверсальным, либо требовать
-----
А для тебя поставлены какие-то ограничения? Вроде как нет.
Извращайся как можешь/хочешь.
Гарантирую - когда будет приемлемое решение - будет весьма полезно.
С SAX будет побыстрее.
-----
Насколько? Успеешь за 20 мил отсканить SAXom 10-20 гиг?
А если уже сейчас:
- понимаешь что не успеешь
- утверждается что решение есть
то надо как-то подумать над вопросом...
Но я за тряпки
-----
Подсказка - посмотри из чего выплыла задачка.
Ах, да - на решение 15 минут.
-----
Вообще-то, тебе давалось два часа.
А требуемый по заданию код - да, можно написать за 10-15 минут...
Как же ты, бедолага, будешь работать при таком подходе к решению задач...
Про тряпки тут уже поминали... перед этим еще ПМ поимеет по полной...
А если ЕСТЬ более простое решение, чем использование БД?
У каждого инструмента есть своя область применение. Безусловно, орехи можно колоть и гидравлическим прессом, но есть и более подходяшие инструменты ;)
Ты, кстати, допустил ту же ошибку, которую уже разбирали: выполняешь парсинг всего файла, об котором в задании НИЧЕГО не говорится.
Нет, просто если у тебя есть 10гиг конфигурации, то использовать XML будет очень странный человек :) И этого странного человека надо гнать ссаными тряпками.
есть и более подходяшие инструменты
-----
Вот и Я не понимаю - зачем ты тянешь гудравлический пресс (БД), туда где он совершенно не нужен.
если у тебя есть 10гиг конфигурации, то использовать XML будет очень странный человек
-----
Скучно.
Есть - задача. Известно, что есть решение. Известно что решение - простое.
Так нет - обсуждается то, что задача изначально неправильная.
А она не неправильная - она - целевая...
Насколько? Успеешь за 20 мил отсканить SAXom 10-20 гиг?
Конечно нет. За 20 мс. 10 ГБ даже с диска прочитать не успеешь. Даже с ССД. Мегабайт 60 максимум.
- понимаешь что не успеешь
- утверждается что решение есть
то надо как-то подумать над вопросом...
А что тут думать? Очередной "муркин высер". Который в конечном итоге через 100500 уточняющих вопросов сведётся к какой-то ерунде не имеющей ни малейшего отношения к изначальной формулировке вопроса.
PS Вангую что окажется что оффсет от начала файла заранее известен (искать не надо) и используется отлично работающая с random access файлами файловая система. Отсюда и ограничение в 4 К.
Или нет, это же мурка... Тут надо думать максимально нелогично...Какой-нибудь индекс сейчас всплывёт.
Хранить и давать доступ для чтения и записи к 10ГБ структурированной информации - это задача для БД.
Есть - задача. Известно, что есть решение.
Нет даже решения, чтобы прочитать 10ГБ за 20милисекунд. Можно конечно записывать эти фрагменты тупо в конец файла, но не факт, что 10ГБ можно будет открыть за 20 милисекунд.
Как решать не знаю.
-----
Это Я вполне хорошо понимаю - задачка дана именно под то что ты не знаешь.
слишком много неоговорено
-----
Уточняй. Что будет реально влиять на выполнение задачи - доопределим.
Честно, мне лень дальше по этой задачке думать. Извините.
Давайте уже своё решение, и желательно без копирайта. ))
PS Вангую что окажется что оффсет от начала файла заранее известен (искать не надо) и используется отлично работающая с random access файлами файловая система. Отсюда и ограничение в 4 К.
У него было про случайные вставки - т.е. никаких заранее известных оффсетов и меток. Т. е. по идее нужно сначала найти место в фале, куда вставлять (т.е. просканировать его), затем вставить. Чтобы просканировать, нужно открыть целиком или простримить. И если место для встаки окажнтся в конце файла, то в 20 мс никак не уложиться.
Конечно нет.
-----
Ну тогда не трогаем SAX...
Вангую
-----
Уже ближе.
Товарищ, которому задачка адресована, уже предлагал какие-то метки в файл помещать.
Какой-нибудь индекс сейчас всплывёт.
-----
Нее, не всплывет.
Бо, решение совершенно элементарное.
Даже при 30 потоках...
оффсет от начала файла заранее известен (искать не надо)
-----
В том решении об котором ты подумал - это решение номер два - нет.
Просто есть еще более простой вариант при котором будет ответ - да.
Думаю, что подумав и посмотрев в доки ты его найдешь.
А когда найдешь, будь ласка, подтверди наличие решения и поделись ТОЛЬКО ссылкой на доку... Ок?
давать доступ для чтения
-----
Где именно в задании есть это требование?
Нет даже решения, чтобы прочитать 10ГБ за 20милисекунд.
-----
Ну если ты ЭТО понимаешь, то зачем говоришь что надо читать?
Напряги извилины, перечитай задание, подумай, ковырни доки...
... и будем смеяться вместе над примитивностью решения.
Только - тссс... не подсказывай...
но не факт, что 10ГБ можно будет открыть за 20 милисекунд
-----
А с каких пор размер файла начал влиять на время создания дескриптора доступа?
Ну если там шадов копи делается, маппинг или какой-нибудь индекс система строит - то да...
но просто открыть файл у меня это около 22 мс...
Инклюдом сократим количество записываемой информации до одной строчки. Но всё равно надо сначала найти место, где его вставить (в 10 гигах), а потом записать изменение.
Или вы думаете Мурр собрал 10 гигов данных в 10.000 файликах по 1 мегу и все их заинклюдил в один большой из 10.000 инклюдов? Не, он может, конечно :)
Для сомневающихся в возможностях решения задачи,
По результатам фактического теста (под отладчиком Студии) - 3883 милисекунд на 10.000 добавлений...
Время включает подготовку отдельного хмл для каждой записи - т.е. реальное время где-то 0.3 мс/добавление...
Все записи реально добавлены в файл. Записи - короткие - всего в файле 2.7Мб...
Ах, даа... старый лапоть - ССД, НТФС, И7, 8 Гб РАМ...
А что именно ты собираешься искать?
Я? Ничего. Это ты что-то искать должен. Ты же что-то куда-то вставляешь. А куда именно вставляешь - не знаешь.
Значит что? Значит ты должен найти место куда вставлять. Для поиска этого места в 10-и гиговом XML файле тебе в худшем случае (если это место будет в конце файла) придётся прочитать весь файл.
А теперь начинай юлить "я имела в виду не это, я не это имела в виду".
А куда именно вставляешь - не знаешь.
-----
Кто тебе это сказал?
Я назвал время - 0.3мс/вставка - по результату фактического тестирования - оно тебе хоть что-нибудь говорит?
Если поможет - оно не будет сильно менятся с ростом размера файла... какие-нибудь 0.02 мс... система больше задержать может...
придётся прочитать весь файл
-----
Зачем?
Уже сейчас ясно, что успеть поднять 10 гиг с диска за отводимое время не получится - ни документом, ни сахом, ни риадом - канал чтения 6 гб/с мах...
Начинай говорить, что надо решить задачу по второму варианту - т.е, найти ДокументЭлемент, потом позиционироваться примерно в конец и искать начало закрывающего тега... И сразу - второй вариант тоже идет в помойку, хотя и может уложится по времени в 20 мс...
Правильный ответ был бы
-----
Не был бы, а уже дан - пофиг дважды.
Фат берется по единственной причине - избавится от контроля прав доступа.
Я знаю, что под виндой есть возможность заблокировать этот контроль для определенных файлов под НТФС, но, увы, не умею этого делать.
А ограничения на размер могут быть любыми - как ты и говорил - будет ограничение в мегабайт - напишем 10К инклюдов...
П.С. "Сними погоны - стань обезьяном" (с) Мурр, сегодня.
придётся прочитать весь файл
-----
Зачем?
Уже сейчас ясно, что успеть поднять 10 гиг с диска за отводимое время не получится - ни документом, ни сахом, ни риадом - канал чтения 6 гб/с мах...
Что и подводит к мысли что задачу в том виде, как они сформулирована (вставка в произвольное место xml фала), решить невозможно. Отсюда вывод: очередной "муркин высер".
Учись формулировать задания.
Подсказка из зала: попробуй написать, а как именно ты хочешь задавать место вставки в XML? "Вставь <a>bbb</a> на 8-ю строчку"? Или "Вставь abc как значение элемента /document/chapter[@number=1]" или как?
На собесах подобные же задачки даёте?
-----
На собесе - нет - бессмысленно, ибо задача не на знание определенных вещей.
Мог бы и не спрашивать - тебе на нее дали 2 часа - на собесе столько времени на тебя тратить никто не будет.
А вот в качестве проверки навыков - да, вполне годится.
Ты, кстати, завалил два момента - общие инженерные навыки и умение работать с документацией.
Думаю, что дав пару тестов на сообразительность получу полную картинку.
И она сильно не в твою пользу будет.
Думай, работай над собой.
На собесах подобные же задачки даёте?
-----
На собесе - нет - бессмысленно, ибо задача не на знание определенных вещей.
Мог бы и не спрашивать - тебе на нее дали 2 часа - на собесе столько времени на тебя тратить никто не будет.
А вот в качестве проверки навыков - да, вполне годится.
Ты, кстати, завалил два момента - общие инженерные навыки и умение работать с документацией.
Думаю, что дав пару тестов на сообразительность получу полную картинку.
И она сильно не в твою пользу будет.
Думай, работай над собой.
Смысл? Все ваши закидоны не помогли вам набрать нормальных, а не "обезьян".
за что он туда попал
-----
Господа ХТМЛщики, когда Я их спросил вам как - порезать на единицы обработки или одним куском.
Ты не поверишь - вместо того чтобы ограничится необходимым они пожелали ВСЕ в куче...
10 Гиг там не было, но под 700 мб - имелось...
Господа ХТМЛщики, когда Я их спросил вам как - порезать на единицы обработки или одним куском.
Ты не поверишь - вместо того чтобы ограничится необходимым они пожелали ВСЕ в куче...
10 Гиг там не было, но под 700 мб - имелось...
Ну вот видите. Оказывается, у вас не одним файлом ваши 10 ГБ, а вы порезали. И потом в один маленький кусочек свои добавления делаете. И поди заранее знаете, в какой из кусочков добавлять надо.
ХТМЛщики работают с DOM. А кто им нормальный DOM создаст, а не в лучшем случае слепок местного участка разметки, когда всё кусками разбросано? Если файл так уж постоянно нужен, то проще всё в оперативке держать, загружая раз только при старте системы. Ну сколько займёт создание DOM из 700 МБ файла? Гигабайт 16, или даже 32? Цена вопроса даже сейчас, после взлёта цен на оперативку - 70-150 евро.
Что значит "а подумать"? Мне самому себе придумать задачу и её решить? Откуда я знаю, что тебе надо? Может ты тупо добавляешь всё к концу, переписывая последний закрывающий тег.
Мне тут пришла светлая до опупения мысль - надо XML представить в виде файлов и папок :D
<SomeNode>
<SomeOtherNode someAtt="bla-bla" >bla-bla-bla</SomeOtherNode>
<SomeCollection>
<SomeItem>Item 1<SomeItem/>
<SomeItem>Item 2<SomeItem/>
<SomeItem>Item 3<SomeItem/>
</SomeCollection>
</SomeNode>
Все это безобразие можно замэпить на файловую систему:
..\
SomeNode\
SomoeOtherNode\
attributes.txt
value.txt
SomeCollection\
SomeItem.1\
value.txt
SomeItem.2\
value.txt
SomeItem.3\
value.txt
Это правда не совсем XML, да и похер :D Зато можно быстро вставить что угодно и куда угодно :D
Проще в БД загнать. В современных вроде есть какие штуки для поддержки иерархических данных.
А как вы потом этот XML собирать будете? Вам нужено либо кастомный data provider городить для такой сериализации или десериализации, либо прожку писать, которая будет всё это делать. Ну и для вставок и прочих обработок всё равно нужно где-то держать схему этого XML или файловой структуры, чтобы знать, куда вставлять. Или будете схему каждый раз при вставке воссоздавать из структуры каталогов? А тогда уложитесь в 20 мс?
Вообще, решение, в котором если и можно добиться 20 мс на добавление чего-то куда-то, то всё остальное принесено в жертву.
Мне тут пришла светлая до опупения мысль - надо XML представить в виде файлов и папок :D
Ага. Или ещё какой индекс. Структуру 10-и гигового xml в файлы... NTFS охренеет сразу. Она с кучей мелких файлов прям ну совсем никак. Потом охренеет винда до 10ки. Из-за ограничения длины полного имени файла на 260 символов.10-ка поживёт подольше, она после какого-то билда 32к символов поддерживает.
Ну и опять же - остаётся загадкой куда ж вставлять-то охота. По файловой системе искать файлики тоже времени стоит немало.
В общем сплошные загадки. Не смешно и не интересно уже :)
Проще в БД загнать.
Это задача от 
Murr'а, там нет места для "проще" :D Тем более, что про ДБ ему сразу сказали и вариант с ДБ не подходит :D
А как вы потом этот XML собирать будете?
Кастомный сериализатор/десериализатор. Да и не нужно это все собирать ;) Задание состоит в том, чтобы добавлять данные ;)
Потом охренеет винда до 10ки.
Винды до 10ки уже давно не поддерживаются майкрософтом :D
Из-за ограничения длины полного имени файла на 260 символов.
Ну так UNC имена решают ;)
Ну и опять же - остаётся загадкой куда ж вставлять-то охота. По файловой системе искать файлики тоже времени стоит немало.
XPath дает путь к каталогу, так что надо просто создать папочку, если ее еще нет, и записать туда нужную информацию.
XPath дает путь к каталогу, так что надо просто создать папочку, если ее еще нет, и записать туда нужную информацию.
Можно, конечно. Но поискать-то придётся. А если у нас в каталоге пара тысяч подкаталогов (да, для одинаковых элементов придётся ещё какие-то индексы придумывать, двоеточие кодировать...), то просто получить их список легко займёт все 20 мс.
Но XPath-у места тут нет. На 10 гигах поиск по XPath займёт несколько секунд. Если у нас памяти хватит. XPath только на DOMе работает (если мне склероз не изменяет...)
странные какие-то вводные
-----
Конечно.
Ведь они даны именно под то, чего ты не знаешь.
Нахождение решения дало бы тебе знания в двух областях в которых ты откровенно слаб...
Да никто уже давно из нормальных людей не использует XML для хранения данных. Если чисто хранение, то джейсон лучше подходит - не такой многословный.
Кстати, ваш метод для джейсона сработает?
ваш метод для джейсона сработает?
-----
Не проверял.
Но, видишь ли, если применяемое решение не будет работать на джейсоне - всегда можно применить ту же методику по которой получено решение и найти что-то подходящее...
Твои проблемы в двух вещах :
- очень мало знаешь
- не умеешь быстро изучать проблему.
Работай над собой...
Вместо 10 минут на добавление одного фрагмента надо сделать... хммм... 100 милисекунд... хотя, пожалуй, много.. 20-ти хватит...
Имхо всё зависит наверное от архитектуры, типа диска и файловой системы. Если это всё делать в ОЗУ или на SSD, то наверное будет быстрее, не зря ведь IMDB наберает популярность. Может что-нибудь такое https://stackoverflow.com/questions/4942884/how-to-create-in-memory-xml-document-and-get-string-out-of-it или http://csharphelper.com/blog/2014/09/build-a-formatted-xml-document-in-memory-in-c/?
XML на несколько гигов - в принципе нерабочая история :)
-----
ХМЛ на несколько гигов - это достаточно регулярная задача.
Стандартные либы - это какие? Да и собственно говоря зачем им это? :)
-----
Скажем так - все что в System.Xml.*...
Это - не зачем, для чего.
Целей у задачи много.
Одна из целей - достичь понимания того, что РАМа не бесконечна и надо уметь работать не только с обьектом в памяти.
Другая - что мало не знать - знать все невозможно - но надо еще оставаться тупым, не изучая ничего нового... или старого, что не было изучено.
Прикол в том, что задача не понята ТОБОЙ :)
Точнее говоря, тобой не понята групость и несуразность этой задачи.
Он не может отказаться. Менеджер сказал - значит закон.
А что, правда увольняют за то, что подобной задачи решить не смог? Есть такой подход - до первого проё...а. Т.е. что бы ты ни сделал, какие бы заслуги ни были, а после первого же проё...а дают пинка под зад. А то и просто дают, если найдут кого получше.
Потому что у тебя в принципе отсутствует возможность решать подобные задачи - для тебя это новое.
Нет никакой проблемы выяснить с чем еще у тебя проблемы и предложить другую задачу...
А насчет второго... никая задача не будет "тупой"... тупым, по определению, может быть лишь инструменt...
ХМЛ на несколько гигов - это достаточно регулярная задача.
Это только в твоем странном мире это регулярная задача. Нормальные люди в таких случаях используют БД.
Одна из целей - достичь понимания того, что РАМа не бесконечна и надо уметь работать не только с обьектом в памяти.
Другая - что мало не знать - знать все невозможно - но надо еще оставаться тупым, не изучая ничего нового... или старого, что не было изучено.
Странно, что нет цели научиться использовать подходящий к конкретным целям инструментарий :)
Менеджер сказал - значит закон.
Менеджер не марсианин. У него есть голова и он восприимцив к аргументам. Особенно, если аргументировать цифрами.
Ты себе не представляешь сколько "нерушимых" указаний менеджеров было изменено. И сколько раз менялись подходы с "мы всегда так делали и будем делать дальше" на что-то вменяемое.
Любые изменения - это вопрос денег. С одной стороны деньги на непосредственное изменение и с другой потери, в том числе и репутационные, из-за использования неправильной технологии. Как только переделать становиться дешевле, сразу отдается команда на переделку. Так что остается только доказать менеджеру, что переделка будет дешевле.
А что, правда увольняют за то, что подобной задачи решить не смог? Есть такой подход - до первого проё...а.
Ты же понимаешь, что это зависит
от проеба :) Но в общем случае нет, это неправда.
Менеджер не марсианин. У него есть голова и он восприимцив к аргументам. Особенно, если аргументировать цифрами.
Ты себе не представляешь сколько "нерушимых" указаний менеджеров было изменено. И сколько раз менялись подходы с "мы всегда так делали и будем делать дальше" на что-то вменяемое.
Может Мурр не может перечить менеджеру. Кто знает, что у него там за условия труда.
Может Мурр не может перечить менеджеру. Кто знает, что у него там за условия труда.
Скорее Мурр в принципе не может перечить менеджеру. Более того, тех, кто может перечить менеджеру не так уж и много. Плюс много зависит от менеджера. У нас пару месяцев назад одного мужика уволили одним днем (что в Германии вообще нонсенс) за то, что перечил менеджеру...
Так что всякое бывает, но большинство менеджерам не перечит...
Ну, просто не стоит забывать, что в отличие от тех же США он мог бы и оспорить увольнение и остаться работать. Но не захотел. Работу сейчас найти не сложно, да и зарплату повысить.
Блин, почему мои менеджеры меня не увольняли, а? 3 месяца на зарплату дома посидеть... Красота! :)
Блин, почему мои менеджеры меня не увольняли, а? 3 месяца на зарплату дома посидеть... Красота! :)
Так того, которого за день, ему может и не платили ничего. Вчера ты перечил менеджеру, а сегодня утром твои вещи стоят у входа и твой пропуск не считывается на входе.
Это не «да», это «нет»
Тебе 1-3 месяца платят за то, что сидишь дома.
В России тоже вроде всякие такие законы есть, чтобы пособие по увольнению или как там. Только по факту не так уж редко ничего не получаешь. Обычно зарплату делят на оклад и премию, если ты перестаёшь устраивать, тебе просто премию режут и ты сам уходишь, по собственному желанию, не дожидаясь увольнения от работодателя. А если сам ушёл - то выплаты по увольнению не положены.
Скорее Мурр в принципе не может перечить менеджеру.
-----
Мурр предпочитает работать с теми кому не нужно перечить.
Высказать свою позицию по вопросу - может всегда.
И выполнить работу именно так как требует менеджер - тоже.
Вот чего Мурр не делает - не исправляет то, что сделано после обьяснения непригодности решения... до признания его непригодности менеджером.