Вопрос: Сервисные инженеры помогите пожалуйста: | Onpioneer

Сервисные инженеры помогите пожалуйста:

1. где можно скачать драйвер для mutton RJ-900c он же xerox 7442?
2. где достать схемы основных блоков управления с предохранителями?
3. где можно достать описание или расшифровку кодов ошибок этого плоттера.
4. поясните подробно пожалуйста алгоритм проверки печатающей головки или вероятные неисправности (выдает чистый лист как с компа так и в тестовом режиме непосредственно с принтера)
Михаил Сковородников
// скачать драйвер// —-Драйвера_Mutoh Rj-900c[ссылка]
// достать схемы// —Mutoh_Forum[ссылка] и так жMutoh_Manual[ссылка]
//описание или расшифровку// —КодОшибок_Mutoh[ссылка]
//алгоритм проверки печатающей головки или вероятные неисправности// — какую нит ошибку видает на дисплее ?
savoljavob1
Всего 1 ответ.

Другие интересные вопросы и ответы

Здравствуйте! Помогите пожалуйста — уже 2 день я не могу с этой страницы прикрепить фото к ответу. Пишет ,,Ошибка при загрузке файла», но с других страниц всё загружает нормально! Помогите пожалуйста!?

Гость6
Попробуйте очистить кеш браузера.
Как очистить кеш читай по ссылке
http://www.rtiopt64.ru/blog/ochistit_kehsh/2014-10-02-201
Влад1
Всего 1 ответ.[my_custom_ad_shortcode1]

Как максимально быстро выучить программирование и попасть в IT-сферу?

John Doe55

В вопросе «Как максимально быстро выучить программирование и попасть в IT-сферу», на самом деле, скрывается два вопроса. Вам нужно понять, что хочется: научиться программированию и работать в IT-сфере, или просто работать в IT-сфере.

Если, тщательно подумав, вы пришли к выводу, что просто хотите работать в IT, то вам не обязательно становиться программистом. Кроме программистов в IT-бизнесе огромное количество других специальностей: тестировщики и дизайнеры, менеджеры продуктов и бизнес девелоперы, и т.д. Для работы на данных специальностях вовсе не обязательно обладать навыками программирования, достаточно просто мыслить как программист. Например, проектировщики интерфейсов обычно пользуются двумя-тремя программами и основную ценность их работы составляют схематичные рисунки и текстовые документы без какого-либо программирования.

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

Если все-таки хочется научиться программированию, то нужно быть готовым очень хорошо учиться и усердно работать, ведь это сложная специальность, требующая хороших фундаментальных знаний и опыта. Как и в любой другой профессии, среди людей, работающих в IT, профессионалов порядка 5—10%, и это абсолютно нормально, ведь существует большое количество типовых, часто повторяющихся задач, которые не требуют сложного программирования и решаются по шаблону. Проведем аналогию со строительством: для того, чтобы возводить здания не нужна сотня архитекторов и один строитель, а, скорее наоборот, требуется один крутой архитектор и много строителей.

Исходя из этого, если поставить перед собой цель для начала попасть на нижний уровень «виртуальной пирамиды профессионализма» в IT-сфере, то, скорее всего, заниматься придется какой-то специализированной прикладной разработкой. Если выделять три сферы, которые чаще всего встречались в моей практике, то это будут:

  • разработка веб-сайтов, особенно создание самих веб-страниц;
  • разработка разного рода несложных embedded-систем, программирование микроконтроллеров, промышленных контроллеров, SCADA-систем;
  • разработка несложного софта, решающего бухгалтерские или учётные задачи: начиная от самодельной программы учета домашней библиотеки DVD-дисков до программирования 1С-бухгалтерии.

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

Если говорить про какой-то конкретный язык программирования, то это будут Javascript, PHP или Python. На изучение именно одного из них и стоит потратить свои силы.

Начиная свой путь, важно понимать что без хороших системных знаний, дальнейший профессиональный рост будет проходить очень медленно. Чтобы его ускорить, вам потребуется потратить много времени и усилий на самостоятельное приобретение фундаментальных знаний и самостоятельное решение типовых задач без заранее прочитанного в книге ответа. В этом помогут платформы типа Coursera или Hexlet, которые, кроме непосредственных знаний, также помогают понять, нравится ли вам программирование как таковое, или просто хочется работать в IT, как мы обсуждали выше.

Говоря о самообразовании, стоит отметить, что не «курсами едиными» формируются знания, но и специализированной литературой. Новичку бы я посоветовал читать только книги, непосредственно обучающие самому языку:

  • По PHP5 – «PHP5» — Д. Котеров, А.Костарев 
  • По Python — Dive into python — Mark Pilgrim (частично переведенная версия ru.diveintopython.net
  • По Javascript рекомендую сайт — learn.javascript.ru
  • По Haskell — learnyouahaskell.com
  • По Go — golang-book.ru

Овладев основами и приступив к работе, можно перейти к более глубоким знаниям в теории алгоритмов, программировании, работе с большими данными и т.д. В этой сфере заслуженным признанием обычно пользуются три книги:

  • Алгоритмы + структуры данных = программы. — Вирт Н. 
  • Structure and Interpretation of Computer Programs Textbook by Gerald Jay Sussman and Hal Abelson
  • Язык C — Б. Керниган, Д. Ричи.

В заключение я хочу пожелать вам удачи и терпения на этом нелегком пути!

Сергей Аверин62
Всего 3 ответа.

Как писать код без багов?

Сергей Чистович18

Я пишу код уже больше 20 лет и, хотя в последнее время больше занимаюсь руководством, на пике формы был способен писать по 500+ строк хорошо работающего кода в день. Вот принципы, которые мне в этом помогали:

  1. Не переобобщайте. Если не получается малой кровью создать универсальное решение, то и неважно, решите конкретную текущую задачу и двигайтесь дальше. Обобщение, даже хорошее, в 70% случаев так и остается нигде больше не использованным.

  2. Не оптимизируйте код заранее. Идея усложнить код ради его ускорения почти всегда ошибочна. Исключение возможно только в том случае, когда именно этот участок код «тормозит» так, что это уже заметно на уровне продукта или бизнеса. «Пессимизировать» код тоже, конечно, не нужно, из двух версий, одинаковых по сложности и по объему кода, выбирайте более быструю. Из этого есть важное следствие: нельзя дублировать данные и нельзя кешировать результаты вычислений там, где этого не требует во весь голос производительность. Больше половины структурных багов возникает из-за того, что «разъехались» кэш и реальные данные, причем еще и отлаживать такое обычно адски сложно, потому что в момент собственно «разъезжания» никакого бага еще не видно, он проявится потом, когда ставить breakpoint-ы и проходить исполнение по шагам уже поздно.

  3. Называйте и группируйте всё происходящее правильно. Код, в котором нет алгоритмических или технологических сложностей, должен читаться как текст, написанный по-английски. Хорошо, когда код, в котором ниндзя куда-то крадётся, выглядит как-то вроде ninja.sneak(…), а не pDst2.trySetCoord(…) и ещё десять строчек после этой, ни одну из которых нельзя забыть. Если функция что-то меняет в состоянии объекта, она не может называться isSomething — если так сделать, следующий же код с её участием обречён на интересный дебаг. Если функция что-то трудно вычисляет, она не может называться getSomething — кто-нибудь наверняка начнёт вызывать её в цикле и удивляться, почему всё тормозит. Класс, который хранит состояние документа, может называться DocumentState или Document, но никак не SDManager. Кстати, про Manager-ов. Если единственное название, которое вы можете выбрать для класса или метода, получается очень расплывчатым, это верный признак того, что вы делаете что-то неправильно. Классы BaseObject и World или функции databaseOps и initService быстро приведут к самым разным проблемам и багам, связанным с нарушениями этого и предыдущего пунктов.

  4. Не смешивайте алгоритмы и другие технологически сложные участки кода с бизнес-логикой. Выразительности современных языков программирования вполне достаточно для того, чтобы, скажем, графический движок компьютерной игры ничего не знал о ниндзя и вертолётах, функции работы с БД в CRM-системе не знали слов «счёт» и «клиент», и т.д. и т.п. Для бизнес-логики типичны постоянные изменения, нечеткость и путаница. Как только сущности с разных уровней абстракции начинают упоминаться в соседних строчках кода, , всё это тут же начинает проникать и в технологически сложный код, и всё взрывается.

  5. Не используйте никакие advanced фичи никакого языка. В С++, например, не стоит пользоваться темплейтной магией, переопределением операторов, множественным наследованием и т.д. и т.п. Экзотические языки программирования (Haskell, диалекты Лиспа, хитрые декларативные язычки, работающие поверх JVM) вообще стоит использовать только как хобби, источник вдохновения. Не напрямую в той работе, за которую вам деньги платят. Эта точка зрения часто вызывает споры. К сожалению, обстоятельно аргументировать её в формате ответа на Знатоках не получится. Поэтому просто сошлюсь на свой почти 20-летний опыт индустриального программирования. Во всех областях и организациях, в которых я успел поработать, что в Яндексе, что в разработке игр, что в науке идея использовать в качестве рабочего инструмента «красивый полёт свободной мысли, недоступный простым умам» оказывалась разрушительной. Часто и для всего проекта, но всегда, без исключений, для автора идеи.

  6. Стоит выкинуть из головы все ООП. Единственное полезное, что в императивные языки пришло из этой идеологии — модификаторы private. Иерархии классов это зло, наследовать реализации нужно себе запретить. Наследовать можно интерфейсы, и то не слишком много уровней. Агрегация почти всегда лучше наследования. Большая часть классических «шаблонов проектирования» уже либо устарела, либо нашла поддержку на уровне языка.

  7. Используйте как можно больше assert’ов, логов и прочих способов поймать незапланированное состояние системы как можно раньше. Очень часто в момент, когда неверное поведение системы становится заметно пользователю, дебажить её уже сложно. Если же вы смогли поймать систему именно в тот момент, когда её внутреннее состояние впервые становится неконсистентным или она начинает вести себя не так, как вы задумывали, чаще всего разобраться в том, почему, становится тривиально.

  8. Каждая лишняя строчка кода это зло. Там, где это вообще возможно, не стоит пользоваться чужим кодом, который вы не прочитали и не поняли от и до. Это касается в том числе и широко известных библиотек и фреймворков общего назначения. Чем меньше кода (включая и тот, который пишешь сам, и тот, от которого зависишь) — тем лучше.

  9. Граничные случаи стоит проверять «в голове» прямо по ходу написания кода. Например: я пишу list.back(), а почему этот список не пуст? Как я «доказал» к этому моменту, что этого не может произойти? Что сделает эта функция, работающая со строчкой, если она пуста?

  10. Любой баг, если он все-таки вам встретился, старайтесь возводить до первопричины и до общего правила. Что я написал в коде такого, что этот баг вообще оказался возможен? Как я могу поменять свои практики так, чтобы больше никогда не допускать таких же? Например, баг состоял в том, что я написал такую-то строчку в функции save и забыл добавить симметричную в функции load. Может быть, пора, наконец, заменить эту пару на одну функцию serialize? Обложить их тестами? Или хотя бы поклясться вслух самому себе, что никогда не будете трогать их по одиночке? Или, например, причина бага была в том, что в указателе pNeighbor содержится null, а программа этого не ожидает и падает. Можно просто воткнуть if (pNeighbor != null) и закрыть баг как исправленный. А где ещё в коде разыменовывается pNeighbor? Везде ли есть такая же проверка? Насколько вообще эта ситуация легальна, может быть, настоящая ошибка там, где pNeighbor впервые оказался нулевым? Если значение pNeighbor это результат отображения NULL из БД на объектную модель, то как этот NULL попал в БД, кто его туда положил и не стоит ли воткнуть там constraint? И т.д и т.п. Никогда не считайте, что ваш код уже идеален! Наблюдайте за собой, совершенствуйтесь, старайтесь работать вместе с людьми, у которых есть, чему поучиться.

Тема эта неисчерпаема, приёмов и приёмчиков можно вспомнить ещё много, но я, пожалуй, остановлюсь на этой десятке. Всем хорошего кода!

А. Плахов41
я не программист, но могу предполагать, что поможет1 делать всё максимально просто,2 отчётливо3 делать только уникальные имена4 писать комментарии5 прежде всего писать псевдокод6 не спешить7 всегда проверять программу в деле8 найти\написать наиболее полный справочник исключений9 работать лишь при ясной голове, не ночью, высыпаться10 отлично знать язык11 смотреть на программу глазами пользователя12 стремиться локализовать ошибку13 делать сущностные тесты, не считать что просто прошедшая тест программа пригоднаIvan Kuznetsov-1
Всего 6 ответов.

На почту пришло письмо о выводе денег. Лохотрон, мошенники?

На почту пришло письмо, за ним другое. Комиссия по заявкам.

Так как вывод средств периодически делаю и с вебмани, и с киви, по невнимательности тыкнула в письмо и открыла. Второе уже открыла из интереса. Вот так они выглядят

Это мошенники? Что произойдет, если нажать на ссылку Заказать вывод в письмах? Можно вообще эти письма открывать или лучше не открывать? Что может произойти, если уже открыла письма? Куда можно на них пожаловаться?

А, может это реально деньги?)

НеЯэто4

Мне на почту неоднократно присылают такие сообщения, я на них даже не реагирую. Причем суммы могут писать абсолютно разные. Пример такого письма.

Бывает даже до смешного, что текст внутри письма с корявым переводом. Цели у мошенников никакой нет, если только заразить ваш компьютер вирусами, реже бывает, что прикрепляют ссылку, переходишь по ней, а там пишут, что вывод денег доступен если заплатите комиссию. Это все лохотрон, подобное не задумываясь надо отправлять в спам не читая даже. Не стоит кормить мошенников даже переводом на 1 рубль, ну или подвергать свой компьютер вирусной атаке. Вирус может покрасть с вашего компьютера платежные данные.

Илта3
Всего 11 ответов.

База данных и работа. Помогите пожалуйста, поделитесь знаниями.

Здравствуйте!
Друг мой попросил помочь или история по классике «тыжпрограммист» Я с радостью ребята мне это интересно.
Поделитесь информацией, какой программой лучше БД создать и что это за слова такие английские? Microsoft Access годен для этого?

Проект: База данных деревянных ремесел.

“Wooden Crafts” — небольшой бизнес-киоск в торговом центре. Они продают деревянные игрушки. “Wooden Crafts” попросили вас создать базу данных, в которой хранятся данные о продуктах и данные поставщика, которые будут представлять отчеты, такие как список продуктов, список поставщиков и стоимость инвентаря.

1. Создайте новую базу данных и назовите ее: Wooden Crafts

2. Импортируйте таблицы “State Data” и “SupplierData” в базу данных Wooden Crafts

3. Создайте таблицу для продуктов, которые “Wooden Crafts” продают в торговом центре и назовите ее: “Products”

4. Используйте тип поиска – “Lookup Wizard”, чтобы подключить таблицу «Products» к таблице «SupplierData»

5. Используйте Relationship Window, чтобы добавить “Referential Integrity” к полям «Code fields»

6. Создайте форму и назовите ее: “Products”

7. Добавьте данные в таблицу «Products», используя форму «Products»

8. Используя “Class Queries Project handout”, создайте Запросы и сохраните каждый запрос

9. Создайте отчеты с использованием сохраненных запросов
Guest2

Microsoft Access для этого годен.

Гость7
Всего 1 ответ.
Вам также может понравиться
Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *