All streams
Search
Write a publication
Pull to refresh
40
0
Henadzi Matuts @HenadziMatuts

Инженер-программист

Send message

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

И хотя мы обсуждали это в контексте разработки ПО, оправдания клиента, мол, "это не я дурак, это ии плохой", в некотором роде подтверждают мой тезис о том, что "вопрошающая" сторона будет пытаться всеми силами снимать с себя любую ответвенность за ошибки (хотя в налоговой уже такое не пройдём).

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

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

Я помню у меня был момент, когда при первом прохождении я полез в прохожение (в журнале ЛКИ), что бы перепроверить какие-то моменты, и примерно долистав до нужного места - я вообще не понял о чём идёт речь, потому что моё прохождение пошло по одному месту по совешенно другому пути. Или вот более конкретный пример (под спойлером, потому что там довольно важный сюжетный момент):

Скрытый текст

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

И вот чисто в этом плане, MD, при своей, в целом, камерности, мне кажется ближе к оригиналу. HR - хорош, но вместо "свободного" геймплея первой части, она, в рамках уровня, как будто толкает игрока на вполне определённые "пути". Но это чисто моё субъективное. В любом случае очень жаль, что серия заглохла.

Почти - не считается :)

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

uint8_t b[8] = { 0x01, 0x00, ... }; // допустим, b указывает на 0x00000000
uint8_t* pb = b + 1; // pb указывает на 0x00000001

uint32_t* pu =  (uint32_t*)pb; // pu всё ещё указывает на 0x00000001
uint32_t u = *pu; // ожидаем, что u == 0, но u == 1

Конкретно тот код изначально затачиваля под 32-битную Винду и MSVC, и корретно работал после портирования на десктопный Linux/GCC. А вот при портировании на этот АRМ, понадобилось проверять выравнивания исходных адресов (в местах, где мы не знаем этого изначально), и при необходимости, как Вы и сказали - кастить через буфер.

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

Как отметил комментатор выше - в С++ это UB без исключений, но реализовано и работает в самых распространённых компиляторах.

В С - по идее могут быть приколы, если написать так:

union {
  uint16_t u16;
  uint8_t u8;
} u;

u.u8 = 1;
return u.u16 == 1; // байты u16 не влезающие в u8 - не определены

Но даже в этом случае - они называют это "unspecified", а не "undefined", а это, насколько я понимаю, немного разные вещи.

Ну и справедливости ради, до вашего комментария, о том что тут в принципе где-то может UB до я и знать не знал :) Получается, что из этого вопрос можно вытянуть ещё больше, чем я думал.

Как сказал мой первый руководитель: "всё ваше программирование - это, в конце концов, всего лишь перекладывание данных из одной области памяти в другую" :)

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

Из вопросов такого плана у меня есть один очень хороший, по моему мнению, пример. Мне его впервые задали на техсобесе на сишника в московский Samsung, и хоть в Samsung я в итоге не пошёл (а пошёл в SK hynix), этот вопрос мне хорошо запомнился и я сам не раз его использовал.

Звучит примерно так: написать функцию/макрос, которая в рантайме проверяет порядок байт (endianness) на машине на которой этот код выполняется. Под спойлером (на случай если кто-то захочет проверить себя) - пара возможных решений (верхнее дал я сам):

Скрытый текст
bool isLE()
{
    uint16_t u16 = 1;
    uint8_t* u8 = (uint8_t*)&u16;
    return (u8[0] == 1);
}

bool isLE()
{
    union {
        uint16_t u16;
        uint8_t u8[2];
    } u;
    u.u16 = 1;
    return (u.u8[0] == 1);
}

Почему я считаю это вопрос хорошим? Потому что по ответу, вмещающемуся буквально в 3-4 строчки (или даже в одну), можно вполне себе адекватно оценить насколько кандидат понимает что-то в С. И дело здесь не в решении конкретной проблемы, "практичность" которой можно оспорить (хотя лично мне оно не раз пригождалось), а в понимании как оно вообще всё устроено в этой жизни.

StrongSwan VPN - https://docs.strongswan.org/docs/5.9/devs/objectOrientedC.html, там ещё сильнее заморочились в плане синтаксического сахара на макросах. При этом общую идею авторы взяли из xine. Вполне живая и рабочая схема на самом деле.

В тему внешних дедлайнов вспомнились Лайвлибовские книгомарафоны (на месяц) и книжные вызовы (на год).

Маккензи Дэвис ("Остановись и гори") прям вижу.

Маккензи Дэвис

По-моему, автор описал вещи, которые кажутся полезными лично ему, и описал своего личного "идеального специалиста в вакууме".

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

Ну это уже больше выживач, чем РПГ :) но в целом да, так тоже работает. Опять же, авторы могут не давать прямых указаний, как крафтить условные гвозди, а дать лишь туманные намеки в тексте упражнения. Что, собственно, и происходит.
Занимаюсь самостоятельно чуть меньше года. По сути, в математику пришёл из прикладной криптографии. Изначально хотел въехать в мат.часть эллиптической криптографии, как минимум на уровень понимания актуальных публикаций по теме. Но начав читать попавшуюся литературу — жёстко разбился об порог вхождения. Постепенно начал спускаться к основам, сначала в конечные поля — не пошло, потом в абстрактную алгебру — та же история. В итоге пришёл в теорию чисел, и провёл там чуть больше полугода (в процессе даже снял и залил несколько роликов на ютубчик). На данный момент уже вернулся к абстрактной алгебре, где дела пошли гораздо лучше, чем в прошлый раз.

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

Ещё одна проблема — в необходимости решения упражнений. И это именно необходимость, а не опция. В большом количестве учебной литературы, упражнения — это примерно 30% хронометража (если не все 50), но, при этом, через упражнение подаётся примерно 80% контента книги. (исключительно по моим ощущениям, на объективность не претендую).

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

Но это я уже немного увлёкся аналогиями. А вообще с упражнениями у меня была проблема следующая — я долго не мог привыкнуть к тому что, на чтение главы уходит минут 10-15, а на решение упражнений к этой главе 2-3 дня (в среднем, тут, конечно, ещё зависит от наличия свободного времени). Но со временем втянулся, и упражнения стали казаться чем-то само собой разумеющимся, а процесс решения стал некой формой медитации. Тем более, что в моём случае упражнения были действительно интересными.

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

В SICP этому посвящена третья глава (1979 год, на секундочку).

Вот это имеет смысл! Но никак не корреляция «настоящести» и количества используемых языков программирования.
Согласен, мнение есть мнение. Но, повторюсь, что в моём понимании «настоящий» здесь едва ли имеет отношение к профессии. Интересно было бы услышать разъяснение автора по этому поводу :)
Там нет причинно-следственной связи в духе «я — настоящий программист, потому что программирую на разных языках».

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

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

Всё это к тому, что обе статьи в принципе не про настоящих/ненастоящих программистов. Здесь "настоящий" приравнивается к "приносящий пользу обществу", и ни один из авторов не привязывает это к профессионализму.
А разве где-то в статье программирование на разных языках позиционируется как такой признак?
Сертификация заключается в проверке соблюдения изготовителем требований к производству, наличия у него в штате нужного количества соответствующих специалистов, соответствия технической документации ГОСТам, а продукта — технической документации и т.д.

Вообще, по опыту, зависит от того что и на что сертифицируют. Если речь идёт о средствах хранения данных особой важности и/или криптографической защиты информации, то анализ исходного кода и устройства аппаратной части очень даже входит в программу сертификации.

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

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Registered
Activity