За одну ошибку может и не уволят. Это все зависит от многих причин, в том числе и личностных — отношение других сотрудников именно к этому человеку, руководства и пр. К томуже все чтут законодательство. Но если ошибки повторяются часто, то уже есть законодательный повод расстаться.
А если убытки исчисляются миллиардами и потерей рынка?
За 200000 сеньоры несут пермональную отвественность. И если программера за 60килоевро на первый случай могут и простить (что сомнительно судя по размерам ущерба), то сеньора просто сразу же уволят с надлежащей рецензией.
И в этом конкретном случае речь идет не об ошибках, а о намеренном изменении кода.
Отсюда вывод — сеньор сам по себе человек разумный и не мог не знать о том, что программирует код для мошенничества. Или это был приказ откудато сверху.
В любом случае сейчас спорить глупо. Пройдет разбирательство.тогда послушаем, что официально заявят.
Есть ошибки. Вы уж определитесь, в евро или долларах. Очень может быть, что индусы в сша получают намного круче. Но 60000 евро в год это довольно приличная работа для программера. Можете посмотреть о показателях зарблаты именно в Niedersachsen (именно там располагается головной завод в Wolfsburg) на http://gehalt.de. Или можете посмотреть на любых сайтах по поиску работы в этом регионе.
Вспоминаю еще компы, когда инфу хранили на касетах бытового касетного магнитофона. Вспоминаю еще приблуду для уже ibm совместимых, когда инфу можно было на vhs касету сохранить. Этакий бытовой стриммер.
Iomega появилась одновременно CD. И чуть попозже в продаже появились пишущие приводы. Так что CD(650МБ) по объему и сохранности инфы явно выигрывали и не дали Iomegе развернуться на рынке.
Да. Рассмешили. На фольксвагене программисты работают за 3 копейки. И еще они нанимают для разработки индусов по аутсорсу.
Специалисты в концернах такого класса в худшем случае работают по тарифам, где самый минимум 2000евро нетто(уже с учетом налогов) и максимум 3500(5000 брутто). А скорее всего работаю по отдельным договорам, где заработок от 60000 брутто в год.
За такие деньги ошибок быть не должно — каждая ошибка и ее последующее исправление обходится концерну в миллиардные убытки. Поэтому тестирование идет не на коленке, а на специальных стендах и выполняется специальнообученными людьми.
Ну вот на суде и будут ращбираться — тупо ли программисты реализовывали хитросоставленное техзадание или всетаки понимали какие процессы там идут.
В случае мошенничества нужно было сообщить об этом руководству. Не надо мне расказывать сказки, что за это могли уволить. Могли, конечно. Но по суду ещеб и компенсацию выплатили на пару десятилений вперед и такого международного скандала бы не было, все пресеклось бы на этой стадии. Это не Россия. Тут даже профсоюзы настоящие.
А разве в какую либо этику входит обман? Врача в ФРГ ожидает таже участь, если его пациент потерял здоровье, которое уже не вернуть. Хотя и в России так же (если, например, припомнить историю косметических операций жены Пименова).
Точно такими же мотивами можно оправдать мошенника, «нашедшего» кредитную карточку кого-либо и «оформив кредит» на этого человека.
Специалист, которому предложили запрграммировать «этот трюк», должен быть совсем идит, чтоб не понимать, что это обман и мошенничество. Но наивные идиоты врядли программированием занимаются.
Пять лет назад, устроившись в одну фирмочу в ФРГ столкнулся с подобным вопросом. Из-за плохого на тот момент владения языком подписал одну бумажку этой конторы, что якобы участвовал в каких-то действиях по обучению практикантов. Фирме за это от города отчисляли немного денег и вероятно налоговые плюшки. Мой коллега просто отказался это делать и позже объяснил мне положерие дел. Тогда все обошлось, но думать стал лучше.
«Eсли бы у нас была настоящая профессия (видимо, здесь имеется в виду формальная причастность с сертификацией и лицензией, как у врачей — прим.перев.), то они бы предстали перед профессиональной комиссией, было бы проведено расследование, и если бы их признали виновными — выпнули бы из профессии с позором.»
Не переживайте. В Германии есть такие виды наказания за мошенничество — запрет заниматься определенным судом видом деятельности. Поэтому мошенников, вложившихся в свое обучение и временем и деньгами в этой стране довольно мало.
Советую почитать https://navalny.com/p/4497/
Когда указанный господин «выражался», он оказывается совсем другое имел ввиду. Но и лица принимающие решения (перед которыми он и держал речь) видимо «опять неправильно поняли», как и все другие люди.
В кольчуге вместо углеволокнистой ткани достаточно использовать кевлар. А вот пластичность решетки проблему не решит — решетка будет себя вести как аморфное тело и прогибаться в месте удара. Так что титановые пластины будут использовать еще долго.
Нестолько сама идея плоха — поручить хранение и обработку данных экономя ресурся профи является блестящей идеей. Минусом в ней только возможность контроля со стороны неуполномоченного человека.
А рано или поздно вы начнете монтировать ip-камеры, а позже будете удивляться появлению в публичной сети приватных фото и роликов. Но это самый банальный пример. Также нужно не забыть напомнить, что кто-то сможет управлять извне вашим электронным замком, газовым котлом, намекать на «восстание машин» управляя роботом-пылесосом.
С Дельфи-3 и берут свое начало многие корпоративные разработки. Если правильно помню, то именно в этой версии была расширена работа с клиент-серверными технологиями, введена поддержка 3-хзвенки и отдельный TClientDataset, позволяющий использовать XML-данные. Из минусов стало то, что в отличии от Дельфи-2 изменлся формат PE-файлов и стало не возможно на ней создавати штуки для системы — дрйвера и пр.
Как можно сравнивать не сравнимое, типа Arduino и JavaScript? Это примерно так же, как сравнивать арбузы и девушек между собой. Если ужи хотите «опустить» Ардуино-фреймворк (а не само железо), то хотяб сравните с разработкой на чистом avr-gcc.
конечно ничем не дольше. пример из давнего прошлого: отдельно таблица действий и отдельно таблица юзеров. Построена проекция vw_action_user на основе запроса для построения рапорта за сегоднешний день
select * from action a, users u where a.usr_id=u.id and a.a_date = 'today'.
вызов этой проекции select * from vw_action_user всегда выводил нужные данные для рабочей смены, как в отчете так и в реальном времени для просмотра. А для забывчивых начальников смены не успевших вовремя оформить отчет существовала хранимая, которая делала тоже самое но с указанной в параметре датой:
select * from sp_action_users('01.01.2005')
что уж сложного и ленивого? особенно со средствами генерации отчета в виде иконки, клик на которой приводил к мокрой спине сотрудника.
Хотелось лишь дополнить ответ Дмитрия ( http://habrahabr.ru/post/267211/#comment_8580745 ).
Все вопросы типа «что за юзер скрывается под номером ...» очень запросто решаются однажды составленными и сохраненными запросами, использовать которые не требуется много времени. Хранить их можно как в отдельных файлах вне базы, так и в самой базе в специально имеющихся именно для таких случаев структурных объектах: проекции(view's) и хранимые процедуры.
что от этого меняется? Скорость разработки? Чем больше я трачу времени на разработку, тем больше мне платят денег — это жизненный факт. Моим работодателям не нужно быстрее, им нужно чтоб работало без ошибок и сбоев, как и клиентов, которым они продают комплексы. Меня и так упрекают, что в отличии от своих коллег я очень быстро делаю свою работу — они не успевают за мной. Понимание взаимодействия сущностей? Все и так их прекрасно понимают, именно со стороны сущностей. А вот таблицы базы для них вторичны — просто хранилище данных из сущностей. Также как и контроллеры железки — они просто принимают эти хе сущности и отдают их же, абсолютно не интересуясь что там с базой данных и на каком она сервере крутится.
Так в чем же выигрыш?
Перевод в js-api для меня не делает погоды. Есть только один единственный модуль, который знаком с этой технологией — для обмена данных от внешнего клиента, чтоб переколбасить эти все данные во внутрениий, опримизированный и построеный для системы api и сформировать правильное сообщение в систему. Все. И то, если у клиентов совершенно другая система обмена сообщений (напрмер описанная на хабре HL7), то и этот модулек не будет использоваться.
Так подведем маленький итог нашей дискуссии: Сущности важны в основном процессе. Если у вас обработка(бизнес-логика) крутится непосретственно в базе — то тогда есть удобство использовать сущности. Иначе, любые конечные ветви взаимодествия извне полюбому упирается в плоскую передачу упорядоченных байтов, будь то обмен даххы наприме по tcp, хранение в бинарном файле или в РСУБД.
У самого не малый опыт в базах данных. Тоже возникали подобные мысли о не совершенстве реляцилнных баз. Но есть непреодалимое «но». Называется оно «уровень абстракции». Наверное знаете про трех-звенную архитектуру построения. Вот в этой архитектуре, во второем слое (бизнес-логики) имеет место применять понятие сущьностей. Именно там их и удобнее всего принимать от клиента как сущьности и конверитровать в плоскую модель. И из плоской модели выдавать клиенту уже собранные сущьности.
Добавлю, что в текущей момент работаю с обычной двузвенкой (клинет-сервер), но сущьности использую только на стороне клиентской программы (программы управления роботизированным комплексом). Это и обеспечивает более логичный с точки зрения ООП код, при этом не возникает определенных сложностей и затыков разобраться в миграции данных и понять причину того или другого поведения комплекса.
Тоже можно сказать, что это часный случай. Но в том то все и дело, что любое применение того или иного инструмента является частным случает — в примере от ТС часный случай использования шуруповерта в качестве отбойника.
А если убытки исчисляются миллиардами и потерей рынка?
И в этом конкретном случае речь идет не об ошибках, а о намеренном изменении кода.
Отсюда вывод — сеньор сам по себе человек разумный и не мог не знать о том, что программирует код для мошенничества. Или это был приказ откудато сверху.
В любом случае сейчас спорить глупо. Пройдет разбирательство.тогда послушаем, что официально заявят.
Iomega появилась одновременно CD. И чуть попозже в продаже появились пишущие приводы. Так что CD(650МБ) по объему и сохранности инфы явно выигрывали и не дали Iomegе развернуться на рынке.
Но это не тот ресурс, где это нужно обсуждать.
Специалисты в концернах такого класса в худшем случае работают по тарифам, где самый минимум 2000евро нетто(уже с учетом налогов) и максимум 3500(5000 брутто). А скорее всего работаю по отдельным договорам, где заработок от 60000 брутто в год.
За такие деньги ошибок быть не должно — каждая ошибка и ее последующее исправление обходится концерну в миллиардные убытки. Поэтому тестирование идет не на коленке, а на специальных стендах и выполняется специальнообученными людьми.
В случае мошенничества нужно было сообщить об этом руководству. Не надо мне расказывать сказки, что за это могли уволить. Могли, конечно. Но по суду ещеб и компенсацию выплатили на пару десятилений вперед и такого международного скандала бы не было, все пресеклось бы на этой стадии. Это не Россия. Тут даже профсоюзы настоящие.
Точно такими же мотивами можно оправдать мошенника, «нашедшего» кредитную карточку кого-либо и «оформив кредит» на этого человека.
Специалист, которому предложили запрграммировать «этот трюк», должен быть совсем идит, чтоб не понимать, что это обман и мошенничество. Но наивные идиоты врядли программированием занимаются.
Пять лет назад, устроившись в одну фирмочу в ФРГ столкнулся с подобным вопросом. Из-за плохого на тот момент владения языком подписал одну бумажку этой конторы, что якобы участвовал в каких-то действиях по обучению практикантов. Фирме за это от города отчисляли немного денег и вероятно налоговые плюшки. Мой коллега просто отказался это делать и позже объяснил мне положерие дел. Тогда все обошлось, но думать стал лучше.
Не переживайте. В Германии есть такие виды наказания за мошенничество — запрет заниматься определенным судом видом деятельности. Поэтому мошенников, вложившихся в свое обучение и временем и деньгами в этой стране довольно мало.
А настоящее коровье масло почти совершенно вывелось из употребления, поскольку по существующим ценам производство его невозможно...".
© Из доклада депутата С.Бубнова, сделанного на заседании московской городской думы в октябре 1898 года
Так что ни что не ново под луной.
Когда указанный господин «выражался», он оказывается совсем другое имел ввиду. Но и лица принимающие решения (перед которыми он и держал речь) видимо «опять неправильно поняли», как и все другие люди.
А рано или поздно вы начнете монтировать ip-камеры, а позже будете удивляться появлению в публичной сети приватных фото и роликов. Но это самый банальный пример. Также нужно не забыть напомнить, что кто-то сможет управлять извне вашим электронным замком, газовым котлом, намекать на «восстание машин» управляя роботом-пылесосом.
Как можно сравнивать не сравнимое, типа Arduino и JavaScript? Это примерно так же, как сравнивать арбузы и девушек между собой. Если ужи хотите «опустить» Ардуино-фреймворк (а не само железо), то хотяб сравните с разработкой на чистом avr-gcc.
select * from action a, users u where a.usr_id=u.id and a.a_date = 'today'.
вызов этой проекции select * from vw_action_user всегда выводил нужные данные для рабочей смены, как в отчете так и в реальном времени для просмотра. А для забывчивых начальников смены не успевших вовремя оформить отчет существовала хранимая, которая делала тоже самое но с указанной в параметре датой:
select * from sp_action_users('01.01.2005')
что уж сложного и ленивого? особенно со средствами генерации отчета в виде иконки, клик на которой приводил к мокрой спине сотрудника.
Все вопросы типа «что за юзер скрывается под номером ...» очень запросто решаются однажды составленными и сохраненными запросами, использовать которые не требуется много времени. Хранить их можно как в отдельных файлах вне базы, так и в самой базе в специально имеющихся именно для таких случаев структурных объектах: проекции(view's) и хранимые процедуры.
Так в чем же выигрыш?
Перевод в js-api для меня не делает погоды. Есть только один единственный модуль, который знаком с этой технологией — для обмена данных от внешнего клиента, чтоб переколбасить эти все данные во внутрениий, опримизированный и построеный для системы api и сформировать правильное сообщение в систему. Все. И то, если у клиентов совершенно другая система обмена сообщений (напрмер описанная на хабре HL7), то и этот модулек не будет использоваться.
Так подведем маленький итог нашей дискуссии: Сущности важны в основном процессе. Если у вас обработка(бизнес-логика) крутится непосретственно в базе — то тогда есть удобство использовать сущности. Иначе, любые конечные ветви взаимодествия извне полюбому упирается в плоскую передачу упорядоченных байтов, будь то обмен даххы наприме по tcp, хранение в бинарном файле или в РСУБД.
Добавлю, что в текущей момент работаю с обычной двузвенкой (клинет-сервер), но сущьности использую только на стороне клиентской программы (программы управления роботизированным комплексом). Это и обеспечивает более логичный с точки зрения ООП код, при этом не возникает определенных сложностей и затыков разобраться в миграции данных и понять причину того или другого поведения комплекса.
Тоже можно сказать, что это часный случай. Но в том то все и дело, что любое применение того или иного инструмента является частным случает — в примере от ТС часный случай использования шуруповерта в качестве отбойника.