Если Вы имеете ввиду мою публикацию, то ее основная цель — дать основы внутреннего строения образов прошивок (Firmware). Иначе как Вы себе представляете, например, описание таблицы умножения? Сразу — основы, затем — «разбор полетов».
В перспективе будут статьи с чисто практическими решениями тех или иных задач: разборка/сборка прошивок, внесение в них изменений и т.д.
Если работа посвящена малоизученной области знаний или содержит революционный прорыв, то понять или оценить ее могут и через 20-30 лет.
У нас зав. кафедрой вписывался во все труды как соавтор. Соответственно, он Великий изобретатель и ученый с ооочень большой цитируемостью. Поэтому это точно не мерило значимости, а просто констатация факта принадлежности ученого к направлению в науке.
Человек же не семечки грыз, запустив «file», и даже не «Hello, World!» вывел.
Про 32 байта, это он, надеюсь, для начала написал. Распихает основные форматы, а потом допишет и другие.
Странно читать все эти пункты обеспечения безопасности от автора, который позиционирует себя как «Эксперт по безопасности». Потому что это описание необходимых мероприятий для работы с любой коммерческой информацией.
Со специнформацией никто (если он действительно нормальный сотрудник) не работает ни в облаке, ни с мобильных устройств. И тем более вне служебных помещений.
В случае крайней необходимости, под которую никак не подходит поездка к родственникам или поход на корпоратив, используются спецсредства со спецканалами связи…
А Вы MS DOS поставьте, так чтобы не улетел, будете якорь привязывать…
В статье сравнивается отклик нажатия на клавиатуру через обработку ОС и выводного приложения, которые на каждом аппаратном решении будут разные.
Но это неверно, чтобы отбросить влияние этого «мусора», создайте приложение, которое само управляет I/O и скомпилируйте его на Assembler. Мне кажется, что так были бы более сопоставимые результаты.
Вы же не спрашивали, когда начинали писать статью, т.е. действовали по своему плану. Так и сейчас не надо спрашивать: конечно, пишите.
Только я бы подавал этот материал не в контексте описания работы компиляторов, а как рекомендации разработчикам по написанию кода на Assembler. Ведь запуская на компиляцию уже оптимизированный код, мы ускоряем процесс отладки и экономим память.
Отличная мысль перевести серию материалов по AI.
Лично меня интересуют разработки на MXNet и по Automated Driving. Надеюсь, что Вы не остановитесь просто на переводе статей, а дополните их разбором примеров.
Спасибо за намерения…
Я изучал программирование на доске, т.к. компьютеры и клавиатуры были недоступны. А сейчас клавиатура, как устройство ввода, исчезает даже из касс в магазинах или столовых.
Поэтому Ваши принципы спорны.
Программисту нужны общие знания с упором на математику, физику, логику. Да и кто-то же должен будет еще и таксистом работать или дворником, например.
Чем больше я пытаюсь пояснить свои наблюдения, тем в больший минус меня загоняют…
Попробую еще раз.
Обсуждение идет о том, как работнику остаться.
Я не сторонник силовых методов управления. Выше я пытался как раз и прояснить ответ на Ваше замечание, но со стороны руководителя.
В его обязанности входит забота о коллективе, о каждом конкретном работнике и их взаимоотношениях. Т.е. профессиональный опыт сотрудников, его рост и качество — это все лежит на руководителе. Плюс контроль и обеспечение соответствия з/п всему описанному выше.
Если начальник это не контролирует, то просить бесполезно. Повлиять может только угроза увольнения, да и то, в случае, когда такому руководителю некуда деться (срываются сроки, большие переработки вследствие недостатка исполнителей и др.).
Если руководитель на своем месте, то просить ничего не придется, он и сам все увидит. Будет возможность — будет и повышение. Нет возможности — будут обещания, разговоры и т.д., т.е. психологическая обработка.
Поэтому со стороны работника просить о повышении з/п нет смысла. Просто нужно принять решение остаться с хорошим начальником или все же уйти. А от плохого — я бы однозначно уходил.
Это не советы, а мое личное мнение. Решение каждый должен принимать САМ.
Ну, во-первых, тех, кто доволен з/п не существует. Но это не значит, что нужно сразу менять место работы. Может быть Вас устраивают другие условия, например, свободный график, отличное рабочее место, близость к дому и др.
Во-вторых, что значит
Человек пришел и честно спросил
Это говорит только о том, что руководитель что-то не доглядел, не доделал и т.д. Если «пришел» один раз, то ничего страшного тут может быть и нет. Может быть действительно я (руководитель) что-то проглядел. А если он начнет ходить ежедневно, то лучше лечить этот недуг кардинальными средствами.
Когда он устраивался на работу, то принимал осознанное решение. А вот выпрашивать з/п, по-моему, по крайней мере неэтично. Не устраивают условия — ищи другое место.
Я писал, что каждый должен заниматься своим делом, причем самостоятельно, а не по формуле «делай, что сказано». Эта формула верна только в армии, да и то, наверно, при ведении боевых действий.
А под «ноет» я имел ввиду, что если ко мне пришел сотрудник и требует повышения, то это говорит о том, что я плохо работаю, т.к. не заметил его достижений, или что этот сотрудник слишком высокого мнения о себе и в этом случае принесет много неприятностей.
Кстати, выполнять должностную инструкцию надо всегда. Если это невозможно, то либо она плохо написана, или Вы не на своем месте.
Я понимаю так, что я написал, что-то неправильно, раз мне поставили минус. Т.к. если кто-то не согласен с моими высказываниями, то честнее было бы написать пост в тему, а не минусовать из-подтишка…
Под «свою» модель может и не существовать программы. Я так понял, что автор собирается показать как и что он разработал…
Жду продолжения!
В перспективе будут статьи с чисто практическими решениями тех или иных задач: разборка/сборка прошивок, внесение в них изменений и т.д.
можете почитать.
Т.к. iOS это операционная система (ОС), а ОС вступает в права уже после разметки, то Вы в публикации должны найти для себя что-то интересное.
Код не программиста, но для «Инженера» просто здорово.
Да, а в первом абзаце заключения, я бы просто поставил точку вот после этих слов:
У нас зав. кафедрой вписывался во все труды как соавтор. Соответственно, он Великий изобретатель и ученый с ооочень большой цитируемостью. Поэтому это точно не мерило значимости, а просто констатация факта принадлежности ученого к направлению в науке.
Человек же не семечки грыз, запустив «file», и даже не «Hello, World!» вывел.
Про 32 байта, это он, надеюсь, для начала написал. Распихает основные форматы, а потом допишет и другие.
Со специнформацией никто (если он действительно нормальный сотрудник) не работает ни в облаке, ни с мобильных устройств. И тем более вне служебных помещений.
В случае крайней необходимости, под которую никак не подходит поездка к родственникам или поход на корпоратив, используются спецсредства со спецканалами связи…
В статье сравнивается отклик нажатия на клавиатуру через обработку ОС и выводного приложения, которые на каждом аппаратном решении будут разные.
Но это неверно, чтобы отбросить влияние этого «мусора», создайте приложение, которое само управляет I/O и скомпилируйте его на Assembler. Мне кажется, что так были бы более сопоставимые результаты.
Только я бы подавал этот материал не в контексте описания работы компиляторов, а как рекомендации разработчикам по написанию кода на Assembler. Ведь запуская на компиляцию уже оптимизированный код, мы ускоряем процесс отладки и экономим память.
Лично меня интересуют разработки на MXNet и по Automated Driving. Надеюсь, что Вы не остановитесь просто на переводе статей, а дополните их разбором примеров.
Спасибо за намерения…
А публикация действительно превосходная с очень неожиданной логикой связи между CSS и транзистором.
Поэтому Ваши принципы спорны.
Программисту нужны общие знания с упором на математику, физику, логику. Да и кто-то же должен будет еще и таксистом работать или дворником, например.
Честь, хвала и уважение автору.
Человек описал пример своего времяпровождения, если имеете что-то против, опишите и Вы как проводите свое свободное время…
Попробую еще раз.
Я не сторонник силовых методов управления. Выше я пытался как раз и прояснить ответ на Ваше замечание, но со стороны руководителя.
В его обязанности входит забота о коллективе, о каждом конкретном работнике и их взаимоотношениях. Т.е. профессиональный опыт сотрудников, его рост и качество — это все лежит на руководителе. Плюс контроль и обеспечение соответствия з/п всему описанному выше.
Если начальник это не контролирует, то просить бесполезно. Повлиять может только угроза увольнения, да и то, в случае, когда такому руководителю некуда деться (срываются сроки, большие переработки вследствие недостатка исполнителей и др.).
Если руководитель на своем месте, то просить ничего не придется, он и сам все увидит. Будет возможность — будет и повышение. Нет возможности — будут обещания, разговоры и т.д., т.е. психологическая обработка.
Поэтому со стороны работника просить о повышении з/п нет смысла. Просто нужно принять решение остаться с хорошим начальником или все же уйти. А от плохого — я бы однозначно уходил.
Это не советы, а мое личное мнение. Решение каждый должен принимать САМ.
Во-вторых, что значит
Это говорит только о том, что руководитель что-то не доглядел, не доделал и т.д. Если «пришел» один раз, то ничего страшного тут может быть и нет. Может быть действительно я (руководитель) что-то проглядел. А если он начнет ходить ежедневно, то лучше лечить этот недуг кардинальными средствами.
Когда он устраивался на работу, то принимал осознанное решение. А вот выпрашивать з/п, по-моему, по крайней мере неэтично. Не устраивают условия — ищи другое место.
А под «ноет» я имел ввиду, что если ко мне пришел сотрудник и требует повышения, то это говорит о том, что я плохо работаю, т.к. не заметил его достижений, или что этот сотрудник слишком высокого мнения о себе и в этом случае принесет много неприятностей.
Кстати, выполнять должностную инструкцию надо всегда. Если это невозможно, то либо она плохо написана, или Вы не на своем месте.